From rfg at tristatelogic.com Sun May 1 00:05:09 2011 From: rfg at tristatelogic.com (Ronald F. Guilmette) Date: Sat, 30 Apr 2011 21:05:09 -0700 Subject: [arin-ppml] ARIN-2011-2 (Was: Forcing POCs and other contacts to act through a "blacklist") In-Reply-To: <20110430034341.GA68511@ussenterprise.ufp.org> Message-ID: <98430.1304222709@tristatelogic.com> In message <20110430034341.GA68511 at ussenterprise.ufp.org>, Leo Bicknell wrote: curran> "Legacy resources that have been abandoned because a company, for curran> example, has dissolved don't really pose a problem." >Having personally tracked spam and botnets back to such blocks in >the past I know first hand John is incorrect in this statement. Leo is more diplomatic that I am. "Incorrect" is not the word that I would have used. John Curran knows good and well that there is a problem. He has simply been doing his level best to steer himself and his minions well and truly clear of taking any responsiblity for fixing it, or even in- vestigating it. I am self-admittedly ignorant about a lot of things, and that probably includes essentally all of the policy manual. But I have been led to believe that ARIN has basically two responsibilities, to wit: 1) To make allocations, fairly and impartially, according to policy, and 2) to keep an acurate data base of who is using all of the number resources that have been assigned to ARIN and ARIN's region, both legacy and non-legacy. As a result of the recent Nortel/Microsoft deal, some have raised questions about ARIN's ability and/or willingness to fulfill its responsibilities to do (1). Based upon what has, apparently, transpired with respect to Leo's proposal however, I would like to assert, here and now, my own personal disbelief in the notion that ARIN is even seriously comitted to doing (2). Given that, I see nothing left for me to do other than to echo Leo's earlier sentiment... >So long, and thanks for all the fish! Regards, rfg From frnkblk at iname.com Sun May 1 00:14:01 2011 From: frnkblk at iname.com (Frank Bulk) Date: Sat, 30 Apr 2011 23:14:01 -0500 Subject: [arin-ppml] Call for a study & survey to obtain necessary information for policy development In-Reply-To: References: <39209.1303885464@tristatelogic.com> <7348D3C8-4EB7-4440-A152-210CC8B0DA3C@arin.net> <471D76419F9EF642962323D13DF1DF69011E60@newserver.arneill-py.local> <471D76419F9EF642962323D13DF1DF69011E61@newserver.arneill-py.local> Message-ID: <002b01cc07b6$33b453c0$9b1cfb40$@iname.com> A survey would be helpful, but the focus should not be on utilization rates (what would we do with that information other than a "nice to know"?) but on what they would want a transfer policy to look like if they wanted to sell or buy address space. Frank -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of John Curran Sent: Saturday, April 30, 2011 6:51 AM To: Public Policy Mailing List Subject: [arin-ppml] Call for a study & survey to obtain necessary information for policy development PPML Folks - Apologies for top-posting, but Mr. Lyon's message which follows contains a specific call for ARIN to charter a study including a survey in order to obtain additional information to assist in policy development. I've not seen any discussion of this suggestion; would it be possible to get feedback from the otherwise shy participants on the PPML mailing list? Thanks! /John John Curran President and CEO ARIN On Apr 29, 2011, at 5:46 PM, Jeffrey Lyon wrote: > All, > > I would like to go on record and state my position in support Mike > Burns' idea that IPv4 resources be transitioned into an open market > exchange. Realizing that i'm making this recommendation without proper > data and generally going against the current what we should do is > charter ARIN to conduct a comprehensive study and: > > - Conduct a survey of the public at large, PPML users, full members, > resource holders, and the AC to gain a clear understanding of > sentiment for or against an open market. > - In the survey, ask IPv4 resource holders to anonymously disclose > their true utilization rates and determine if companies are hoarding > resources either in hopes of future resale or to cover an arbitrary > future need. > - Determine the amount of participants that would come forward if told > they could resell their space on the open market and ultimately > determine how much unneeded space is being locked away in loosely > justified allocations. > - Determine how many companies actually have IPv6 migration plans and > ascertain road blocks, either legitimate or financial, that are > preventing migration. > - Determine the economic impact. Would resource holders be better off > selling their resources to more affluent companies who would be able > to put the space to better use? Might there be a host of struggling > small businesses who would like to put their /17 - /21 on the balance > sheet? Are there companies that would purchase IPv4 space at a premium > if allowed to do so? > - Determine if resource holders would be encouraged to tighten up > internal policies and free up more space if there were a fair market > value assigned to their space. > - Would resource holders support a model that allowed ARIN to take a > small commission on resource sales and then discontinue the practice > of charging an annual fee to its members who are not buying and > selling resources. > > I'm sure I have colleagues here that could help refine what this study > would hope to achieve or provide ideas for other data that can be > tracked. > > Best regards, > -- > Jeffrey Lyon, Leadership Team > jeffrey.lyon at blacklotus.net | http://www.blacklotus.net > Black Lotus Communications - AS32421 > First and Leading in DDoS Protection Solutions > _______________________________________________ > 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 frnkblk at iname.com Sun May 1 00:23:14 2011 From: frnkblk at iname.com (Frank Bulk) Date: Sat, 30 Apr 2011 23:23:14 -0500 Subject: [arin-ppml] If we would pursue a transfer policy without needs justification... Message-ID: <002c01cc07b7$7d400920$77c01b60$@iname.com> If the community does ever debate a transfer policy that eliminates need justification, there should be some verbiage that the selling organization and its successors would not be able to receive more IPv4 space from ARIN's free pool unless there were exceptional circumstances. Otherwise an org could be set up to justify space and then sell, show need, rinse and repeat. Frank From michel at arneill-py.sacramento.ca.us Sun May 1 00:28:22 2011 From: michel at arneill-py.sacramento.ca.us (Michel Py) Date: Sat, 30 Apr 2011 21:28:22 -0700 Subject: [arin-ppml] Interesting personal experiences In-Reply-To: References: <7EB32A4E-DDE3-417F-926E-F4A3D90A893E@virtualized.org><0AC9CF9F-5AE7-4E09-A523-3C63E4BBFFAA@delong.com><7772B728-A6F9-4FE9-9B7C-7C688F76BEE8@virtualized.org><471D76419F9EF642962323D13DF1DF69011E6B@newserver.arneill-py.local><4DBB892E.60604@matthew.at> Message-ID: <471D76419F9EF642962323D13DF1DF69011E6F@newserver.arneill-py.local> Matthew and Bill, It was very interesting to read you feedback, and as a matter of fact I have contributed my own below. But before we get into the details, I have to say that our own personal experiences in this matter are mostly irrelevant to future policy about legacy holders. We are geeks, we are not representative of the legacy holder population. Owen, this applies to you, too. If we had to bill ourselves the way we bill customers, we would be bankrupt. >>> Michel Py wrote: >>> it's about the gut reaction about a new recurring fee. >> Matthew Kaufman wrote: >> Agree. This is why I don't have any end-user IPv6 space of >> my own still. Sure, I'd love to configure up my own >> globally-routable IPv6 across the local microwave IP network >> I have, but that particular hobby already uses more $/month >> out of the budget than I should be spending, so $100/year >> isn't going to go to ARIN for this. > William Herrin wrote: > I coughed up the $500 a few years ago for an AS number > to multihome my legacy addresses and I pay the $100/year > as a result. If IPv6 usage ever takes off, I'll cough up > the $1250 too, but $1250 is a steep barrier to join a > system whose current usage is, well, negligible. Here's my part: I coughed up $500 a few years ago for an AS number (AS 23169) to multihomed my _home_ 6bone prefix. Maybe these years are more than "a few", now :-( Technically, I could have scrounged a re-whoised AS from RIPE following an AS merge, but half the fun was to see if ARIN would give one to me, and I did not embellish my application for it. I stated that that I had 2 tunnels, one with HE and the other one with Viagenie and ARIN took my $500 setup and gave me my AS. What has not changed since then is that IPv6 multihoming through tunnels is nothing more than a lab experiment. I had a very nice setup, BTW: some tunnels terminated in a c7507 and some other into an Olive PC, both of which were iBGP peers, of course. Heck, what do you do for fun on your home network when you're a CCIE going for JNCIE; it's a lot safer than messing the office network, as only one user will complain about downtime and she sleeps in your bed. Anyway, at some point reality kicked in too, and it turned up that IPv6 multihoming through tunnels was not worth $100/year so I decided to write off the $500 initial investment and returned my AS to ARIN. > I don't mean to imply the fee is unfair... it isn't. I don't think anybody serious argues about that. Michel. From dogwallah at gmail.com Sun May 1 00:59:06 2011 From: dogwallah at gmail.com (McTim) Date: Sun, 1 May 2011 07:59:06 +0300 Subject: [arin-ppml] Accusation of fundamental conflict of interest/IPaddress policy pitched directly to ICANN In-Reply-To: <274D7568A828485B91D64F9308B3A24E@video> References: <4DBB208B.4060808@ipinc.net> <112FF1070FFF4B7E957E13C757CCB513@video> <23B533DB44354E3EA201D0941C47C46C@video> <861B310C-7502-49FE-BD13-3D1B123A57EB@delong.com> <274D7568A828485B91D64F9308B3A24E@video> Message-ID: On Sat, Apr 30, 2011 at 11:48 PM, Mike Burns wrote: >> What higher organizational level? > >> The Number Resource Organization and Address Supporting Organization roles >> at the IANA are the collective committee of representatives from the 5 RIRs. >> >Global address policy results from the same policy being passed by all RIRs >> and then ratified (a formality) at the IANA level. The "higher level >> organization" is >completely and directly controlled by the RIRs, as it >> should be. > >> Owen > > I think you misconstrue the relationship and have the tail wagging the dog. > ICANN/IANA is the entity that delegated the roles you describe, the NRO and > ASO roles, to committees which are run by representatives from the RIRs. representatives from the regional communities, not the RIRs themselves. In Africa, for example, we recently elected a ASO Councillor who was not previously an active member of the RIR community, but an active member of the larger Internet Governance/technical and policy community. I would dipute both your and Owen characterisations. The fox is neither guarding the henhouse, nor is the ASO AC "completely and directly controlled by the RIRs". > > "The Internet Assigned Numbers Authority (the IANA), as part of the > administrative functions associated with management of the Internet Protocol > (IP) address space, is responsible for evaluating applications for approval > of new Regional Internet Registries. " > > All I am saying is that although this is not a new "regional" registry, it > is a registry which could compete with the RIRs, and why not have IANA I think you mean ICANN here. > decide, since the representatives of the RIRs may have a vested interest in > "regional-only" self-preservation which would affect their votes? http://www.icann.org/en/aso/aso-mou-29oct04.htm says "The ASO Address Council is responsible for the organizational roles of: 1. undertaking a role in the global policy development process as described in attachment A of this document. 2. providing recommendations to the Board of ICANN concerning the recognition of new RIRs, according to agreed requirements and policies as currently described in document [ICP-2]." so the "vested interest" is in following ICP-2, which does proscribe regionality. However, none of the folk who would like to make money in IPv4 trading seem to want to set up a new "RIR" (complete with allocation and assignment authority), so the regionality argument regarding Conflict of Interest doesn't seem to apply. The ICANN by-laws are pretty clear on this issue: "ARTICLE VIII: ADDRESS SUPPORTING ORGANIZATION Section 1. DESCRIPTION 1. The Address Supporting Organization (ASO) shall advise the Board with respect to policy issues relating to the operation, assignment, and management of Internet addresses." so while it may ultimately be an ICANN Board decision, it will be the ASO that "advises" the ICANN BoT. BTW, there is an independent review of the ASO in progress: http://www.nro.net/news/independent-review-of-the-icann-aso the results of which should be interesting. As for other fora where this could be discussed (besides ICANN), the IGF (global and regionals) springs to mind, as does the OECD and even perhaps the CoE. None of whom would be the "deciders", but could provide platforms for wider discussion (and capacity building) around these issues. -- Cheers, McTim "A name indicates what we seek. An address indicates where it is. A route indicates how we get there."? Jon Postel From jcurran at arin.net Sun May 1 01:57:58 2011 From: jcurran at arin.net (John Curran) Date: Sun, 1 May 2011 05:57:58 +0000 Subject: [arin-ppml] If we would pursue a transfer policy without needs justification... In-Reply-To: <002c01cc07b7$7d400920$77c01b60$@iname.com> References: <002c01cc07b7$7d400920$77c01b60$@iname.com> Message-ID: <82026FDB-C821-4C2A-9A46-6A5162147F21@arin.net> On May 1, 2011, at 6:23 AM, Frank Bulk wrote: > If the community does ever debate a transfer policy that eliminates need > justification, there should be some verbiage that the selling organization > and its successors would not be able to receive more IPv4 space from ARIN's > free pool unless there were exceptional circumstances. Otherwise an org > could be set up to justify space and then sell, show need, rinse and repeat. A similar provision exists in APNIC's transfer policy which makes selling organization ineligible to receive any further IPv4 address allocations or assignments for a period of 12 months after the transfer (or until APNIC reaches its austerity phase with 1 final allocation allowed per organization from their final /8 of space) I'm expressing neither support or concern over the provision, but believe as "running code", it's information that the community should be aware of in this discussion. FYI, /John John Curran President and CEO ARIN From jcurran at arin.net Sun May 1 02:19:46 2011 From: jcurran at arin.net (John Curran) Date: Sun, 1 May 2011 06:19:46 +0000 Subject: [arin-ppml] ARIN-2011-2 (Was: Forcing POCs and other contacts to act through a "blacklist") In-Reply-To: <98430.1304222709@tristatelogic.com> References: <98430.1304222709@tristatelogic.com> Message-ID: <3BEF530A-B50C-400A-893B-CD6497CC3FD9@arin.net> On May 1, 2011, at 6:05 AM, Ronald F. Guilmette wrote: > curran> "Legacy resources that have been abandoned because a company, for > curran> example, has dissolved don't really pose a problem." > ... > > John Curran knows good and well that there is a problem. He has simply > been doing his level best to steer himself and his minions well and > truly clear of taking any responsiblity for fixing it, or even in- > vestigating it. Ron - Leo seems to have pulled one sentence from the middle of my remarks; here's the full statement in context from the transcript - "Legacy resources that have been abandoned because a company, for example, has dissolved don't really pose a problem. Misuse of legacy resources could be problematic, could take more resources than handling other cases. And, again, we need to know is there a prioritization here that the community would apply if we adopt this policy." I meant exactly what I said, which is that ARIN doesn't have difficulties cleaning up resources which are truly abandoned... it's fairly simple to do so once we receive a report and can determine the address holder is defunct. I was not speaking of resources of a defunct organization which are in active use and likely being misused; those can indeed be problem *which is precisely as I said in my remarks* We're absolutely willing to put more resources on these types of abuse, but need to understand which targets and what level of resources the members want us to invest here. Thanks, /John John Curran President and CEO ARIN From dogwallah at gmail.com Sun May 1 03:15:55 2011 From: dogwallah at gmail.com (McTim) Date: Sun, 1 May 2011 10:15:55 +0300 Subject: [arin-ppml] ARIN-2011-2 (Was: Forcing POCs and other contacts to act through a "blacklist") In-Reply-To: <3BEF530A-B50C-400A-893B-CD6497CC3FD9@arin.net> References: <98430.1304222709@tristatelogic.com> <3BEF530A-B50C-400A-893B-CD6497CC3FD9@arin.net> Message-ID: Hi John, On Sun, May 1, 2011 at 9:19 AM, John Curran wrote: > > ?We're absolutely willing to put more resources on these types > ?of abuse, but need to understand which targets and what level > ?of resources the members want us to invest here. I would rather ARIN survey the Members/community on this issue rather than the "if you could make money flogging your IP space would you want to" kind of survey. In addition, I think that rfg has a rather simplistic view of accuracy of the DB entries. Perhaps John, you can enlighten us as to whois responsible for said accuracy?. I had thought that it was largely down to holders of resources to keep information up-to-date, with the caveat that ARIN RS does have some role to play for those allocations and direct assignments it maintains. What I see happening is that that ARIN is being put in a damned if they do and damned if they don't position in re: accuracy of legacy resources, with some folk saying "ARIN is not doing its job regarding accuracy of legacy entries" and others saying "don't you dare touch any legacy entries". Anyway that's my 2 shillings. -- Cheers, McTim "A name indicates what we seek. An address indicates where it is. A route indicates how we get there."? Jon Postel From aservin at lacnic.net Sun May 1 08:57:50 2011 From: aservin at lacnic.net (Arturo Servin) Date: Sun, 1 May 2011 09:57:50 -0300 Subject: [arin-ppml] Analogies In-Reply-To: References: <39209.1303885464@tristatelogic.com> <75822E125BCB994F8446858C4B19F0D7173057C827@SUEX07-MBX-04.ad.syr.edu> <471D76419F9EF642962323D13DF1DF69011E5C@newserver.arneill-py.local> <7348D3C8-4EB7-4440-A152-210CC8B0DA3C@arin.net> <471D76419F9EF642962323D13DF1DF69011E60@newserver.arneill-py.local> <583A067A-B8AE-4026-844E-6769D1D7CF88@arin.net> <471D76419F9EF642962323D13DF1DF69011E61@newserver.arneill-py.local> <7DF2A1C4-1799-486B-A631-2E1119C22A7C@arin.net> <3CCC6D1F-11F4-40BC-B102-CC6744A5E709@virtualized.org> <4DB9BACE.6000307@ipinc.net> <0E134D8B-0A4B-466E-B261-9C7D0ED11867@virtualized.org> <388190E3-08F2-4AC7-870A-621A2FD6EEFE@virtualized.org> Message-ID: <7CD5F1ED-DB5D-44F2-82F7-4770E6E2D2E1@lacnic.net> LACNIC does not. -as On 30 Apr 2011, at 02:31, Owen DeLong wrote: > APNIC, RIPE, AfriNIC, and LACNIC all charge their legacy holders > annual fees to the best of my knowledge. From owen at delong.com Sun May 1 12:05:36 2011 From: owen at delong.com (Owen DeLong) Date: Sun, 1 May 2011 09:05:36 -0700 Subject: [arin-ppml] Statistics regarding NRPM 8.3 Transfers to date In-Reply-To: <4DBCA58D.4060704@sprunk.org> References: <75E9BD24-F12F-42BF-A989-CF6CC282B28E@arin.net> <7406316661701612155@unknownmsgid> <3F57F52B-F1F1-4450-B493-AA4D544D8D15@arin.net> <8740380157159276993@unknownmsgid> <49E26DCB-DAF7-4A0A-912E-F981494979F5@delong.com> <4DBC2AEB.9040307@matthew.at> <4DBCA58D.4060704@sprunk.org> Message-ID: <2344ADD7-616E-4FA7-9552-19735926A952@delong.com> Sent from my iPad On Apr 30, 2011, at 17:13, Stephen Sprunk wrote: > On 30-Apr-11 10:40, Owen DeLong wrote: >> On Apr 30, 2011, at 8:29 AM, Matthew Kaufman wrote: >>> And then once you've justified 980 addresses to ARIN, you should clearly be able to use 8.3 transfers twice in a row, for two separate /23s... it wouldn't make much sense for ARIN to require you to resubmit all the justification paperwork you just sent them a few hours ago, would it? >> Again, I disagree. The intent of this phrase was to reduce the amount of disaggregation of the routing table that will be caused by transfers. Allowing this revolving door use of the transfer policy will increase disaggregation. > > Imagine you qualify to receive a /23 but there are no /23s available on > the market. AIUI, the policy's intent was to prohibit you buying half > of someone else's /22. However, is there any harm in ARIN fulfilling > your request with my two disjoint /24s in that scenario? Keep in mind > you could get my /24s (or one from me and one from someone else) anyway > via two separate transfer requests. > No, that intent went out the window early in the debate. It was replaced with an intent to prevent you from creating a /18 equivalent out of disparate /24 sized chunks of someone else's /8. > This interpretation, which could be creatively read into the policy > text, could easily explain the statistics recently posted and, IMHO, > doesn't violate the policy's intent or goals. > While I would be fine with ARIN fulfilling your request with 2 /24s that were already disjoint, however, I don't want to see someone with, say, 44/8 find a buyer that needs a /20 and sell them 44.0.5/24, 44.0.8/24, 44.15.23/24, 44.28.6/24, etc. Owen From jcurran at arin.net Sun May 1 12:25:30 2011 From: jcurran at arin.net (John Curran) Date: Sun, 1 May 2011 16:25:30 +0000 Subject: [arin-ppml] Statistics regarding NRPM 8.3 Transfers to date In-Reply-To: <2344ADD7-616E-4FA7-9552-19735926A952@delong.com> References: <75E9BD24-F12F-42BF-A989-CF6CC282B28E@arin.net> <7406316661701612155@unknownmsgid> <3F57F52B-F1F1-4450-B493-AA4D544D8D15@arin.net> <8740380157159276993@unknownmsgid> <49E26DCB-DAF7-4A0A-912E-F981494979F5@delong.com> <4DBC2AEB.9040307@matthew.at> <4DBCA58D.4060704@sprunk.org> <2344ADD7-616E-4FA7-9552-19735926A952@delong.com> Message-ID: On May 1, 2011, at 6:05 PM, Owen DeLong wrote: >> Imagine you qualify to receive a /23 but there are no /23s available on >> the market. AIUI, the policy's intent was to prohibit you buying half >> of someone else's /22. However, is there any harm in ARIN fulfilling >> your request with my two disjoint /24s in that scenario? Keep in mind >> you could get my /24s (or one from me and one from someone else) anyway >> via two separate transfer requests. >> > No, that intent went out the window early in the debate. It was replaced with > an intent to prevent you from creating a /18 equivalent out of disparate /24 sized > chunks of someone else's /8. >> This interpretation, which could be creatively read into the policy >> text, could easily explain the statistics recently posted and, IMHO, >> doesn't violate the policy's intent or goals. >> > While I would be fine with ARIN fulfilling your request with 2 /24s that were already > disjoint, however, I don't want to see someone with, say, 44/8 find a buyer that needs > a /20 and sell them 44.0.5/24, 44.0.8/24, 44.15.23/24, 44.28.6/24, etc. Owen - Please elaborate. The phrase "single aggregate", if moved to the resources transferred clause, would definitely preclude the example that Stephen provides. /John From fw at deneb.enyo.de Sun May 1 12:25:45 2011 From: fw at deneb.enyo.de (Florian Weimer) Date: Sun, 01 May 2011 18:25:45 +0200 Subject: [arin-ppml] Fwd: [arin-announce] LRSA Requirement Modified for 8.3 Transfers In-Reply-To: <6ED911B8-585E-440F-A868-D63945082C09@arin.net> (John Curran's message of "Wed, 20 Apr 2011 18:29:28 +0000") References: <4DAEE770.7010400@arin.net> <4506B4AA-98E5-4150-9C36-CF123A1762C1@queuefull.net> <878vv4ltue.fsf@mid.deneb.enyo.de> <6ED911B8-585E-440F-A868-D63945082C09@arin.net> Message-ID: <87pqo2mlpy.fsf@mid.deneb.enyo.de> * John Curran: > Florian - > > This has no impact on inter-RIR transfers today, as we still lack approved > policies in the regions to allow such. Most of the discussions around such > policies have included having the seller's RIR confirm that the resources > are registered correctly, and that would imply similar practices if/when > inter-RIR transfers are recognized. I was under the impression that the lack of an (L)RSA requirement would implicitly open the door to inter-RIR transfers. (Registration with another RIR could probably serve as proper documentation that the transferring party actually controls the address space subject to the transfer.) Thanks for clarifying that this is not the case. From kevin.billings at spirittelecom.com Sun May 1 13:03:15 2011 From: kevin.billings at spirittelecom.com (Kevin Billings) Date: Sun, 1 May 2011 13:03:15 -0400 Subject: [arin-ppml] ARIN-PPML Digest, Vol 71, Issue 2 Message-ID: <0rvm28dgufjqn6euib6t81rx.1304269393226@email.android.com> Sent from my Verizon Wireless Phone "arin-ppml-request at arin.net" wrote: Send ARIN-PPML mailing list submissions to arin-ppml at arin.net To subscribe or unsubscribe via the World Wide Web, visit http://lists.arin.net/mailman/listinfo/arin-ppml or, via email, send a message with subject or body 'help' to arin-ppml-request at arin.net You can reach the person managing the list at arin-ppml-owner at arin.net When replying, please edit your Subject line so it is more specific than "Re: Contents of ARIN-PPML digest..." Today's Topics: 1. Re: Accusation of fundamental conflict of interest/IPaddress policy pitched directly to ICANN (McTim) 2. Re: If we would pursue a transfer policy without needs justification... (John Curran) 3. Re: ARIN-2011-2 (Was: Forcing POCs and other contacts to act through a "blacklist") (John Curran) 4. Re: ARIN-2011-2 (Was: Forcing POCs and other contacts to act through a "blacklist") (McTim) 5. Re: Analogies (Arturo Servin) ---------------------------------------------------------------------- Message: 1 Date: Sun, 1 May 2011 07:59:06 +0300 From: McTim To: Mike Burns Cc: John Curran , arin-ppml at arin.net Subject: Re: [arin-ppml] Accusation of fundamental conflict of interest/IPaddress policy pitched directly to ICANN Message-ID: Content-Type: text/plain; charset=ISO-8859-1 On Sat, Apr 30, 2011 at 11:48 PM, Mike Burns wrote: >> What higher organizational level? > >> The Number Resource Organization and Address Supporting Organization roles >> at the IANA are the collective committee of representatives from the 5 RIRs. >> >Global address policy results from the same policy being passed by all RIRs >> and then ratified (a formality) at the IANA level. The "higher level >> organization" is >completely and directly controlled by the RIRs, as it >> should be. > >> Owen > > I think you misconstrue the relationship and have the tail wagging the dog. > ICANN/IANA is the entity that delegated the roles you describe, the NRO and > ASO roles, to committees which are run by representatives from the RIRs. representatives from the regional communities, not the RIRs themselves. In Africa, for example, we recently elected a ASO Councillor who was not previously an active member of the RIR community, but an active member of the larger Internet Governance/technical and policy community. I would dipute both your and Owen characterisations. The fox is neither guarding the henhouse, nor is the ASO AC "completely and directly controlled by the RIRs". > > "The Internet Assigned Numbers Authority (the IANA), as part of the > administrative functions associated with management of the Internet Protocol > (IP) address space, is responsible for evaluating applications for approval > of new Regional Internet Registries. " > > All I am saying is that although this is not a new "regional" registry, it > is a registry which could compete with the RIRs, and why not have IANA I think you mean ICANN here. > decide, since the representatives of the RIRs may have a vested interest in > "regional-only" self-preservation which would affect their votes? http://www.icann.org/en/aso/aso-mou-29oct04.htm says "The ASO Address Council is responsible for the organizational roles of: 1. undertaking a role in the global policy development process as described in attachment A of this document. 2. providing recommendations to the Board of ICANN concerning the recognition of new RIRs, according to agreed requirements and policies as currently described in document [ICP-2]." so the "vested interest" is in following ICP-2, which does proscribe regionality. However, none of the folk who would like to make money in IPv4 trading seem to want to set up a new "RIR" (complete with allocation and assignment authority), so the regionality argument regarding Conflict of Interest doesn't seem to apply. The ICANN by-laws are pretty clear on this issue: "ARTICLE VIII: ADDRESS SUPPORTING ORGANIZATION Section 1. DESCRIPTION 1. The Address Supporting Organization (ASO) shall advise the Board with respect to policy issues relating to the operation, assignment, and management of Internet addresses." so while it may ultimately be an ICANN Board decision, it will be the ASO that "advises" the ICANN BoT. BTW, there is an independent review of the ASO in progress: http://www.nro.net/news/independent-review-of-the-icann-aso the results of which should be interesting. As for other fora where this could be discussed (besides ICANN), the IGF (global and regionals) springs to mind, as does the OECD and even perhaps the CoE. None of whom would be the "deciders", but could provide platforms for wider discussion (and capacity building) around these issues. -- Cheers, McTim "A name indicates what we seek. An address indicates where it is. A route indicates how we get there."? Jon Postel ------------------------------ Message: 2 Date: Sun, 1 May 2011 05:57:58 +0000 From: John Curran To: "frnkblk at iname.com" Cc: "ppml at arin.net" Subject: Re: [arin-ppml] If we would pursue a transfer policy without needs justification... Message-ID: <82026FDB-C821-4C2A-9A46-6A5162147F21 at arin.net> Content-Type: text/plain; charset="us-ascii" On May 1, 2011, at 6:23 AM, Frank Bulk wrote: > If the community does ever debate a transfer policy that eliminates need > justification, there should be some verbiage that the selling organization > and its successors would not be able to receive more IPv4 space from ARIN's > free pool unless there were exceptional circumstances. Otherwise an org > could be set up to justify space and then sell, show need, rinse and repeat. A similar provision exists in APNIC's transfer policy which makes selling organization ineligible to receive any further IPv4 address allocations or assignments for a period of 12 months after the transfer (or until APNIC reaches its austerity phase with 1 final allocation allowed per organization from their final /8 of space) I'm expressing neither support or concern over the provision, but believe as "running code", it's information that the community should be aware of in this discussion. FYI, /John John Curran President and CEO ARIN ------------------------------ Message: 3 Date: Sun, 1 May 2011 06:19:46 +0000 From: John Curran To: "Ronald F. Guilmette" Cc: "arin-ppml at arin.net" Subject: Re: [arin-ppml] ARIN-2011-2 (Was: Forcing POCs and other contacts to act through a "blacklist") Message-ID: <3BEF530A-B50C-400A-893B-CD6497CC3FD9 at arin.net> Content-Type: text/plain; charset="us-ascii" On May 1, 2011, at 6:05 AM, Ronald F. Guilmette wrote: > curran> "Legacy resources that have been abandoned because a company, for > curran> example, has dissolved don't really pose a problem." > ... > > John Curran knows good and well that there is a problem. He has simply > been doing his level best to steer himself and his minions well and > truly clear of taking any responsiblity for fixing it, or even in- > vestigating it. Ron - Leo seems to have pulled one sentence from the middle of my remarks; here's the full statement in context from the transcript - "Legacy resources that have been abandoned because a company, for example, has dissolved don't really pose a problem. Misuse of legacy resources could be problematic, could take more resources than handling other cases. And, again, we need to know is there a prioritization here that the community would apply if we adopt this policy." I meant exactly what I said, which is that ARIN doesn't have difficulties cleaning up resources which are truly abandoned... it's fairly simple to do so once we receive a report and can determine the address holder is defunct. I was not speaking of resources of a defunct organization which are in active use and likely being misused; those can indeed be problem *which is precisely as I said in my remarks* We're absolutely willing to put more resources on these types of abuse, but need to understand which targets and what level of resources the members want us to invest here. Thanks, /John John Curran President and CEO ARIN ------------------------------ Message: 4 Date: Sun, 1 May 2011 10:15:55 +0300 From: McTim To: John Curran Cc: "arin-ppml at arin.net" Subject: Re: [arin-ppml] ARIN-2011-2 (Was: Forcing POCs and other contacts to act through a "blacklist") Message-ID: Content-Type: text/plain; charset=ISO-8859-1 Hi John, On Sun, May 1, 2011 at 9:19 AM, John Curran wrote: > > ?We're absolutely willing to put more resources on these types > ?of abuse, but need to understand which targets and what level > ?of resources the members want us to invest here. I would rather ARIN survey the Members/community on this issue rather than the "if you could make money flogging your IP space would you want to" kind of survey. In addition, I think that rfg has a rather simplistic view of accuracy of the DB entries. Perhaps John, you can enlighten us as to whois responsible for said accuracy?. I had thought that it was largely down to holders of resources to keep information up-to-date, with the caveat that ARIN RS does have some role to play for those allocations and direct assignments it maintains. What I see happening is that that ARIN is being put in a damned if they do and damned if they don't position in re: accuracy of legacy resources, with some folk saying "ARIN is not doing its job regarding accuracy of legacy entries" and others saying "don't you dare touch any legacy entries". Anyway that's my 2 shillings. -- Cheers, McTim "A name indicates what we seek. An address indicates where it is. A route indicates how we get there."? Jon Postel ------------------------------ Message: 5 Date: Sun, 1 May 2011 09:57:50 -0300 From: Arturo Servin To: arin-ppml Subject: Re: [arin-ppml] Analogies Message-ID: <7CD5F1ED-DB5D-44F2-82F7-4770E6E2D2E1 at lacnic.net> Content-Type: text/plain; charset=us-ascii LACNIC does not. -as On 30 Apr 2011, at 02:31, Owen DeLong wrote: > APNIC, RIPE, AfriNIC, and LACNIC all charge their legacy holders > annual fees to the best of my knowledge. ------------------------------ _______________________________________________ ARIN-PPML mailing list ARIN-PPML at arin.net http://lists.arin.net/mailman/listinfo/arin-ppml End of ARIN-PPML Digest, Vol 71, Issue 2 **************************************** -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcurran at arin.net Sun May 1 13:16:27 2011 From: jcurran at arin.net (John Curran) Date: Sun, 1 May 2011 17:16:27 +0000 Subject: [arin-ppml] REVISED Statistics regarding NRPM 8.3 Transfers to date In-Reply-To: <75E9BD24-F12F-42BF-A989-CF6CC282B28E@arin.net> References: <75E9BD24-F12F-42BF-A989-CF6CC282B28E@arin.net> Message-ID: <6389E6EC-7D1F-4CDA-8370-2ECB83D36029@arin.net> On Apr 29, 2011, at 7:08 PM, John Curran wrote: To date, there have been 10 completed specified transfers under NRPM 8.3: Distribution of IPv4 Resources transferred: 1 /17 3 /20s 1 /21 1 /23 49 /24s PPML Readers - I'm going to expand on the above for sake of clarity, as it occurs to me that the provided summary was not at all useful for analysis as we combined any resources that were not a clean CIDR block boundary into the "49 /24s" entry at the end of the list. There were 10 specified transfers total. The recipients received the following aggregates (one recipient per line, all under RSA) - (1) /24 (1) /24 (1) /23 (1) /17 (2) /20 (1) /22, (2) /23 (1) /20, (1) /21, (2) /22, (2) /23 (1) /20 (1) /21 (1) /23, (1) /24 In some cases, the transfers were record keeping in nature (e.g. an entity recording specified transfer of an address lock already in use by another related entity) Additionally, in many cases the smaller blocks are actually contiguous but not aligned on a CIDR block boundary (e.g. a large block with smaller blocks on either side being reported as 3 distinct transferred aggregates) I hope this helps, and we will keep trying to provide better insight into use of the NRPM 8.3 specified transfer policy. Thanks! /John John Curran President and CEO ARIN -------------- next part -------------- An HTML attachment was scrubbed... URL: From stephen at sprunk.org Sun May 1 13:44:21 2011 From: stephen at sprunk.org (Stephen Sprunk) Date: Sun, 01 May 2011 12:44:21 -0500 Subject: [arin-ppml] Statistics regarding NRPM 8.3 Transfers to date In-Reply-To: <2344ADD7-616E-4FA7-9552-19735926A952@delong.com> References: <75E9BD24-F12F-42BF-A989-CF6CC282B28E@arin.net> <7406316661701612155@unknownmsgid> <3F57F52B-F1F1-4450-B493-AA4D544D8D15@arin.net> <8740380157159276993@unknownmsgid> <49E26DCB-DAF7-4A0A-912E-F981494979F5@delong.com> <4DBC2AEB.9040307@matthew.at> <4DBCA58D.4060704@sprunk.org> <2344ADD7-616E-4FA7-9552-19735926A952@delong.com> Message-ID: <4DBD9BF5.7050002@sprunk.org> On 01-May-11 11:05, Owen DeLong wrote: > On Apr 30, 2011, at 17:13, Stephen Sprunk wrote: >> On 30-Apr-11 10:40, Owen DeLong wrote: >>> On Apr 30, 2011, at 8:29 AM, Matthew Kaufman wrote: >>>> And then once you've justified 980 addresses to ARIN, you should clearly be able to use 8.3 transfers twice in a row, for two separate /23s... it wouldn't make much sense for ARIN to require you to resubmit all the justification paperwork you just sent them a few hours ago, would it? >>> Again, I disagree. The intent of this phrase was to reduce the amount of disaggregation of the routing table that will be caused by transfers. Allowing this revolving door use of the transfer policy will increase disaggregation. >> Imagine you qualify to receive a /23 but there are no /23s available on the market. AIUI, the policy's intent was to prohibit you buying half of someone else's /22. However, is there any harm in ARIN fulfilling your request with my two disjoint /24s in that scenario? Keep in mind you could get my /24s (or one from me and one from someone else) anyway via two separate transfer requests. > No, that intent went out the window early in the debate. It was replaced with an intent to prevent you from creating a /18 equivalent out of disparate /24 sized chunks of someone else's /8. Hmm. I was concerned about the latter as well, but I didn't realize we had agreed to allow deaggregation in the first place. That makes things easier. >> This interpretation, which could be creatively read into the policy text, could easily explain the statistics recently posted and, IMHO, doesn't violate the policy's intent or goals. > While I would be fine with ARIN fulfilling your request with 2 /24s that were already disjoint, however, I don't want to see someone with, say, 44/8 find a buyer that needs a /20 and sell them 44.0.5/24, 44.0.8/24, 44.15.23/24, 44.28.6/24, etc. How about this: "The transferor's resources may be recursively bisected the minimum number of times necessary to create one CIDR block equal to the transferee's justified need." So, if someone with a /8 wants to sell you a /20, their /8 would be divided into one /9, one /10, one /11, one /12, one /13, one /14, one /15, one /16, one /17, one /18, one /19 and two /20s, and then you would get one of those /20s. If you agree with that, I'll figure out how to shoehorn it into the existing text of NRPM 8.3, though I'd prefer a complete restructuring. I also see several ugly possibilities when the transferor has multiple blocks of different sizes available to sell, but I'd need to see examples of how you'd want those handled before I could address them (no pun intended). However, assuming that aggregation has inherent value to buyers, sellers will avoid them out of self-interest, so we may not need to put anything into policy. Is anyone seriously concerned that assumption is wrong? S -- Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3646 bytes Desc: S/MIME Cryptographic Signature URL: From cgrundemann at gmail.com Sun May 1 15:14:25 2011 From: cgrundemann at gmail.com (Chris Grundemann) Date: Sun, 1 May 2011 13:14:25 -0600 Subject: [arin-ppml] Microsoft receives court approval for transfer as agreed with ARIN In-Reply-To: References: <39209.1303885464@tristatelogic.com> <75822E125BCB994F8446858C4B19F0D7173057C827@SUEX07-MBX-04.ad.syr.edu> <91860AD2-F0CB-42F3-9974-E280A9B1F690@arin.net> <20110427195407.GB88483@ussenterprise.ufp.org> <5874CCF0-0862-4BBC-ADEC-AEE5B229170B@arin.net> <4DB9BCC7.9080505@ipinc.net> Message-ID: John, My understanding is that all requests for IPv4 space from ARIN (allocation and assignment) currently require officer attestation in order to be accepted by ARIN. Two questions: 1) Is that understanding correct? 2) Is officer attestation also required for all transfer justifications/requests? Thanks! ~Chris On Thu, Apr 28, 2011 at 16:15, John Curran wrote: > On Apr 28, 2011, at 3:15 PM, Ted Mittelstaedt wrote: >> >> The fact is that transparency isn't important for the justification >> end of things if you think about it. ?As long as 80% of the IPv4 >> addresses that Microsoft got from the sale go into use within 12 months >> or whatever their utilization requirement is, then we don't need to >> have transparency there. ?We DO need to have someone following up >> and making sure this happens on these very large public consumptions, >> though. > > ARIN may review the current usage of any resources maintained > in the ARIN database, and while I don't know about this being > a "very large public consumption" relatively speaking, the point > is noted for followup. > > /John > > John Curran > President and CEO > ARIN > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > -- @ChrisGrundemann weblog.chrisgrundemann.com www.burningwiththebush.com www.theIPv6experts.net www.coisoc.org From matthew at matthew.at Sun May 1 17:25:05 2011 From: matthew at matthew.at (Matthew Kaufman) Date: Sun, 01 May 2011 14:25:05 -0700 Subject: [arin-ppml] Statistics regarding NRPM 8.3 Transfers to date In-Reply-To: <4DBD9BF5.7050002@sprunk.org> References: <75E9BD24-F12F-42BF-A989-CF6CC282B28E@arin.net> <7406316661701612155@unknownmsgid> <3F57F52B-F1F1-4450-B493-AA4D544D8D15@arin.net> <8740380157159276993@unknownmsgid> <49E26DCB-DAF7-4A0A-912E-F981494979F5@delong.com> <4DBC2AEB.9040307@matthew.at> <4DBCA58D.4060704@sprunk.org> <2344ADD7-616E-4FA7-9552-19735926A952@delong.com> <4DBD9BF5.7050002@sprunk.org> Message-ID: <4DBDCFB1.4040105@matthew.at> On 5/1/2011 10:44 AM, Stephen Sprunk wrote: > However, assuming that aggregation has inherent value to > buyers, sellers will avoid them out of self-interest, so we may not need > to put anything into policy. Is anyone seriously concerned that > assumption is wrong? That's exactly why I don't think we need really complicated language that then has lots of associated loopholes. If aggregation is good, providers will encourage it, and addresses that are big aggregates will have more value. Done. Matthew Kaufman From stephen at sprunk.org Sun May 1 18:55:01 2011 From: stephen at sprunk.org (Stephen Sprunk) Date: Sun, 01 May 2011 17:55:01 -0500 Subject: [arin-ppml] ARIN-2011-2 (Was: Forcing POCs and other contacts to act through a "blacklist") In-Reply-To: References: <000001cc0671$a9715630$fc540290$@com> <83915.1304131731@tristatelogic.com> <20110430025750.GA67943@ussenterprise.ufp.org> <-2254271368334540242@unknownmsgid> Message-ID: <4DBDE4C5.5050600@sprunk.org> On 30-Apr-11 21:47, William Herrin wrote: > Personally, my opposition to 2011-2 was that "proactively looking" was > too open-ended. I don't want ARIN proactively going after legacy > registrants looking for reasons to separate them from their IP addresses. I don't either, provided the legitimate registrants at least make a reasonable claim of still using them. OTOH, I /do/ want ARIN to go after "abandoned" address blocks, nearly all of which are legacy for obvious reasons. > I could get behind a softened proposal compelling ARIN to act on > externally reported and well documented lists such as > http://www.spamhaus.org/drop/drop.lasso with an expectation that > hijack + inability to reach a registrant who asserts legitimacy with a > reasonable probability of truth = revocation. Such reports should go to the head of the queue, but there's enough abandoned or forgotten space out there, and some that would be returned if only someone were to ask nicely, that IMHO it's worth ARIN dedicating some ongoing resources to the task. > In other words: ARIN shouldn't go looking for trouble, but when > trouble lands on its doorstep it might be nice if they had better > policy tools to deal with it. What do you think needs to be added to/improved in NRPM 12 for this? I'll grant that it's pretty restrictive as it stands, but so far I haven't seen any complaints from ARIN staff that they can't do what they need to do. S -- Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3646 bytes Desc: S/MIME Cryptographic Signature URL: From mysidia at gmail.com Mon May 2 00:51:13 2011 From: mysidia at gmail.com (Jimmy Hess) Date: Sun, 1 May 2011 23:51:13 -0500 Subject: [arin-ppml] Accusation of fundamental conflict of interest/IPaddress policy pitched directly to ICANN In-Reply-To: <274D7568A828485B91D64F9308B3A24E@video> References: <4DBB208B.4060808@ipinc.net> <112FF1070FFF4B7E957E13C757CCB513@video> <23B533DB44354E3EA201D0941C47C46C@video> <861B310C-7502-49FE-BD13-3D1B123A57EB@delong.com> <274D7568A828485B91D64F9308B3A24E@video> Message-ID: On Sat, Apr 30, 2011 at 3:48 PM, Mike Burns wrote: > I think you misconstrue the relationship and have the tail wagging the dog. > ICANN/IANA is the entity that delegated the roles you describe, the NRO and No... it's not the tail wagging the dog; you have two separate dogs. The RIR dog, and the ICANN dog; each dog has its own different jobs. Neither dog is master of the other. One dog is the seeing-eye dog, the other dog is the drug sniffing dog. The proposal to the ICANN dog is asking the drug-sniffing dog to lead the blind. > All I am saying is that although this is not a new "regional" registry, it > is a registry which could compete with the RIRs, and why not have IANA > decide, since the representatives of the RIRs may have a vested interest in > "regional-only" self-preservation which would affect their votes? The IANA function maintains the list of number resources assigned. In the case of IP addresses and AS numbers, which RIR IP addresses and AS numbers are assigned to. At this point, it would be a bit pointless to for any new registry to apply, as responsibility for the entire IPv4 address space has already been granted to RIR organizations, the assignments are not revokable, the RIRs currently do not provide any way to release or transfer resources between RIRs, and no entity other than RIRs can enable transfers of resources between registries. A new additional registry could receive IPv6 space and AS numbers, however. If anyone wanted to make a new registry, of this nature, it would be in their interest to work with the community, and the RIRs, first. The spurious, frivolous "conflict of interest" claims to attempt to hold the discussion outside the normal community venues for IP addressing policy discussion, are obviously an attempt to end-run around things like rational discussion of proposals by the proper community, and comment by RIRs the IP address space was given to. The bottom up policy process, would indicate a proposal like this goes to the community first. If the communities accept the proposal, but the RIR boards don't go along with this, they abandon the proposal despite proven support, _then_ the author might have a case to seek out other (unusual) venues. But by sending some letter to ICANN, things are made to look as an attempt to sneak something in / slip something by the community. > I have nothing against the RIRs being heard and their case presented, but if > their decision is dispositive, it appears as if the fox is guarding the > henhouse. No, a horde of hens are guarding the henhouse. If the entire RIR community is being characterized a 'fox'; that is really quite strange. -- -JH From jcurran at arin.net Mon May 2 04:26:19 2011 From: jcurran at arin.net (John Curran) Date: Mon, 2 May 2011 08:26:19 +0000 Subject: [arin-ppml] Officer attestations for requests In-Reply-To: References: <39209.1303885464@tristatelogic.com> <75822E125BCB994F8446858C4B19F0D7173057C827@SUEX07-MBX-04.ad.syr.edu> <91860AD2-F0CB-42F3-9974-E280A9B1F690@arin.net> <20110427195407.GB88483@ussenterprise.ufp.org> <5874CCF0-0862-4BBC-ADEC-AEE5B229170B@arin.net> <4DB9BCC7.9080505@ipinc.net> Message-ID: On May 1, 2011, at 9:14 PM, Chris Grundemann wrote: > My understanding is that all requests for IPv4 space from ARIN > (allocation and assignment) currently require officer attestation in > order to be accepted by ARIN. Two questions: > > 1) Is that understanding correct? Yes. > 2) Is officer attestation also required for all transfer > justifications/requests? Yes (although 8.2 transfers are often based on corporate transaction documentation which is already sufficient - when it is not, we ask for officer attestation as well) FYI, /John John Curran President and CEO ARIN From mike at nationwideinc.com Mon May 2 09:27:38 2011 From: mike at nationwideinc.com (Mike Burns) Date: Mon, 2 May 2011 09:27:38 -0400 Subject: [arin-ppml] Accusation of fundamental conflict of interest/IPaddress policy pitched directly to ICANN References: <4DBB208B.4060808@ipinc.net><112FF1070FFF4B7E957E13C757CCB513@video><23B533DB44354E3EA201D0941C47C46C@video><861B310C-7502-49FE-BD13-3D1B123A57EB@delong.com><274D7568A828485B91D64F9308B3A24E@video> Message-ID: The authority flows down from the US Dept of Commerce. It doesn't go from there to the RIRs and back up to ICANN. ICANN>>RIRs I don't have any problems with the RIRs being heard from, just with them deciding. As for the IPV4 address space, the presumption is that addresses could be transferred to a new registry with a whois pointer to that new registry. So even though it is all allocated currently, inter-RIR transfer is coming via the Global Transfer Policy, and that mechanism could be used to populate a new registry. By address holders voluntarily choosing their registry provider in the way domain name holders can choose their provider. So in the sense that the RIRs will be trying to protect their monopoly markets, they are the fox. And the network operators and address holders will be the real deciders of registry competence. Regards, Mike ----- Original Message ----- From: "Jimmy Hess" To: "Mike Burns" Cc: "Owen DeLong" ; "John Curran" ; Sent: Monday, May 02, 2011 12:51 AM Subject: Re: [arin-ppml] Accusation of fundamental conflict of interest/IPaddress policy pitched directly to ICANN > On Sat, Apr 30, 2011 at 3:48 PM, Mike Burns > wrote: >> I think you misconstrue the relationship and have the tail wagging the >> dog. >> ICANN/IANA is the entity that delegated the roles you describe, the NRO >> and > No... it's not the tail wagging the dog; you have two separate dogs. > > The RIR dog, and the ICANN dog; each dog has its own different jobs. > Neither dog is master of the other. > > One dog is the seeing-eye dog, the other dog is the drug sniffing dog. > The proposal to the ICANN dog is asking the drug-sniffing dog to lead the > blind. > >> All I am saying is that although this is not a new "regional" registry, >> it >> is a registry which could compete with the RIRs, and why not have IANA >> decide, since the representatives of the RIRs may have a vested interest >> in >> "regional-only" self-preservation which would affect their votes? > > The IANA function maintains the list of number resources assigned. > In the case of IP addresses and AS numbers, which RIR IP addresses > and AS numbers are assigned to. > > At this point, it would be a bit pointless to for any new registry to > apply, as > responsibility for the entire IPv4 address space has already been granted > to RIR organizations, the assignments are not revokable, the RIRs > currently > do not provide any way to release or transfer resources between RIRs, > and no entity other than RIRs can enable transfers of resources between > registries. > > A new additional registry could receive IPv6 space and AS numbers, > however. > > > If anyone wanted to make a new registry, of this nature, it would be in > their > interest to work with the community, and the RIRs, first. > > The spurious, frivolous "conflict of interest" claims to attempt to > hold > the discussion outside the normal community venues for IP addressing > policy > discussion, are obviously an attempt to end-run around things like > rational > discussion of proposals by the proper community, and comment by RIRs > the IP address space was given to. > > > The bottom up policy process, would indicate a proposal like this goes > to the community first. > > If the communities accept the proposal, but the RIR boards don't go > along with this, > they abandon the proposal despite proven support, > > > _then_ the author might have a case to seek out other (unusual) venues. > But by sending some letter to ICANN, things are made to look as an > attempt > to sneak something in / slip something by the community. > > >> I have nothing against the RIRs being heard and their case presented, but >> if >> their decision is dispositive, it appears as if the fox is guarding the >> henhouse. > > No, a horde of hens are guarding the henhouse. > If the entire RIR community is being characterized a 'fox'; that is > really quite strange. > > -- > -JH From Wesley.E.George at sprint.com Mon May 2 10:10:56 2011 From: Wesley.E.George at sprint.com (George, Wes E [NTK]) Date: Mon, 2 May 2011 14:10:56 +0000 Subject: [arin-ppml] Staff proposing policy. In-Reply-To: References: <20110428152211.GA42655@ussenterprise.ufp.org> <20110428181008.GB49764@ussenterprise.ufp.org> <-7803719968472541934@unknownmsgid> <0FA8C03B-4A04-4823-AD34-B38170902614@arin.net> <4DBA513F.2060608@sprunk.org> Message-ID: <54E900DC635DAB4DB7A6D799B3C4CD8E10C8D062@PDAWM12B.ad.sprint.com> -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Chris Grundemann Sent: Saturday, April 30, 2011 3:05 PM To: Stephen Sprunk Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] Staff proposing policy. On Thu, Apr 28, 2011 at 23:48, Stephen Sprunk wrote: > IMHO, staff should be free to ask the community (via PPML or any other > appropriate means) about our intent and goals, but I'm not comfortable > with staff telling us what our intent or goals should be. > [WEG] +1 > Staff should also be free to point out when current or proposed policy > does not appear to meet our intent or goals, as discovered above, or > hard facts that are relevant to ongoing discussions.? And, when one > points out a problem, it's polite to also offer one or more possible solutions. Is everyone aware that staff performs and publishes an assessment of all policy proposals that make it onto the AC's docket? These assessments often include potential problems with the text, questions regarding intent, and sometimes even suggestions for making the text more clear / less likely to be misunderstood. ____________________ [WEG] yes, but as this is only regarding existing proposed policy, this still creates a potential gap. Staff's review of policy implemented at each meeting is mainly focused on new policies (either pending or recently implemented). I think that there are times when existing policy (or lack of a policy to provide guidance) would be important to highlight, instead of simply focusing on reviewing the last round of passed policy and the pending policy work. That said, this may be more effective as an update to the existing method of providing feedback rather than formalizing the ability for staff to propose policy. Wes George -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 6753 bytes Desc: not available URL: From cgrundemann at gmail.com Mon May 2 10:21:06 2011 From: cgrundemann at gmail.com (Chris Grundemann) Date: Mon, 2 May 2011 08:21:06 -0600 Subject: [arin-ppml] Accusation of fundamental conflict of interest/IPaddress policy pitched directly to ICANN In-Reply-To: References: <4DBB208B.4060808@ipinc.net> <112FF1070FFF4B7E957E13C757CCB513@video> <23B533DB44354E3EA201D0941C47C46C@video> <861B310C-7502-49FE-BD13-3D1B123A57EB@delong.com> <274D7568A828485B91D64F9308B3A24E@video> Message-ID: On Mon, May 2, 2011 at 07:27, Mike Burns wrote: > I don't have any problems with the RIRs being heard from, just with them > deciding. > So in the sense that the RIRs will be trying to protect their monopoly > markets, they are the fox. I am a bit confused by your use of "the RIRs" here. If you are referring to RIR staff (the RIR as an organization); they are already kept out of policy decision making and have no real way to "protect their monopoly markets" through the current, long-standing, global policy process because it is _the community_ (read: everyone who cares enough to speak up) who gets to make those decisions, not the staff. > And the network operators and address ?holders will be the real deciders of > registry competence. Exactly what this forum is for - changing the registry (through policy) to match the community's definition of competence. I highly encourage those who would like to see changes to post their ideas here, for discussion and consideration. Cheers, ~Chris > Regards, > > Mike -- @ChrisGrundemann weblog.chrisgrundemann.com www.burningwiththebush.com www.theIPv6experts.net www.coisoc.org From Keith at jcc.com Mon May 2 10:48:01 2011 From: Keith at jcc.com (Keith W. Hare) Date: Mon, 2 May 2011 10:48:01 -0400 Subject: [arin-ppml] Accusation of fundamental conflict of interest/IPaddress policy pitched directly to ICANN In-Reply-To: References: <4DBB208B.4060808@ipinc.net><112FF1070FFF4B7E957E13C757CCB513@video><23B533DB44354E3EA201D0941C47C46C@video><861B310C-7502-49FE-BD13-3D1B123A57EB@delong.com><274D7568A828485B91D64F9308B3A24E@video> Message-ID: <9737f78a74367c4fde16e526d31442304dbec379@jcc.com> As a legacy resource holder, my company benefits from a reasonably stable internet. So far, I have only seen bits of the changes that people seem to have in mind to allow for alternative address registries. I have not seen a complete enough proposal to evaluate what effect such a proposal will have on internet stability. With ARIN, I can influence policies as much as someone who works for a company that is assigned (or allocated) a couple of /8s. My influence on policy comes from my ability to write a coherent argument, not from how much money my company spends. I don't see how I will have any ability to influence a for-profit address registry. If ARIN is a monopoly, it is a benevolent monopoly that is protecting my interests. To convince me to support fragmentation of address registries, I will have to be convinced that such a fragmentation will protect my interests and give me at least the same influence as I have today. Keith Hare -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Mike Burns Sent: Monday, May 02, 2011 9:28 AM To: Jimmy Hess Cc: John Curran; arin-ppml at arin.net Subject: Re: [arin-ppml] Accusation of fundamental conflict of interest/IPaddress policy pitched directly to ICANN The authority flows down from the US Dept of Commerce. It doesn't go from there to the RIRs and back up to ICANN. ICANN>>RIRs I don't have any problems with the RIRs being heard from, just with them deciding. As for the IPV4 address space, the presumption is that addresses could be transferred to a new registry with a whois pointer to that new registry. So even though it is all allocated currently, inter-RIR transfer is coming via the Global Transfer Policy, and that mechanism could be used to populate a new registry. By address holders voluntarily choosing their registry provider in the way domain name holders can choose their provider. So in the sense that the RIRs will be trying to protect their monopoly markets, they are the fox. And the network operators and address holders will be the real deciders of registry competence. Regards, Mike ----- Original Message ----- From: "Jimmy Hess" To: "Mike Burns" Cc: "Owen DeLong" ; "John Curran" ; Sent: Monday, May 02, 2011 12:51 AM Subject: Re: [arin-ppml] Accusation of fundamental conflict of interest/IPaddress policy pitched directly to ICANN > On Sat, Apr 30, 2011 at 3:48 PM, Mike Burns > wrote: >> I think you misconstrue the relationship and have the tail wagging the >> dog. >> ICANN/IANA is the entity that delegated the roles you describe, the NRO >> and > No... it's not the tail wagging the dog; you have two separate dogs. > > The RIR dog, and the ICANN dog; each dog has its own different jobs. > Neither dog is master of the other. > > One dog is the seeing-eye dog, the other dog is the drug sniffing dog. > The proposal to the ICANN dog is asking the drug-sniffing dog to lead the > blind. > >> All I am saying is that although this is not a new "regional" registry, >> it >> is a registry which could compete with the RIRs, and why not have IANA >> decide, since the representatives of the RIRs may have a vested interest >> in >> "regional-only" self-preservation which would affect their votes? > > The IANA function maintains the list of number resources assigned. > In the case of IP addresses and AS numbers, which RIR IP addresses > and AS numbers are assigned to. > > At this point, it would be a bit pointless to for any new registry to > apply, as > responsibility for the entire IPv4 address space has already been granted > to RIR organizations, the assignments are not revokable, the RIRs > currently > do not provide any way to release or transfer resources between RIRs, > and no entity other than RIRs can enable transfers of resources between > registries. > > A new additional registry could receive IPv6 space and AS numbers, > however. > > > If anyone wanted to make a new registry, of this nature, it would be in > their > interest to work with the community, and the RIRs, first. > > The spurious, frivolous "conflict of interest" claims to attempt to > hold > the discussion outside the normal community venues for IP addressing > policy > discussion, are obviously an attempt to end-run around things like > rational > discussion of proposals by the proper community, and comment by RIRs > the IP address space was given to. > > > The bottom up policy process, would indicate a proposal like this goes > to the community first. > > If the communities accept the proposal, but the RIR boards don't go > along with this, > they abandon the proposal despite proven support, > > > _then_ the author might have a case to seek out other (unusual) venues. > But by sending some letter to ICANN, things are made to look as an > attempt > to sneak something in / slip something by the community. > > >> I have nothing against the RIRs being heard and their case presented, but >> if >> their decision is dispositive, it appears as if the fox is guarding the >> henhouse. > > No, a horde of hens are guarding the henhouse. > If the entire RIR community is being characterized a 'fox'; that is > really quite strange. > > -- > -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 mike at nationwideinc.com Mon May 2 11:14:09 2011 From: mike at nationwideinc.com (Mike Burns) Date: Mon, 2 May 2011 11:14:09 -0400 Subject: [arin-ppml] Accusation of fundamental conflict ofinterest/IPaddress policy pitched directly to ICANN References: <4DBB208B.4060808@ipinc.net><112FF1070FFF4B7E957E13C757CCB513@vid eo><23B533DB44354E3EA201D0941C47C46C@video><861B310C-7502-49FE-BD13-3D1B123A57EB @delong.com><274D7568A828485B91D64F9308B3A24E@video> <9737f78a74367c4fde16e526d31442304dbec379@jcc.com> Message-ID: Hi Keith, I'm pretty sure that everybody, legacy and non-legacy, also benefits from a stable internet. It will be the decision of the voluntary participants in the market which will influence control over a new registry, and presumably the owners of the registry. The address holders like yourself, and the network operators who will chose, or not chose, to utilize the services of the new registry to provide authoritative routing authority. One of the changes proposed is to allow for legacy address holders like yourself, to move registry services to a new commercial registry, with ARIN including a pointer to that new registry in whois. The new registry will have it's own transfer policies, for example, and may be stricter or less strict than existing RIRs, which already differ in transfer policies. It may have a stricter chain-of-custody analysis than existing registries do. It may have a team of lawyers reviewing things to ensure that those registered are the actual holders of the rights to those addresses. It may have an insurance component to provide title insurance to account holders. It may be recognized by network operators as a reliable source for routing authority, or it may not. I presume that this will be based on the registry's performance in establishing the legitmacy of address holders' rights, and the ease with which network operators can access the data. If I was a network operator, and I could choose from a registry that offered a service like address dispute resolution or title insurance, I might consider utilizing that registry to establish routing authority. The registry will stand or fall based on its performance in a competitive environment. The idea is similar to the concept of school vouchers. With school vouchers, you can take your child out of public school, and put him in private school. The public schools lose some money as the vouchers are created, just as ARIN may lose some registration fee revenue. The concept is that competitive pressures will be applied to the public resources which will increase the efficiency of the public schools, or in our case, the efficiency of the regional-monopoly-registry. This concept was expressed by the opt-out proposal Benson proposed earlier, and perhaps it was not fully understood. Benson's proposal would have been the ground-up policy development which would have naturally led to the creation of alternate registries. Since that proposal failed, I have no problems with John Curran representing that the ARIN community does not support the proposal to allow competing registries as ARIN's Executive Council member on the NRO. But I feel the decision, informed by input from the RIRs through the NRO, should be made by the level above the RIRs and below US Dept. of Commerce. Regards, Mike ----- Original Message ----- From: "Keith W. Hare" To: ; "Mike Burns" Cc: "John Curran" ; "Jimmy Hess" Sent: Monday, May 02, 2011 10:48 AM Subject: RE: [arin-ppml] Accusation of fundamental conflict ofinterest/IPaddress policy pitched directly to ICANN As a legacy resource holder, my company benefits from a reasonably stable internet. So far, I have only seen bits of the changes that people seem to have in mind to allow for alternative address registries. I have not seen a complete enough proposal to evaluate what effect such a proposal will have on internet stability. With ARIN, I can influence policies as much as someone who works for a company that is assigned (or allocated) a couple of /8s. My influence on policy comes from my ability to write a coherent argument, not from how much money my company spends. I don't see how I will have any ability to influence a for-profit address registry. If ARIN is a monopoly, it is a benevolent monopoly that is protecting my interests. To convince me to support fragmentation of address registries, I will have to be convinced that such a fragmentation will protect my interests and give me at least the same influence as I have today. Keith Hare -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Mike Burns Sent: Monday, May 02, 2011 9:28 AM To: Jimmy Hess Cc: John Curran; arin-ppml at arin.net Subject: Re: [arin-ppml] Accusation of fundamental conflict of interest/IPaddress policy pitched directly to ICANN The authority flows down from the US Dept of Commerce. It doesn't go from there to the RIRs and back up to ICANN. ICANN>>RIRs I don't have any problems with the RIRs being heard from, just with them deciding. As for the IPV4 address space, the presumption is that addresses could be transferred to a new registry with a whois pointer to that new registry. So even though it is all allocated currently, inter-RIR transfer is coming via the Global Transfer Policy, and that mechanism could be used to populate a new registry. By address holders voluntarily choosing their registry provider in the way domain name holders can choose their provider. So in the sense that the RIRs will be trying to protect their monopoly markets, they are the fox. And the network operators and address holders will be the real deciders of registry competence. Regards, Mike ----- Original Message ----- From: "Jimmy Hess" To: "Mike Burns" Cc: "Owen DeLong" ; "John Curran" ; Sent: Monday, May 02, 2011 12:51 AM Subject: Re: [arin-ppml] Accusation of fundamental conflict of interest/IPaddress policy pitched directly to ICANN > On Sat, Apr 30, 2011 at 3:48 PM, Mike Burns > wrote: >> I think you misconstrue the relationship and have the tail wagging the >> dog. >> ICANN/IANA is the entity that delegated the roles you describe, the NRO >> and > No... it's not the tail wagging the dog; you have two separate dogs. > > The RIR dog, and the ICANN dog; each dog has its own different jobs. > Neither dog is master of the other. > > One dog is the seeing-eye dog, the other dog is the drug sniffing dog. > The proposal to the ICANN dog is asking the drug-sniffing dog to lead the > blind. > >> All I am saying is that although this is not a new "regional" registry, >> it >> is a registry which could compete with the RIRs, and why not have IANA >> decide, since the representatives of the RIRs may have a vested interest >> in >> "regional-only" self-preservation which would affect their votes? > > The IANA function maintains the list of number resources assigned. > In the case of IP addresses and AS numbers, which RIR IP addresses > and AS numbers are assigned to. > > At this point, it would be a bit pointless to for any new registry to > apply, as > responsibility for the entire IPv4 address space has already been granted > to RIR organizations, the assignments are not revokable, the RIRs > currently > do not provide any way to release or transfer resources between RIRs, > and no entity other than RIRs can enable transfers of resources between > registries. > > A new additional registry could receive IPv6 space and AS numbers, > however. > > > If anyone wanted to make a new registry, of this nature, it would be in > their > interest to work with the community, and the RIRs, first. > > The spurious, frivolous "conflict of interest" claims to attempt to > hold > the discussion outside the normal community venues for IP addressing > policy > discussion, are obviously an attempt to end-run around things like > rational > discussion of proposals by the proper community, and comment by RIRs > the IP address space was given to. > > > The bottom up policy process, would indicate a proposal like this goes > to the community first. > > If the communities accept the proposal, but the RIR boards don't go > along with this, > they abandon the proposal despite proven support, > > > _then_ the author might have a case to seek out other (unusual) venues. > But by sending some letter to ICANN, things are made to look as an > attempt > to sneak something in / slip something by the community. > > >> I have nothing against the RIRs being heard and their case presented, but >> if >> their decision is dispositive, it appears as if the fox is guarding the >> henhouse. > > No, a horde of hens are guarding the henhouse. > If the entire RIR community is being characterized a 'fox'; that is > really quite strange. > > -- > -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 jcurran at arin.net Mon May 2 11:32:59 2011 From: jcurran at arin.net (John Curran) Date: Mon, 2 May 2011 15:32:59 +0000 Subject: [arin-ppml] Accusation of fundamental conflict of interest / IP address policy pitched directly to ICANN In-Reply-To: References: <4DBB208B.4060808@ipinc.net> <112FF1070FFF4B7E957E13C757CCB513@vid> <23B533DB44354E3EA201D0941C47C46C@video> <861B310C-7502-49FE-BD13-3D1B123A57EB@delong.com> <274D7568A828485B91D64F9308B3A24E@video> <"D4AAEAB3B4384217B478E3 9F9591D3EC"@mike> <9737f78a74367c4fde16e526d31442304dbec379@jcc.com> Message-ID: <5999842A-528A-42D3-8560-DC0F5279EB54@arin.net> On May 2, 2011, at 5:14 PM, Mike Burns wrote: > The new registry will have it's own transfer policies, for example, and may be stricter or less strict than existing RIRs, which already differ in transfer policies. Mike - Could you elaborate? If the structure of the Internet's number registry system were to evolve in some manner to accommodate new customer-facing "registries, wouldn't it be expected that such registries would operated according to overall global policies? (just as occurs in the DNS registry/registrar system today?) Thanks! /John John Curran President and CEO ARIN From mike at nationwideinc.com Mon May 2 11:39:43 2011 From: mike at nationwideinc.com (Mike Burns) Date: Mon, 2 May 2011 11:39:43 -0400 Subject: [arin-ppml] Accusation of fundamental conflict of interest / IPaddress policy pitched directly to ICANN References: <4DBB208B.4060808@ipinc.net> <112FF1070FFF4B7E957E13C757CCB513@vid> <23B533DB44354E3EA201D0941C47C46C@video><861B310C-7502-49FE-BD13-3D1B123A57EB@de long.com><274D7568A828485B91D64F9308B3A24E@video><"D4AAEAB3B4384217B478E3 9F9591D3EC"@mike><9737f78a74367c4fde16e526d31442304dbec379@jcc.com> <5999842A-528A-42D3-8560-DC0F5279EB54@arin.net> Message-ID: <928CFB54658D4E4181D94E46F6F076B9@mike> I would expect that the policies all new registries must follow will be established by IANA. And as such, they would be global policies. But just as existing global policies allow RIRs to have different transfer policies, all registries would be subject to IANA global policies. Isn't there already policy somewhere which details global requirements for RIRs, within which they can have policy difference? ----- Original Message ----- From: "John Curran" To: "Mike Burns" Cc: "Keith W. Hare" ; Sent: Monday, May 02, 2011 11:32 AM Subject: Re: [arin-ppml] Accusation of fundamental conflict of interest / IPaddress policy pitched directly to ICANN On May 2, 2011, at 5:14 PM, Mike Burns wrote: > The new registry will have it's own transfer policies, for example, and > may be stricter or less strict than existing RIRs, which already differ in > transfer policies. Mike - Could you elaborate? If the structure of the Internet's number registry system were to evolve in some manner to accommodate new customer-facing "registries, wouldn't it be expected that such registries would operated according to overall global policies? (just as occurs in the DNS registry/registrar system today?) Thanks! /John John Curran President and CEO ARIN From Keith at jcc.com Mon May 2 12:08:10 2011 From: Keith at jcc.com (Keith W. Hare) Date: Mon, 2 May 2011 12:08:10 -0400 Subject: [arin-ppml] Accusation of fundamental conflict ofinterest/IPaddress policy pitched directly to ICANN In-Reply-To: References: <4DBB208B.4060808@ipinc.net><112FF1070FFF4B7E957E13C757CCB513@vid eo><23B533DB44354E3EA201D0941C47C46C@video><861B310C-7502-49FE-BD13-3D1B123A57EB @delong.com><274D7568A828485B91D64F9308B3A24E@video> <9737f78a74367c4fde16e526d31442304dbec379@jcc.com> Message-ID: <40d2346a1b58436fb0387d165b0c7bee4dbed641@jcc.com> Mike, You wrote: The registry will stand or fall based on its performance in a competitive environment. The idea is similar to the concept of school vouchers. With school vouchers, you can take your child out of public school, and put him in private school. The public schools lose some money as the vouchers are created, just as ARIN may lose some registration fee revenue. The concept is that competitive pressures will be applied to the public resources which will increase the efficiency of the public schools, or in our case, the efficiency of the regional-monopoly-registry. As it happens, I've spent some amount of time looking at school funding in the rural Ohio school district where I live. My observations on the concepts of school vouchers and competition as a driver of school efficiency are: 1. While school vouchers may provide some benefit in urban areas with large student populations, they are of no benefit in rural areas. 2. At least in Ohio, school voucher programs have cost funding for rural school districts while providing no benefit to rural students. 3. The issues in public school districts are mostly not related to efficiency. So maybe your analogy is valid. >From my point of view, ARIN is operating very efficiently. I do not see how getting lawyers and "title" insurance involved is going to be more efficient -- any time I have to deal with a lawyer it costs me time and money. Keith Hare From mike at nationwideinc.com Mon May 2 12:13:29 2011 From: mike at nationwideinc.com (Mike Burns) Date: Mon, 2 May 2011 12:13:29 -0400 Subject: [arin-ppml] Accusation of fundamental conflict ofinterest/IPaddress policy pitched directly to ICANN References: <4DBB208B.4060808@ipinc.net><112FF1070FFF4B7E957E13C757CCB513@vid eo><23B533DB44354E3EA201D0941C47C46C@video><861B310C-7502-49FE-BD13-3D1B123A57EB @delong.com><274D7568A828485B91D64F9308B3A24E@video> <9737f78a74367c4fde16e526d31442304dbec379@jcc.com> <40d2346a1b58436fb0387d165b0c7bee4dbed64a@jcc.com> Message-ID: <34A035C8AB3147919076CC4BB118C83B@mike> I understand and appreciate that ARIN has faithfully fulfilled its stewardship role, and I am in the camp of don't fix what ain't broke. But times are changing, these issues are upon us because the promise of gradual transition has failed and the problem of exhaust has arrived. Some might say that public education has failed, and vouchers are a result of that failure, but that can be debated. What can't be debated is that the IPv6 transition has failed to proceed gracefully, and conflict over valuable resources are bound to occur. This issue seems to elicit analogies, and the analogies can take on a life and argument of their own, so I shall try to refrain from them in the future. Regards, Mike ----- Original Message ----- From: "Keith W. Hare" To: ; "Mike Burns" Sent: Monday, May 02, 2011 12:08 PM Subject: RE: [arin-ppml] Accusation of fundamental conflict ofinterest/IPaddress policy pitched directly to ICANN Mike, You wrote: The registry will stand or fall based on its performance in a competitive environment. The idea is similar to the concept of school vouchers. With school vouchers, you can take your child out of public school, and put him in private school. The public schools lose some money as the vouchers are created, just as ARIN may lose some registration fee revenue. The concept is that competitive pressures will be applied to the public resources which will increase the efficiency of the public schools, or in our case, the efficiency of the regional-monopoly-registry. As it happens, I've spent some amount of time looking at school funding in the rural Ohio school district where I live. My observations on the concepts of school vouchers and competition as a driver of school efficiency are: 1. While school vouchers may provide some benefit in urban areas with large student populations, they are of no benefit in rural areas. 2. At least in Ohio, school voucher programs have cost funding for rural school districts while providing no benefit to rural students. 3. The issues in public school districts are mostly not related to efficiency. So maybe your analogy is valid. >From my point of view, ARIN is operating very efficiently. I do not see how getting lawyers and "title" insurance involved is going to be more efficient -- any time I have to deal with a lawyer it costs me time and money. Keith Hare From dogwallah at gmail.com Mon May 2 12:22:56 2011 From: dogwallah at gmail.com (McTim) Date: Mon, 2 May 2011 19:22:56 +0300 Subject: [arin-ppml] Accusation of fundamental conflict ofinterest/IPaddress policy pitched directly to ICANN In-Reply-To: References: <4DBB208B.4060808@ipinc.net> <23B533DB44354E3EA201D0941C47C46C@video> <274D7568A828485B91D64F9308B3A24E@video> <9737f78a74367c4fde16e526d31442304dbec379@jcc.com> Message-ID: On Mon, May 2, 2011 at 6:14 PM, Mike Burns wrote: > Hi Keith, > But I feel the decision, informed by input from the RIRs through the NRO, > should be made by the level above the RIRs and below US Dept. of Commerce. Can you be more specific? The ICANN ASO? the ICANN BoT? the IANA? -- Cheers, McTim "A name indicates what we seek. An address indicates where it is. A route indicates how we get there."? Jon Postel From dogwallah at gmail.com Mon May 2 12:24:20 2011 From: dogwallah at gmail.com (McTim) Date: Mon, 2 May 2011 19:24:20 +0300 Subject: [arin-ppml] Accusation of fundamental conflict ofinterest/IPaddress policy pitched directly to ICANN In-Reply-To: <34A035C8AB3147919076CC4BB118C83B@mike> References: <4DBB208B.4060808@ipinc.net> <23B533DB44354E3EA201D0941C47C46C@video> <274D7568A828485B91D64F9308B3A24E@video> <9737f78a74367c4fde16e526d31442304dbec379@jcc.com> <40d2346a1b58436fb0387d165b0c7bee4dbed64a@jcc.com> <34A035C8AB3147919076CC4BB118C83B@mike> Message-ID: On Mon, May 2, 2011 at 7:13 PM, Mike Burns wrote: > I understand and appreciate that ARIN has faithfully fulfilled its > stewardship role, and I am in the camp of don't fix what ain't broke. > > But times are changing, these issues are upon us because the promise of > gradual transition has failed and the problem of exhaust has arrived. or are these issues upon us because some folk want to make money? -- Cheers, McTim "A name indicates what we seek. An address indicates where it is. A route indicates how we get there."? Jon Postel From ANadarajah at primustel.ca Mon May 2 12:41:46 2011 From: ANadarajah at primustel.ca (Ahim Nadarajah) Date: Mon, 2 May 2011 12:41:46 -0400 Subject: [arin-ppml] ARIN-2011-5: Shared Transition Space for IPv4 Address Extension - Last Call Message-ID: I support this proposal. Ahim Nadarajah -------------------------------------------------------------------------- ?This electronic message contains information from Primus Telecommunications Canada Inc. ("PRIMUS") , which may be legally privileged and confidential. The information is intended to be for the use of the individual(s) or entity named above. If you are not the intended recipient, be aware that any disclosure, copying, distribution or use of the contents of this information is prohibited. If you have received this electronic message in error, please notify us by telephone or e-mail (to the number or address above) immediately. Any views, opinions or advice expressed in this electronic message are not necessarily the views, opinions or advice of PRIMUS. It is the responsibility of the recipient to ensure that any attachments are virus free and PRIMUS bears no responsibility for any loss or damage arising in any way from the use thereof.The term "PRIMUS" includes its affiliates. -------------------------------------------------------------------------- ?Pour la version en fran?ais de ce message, veuillez voir http://www.primustel.ca/fr/legal/cs.htm -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike at nationwideinc.com Mon May 2 12:45:48 2011 From: mike at nationwideinc.com (Mike Burns) Date: Mon, 2 May 2011 12:45:48 -0400 Subject: [arin-ppml] Accusation of fundamental conflict ofinterest/IPaddress policy pitched directly to ICANN References: <4DBB208B.4060808@ipinc.net> <23B533DB44354E3EA201D0941C47C46C@video> <274D7568A828485B91D64F9308B3A24E@video> <9737f78a74367c4fde16e526d31442304dbec379@jcc.com> <40d2346a1b58436fb0387d165b0c7bee4dbed64a@jcc.com> <34A035C8AB3147919076CC4BB118C83B@mike> Message-ID: On Mon, May 2, 2011 at 7:13 PM, Mike Burns wrote: > I understand and appreciate that ARIN has faithfully fulfilled its > stewardship role, and I am in the camp of don't fix what ain't broke. > > But times are changing, these issues are upon us because the promise of > gradual transition has failed and the problem of exhaust has arrived. >or are these issues upon us because some folk want to make money? >-Mc Tim If the transition had happened, these issues would be moot. As the transition has not happened, these issues result from elementary economic principles which are ignored at our peril. Who, excepting spammers and the like, would argue or commit fraud over the control of IP addresses in an age where they are free? When they are not free, things change fundamentally. Recognizing that people want to make money is a very good start when appreciating the realities of markets. That recognition can lead to effective mechanisms to establish trust. Such as having a neutral party like an insurer provide title insurance after reviewing claims of ownership. Regards, Mike From mike at nationwideinc.com Mon May 2 12:48:00 2011 From: mike at nationwideinc.com (Mike Burns) Date: Mon, 2 May 2011 12:48:00 -0400 Subject: [arin-ppml] Fw: Accusation of fundamental conflict ofinterest/IPaddress policy pitched directly to ICANN Message-ID: >Can you be more specific? The ICANN ASO? the ICANN BoT? the IANA? Hi Tim, Keep going, all the organizations above are suspect due to the fact that they are all comprised of the same basic group of RIR designees. I would take it to NTIA like DNS. And I would use DNS as a template for the creation of the global policy restrictions John Curran asked about, which restrictions would apply to all registries, regional or commercial. Just as all DNS registrars must meet certain qualifications, so would private registries of number space. Let the NTIA hear arguments from the proposer and from the ASO, the ICANN BoT, and IANA, although I suspect they will all sound the same. Regards, Mike ----- Original Message ----- From: "McTim" To: "Mike Burns" Cc: "Keith W. Hare" ; ; "John Curran" Sent: Monday, May 02, 2011 12:22 PM Subject: Re: [arin-ppml] Accusation of fundamental conflict ofinterest/IPaddress policy pitched directly to ICANN On Mon, May 2, 2011 at 6:14 PM, Mike Burns wrote: > Hi Keith, > But I feel the decision, informed by input from the RIRs through the NRO, > should be made by the level above the RIRs and below US Dept. of Commerce. Can you be more specific? The ICANN ASO? the ICANN BoT? the IANA? -- Cheers, McTim "A name indicates what we seek. An address indicates where it is. A route indicates how we get there." Jon Postel From William.C.Hale at windstream.com Mon May 2 13:07:16 2011 From: William.C.Hale at windstream.com (Hale, William C) Date: Mon, 2 May 2011 12:07:16 -0500 Subject: [arin-ppml] ARIN-2011-3: Better IPv6 Allocations for ISPs - Last Call In-Reply-To: <4DAC8B7F.2080303@arin.net> References: <4DAC8B7F.2080303@arin.net> Message-ID: <35780B35A0003743943EF86BA4D0B4171EA54F33@CWWAPP230.windstream.com> I support this draft policy. Regards, Bill ________________________________________ From: arin-ppml-bounces at arin.net [arin-ppml-bounces at arin.net] On Behalf Of ARIN [info at arin.net] Sent: Monday, April 18, 2011 2:05 PM To: arin-ppml at arin.net Subject: [arin-ppml] ARIN-2011-3: Better IPv6 Allocations for ISPs - Last Call The ARIN Advisory Council (AC) met on 13 April 2011 and decided to send a revised version of the following draft policy to last call: ARIN-2011-3: Better IPv6 Allocations for ISPs Changes include: 1. Does not delete section 2.9 (request from staff, no impact on policy meaning) 2. Limits LIR recursion to a single level and limit subordinate LIRs to /32. (community concern) 3. Restores PAU to the calculation in 6.5.2.1(c) (from errata slide presented in meeting) 4. Preserves 2010-12 language in new 6.5.3.1 (from errata slide presented in meeting) 5. Preserves verbiage allowing ISPs to allocate to their own internal infrastructure in 6.5.4.1 (from errata slide presented in meeting) 6. Adds a statement to delete current NRPM 6.9 (from errata slide presented in meeting) 7. Adds language to limit initial allocations to no more than a /16 (6.5.2.1(b)) and to limit subsequent allocations to no larger than a /12 (an organization may apply for additional /12s, but, no single allocation larger than a /12 can be made at one time) (6.5.2.1(e)) (community concern) Feedback is encouraged during the last call period. All comments should be provided to the Public Policy Mailing List. Last call for 2011-3 will expire on 2 May 2011. 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-2011-3 Better IPv6 Allocations for ISPs Version/Date: 18 April 2011 Policy Statement: Amend section 2 as follows: Replace section 2.10 with the following: 2.10 The term End Site shall mean a single structure or service delivery address, or, in the case of a multi-tenant structure, a single tenant within said structure (a single customer location). Add the following: 2.12 When applied to IPv6 policies, the term serving site shall mean a location where an ISP terminates or aggregates customer connections, including, but, not limited to Points of Presence (POPs), Datacenters, Central or Local switching office or regional or local combinations thereof. 2.13 When applied to IPv6 policies, the term "provider assignment unit" shall mean the prefix of the smallest block a given ISP assigns to end sites (recommended /48). 2.14 The term utilized shall have the following definitions when applied to IPv6 policies: (i) A provider assignment unit shall be considered fully utilized when it is assigned to an end-site. (ii) Larger blocks shall have their utilization defined by dividing the number of provider assignment units assigned from the containing block by the total number of provider assignment units. This ratio will often be expressed as a percentage (e.g. a/t*100, for a /36 3072/4096 * 100 = 75% utilization) Replace sections 6.5.1 through 6.5.3 with the following: 6.5.1 Terminology (a) The terms ISP and LIR are used interchangeably in this document and any use of either term shall be construed to include both meanings. (b) The term nibble boundary shall mean a network mask which aligns on a 4-bit boundary (in slash notation, /n, where n is evenly divisible by 4, allowing unit quantities of X such that 2^n=X where n is evenly divisible by 4, such as 16, 256, 4096, etc.) 6.5.2 Initial Allocations to LIRs 6.5.2.1 Size (a) All allocations shall be made on nibble boundaries. (b) In no case shall an LIR receive smaller than a /32 unless they specifically request a /36. In no case shall an ISP receive more than a /16 initial allocation. (c) The maximum allowable allocation shall be the smallest nibble-boundary aligned block that can provide an equally sized nibble-boundary aligned block to each of the requesters serving sites large enough to satisfy the needs of the requesters largest single serving site using no more than 75% of the available addresses. This calculation can be summarized as /N where N = P-(X+Y) and P is the organization's Provider Allocation Unit X is a multiple of 4 greater than 4/3*serving sites and Y is a multiple of 4 greater than 4/3*end sites served by largest serving site. (d) For purposes of the calculation in (c), an end site which can justify more than a /48 under the end-user assignment criteria in 6.5.8 shall count as the appropriate number of /48s that would be assigned under that policy. (e) For purposes of the calculation in (c), an LIR which has subordinate LIRs shall make such allocations according to the same policies and criteria as ARIN. In such a case, the prefixes necessary for such an allocation should be treated as fully utilized in determining the block sizing for the parent LIR. LIRs which do not receive resources directly from ARIN will not be able to make such allocations to subordinate LIRs and subordinate LIRs which need more than a /32 shall apply directly to ARIN. (f) An LIR is not required to design or deploy their network according to this structure. It is strictly a mechanism to determine the largest IP address block to which the LIR is entitled. 6.5.2.2 Qualifications An organization qualifies for an allocation under this policy if they meet any of the following criteria: (a) Have a previously justified IPv4 ISP allocation from ARIN or one of its predecessor registries or can qualify for an IPv4 ISP allocation under current criteria. (b) Are currently multihomed for IPv6 or will immediately become multihomed for IPv6 using a valid assigned global AS number. In either case, they will be making reassignments from allocation(s) under this policy to other organizations. (c) Provide ARIN a reasonable technical justification indicating why an allocation is necessary. Justification must include the intended purposes for the allocation and describe the network infrastructure the allocation will be used to support. Justification must also include a plan detailing anticipated assignments to other organizations or customers for one, two and five year periods, with a minimum of 50 assignments within 5 years. 6.5.3 Subsequent Allocations to LIRs (a) Where possible ARIN will make subsequent allocations by expanding the existing allocation. (b) An LIR which can show utilization of 75% or more of their total address space, or more than 90% of any serving site shall be entitled to a subsequent allocation. (c) If ARIN can not expand one or more existing allocations, ARIN shall make a new allocation based on the initial allocation criteria above. The LIR is encouraged, but not required to renumber into the new allocation over time and return any allocations no longer in use. (d) If an LIR has already reached a /12 or more, ARIN will allocate a single additional /12 rather than continue expanding nibble boundaries. Renumber/move the second paragraph of existing section 6.5.2.1 to 6.5.3.1. For reference, this would become: 6.5.3.1 Subsequent Allocations for Transition Subsequent allocations will also be considered for deployments that cannot be accommodated by, nor were accounted for, under the initial allocation. Justification for the subsequent subnet size will be based on the plan and technology provided with a /24 being the maximum allowed for a transition technology. Justification for transitional allocations will be reviewed every 3 years and reclaimed if they are no longer in use for transitional purposes. All such allocations for transitional technology will be made from a block designated for this purpose. (This paragraph comes from 2010-12 which was adopted after this draft policy was written). Replace section 6.5.4 with the following 6.5.4 Assignments to end users shall be governed by the same practices adopted by the community in section 6.5.8 except that the requirements in 6.5.8.1 do not apply. 6.5.4.1 An LIR may assign up to a /48 per PoP as well as up to an additional /48 globally for its own infrastructure. Add the following to 6.5.7 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 provided that they agree to renumber into that new allocation and return their prior allocation(s) within 5 years. If possible, ARIN will simply expand their existing allocation rather than requiring renumber and return. Delete section 6.9 _______________________________________________ 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 information contained in this message, including attachments, may contain privileged or confidential information that is intended to be delivered only to the person identified above. If you are not the intended recipient, or the person responsible for delivering this message to the intended recipient, Windstream requests that you immediately notify the sender and asks that you do not read the message or its attachments, and that you delete them without copying or sending them to anyone else. From William.C.Hale at windstream.com Mon May 2 13:09:16 2011 From: William.C.Hale at windstream.com (Hale, William C) Date: Mon, 2 May 2011 12:09:16 -0500 Subject: [arin-ppml] ARIN-2011-4: Reserved Pool for Critical Infrastructure - Last Call In-Reply-To: <4DAC8B90.5070104@arin.net> References: <4DAC8B90.5070104@arin.net> Message-ID: <35780B35A0003743943EF86BA4D0B4171EA54F34@CWWAPP230.windstream.com> I do not support this draft policy. Bill ________________________________________ From: arin-ppml-bounces at arin.net [arin-ppml-bounces at arin.net] On Behalf Of ARIN [info at arin.net] Sent: Monday, April 18, 2011 2:05 PM To: arin-ppml at arin.net Subject: [arin-ppml] ARIN-2011-4: Reserved Pool for Critical Infrastructure - Last Call The ARIN Advisory Council (AC) met on 13 April 2011 and decided to send a revised version of the following draft policy to last call: ARIN-2011-4: Reserved Pool for Critical Infrastructure Feedback is encouraged during the last call period. All comments should be provided to the Public Policy Mailing List. Last call for 2011-4 will expire on 2 May 2011. 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-2011-4 Reserved Pool for Critical Infrastructure Version/Date: 16 Feb 2011 Policy term: 36 Months following implementation Policy statement: ARIN will place an equivalent of a /16 of IPv4 address space in a reserve for Critical Infrastructure, as defined in section 4.4. If at the end of the policy term there is unused address space remaining in this pool, ARIN staff is authorized to utilize this space in a manner consistent with community expectations. Rationale: Section 4.10 of the NRPM is insufficient with respect to insuring the continued operation of critical infrastructure. This proposal, if adopted, will protect those resources with a reasonable amount of reserved v4 address space and prevent an overrun of CI needs by NRPM Section 4.10 or any successor. The intent is to separate CI needs and make a distinct pool available to insure the continuity of CI allocations per NRPM Section 4.4 for at least 36 months. 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. *************************************************************************************** The information contained in this message, including attachments, may contain privileged or confidential information that is intended to be delivered only to the person identified above. If you are not the intended recipient, or the person responsible for delivering this message to the intended recipient, Windstream requests that you immediately notify the sender and asks that you do not read the message or its attachments, and that you delete them without copying or sending them to anyone else. From William.C.Hale at windstream.com Mon May 2 13:09:48 2011 From: William.C.Hale at windstream.com (Hale, William C) Date: Mon, 2 May 2011 12:09:48 -0500 Subject: [arin-ppml] ARIN-2011-5: Shared Transition Space for IPv4 Address Extension - Last Call In-Reply-To: <4DAC8BCB.2000300@arin.net> References: <4DAC8BCB.2000300@arin.net> Message-ID: <35780B35A0003743943EF86BA4D0B4171EA54F35@CWWAPP230.windstream.com> I support this draft policy. Bill ________________________________________ From: arin-ppml-bounces at arin.net [arin-ppml-bounces at arin.net] On Behalf Of ARIN [info at arin.net] Sent: Monday, April 18, 2011 2:06 PM To: arin-ppml at arin.net Subject: [arin-ppml] ARIN-2011-5: Shared Transition Space for IPv4 Address Extension - Last Call The ARIN Advisory Council (AC) met on 13 April 2011 and decided to send the following draft policy to last call: ARIN-2011-5: Shared Transition Space for IPv4 Address Extension Feedback is encouraged during the last call period. All comments should be provided to the Public Policy Mailing List. Last call for 2011-5 will expire on 2 May 2011. 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-2011-5 Shared Transition Space for IPv4 Address Extension Date: 20 January 2011 Policy statement: Updates 4.10 of the NRPM: A second contiguous /10 IPv4 block will be reserved to facilitate IPv4 address extension. This block will not be allocated or assigned to any single organization, but is to be shared by Service Providers for internal use for IPv4 address extension deployments until connected networks fully support IPv6. Examples of such needs include: IPv4 addresses between home gateways and NAT444 translators. Rationale: The Internet community is rapidly consuming the remaining supply of unallocated IPv4 addresses. During the transition period to IPv6, it is imperative that Service Providers maintain IPv4 service for devices and networks that are currently incapable of upgrading to IPv6. Consumers must be able to reach the largely IPv4 Internet after exhaustion. Without a means to share addresses, people or organizations who gain Internet access for the first time, or those who switch providers, or move to another area, will be unable to reach the IPv4 Internet. Further, many CPE router devices used to provide residential or small-medium business services have been optimized for IPv4 operation, and typically require replacement in order to fully support the transition to IPv6 (either natively or via one of many transition technologies). In addition, various consumer devices including IP-enabled televisions, gaming consoles, medical and family monitoring devices, etc. are IPv4-only, and cannot be upgraded. While these will eventually be replaced with dual-stack or IPv6 capable devices, this transition will take many years. As these are typically consumer-owned devices, service providers do not have control over the speed of their replacement cycle. However, consumers have an expectation that they will continue to receive IPv4 service, and that such devices will continue to have IPv4 Internet connectivity after the IPv4 pool is exhausted, even if the customer contracts for new service with a new provider. Until such customers replace their Home Gateways and all IPv4-only devices with IPv6-capable devices, Service Providers will be required to continue to offer IPv4 services through the use of an IPv4 address sharing technology such as NAT444. A recent study showed that there is no part of RFC1918 space which would not overlap with some IPv4 gateways, and therefore to prevent address conflicts, new address space is needed. Service providers are currently presented with three options for obtaining sufficient IPv4 address space for NAT444/IPv4 extension deployments: (1) Request allocations under the NRPM; (2) share address space with other providers (this proposal); or (3) use address space allocated to another entity (i.e. ?squat?). Of the three options, option 2 (this proposal) is preferable, as it will minimize the number of addresses used for IPv4 extension deployments while preserving the authority of IANA and RIRs. Timetable for implementation: immediately _______________________________________________ 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 information contained in this message, including attachments, may contain privileged or confidential information that is intended to be delivered only to the person identified above. If you are not the intended recipient, or the person responsible for delivering this message to the intended recipient, Windstream requests that you immediately notify the sender and asks that you do not read the message or its attachments, and that you delete them without copying or sending them to anyone else. From William.C.Hale at windstream.com Mon May 2 13:10:04 2011 From: William.C.Hale at windstream.com (Hale, William C) Date: Mon, 2 May 2011 12:10:04 -0500 Subject: [arin-ppml] ARIN-2011-6: Returned IPv4 Addresses - Last Call In-Reply-To: <4DAC8BE4.9060002@arin.net> References: <4DAC8BE4.9060002@arin.net> Message-ID: <35780B35A0003743943EF86BA4D0B4171EA54F36@CWWAPP230.windstream.com> I support this draft policy. Bill ________________________________________ From: arin-ppml-bounces at arin.net [arin-ppml-bounces at arin.net] On Behalf Of ARIN [info at arin.net] Sent: Monday, April 18, 2011 2:07 PM To: arin-ppml at arin.net Subject: [arin-ppml] ARIN-2011-6: Returned IPv4 Addresses - Last Call The ARIN Advisory Council (AC) met on 13 April 2011 and decided to send a revised version of the following draft policy to last call: ARIN-2011-6: Returned IPv4 Addresses Feedback is encouraged during the last call period. All comments should be provided to the Public Policy Mailing List. Last call for 2011-6 will expire on 2 May 2011. 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-2011-6 Returned IPv4 Addresses Date: 18 April 2011 Policy statement: 4.1.9 Returned IPv4 Addresses Until a global policy which clearly defines a mechanism for the re-allocation of IPv4 addresses returned to the IANA is adopted by all five regions and implemented at the IANA which clearly defines a mechanism for the re-allocation of IPv4 addresses returned to the IANA; all IPv4 addresses returned to, recovered, or revoked by ARIN will be made available for allocation or assignment in the ARIN region as quickly as practicable. Rationale: Adopting this proposal will result in the clarification of the status of returned IPv4 addresses. IPv4 address resources should not sit idle due to lack of policy clarity. Timetable for implementation: Immediately _______________________________________________ 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 information contained in this message, including attachments, may contain privileged or confidential information that is intended to be delivered only to the person identified above. If you are not the intended recipient, or the person responsible for delivering this message to the intended recipient, Windstream requests that you immediately notify the sender and asks that you do not read the message or its attachments, and that you delete them without copying or sending them to anyone else. From rudi.daniel at gmail.com Mon May 2 13:18:00 2011 From: rudi.daniel at gmail.com (Rudolph Daniel) Date: Mon, 2 May 2011 14:18:00 -0300 Subject: [arin-ppml] ARIN-2011-3: Better IPv6 Allocations for ISPs last call Message-ID: I support this draft policy RD > ARIN-2011-3: Better IPv6 Allocations for ISPs > > Changes include: > 1. Does not delete section 2.9 (request from staff, no impact on policy > meaning) > 2. Limits LIR recursion to a single level and limit subordinate LIRs to > /32. (community concern) > 3. Restores PAU to the calculation in 6.5.2.1(c) (from errata slide > presented in meeting) > 4. Preserves 2010-12 language in new 6.5.3.1 (from errata slide > presented in meeting) > 5. Preserves verbiage allowing ISPs to allocate to their own internal > infrastructure in 6.5.4.1 (from errata slide presented in meeting) > 6. Adds a statement to delete current NRPM 6.9 (from errata slide > presented in meeting) > 7. Adds language to limit initial allocations to no more than a /16 > (6.5.2.1(b)) and to limit subsequent allocations to no larger than a /12 > (an organization may apply for additional /12s, but, no single > allocation larger than a /12 can be made at one time) (6.5.2.1(e)) > (community concern) > > Feedback is encouraged during the last call period. All comments should > be provided to the Public Policy Mailing List. Last call for 2011-3 will > expire on 2 May 2011. 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-2011-3 > Better IPv6 Allocations for ISPs > > Version/Date: 18 April 2011 > > Policy Statement: > > Amend section 2 as follows: > > Replace section 2.10 with the following: > > 2.10 The term End Site shall mean a single structure or service delivery > address, or, in the case of a multi-tenant structure, a single tenant > within said structure (a single customer location). > > Add the following: > > 2.12 When applied to IPv6 policies, the term serving site shall > mean a location where an ISP terminates > or aggregates customer connections, including, but, not limited to > Points of Presence (POPs), Datacenters, Central or Local switching > office or regional or local combinations thereof. > > 2.13 When applied to IPv6 policies, the term > "provider assignment unit" shall mean the prefix of the > smallest block a given ISP assigns to end sites (recommended /48). > > 2.14 The term utilized shall have the following definitions when applied > to IPv6 > policies: > > (i) A provider assignment unit shall be considered fully utilized when > it is assigned to an end-site. > > (ii) Larger blocks shall have their utilization defined by dividing the > number of provider assignment units assigned from the > containing block by the total number of provider assignment > units. This ratio will often be expressed as a percentage > (e.g. a/t*100, for a /36 3072/4096 * 100 = 75% utilization) > > Replace sections 6.5.1 through 6.5.3 with the following: > 6.5.1 Terminology > > (a) The terms ISP and LIR are used interchangeably in this document and > any use of either term shall be construed to include both meanings. > > (b) The term nibble boundary shall mean a network mask which aligns > on a 4-bit boundary (in slash notation, /n, where n is evenly divisible > by 4, allowing unit quantities of X such that 2^n=X where n is > evenly divisible by 4, such as 16, 256, 4096, etc.) > > 6.5.2 Initial Allocations to LIRs > 6.5.2.1 Size > > (a) All allocations shall be made on nibble boundaries. > > (b) In no case shall an LIR receive smaller than a /32 > unless they specifically request a /36. In no case shall > an ISP receive more than a /16 initial allocation. > > (c) The maximum allowable allocation shall be the smallest > nibble-boundary aligned block that can provide an equally > sized nibble-boundary aligned block to each of the > requesters serving sites large enough to satisfy the needs > of the requesters largest single serving site using no more > than 75% of the available addresses. > > This calculation can be summarized as /N where > N = P-(X+Y) and P is the organization's > Provider Allocation Unit X is a multiple of 4 greater > than 4/3*serving sites and Y is a multiple of 4 > greater than 4/3*end sites served by largest serving site. > > (d) For purposes of the calculation in (c), an end site which > can justify more than a /48 under the end-user assignment > criteria in 6.5.8 shall count as the appropriate number of /48s > that would be assigned under that policy. > > (e) For purposes of the calculation in (c), an LIR which has > subordinate LIRs shall make such allocations according > to the same policies and criteria as ARIN. In such a case, > the prefixes necessary for such an allocation should be treated > as fully utilized in determining the block sizing for the parent LIR. > LIRs which do not receive resources directly from ARIN will > not be able to make such allocations to subordinate LIRs and > subordinate LIRs which need more than a /32 shall apply > directly to ARIN. > > (f) An LIR is not required to design or deploy their network > according to this structure. It is strictly a mechanism to > determine the largest IP address block to which the LIR > is entitled. > > 6.5.2.2 Qualifications > An organization qualifies for an allocation under this policy if > they meet any of the following criteria: > > (a) Have a previously justified IPv4 ISP allocation from ARIN > or one of its predecessor registries or can qualify for > an IPv4 ISP allocation under current criteria. > > (b) Are currently multihomed for IPv6 or will immediately > become multihomed for IPv6 using a valid assigned > global AS number. > > In either case, they will be making reassignments > from allocation(s) under this policy to other organizations. > > (c) Provide ARIN a reasonable technical justification > indicating why an allocation is necessary. Justification > must include the intended purposes for the allocation and > describe the network infrastructure the allocation will be used to > support. Justification must also include a plan detailing anticipated > assignments to other organizations or customers for one, > two and five year periods, with a minimum of 50 assignments > within 5 years. > > 6.5.3 Subsequent Allocations to LIRs > > (a) Where possible ARIN will make subsequent allocations by > expanding the existing allocation. > > (b) An LIR which can show utilization of 75% or more of their > total address space, or more than 90% of any serving site > shall be entitled to a subsequent allocation. > > (c) If ARIN can not expand one or more existing allocations, > ARIN shall make a new allocation based on the initial > allocation criteria above. The LIR is encouraged, but not > required to renumber into the new allocation over time > and return any allocations no longer in use. > > (d) If an LIR has already reached a /12 or more, ARIN will > allocate a single additional /12 rather than continue > expanding nibble boundaries. > > Renumber/move the second paragraph of existing section 6.5.2.1 to 6.5.3.1. > > For reference, this would become: > 6.5.3.1 Subsequent Allocations for Transition > Subsequent allocations will also be considered for deployments > that cannot be accommodated by, nor were accounted for, under > the initial allocation. Justification for the subsequent subnet size > will be based on the plan and technology provided with a /24 > being the maximum allowed for a transition technology. > Justification for transitional allocations will be reviewed every 3 > years and reclaimed if they are no longer in use for transitional > purposes. All such allocations for transitional technology will be > made from a block designated for this purpose. > > (This paragraph comes from 2010-12 which was adopted after this draft > policy was written). > > Replace section 6.5.4 with the following > > 6.5.4 Assignments to end users shall be governed by the same > practices adopted by the community in section 6.5.8 except > that the requirements in 6.5.8.1 do not apply. > > 6.5.4.1 An LIR may assign up to a /48 per PoP as well as up to an > additional /48 globally for its own infrastructure. > > Add the following to 6.5.7 > > 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 provided that they agree to > renumber into that new allocation and return their prior allocation(s) > within 5 years. If possible, ARIN will simply expand their existing > allocation rather than requiring renumber and return. > > Delete section 6.9 > > > > > _______________________________________________ > 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 information contained in this message, including attachments, may > contain > privileged or confidential information that is intended to be delivered > only to the > person identified above. If you are not the intended recipient, or the > person > responsible for delivering this message to the intended recipient, > Windstream requests > that you immediately notify the sender and asks that you do not read the > message or its > attachments, and that you delete them without copying or sending them to > anyone else. > > ------------------------------ > > _______________________________________________ > ARIN-PPML mailing list > ARIN-PPML at arin.net > http://lists.arin.net/mailman/listinfo/arin-ppml > > End of ARIN-PPML Digest, Vol 71, Issue 8 > **************************************** > -- Rudi Daniel *danielcharles consulting **1-784 498 8277 * * * -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill at herrin.us Mon May 2 13:17:51 2011 From: bill at herrin.us (William Herrin) Date: Mon, 2 May 2011 13:17:51 -0400 Subject: [arin-ppml] Accusation of fundamental conflict of interest/IPaddress policy pitched directly to ICANN In-Reply-To: References: <4DBB208B.4060808@ipinc.net> <112FF1070FFF4B7E957E13C757CCB513@video> <23B533DB44354E3EA201D0941C47C46C@video> <861B310C-7502-49FE-BD13-3D1B123A57EB@delong.com> <274D7568A828485B91D64F9308B3A24E@video> Message-ID: On Mon, May 2, 2011 at 9:27 AM, Mike Burns wrote: > The authority flows down from the US Dept of Commerce. It doesn't go from > there to the RIRs and back up to ICANN. > ICANN>>RIRs Mike, This is not accurate. ICANN operates IANA under at least two contracts, one to the IETF and one to the DOC. DOC provides the money. IETF provides the authority. http://www.icann.org/en/general/ietf-icann-mou-01mar00.htm http://www.icann.org/en/general/ietf-iana-agreement-v8.htm I could swear there are also contracts with the RIRs themselves which spell out the RIR's responsibility to the IETF and the IANA's responsibility to the RIRs but my google-fu is failing me. Regardless, the source of authority does not derive from the DOC and does not pass through ICANN on its way to the RIRs. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From v6ops at globis.net Mon May 2 13:19:24 2011 From: v6ops at globis.net (Ray Hunter) Date: Mon, 02 May 2011 19:19:24 +0200 Subject: [arin-ppml] Accusation of fundamental conflict of interest/IPaddress policy pitched directly to ICANN Message-ID: <4DBEE79C.6030007@globis.net> Anyone interested in some DECnet phase IV addresses? They're pretty rare: Only 63 areas are available, each allowing 1023 nodes! I also have 2^32 valid IPv4 addresses. [Just don't try routing them on the Public Internet, but they'll work fine for your own use] Maybe we should set up a new global registry? Sound ludicrous? The point being that globally unique IPv4 addresses will only have value to a corporation whilst the majority of their target customers continue to use them as on today's consensus-based Internet. If all of your customers have migrated to IPv6, they're worthless If the IPv4 Internet has fragmented, they're worthless. Is it 100% clear to everyone who actually "owns" all of the current IPv4 address allocations today? Also, the future of the Internet is clearly mobile. There are already about as many mobile Internet users in China as there are people in the US, if not more. Same story in India. Even in the US, there simply won't be enough IPv4 addresses to cover a mass move to mobile devices no matter how much you're prepared to pay for them. So assuming that any semblance of an efficient market in globally unique IPv4 numbers can be created now is IMHO highly questionable. Your mileage may vary. In any case, my personal preference would be to ask ARIN to at least adopt a policy (for the remaining unallocated IPv4 addresses from the ranges that it has been allocated by IANA) that works "in the best interests of the Internet community" by rewarding a migration to IPv6 over anything attempting to further extend the useful life of IPv4, because that is clearly a lost cause. To that end, I personally like the APNIC last /8 policy that somewhat protects new entrants and allows them to deploy at least some useful backwards compatible connectivity to the IPv4 Internet e.g. via stateful NAT64. That existing APNIC last /8 policy could of course potentially be improved upon, taking into account local ARIN regional drivers. You may well yet see "registry shopping" by large organisations. So any policy that ARIN adopts may well have knock on impact to other RIR's, and thus may have to be reviewed at another level to ensure that this is not detrimental to the functioning of the other RIR's, or the Internet as a whole. Just my 2c worth. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike at nationwideinc.com Mon May 2 13:35:20 2011 From: mike at nationwideinc.com (Mike Burns) Date: Mon, 2 May 2011 13:35:20 -0400 Subject: [arin-ppml] Accusation of fundamental conflict ofinterest/IPaddress policy pitched directly to ICANN References: <4DBB208B.4060808@ipinc.net> <112FF1070FFF4B7E957E13C757CCB513@video> <23B533DB44354E3EA201D0941C47C46C@video><861B310C-7502-49FE-BD13-3D1B123A57EB@delong.com> <274D7568A828485B91D64F9308B3A24E@video> Message-ID: <53A513E31BE148B590E399558AA71963@mike> Hi Bill, OK, then let the IETF and either the DoC or NTIA hash it out, since they are all entities above the RIRs. I think the contracts with the RIRs you reference are not actually contracts but further MoAs. I think there is enough separation between the IETF and the RIRs that there would be an honest appraisal of the proposal. And if money and authority speak with one voice, I suppose it will be heard. Regards, Mike ----- Original Message ----- From: "William Herrin" To: "Mike Burns" Cc: "Jimmy Hess" ; "John Curran" ; Sent: Monday, May 02, 2011 1:17 PM Subject: Re: [arin-ppml] Accusation of fundamental conflict ofinterest/IPaddress policy pitched directly to ICANN On Mon, May 2, 2011 at 9:27 AM, Mike Burns wrote: > The authority flows down from the US Dept of Commerce. It doesn't go from > there to the RIRs and back up to ICANN. > ICANN>>RIRs Mike, This is not accurate. ICANN operates IANA under at least two contracts, one to the IETF and one to the DOC. DOC provides the money. IETF provides the authority. http://www.icann.org/en/general/ietf-icann-mou-01mar00.htm http://www.icann.org/en/general/ietf-iana-agreement-v8.htm I could swear there are also contracts with the RIRs themselves which spell out the RIR's responsibility to the IETF and the IANA's responsibility to the RIRs but my google-fu is failing me. Regardless, the source of authority does not derive from the DOC and does not pass through ICANN on its way to the RIRs. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From mpetach at netflight.com Mon May 2 13:47:34 2011 From: mpetach at netflight.com (Matthew Petach) Date: Mon, 2 May 2011 10:47:34 -0700 Subject: [arin-ppml] ARIN-2011-3: Better IPv6 Allocations for ISPs - Last Call In-Reply-To: <4DAC8B7F.2080303@arin.net> References: <4DAC8B7F.2080303@arin.net> Message-ID: On Mon, Apr 18, 2011 at 12:05 PM, ARIN wrote: > The ARIN Advisory Council (AC) met on 13 April 2011 and decided to > send a revised version of the following draft policy to last call: > > ?ARIN-2011-3: Better IPv6 Allocations for ISPs > ... > 7. Adds language to limit initial allocations to no more than a /16 > (6.5.2.1(b)) and to limit subsequent allocations to no larger than a /12 > (an organization may apply for additional /12s, but, no single > allocation larger than a /12 can be made at one time) (6.5.2.1(e)) > (community concern) I am opposed to this draft policy. The idea of handing out /12 blocks, and potentially *multiple* /12 blocks to an organization is ludicrous if this protocol is to have any hope for longevity. :( I think the largest block that should be allocatable should be a /20; that would still allow for 6rd deployments using /56 allocations for end sites, which is reasonable for a transition technology; if they want full /48s, they can start with a /56 during the 6rd period, and then once their upstream goes fully native, they can get a natively routed /48. With a /20 as the shortest prefix allocatable to an ISP, that still allows for a million such allocations, which is likely to last us considerably longer than the 4096 /12 blocks espoused by this proposal. Matt From mike at nationwideinc.com Mon May 2 13:50:55 2011 From: mike at nationwideinc.com (Mike Burns) Date: Mon, 2 May 2011 13:50:55 -0400 Subject: [arin-ppml] Accusation of fundamental conflict ofinterest/IPaddress policy pitched directly to ICANN References: <4DBEE79C.6030007@globis.net> Message-ID: >The point being that globally unique IPv4 addresses will only have value to a corporation whilst the majority of their target customers continue to use them as on today's consensus-based Internet. >If all of your customers have migrated to IPv6, they're worthless >If the IPv4 Internet has fragmented, they're worthless. >Is it 100% clear to everyone who actually "owns" all of the current IPv4 address allocations today? >Also, the future of the Internet is clearly mobile. There are already about as many mobile Internet users in China as there are people in the US, if not more. Same story in India. Even in the US, there simply won't be >enough IPv4 addresses to cover a mass move to mobile devices no matter how much you're prepared to pay for them. >So assuming that any semblance of an efficient market in globally unique IPv4 numbers can be created now is IMHO highly questionable. >Ray Hunter Hi Ray, I'm sorry but I don't see how the prior statements lead to the conclusion that an efficient market in globally unique IPv4 numbers can not now be created. Is it because there is confusion over who actually "owns" the current IPv4 allocations today? Because that goes right to the issues with whois veracity that I think will be improved with competing registries, and is likely to improve anyway, as IP address values are understood and claims are made. Yes, IPv4 addresses only have value if customers use them on the Internet. Yes, if all customers migrate to IPv6, they are worthless, and yes, if the IPv4 is fragmented to the point of non-usability, they are worthless. Yes, there will be continued demand for addresses that will be larger than can be accomodated if by the IPv4 pool, if the Internet retains it's current single-level NAT architecture. But I don't see how the conclusion that a viable market cannot be created follows from your statements, though.Some have posted that the market will provide incentive to transition that is otherwise lacking, a problem described way back by a prescient John Curran over 15 years ago. http://www.armware.dk/RFC/rfc/rfc1669.html Certainly you have elucidated risks to those who participate in those markets, but those risks will presumably be known to participants, and presumably were known to Microsoft before they paid $7.5 million. Regards, Mike Burns -------------- next part -------------- An HTML attachment was scrubbed... URL: From ebw at abenaki.wabanaki.net Mon May 2 13:39:23 2011 From: ebw at abenaki.wabanaki.net (Eric Brunner-Williams) Date: Mon, 02 May 2011 13:39:23 -0400 Subject: [arin-ppml] Accusation of fundamental conflict of interest/IPaddress policy pitched directly to ICANN In-Reply-To: References: <4DBB208B.4060808@ipinc.net><112FF1070FFF4B7E957E13C757CCB513@video><23B533DB44354E3EA201D0941C47C46C@video><861B310C-7502-49FE-BD13-3D1B123A57EB@delong.com><274D7568A828485B91D64F9308B3A24E@video> Message-ID: <4DBEEC4B.3080602@abenaki.wabanaki.net> On 5/2/11 9:27 AM, Mike Burns wrote: > The authority flows down from the US Dept of Commerce. It doesn't go > from there to the RIRs and back up to ICANN. > ICANN>>RIRs what statutory authority? i see two possible errors in mike's response to owen, john, etc. first, he characterizes the iana function as an institutional actor, and thereby a "higher authority", rather than as a function currently contained within a set of functions in, or added to, the contract now the subject of review by the department of commerce. see the federal register of february 25th for the notice of inquiry. second, in an error more generally shared than this specific context, he removes the specific purposes of diversity of territorial jurisdiction and scaling for the initial reformation of the "numbers czar" function to one which permits delegation, creating the rir responsibilities. these historic purposes are not modernly inoperative, nor replaced without risk by a novel aterritorial responsibility serving no diversity of territorial or scaling interests, however beneficial such a grant of franchise may be to the recipient. eric From info at arin.net Mon May 2 13:58:55 2011 From: info at arin.net (ARIN) Date: Mon, 02 May 2011 13:58:55 -0400 Subject: [arin-ppml] ARIN-prop-140 Business Failure Clarification Message-ID: <4DBEF0DF.8060800@arin.net> ARIN-prop-140 Business Failure Clarification 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-140 Business Failure Clarification Proposal Originator: Matthew Kaufman Proposal Version: 1 Date: 2 May 2011 Proposal type: new Policy term: permanent Policy statement: Add to end of Section 8.1: "Note that an entity which is reorganizing under any section of the US bankruptcy code (or foreign equivalent) is not 'out of business' for the purpose of interpreting this section" Rationale: Potential confusion exists over the requirement to return address space from a bankrupt entity. This is a needed clarification to the policy manual. Timetable for implementation: immediate From info at arin.net Mon May 2 13:59:07 2011 From: info at arin.net (ARIN) Date: Mon, 02 May 2011 13:59:07 -0400 Subject: [arin-ppml] ARIN-prop-141 Combined M&A and Specified Transfers Message-ID: <4DBEF0EB.5070905@arin.net> ARIN-prop-141 Combined M&A and Specified Transfers 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-141 Combined M&A and Specified Transfers Proposal Originator: Matthew Kaufman Proposal Version: 1 Date: 2 May 2011 Proposal type: new Policy term: permanent Policy statement: To section 8.2 change "... ARIN will work with the resource holder(s) to return, aggregate, or reclaim resources as appropriate via the processes outlined in current ARIN policy (for example, sections 4.6, 4.7, or 12 of the NRPM)." to "... ARIN will work with the resource holder(s) to return, aggregate, or reclaim resources as appropriate via the processes outlined in current ARIN policy (for example, sections 4.6, 4.7, or 12 of the NRPM), or to transfer resources to a qualified specified recipient via the processes outlined in current ARIN policy (section 8.3 of the NRPM)". Rationale: Given that both M&A transfers and specified transfers are possible, it should be possible to execute a combined transfer in which unneeded resources are transferred via 8.3 (rather than returning unneeded resources to the free pool) and the rest are transferred via 8.2. Doing this in the wrong order (i.e., attempting to execute the 8.2 transfer first) should not penalize the transferring entity... especially as ARIN's opinion as to what is "no longer justified under ARIN policy" is best known by ARIN and may not be completely knowable by the transferring entity. Note that as there is no ARIN policy permitting IPv6 specified transfers, this policy would only affect IPv4 resources at this time. Timetable for implementation: immediate From info at arin.net Mon May 2 13:59:18 2011 From: info at arin.net (ARIN) Date: Mon, 02 May 2011 13:59:18 -0400 Subject: [arin-ppml] ARIN-prop-142 Define RSA Message-ID: <4DBEF0F6.2050502@arin.net> ARIN-prop-142 Define RSA 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-142 Define RSA Proposal Originator: Matthew Kaufman Proposal Version: 1 Date: 2 May 2011 Proposal type: new Policy term: permanent Policy statement: Add to "Definitions" the definition of "Registration Services Agreement (RSA)" - A Registration Services Agreement (RSA) is an agreement entered into between this Internet Registry and a Local Internet Registry or End-user. The specific form of agreement is not defined in this document and may differ in its specifics from one agreement to another. The "Standard RSA" and the various forms of "Legacy Registration Services Agreement (LRSA)" are examples of such an agreement. Rationale: The term "Registration Services Agreement" is used in 4.2.1.2 and 8.1 without definition. The term RSA is used in 4.6.5 and 8.3 without definition. ARIN staff has interpreted Registration Services Agreement in 8.3 (and possibly other places) to mean "any registration services agreement" rather than "a specific, standard, and unmodified Registration Services Agreement". Readers of the NRPM have come to other conclusions. Timetable for implementation: immediate From info at arin.net Mon May 2 13:59:29 2011 From: info at arin.net (ARIN) Date: Mon, 02 May 2011 13:59:29 -0400 Subject: [arin-ppml] ARIN-prop-143 Clarify Specified Transfer RSA Requirement Message-ID: <4DBEF101.5060407@arin.net> ARIN-prop-143 Clarify Specified Transfer RSA Requirement ARIN received the following policy proposal and is posting it to the Public Policy Mailing List (PPML) in accordance with the Policy Development Process. The ARIN Advisory Council (AC) will review the proposal at their next regularly scheduled meeting (if the period before the next regularly scheduled meeting is less than 10 days, then the period may be extended to the subsequent regularly scheduled meeting). The AC will decide how to utilize the proposal and announce the decision to the PPML. The AC invites everyone to comment on the proposal on the PPML, particularly their support or non-support and the reasoning behind their opinion. Such participation contributes to a thorough vetting and provides important guidance to the AC in their deliberations. Draft Policies and Proposals under discussion can be found at: https://www.arin.net/policy/proposals/index.html The ARIN Policy Development Process can be found at: https://www.arin.net/policy/pdp.html Mailing list subscription information can be found at: https://www.arin.net/mailing_lists/ Regards, Communications and Member Services American Registry for Internet Numbers (ARIN) ## * ## ARIN-prop-143 Clarify Specified Transfer RSA Requirement Proposal Originator: Matthew Kaufman Proposal Version: 1 Date: 2 May 2011 Proposal type: new Policy term: permanent Policy statement: Replace section 8.3 "Such transferred number resources may only be received under RSA" with "Such transferred number resources may only be received under a registration services agreement" Add to section 8.3 "It is the intent of this policy that the registration services agreement under which the transferred resources are received SHOULD be at least as restrictive as the registration services agreement that covers these resources prior to the transfer. Legacy resources that are not currently covered by a registration services agreement should be received under a Legacy Registration Services Agreement (or at the recipient's option, the standard Registration Services Agreement). Legacy resources that are currently covered by a Legacy Registration Services Agreement should be received under a Legacy Registration Services Agreement which is at least as restrictive as the previous LRSA (or at the recipient's option, the standard Registration Services Agreement). Resources that are currently covered under the standard Registration Services Agreement should be received under the standard Registration Services Agreement. ARIN staff shall report periodically on any required deviation from this paragraph, including modifications that have been required to either the standard forms of the LRSA or RSA." Rationale: Clarifies the NRPM to reflect policy as currently implemented and to properly reflect that legacy resources may be received, at the option of the recipient, under either the standard RSA or the legacy RSA. Also clarifies the NRPM to reflect that registration services agreements may be modified from standard if necessary for the purposes of effecting Section 8.3 transfers. Requires transparency for deviations from the recommended policy and/or customized registration services agreements. Timetable for implementation: immediate From info at arin.net Mon May 2 13:59:39 2011 From: info at arin.net (ARIN) Date: Mon, 02 May 2011 13:59:39 -0400 Subject: [arin-ppml] ARIN-prop-144 Remove Single Aggregate requirement from Specified Transfer Message-ID: <4DBEF10B.50902@arin.net> ARIN-prop-144 Remove Single Aggregate requirement from Specified Transfer 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-144 Remove Single Aggregate requirement from Specified Transfer Proposal Originator: Matthew Kaufman Proposal Version: 1 Date: 2 May 2011 Proposal type: new Policy term: permanent Policy statement: Modify Section 8.3 as follows: Change "can demonstrate the need for such resources, as a single aggregate, in the exact amount which they can justify under current ARIN policies" to "can demonstrate the need for such resources in the amount which they can justify under current ARIN policies" Rationale: The "as a single aggregate" has been interpreted to apply only to "demonstrate the need" as opposed to the resources which may be received by ARIN staff. It is possible that the original intent was to require than each transfer be of a single aggregate. HOWEVER, as multiple Section 8.3 transfers may be executed serially by a pair of entities which wish to use the specified transfer policy in order to transfer any number of blocks as long as there is needs justification for each, it simply saves the transferring entity, the recipient, AND ARIN paperwork to allow a transfer of multiple blocks to proceed as a single transfer. Timetable for implementation: immediate From hannigan at gmail.com Mon May 2 13:59:25 2011 From: hannigan at gmail.com (Martin Hannigan) Date: Mon, 2 May 2011 13:59:25 -0400 Subject: [arin-ppml] ARIN-2011-4: Reserved Pool for Critical Infrastructure - Last Call In-Reply-To: <35780B35A0003743943EF86BA4D0B4171EA54F34@CWWAPP230.windstream.com> References: <4DAC8B90.5070104@arin.net> <35780B35A0003743943EF86BA4D0B4171EA54F34@CWWAPP230.windstream.com> Message-ID: Why not? Best, -M< On Mon, May 2, 2011 at 1:09 PM, Hale, William C wrote: > I do not support this draft policy. > > Bill > ________________________________________ > From: arin-ppml-bounces at arin.net [arin-ppml-bounces at arin.net] On Behalf Of ARIN [info at arin.net] > Sent: Monday, April 18, 2011 2:05 PM > To: arin-ppml at arin.net > Subject: [arin-ppml] ARIN-2011-4: Reserved Pool for Critical Infrastructure ? ? - Last Call > > The ARIN Advisory Council (AC) met on 13 April 2011 and decided to > send a revised version of the following draft policy to last call: > > ? ARIN-2011-4: Reserved Pool for Critical Infrastructure > > Feedback is encouraged during the last call period. All comments should > be provided to the Public Policy Mailing List. Last call for 2011-4 will > expire on 2 May 2011. 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-2011-4 > Reserved Pool for Critical Infrastructure > > Version/Date: 16 Feb 2011 > > Policy term: 36 Months following implementation > > Policy statement: > > ARIN will place an equivalent of a /16 of IPv4 address space in a > reserve for Critical Infrastructure, as defined in section 4.4. If at > the end of the policy term there is unused address space remaining in > this pool, ARIN staff is authorized to utilize this space in a manner > consistent with community expectations. > > Rationale: > > Section 4.10 of the NRPM is insufficient with respect to insuring the > continued operation of critical infrastructure. This proposal, if > adopted, will protect those resources with a reasonable amount of > reserved v4 address space and prevent an overrun of CI needs by NRPM > Section 4.10 or any successor. The intent is to separate CI needs and > make a distinct pool available to insure the continuity of CI > allocations per NRPM Section 4.4 for at least 36 months. > > 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. > *************************************************************************************** > The information contained in this message, including attachments, may contain > privileged or confidential information that is intended to be delivered only to the > person identified above. If you are not the intended recipient, or the person > responsible for delivering this message to the intended recipient, Windstream requests > that you immediately notify the sender and asks that you do not read the message or its > attachments, and that you delete them without copying or sending them to anyone else. > _______________________________________________ > 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 Mon May 2 13:59:50 2011 From: info at arin.net (ARIN) Date: Mon, 02 May 2011 13:59:50 -0400 Subject: [arin-ppml] ARIN-prop-145 STLS Listing Immunity Message-ID: <4DBEF116.1000400@arin.net> ARIN-prop-145 STLS Listing Immunity 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-145 STLS Listing Immunity Proposal Originator: Matthew Kaufman Proposal Version: 1 Date: 2 May 2011 Proposal type: new Policy term: permanent Policy statement: Add a subsection to Section 12 (Resource Review) of the NRPM: ARIN may not revoke any resources issued by ARIN that are presently listed as "available" on the ARIN Specified Transfer Listing Service unless there is sufficient reason to believe that the holder does not in fact intend to transfer these resources. Rationale: An entity may list space as available and might begin the process of moving out of that space in order to facilitate the transfer. A review after such work was in progress might reveal that the addresses are not sufficiently utilized. Additionally, because posting a listing on the STLS signals directly to ARIN that an entity believes it can use addresses more efficiently, ARIN might simply use STLS listings in order to trigger audit under 12.2(c). This would not be fair. (And would be a disincentive to using the ARIN STLS at all in order to list available space) This policy would also serve to increase the value of the ARIN STLS over other possible transfer listing services, increasing the transparency of the transfer market, particularly to ARIN, who wishes to ensure that transfers take place within NRPM 8.3. Timetable for implementation: immediate From info at arin.net Mon May 2 14:00:00 2011 From: info at arin.net (ARIN) Date: Mon, 02 May 2011 14:00:00 -0400 Subject: [arin-ppml] ARIN-prop-146 Clarify Justified Need for Transfers Message-ID: <4DBEF120.4080901@arin.net> ARIN-prop-146 Clarify Justified Need for Transfers 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-146 Clarify Justified Need for Transfers Proposal Originator: Matthew Kaufman Proposal Version: 1 Date: 2 May 2011 Proposal type: new Policy term: permanent Policy statement: Add a subsection to Section 8 (Transfers) of the NRPM: "Justified Need" for resources associated with a transfer shall be determined using the "4.2.4 ISP Additional Requests" criteria applied as though the recipient has been a subscriber member of ARIN for at least one year (whether or not that is the case). Rationale: An organization which is not able to obtain its initial IPv4 address assignment from ARIN post-runout would otherwise be limited to purchasing only a 3-month supply (because the language in 4.2.4.4 regarding 8.3 transfers is not triggered). An organization which has only recently received its first allocation under the "last /8" criteria is also otherwise limited to purchasing only a 3-month supply (because the language in 4.2.4.4 is again not applicable). There is also ambiguity if 4.2.2.1.3 is applied in that a transfer to a new organization might only need to show need for a /20 (because that is what is specifically called out) even though they are receiving a much larger block. There is also ambiguity with regard to transfers under 8.2 where the receiving organization is a new organization... not at all clear how "justified need" has been or should be determined. Timetable for implementation: immediate From info at arin.net Mon May 2 14:00:10 2011 From: info at arin.net (ARIN) Date: Mon, 02 May 2011 14:00:10 -0400 Subject: [arin-ppml] ARIN-prop-147 Set Transfer Need to 24 months and Clarify Exception Message-ID: <4DBEF12A.2020002@arin.net> ARIN-prop-147 Set Transfer Need to 24 months and Clarify Exception 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-147 Set Transfer Need to 24 months and Clarify Exception Proposal Originator: Matthew Kaufman Proposal Version: 1 Date: 2 May 2011 Proposal type: new Policy term: permanent Policy statement: Change section 4.2.4.4 content as follows: Replace: "This reduction does not apply to resources received via section 8.3. An organization receiving a transfer under section 8.3 may continue to request up to a 12-month supply of IP addresses." With: "This reduction does not apply to resources received via transfer. An organization receiving a transfer under section 8 may request up to a 24-month supply of IP addresses." Rationale: The exception should apply to transfers under 8.2 as well as 8.3 (and any future transfer policies). Due to the complexity of the financial transaction that may be involved and the associated budgeting on the part of the receiving organization, 24 months is a more reasonable amount of forecast need to allow to be fulfilled via the transfer process. Potential benefit to address aggregation by allowing fewer larger transfers sooner. Timetable for implementation: immediate From mpetach at netflight.com Mon May 2 14:01:17 2011 From: mpetach at netflight.com (Matthew Petach) Date: Mon, 2 May 2011 11:01:17 -0700 Subject: [arin-ppml] ARIN-2011-4: Reserved Pool for Critical Infrastructure - Last Call In-Reply-To: <4DAC8B90.5070104@arin.net> References: <4DAC8B90.5070104@arin.net> Message-ID: On Mon, Apr 18, 2011 at 12:05 PM, ARIN wrote: > The ARIN Advisory Council (AC) met on 13 April 2011 and decided to > send a revised version of the following draft policy to last call: > > ?ARIN-2011-4: Reserved Pool for Critical Infrastructure I'm down with this as written. Matt From lea.roberts at stanford.edu Mon May 2 14:04:03 2011 From: lea.roberts at stanford.edu (Lea Roberts) Date: Mon, 2 May 2011 11:04:03 -0700 (PDT) Subject: [arin-ppml] ARIN-2011-3: Better IPv6 Allocations for ISPs - Last Call In-Reply-To: References: <4DAC8B7F.2080303@arin.net> Message-ID: +1 (well said, Matt!) /Lea On Mon, 2 May 2011, Matthew Petach wrote: > On Mon, Apr 18, 2011 at 12:05 PM, ARIN wrote: >> The ARIN Advisory Council (AC) met on 13 April 2011 and decided to >> send a revised version of the following draft policy to last call: >> >> ?ARIN-2011-3: Better IPv6 Allocations for ISPs >> > ... >> 7. Adds language to limit initial allocations to no more than a /16 >> (6.5.2.1(b)) and to limit subsequent allocations to no larger than a /12 >> (an organization may apply for additional /12s, but, no single >> allocation larger than a /12 can be made at one time) (6.5.2.1(e)) >> (community concern) > > I am opposed to this draft policy. The idea of handing out /12 blocks, > and potentially *multiple* /12 blocks to an organization is ludicrous if > this protocol is to have any hope for longevity. :( > I think the largest block that should be allocatable should be a /20; > that would still allow for 6rd deployments using /56 allocations for > end sites, which is reasonable for a transition technology; if they > want full /48s, they can start with a /56 during the 6rd period, and > then once their upstream goes fully native, they can get a natively > routed /48. > With a /20 as the shortest prefix allocatable to an ISP, that still > allows for a million such allocations, which is likely to last us > considerably longer than the 4096 /12 blocks espoused by this > proposal. > > Matt From mike at nationwideinc.com Mon May 2 14:07:02 2011 From: mike at nationwideinc.com (Mike Burns) Date: Mon, 2 May 2011 14:07:02 -0400 Subject: [arin-ppml] Accusation of fundamental conflictof interest/IPaddress policy pitched directly to ICANN References: <4DBB208B.4060808@ipinc.net><112FF1070FFF4B7E957E13C757CCB513@vid eo><23B533DB44354E3EA201D0941C47C46C@video><861B310C-7502-49FE-BD13-3D1B123A57EB @delong.com><274D7568A828485B91D64F9308B3A24E@video> <4DBEEC4B.3080602@abenaki.wabanaki.net> Message-ID: <3770701FD04F4F678AF7188174246730@mike> Hi Eric, I don't think it makes sense to view the RIRs, who are latecomers after all, as the top of the totem pole in terms of authority. As a member who received his allocation prior to ARIN's existence, and all the other RIR's existences, I know there is a higher authority. Whether the contract is being reviewed or not, the contract with DoC exists. I don't understand the paragraph that begins with the word second, but I would like to, could it be rephrased? I understand that you support the concept of regionality, but there are those pesky legacy addresses to consider, and they were allocated in a pre-regional Internet. Would you consider that legacy addresses, at the least, should be portable to an alternate registry? Regards, Mike ----- Original Message ----- From: "Eric Brunner-Williams" To: Sent: Monday, May 02, 2011 1:39 PM Subject: Re: [arin-ppml] Accusation of fundamental conflictof interest/IPaddress policy pitched directly to ICANN > On 5/2/11 9:27 AM, Mike Burns wrote: >> The authority flows down from the US Dept of Commerce. It doesn't go >> from there to the RIRs and back up to ICANN. >> ICANN>>RIRs > > what statutory authority? > > i see two possible errors in mike's response to owen, john, etc. > > first, he characterizes the iana function as an institutional actor, and > thereby a "higher authority", rather than as a function currently > contained within a set of functions in, or added to, the contract now the > subject of review by the department of commerce. see the federal register > of february 25th for the notice of inquiry. > > second, in an error more generally shared than this specific context, he > removes the specific purposes of diversity of territorial jurisdiction and > scaling for the initial reformation of the "numbers czar" function to one > which permits delegation, creating the rir responsibilities. > > these historic purposes are not modernly inoperative, nor replaced without > risk by a novel aterritorial responsibility serving no diversity of > territorial or scaling interests, however beneficial such a grant of > franchise may be to the recipient. > > eric > _______________________________________________ > 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 2 14:07:43 2011 From: bill at herrin.us (William Herrin) Date: Mon, 2 May 2011 14:07:43 -0400 Subject: [arin-ppml] Accusation of fundamental conflict ofinterest/IPaddress policy pitched directly to ICANN In-Reply-To: <53A513E31BE148B590E399558AA71963@mike> References: <4DBB208B.4060808@ipinc.net> <112FF1070FFF4B7E957E13C757CCB513@video> <23B533DB44354E3EA201D0941C47C46C@video> <861B310C-7502-49FE-BD13-3D1B123A57EB@delong.com> <274D7568A828485B91D64F9308B3A24E@video> <53A513E31BE148B590E399558AA71963@mike> Message-ID: On Mon, May 2, 2011 at 1:35 PM, Mike Burns wrote: > OK, then let the IETF and either the DoC or NTIA hash it out, since they are > all entities above the RIRs. Hi Mike, The IETF is certainly available as a forum for discussing IP addressing ideas too fundamentally at odds with the RIR process to gain a fair hearing there. I don't see a working group listed which would be obviously appropriate. Suggest you hold a BOF (informal Birds of a Feather meeting) at the next IETF conference and solicit interest in forming a working group. I would also suggest that a BOF would be a much more appropriate forum for such discussion than letters to the ICANN. With respect to IP addresses, ICANN is not empowered to act counter to the wishes of the IETF and RIRs. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From joe at oregon.uoregon.edu Mon May 2 13:59:46 2011 From: joe at oregon.uoregon.edu (Joe St Sauver) Date: Mon, 2 May 2011 10:59:46 -0700 (PDT) Subject: [arin-ppml] ARIN-prop-140 Business Failure Clarification Message-ID: <11050210594687_A4@oregon.uoregon.edu> Hi, Regarding the proposal to... #Add to end of Section 8.1: "Note that an entity which is reorganizing #under any section of the US bankruptcy code (or foreign equivalent) is #not 'out of business' for the purpose of interpreting this section" # #Rationale: # #Potential confusion exists over the requirement to return address space #from a bankrupt entity. This is a needed clarification to the policy manual. I have some concerns with the proposed language. While I am not a lawyer and this is not legal advice, it is my understanding that not all types of US bankruptcies are the same. For example, while it is true that a company often comes out the other side of a Chapter 11 reorganization as a functioning entity, a totally insolvent company that files a Chapter 7 liquidation is typically disolved/end-of-life/ out-of-business for all intents and purposes. In my opinion, the proposed policy should make it clear that it applies ONLY to "reorganizations" and NOT to "liquidations" (as might be implied by the "under ANY section of the US bankruptcy code" reference, emphasis added), assuming that this is indeed the intent of the suggested policy language. I am also not aware of the extent to which non-US entities offer the equivalent of US Chapter 11 reorganizatons as an option for financially distressed companies. How close would an "equivalent" foreign policy need to be to "count" for the purposes of this policy? Regards, Joe St Sauver Disclaimer: all opinions strictly my own. From mike at nationwideinc.com Mon May 2 14:12:43 2011 From: mike at nationwideinc.com (Mike Burns) Date: Mon, 2 May 2011 14:12:43 -0400 Subject: [arin-ppml] Accusation of fundamental conflictofinterest/IPaddress policy pitched directly to ICANN References: <4DBB208B.4060808@ipinc.net> <112FF1070FFF4B7E957E13C757CCB513@video> <23B533DB44354E3EA201D0941C47C46C@video><861B310C-7502-49FE-BD13-3D1B123A57EB@delong.com> <274D7568A828485B91D64F9308B3A24E@video> <53A513E31BE148B590E399558AA71963@mike> Message-ID: <01D6F4E05B5D4FD6A223221DEEDB2F97@mike> >I would also suggest that a BOF would be a much more appropriate forum >for such discussion than letters to the ICANN. With respect to IP >addresses, ICANN is not empowered to act counter to the wishes of the >IETF and RIRs. >Regards, >Bill Herrin Hi Bill, I suppose the letter writer was looking for a shortcut, although the whole issue of authority seems a little nebulous to me. Thanks for your advice regarding the IETF. BOF, I like that acronym. Regards, Mike From mike at nationwideinc.com Mon May 2 14:14:50 2011 From: mike at nationwideinc.com (Mike Burns) Date: Mon, 2 May 2011 14:14:50 -0400 Subject: [arin-ppml] ARIN-2011-4: Reserved Pool for CriticalInfrastructure - Last Call References: <4DAC8B90.5070104@arin.net><35780B35A0003743943EF86BA4D0B4171EA54F34@CWWAPP230.windstream.com> Message-ID: <93E2853DCE734515BF30546CA4ED5355@mike> I support ARIN-2011-4 Reserved Pool for critical infrastructure. Inasmuch as I see more life in IPv4 than most on this list, I think this reserve makes sense. Regards, Mike Burns : > > ARIN-2011-4: Reserved Pool for Critical Infrastructure > > Feedback is encouraged during the last call period. All comments should > be provided to the Public Policy Mailing List. Last call for 2011-4 will > expire on 2 May 2011. 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-2011-4 > Reserved Pool for Critical Infrastructure > > Version/Date: 16 Feb 2011 > > Policy term: 36 Months following implementation > > Policy statement: > > ARIN will place an equivalent of a /16 of IPv4 address space in a > reserve for Critical Infrastructure, as defined in section 4.4. If at > the end of the policy term there is unused address space remaining in > this pool, ARIN staff is authorized to utilize this space in a manner > consistent with community expectations. > > Rationale: > > Section 4.10 of the NRPM is insufficient with respect to insuring the > continued operation of critical infrastructure. This proposal, if > adopted, will protect those resources with a reasonable amount of > reserved v4 address space and prevent an overrun of CI needs by NRPM > Section 4.10 or any successor. The intent is to separate CI needs and > make a distinct pool available to insure the continuity of CI > allocations per NRPM Section 4.4 for at least 36 months. > > 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. > *************************************************************************************** > The information contained in this message, including attachments, may > contain > privileged or confidential information that is intended to be delivered > only to the > person identified above. If you are not the intended recipient, or the > person > responsible for delivering this message to the intended recipient, > Windstream requests > that you immediately notify the sender and asks that you do not read the > message or its > attachments, and that you delete them without copying or sending them to > anyone else. > _______________________________________________ > 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 mpetach at netflight.com Mon May 2 14:19:07 2011 From: mpetach at netflight.com (Matthew Petach) Date: Mon, 2 May 2011 11:19:07 -0700 Subject: [arin-ppml] ARIN-prop-144 Remove Single Aggregate requirement from Specified Transfer In-Reply-To: <4DBEF10B.50902@arin.net> References: <4DBEF10B.50902@arin.net> Message-ID: On Mon, May 2, 2011 at 10:59 AM, ARIN wrote: > ARIN-prop-144 Remove Single Aggregate requirement from Specified Transfer > ... > Modify Section 8.3 as follows: > Change "can demonstrate the need for such resources, as a single > aggregate, in the exact amount which they can justify under current ARIN > policies" to "can demonstrate the need for such resources in the amount > which they can justify under current ARIN policies" I totally support this. The weekly CIDR report shows that people aren't aggregating their blocks as is, and public shame does nothing to change that trend. Requiring a single aggregate during transfer or allocation does nothing to prevent the recipient from splitting it into tiny fragments seconds after they receive the allocation, and turns the existing policy into a toothless dragon. This will simply make policy fit the demonstrated real behaviour of networks in the real world. Matt From matthew at matthew.at Mon May 2 14:20:19 2011 From: matthew at matthew.at (Matthew Kaufman) Date: Mon, 2 May 2011 11:20:19 -0700 Subject: [arin-ppml] ARIN-prop-140 Business Failure Clarification In-Reply-To: <11050210594687_A4@oregon.uoregon.edu> References: <11050210594687_A4@oregon.uoregon.edu> Message-ID: <4CF8BEEF-4CFB-4EB6-B395-9CB1CEF8326B@matthew.at> On May 2, 2011, at 10:59 AM, Joe St Sauver wrote: > > I have some concerns with the proposed language. > > While I am not a lawyer and this is not legal advice, it is my understanding > that not all types of US bankruptcies are the same. > > For example, while it is true that a company often comes out the other side > of a Chapter 11 reorganization as a functioning entity, a totally insolvent > company that files a Chapter 7 liquidation is typically disolved/end-of-life/ > out-of-business for all intents and purposes. Correct. But is it better for their creditors to be paid using the proceeds of an 8.3 transfer, or is it better for ARIN to attempt to reclaim the addresses. It is questionable if the latter would succeed anyway, given that in Chapter 7 the assets (and anything even somewhat like "assets") are frozen... and that the Nortel-Microsoft transfer is an example of how the court treats this. Part of the intent here is to bring written policy into agreement with how this is actually being implemented. > > In my opinion, the proposed policy should make it clear that it applies > ONLY to "reorganizations" and NOT to "liquidations" (as might be implied by > the "under ANY section of the US bankruptcy code" reference, emphasis added), > assuming that this is indeed the intent of the suggested policy language. The intent is to apply to any organization which has not yet been actually dissolved. > > I am also not aware of the extent to which non-US entities offer the > equivalent of US Chapter 11 reorganizatons as an option for financially > distressed companies. How close would an "equivalent" foreign policy need > to be to "count" for the purposes of this policy? I'm not a bankruptcy attorney either... this might need discussion. Matthew Kaufman From bret at getjive.com Mon May 2 14:16:20 2011 From: bret at getjive.com (Bret Palsson) Date: Mon, 2 May 2011 12:16:20 -0600 Subject: [arin-ppml] ARIN-2011-4: Reserved Pool for CriticalInfrastructure - Last Call In-Reply-To: <93E2853DCE734515BF30546CA4ED5355@mike> References: <4DAC8B90.5070104@arin.net> <35780B35A0003743943EF86BA4D0B4171EA54F34@CWWAPP230.windstream.com> <93E2853DCE734515BF30546CA4ED5355@mike> Message-ID: <-5461547782692310567@unknownmsgid> I'm a go. Yes. Sent from my iPhone On May 2, 2011, at 12:15 PM, "Mike Burns" wrote: > I support ARIN-2011-4 Reserved Pool for critical infrastructure. > > Inasmuch as I see more life in IPv4 than most on this list, I think this reserve makes sense. > > Regards, > > Mike Burns > > : >> >> ARIN-2011-4: Reserved Pool for Critical Infrastructure >> >> Feedback is encouraged during the last call period. All comments should >> be provided to the Public Policy Mailing List. Last call for 2011-4 will >> expire on 2 May 2011. 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-2011-4 >> Reserved Pool for Critical Infrastructure >> >> Version/Date: 16 Feb 2011 >> >> Policy term: 36 Months following implementation >> >> Policy statement: >> >> ARIN will place an equivalent of a /16 of IPv4 address space in a >> reserve for Critical Infrastructure, as defined in section 4.4. If at >> the end of the policy term there is unused address space remaining in >> this pool, ARIN staff is authorized to utilize this space in a manner >> consistent with community expectations. >> >> Rationale: >> >> Section 4.10 of the NRPM is insufficient with respect to insuring the >> continued operation of critical infrastructure. This proposal, if >> adopted, will protect those resources with a reasonable amount of >> reserved v4 address space and prevent an overrun of CI needs by NRPM >> Section 4.10 or any successor. The intent is to separate CI needs and >> make a distinct pool available to insure the continuity of CI >> allocations per NRPM Section 4.4 for at least 36 months. >> >> 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. >> *************************************************************************************** >> The information contained in this message, including attachments, may contain >> privileged or confidential information that is intended to be delivered only to the >> person identified above. If you are not the intended recipient, or the person >> responsible for delivering this message to the intended recipient, Windstream requests >> that you immediately notify the sender and asks that you do not read the message or its >> attachments, and that you delete them without copying or sending them to anyone else. >> _______________________________________________ >> 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 John.Kuhn at ontario.ca Mon May 2 14:26:39 2011 From: John.Kuhn at ontario.ca (Kuhn, John (MGS)) Date: Mon, 2 May 2011 14:26:39 -0400 Subject: [arin-ppml] ARIN-2011-3: Better IPv6 Allocations for ISPs last call In-Reply-To: Message-ID: <258C60971045264D8696361D3B7FD7FB027E91F0@CTSPITDCEMMVX24.cihs.ad.gov.on.ca> Team, While IPv6 is not IPv4 we should never the less take into consideration everything we have learned and develop Best Practices from Lessons Learned. I support this Policy. John Kuhn Break Through Technologies ESC MGS Government of Ontario ARIN-2011-3: Better IPv6 Allocations for ISPs Changes include: 1. Does not delete section 2.9 (request from staff, no impact on policy meaning) 2. Limits LIR recursion to a single level and limit subordinate LIRs to /32. (community concern) 3. Restores PAU to the calculation in 6.5.2.1(c) (from errata slide presented in meeting) 4. Preserves 2010-12 language in new 6.5.3.1 (from errata slide presented in meeting) 5. Preserves verbiage allowing ISPs to allocate to their own internal infrastructure in 6.5.4.1 (from errata slide presented in meeting) 6. Adds a statement to delete current NRPM 6.9 (from errata slide presented in meeting) 7. Adds language to limit initial allocations to no more than a /16 (6.5.2.1(b)) and to limit subsequent allocations to no larger than a /12 (an organization may apply for additional /12s, but, no single allocation larger than a /12 can be made at one time) (6.5.2.1(e)) (community concern) Feedback is encouraged during the last call period. All comments should be provided to the Public Policy Mailing List. Last call for 2011-3 will expire on 2 May 2011. 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-2011-3 Better IPv6 Allocations for ISPs Version/Date: 18 April 2011 Policy Statement: Amend section 2 as follows: Replace section 2.10 with the following: 2.10 The term End Site shall mean a single structure or service delivery address, or, in the case of a multi-tenant structure, a single tenant within said structure (a single customer location). Add the following: 2.12 When applied to IPv6 policies, the term serving site shall mean a location where an ISP terminates or aggregates customer connections, including, but, not limited to Points of Presence (POPs), Datacenters, Central or Local switching office or regional or local combinations thereof. 2.13 When applied to IPv6 policies, the term "provider assignment unit" shall mean the prefix of the smallest block a given ISP assigns to end sites (recommended /48). 2.14 The term utilized shall have the following definitions when applied to IPv6 policies: (i) A provider assignment unit shall be considered fully utilized when it is assigned to an end-site. (ii) Larger blocks shall have their utilization defined by dividing the number of provider assignment units assigned from the containing block by the total number of provider assignment units. This ratio will often be expressed as a percentage (e.g. a/t*100, for a /36 3072/4096 * 100 = 75% utilization) Replace sections 6.5.1 through 6.5.3 with the following: 6.5.1 Terminology (a) The terms ISP and LIR are used interchangeably in this document and any use of either term shall be construed to include both meanings. (b) The term nibble boundary shall mean a network mask which aligns on a 4-bit boundary (in slash notation, /n, where n is evenly divisible by 4, allowing unit quantities of X such that 2^n=X where n is evenly divisible by 4, such as 16, 256, 4096, etc.) 6.5.2 Initial Allocations to LIRs 6.5.2.1 Size (a) All allocations shall be made on nibble boundaries. (b) In no case shall an LIR receive smaller than a /32 unless they specifically request a /36. In no case shall an ISP receive more than a /16 initial allocation. (c) The maximum allowable allocation shall be the smallest nibble-boundary aligned block that can provide an equally sized nibble-boundary aligned block to each of the requesters serving sites large enough to satisfy the needs of the requesters largest single serving site using no more than 75% of the available addresses. This calculation can be summarized as /N where N = P-(X+Y) and P is the organization's Provider Allocation Unit X is a multiple of 4 greater than 4/3*serving sites and Y is a multiple of 4 greater than 4/3*end sites served by largest serving site. (d) For purposes of the calculation in (c), an end site which can justify more than a /48 under the end-user assignment criteria in 6.5.8 shall count as the appropriate number of /48s that would be assigned under that policy. (e) For purposes of the calculation in (c), an LIR which has subordinate LIRs shall make such allocations according to the same policies and criteria as ARIN. In such a case, the prefixes necessary for such an allocation should be treated as fully utilized in determining the block sizing for the parent LIR. LIRs which do not receive resources directly from ARIN will not be able to make such allocations to subordinate LIRs and subordinate LIRs which need more than a /32 shall apply directly to ARIN. (f) An LIR is not required to design or deploy their network according to this structure. It is strictly a mechanism to determine the largest IP address block to which the LIR is entitled. 6.5.2.2 Qualifications An organization qualifies for an allocation under this policy if they meet any of the following criteria: (a) Have a previously justified IPv4 ISP allocation from ARIN or one of its predecessor registries or can qualify for an IPv4 ISP allocation under current criteria. (b) Are currently multihomed for IPv6 or will immediately become multihomed for IPv6 using a valid assigned global AS number. In either case, they will be making reassignments from allocation(s) under this policy to other organizations. (c) Provide ARIN a reasonable technical justification indicating why an allocation is necessary. Justification must include the intended purposes for the allocation and describe the network infrastructure the allocation will be used to support. Justification must also include a plan detailing anticipated assignments to other organizations or customers for one, two and five year periods, with a minimum of 50 assignments within 5 years. 6.5.3 Subsequent Allocations to LIRs (a) Where possible ARIN will make subsequent allocations by expanding the existing allocation. (b) An LIR which can show utilization of 75% or more of their total address space, or more than 90% of any serving site shall be entitled to a subsequent allocation. (c) If ARIN can not expand one or more existing allocations, ARIN shall make a new allocation based on the initial allocation criteria above. The LIR is encouraged, but not required to renumber into the new allocation over time and return any allocations no longer in use. (d) If an LIR has already reached a /12 or more, ARIN will allocate a single additional /12 rather than continue expanding nibble boundaries. Renumber/move the second paragraph of existing section 6.5.2.1 to 6.5.3.1. For reference, this would become: 6.5.3.1 Subsequent Allocations for Transition Subsequent allocations will also be considered for deployments that cannot be accommodated by, nor were accounted for, under the initial allocation. Justification for the subsequent subnet size will be based on the plan and technology provided with a /24 being the maximum allowed for a transition technology. Justification for transitional allocations will be reviewed every 3 years and reclaimed if they are no longer in use for transitional purposes. All such allocations for transitional technology will be made from a block designated for this purpose. (This paragraph comes from 2010-12 which was adopted after this draft policy was written). Replace section 6.5.4 with the following 6.5.4 Assignments to end users shall be governed by the same practices adopted by the community in section 6.5.8 except that the requirements in 6.5.8.1 do not apply. 6.5.4.1 An LIR may assign up to a /48 per PoP as well as up to an additional /48 globally for its own infrastructure. Add the following to 6.5.7 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 provided that they agree to renumber into that new allocation and return their prior allocation(s) within 5 years. If possible, ARIN will simply expand their existing allocation rather than requiring renumber and return. Delete section 6.9 _______________________________________________ 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 information contained in this message, including attachments, may contain privileged or confidential information that is intended to be delivered only to the person identified above. If you are not the intended recipient, or the person responsible for delivering this message to the intended recipient, Windstream requests that you immediately notify the sender and asks that you do not read the message or its attachments, and that you delete them without copying or sending them to anyone else. ------------------------------ _______________________________________________ ARIN-PPML mailing list ARIN-PPML at arin.net http://lists.arin.net/mailman/listinfo/arin-ppml End of ARIN-PPML Digest, Vol 71, Issue 8 **************************************** -- Rudi Daniel danielcharles consulting 1-784 498 8277 -------------- next part -------------- An HTML attachment was scrubbed... URL: From farmer at umn.edu Mon May 2 14:28:17 2011 From: farmer at umn.edu (David Farmer) Date: Mon, 02 May 2011 13:28:17 -0500 Subject: [arin-ppml] Fw: Accusation of fundamental conflict ofinterest/IPaddress policy pitched directly to ICANN In-Reply-To: References: Message-ID: <4DBEF7C1.10502@umn.edu> On 5/2/11 11:48 CDT, Mike Burns wrote: >> Can you be more specific? The ICANN ASO? the ICANN BoT? the IANA? > > Hi Tim, > > Keep going, all the organizations above are suspect due to the fact that > they are all comprised of the same basic group of RIR designees. > > I would take it to NTIA like DNS. > > And I would use DNS as a template for the creation of the global policy > restrictions John Curran asked about, which restrictions would apply to > all registries, regional or commercial. > Just as all DNS registrars must meet certain qualifications, so would > private registries of number space. > > Let the NTIA hear arguments from the proposer and from the ASO, the > ICANN BoT, and IANA, although I suspect they will all sound the same. And why do you think the global Internet governance community will be happy with the DoC or NTIA (US Gov) being the arbiter of this situation? The global community wants the US Gov less directly in control of Internet, not more in control. It is in the interest of everyone involved the RIRs, IANA, ICANN, the majority of Legacy Address holders, and everyone who supports a free and open Internet for this to be resolved within the Internet industry self-governance frame work in this situation ICANN or maybe IETF. If we involve government regulators as more than just another stake-holder in the overall process, then I fear that ultimately the ITU will be put in charge. The ITU would not be a good body for anyone involved in this discussion to be the arbiter of this situation. An open discussion is necessary and the only way this is going to be resolved. If you don't think that it is a good idea to change the system with alternate registries or removal of the needs basis, you still need to respectively listen to the proponents of changing the system. And those that want to change the system, you need to provide reasoned proposals, arguments, and counter arguments, not just one or twice, but over and over. You are asking for big changes, if your changes are going to work you need a large portion of the community to accept your new ideas, this take time and hard work, but in the end the system what ever it ends up being will be better for it. I think most people realize that things are going to change, but I'm not sure we have a consensus on how to react to those changes and how the system will change to meet the new realities. -- =============================================== 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 istaff.org Mon May 2 14:42:47 2011 From: jcurran at istaff.org (John Curran) Date: Mon, 2 May 2011 20:42:47 +0200 Subject: [arin-ppml] ARIN-2011-4: Reserved Pool for Critical Infrastructure - Last Call In-Reply-To: References: <4DAC8B90.5070104@arin.net> Message-ID: Matt - For clarity: "I'm down with this" means you support it? Thanks! /John On May 2, 2011, at 8:01 PM, Matthew Petach wrote: > On Mon, Apr 18, 2011 at 12:05 PM, ARIN wrote: >> The ARIN Advisory Council (AC) met on 13 April 2011 and decided to >> send a revised version of the following draft policy to last call: >> >> ARIN-2011-4: Reserved Pool for Critical Infrastructure > > I'm down with this as written. > > Matt > _______________________________________________ > 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 2 14:43:27 2011 From: bill at herrin.us (William Herrin) Date: Mon, 2 May 2011 14:43:27 -0400 Subject: [arin-ppml] ARIN-prop-140 Business Failure Clarification In-Reply-To: <4DBEF0DF.8060800@arin.net> References: <4DBEF0DF.8060800@arin.net> Message-ID: On Mon, May 2, 2011 at 1:58 PM, ARIN wrote: > ARIN-prop-140 Business Failure Clarification > > Add to end of Section 8.1: "Note that an entity which is reorganizing > under any section of the US bankruptcy code (or foreign equivalent) is > not 'out of business' for the purpose of interpreting this section" > > Rationale: > > Potential confusion exists over the requirement to return address space > from a bankrupt entity. This is a needed clarification to the policy manual. Hi Matthew, If I understand properly, the language you object to in section 8.1 is: "Thus, if a company goes out of business, regardless of the reason, the point of contact (POC) listed for the number resource does not have the authority to sell, transfer, assign, or give the number resource to any other person or organization. The POC must notify ARIN if a business fails so the assigned number resources can be returned to the available pool of number resources if a transfer is not requested and justified." The main point of that paragraph is that if your company's network is terminated (as part of a general company shutdown) you, as the POC, don't get to keep the addresses as some kind of severance pay. Your suggested text frankly just muddies the waters further. I would suggest replacing "goes out of business" with "ceases operations" and just strike the last sentence entirely. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From Keith at jcc.com Mon May 2 14:49:44 2011 From: Keith at jcc.com (Keith W. Hare) Date: Mon, 2 May 2011 14:49:44 -0400 Subject: [arin-ppml] Accusation of fundamental conflict ofinterest/IPaddress policy pitched directly to ICANN In-Reply-To: <34A035C8AB3147919076CC4BB118C83B@mike> References: <4DBB208B.4060808@ipinc.net><112FF1070FFF4B7E957E13C757CCB513@vid eo><23B533DB44354E3EA201D0941C47C46C@video><861B310C-7502-49FE-BD13-3D1B123A57EB @delong.com><274D7568A828485B91D64F9308B3A24E@video> <9737f78a74367c4fde16e526d31442304dbec379@jcc.com> <40d2346a1b58436fb0387d165b0c7bee4dbed64a@jcc.com> <34A035C8AB3147919076CC4BB118C83B@mike> Message-ID: <03bbb072c4565685fb86a50e59d5178b4dbefc20@jcc.com> But what is it about ARIN that is broken? What exactly do you think needs to be fixed? The only thing I've gotten out of the discussions so far is that some people think there is money to be made by providing IPv4 addresses based on willingness and ability to pay rather than ARIN's current demonstrated need policies. Why is it to my benefit if someone else makes money? Particularly if it perturbs the current mechanisms in a way that costs me money? Keith Hare -----Original Message----- From: Mike Burns [mailto:mike at nationwideinc.com] Sent: Monday, May 02, 2011 12:13 PM To: Keith W. Hare; arin-ppml at arin.net Subject: Re: [arin-ppml] Accusation of fundamental conflict ofinterest/IPaddress policy pitched directly to ICANN I understand and appreciate that ARIN has faithfully fulfilled its stewardship role, and I am in the camp of don't fix what ain't broke. But times are changing, these issues are upon us because the promise of gradual transition has failed and the problem of exhaust has arrived. Some might say that public education has failed, and vouchers are a result of that failure, but that can be debated. What can't be debated is that the IPv6 transition has failed to proceed gracefully, and conflict over valuable resources are bound to occur. This issue seems to elicit analogies, and the analogies can take on a life and argument of their own, so I shall try to refrain from them in the future. Regards, Mike ----- Original Message ----- From: "Keith W. Hare" To: ; "Mike Burns" Sent: Monday, May 02, 2011 12:08 PM Subject: RE: [arin-ppml] Accusation of fundamental conflict ofinterest/IPaddress policy pitched directly to ICANN Mike, You wrote: The registry will stand or fall based on its performance in a competitive environment. The idea is similar to the concept of school vouchers. With school vouchers, you can take your child out of public school, and put him in private school. The public schools lose some money as the vouchers are created, just as ARIN may lose some registration fee revenue. The concept is that competitive pressures will be applied to the public resources which will increase the efficiency of the public schools, or in our case, the efficiency of the regional-monopoly-registry. As it happens, I've spent some amount of time looking at school funding in the rural Ohio school district where I live. My observations on the concepts of school vouchers and competition as a driver of school efficiency are: 1. While school vouchers may provide some benefit in urban areas with large student populations, they are of no benefit in rural areas. 2. At least in Ohio, school voucher programs have cost funding for rural school districts while providing no benefit to rural students. 3. The issues in public school districts are mostly not related to efficiency. So maybe your analogy is valid. >From my point of view, ARIN is operating very efficiently. I do not see how getting lawyers and "title" insurance involved is going to be more efficient -- any time I have to deal with a lawyer it costs me time and money. Keith Hare From mike at nationwideinc.com Mon May 2 14:49:08 2011 From: mike at nationwideinc.com (Mike Burns) Date: Mon, 2 May 2011 14:49:08 -0400 Subject: [arin-ppml] Fw: Accusation of fundamental conflict ofinterest/IPaddress policy pitched directly to ICANN References: <4DBEF7C1.10502@umn.edu> Message-ID: <6E43B70A4F6D410786DA078A424BF9FE@mike> Hi David, I appreciate what you are saying and I fear the ITU. It would be better if the decision to allow competing registries came from the community. But as the community's voice is currently heard, it is filtered through the very organizations which have a self-preservation component, and condensed down to a very small group of individuals whose names appear as members of the RIR boards, members of the ASO and the NRO. Essentially these are all the same people. Be that as it may, I am trying to participate in the process you describe, and I have expressed that the decisionmakers, whomever they are, should be presented with information from all sides. It's just that if we let ASO/NRO/RIRs decide, the decision is a foregone conclusion that would not appear impartial to me, anyway. Regards, Mike > And why do you think the global Internet governance community will be > happy with the DoC or NTIA (US Gov) being the arbiter of this situation? > The global community wants the US Gov less directly in control of > Internet, not more in control. > > It is in the interest of everyone involved the RIRs, IANA, ICANN, the > majority of Legacy Address holders, and everyone who supports a free and > open Internet for this to be resolved within the Internet industry > self-governance frame work in this situation ICANN or maybe IETF. If we > involve government regulators as more than just another stake-holder in > the overall process, then I fear that ultimately the ITU will be put in > charge. The ITU would not be a good body for anyone involved in this > discussion to be the arbiter of this situation. > > An open discussion is necessary and the only way this is going to be > resolved. If you don't think that it is a good idea to change the system > with alternate registries or removal of the needs basis, you still need to > respectively listen to the proponents of changing the system. And those > that want to change the system, you need to provide reasoned proposals, > arguments, and counter arguments, not just one or twice, but over and > over. You are asking for big changes, if your changes are going to work > you need a large portion of the community to accept your new ideas, this > take time and hard work, but in the end the system what ever it ends up > being will be better for it. > > I think most people realize that things are going to change, but I'm not > sure we have a consensus on how to react to those changes and how the > system will change to meet the new realities. > > -- > =============================================== > 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 > =============================================== Hi David, I appreciate what you are saying and I fear the ITU. It would be better if the decision to allow competing registries came from the community. But as the community's voice is currently heard, it is filtered through the very organizations which have a self-preservation component, and condensed down to a very small group of individuals whose names appear as members of the RIR boards, members of the ASO and the NRO. Essentially these are all the same people. Be that as it may, I am trying to participate in the process you describe, and I have expressed that the decisionmakers, whomever they are, should be presented with information from all sides. It's just that if we let ASO/NRO/RIRs decide, the decision is a foregone conclusion that would not appear impartial to me, anyway. Regards, Mike From scottleibrand at gmail.com Mon May 2 14:50:09 2011 From: scottleibrand at gmail.com (Scott Leibrand) Date: Mon, 2 May 2011 11:50:09 -0700 Subject: [arin-ppml] ARIN-prop-145 STLS Listing Immunity In-Reply-To: <4DBEF116.1000400@arin.net> References: <4DBEF116.1000400@arin.net> Message-ID: On Mon, May 2, 2011 at 10:59 AM, ARIN wrote: > ARIN-prop-145 STLS Listing Immunity > > Add a subsection to Section 12 (Resource Review) of the NRPM: > > ARIN may not revoke any resources issued by ARIN that are presently > listed as "available" on the ARIN Specified Transfer Listing Service > unless there is sufficient reason to believe that the holder does not in > fact intend to transfer these resources. > Another way to accomplish this would be with the following language from the original transfer policy proposal, 2008-2: The fact that an IPv4 address holder is making IPv4 addresses available for transfer, pursuant to this policy, does not, in and of itself, indicate that the address holder lacks the need required for an allocation under ARIN policy. > > Rationale: > > An entity may list space as available and might begin the process of > moving out of that space in order to facilitate the transfer. A review > after such work was in progress might reveal that the addresses are not > sufficiently utilized. > > Additionally, because posting a listing on the STLS signals directly to > ARIN that an entity believes it can use addresses more efficiently, ARIN > might simply use STLS listings in order to trigger audit under 12.2(c). > This would not be fair. (And would be a disincentive to using the ARIN > STLS at all in order to list available space) > I believe that ARIN has made assurances that this will not be done, but I would support such assurances into policy as well if people think it's needed. This policy would also serve to increase the value of the ARIN STLS over > other possible transfer listing services, increasing the transparency of > the transfer market, particularly to ARIN, who wishes to ensure that > transfers take place within NRPM 8.3. > > I think it's important to make any "Safe Harbor" statement apply to all IPv4 addresses being made available for transfer (including those on eBay etc.) not just those offered through ARIN's Specified Transfer Listing Service. ARIN has repeatedly made clear that the STLS is completely optional, which I believe is the right way to approach it. I don't believe we should be giving the STLS preferential treatment in the transfer policy in any way. -Scott P.S. Thanks for all the straightforward, well-thought-out proposals. -------------- next part -------------- An HTML attachment was scrubbed... URL: From v6ops at globis.net Mon May 2 14:53:52 2011 From: v6ops at globis.net (Ray Hunter) Date: Mon, 02 May 2011 20:53:52 +0200 Subject: [arin-ppml] Accusation of fundamental conflict ofinterest/IPaddress policy pitched directly to ICANN In-Reply-To: References: <4DBEE79C.6030007@globis.net> Message-ID: <4DBEFDC0.3070705@globis.net> No one owns the addresses today. They're just 32 bit numbers. That's all. Nothing more. Nothing less. No one ever owned the addresses. They have zero intrinsic value. The only reason they are perceived as having any value today is the fact that several million Internet users all around the globe have consented to respect ICANN (and in turn the RIRs) coordination of IPv4 address allocation in order to make those 32 bit numbers globally unique, and we can't manufacture any more numbers. As I stated, today's Internet is consensus-based. I repeat the word "consensus." Should I say that again? Maybe not. I think you get the idea though. China Telecom and China Mobile accept the authority of ICANN, just like everyone else. They have by far the biggest user base, and yet they also have the smallest allocations (relatively speaking). Likewise, not for profit, educational institutions, and governments also respect the authority of ICANN. If you or anyone else would like to start up a private commercial IPv4 registry to register IPv4 addresses that are globally unique for connection to a Global Private Commercial IPv4 Internet, I don't think anyone will stop you. They may even encourage it to take the pressure off the Public Internet. One simple reality is that some regions and countries have far higher allocation rates of IPv4 addresses per head of population than others. The US has 41% of current IPv4 address allocations = 5.5 addresses per head of population. See http://www.bgpexpert.com/addressespercountry.php for details. There are going to be an awful lot of people crying "foul," especially if this market mechanism is only applied internally at ARIN level (which relatively speaking has the highest allocation rate per head of population in the World). Where's their fair share? I therefore find it highly unlikely that you, or I, or anyone else, will ever ever gain consensus from the majority of current IPv4 Internet users that in order to remain connected to the Public Internet, or to grow their user base, they have to participate in a commercial market to obtain the right to be allocated an IPv4 address (whilst most users in some countries have already been allocated one or more "for free" on an "as-needed" basis). Any attempt to impose a commercial market on IPv4 addresses will very likely result in the destruction of the general consensus that made the Public Internet possible, and thus risk fragmentation or even destruction of the Public Internet. In other words, attempting to extract any monetary value from the scarcity of the IPv4 address space is likely going to completely destroy the value of the Public IPv4 Internet, without ensuring any (smooth) transition to a single global Public IPv6 Internet. As for the discussion on a (financial) incentive to move to IPv6: Seven alternatives straight off the top of my head that would achieve a similar effect of adding a strong incentive to migrate to IPv6 would be: 1) adopting an open market for IPv4 addresses 2) CGN. It's going to be so awful that it will become the IPv6 killer app. 3) The US Federal government mandates it. If you want to do business with them then you're going to comply. This is also already true in India and China too. 4) Ask Ben Bernanke to divert a small amount of money from the various Federal Reserve's Open Market Operations schemes to buy up any IPv4 addresses that hit the market to create artificial scarcity and drive up prices. 5) The IETF could deprecate RFC 791 and move it to historic status. 6) Allocate the last few IPv4 unallocated addresses and declare "game over" 7) Ask ARIN to prevent any and all transfers that are motivated purely by financial gain, and instead insist that such participants return IPv4 allocations to the unallocated pool "for their benefit of the Internet Community" once the existing allocation is no longer needed. IMVHO 7) would be consistent with the historical policies of "allocation on an as-needed basis" and would not require any significant change to policy. I'm not attempting to influence the decision of the ARIN community in any one particular direction, but the "free marketeers" certainly do not have a monopoly on ideas, and I personally doubt whether a market based approach is any more practical than the alternatives, no matter how crazy they sound. regards, RayH Mike Burns wrote: > > >The point being that globally unique IPv4 addresses will only have > value to a corporation whilst the majority of their target customers > continue to use them as on today's consensus-based Internet. > > >If all of your customers have migrated to IPv6, they're worthless > > >If the IPv4 Internet has fragmented, they're worthless. > > >Is it 100% clear to everyone who actually "owns" all of the current > IPv4 address allocations today? > > >Also, the future of the Internet is clearly mobile. There are already > about as many mobile Internet users in China as there are people in > the US, if not more. Same story in India. Even in the US, there simply > won't be >enough IPv4 addresses to cover a mass move to mobile devices > no matter how much you're prepared to pay for them. > > >So assuming that any semblance of an efficient market in globally > unique IPv4 numbers can be created now is IMHO highly questionable. > > >Ray Hunter > Hi Ray, > I'm sorry but I don't see how the prior statements lead to the > conclusion that an efficient market in globally unique IPv4 numbers > can not now be created. > Is it because there is confusion over who actually "owns" the current > IPv4 allocations today? > Because that goes right to the issues with whois veracity that I think > will be improved with competing registries, and is likely to improve > anyway, as IP address values are understood and claims are made. > Yes, IPv4 addresses only have value if customers use them on the > Internet. Yes, if all customers migrate to IPv6, they are worthless, > and yes, if the IPv4 is fragmented to the point of non-usability, they > are worthless. > Yes, there will be continued demand for addresses that will be larger > than can be accomodated if by the IPv4 pool, if the Internet retains > it's current single-level NAT architecture. > But I don't see how the conclusion that a viable market cannot be > created follows from your statements, though.Some have posted that > the market will provide incentive to transition that is otherwise > lacking, a problem described way back by a prescient John Curran over > 15 years ago. > http://www.armware.dk/RFC/rfc/rfc1669.html > Certainly you have elucidated risks to those who participate in those > markets, but those risks will presumably be known to participants, and > presumably were known to Microsoft before they paid $7.5 million. > Regards, > > Mike Burns -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill at herrin.us Mon May 2 14:57:25 2011 From: bill at herrin.us (William Herrin) Date: Mon, 2 May 2011 14:57:25 -0400 Subject: [arin-ppml] ARIN-2011-4: Reserved Pool for Critical Infrastructure - Last Call In-Reply-To: <4DAC8B90.5070104@arin.net> References: <4DAC8B90.5070104@arin.net> Message-ID: On Mon, Apr 18, 2011 at 3:05 PM, ARIN wrote: > Draft Policy ARIN-2011-4 > Reserved Pool for Critical Infrastructure > > Version/Date: 16 Feb 2011 > > Policy term: 36 Months following implementation > > Policy statement: > > ARIN will place an equivalent of a /16 of IPv4 address space in a > reserve for Critical Infrastructure, as defined in section 4.4. If at > the end of the policy term there is unused address space remaining in > this pool, ARIN staff is authorized to utilize this space in a manner > consistent with community expectations. I support this draft policy as written. 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 2 14:52:15 2011 From: bill at herrin.us (William Herrin) Date: Mon, 2 May 2011 14:52:15 -0400 Subject: [arin-ppml] ARIN-prop-144 Remove Single Aggregate requirement from Specified Transfer In-Reply-To: <4DBEF10B.50902@arin.net> References: <4DBEF10B.50902@arin.net> Message-ID: On Mon, May 2, 2011 at 1:59 PM, ARIN wrote: > ARIN-prop-144 Remove Single Aggregate requirement from Specified Transfer > Proposal Originator: Matthew Kaufman > > Modify Section 8.3 as follows: > Change "can demonstrate the need for such resources, as a single > aggregate, in the exact amount which they can justify under current ARIN > policies" to "can demonstrate the need for such resources in the amount > which they can justify under current ARIN policies" Hi Matthew, IIRC, the source of that gobbledygook was that we didn't want folks splitting up aggregates and selling them off piecemeal. Unless we can find consensus on a better way to word that requirement, I would support the offered change. 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 2 14:59:59 2011 From: owen at delong.com (Owen DeLong) Date: Mon, 2 May 2011 11:59:59 -0700 Subject: [arin-ppml] New Entrants shut out? (Was: ARIN-2011-5: ... - Last Call In-Reply-To: References: <4DBAF9E2.80000@globis.net> <4DBB305F.3010205@umn.edu> <4DBB41AE.20007@ipinc.net> <412B69ED-0D49-4F1A-806C-4F250C64EAED@delong.com> <07C619E6-58E3-41FF-81EC-6BA23BDA7391@delong.com> <35A3C7E4-5FA6-46BE-B14C-E2F97579CE8D@delong.com> <79CCE0F1-EF17-495B-AC28-9495052013EB@delong.com> Message-ID: <92CDFD35-7489-4037-A8C7-1CB344A9F091@delong.com> On Apr 30, 2011, at 12:50 PM, Jeffrey Lyon wrote: > On Sat, Apr 30, 2011 at 3:28 PM, Owen DeLong wrote: >> >> >> Jimmy, >> >> At the moment we have a system that favors small players at the >> expense of commerce. It also fails to create economic incentives to >> migrate to IPv6. Note that C-Squad execs speak dollars, not value to >> the community. >> >> I would argue that the current system appears to be creating quite a few >> incentives to add IPv6 capabilities if you look at the current uptick in v6 >> statistics since Feb. 3. >> >> So long as we continue to squeeze blood out of the IPv4 turnip, >> companies will continue to delay IPv6. The choices become the Lyon >> strategy of letting the market set the price and encourage natural >> migration, or the Owen strategy of taking IPv4 off life support. >> >> I don't think it is on life support and I think a natural evolution is >> occurring. Some organizations which are unable to look beyond short term >> dollars will have faster and more disruptive migration processes while >> others with better vision have been planning and executing their migration >> strategies for years. >> The longer you wait, the more rushed, expensive, and disruptive your >> inevitable transition will be. >> Owen >> > > Owen, > > I agree that there are some incentives to migrate to IPv6 and that > companies who wait will suffer. My point is that these incentives are > not economic in nature which is what will be necessary to motivate > companies to act. Companies are the driving force behind either > creating or removing roadblocks to adoption (eg. carrier support, > vendor support, and so forth). > I will say that not ALL incentives are economic in nature. However, the economy of failing to implement IPv6 is a pretty strong incentive if you fully understand the results. Becoming increasingly disconnected from more and more of your potential customer base should, for any rational business, create a strong economic incentive to do something different. That is the inevitable result of remaining IPv4-only. Further, the costs at the carrier and the subscriber level of continuing to attempt to maintain some level of connectivity to a growing internet incapable of producing additional IPv4 addresses for those new connections will significantly increase the costs of remaining on IPv4 and keeping it functional. These costs are only increased by failing to add IPv6 capabilities. > I fundamentally disagree that we should taking the position of > "migrate now or suffer later," rather create the economic incentive > for a natural progression to IPv6 without having to twist any arms or > cause any suffering. > Huh? 1. I think that migrate now is a misnomer. What I am saying is "Add IPv6 capabilities to your network now, or, you will, inevitably suffer later." That's not to say I am trying to cause that suffering or that anyone is out to inflict additional suffering on those who fail to add IPv6 capabilities. The NATURAL CONSEQUENCE of failing to adapt to a changing and growing internet is suffering. It will happen to those that do not add IPv6 capabilities no matter what anyone else does or does not do. 2. There is already a great deal of economic incentive there for anyone who takes the time to understand the economics of the situation. IPv4 will inevitably become increasingly more costly. This policy is intended to allow a single /10 to be used for purposes that will otherwise require multiple providers to collectively use much more than one /10 and will ultimately result in accelerating the time at which IPv4 becomes more expensive and accelerating and increasing the resulting suffering. > Very rarely are technologies widely adopted on account of a decree. > Successful adoption occurs when migrating to a new technology is an > all around attractive prospect. I would be willing to hypothesize that > there are about equal numbers of people who want immediate adoption of > IPv6 and those who want to see IPv4 continue to survive for a number > of years, at least until IPv6 can gain a more stable footing. > I think I can say that almost everyone wishes that IPv4 could continue to survive for many more years. I wish that were true. I think, instead, you can say that there is some disagreement among professionals as to whether this is actually a viable strategy or not. I don't know of anyone among the IPv6 cheerleading crowd (and I'm pretty sure I have about as much of an IPv6 cheerleader perspective as anyone) who wouldn't love to see a way for IPv4 to provide a real solution to continued growth in the internet without the disruption or inconvenience or costs of deploying a new protocol. The difference comes in the subtlety of what people are willing to accept as a "real solution". Some of us want to see the internet continue to be able to provide at least the services and capabilities that exist today. Some are willing to accept a greatly reduced subset. Some of us want to see expansion and continued innovation. For the first camp (existing capabilities), IPv4 has a very limited lifespan, but, until the RIRs all run out and maybe even for a few months thereafter, we can kind of limp along and keep that somewhat functional. For the second camp, there is NAT444 and if you are willing to reduce the internet to basic HTTP/HTTPs and SMTP and little else, then, you can probably keep IPv4 somewhat serviceable for a few more years. Finally, for the third camp, there really is no remaining viability in IPv4. The end-to-end model failed with the introduction of NAT. The peer to peer nature has been reduced to the consumer/provider model as a result and services which people want (remote access to resources at home, for example) have to involve rendezvous servers hosted by other providers to be made possible. There are so many cool things that we already know how to do and have the technology for that cannot be implemented for lack of end-to-end connections that I think there is additional economic incentive available here as well. Indeed, the question is not whether or not IPv6 has economic incentives. The question is how to best explain and convey those economic incentives to the CxOs of the world. In the meantime, this policy seeks to provide a way that many providers can coordinate their use of a very limited amount of IPv4 space for a specific purpose rather than requiring each of them to get their own distinct space for this purpose. Owen From owen at delong.com Mon May 2 15:00:36 2011 From: owen at delong.com (Owen DeLong) Date: Mon, 2 May 2011 12:00:36 -0700 Subject: [arin-ppml] Microsoft receives court approval for transfer asagreed with ARIN In-Reply-To: References: <94030.1304191624@tristatelogic.com> <2F1F43FA-8724-4298-89C3-76ABEA5A3AAF@delong.com> Message-ID: >> > > Owen, > > Could the annual fee be something like $100/yr versus $1250 and up? For LRSA signatories it already is $100/year. Owen From jcurran at arin.net Mon May 2 15:07:09 2011 From: jcurran at arin.net (John Curran) Date: Mon, 2 May 2011 19:07:09 +0000 Subject: [arin-ppml] ARIN-prop-140 Business Failure Clarification In-Reply-To: <4CF8BEEF-4CFB-4EB6-B395-9CB1CEF8326B@matthew.at> References: <11050210594687_A4@oregon.uoregon.edu> <4CF8BEEF-4CFB-4EB6-B395-9CB1CEF8326B@matthew.at> Message-ID: <8D906FB6-D0FF-4106-88AE-6B12AB7CAD35@arin.net> On May 2, 2011, at 8:20 PM, Matthew Kaufman wrote: > ... > I'm not a bankruptcy attorney either... this might need discussion. As part of trying to get staff input into the process earlier (as discussed earlier in the week on this list), please note: 1) The policy proposal suggests "Potential confusion exists over the requirement to return address space from a bankrupt entity. This is a needed clarification to the policy manual" whereas this language has not resulted in any actual confusion for ARIN staff. 2) ARIN must handle bankruptcies in compliance with appropriate law; encoding a specific legal approach within policy is both ill-advised and inconsistent with the Policy Development Process which states that ARIN business practices are not policy matters. Thanks, /John John Curran President and CEO ARIN From mike at nationwideinc.com Mon May 2 15:09:24 2011 From: mike at nationwideinc.com (Mike Burns) Date: Mon, 2 May 2011 15:09:24 -0400 Subject: [arin-ppml] Accusation of fundamental conflict ofinterest/IPaddresspolicy pitched directly to ICANN References: <4DBEE79C.6030007@globis.net> <4DBEFDC0.3070705@globis.net> Message-ID: <96AF0FBE0B5A40CFB80A34CA2FF86FCA@mike> ----- Original Message ----- From: Ray Hunter To: Mike Burns Cc: arin-ppml at arin.net Sent: Monday, May 02, 2011 2:53 PM Subject: Re: [arin-ppml] Accusation of fundamental conflict ofinterest/IPaddresspolicy pitched directly to ICANN No one owns the addresses today. They're just 32 bit numbers. That's all. Nothing more. Nothing less. No one ever owned the addresses. They have zero intrinsic value. Ray, That train has left the station. Nortel sold addresses to Microsoft for $7.5 million. Addresses which have been allocated very obviously have a value different from a random string of 32 bit numbers. You can argue that they shouldn't, you can argue that correct stewardship would be to establish policies to kill IPv4 and thus transition more swiftly. But you can't argue that they have zero value. Regards, Mike -------------- next part -------------- An HTML attachment was scrubbed... URL: From owen at delong.com Mon May 2 15:13:18 2011 From: owen at delong.com (Owen DeLong) Date: Mon, 2 May 2011 12:13:18 -0700 Subject: [arin-ppml] Accusation of fundamental conflict of interest/IPaddress policy pitched directly to ICANN In-Reply-To: <274D7568A828485B91D64F9308B3A24E@video> References: <4DBB208B.4060808@ipinc.net> <112FF1070FFF4B7E957E13C757CCB513@video> <23B533DB44354E3EA201D0941C47C46C@video> <861B310C-7502-49FE-BD13-3D1B123A57EB@delong.com> <274D7568A828485B91D64F9308B3A24E@video> Message-ID: <1EA5AF3B-EE53-4D0B-8F2E-E011A4397497@delong.com> On Apr 30, 2011, at 1:48 PM, Mike Burns wrote: >> What higher organizational level? > >> The Number Resource Organization and Address Supporting Organization roles at the IANA are the collective committee of representatives from the 5 RIRs. >Global address policy results from the same policy being passed by all RIRs and then ratified (a formality) at the IANA level. The "higher level organization" is >completely and directly controlled by the RIRs, as it should be. > >> Owen > > I think you misconstrue the relationship and have the tail wagging the dog. > ICANN/IANA is the entity that delegated the roles you describe, the NRO and ASO roles, to committees which are run by representatives from the RIRs. > Sort of... > "The Internet Assigned Numbers Authority (the IANA), as part of the administrative functions associated with management of the Internet Protocol (IP) address space, is responsible for evaluating applications for approval of new Regional Internet Registries. " > Look again at the header for the ICP-2 Document (emphasis mine): IMPORTANT NOTICE. The following Internet Coordination Policy is being posted for the information of the Internet community. It contains a statement of policy followed by the Internet Assigned Numbers Authority (IANA) in administering the system for allocation and assignment of Internet Protocol (IP) addresses. This document was developed through ICANN's Address Supporting Organization (ASO) with the assistance of APNIC, ARIN, and RIPE NCC, was recommended by the ASO's Address Council, and on 4 June 2001 was accepted by the ICANN Board of Directors as a statement of essential requirements for the recognition of new Regional Internet Registries (RIRs), in supplementation to section 9 of the ASO-Memorandum of Understanding, and acknowledged it as a framework for consideration of applications for recognition of new RIRs. Comments on this document are welcome and should be directed to comments at icann.org. Note the emphasized phrase... The document was developed through the ASO (a committee of the RIRs) and was recommended by the ASOs AC (a committee of representatives elected BY the RIR communities). The number resource administration portion of IANA is governed entirely by the RIRs and that is, as I said, the proper bottom-up way things should be managed. > All I am saying is that although this is not a new "regional" registry, it is a registry which could compete with the RIRs, and why not have IANA decide, since the representatives of the RIRs may have a vested interest in "regional-only" self-preservation which would affect their votes? > Again, what part of IANA would you have decide? IMHO, this would have to rest in the NRO. See also: http://www.icann.org/en/aso/aso-mou-29oct04.htm The NRO (Number Resource Organization) which is a forum of the 5 RIRs is given the role of the ASO as defined in the ICANN charter. The ASO (Address Supporting Organization) is essentially fully autonomous with ICANN under the above referenced document. There is no authority at ICANN to override the RIRs collective decisions. > I have nothing against the RIRs being heard and their case presented, but if their decision is dispositive, it appears as if the fox is guarding the henhouse. > I disagree with your characterization of the RIRs as a fox. In reality, the above referenced documents make it quite clear that the process is governed by the bottom-up community-consenus policy process. You can make changes to any global policy and such changes could override the MOU and/or the ICP-2 document. However, to make those changes, you must acquire community consensus for them in each of the 5 RIRs as a global policy proposal. Much like getting an amendment to the US constitution requires ratification by 2/3rds of the state legislatures. To me, this seems right and good. Owen -------------- next part -------------- An HTML attachment was scrubbed... URL: From owen at delong.com Mon May 2 15:24:52 2011 From: owen at delong.com (Owen DeLong) Date: Mon, 2 May 2011 12:24:52 -0700 Subject: [arin-ppml] Analogies In-Reply-To: References: <39209.1303885464@tristatelogic.com> <75822E125BCB994F8446858C4B19F0D7173057C827@SUEX07-MBX-04.ad.syr.edu> <471D76419F9EF642962323D13DF1DF69011E5C@newserver.arneill-py.local> <7348D3C8-4EB7-4440-A152-210CC8B0DA3C@arin.net> <471D76419F9EF642962323D13DF1DF69011E60@newserver.arneill-py.local> <583A067A-B8AE-4026-844E-6769D1D7CF88@arin.net> <471D76419F9EF642962323D13DF1DF69011E61@newserver.arneill-py.local> <7DF2A1C4-1799-486B-A631-2E1119C22A7C@arin.net> <3CCC6D1F-11F4-40BC-B102-CC6744A5E709@virtualized.org> <4DB9BACE.6000307@ipinc.net> <0E134D8B-0A4B-466E-B261-9C7D0ED11867@virtualized.org> <388190E3-08F2-4AC7-870A-621A2FD6EEFE@virtualized.org> Message-ID: <2ABCF380-7866-4ED8-BE43-C789CBEBFE27@delong.com> On Apr 30, 2011, at 5:39 PM, William Herrin wrote: > On Sat, Apr 30, 2011 at 1:31 AM, Owen DeLong wrote: >> I will point out that ARIN is the only registry that did not start >> charging their legacy holders shortly after coming into existence. >> >> APNIC, RIPE, AfriNIC, and LACNIC all charge their legacy holders >> annual fees to the best of my knowledge. >> >> I do not know whether a contract was required in any or all cases, >> but, the fee portion of the equation is unique to ARIN to the best >> of my knowledge. > > Hi Owen, > > I will suggest that an attempt by ARIN to charge $100/year under a > contract simplified to, "We agree to keep your whois data and RDNS > delegations intact as is for one year increments until either of us > choose to cancel this contract" would meet with at most mild > resistance from the legacy registrants. It would also, IMHO, provide > an excellent way to weed out the abandoned registrations. > That seems like a reasonable summary of the current LRSA. > This hasn't been done in part because we, in this forum, have insisted > that legacy registrants should not be invited into the fold under such > terms. > Huh? It seems to me that is exactly what we have done with the LRSA, so, I am confused by your statement. Owen From owen at delong.com Mon May 2 15:20:33 2011 From: owen at delong.com (Owen DeLong) Date: Mon, 2 May 2011 12:20:33 -0700 Subject: [arin-ppml] Internet 101: Collaboration (was - Microsoft receives court approval for transfer as agreed with ARIN) In-Reply-To: References: <7EB32A4E-DDE3-417F-926E-F4A3D90A893E@virtualized.org> Message-ID: <716F0219-7439-48C2-858E-98A422C9F122@delong.com> On Apr 30, 2011, at 3:27 PM, Chris Grundemann wrote: > On Thu, Apr 28, 2011 at 20:06, David Conrad wrote: >> Chris, >> >> On Apr 28, 2011, at 11:02 AM, Chris Grundemann wrote: >>> The Internet is an exercise in collaboration. >> >> Exactly. Which is why "the ARIN community" (which, just to remind you, consists of maybe a couple of hundred technical folks, a tiny fraction of which participate actively) > > Actually, the ARIN community consists explicitly of everyone within > the ARIN region (including, but not limited to, legacy address > holders) and implicitly of anyone in the world who wishes to > participate. > Technically, you don't have to be within the ARIN region to participate in the ARIN community. For example, I live and work in the US. However, I am an active participant in the ARIN, APNIC, and AfriNIC communities for policy development. I am a less active participant in RIPE and LACNIC communities as well. However, I consider myself part of each of those communities and my input into their policy process(es) has always been welcomed. Anyone who is not involved in any RIR policy process is not involved of their own choosing or because they are unaware of their ability to get involved. I am all for making it better known that people can get involved in the process. I am not for overriding or destroying the process because of some fictional claim that people cannot be involved. >> deciding unilaterally not to collaborate with legacy holders by attempting to force them to submit themselves to a policy regime that goes against their interests, is in my estimation unlikely to be successful. > > I obviously did not make myself clear, let me try again: Fragmentation > and balkanization of the Internet is against the interests of all who > use the Internet (including, but not limited to, legacy address > holders). > Agreed. I think there is a good middle ground to be had. I believe that the LRSA is good middle ground once it is properly understood. It actually grants to legacy holders significantly more rights than most RSA signatories and protects and preserves that status even in the face of overwhelming community consensus to the contrary. Absent such an agreement, legacy holders have only the rights and services from ARIN that the community chooses to tolerate. I would oppose ARIN engaging in any sort of disruptive or punitive measures against legacy registrations even those that have not signed the LRSA, but, I am just one voice. After IPv4 free pool runout, the overall sentiment of the community may be less calm in relation to legacy holders and I think they could face real risks. Owen From mike at nationwideinc.com Mon May 2 15:30:47 2011 From: mike at nationwideinc.com (Mike Burns) Date: Mon, 2 May 2011 15:30:47 -0400 Subject: [arin-ppml] Accusation of fundamental conflict of interest/IPaddress policy pitched directly to ICANN References: <4DBB208B.4060808@ipinc.net> <112FF1070FFF4B7E957E13C757CCB513@video> <23B533DB44354E3EA201D0941C47C46C@video> <861B310C-7502-49FE-BD13-3D1B123A57EB@delong.com> <274D7568A828485B91D64F9308B3A24E@video> <1EA5AF3B-EE53-4D0B-8F2E-E011A4397497@delong.com> Message-ID: <96228BA36D5948208E79184A5D1C0D6A@mike> Owen, The salient point was that the document was accepted by the ICANN Board of Directors. My reading of this is that while the ASO recommended a policy, it was decided by ICANN. You may call that a formality, but to me the relevant positions of authority are clear. I grant that it would appear better to the world community if the decision were made with expressed community support. Perhaps, as I suggested earlier, both IETF and DoC should be involved in the decision. But to ask the RIRs whether to dilute their position by allowing private competing registries is a question asked and answered. Regards, Mike ----- Original Message ----- From: Owen DeLong To: Mike Burns Cc: John Curran ; arin-ppml at arin.net Sent: Monday, May 02, 2011 3:13 PM Subject: Re: [arin-ppml] Accusation of fundamental conflict of interest/IPaddress policy pitched directly to ICANN On Apr 30, 2011, at 1:48 PM, Mike Burns wrote: What higher organizational level? The Number Resource Organization and Address Supporting Organization roles at the IANA are the collective committee of representatives from the 5 RIRs. >Global address policy results from the same policy being passed by all RIRs and then ratified (a formality) at the IANA level. The "higher level organization" is >completely and directly controlled by the RIRs, as it should be. Owen I think you misconstrue the relationship and have the tail wagging the dog. ICANN/IANA is the entity that delegated the roles you describe, the NRO and ASO roles, to committees which are run by representatives from the RIRs. Sort of... "The Internet Assigned Numbers Authority (the IANA), as part of the administrative functions associated with management of the Internet Protocol (IP) address space, is responsible for evaluating applications for approval of new Regional Internet Registries. " Look again at the header for the ICP-2 Document (emphasis mine): IMPORTANT NOTICE. The following Internet Coordination Policy is being posted for the information of the Internet community. It contains a statement of policy followed by the Internet Assigned Numbers Authority (IANA) in administering the system for allocation and assignment of Internet Protocol (IP) addresses. This document was developed through ICANN's Address Supporting Organization (ASO) with the assistance of APNIC, ARIN, and RIPE NCC, was recommended by the ASO's Address Council, and on 4 June 2001 was accepted by the ICANN Board of Directors as a statement of essential requirements for the recognition of new Regional Internet Registries (RIRs), in supplementation to section 9 of the ASO-Memorandum of Understanding, and acknowledged it as a framework for consideration of applications for recognition of new RIRs. Comments on this document are welcome and should be directed to comments at icann.org. Note the emphasized phrase... The document was developed through the ASO (a committee of the RIRs) and was recommended by the ASOs AC (a committee of representatives elected BY the RIR communities). The number resource administration portion of IANA is governed entirely by the RIRs and that is, as I said, the proper bottom-up way things should be managed. All I am saying is that although this is not a new "regional" registry, it is a registry which could compete with the RIRs, and why not have IANA decide, since the representatives of the RIRs may have a vested interest in "regional-only" self-preservation which would affect their votes? Again, what part of IANA would you have decide? IMHO, this would have to rest in the NRO. See also: http://www.icann.org/en/aso/aso-mou-29oct04.htm The NRO (Number Resource Organization) which is a forum of the 5 RIRs is given the role of the ASO as defined in the ICANN charter. The ASO (Address Supporting Organization) is essentially fully autonomous with ICANN under the above referenced document. There is no authority at ICANN to override the RIRs collective decisions. I have nothing against the RIRs being heard and their case presented, but if their decision is dispositive, it appears as if the fox is guarding the henhouse. I disagree with your characterization of the RIRs as a fox. In reality, the above referenced documents make it quite clear that the process is governed by the bottom-up community-consenus policy process. You can make changes to any global policy and such changes could override the MOU and/or the ICP-2 document. However, to make those changes, you must acquire community consensus for them in each of the 5 RIRs as a global policy proposal. Much like getting an amendment to the US constitution requires ratification by 2/3rds of the state legislatures. To me, this seems right and good. Owen -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike at nationwideinc.com Mon May 2 15:32:28 2011 From: mike at nationwideinc.com (Mike Burns) Date: Mon, 2 May 2011 15:32:28 -0400 Subject: [arin-ppml] ARIN-prop-145 STLS Listing Immunity References: <4DBEF116.1000400@arin.net> Message-ID: Scott, I think these are excellent ideas and that they will serve to free up addresses for transfer by reducing fear of ARIN. Particularly extending the safe harbor to all sales venues. What would free up even more addresses is a total elimination of needs analyses for all transfers. ;-) Although needs analyses are still required, I support your changes as they move policy in the right direction. Regards, Mike ----- Original Message ----- From: Scott Leibrand To: ARIN-PPML List Sent: Monday, May 02, 2011 2:50 PM Subject: Re: [arin-ppml] ARIN-prop-145 STLS Listing Immunity On Mon, May 2, 2011 at 10:59 AM, ARIN wrote: ARIN-prop-145 STLS Listing Immunity Add a subsection to Section 12 (Resource Review) of the NRPM: ARIN may not revoke any resources issued by ARIN that are presently listed as "available" on the ARIN Specified Transfer Listing Service unless there is sufficient reason to believe that the holder does not in fact intend to transfer these resources. Another way to accomplish this would be with the following language from the original transfer policy proposal, 2008-2: The fact that an IPv4 address holder is making IPv4 addresses available for transfer, pursuant to this policy, does not, in and of itself, indicate that the address holder lacks the need required for an allocation under ARIN policy. Rationale: An entity may list space as available and might begin the process of moving out of that space in order to facilitate the transfer. A review after such work was in progress might reveal that the addresses are not sufficiently utilized. Additionally, because posting a listing on the STLS signals directly to ARIN that an entity believes it can use addresses more efficiently, ARIN might simply use STLS listings in order to trigger audit under 12.2(c). This would not be fair. (And would be a disincentive to using the ARIN STLS at all in order to list available space) I believe that ARIN has made assurances that this will not be done, but I would support such assurances into policy as well if people think it's needed. This policy would also serve to increase the value of the ARIN STLS over other possible transfer listing services, increasing the transparency of the transfer market, particularly to ARIN, who wishes to ensure that transfers take place within NRPM 8.3. I think it's important to make any "Safe Harbor" statement apply to all IPv4 addresses being made available for transfer (including those on eBay etc.) not just those offered through ARIN's Specified Transfer Listing Service. ARIN has repeatedly made clear that the STLS is completely optional, which I believe is the right way to approach it. I don't believe we should be giving the STLS preferential treatment in the transfer policy in any way. -Scott P.S. Thanks for all the straightforward, well-thought-out proposals. ------------------------------------------------------------------------------ _______________________________________________ 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 mike at nationwideinc.com Mon May 2 15:33:43 2011 From: mike at nationwideinc.com (Mike Burns) Date: Mon, 2 May 2011 15:33:43 -0400 Subject: [arin-ppml] Accusation of fundamental conflict ofinterest/IPaddress policy pitched directly to ICANN References: <4DBB208B.4060808@ipinc.net><112FF1070FFF4B7E957E13C757CCB513@vid eo><23B533DB44354E3EA201D0941C47C46C@video><861B310C-7502-49FE-BD13-3D1B123A57EB @delong.com><274D7568A828485B91D64F9308B3A24E@video> <9737f78a74367c4fde16e526d31442304dbec379@jcc.com> <40d2346a1b58436fb0387d165b0c7bee4dbed64a@jcc.com> <34A035C8AB3147919076CC4BB118C83B@mike> <03bbb072c4565685fb86a50e59d5178b4dbefc1f@jcc.com> Message-ID: <35F0C71BD6974F21A3C296005F0DDA0F@mike> >But what is it about ARIN that is broken? What exactly do you think needs >to be fixed? >The only thing I've gotten out of the discussions so far is that some >people think there is money to be made by providing IPv4 addresses based on >willingness and ability to pay rather than ARIN's current >demonstrated >need policies. >Why is it to my benefit if someone else makes money? Particularly if it >perturbs the current mechanisms in a way that costs me money? >Keith Hare Hi Keith, What is broken about ARIN is that scandalously large numbers of netblocks do not have valid POCs, for example. The stewardship of Whois leaves a lot to be desired. Competitive pressures would help to finally decide who controls these addresses and allow them to be transferred to those who would pay for them. Network operators don't really have much of a choice in accessing Whois information to determine the rights to advertise addresses, and competive registries. In my experience they rely on attestation and review of proferred chain-of-custody docs when determining who can advertise which addresses, when confronted with inconsistencies with whois. A competitive registry with a title insurance component will give network operators more security when deciding questionable cases. What is broken about ARIN is that their transfer policies are more restrictive than APNICs, and that will cause a flow of addresses out of ARIN and into APNIC. A competitive registry could presumably have a different transfer policy, as APNICs differs from ARINs. What is broken about ARIN is that ARIN has professed no statutory control over legacy addresses in the Plzak declaration in the Kremen case, and yet attempts to control the registration of legacy resources. With a private registry, the address rights holders can choose to opt-out of ARIN's dictats and choose their registry voluntarily. I don't see how the creation of a private registry will perturb the current mechanisms in a way that costs you money, could you share why you feel that way? Regards, Mike Burns From bill at herrin.us Mon May 2 15:33:47 2011 From: bill at herrin.us (William Herrin) Date: Mon, 2 May 2011 15:33:47 -0400 Subject: [arin-ppml] Analogies In-Reply-To: <2ABCF380-7866-4ED8-BE43-C789CBEBFE27@delong.com> References: <39209.1303885464@tristatelogic.com> <75822E125BCB994F8446858C4B19F0D7173057C827@SUEX07-MBX-04.ad.syr.edu> <471D76419F9EF642962323D13DF1DF69011E5C@newserver.arneill-py.local> <7348D3C8-4EB7-4440-A152-210CC8B0DA3C@arin.net> <471D76419F9EF642962323D13DF1DF69011E60@newserver.arneill-py.local> <583A067A-B8AE-4026-844E-6769D1D7CF88@arin.net> <471D76419F9EF642962323D13DF1DF69011E61@newserver.arneill-py.local> <7DF2A1C4-1799-486B-A631-2E1119C22A7C@arin.net> <3CCC6D1F-11F4-40BC-B102-CC6744A5E709@virtualized.org> <4DB9BACE.6000307@ipinc.net> <0E134D8B-0A4B-466E-B261-9C7D0ED11867@virtualized.org> <388190E3-08F2-4AC7-870A-621A2FD6EEFE@virtualized.org> <2ABCF380-7866-4ED8-BE43-C789CBEBFE27@delong.com> Message-ID: On Mon, May 2, 2011 at 3:24 PM, Owen DeLong wrote: > On Apr 30, 2011, at 5:39 PM, William Herrin wrote: >> I will suggest that an attempt by ARIN to charge $100/year under a >> contract simplified to, "We agree to keep your whois data and RDNS >> delegations intact as is for one year increments until either of us >> choose to cancel this contract" would meet with at most mild >> resistance from the legacy registrants. It would also, IMHO, provide >> an excellent way to weed out the abandoned registrations. > > That seems like a reasonable summary of the current LRSA. If counsel agrees with that assessment (he doesn't and you didn't check) then start summarizing and put the result in front of me, without all the excess baggage in the current LRSA. 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 2 15:39:35 2011 From: owen at delong.com (Owen DeLong) Date: Mon, 2 May 2011 12:39:35 -0700 Subject: [arin-ppml] Internet 101: Collaboration (was -Microsoft receives court approval for transfer as agreed with ARIN) In-Reply-To: References: <7EB32A4E-DDE3-417F-926E-F4A3D90A893E@virtualized.org> <0AC9CF9F-5AE7-4E09-A523-3C63E4BBFFAA@delong.com> <7772B728-A6F9-4FE9-9B7C-7C688F76BEE8@virtualized.org> <471D76419F9EF642962323D13DF1DF69011E6B@newserver.arneill-py.local> <4DBB892E.60604@matthew.at> Message-ID: <680D3BA8-7BDE-448A-989E-E2B9939D9ADC@delong.com> On Apr 30, 2011, at 6:06 PM, William Herrin wrote: > On Sat, Apr 30, 2011 at 2:13 AM, Owen DeLong wrote: >> On Apr 29, 2011, at 8:59 PM, Matthew Kaufman wrote: >>> On 4/29/2011 8:49 PM, Michel Py wrote: >>>> it's about the gut >>>> reaction about a new recurring fee. >>> >>> Agree. This is why I don't have any end-user IPv6 space of my own still. Sure, I'd love to configure up my own globally-routable IPv6 across the local microwave IP network I have, but that particular hobby already uses more $/month out of the budget than I should be spending, so $100/year isn't going to go to ARIN for this. (Never mind that even with approximately zero IPv6 usage the initial fee discounts have mostly gone away). >>> >> I have an IPv6 direct assignment from ARIN and my fees to ARIN increased >> by exactly $0 per year as a result. > > > I don't. I coughed up the $500 a few years ago for an AS number to > multihome my legacy addresses and I pay the $100/year as a result. If > IPv6 usage ever takes off, I'll cough up the $1250 too, but $1250 is a > steep barrier to join a system whose current usage is, well, > negligible. I don't mean to imply the fee is unfair... it isn't. But > participation isn't yet worth it at that price. > At the time, there was a discount on IPv6 assignments and I only payed $500 for my /48. The discount was motivation enough for me to do so, as I figured I'd have to get v6 eventually and $500 now seemed a bargain compared to $1250 or more later. > My own complaints about the recurring fees ended abruptly when I > calculated how much it cost "everybody else" to support my > non-aggregable registration in the BGP table. > http://bill.herrin.us/network/bgpcost.html lol As you know, we still disagree about your calculations, but, I agree that $100/year is quite reasonable to cover my IPv4 and IPv6 assignments. Owen From bill at herrin.us Mon May 2 15:42:38 2011 From: bill at herrin.us (William Herrin) Date: Mon, 2 May 2011 15:42:38 -0400 Subject: [arin-ppml] ARIN-prop-140 Business Failure Clarification In-Reply-To: References: <4DBEF0DF.8060800@arin.net> Message-ID: On Mon, May 2, 2011 at 2:43 PM, William Herrin wrote: > "Thus, if a company goes out of business, regardless of the reason, > the point of contact (POC) listed for the number resource does not > have the authority to sell, transfer, assign, or give the number > resource to any other person or organization. The POC must notify ARIN > if a business fails so the assigned number resources can be returned > to the available pool of number resources if a transfer is not > requested and justified." > > The main point of that paragraph is that if your company's network is > terminated (as part of a general company shutdown) you, as the POC, > don't get to keep the addresses as some kind of severance pay. Your > suggested text frankly just muddies the waters further. Another suitable rewrite might replace those two sentences with: "An individual shall not have the authority to retain, sell, transfer, assign, or give the number resource to any other person or organization solely because he is listed as the point of contact for an otherwise defunct organization, nor shall the organization cede such authority to said individual except as is consistent with these transfer policies." 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 2 15:44:58 2011 From: owen at delong.com (Owen DeLong) Date: Mon, 2 May 2011 12:44:58 -0700 Subject: [arin-ppml] NRPN 8.2 & 2.3 In-Reply-To: References: Message-ID: At this point, I would agree. However, I would like to wait until I get a chance to discuss the matter with ARIN Counsel and further discuss it with staff before I start crafting proposals to do so. I don't feel that staff or the board have acted improperly. I think that policy failed to express the community intent well enough as to achieve or goals. I will continue to work on finding a way to bring policy better in line with community intent, but, the hard part will be achieving consensus on what that intent is. It seems the community is rather divided with some advocating a complete abandonment of the principles of stewardship in favor of a laissez faire address economy while others favor preservation of the principles of stewardship and justified need while enabling market incentives to free up space. It is most unfortunate that we failed to produce clear policy in 2009-1. I hope we can correct it at Philadelphia. Owen On Apr 30, 2011, at 6:48 PM, Rudolph Daniel wrote: > It would seem clear to me that at the very least, NRPN 8.2 and 8.3 requires rephrasing. Is that also the view of the ppml? > > rd > > > >> for such resources, as a single aggregate", not that a single > >> aggregate be transferred. > > > > ... I do not believe that Stephen's interpretation below matches the > > meaning or the intent of the policy as I understand it. ... > > I don't think it does either, for the record. However, this points out > how bad wording has left us in a situation where we're not sure /what/ > the policy text means--much less whether we agree with it. > > > I do agree that your interpretation would be a syntactically and > > grammatically valid construction, but, I believe it is contextually > > nonsensical and not the intended meaning of the words. > > > > If anyone has a suggestion for making the actual intent more clear, I > > am open to suggestions and would support making an editorial > > correction for clarity. > > If you can provide examples of transfers you both do and don't wish to > allow, I'll be happy to come up with wording to express your intent. As > it stands, though, I don't understand your (or anyone else's) intent > well enough to try. > > S > > -- > Stephen Sprunk "God does not play dice." --Albert Einstein > CCIE #3723 "God is an inveterate gambler, and He throws the > K5SSS dice at every possible opportunity." --Stephen Hawking > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: smime.p7s > Type: application/pkcs7-signature > Size: 3646 bytes > Desc: S/MIME Cryptographic Signature > URL: > > ------------------------------ > > Message: 2 > Date: Sat, 30 Apr 2011 20:28:39 -0400 > From: William Herrin > To: John Curran > Cc: Public Policy Mailing List > Subject: Re: [arin-ppml] Call for a study & survey to obtain necessary > information for policy development > Message-ID: > Content-Type: text/plain; charset=ISO-8859-1 > > On Sat, Apr 30, 2011 at 7:51 AM, John Curran wrote: > > ? contains a specific call for ARIN to charter a study including > > ? a survey in order to obtain additional information to assist in > > ? policy development. > > > > ? I've not seen any discussion of this suggestion; would it be > > ? possible to get feedback from the otherwise shy participants > > ? on the PPML mailing list? > > > > On Apr 29, 2011, at 5:46 PM, Jeffrey Lyon wrote: > >> what we should do is > >> charter ARIN to conduct a comprehensive study and: > >> > >> - Conduct a survey of the public at large, PPML users, full members, > >> resource holders, and the AC to gain a clear understanding of > >> sentiment for or against an open market. > >> - Determine how many companies actually have IPv6 migration plans and > >> ascertain road blocks, either legitimate or financial, that are > >> preventing migration. > >> - Would resource holders support a model that allowed ARIN to take a > >> small commission on resource sales and then discontinue the practice > >> of charging an annual fee to its members who are not buying and > >> selling resources. > > These seem like they could be determined by survey. > > > >> - In the survey, ask IPv4 resource holders to anonymously disclose > >> their true utilization rates and determine if companies are hoarding > >> resources either in hopes of future resale or to cover an arbitrary > >> future need. > >> - Determine the amount of participants that would come forward if told > >> they could resell their space on the open market and ultimately > >> determine how much unneeded space is being locked away in loosely > >> justified allocations. > >> - Determine if resource holders would be encouraged to tighten up > >> internal policies and free up more space if there were a fair market > >> value assigned to their space. > > These strike me as very difficult to determine by anything approaching > a statistically valid survey. I would want to see a detailed > methodology proposed before agreeing either that money should be spent > conducting the survey or that the results would have merit to > contribute to the policy debate. > > > >> - Determine the economic impact. Would resource holders be better off > >> selling their resources to more affluent companies who would be able > >> to put the space to better use? Might there be a host of struggling > >> small businesses who would like to put their /17 - /21 on the balance > >> sheet? Are there companies that would purchase IPv4 space at a premium > >> if allowed to do so? > > This would require a cost analysis of a great many factors, only some > of which have been touched on in the listed survey. Given the abject > lack of use of cost analysis in the Internet industry, it would > require at least three independent cost analyses and considerable > subsequent debate on and validation of the methodologies... > > Start here: http://www.sceaonline.net/ > > Disclaimer: my father is a crotchety old cost analyst so I get a > regular earful about this stuff. > > Regards, > Bill Herrin > > > -- > William D. Herrin ................ herrin at dirtside.com? bill at herrin.us > 3005 Crane Dr. ...................... Web: > Falls Church, VA 22042-3004 > > > ------------------------------ > > Message: 3 > Date: Sat, 30 Apr 2011 20:39:08 -0400 > From: William Herrin > To: Owen DeLong > Cc: John Curran , arin-ppml > Subject: Re: [arin-ppml] Analogies > Message-ID: > Content-Type: text/plain; charset=ISO-8859-1 > > On Sat, Apr 30, 2011 at 1:31 AM, Owen DeLong wrote: > > I will point out that ARIN is the only registry that did not start > > charging their legacy holders shortly after coming into existence. > > > > APNIC, RIPE, AfriNIC, and LACNIC all charge their legacy holders > > annual fees to the best of my knowledge. > > > > I do not know whether a contract was required in any or all cases, > > but, the fee portion of the equation is unique to ARIN to the best > > of my knowledge. > > Hi Owen, > > I will suggest that an attempt by ARIN to charge $100/year under a > contract simplified to, "We agree to keep your whois data and RDNS > delegations intact as is for one year increments until either of us > choose to cancel this contract" would meet with at most mild > resistance from the legacy registrants. It would also, IMHO, provide > an excellent way to weed out the abandoned registrations. > > This hasn't been done in part because we, in this forum, have insisted > that legacy registrants should not be invited into the fold under such > terms. > > Regards, > Bill Herrin > > > -- > William D. Herrin ................ herrin at dirtside.com? bill at herrin.us > 3005 Crane Dr. ...................... Web: > Falls Church, VA 22042-3004 > > > ------------------------------ > > Message: 4 > Date: Sat, 30 Apr 2011 20:43:29 -0400 > From: "Mike Burns" > To: "Stephen Sprunk" , "Owen DeLong" > > Cc: arin-ppml at arin.net > Subject: Re: [arin-ppml] ARIN / Microsoft press release regarding IP > addressTransfers > Message-ID: <7B6110E30D2E40CDA7E10BCB85E290B7 at video> > Content-Type: text/plain; charset="utf-8" > > >If you can provide examples of transfers you both do and don't wish to allow, I'll be happy to come up with wording to express your intent. As it stands, though, I >don't understand your (or anyone else's) intent well enough to try. > > >S > > Steve, > > Here is why I call BS on the claim that these transfers comply with policy: > > "Such transferred number resources may only be received under RSA by organizations that are within the ARIN region and can demonstrate the need for such resources, as a single aggregate, in the exact amount which they can justify under current ARIN policies." > > That is the text. The comma between resources and "as a single aggregate" can be read to cause the "as a single aggregate" clause to apply to either the verb phrase "be received" or the verb phrase "can demonstrate." > > But how would anybody demonstrate a need for multiple netblocks anyway? > Isn't the need ALWAYS determined as a single aggregate? > > Regards, > > Mike > > > > ----- Original Message ----- > From: Stephen Sprunk > To: Owen DeLong > Cc: arin-ppml at arin.net > Sent: Saturday, April 30, 2011 8:27 PM > Subject: Re: [arin-ppml] ARIN / Microsoft press release regarding IP addressTransfers > > > On 16-Apr-11 02:19, Owen DeLong wrote: > > On Apr 15, 2011, at 9:53 PM, Stephen Sprunk wrote: > > On 15-Apr-11 19:00, Matthew Kaufman wrote: > > The adopted policies (if they are using the "relatively new policy" as alluded to in the release) require the transfer of *a single aggregate*. > > > Not quite. NRPM 8.3 only requires the receiver "demonstrate the need for such resources, as a single aggregate", not that a single aggregate be transferred. > > ... I do not believe that Stephen's interpretation below matches the meaning or the intent of the policy as I understand it. ... > > I don't think it does either, for the record. However, this points out how bad wording has left us in a situation where we're not sure what the policy text means--much less whether we agree with it. > > > I do agree that your interpretation would be a syntactically and grammatically valid construction, but, I believe it is contextually nonsensical and not the intended meaning of the words. > > > If anyone has a suggestion for making the actual intent more clear, I am open to suggestions and would support making an editorial correction for clarity. > > If you can provide examples of transfers you both do and don't wish to allow, I'll be happy to come up with wording to express your intent. As it stands, though, I don't understand your (or anyone else's) intent well enough to try. > > S > > > -- > Stephen Sprunk "God does not play dice." --Albert Einstein > CCIE #3723 "God is an inveterate gambler, and He throws the > K5SSS dice at every possible opportunity." --Stephen Hawking > > > ------------------------------------------------------------------------------ > > > _______________________________________________ > 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: > > ------------------------------ > > _______________________________________________ > ARIN-PPML mailing list > ARIN-PPML at arin.net > http://lists.arin.net/mailman/listinfo/arin-ppml > > End of ARIN-PPML Digest, Vol 70, Issue 176 > ****************************************** > > > > -- > > Rudi Daniel > danielcharles consulting > 1-784 498 8277 > > > > _______________________________________________ > 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 v6ops at globis.net Mon May 2 15:53:16 2011 From: v6ops at globis.net (Ray Hunter) Date: Mon, 02 May 2011 21:53:16 +0200 Subject: [arin-ppml] Accusation of fundamental conflict ofinterest/IPaddresspolicy pitched directly to ICANN In-Reply-To: <4DBF09D8.7020206@globis.net> References: <4DBEE79C.6030007@globis.net> <4DBEFDC0.3070705@globis.net> <96AF0FBE0B5A40CFB80A34CA2FF86FCA@mike> <4DBF09D8.7020206@globis.net> Message-ID: <4DBF0BAC.6040703@globis.net> Once again I declare my neutrality. I'm neither pro nor anti Microsoft, Nortel, Addrex, or anyone else mentioned in the discussion. I am aware of that transaction from press reports. As I understand it, Microsoft bought a defunct portion of a company in Chapter 11 bankruptcy in order to obtain access to a chunk of legacy space. According to press reports, 80 parties were contacted by Addrex and Nortel. Were major Asian providers like China Mobile China Telecom, and Bharti Airtel// on that contact list? I don't know. But just because two companies like Microsoft and Addrex do something once in the US (and potentially "get away with it") certainly does not IMVHO set a precedent for global policy on how to run the Internet, nor establish a market value for an IPv4 address. In fact one could very succinctly argue that precisely this example could/should trigger the ARIN / ICANN community to now officially adopt a tighter /explicit policy like example #7 I mentioned. 7) Ask ARIN to prevent any and all transfers that are motivated purely by financial gain, and instead insist that such participants return IPv4 allocations to the unallocated pool "for the benefit of the Internet Community" once the existing allocation is no longer needed. The ARIN community directs how ARIN operates. Microsoft are also members of the ARIN community. The Internet is far bigger than the US. As others have warned, there's potentially a huge risk of organizations like the ITU and the WTO getting involved in a major trade dispute. I doubt if anyone would look forward to that conflict, or that (m)any in the Internet community would indeed benefit. regards, RayH Mike Burns wrote: > > ----- Original Message ----- > *From:* Ray Hunter > *To:* Mike Burns > *Cc:* arin-ppml at arin.net > *Sent:* Monday, May 02, 2011 2:53 PM > *Subject:* Re: [arin-ppml] Accusation of fundamental conflict > ofinterest/IPaddresspolicy pitched directly to ICANN > > No one owns the addresses today. They're just 32 bit numbers. > That's all. Nothing more. Nothing less. No one ever owned the > addresses. They have zero intrinsic value. > > Ray, > That train has left the station. Nortel sold addresses to > Microsoft for $7.5 million. > Addresses which have been allocated very obviously have a value > different from a random string of 32 bit numbers. > You can argue that they shouldn't, you can argue that correct > stewardship would be to establish policies to kill IPv4 and thus > transition more swiftly. > But you can't argue that they have zero value. > Regards, > Mike > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike at nationwideinc.com Mon May 2 15:57:18 2011 From: mike at nationwideinc.com (Mike Burns) Date: Mon, 2 May 2011 15:57:18 -0400 Subject: [arin-ppml] NRPN 8.2 & 2.3 References: Message-ID: <61CEAA1048BE416E9BD7FB5C7CBF47FB@mike> >It seems the community is >rather divided with some advocating a complete abandonment >of the principles of stewardship in favor of a laissez faire >address economy while others favor preservation of the >principles of stewardship and justified need while enabling >market incentives to free up space. >Owen Removing artificial restrictions on the transfer of IP address space is not, as Owen persists in characterizing it, an abandonment of the principles of stewardship. Stewardship simply means different things pre- and post-exhaust. Pre-exhaust requires needs analyses to ensure efficient use of address space. Post-exahust, efficient use is ensured by the same market incentives you claim enables the freeing up of space. To wit, price. I don't believe that there has been an answer to those of us who said that while it is grammatically acceptable to decide that a "single aggregate" relates to the needs justification, it is nonsensical to do that, as all needs analyses result in a single aggregate. You don't have a needs analysis at any time where it is found that a need is outside CIDR boundaries. Need assessment has always rounded up to that boundary. No, the only way to interpret the language of 8.3 is that the reception of the addresses should occur as a single aggregate, which is clear has not occurred with 8.3. To say the staff or the board acted outside of policy is correct in the MS/Nortel case. Regards, Mike ----- Original Message ----- From: Owen DeLong To: Rudolph Daniel Cc: arin-ppml at arin.net Sent: Monday, May 02, 2011 3:44 PM Subject: Re: [arin-ppml] NRPN 8.2 & 2.3 At this point, I would agree. However, I would like to wait until I get a chance to discuss the matter with ARIN Counsel and further discuss it with staff before I start crafting proposals to do so. I don't feel that staff or the board have acted improperly. I think that policy failed to express the community intent well enough as to achieve or goals. I will continue to work on finding a way to bring policy better in line with community intent, but, the hard part will be achieving consensus on what that intent is. It seems the community is rather divided with some advocating a complete abandonment of the principles of stewardship in favor of a laissez faire address economy while others favor preservation of the principles of stewardship and justified need while enabling market incentives to free up space. It is most unfortunate that we failed to produce clear policy in 2009-1. I hope we can correct it at Philadelphia. Owen On Apr 30, 2011, at 6:48 PM, Rudolph Daniel wrote: It would seem clear to me that at the very least, NRPN 8.2 and 8.3 requires rephrasing. Is that also the view of the ppml? rd >> for such resources, as a single aggregate", not that a single >> aggregate be transferred. > > ... I do not believe that Stephen's interpretation below matches the > meaning or the intent of the policy as I understand it. ... I don't think it does either, for the record. However, this points out how bad wording has left us in a situation where we're not sure /what/ the policy text means--much less whether we agree with it. > I do agree that your interpretation would be a syntactically and > grammatically valid construction, but, I believe it is contextually > nonsensical and not the intended meaning of the words. > > If anyone has a suggestion for making the actual intent more clear, I > am open to suggestions and would support making an editorial > correction for clarity. If you can provide examples of transfers you both do and don't wish to allow, I'll be happy to come up with wording to express your intent. As it stands, though, I don't understand your (or anyone else's) intent well enough to try. S -- Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3646 bytes Desc: S/MIME Cryptographic Signature URL: ------------------------------ Message: 2 Date: Sat, 30 Apr 2011 20:28:39 -0400 From: William Herrin To: John Curran Cc: Public Policy Mailing List Subject: Re: [arin-ppml] Call for a study & survey to obtain necessary information for policy development Message-ID: Content-Type: text/plain; charset=ISO-8859-1 On Sat, Apr 30, 2011 at 7:51 AM, John Curran wrote: > ? contains a specific call for ARIN to charter a study including > ? a survey in order to obtain additional information to assist in > ? policy development. > > ? I've not seen any discussion of this suggestion; would it be > ? possible to get feedback from the otherwise shy participants > ? on the PPML mailing list? > > On Apr 29, 2011, at 5:46 PM, Jeffrey Lyon wrote: >> what we should do is >> charter ARIN to conduct a comprehensive study and: >> >> - Conduct a survey of the public at large, PPML users, full members, >> resource holders, and the AC to gain a clear understanding of >> sentiment for or against an open market. >> - Determine how many companies actually have IPv6 migration plans and >> ascertain road blocks, either legitimate or financial, that are >> preventing migration. >> - Would resource holders support a model that allowed ARIN to take a >> small commission on resource sales and then discontinue the practice >> of charging an annual fee to its members who are not buying and >> selling resources. These seem like they could be determined by survey. >> - In the survey, ask IPv4 resource holders to anonymously disclose >> their true utilization rates and determine if companies are hoarding >> resources either in hopes of future resale or to cover an arbitrary >> future need. >> - Determine the amount of participants that would come forward if told >> they could resell their space on the open market and ultimately >> determine how much unneeded space is being locked away in loosely >> justified allocations. >> - Determine if resource holders would be encouraged to tighten up >> internal policies and free up more space if there were a fair market >> value assigned to their space. These strike me as very difficult to determine by anything approaching a statistically valid survey. I would want to see a detailed methodology proposed before agreeing either that money should be spent conducting the survey or that the results would have merit to contribute to the policy debate. >> - Determine the economic impact. Would resource holders be better off >> selling their resources to more affluent companies who would be able >> to put the space to better use? Might there be a host of struggling >> small businesses who would like to put their /17 - /21 on the balance >> sheet? Are there companies that would purchase IPv4 space at a premium >> if allowed to do so? This would require a cost analysis of a great many factors, only some of which have been touched on in the listed survey. Given the abject lack of use of cost analysis in the Internet industry, it would require at least three independent cost analyses and considerable subsequent debate on and validation of the methodologies... Start here: http://www.sceaonline.net/ Disclaimer: my father is a crotchety old cost analyst so I get a regular earful about this stuff. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 ------------------------------ Message: 3 Date: Sat, 30 Apr 2011 20:39:08 -0400 From: William Herrin To: Owen DeLong Cc: John Curran , arin-ppml Subject: Re: [arin-ppml] Analogies Message-ID: Content-Type: text/plain; charset=ISO-8859-1 On Sat, Apr 30, 2011 at 1:31 AM, Owen DeLong wrote: > I will point out that ARIN is the only registry that did not start > charging their legacy holders shortly after coming into existence. > > APNIC, RIPE, AfriNIC, and LACNIC all charge their legacy holders > annual fees to the best of my knowledge. > > I do not know whether a contract was required in any or all cases, > but, the fee portion of the equation is unique to ARIN to the best > of my knowledge. Hi Owen, I will suggest that an attempt by ARIN to charge $100/year under a contract simplified to, "We agree to keep your whois data and RDNS delegations intact as is for one year increments until either of us choose to cancel this contract" would meet with at most mild resistance from the legacy registrants. It would also, IMHO, provide an excellent way to weed out the abandoned registrations. This hasn't been done in part because we, in this forum, have insisted that legacy registrants should not be invited into the fold under such terms. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 ------------------------------ Message: 4 Date: Sat, 30 Apr 2011 20:43:29 -0400 From: "Mike Burns" To: "Stephen Sprunk" , "Owen DeLong" Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] ARIN / Microsoft press release regarding IP addressTransfers Message-ID: <7B6110E30D2E40CDA7E10BCB85E290B7 at video> Content-Type: text/plain; charset="utf-8" >If you can provide examples of transfers you both do and don't wish to allow, I'll be happy to come up with wording to express your intent. As it stands, though, I >don't understand your (or anyone else's) intent well enough to try. >S Steve, Here is why I call BS on the claim that these transfers comply with policy: "Such transferred number resources may only be received under RSA by organizations that are within the ARIN region and can demonstrate the need for such resources, as a single aggregate, in the exact amount which they can justify under current ARIN policies." That is the text. The comma between resources and "as a single aggregate" can be read to cause the "as a single aggregate" clause to apply to either the verb phrase "be received" or the verb phrase "can demonstrate." But how would anybody demonstrate a need for multiple netblocks anyway? Isn't the need ALWAYS determined as a single aggregate? Regards, Mike ----- Original Message ----- From: Stephen Sprunk To: Owen DeLong Cc: arin-ppml at arin.net Sent: Saturday, April 30, 2011 8:27 PM Subject: Re: [arin-ppml] ARIN / Microsoft press release regarding IP addressTransfers On 16-Apr-11 02:19, Owen DeLong wrote: On Apr 15, 2011, at 9:53 PM, Stephen Sprunk wrote: On 15-Apr-11 19:00, Matthew Kaufman wrote: The adopted policies (if they are using the "relatively new policy" as alluded to in the release) require the transfer of *a single aggregate*. Not quite. NRPM 8.3 only requires the receiver "demonstrate the need for such resources, as a single aggregate", not that a single aggregate be transferred. ... I do not believe that Stephen's interpretation below matches the meaning or the intent of the policy as I understand it. ... I don't think it does either, for the record. However, this points out how bad wording has left us in a situation where we're not sure what the policy text means--much less whether we agree with it. I do agree that your interpretation would be a syntactically and grammatically valid construction, but, I believe it is contextually nonsensical and not the intended meaning of the words. If anyone has a suggestion for making the actual intent more clear, I am open to suggestions and would support making an editorial correction for clarity. If you can provide examples of transfers you both do and don't wish to allow, I'll be happy to come up with wording to express your intent. As it stands, though, I don't understand your (or anyone else's) intent well enough to try. S -- Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking ------------------------------------------------------------------------------ _______________________________________________ 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: ------------------------------ _______________________________________________ ARIN-PPML mailing list ARIN-PPML at arin.net http://lists.arin.net/mailman/listinfo/arin-ppml End of ARIN-PPML Digest, Vol 70, Issue 176 ****************************************** -- Rudi Daniel danielcharles consulting 1-784 498 8277 _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. ------------------------------------------------------------------------------ _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcurran at arin.net Mon May 2 15:57:37 2011 From: jcurran at arin.net (John Curran) Date: Mon, 2 May 2011 19:57:37 +0000 Subject: [arin-ppml] Analogies In-Reply-To: References: <39209.1303885464@tristatelogic.com> <75822E125BCB994F8446858C4B19F0D7173057C827@SUEX07-MBX-04.ad.syr.edu> <471D76419F9EF642962323D13DF1DF69011E5C@newserver.arneill-py.local> <7348D3C8-4EB7-4440-A152-210CC8B0DA3C@arin.net> <471D76419F9EF642962323D13DF1DF69011E60@newserver.arneill-py.local> <583A067A-B8AE-4026-844E-6769D1D7CF88@arin.net> <471D76419F9EF642962323D13DF1DF69011E61@newserver.arneill-py.local> <7DF2A1C4-1799-486B-A631-2E1119C22A7C@arin.net> <3CCC6D1F-11F4-40BC-B102-CC6744A5E709@virtualized.org> <4DB9BACE.6000307@ipinc.net> <0E134D8B-0A4B-466E-B261-9C7D0ED11867@virtualized.org> <388190E3-08F2-4AC7-870A-621A2FD6EEFE@virtualized.org> <2ABCF380-7866-4ED8-BE43-C789CBEBFE27@delong.com> Message-ID: On May 2, 2011, at 9:33 PM, William Herrin wrote: > On Mon, May 2, 2011 at 3:24 PM, Owen DeLong wrote: >> On Apr 30, 2011, at 5:39 PM, William Herrin wrote: >>> I will suggest that an attempt by ARIN to charge $100/year under a >>> contract simplified to, "We agree to keep your whois data and RDNS >>> delegations intact as is for one year increments until either of us >>> choose to cancel this contract" would meet with at most mild >>> resistance from the legacy registrants. It would also, IMHO, provide >>> an excellent way to weed out the abandoned registrations. >> >> That seems like a reasonable summary of the current LRSA. > > If counsel agrees with that assessment (he doesn't and you didn't > check) then start summarizing and put the result in front of me, > without all the excess baggage in the current LRSA. Bill - That additional language in the LRSA comes from the RSA (which is what everyone else has agreed to to receive registry services) If you have a suggestion for revising the RSA or LRSA, you can send it directly to me or submit it via the ARIN Consultation and Suggestion process[1]. Revisions to these agreements have resulted from past suggestions. Thanks! /John John Curran President and CEO ARIN [1] https://www.arin.net/participate/acsp/index.html From mike at nationwideinc.com Mon May 2 16:02:34 2011 From: mike at nationwideinc.com (Mike Burns) Date: Mon, 2 May 2011 16:02:34 -0400 Subject: [arin-ppml] Accusation of fundamental conflictofinterest/IPaddresspolicy pitched directly to ICANN References: <4DBEE79C.6030007@globis.net><4DBEFDC0.3070705@globis.net><96AF0FBE0B5A40CFB80 A34CA2FF86FCA@mike><4DBF09D8.7020206@globis.net> <4DBF0BAC.6040703@globis.net> Message-ID: <921C6A7057A94379A7D4267C47D2ABEC@mike> Now you would ask ARIN not only whether the addresses are justified in their opinion, but also to judge the financial motivations of the participants? Under what policy would ARIN be able to have legacy addresses returned to the free pool as you describe? In fact, the MS/Nortel deal is not the only transaction that has occurred, and the existence of tradeipv4.com and other sites is testimony to the likelihood it will happen again, policy or no policy. Who knows which 80 companies were contacted? Wouldn't it be better if the whole thing was conducted in the open, so that ChinaTelecom could bid as well? Why not an open and transparent marketplace free from artifical and easily-scammable justification regimes? Regards, MIke In fact one could very succinctly argue that precisely this example could/should trigger the ARIN / ICANN community to now officially adopt a tighter /explicit policy like example #7 I mentioned. 7) Ask ARIN to prevent any and all transfers that are motivated purely by financial gain, and instead insist that such participants return IPv4 allocations to the unallocated pool "for the benefit of the Internet Community" once the existing allocation is no longer needed. Ray -------------- next part -------------- An HTML attachment was scrubbed... URL: From owen at delong.com Mon May 2 16:05:14 2011 From: owen at delong.com (Owen DeLong) Date: Mon, 2 May 2011 13:05:14 -0700 Subject: [arin-ppml] ARIN-2011-2 (Was: Forcing POCs and other contacts to act through a "blacklist") In-Reply-To: <98430.1304222709@tristatelogic.com> References: <98430.1304222709@tristatelogic.com> Message-ID: On Apr 30, 2011, at 9:05 PM, Ronald F. Guilmette wrote: > > In message <20110430034341.GA68511 at ussenterprise.ufp.org>, > Leo Bicknell wrote: > > curran> "Legacy resources that have been abandoned because a company, for > curran> example, has dissolved don't really pose a problem." > >> Having personally tracked spam and botnets back to such blocks in >> the past I know first hand John is incorrect in this statement. > > Leo is more diplomatic that I am. "Incorrect" is not the word that I > would have used. > > John Curran knows good and well that there is a problem. He has simply > been doing his level best to steer himself and his minions well and > truly clear of taking any responsiblity for fixing it, or even in- > vestigating it. > > I am self-admittedly ignorant about a lot of things, and that probably > includes essentally all of the policy manual. But I have been led to > believe that ARIN has basically two responsibilities, to wit: > > 1) To make allocations, fairly and impartially, according to policy, > and > > 2) to keep an acurate data base of who is using all of the number > resources that have been assigned to ARIN and ARIN's region, > both legacy and non-legacy. > You are close, but, not quite... 2) to keep an accurate data base of who has been assigned or allocated number resources in the ARIN region either by ARIN or its predecessor registries. > As a result of the recent Nortel/Microsoft deal, some have raised questions > about ARIN's ability and/or willingness to fulfill its responsibilities to > do (1). Based upon what has, apparently, transpired with respect to Leo's > proposal however, I would like to assert, here and now, my own personal > disbelief in the notion that ARIN is even seriously comitted to doing (2). > I think part of that comes from the difference between your (2) and the version of (2) I have stated above. I believe mine to be a more accurate reflection of ARIN's mission. However, I do agree that ARIN should be more proactive about reclaiming abandoned and/or hijacked blocks and I would like to support policy in that direction. I think that Leo's policy went a little too far into blank-check land and that was why I favored abandoning it. Owen From dogwallah at gmail.com Mon May 2 16:06:32 2011 From: dogwallah at gmail.com (McTim) Date: Mon, 2 May 2011 23:06:32 +0300 Subject: [arin-ppml] Fw: Accusation of fundamental conflict ofinterest/IPaddress policy pitched directly to ICANN In-Reply-To: References: Message-ID: On Mon, May 2, 2011 at 7:48 PM, Mike Burns wrote: >> Can you be more specific? The ICANN ASO? the ICANN BoT? the IANA? > > Hi Tim, > > Keep going, all the organizations above are suspect due to the fact that > they are all comprised of the same basic group of ?RIR designees. The RIRs do not "designate" or appoint anyone to any of the above bodies. The ASO AC members are elected by their respective RIR communities. Those ASO AC members do have a role to play in choosing 2 (IIRC) of the ICANN Board. Neither the RIRs nor the ASO get to choose IANA staff. > > I would take it to NTIA like DNS. I think you overestimate the role of the NTIA in the DNS. > > And I would use DNS as a template for the creation of the global policy > restrictions John Curran asked about, which restrictions would apply to all > registries, regional or commercial. > Just as all DNS registrars must meet certain qualifications, so would > private registries of number space. > > Let the NTIA hear arguments from the proposer and from the ASO, the ICANN > BoT, and IANA, although I suspect they will all sound the same. Back in the 1990's, the idea was for the USG to divest itself (via ICANN) of the naming and numbering roles. That process is still ongoing, and one can see a certain acceleration of divestiture in recent years. The Affirmation of Commitments is, I think, an example of this. As DF has indicated, this (asking the NTIA to make this kind of determination) would be a real non-starter for the global Internet Governance community. -- Cheers, McTim "A name indicates what we seek. An address indicates where it is. A route indicates how we get there."? Jon Postel From jeffrey.lyon at blacklotus.net Mon May 2 16:09:02 2011 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Mon, 2 May 2011 16:09:02 -0400 Subject: [arin-ppml] ARIN-prop-145 STLS Listing Immunity In-Reply-To: <4DBEF116.1000400@arin.net> References: <4DBEF116.1000400@arin.net> Message-ID: On Mon, May 2, 2011 at 1:59 PM, ARIN wrote: > ARIN-prop-145 STLS Listing Immunity > > 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-145 STLS Listing Immunity > > Proposal Originator: Matthew Kaufman > > Proposal Version: 1 > > Date: 2 May 2011 > > Proposal type: new > > Policy term: permanent > > Policy statement: > > Add a subsection to Section 12 (Resource Review) of the NRPM: > > ARIN may not revoke any resources issued by ARIN that are presently > listed as "available" on the ARIN Specified Transfer Listing Service > unless there is sufficient reason to believe that the holder does not in > fact intend to transfer these resources. > > Rationale: > > An entity may list space as available and might begin the process of > moving out of that space in order to facilitate the transfer. A review > after such work was in progress might reveal that the addresses are not > sufficiently utilized. > > Additionally, because posting a listing on the STLS signals directly to > ARIN that an entity believes it can use addresses more efficiently, ARIN > might simply use STLS listings in order to trigger audit under 12.2(c). > This would not be fair. (And would be a disincentive to using the ARIN > STLS at all in order to list available space) > > This policy would also serve to increase the value of the ARIN STLS over > other possible transfer listing services, increasing the transparency of > the transfer market, particularly to ARIN, who wishes to ensure that > transfers take place within NRPM 8.3. > > 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. > I would support with additional controls that prevent STLS from being abused by those who want to grant immunity to mismanaged resources, so long as we're continuing to insist on needs analysis. -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications - AS32421 First and Leading in DDoS Protection Solutions From jeffrey.lyon at blacklotus.net Mon May 2 16:10:43 2011 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Mon, 2 May 2011 16:10:43 -0400 Subject: [arin-ppml] Accusation of fundamental conflictofinterest/IPaddresspolicy pitched directly to ICANN In-Reply-To: <921C6A7057A94379A7D4267C47D2ABEC@mike> References: <4DBEE79C.6030007@globis.net> <4DBEFDC0.3070705@globis.net> <4DBF09D8.7020206@globis.net> <4DBF0BAC.6040703@globis.net> <921C6A7057A94379A7D4267C47D2ABEC@mike> Message-ID: On Mon, May 2, 2011 at 4:02 PM, Mike Burns wrote: > Now you would ask ARIN not only whether the addresses are justified in their > opinion, but also to judge the financial motivations of the participants? > Under what policy would ARIN be able to have legacy addresses returned to > the free pool as you describe? > > In fact, the MS/Nortel deal is not the only transaction that has occurred, > and the existence of tradeipv4.com and other sites is testimony to the > likelihood it will happen again, policy or no policy. > > Who knows which 80 companies were contacted? Wouldn't it be better if the > whole thing was conducted in the open, so that ChinaTelecom could bid as > well? > > Why not an open and transparent marketplace free from artifical and > easily-scammable justification regimes? > > Regards, > MIke > > > > > In fact one could very succinctly argue that precisely this example > could/should trigger the ARIN / ICANN community to now officially adopt a > tighter /explicit policy like example #7 I mentioned. > > 7) Ask ARIN to prevent any and all transfers that are motivated purely by > financial gain, and instead insist that such participants return IPv4 > allocations to the unallocated pool "for the benefit of the Internet > Community" once the existing allocation is no longer needed. > > > Ray > > _______________________________________________ > 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. > Why would ARIN want to allow sales of space outside the region? -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications - AS32421 First and Leading in DDoS Protection Solutions From mpetach at netflight.com Mon May 2 16:04:37 2011 From: mpetach at netflight.com (Matthew Petach) Date: Mon, 2 May 2011 13:04:37 -0700 Subject: [arin-ppml] ARIN-2011-5: Shared Transition Space for IPv4 Address Extension - Last Call In-Reply-To: <97A8C174-859A-4457-AB93-66C0962DA1A4@delong.com> References: <4DAC8BCB.2000300@arin.net> <54E900DC635DAB4DB7A6D799B3C4CD8E10C7EF5E@PLSWM12A.ad.sprint.com> <3128593549961341875@unknownmsgid> <54E900DC635DAB4DB7A6D799B3C4CD8E10C899B7@PDAWM12B.ad.sprint.com> <1489147144792938659@unknownmsgid> <54E900DC635DAB4DB7A6D799B3C4CD8E10C89AC7@PDAWM12B.ad.sprint.com> <97A8C174-859A-4457-AB93-66C0962DA1A4@delong.com> Message-ID: On Mon, Apr 25, 2011 at 6:41 AM, Owen DeLong wrote: > On Apr 25, 2011, at 5:46 AM, George, Wes E [NTK] wrote: >> My recommended text: IPv4 addresses used behind a NAT (inside pool) cannot be used for justification of new resources nor counted >> towards utilization calculations for existing resources. NRPM 4.10.x (Shared Transition Space) defines a specific non-unique block >> to ?be shared among multiple networks for this purpose. > > I like this phrasing better than that offered by Mr. Herrin. > I think it more accurately reflects the policy intent. > Owen I would support this draft after inclusion of the above-mentioned text. Matt From mike at nationwideinc.com Mon May 2 16:13:18 2011 From: mike at nationwideinc.com (Mike Burns) Date: Mon, 2 May 2011 16:13:18 -0400 Subject: [arin-ppml] Fw: Accusation of fundamental conflict ofinterest/IPaddress policy pitched directly to ICANN References: Message-ID: Hi Tim, Just read the names of the committe members. Enough said. Regards, Mike ----- Original Message ----- From: "McTim" To: "Mike Burns" Cc: Sent: Monday, May 02, 2011 4:06 PM Subject: Re: Fw: [arin-ppml] Accusation of fundamental conflict ofinterest/IPaddress policy pitched directly to ICANN On Mon, May 2, 2011 at 7:48 PM, Mike Burns wrote: >> Can you be more specific? The ICANN ASO? the ICANN BoT? the IANA? > > Hi Tim, > > Keep going, all the organizations above are suspect due to the fact that > they are all comprised of the same basic group of RIR designees. The RIRs do not "designate" or appoint anyone to any of the above bodies. The ASO AC members are elected by their respective RIR communities. Those ASO AC members do have a role to play in choosing 2 (IIRC) of the ICANN Board. Neither the RIRs nor the ASO get to choose IANA staff. > > I would take it to NTIA like DNS. I think you overestimate the role of the NTIA in the DNS. > > And I would use DNS as a template for the creation of the global policy > restrictions John Curran asked about, which restrictions would apply to > all > registries, regional or commercial. > Just as all DNS registrars must meet certain qualifications, so would > private registries of number space. > > Let the NTIA hear arguments from the proposer and from the ASO, the ICANN > BoT, and IANA, although I suspect they will all sound the same. Back in the 1990's, the idea was for the USG to divest itself (via ICANN) of the naming and numbering roles. That process is still ongoing, and one can see a certain acceleration of divestiture in recent years. The Affirmation of Commitments is, I think, an example of this. As DF has indicated, this (asking the NTIA to make this kind of determination) would be a real non-starter for the global Internet Governance community. -- Cheers, McTim "A name indicates what we seek. An address indicates where it is. A route indicates how we get there." Jon Postel From owen at delong.com Mon May 2 16:10:46 2011 From: owen at delong.com (Owen DeLong) Date: Mon, 2 May 2011 13:10:46 -0700 Subject: [arin-ppml] If we would pursue a transfer policy without needs justification... In-Reply-To: <82026FDB-C821-4C2A-9A46-6A5162147F21@arin.net> References: <002c01cc07b7$7d400920$77c01b60$@iname.com> <82026FDB-C821-4C2A-9A46-6A5162147F21@arin.net> Message-ID: <79682228-A29A-429F-9631-EF3886BEBBBE@delong.com> The problem is that they are allowed to receive as many addresses through transfers as they wish. Additional point of information... APNIC _IS_ in their austerity phase, so, that provision in the APNIC policy has expired. Owen On Apr 30, 2011, at 10:57 PM, John Curran wrote: > On May 1, 2011, at 6:23 AM, Frank Bulk wrote: > >> If the community does ever debate a transfer policy that eliminates need >> justification, there should be some verbiage that the selling organization >> and its successors would not be able to receive more IPv4 space from ARIN's >> free pool unless there were exceptional circumstances. Otherwise an org >> could be set up to justify space and then sell, show need, rinse and repeat. > > A similar provision exists in APNIC's transfer policy which makes selling > organization ineligible to receive any further IPv4 address allocations > or assignments for a period of 12 months after the transfer (or until APNIC > reaches its austerity phase with 1 final allocation allowed per organization > from their final /8 of space) > > I'm expressing neither support or concern over the provision, but believe > as "running code", it's information that the community should be aware of > in this discussion. > > 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 mpetach at netflight.com Mon May 2 16:16:02 2011 From: mpetach at netflight.com (Matthew Petach) Date: Mon, 2 May 2011 13:16:02 -0700 Subject: [arin-ppml] ARIN-prop-144 Remove Single Aggregate requirement from Specified Transfer In-Reply-To: References: <4DBEF10B.50902@arin.net> Message-ID: On Mon, May 2, 2011 at 11:52 AM, William Herrin wrote: > On Mon, May 2, 2011 at 1:59 PM, ARIN wrote: >> ARIN-prop-144 Remove Single Aggregate requirement from Specified Transfer >> Proposal Originator: Matthew Kaufman >> >> Modify Section 8.3 as follows: >> Change "can demonstrate the need for such resources, as a single >> aggregate, in the exact amount which they can justify under current ARIN >> policies" to "can demonstrate the need for such resources in the amount >> which they can justify under current ARIN policies" > > Hi Matthew, > > IIRC, the source of that gobbledygook was that we didn't want folks > splitting up aggregates and selling them off piecemeal. Unless we can > find consensus on a better way to word that requirement, I would > support the offered change. > Regards, > Bill Herrin But that's the point I'm making; the aggregates don't exist as such; they've _already been_ split up: mpetach at pat1.sjc> show route terse 4.0.0.0/8 | grep \* | count Count: 46 lines mpetach at pat1.sjc> show route terse 8.0.0.0/8 | grep \* | count Count: 488 lines mpetach at pat1.sjc> Almost nobody announces their "pure" aggregate route only; so why would we insist that address transfers would have to be done in a more pristine manner than that in which the blocks are already being treated? Putting it more simply: 8.0.0.0/8 is already split into almost 500 pieces in the routing table; allowing those 500 pieces to be transferred to other companies has no intrinsic impact on the routing table size. That's why I think removing the single aggregate requirement is needed. Matt From mpetach at netflight.com Mon May 2 16:20:41 2011 From: mpetach at netflight.com (Matthew Petach) Date: Mon, 2 May 2011 13:20:41 -0700 Subject: [arin-ppml] ARIN-2011-4: Reserved Pool for Critical Infrastructure - Last Call In-Reply-To: References: <4DAC8B90.5070104@arin.net> Message-ID: On Mon, May 2, 2011 at 11:42 AM, John Curran wrote: > Matt - > > ?For clarity: ?"I'm down with this" means you support it? > > Thanks! > /John Sorry, yes. Too many early mornings leads to excessive use of colloquialisms. ^_^; "I support this draft proposal." :) Matt > > On May 2, 2011, at 8:01 PM, Matthew Petach wrote: >> On Mon, Apr 18, 2011 at 12:05 PM, ARIN wrote: >>> The ARIN Advisory Council (AC) met on 13 April 2011 and decided to >>> send a revised version of the following draft policy to last call: >>> >>> ?ARIN-2011-4: Reserved Pool for Critical Infrastructure >> >> I'm down with this as written. >> >> Matt >> _______________________________________________ >> 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 matthew at matthew.at Mon May 2 16:02:50 2011 From: matthew at matthew.at (Matthew Kaufman) Date: Mon, 2 May 2011 13:02:50 -0700 Subject: [arin-ppml] ARIN-prop-140 Business Failure Clarification In-Reply-To: <8D906FB6-D0FF-4106-88AE-6B12AB7CAD35@arin.net> References: <11050210594687_A4@oregon.uoregon.edu> <4CF8BEEF-4CFB-4EB6-B395-9CB1CEF8326B@matthew.at> <8D906FB6-D0FF-4106-88AE-6B12AB7CAD35@arin.net> Message-ID: <1BC551DF-B481-41D1-B83F-23DC5A74146D@matthew.at> On May 2, 2011, at 12:07 PM, John Curran wrote: > On May 2, 2011, at 8:20 PM, Matthew Kaufman wrote: >> ... >> I'm not a bankruptcy attorney either... this might need discussion. > > As part of trying to get staff input into the process earlier (as > discussed earlier in the week on this list), please note: > > 1) The policy proposal suggests "Potential confusion exists over the > requirement to return address space from a bankrupt entity. This is > a needed clarification to the policy manual" whereas this language > has not resulted in any actual confusion for ARIN staff. I'm sure it hasn't. But much of the discussion regarding (for instance) the Nortel-Microsoft transaction was that a plain-language reading of the NRPM by community members didn't match ARIN staff interpretation of the NRPM. I want it to be the case that anyone can flip open the NRPM, see the rule, and know that that's how things will be. So, in this case, the fact that the NRPM suggests that ARIN should be going after resources when a company goes bankrupt means that ARIN's actions *seem* to not match the policy (to anyone who reads the policy as requiring ARIN to do that). In other words I attribute the confusion here not to ARIN staff but to those who might be trying to figure out what ARIN might do in a given context based on what is written down in the NRPM. > > 2) ARIN must handle bankruptcies in compliance with appropriate law; > encoding a specific legal approach within policy is both ill-advised > and inconsistent with the Policy Development Process which states > that ARIN business practices are not policy matters. Yes, agreed. Perhaps that is a much better way of wording this policy so that the NRPM simply notes that ARIN will comply with applicable bankruptcy law and does not suggest that ARIN will be attempting to reclaim resources until they are really and truly "abandoned". Matthew Kaufman From matthew at matthew.at Mon May 2 16:05:59 2011 From: matthew at matthew.at (Matthew Kaufman) Date: Mon, 2 May 2011 13:05:59 -0700 Subject: [arin-ppml] ARIN-prop-140 Business Failure Clarification In-Reply-To: References: <4DBEF0DF.8060800@arin.net> Message-ID: <9BC4E3EC-E693-44D9-A415-A9E0F97E1BAA@matthew.at> On May 2, 2011, at 11:43 AM, William Herrin wrote: > On Mon, May 2, 2011 at 1:58 PM, ARIN wrote: >> ARIN-prop-140 Business Failure Clarification >> >> Add to end of Section 8.1: "Note that an entity which is reorganizing >> under any section of the US bankruptcy code (or foreign equivalent) is >> not 'out of business' for the purpose of interpreting this section" >> >> Rationale: >> >> Potential confusion exists over the requirement to return address space >> from a bankrupt entity. This is a needed clarification to the policy manual. > > Hi Matthew, > > If I understand properly, the language you object to in section 8.1 is: > > "Thus, if a company goes out of business, regardless of the reason, > the point of contact (POC) listed for the number resource does not > have the authority to sell, transfer, assign, or give the number > resource to any other person or organization. The POC must notify ARIN > if a business fails so the assigned number resources can be returned > to the available pool of number resources if a transfer is not > requested and justified." > > The main point of that paragraph is that if your company's network is > terminated (as part of a general company shutdown) you, as the POC, > don't get to keep the addresses as some kind of severance pay. Your > suggested text frankly just muddies the waters further. > > I would suggest replacing "goes out of business" with "ceases > operations" and just strike the last sentence entirely. My problem with it is actually "The POC must notify ARIN if a business fails so the assigned number resources can be returned to the available pool of number resources". Entering, for instance, US Chapter 7 bankruptcy is pretty clear evidence that "a business has failed" and yet there should be neither a requirement on the POC that they notify ARIN in such a case (well, actually, perhaps there should be... but usually the POC is long gone by then) nor a suggestion that ARIN will be returning addresses to the available pool any time soon. Matthew Kaufman From matthew at matthew.at Mon May 2 16:08:42 2011 From: matthew at matthew.at (Matthew Kaufman) Date: Mon, 2 May 2011 13:08:42 -0700 Subject: [arin-ppml] ARIN-prop-140 Business Failure Clarification In-Reply-To: References: <4DBEF0DF.8060800@arin.net> Message-ID: <949B31E1-F496-41B7-B00D-9E7160F3CF8D@matthew.at> On May 2, 2011, at 12:42 PM, William Herrin wrote: > On Mon, May 2, 2011 at 2:43 PM, William Herrin wrote: >> "Thus, if a company goes out of business, regardless of the reason, >> the point of contact (POC) listed for the number resource does not >> have the authority to sell, transfer, assign, or give the number >> resource to any other person or organization. The POC must notify ARIN >> if a business fails so the assigned number resources can be returned >> to the available pool of number resources if a transfer is not >> requested and justified." >> >> The main point of that paragraph is that if your company's network is >> terminated (as part of a general company shutdown) you, as the POC, >> don't get to keep the addresses as some kind of severance pay. Your >> suggested text frankly just muddies the waters further. > > Another suitable rewrite might replace those two sentences with: > > "An individual shall not have the authority to retain, sell, transfer, > assign, or give the number resource to any other person or > organization solely because he is listed as the point of contact for > an otherwise defunct organization, nor shall the organization cede > such authority to said individual except as is consistent with these > transfer policies." If that's the only point of this section then yes, your rewrite seems appropriate. But then it might be even better to simply have a section that explains that when you act as a POC you are acting for the organization and if you don't have the authority to do so then you shouldn't be acting as the POC either. But we'd still need to remove the suggestion that ARIN is able or supposed to be out reclaiming addresses from "failed" businesses before they're all the way dead. Again, my point being that I want people to be able to read the NRPM to predict what ARIN will do... in the case of a bankruptcy proceeding ARIN will NOT be going and reclaiming addresses all on their own, I suspect. Matthew Kaufman From matthew at matthew.at Mon May 2 16:13:53 2011 From: matthew at matthew.at (Matthew Kaufman) Date: Mon, 2 May 2011 13:13:53 -0700 Subject: [arin-ppml] ARIN-prop-145 STLS Listing Immunity In-Reply-To: References: <4DBEF116.1000400@arin.net> Message-ID: <53D491AB-BFBD-442A-A4EE-63FC24160282@matthew.at> On May 2, 2011, at 11:50 AM, Scott Leibrand wrote: > On Mon, May 2, 2011 at 10:59 AM, ARIN wrote: > ARIN-prop-145 STLS Listing Immunity > > > > Add a subsection to Section 12 (Resource Review) of the NRPM: > > ARIN may not revoke any resources issued by ARIN that are presently > listed as "available" on the ARIN Specified Transfer Listing Service > unless there is sufficient reason to believe that the holder does not in > fact intend to transfer these resources. > > Another way to accomplish this would be with the following language from the original transfer policy proposal, 2008-2: > > The fact that an IPv4 address holder is making IPv4 addresses available for transfer, pursuant to this policy, does not, in and of itself, indicate that the address holder lacks the need required for an allocation under ARIN policy. Sounds like it accomplishes basically the same thing, yes. (Only see below) > > > > Rationale: > > An entity may list space as available and might begin the process of > moving out of that space in order to facilitate the transfer. A review > after such work was in progress might reveal that the addresses are not > sufficiently utilized. > > Additionally, because posting a listing on the STLS signals directly to > ARIN that an entity believes it can use addresses more efficiently, ARIN > might simply use STLS listings in order to trigger audit under 12.2(c). > This would not be fair. (And would be a disincentive to using the ARIN > STLS at all in order to list available space) > > I believe that ARIN has made assurances that this will not be done, but I would support such assurances into policy as well if people think it's needed. I think it should be written down somewhere, preferably in a place that is changed based on community involvement (rather than simply the STLS FAQ) in order to keep people from worrying that listing their addresses might trigger an audit. Note that this applies to all listing services, but *particularly* to STLS, as the listing on STLS is a direct statement TO ARIN that the org thinks it can use its address space more efficiently (which an indirect statement, as on eBay, or a hidden statement, as via a 3rd party soliciting bids does not) > > This policy would also serve to increase the value of the ARIN STLS over > other possible transfer listing services, increasing the transparency of > the transfer market, particularly to ARIN, who wishes to ensure that > transfers take place within NRPM 8.3. > > > I think it's important to make any "Safe Harbor" statement apply to all IPv4 addresses being made available for transfer (including those on eBay etc.) not just those offered through ARIN's Specified Transfer Listing Service. ARIN has repeatedly made clear that the STLS is completely optional, which I believe is the right way to approach it. I don't believe we should be giving the STLS preferential treatment in the transfer policy in any way. Interesting point of debate. I wrote this to give STLS an advantage over other listing services because I believe that a single marketplace leads to a more efficient market, particularly in the case where there are so few transactions taking place. This also plays well into the alternative idea that you'd sell them on eBay perhaps but only *after* both signaling your intent to do so to ARIN (by listing on STLS) and at the same time receiving certification that ARIN really believes the addresses are yours to transfer. It is in ARIN's best interest to know about transactions BEFORE they take place. Granting immunity would be one of the incentives for telling ARIN directly. Matthew Kaufman -------------- next part -------------- An HTML attachment was scrubbed... URL: From dogwallah at gmail.com Mon May 2 16:19:24 2011 From: dogwallah at gmail.com (McTim) Date: Mon, 2 May 2011 23:19:24 +0300 Subject: [arin-ppml] Accusation of fundamental conflictofinterest/IPaddresspolicy pitched directly to ICANN In-Reply-To: <921C6A7057A94379A7D4267C47D2ABEC@mike> References: <4DBEE79C.6030007@globis.net> <4DBEFDC0.3070705@globis.net> <4DBF09D8.7020206@globis.net> <4DBF0BAC.6040703@globis.net> <921C6A7057A94379A7D4267C47D2ABEC@mike> Message-ID: On Mon, May 2, 2011 at 11:02 PM, Mike Burns wrote: > > Why not an open and transparent marketplace free from artifical and > easily-scammable justification regimes? Because many thousands of people over many years have determined these policies (your "artifical and easily-scammable justification regimes) via open, transparent, consensus based processes. They have not (yet) determined that a open and transparent market is a better option. -- 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 Mon May 2 16:26:09 2011 From: bill at herrin.us (William Herrin) Date: Mon, 2 May 2011 16:26:09 -0400 Subject: [arin-ppml] ARIN-2011-5: Shared Transition Space for IPv4 Address Extension - Last Call In-Reply-To: <54E900DC635DAB4DB7A6D799B3C4CD8E10C89AC7@PDAWM12B.ad.sprint.com> References: <4DAC8BCB.2000300@arin.net> <54E900DC635DAB4DB7A6D799B3C4CD8E10C7EF5E@PLSWM12A.ad.sprint.com> <3128593549961341875@unknownmsgid> <54E900DC635DAB4DB7A6D799B3C4CD8E10C899B7@PDAWM12B.ad.sprint.com> <1489147144792938659@unknownmsgid> <54E900DC635DAB4DB7A6D799B3C4CD8E10C89AC7@PDAWM12B.ad.sprint.com> Message-ID: On Mon, Apr 25, 2011 at 8:46 AM, George, Wes E [NTK] wrote: > IPv4 addresses used behind a NAT (inside pool) cannot be > used for justification of new resources nor counted towards > utilization calculations for existing resources. > NRPM 4.10.x (Shared Transition Space) defines a specific > non-unique block to ?be shared among multiple networks > for this purpose. Hi Wes, So if I have addresses inside a NAT today, I want to move them outside the NAT and I'm willing to cough up the money for a transfer, I should be denied because the addresses at issue are currently used behind a NAT? I'm sure we can fix this language so that it does what you intend, but that will take time and debate. So, let's take the time and get it right. Let's get 2011-5 on the books as it stands and then let's figure out a good way to rebalance the the justified need concept around its existence. 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 Mon May 2 16:30:44 2011 From: Daniel_Alexander at Cable.Comcast.com (Alexander, Daniel) Date: Mon, 2 May 2011 20:30:44 +0000 Subject: [arin-ppml] Accusation of fundamental conflict ofinterest/IPaddress policy pitched directly to ICANN In-Reply-To: <35F0C71BD6974F21A3C296005F0DDA0F@mike> Message-ID: Mike, While I can only speak for myself, I can attempt to answer your question of what may perturb some people. You make several very large assumptions in your claims, none of which were captured in the opt-in, opt-out, or any other proposals. You speak of title insurance, legal teams, and other items, ensuring that a competitive registry will provide better services than a community defined RIR. The problem is none of this is defined or required in any suggested framework. While some may provide these services, many may not, and there are no mechanisms to protect the ISP's or end users who rely on these services. While many advocates will quickly reply that the market will sort these bad actors out, it will be done at the expense of the people who currently rely on these RIR provided services at a fraction of the cost. If competitive registries are created without oversight, the burden and expense of validating registration records will be shifted to the very people who are supposed to benefit from this new model. This begs the question from some as to what purpose a commercial registry would serve other than to make money. My opinion only. Dan Alexander On 5/2/11 3:33 PM, "Mike Burns" wrote: > > >>But what is it about ARIN that is broken? What exactly do you think >>needs >>to be fixed? > >>The only thing I've gotten out of the discussions so far is that some >>people think there is money to be made by providing IPv4 addresses based >>on >>willingness and ability to pay rather than ARIN's current >demonstrated >>need policies. > >>Why is it to my benefit if someone else makes money? Particularly if it >>perturbs the current mechanisms in a way that costs me money? > >>Keith Hare > > >Hi Keith, > >What is broken about ARIN is that scandalously large numbers of netblocks >do >not have valid POCs, for example. The stewardship of Whois leaves a lot >to >be desired. >Competitive pressures would help to finally decide who controls these >addresses and allow them to be transferred to those who would pay for >them. >Network operators don't really have much of a choice in accessing Whois >information to determine the rights to advertise addresses, and competive >registries. >In my experience they rely on attestation and review of proferred >chain-of-custody docs when determining who can advertise which addresses, >when confronted with inconsistencies with whois. >A competitive registry with a title insurance component will give network >operators more security when deciding questionable cases. > >What is broken about ARIN is that their transfer policies are more >restrictive than APNICs, and that will cause a flow of addresses out of >ARIN >and into APNIC. >A competitive registry could presumably have a different transfer policy, >as >APNICs differs from ARINs. > >What is broken about ARIN is that ARIN has professed no statutory control >over legacy addresses in the Plzak declaration in the Kremen case, and >yet >attempts to control the registration of legacy resources. >With a private registry, the address rights holders can choose to opt-out >of >ARIN's dictats and choose their registry voluntarily. > >I don't see how the creation of a private registry will perturb the >current >mechanisms in a way that costs you money, could you share why you feel >that >way? > >Regards, > >Mike Burns > >_______________________________________________ >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 mike at nationwideinc.com Mon May 2 16:31:31 2011 From: mike at nationwideinc.com (Mike Burns) Date: Mon, 2 May 2011 16:31:31 -0400 Subject: [arin-ppml] Accusation of fundamental conflictofinterest/IPaddresspolicy pitched directly to ICANN References: <4DBEE79C.6030007@globis.net> <4DBEFDC0.3070705@globis.net> <4DBF09D8.7020206@globis.net> <4DBF0BAC.6040703@globis.net> <921C6A7057A94379A7D4267C47D2ABEC@mike> Message-ID: > > Why not an open and transparent marketplace free from artifical and > easily-scammable justification regimes? Because many thousands of people over many years have determined these policies (your "artifical and easily-scammable justification regimes) via open, transparent, consensus based processes. They have not (yet) determined that a open and transparent market is a better option. -- Cheers, Mc Tim Hi Mc Tim, But all these people have acted in a world with a pool of free addresses which is close to dry. That world is gone. Well going, anyways. Regards, Mike From owen at delong.com Mon May 2 16:32:43 2011 From: owen at delong.com (Owen DeLong) Date: Mon, 2 May 2011 13:32:43 -0700 Subject: [arin-ppml] Statistics regarding NRPM 8.3 Transfers to date In-Reply-To: References: <75E9BD24-F12F-42BF-A989-CF6CC282B28E@arin.net> <7406316661701612155@unknownmsgid> <3F57F52B-F1F1-4450-B493-AA4D544D8D15@arin.net> <8740380157159276993@unknownmsgid> <49E26DCB-DAF7-4A0A-912E-F981494979F5@delong.com> <4DBC2AEB.9040307@matthew.at> <4DBCA58D.4060704@sprunk.org> <2344ADD7-616E-4FA7-9552-19735926A952@delong.com> Message-ID: On May 1, 2011, at 9:25 AM, John Curran wrote: > On May 1, 2011, at 6:05 PM, Owen DeLong wrote: > >>> Imagine you qualify to receive a /23 but there are no /23s available on >>> the market. AIUI, the policy's intent was to prohibit you buying half >>> of someone else's /22. However, is there any harm in ARIN fulfilling >>> your request with my two disjoint /24s in that scenario? Keep in mind >>> you could get my /24s (or one from me and one from someone else) anyway >>> via two separate transfer requests. >>> >> No, that intent went out the window early in the debate. It was replaced with >> an intent to prevent you from creating a /18 equivalent out of disparate /24 sized >> chunks of someone else's /8. > >>> This interpretation, which could be creatively read into the policy >>> text, could easily explain the statistics recently posted and, IMHO, >>> doesn't violate the policy's intent or goals. >>> >> While I would be fine with ARIN fulfilling your request with 2 /24s that were already >> disjoint, however, I don't want to see someone with, say, 44/8 find a buyer that needs >> a /20 and sell them 44.0.5/24, 44.0.8/24, 44.15.23/24, 44.28.6/24, etc. > > Owen - > > Please elaborate. The phrase "single aggregate", if moved to the > resources transferred clause, would definitely preclude the example > that Stephen provides. > > /John Agreed... I think that the original intent was to preclude it, but, I agree that intent isn't necessarily in the community interest. So... I'll try to provide some examples of what should and shouldn't be allowed... 1. Org. A has a /8 and wants to transfer 32 of it's constituent /24s to Org. B. However, Org. A doesn't want to put any effort into renumbering, so, those 32 /24s are each individual non-aggregable /24s. This transfer should not be allowed. 2. Org. A has a /20 and a /18. Org. B has need for a /19. Org. A has deprecated their use of the /20 and all of their resources are in the /18, but, they are using just under 75% of the /18. Org. A would rather transfer the /20 and the top 1/4 of the /18 than renumber that 1/4 of the /18 into the /20. This transfer should not be allowed (though I admit the case against it is weak). 3. Org. A has four disparate /20s. Org B. has need of a /19. Org. A would like to transfer two of their /20s to Org. B, but does not have any pair of /20s which can be aggregated. This transfer should be allowed. The /20s are already disaggregated in the routing table and there is no increase in routing table size that results. 4. Org. A has four disparate /20s. Orgs. B, C, D, and E all have need for /24s. Org. A would like to sell individual /24s from one of their /20s to each of the above Orgs. (B,C, D, and E). These transfers should be allowed as there is no significant difference between this and transfers where ARIN has carved up a block during the initial allocations. The transfer sizes comply with community accepted policy. In essence, I'm trying to say that transfers which create unnecessary additional disaggregation should be avoided. Owen From v6ops at globis.net Mon May 2 16:36:32 2011 From: v6ops at globis.net (Ray Hunter) Date: Mon, 02 May 2011 22:36:32 +0200 Subject: [arin-ppml] Accusation of fundamental conflictofinterest/IPaddresspolicy pitched directly to ICANN In-Reply-To: <921C6A7057A94379A7D4267C47D2ABEC@mike> References: <4DBEE79C.6030007@globis.net><4DBEFDC0.3070705@globis.net><96AF0FBE0B5A40CFB80 A34CA2FF86FCA@mike><4DBF09D8.7020206@globis.net> <4DBF0BAC.6040703@globis.net> <921C6A7057A94379A7D4267C47D2ABEC@mike> Message-ID: <4DBF15D0.1020901@globis.net> I am merely pointing out that a market based approach is highly unlikely to succeed in a consensus-based Internet, and that it brings a number of serious risks. I think I have established that quite clearly. Many in the ARIN community think that ARIN have the authority to reclaim allocations if they are no longer needed. The debate over address "ownership" and "value" will probably continue. Possibly in the courts. Jeffery Lyon hits the nail on the head: > Why would ARIN want to allow sales of space outside the region? > -- Jeffrey Lyon, Leadership Team Because otherwise the WTO might get involved, as it could be construed as an unfair restriction on trade that China and India have fewer IPv4 addresses than people, whereas the US has a 5:1 ratio, and now China and India are being asked to pay for more IPv4 addresses or can't get hold of them at all? PS Do you think the Ben Bernanke idea might have legs? regards, RayH Mike Burns wrote: > Now you would ask ARIN not only whether the addresses are justified in > their opinion, but also to judge the financial motivations of the > participants? > Under what policy would ARIN be able to have legacy addresses returned > to the free pool as you describe? > In fact, the MS/Nortel deal is not the only transaction that has > occurred, and the existence of tradeipv4.com and other sites is > testimony to the likelihood it will happen again, policy or no policy. > Who knows which 80 companies were contacted? Wouldn't it be better if > the whole thing was conducted in the open, so that ChinaTelecom could > bid as well? > Why not an open and transparent marketplace free from artifical and > easily-scammable justification regimes? > Regards, > MIke > > In fact one could very succinctly argue that precisely this > example could/should trigger the ARIN / ICANN community to now > officially adopt a tighter /explicit policy like example #7 I > mentioned. > > 7) Ask ARIN to prevent any and all transfers that are motivated > purely by financial gain, and instead insist that such > participants return IPv4 allocations to the unallocated pool "for > the benefit of the Internet Community" once the existing > allocation is no longer needed. > > Ray > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Wesley.E.George at sprint.com Mon May 2 16:39:48 2011 From: Wesley.E.George at sprint.com (George, Wes E [NTK]) Date: Mon, 2 May 2011 20:39:48 +0000 Subject: [arin-ppml] ARIN-2011-5: Shared Transition Space for IPv4 Address Extension - Last Call In-Reply-To: References: <4DAC8BCB.2000300@arin.net> <54E900DC635DAB4DB7A6D799B3C4CD8E10C7EF5E@PLSWM12A.ad.sprint.com> <3128593549961341875@unknownmsgid> <54E900DC635DAB4DB7A6D799B3C4CD8E10C899B7@PDAWM12B.ad.sprint.com> <1489147144792938659@unknownmsgid> <54E900DC635DAB4DB7A6D799B3C4CD8E10C89AC7@PDAWM12B.ad.sprint.com> Message-ID: <54E900DC635DAB4DB7A6D799B3C4CD8E10C8D92B@PDAWM12B.ad.sprint.com> I don't understand your example, specifically how a transfer would figure into the discussion. Please try to rephrase. Ultimately, it's going to be up to the AC to wordsmith this as necessary to cover our concerns, but I would hope that the spirit of my recommendation is clear. I remain convinced that something should make it into this version of the policy, not wait for subsequent policy action. Wes -----Original Message----- From: wherrin at gmail.com [mailto:wherrin at gmail.com] On Behalf Of William Herrin Sent: Monday, May 02, 2011 4:26 PM To: George, Wes E [NTK] Cc: Scott Leibrand; arin-ppml at arin.net Subject: Re: [arin-ppml] ARIN-2011-5: Shared Transition Space for IPv4 Address Extension - Last Call On Mon, Apr 25, 2011 at 8:46 AM, George, Wes E [NTK] wrote: > IPv4 addresses used behind a NAT (inside pool) cannot be used for > justification of new resources nor counted towards utilization > calculations for existing resources. > NRPM 4.10.x (Shared Transition Space) defines a specific non-unique > block to ?be shared among multiple networks for this purpose. Hi Wes, So if I have addresses inside a NAT today, I want to move them outside the NAT and I'm willing to cough up the money for a transfer, I should be denied because the addresses at issue are currently used behind a NAT? I'm sure we can fix this language so that it does what you intend, but that will take time and debate. So, let's take the time and get it right. Let's get 2011-5 on the books as it stands and then let's figure out a good way to rebalance the the justified need concept around its existence. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 6753 bytes Desc: not available URL: From owen at delong.com Mon May 2 16:37:23 2011 From: owen at delong.com (Owen DeLong) Date: Mon, 2 May 2011 13:37:23 -0700 Subject: [arin-ppml] REVISED Statistics regarding NRPM 8.3 Transfers to date In-Reply-To: <6389E6EC-7D1F-4CDA-8370-2ECB83D36029@arin.net> References: <75E9BD24-F12F-42BF-A989-CF6CC282B28E@arin.net> <6389E6EC-7D1F-4CDA-8370-2ECB83D36029@arin.net> Message-ID: <156290C5-32B9-45C0-941A-ADF93E278149@delong.com> Can you provide the data for the 11th completed transfer along the same lines as what was provided for the other 10 below, please? Thanks, Owen On May 1, 2011, at 10:16 AM, John Curran wrote: > On Apr 29, 2011, at 7:08 PM, John Curran wrote: > >> To date, there have been 10 completed specified transfers under NRPM 8.3: >> >> Distribution of IPv4 Resources transferred: >> >> 1 /17 >> 3 /20s >> 1 /21 >> 1 /23 >> 49 /24s > > PPML Readers - > > I'm going to expand on the above for sake of clarity, as it occurs to > me that the provided summary was not at all useful for analysis as > we combined any resources that were not a clean CIDR block > boundary into the "49 /24s" entry at the end of the list. > > There were 10 specified transfers total. The recipients received > the following aggregates (one recipient per line, all under RSA) - > > (1) /24 > (1) /24 > (1) /23 > (1) /17 > (2) /20 > (1) /22, (2) /23 > (1) /20, (1) /21, (2) /22, (2) /23 > (1) /20 > (1) /21 > (1) /23, (1) /24 > > In some cases, the transfers were record keeping in nature (e.g. > an entity recording specified transfer of an address lock already > in use by another related entity) Additionally, in many cases the > smaller blocks are actually contiguous but not aligned on a CIDR > block boundary (e.g. a large block with smaller blocks on either > side being reported as 3 distinct transferred aggregates) > > I hope this helps, and we will keep trying to provide better insight > into use of the NRPM 8.3 specified transfer policy. > > Thanks! > /John > > John Curran > President and CEO > ARIN > > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike at nationwideinc.com Mon May 2 16:41:33 2011 From: mike at nationwideinc.com (Mike Burns) Date: Mon, 2 May 2011 16:41:33 -0400 Subject: [arin-ppml] Accusation of fundamental conflictofinterest/IPaddress policy pitched directly to ICANN References: Message-ID: <7646B57F7F154B028E6722D103BB57C2@mike> Hi Dan, The existence of competing registries does not imply a requirement on anybody to change, so your argument about expense to existing participants is invalid. And yes, the market will sort out bad actors. That's one thing free markets do. Nobody said anything about no oversight, to the contrary I have said the registries should work under the same framework as RIRs. Just like all DNS registrars have to comply with rules setup to govern their behavior. Before you can be a DNS registrar you have to comply with the rules, and maintain compliance. It's true that I was being forward thinking about the additional services competing registries might offer, but my point is that those services would only be offered if there was a demand for them, if the private registries are to endure. Regards, Mike ----- Original Message ----- From: "Alexander, Daniel" To: "Mike Burns" ; Sent: Monday, May 02, 2011 4:30 PM Subject: Re: [arin-ppml] Accusation of fundamental conflictofinterest/IPaddress policy pitched directly to ICANN Mike, While I can only speak for myself, I can attempt to answer your question of what may perturb some people. You make several very large assumptions in your claims, none of which were captured in the opt-in, opt-out, or any other proposals. You speak of title insurance, legal teams, and other items, ensuring that a competitive registry will provide better services than a community defined RIR. The problem is none of this is defined or required in any suggested framework. While some may provide these services, many may not, and there are no mechanisms to protect the ISP's or end users who rely on these services. While many advocates will quickly reply that the market will sort these bad actors out, it will be done at the expense of the people who currently rely on these RIR provided services at a fraction of the cost. If competitive registries are created without oversight, the burden and expense of validating registration records will be shifted to the very people who are supposed to benefit from this new model. This begs the question from some as to what purpose a commercial registry would serve other than to make money. My opinion only. Dan Alexander On 5/2/11 3:33 PM, "Mike Burns" wrote: > > >>But what is it about ARIN that is broken? What exactly do you think >>needs >>to be fixed? > >>The only thing I've gotten out of the discussions so far is that some >>people think there is money to be made by providing IPv4 addresses based >>on >>willingness and ability to pay rather than ARIN's current >demonstrated >>need policies. > >>Why is it to my benefit if someone else makes money? Particularly if it >>perturbs the current mechanisms in a way that costs me money? > >>Keith Hare > > >Hi Keith, > >What is broken about ARIN is that scandalously large numbers of netblocks >do >not have valid POCs, for example. The stewardship of Whois leaves a lot >to >be desired. >Competitive pressures would help to finally decide who controls these >addresses and allow them to be transferred to those who would pay for >them. >Network operators don't really have much of a choice in accessing Whois >information to determine the rights to advertise addresses, and competive >registries. >In my experience they rely on attestation and review of proferred >chain-of-custody docs when determining who can advertise which addresses, >when confronted with inconsistencies with whois. >A competitive registry with a title insurance component will give network >operators more security when deciding questionable cases. > >What is broken about ARIN is that their transfer policies are more >restrictive than APNICs, and that will cause a flow of addresses out of >ARIN >and into APNIC. >A competitive registry could presumably have a different transfer policy, >as >APNICs differs from ARINs. > >What is broken about ARIN is that ARIN has professed no statutory control >over legacy addresses in the Plzak declaration in the Kremen case, and >yet >attempts to control the registration of legacy resources. >With a private registry, the address rights holders can choose to opt-out >of >ARIN's dictats and choose their registry voluntarily. > >I don't see how the creation of a private registry will perturb the >current >mechanisms in a way that costs you money, could you share why you feel >that >way? > >Regards, > >Mike Burns > >_______________________________________________ >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 2 16:41:45 2011 From: owen at delong.com (Owen DeLong) Date: Mon, 2 May 2011 13:41:45 -0700 Subject: [arin-ppml] Statistics regarding NRPM 8.3 Transfers to date In-Reply-To: <4DBD9BF5.7050002@sprunk.org> References: <75E9BD24-F12F-42BF-A989-CF6CC282B28E@arin.net> <7406316661701612155@unknownmsgid> <3F57F52B-F1F1-4450-B493-AA4D544D8D15@arin.net> <8740380157159276993@unknownmsgid> <49E26DCB-DAF7-4A0A-912E-F981494979F5@delong.com> <4DBC2AEB.9040307@matthew.at> <4DBCA58D.4060704@sprunk.org> <2344ADD7-616E-4FA7-9552-19735926A952@delong.com> <4DBD9BF5.7050002@sprunk.org> Message-ID: On May 1, 2011, at 10:44 AM, Stephen Sprunk wrote: > On 01-May-11 11:05, Owen DeLong wrote: >> On Apr 30, 2011, at 17:13, Stephen Sprunk wrote: >>> On 30-Apr-11 10:40, Owen DeLong wrote: >>>> On Apr 30, 2011, at 8:29 AM, Matthew Kaufman wrote: >>>>> And then once you've justified 980 addresses to ARIN, you should clearly be able to use 8.3 transfers twice in a row, for two separate /23s... it wouldn't make much sense for ARIN to require you to resubmit all the justification paperwork you just sent them a few hours ago, would it? >>>> Again, I disagree. The intent of this phrase was to reduce the amount of disaggregation of the routing table that will be caused by transfers. Allowing this revolving door use of the transfer policy will increase disaggregation. >>> Imagine you qualify to receive a /23 but there are no /23s available on the market. AIUI, the policy's intent was to prohibit you buying half of someone else's /22. However, is there any harm in ARIN fulfilling your request with my two disjoint /24s in that scenario? Keep in mind you could get my /24s (or one from me and one from someone else) anyway via two separate transfer requests. >> No, that intent went out the window early in the debate. It was replaced with an intent to prevent you from creating a /18 equivalent out of disparate /24 sized chunks of someone else's /8. > > Hmm. I was concerned about the latter as well, but I didn't realize we > had agreed to allow deaggregation in the first place. That makes things > easier. > >>> This interpretation, which could be creatively read into the policy text, could easily explain the statistics recently posted and, IMHO, doesn't violate the policy's intent or goals. >> While I would be fine with ARIN fulfilling your request with 2 /24s that were already disjoint, however, I don't want to see someone with, say, 44/8 find a buyer that needs a /20 and sell them 44.0.5/24, 44.0.8/24, 44.15.23/24, 44.28.6/24, etc. > > How about this: > > "The transferor's resources may be recursively bisected the minimum > number of times necessary to create one CIDR block equal to the > transferee's justified need." > > So, if someone with a /8 wants to sell you a /20, their /8 would be > divided into one /9, one /10, one /11, one /12, one /13, one /14, one > /15, one /16, one /17, one /18, one /19 and two /20s, and then you would > get one of those /20s. > I believe that would be acceptable, but I would need to know how staff would interpret the language and some assurance that said statement of interpretation would be binding. (Would staff interpretation of the former paragraph match the example in the latter?) How would it perform against the examples I posted a few moments ago? (Since we thought we understood how staff would interpret 8.3 at the time and it turned out not to work as we thought). > If you agree with that, I'll figure out how to shoehorn it into the > existing text of NRPM 8.3, though I'd prefer a complete restructuring. > This intrigues me. Please elaborate on your desired restructuring? > I also see several ugly possibilities when the transferor has multiple > blocks of different sizes available to sell, but I'd need to see > examples of how you'd want those handled before I could address them (no > pun intended). However, assuming that aggregation has inherent value to > buyers, sellers will avoid them out of self-interest, so we may not need > to put anything into policy. Is anyone seriously concerned that > assumption is wrong? > I posted some examples a few minutes ago. Hopefully those will help. Let me know if you ned something else. I am very concerned that your assumption about the value of aggregation to buyers is wrong. Owen -------------- next part -------------- An HTML attachment was scrubbed... URL: From jeffrey.lyon at blacklotus.net Mon May 2 16:58:55 2011 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Mon, 2 May 2011 16:58:55 -0400 Subject: [arin-ppml] New Entrants shut out? (Was: ARIN-2011-5: ... - Last Call In-Reply-To: <92CDFD35-7489-4037-A8C7-1CB344A9F091@delong.com> References: <4DBAF9E2.80000@globis.net> <4DBB305F.3010205@umn.edu> <4DBB41AE.20007@ipinc.net> <412B69ED-0D49-4F1A-806C-4F250C64EAED@delong.com> <07C619E6-58E3-41FF-81EC-6BA23BDA7391@delong.com> <35A3C7E4-5FA6-46BE-B14C-E2F97579CE8D@delong.com> <79CCE0F1-EF17-495B-AC28-9495052013EB@delong.com> <92CDFD35-7489-4037-A8C7-1CB344A9F091@delong.com> Message-ID: On Mon, May 2, 2011 at 2:59 PM, Owen DeLong wrote: > > On Apr 30, 2011, at 12:50 PM, Jeffrey Lyon wrote: > >> On Sat, Apr 30, 2011 at 3:28 PM, Owen DeLong wrote: >>> >>> >>> Jimmy, >>> >>> At the moment we have a system that favors small players at the >>> expense of commerce. It also fails to create economic incentives to >>> migrate to IPv6. Note that C-Squad execs speak dollars, not value to >>> the community. >>> >>> I would argue that the current system appears to be creating quite a few >>> incentives to add IPv6 capabilities if you look at the current uptick in v6 >>> statistics since Feb. 3. >>> >>> So long as we continue to squeeze blood out of the IPv4 turnip, >>> companies will continue to delay IPv6. The choices become the Lyon >>> strategy of letting the market set the price and encourage natural >>> migration, or the Owen strategy of taking IPv4 off life support. >>> >>> I don't think it is on life support and I think a natural evolution is >>> occurring. Some organizations which are unable to look beyond short term >>> dollars will have faster and more disruptive migration processes while >>> others with better vision have been planning and executing their migration >>> strategies for years. >>> The longer you wait, the more rushed, expensive, and disruptive your >>> inevitable transition will be. >>> Owen >>> >> >> Owen, >> >> I agree that there are some incentives to migrate to IPv6 and that >> companies who wait will suffer. My point is that these incentives are >> not economic in nature which is what will be necessary to motivate >> companies to act. Companies are the driving force behind either >> creating or removing roadblocks to adoption (eg. carrier support, >> vendor support, and so forth). >> > I will say that not ALL incentives are economic in nature. > > However, the economy of failing to implement IPv6 is a pretty > strong incentive if you fully understand the results. > > Becoming increasingly disconnected from more and more of your > potential customer base should, for any rational business, create > a strong economic incentive to do something different. That is the > inevitable result of remaining IPv4-only. > > Further, the costs at the carrier and the subscriber level of continuing > to attempt to maintain some level of connectivity to a growing > internet incapable of producing additional IPv4 addresses for those > new connections will significantly increase the costs of remaining > on IPv4 and keeping it functional. These costs are only increased > by failing to add IPv6 capabilities. > >> I fundamentally disagree that we should taking the position of >> "migrate now or suffer later," rather create the economic incentive >> for a natural progression to IPv6 without having to twist any arms or >> cause any suffering. >> > Huh? > > 1. ? ? ?I think that migrate now is a misnomer. What I am saying is > ? ? ? ?"Add IPv6 capabilities to your network now, or, you will, > ? ? ? ?inevitably suffer later." > > ? ? ? ?That's not to say I am trying to cause that suffering or that > ? ? ? ?anyone is out to inflict additional suffering on those who > ? ? ? ?fail to add IPv6 capabilities. The NATURAL CONSEQUENCE > ? ? ? ?of failing to adapt to a changing and growing internet is > ? ? ? ?suffering. It will happen to those that do not add IPv6 > ? ? ? ?capabilities no matter what anyone else does or does not > ? ? ? ?do. > > 2. ? ? ?There is already a great deal of economic incentive there > ? ? ? ?for anyone who takes the time to understand the economics > ? ? ? ?of the situation. IPv4 will inevitably become increasingly > ? ? ? ?more costly. > > ? ? ? ?This policy is intended to allow a single /10 to be used > ? ? ? ?for purposes that will otherwise require multiple providers > ? ? ? ?to collectively use much more than one /10 and will ultimately > ? ? ? ?result in accelerating the time at which IPv4 becomes > ? ? ? ?more expensive and accelerating and increasing the > ? ? ? ?resulting suffering. > >> Very rarely are technologies widely adopted on account of a decree. >> Successful adoption occurs when migrating to a new technology is an >> all around attractive prospect. I would be willing to hypothesize that >> there are about equal numbers of people who want immediate adoption of >> IPv6 and those who want to see IPv4 continue to survive for a number >> of years, at least until IPv6 can gain a more stable footing. >> > I think I can say that almost everyone wishes that IPv4 could continue to survive > for many more years. I wish that were true. > > I think, instead, you can say that there is some disagreement among professionals > as to whether this is actually a viable strategy or not. > > I don't know of anyone among the IPv6 cheerleading crowd (and I'm pretty > sure I have about as much of an IPv6 cheerleader perspective as anyone) > who wouldn't love to see a way for IPv4 to provide a real solution to continued > growth in the internet without the disruption or inconvenience or costs of > deploying a new protocol. The difference comes in the subtlety of what > people are willing to accept as a "real solution". > > Some of us want to see the internet continue to be able to provide at least > the services and capabilities that exist today. Some are willing to accept > a greatly reduced subset. Some of us want to see expansion and continued > innovation. > > For the first camp (existing capabilities), IPv4 has a very limited lifespan, > but, until the RIRs all run out and maybe even for a few months thereafter, > we can kind of limp along and keep that somewhat functional. > > For the second camp, there is NAT444 and if you are willing to reduce the > internet to basic HTTP/HTTPs and SMTP and little else, then, you can > probably keep IPv4 somewhat serviceable for a few more years. > > Finally, for the third camp, there really is no remaining viability in IPv4. > The end-to-end model failed with the introduction of NAT. The peer to > peer nature has been reduced to the consumer/provider model as > a result and services which people want (remote access to resources > at home, for example) have to involve rendezvous servers hosted by > other providers to be made possible. There are so many cool things > that we already know how to do and have the technology for that > cannot be implemented for lack of end-to-end connections that I > think there is additional economic incentive available here as well. > > Indeed, the question is not whether or not IPv6 has economic > incentives. The question is how to best explain and convey those > economic incentives to the CxOs of the world. > > In the meantime, this policy seeks to provide a way that many providers can > coordinate their use of a very limited amount of IPv4 space for a > specific purpose rather than requiring each of them to get their own > distinct space for this purpose. > > Owen > > Owen, I get the feeling that you see IPv4 as a lame horse that needs to be taken out back. While that's certainly one approach, my logic has always been to allow the free exchange of IPv4 until such a time that it becomes naturally cost prohibitive. CxO's talk $, and letting the market make IPv4 costly is a quick and dirty way to convey the benefits of IPv6. At the risk of getting too far off track, I give you this scenario. There may be major ISP's who were early entrants and managed to obtain more IP's than they ever really needed. Perhaps they have austerity plans that allow them to keep chugging on IPv4 for years. Perhaps their fellow competitors will do the same and IPv6 will fail to gain immediate traction. It seems that only small to medium sized businesses are taking IPv6 seriously. Advertising IPv6 support seems like more of a marketing gimmick than a realistic push for support by many companies. -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications - AS32421 First and Leading in DDoS Protection Solutions From jcurran at arin.net Mon May 2 16:59:11 2011 From: jcurran at arin.net (John Curran) Date: Mon, 2 May 2011 20:59:11 +0000 Subject: [arin-ppml] ARIN-prop-140 Business Failure Clarification In-Reply-To: <1BC551DF-B481-41D1-B83F-23DC5A74146D@matthew.at> References: <11050210594687_A4@oregon.uoregon.edu> <4CF8BEEF-4CFB-4EB6-B395-9CB1CEF8326B@matthew.at> <8D906FB6-D0FF-4106-88AE-6B12AB7CAD35@arin.net> <1BC551DF-B481-41D1-B83F-23DC5A74146D@matthew.at> Message-ID: <2F53103F-DBF6-4DAF-BAF3-0C9EEB1BD999@arin.net> On May 2, 2011, at 10:02 PM, Matthew Kaufman wrote: > I want it to be the case that anyone can flip open the NRPM, see the rule, and know that that's how things will be. Alas, we cannot provide meaningful legal advice to parties via the NRPM, and yet a party going into bankruptcy cannot know "how things will be" until comparing their circumstances to applicable law. > So, in this case, the fact that the NRPM suggests that ARIN should be going after resources when a company goes bankrupt means that ARIN's actions *seem* to not match the policy (to anyone who reads the policy as requiring ARIN to do that). Per 8.1 presently, the POC notifies ARIN. Depending on circumstances, ARIN may be able to reclaim the resources or not. If your consulting business is no more, with no creditors at your door, we are likely able to do so. If it is an entity entering various bankruptcy proceedings, the exact circumstances are necessary to know what happens next. > In other words I attribute the confusion here not to ARIN staff but to those who might be trying to figure out what ARIN might do in a given context based on what is written down in the NRPM. We can put anything we want in the NRPM; it will not clarify the matter for a party entering reorganization; e.g. if number resources are necessary for ongoing operations, they may be executory in nature and subject to an entirely different set of guidelines then if they are not essential. The number resources may not be considered an asset, or they might, and in either case may be considered separable from ARIN's services and policies (or not). >> 2) ARIN must handle bankruptcies in compliance with appropriate law; >> encoding a specific legal approach within policy is both ill-advised >> and inconsistent with the Policy Development Process which states >> that ARIN business practices are not policy matters. > > Yes, agreed. > > Perhaps that is a much better way of wording this policy so that the NRPM simply notes that ARIN will comply with applicable bankruptcy law and does not suggest that ARIN will be attempting to reclaim resources until they are really and truly "abandoned". Compliance with law is a good thing, but as expected is already included in the direction I've received from the ARIN Board. The only guidance that would help ARIN in this matter is whether (in light of the existence of a specified transfer policy) you would like ARIN to always work first towards return of resources, and if/when that's not possible to then advise of transfers per 8.3, or whether we are to omit reclamation efforts (where it may be an option) and always direct any legitimate parties to NRPM 8.3 transfers. Hope this helps, /John John Curran President and CEO ARIN From jcurran at arin.net Mon May 2 17:01:23 2011 From: jcurran at arin.net (John Curran) Date: Mon, 2 May 2011 21:01:23 +0000 Subject: [arin-ppml] REVISED Statistics regarding NRPM 8.3 Transfers to date In-Reply-To: <156290C5-32B9-45C0-941A-ADF93E278149@delong.com> References: <75E9BD24-F12F-42BF-A989-CF6CC282B28E@arin.net> <6389E6EC-7D1F-4CDA-8370-2ECB83D36029@arin.net> <156290C5-32B9-45C0-941A-ADF93E278149@delong.com> Message-ID: There are only 10 completed transfers at this point. /John On May 2, 2011, at 10:37 PM, Owen DeLong wrote: Can you provide the data for the 11th completed transfer along the same lines as what was provided for the other 10 below, please? Thanks, Owen On May 1, 2011, at 10:16 AM, John Curran wrote: On Apr 29, 2011, at 7:08 PM, John Curran wrote: To date, there have been 10 completed specified transfers under NRPM 8.3: Distribution of IPv4 Resources transferred: 1 /17 3 /20s 1 /21 1 /23 49 /24s PPML Readers - I'm going to expand on the above for sake of clarity, as it occurs to me that the provided summary was not at all useful for analysis as we combined any resources that were not a clean CIDR block boundary into the "49 /24s" entry at the end of the list. There were 10 specified transfers total. The recipients received the following aggregates (one recipient per line, all under RSA) - (1) /24 (1) /24 (1) /23 (1) /17 (2) /20 (1) /22, (2) /23 (1) /20, (1) /21, (2) /22, (2) /23 (1) /20 (1) /21 (1) /23, (1) /24 In some cases, the transfers were record keeping in nature (e.g. an entity recording specified transfer of an address lock already in use by another related entity) Additionally, in many cases the smaller blocks are actually contiguous but not aligned on a CIDR block boundary (e.g. a large block with smaller blocks on either side being reported as 3 distinct transferred aggregates) I hope this helps, and we will keep trying to provide better insight into use of the NRPM 8.3 specified transfer policy. Thanks! /John John Curran President and CEO ARIN _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. _______________________________________________ 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 2 16:56:01 2011 From: owen at delong.com (Owen DeLong) Date: Mon, 2 May 2011 13:56:01 -0700 Subject: [arin-ppml] Statistics regarding NRPM 8.3 Transfers to date In-Reply-To: <4DBDCFB1.4040105@matthew.at> References: <75E9BD24-F12F-42BF-A989-CF6CC282B28E@arin.net> <7406316661701612155@unknownmsgid> <3F57F52B-F1F1-4450-B493-AA4D544D8D15@arin.net> <8740380157159276993@unknownmsgid> <49E26DCB-DAF7-4A0A-912E-F981494979F5@delong.com> <4DBC2AEB.9040307@matthew.at> <4DBCA58D.4060704@sprunk.org> <2344ADD7-616E-4FA7-9552-19735926A952@delong.com> <4DBD9BF5.7050002@sprunk.org> <4DBDCFB1.4040105@matthew.at> Message-ID: <8475B258-A979-4C4C-A4D3-C9AAFC649C71@delong.com> On May 1, 2011, at 2:25 PM, Matthew Kaufman wrote: > On 5/1/2011 10:44 AM, Stephen Sprunk wrote: >> However, assuming that aggregation has inherent value to >> buyers, sellers will avoid them out of self-interest, so we may not need >> to put anything into policy. Is anyone seriously concerned that >> assumption is wrong? > > That's exactly why I don't think we need really complicated language that then has lots of associated loopholes. > > If aggregation is good, providers will encourage it, and addresses that are big aggregates will have more value. Done. > > Matthew Kaufman I find your faith in a market leading to people doing the right thing... [x] distressing [x] amusing [x] questionable [ ] enlightened [ ] likely [ ] probable (check all that apply) Owen From matthew at matthew.at Mon May 2 17:04:29 2011 From: matthew at matthew.at (Matthew Kaufman) Date: Mon, 2 May 2011 14:04:29 -0700 Subject: [arin-ppml] Statistics regarding NRPM 8.3 Transfers to date In-Reply-To: References: <75E9BD24-F12F-42BF-A989-CF6CC282B28E@arin.net> <7406316661701612155@unknownmsgid> <3F57F52B-F1F1-4450-B493-AA4D544D8D15@arin.net> <8740380157159276993@unknownmsgid> <49E26DCB-DAF7-4A0A-912E-F981494979F5@delong.com> <4DBC2AEB.9040307@matthew.at> <4DBCA58D.4060704@sprunk.org> <2344ADD7-616E-4FA7-9552-19735926A952@delong.com> Message-ID: <366DD56E-44DB-40FA-A788-97EFC9288167@matthew.at> On May 2, 2011, at 1:32 PM, Owen DeLong wrote: > > > 1. Org. A has a /8 and wants to transfer 32 of it's constituent /24s to Org. B. > However, Org. A doesn't want to put any effort into renumbering, > so, those 32 /24s are each individual non-aggregable /24s. > > This transfer should not be allowed. 1A. Org A has a /8 and wants to transfer 32 of its /24s to Org B. Org A is already announcing each of these /24s separately at different points around the world, so they've already done the deaggregation. Should the transfer still not be allowed? > > 2. Org. A has a /20 and a /18. Org. B has need for a /19. Org. A has > deprecated their use of the /20 and all of their resources are in > the /18, but, they are using just under 75% of the /18. > > Org. A would rather transfer the /20 and the top 1/4 of the /18 than > renumber that 1/4 of the /18 into the /20. > > This transfer should not be allowed (though I admit the case against > it is weak). > > 3. Org. A has four disparate /20s. Org B. has need of a /19. Org. A > would like to transfer two of their /20s to Org. B, but does not have > any pair of /20s which can be aggregated. > > This transfer should be allowed. The /20s are already disaggregated > in the routing table and there is no increase in routing table > size that results. Wouldn't it be even better if Org B was forced to find a different Org that can fulfill a /19? (Not that I'm suggesting that this would be good policy) > > 4. Org. A has four disparate /20s. Orgs. B, C, D, and E all have need > for /24s. Org. A would like to sell individual /24s from one of their > /20s to each of the above Orgs. (B,C, D, and E). > > These transfers should be allowed as there is no significant > difference between this and transfers where ARIN has > carved up a block during the initial allocations. The transfer > sizes comply with community accepted policy. > What is Orgs B, C, D, and E are legal subsidiaries of a single organization? > In essence, I'm trying to say that transfers which create unnecessary > additional disaggregation should be avoided. For what definition of "unnecessary" and why is "additional" the criteria? EVERY SINGLE TIME ARIN allocates space to someone, it creates additional disaggregation... and apparently you're ok with that. Matthew Kaufman From matthew at matthew.at Mon May 2 17:04:48 2011 From: matthew at matthew.at (Matthew Kaufman) Date: Mon, 2 May 2011 14:04:48 -0700 Subject: [arin-ppml] ARIN-2011-5: Shared Transition Space for IPv4 Address Extension - Last Call In-Reply-To: References: <4DAC8BCB.2000300@arin.net> <54E900DC635DAB4DB7A6D799B3C4CD8E10C7EF5E@PLSWM12A.ad.sprint.com> <3128593549961341875@unknownmsgid> <54E900DC635DAB4DB7A6D799B3C4CD8E10C899B7@PDAWM12B.ad.sprint.com> <1489147144792938659@unknownmsgid> <54E900DC635DAB4DB7A6D799B3C4CD8E10C89AC7@PDAWM12B.ad.sprint.com> Message-ID: <0816C508-43EE-46BD-8BC2-D5F1222848FE@matthew.at> On May 2, 2011, at 1:26 PM, William Herrin wrote: > On Mon, Apr 25, 2011 at 8:46 AM, George, Wes E [NTK] > wrote: >> IPv4 addresses used behind a NAT (inside pool) cannot be >> used for justification of new resources nor counted towards >> utilization calculations for existing resources. >> NRPM 4.10.x (Shared Transition Space) defines a specific >> non-unique block to be shared among multiple networks >> for this purpose. > > Hi Wes, > > So if I have addresses inside a NAT today, I want to move them outside > the NAT and I'm willing to cough up the money for a transfer, I should > be denied because the addresses at issue are currently used behind a > NAT? > > I'm sure we can fix this language so that it does what you intend, but > that will take time and debate. So, let's take the time and get it > right. Let's get 2011-5 on the books as it stands and then let's > figure out a good way to rebalance the the justified need concept > around its existence. Agree. Yet again we have a problem where the needs justification for using the very last of ARIN's free pool should be totally different than the needs justification for being the recipient of an expensive resource transfer via specified transfer, and yet it isn't. Can't fix the one without breaking the other in this case... or agreeing that needs justification for transfers needs fixing. (One of my proposals today that hasn't received comment yet covers the issue that new recipients can only get 3 months via specified transfer, given the current text, for instance.) Matthew Kaufman From mike at nationwideinc.com Mon May 2 17:05:26 2011 From: mike at nationwideinc.com (Mike Burns) Date: Mon, 2 May 2011 17:05:26 -0400 Subject: [arin-ppml] Statistics regarding NRPM 8.3 Transfers to date References: <75E9BD24-F12F-42BF-A989-CF6CC282B28E@arin.net> <7406316661701612155@unknownmsgid> <3F57F52B-F1F1-4450-B493-AA4D544D8D15@arin.net> <8740380157159276993@unknownmsgid> <49E26DCB-DAF7-4A0A-912E-F981494979F5@delong.com> <4DBC2AEB.9040307@matthew.at> <4DBCA58D.4060704@sprunk.org> <2344ADD7-616E-4FA7-9552-19735926A952@delong.com><4DBD9BF5.7050002@sprunk.org> <4DBDCFB1.4040105@matthew.at> <8475B258-A979-4C4C-A4D3-C9AAFC649C71@delong.com> Message-ID: > I find your faith in a market leading to people doing the right thing... > It's called the Invisible Hand, Owen. http://en.wikipedia.org/wiki/Invisible_hand Regards, Mike From jeffrey.lyon at blacklotus.net Mon May 2 17:22:46 2011 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Mon, 2 May 2011 17:22:46 -0400 Subject: [arin-ppml] Microsoft receives court approval for transfer asagreed with ARIN In-Reply-To: References: <94030.1304191624@tristatelogic.com> <2F1F43FA-8724-4298-89C3-76ABEA5A3AAF@delong.com> Message-ID: On Mon, May 2, 2011 at 3:00 PM, Owen DeLong wrote: >>> >> >> Owen, >> >> Could the annual fee be something like $100/yr versus $1250 and up? > > For LRSA signatories it already is $100/year. > > Owen > > It would be nice if everyone qualified for that rate. -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications - AS32421 First and Leading in DDoS Protection Solutions From owen at delong.com Mon May 2 17:22:37 2011 From: owen at delong.com (Owen DeLong) Date: Mon, 2 May 2011 14:22:37 -0700 Subject: [arin-ppml] Fw: Accusation of fundamental conflict ofinterest/IPaddress policy pitched directly to ICANN In-Reply-To: References: Message-ID: <9A32FA75-9D41-415A-8078-922AB09461BF@delong.com> I would use the quagmire of special interests and profiteering above all else (including stability and functionality) that exist in the modern DNS system as a classic example of what I think would be incredibly undesirable in the address management world. Owen On May 2, 2011, at 9:48 AM, Mike Burns wrote: >> Can you be more specific? The ICANN ASO? the ICANN BoT? the IANA? > > Hi Tim, > > Keep going, all the organizations above are suspect due to the fact that they are all comprised of the same basic group of RIR designees. > > I would take it to NTIA like DNS. > > And I would use DNS as a template for the creation of the global policy restrictions John Curran asked about, which restrictions would apply to all registries, regional or commercial. > Just as all DNS registrars must meet certain qualifications, so would private registries of number space. > > Let the NTIA hear arguments from the proposer and from the ASO, the ICANN BoT, and IANA, although I suspect they will all sound the same. > > Regards, > > Mike > > > > > ----- Original Message ----- From: "McTim" > To: "Mike Burns" > Cc: "Keith W. Hare" ; ; "John Curran" > Sent: Monday, May 02, 2011 12:22 PM > Subject: Re: [arin-ppml] Accusation of fundamental conflict ofinterest/IPaddress policy pitched directly to ICANN > > > On Mon, May 2, 2011 at 6:14 PM, Mike Burns wrote: >> Hi Keith, > > >> But I feel the decision, informed by input from the RIRs through the NRO, >> should be made by the level above the RIRs and below US Dept. of Commerce. > > Can you be more specific? The ICANN ASO? the ICANN BoT? the IANA? > > -- > Cheers, > > McTim > "A name indicates what we seek. An address indicates where it is. A > route indicates how we get there." Jon Postel > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From rcarpen at network1.net Mon May 2 17:26:44 2011 From: rcarpen at network1.net (Randy Carpenter) Date: Mon, 02 May 2011 17:26:44 -0400 (EDT) Subject: [arin-ppml] ARIN-2011-3: Better IPv6 Allocations for ISPs - Last Call In-Reply-To: Message-ID: <568c7580-8893-443b-bee0-c80807b975fc@zimbra.network1.net> I agree that a /12 is pretty insane, but if it is, then who would even be able to justify it? There would not be many organizations that could get that big. And if you limited it to a /20, couldn't they just come back and get multiple /20s, thereby eating up the same (or more) space, and further de-aggregating the DFZ? -Randy -- | Randy Carpenter | Vice President - IT Services | Red Hat Certified Engineer | First Network Group, Inc. | (800)578-6381, Opt. 1 ---- ----- Original Message ----- > On Mon, Apr 18, 2011 at 12:05 PM, ARIN wrote: > > The ARIN Advisory Council (AC) met on 13 April 2011 and decided to > > send a revised version of the following draft policy to last call: > > > > ?ARIN-2011-3: Better IPv6 Allocations for ISPs > > > ... > > 7. Adds language to limit initial allocations to no more than a /16 > > (6.5.2.1(b)) and to limit subsequent allocations to no larger than > > a /12 > > (an organization may apply for additional /12s, but, no single > > allocation larger than a /12 can be made at one time) (6.5.2.1(e)) > > (community concern) > > I am opposed to this draft policy. The idea of handing out /12 > blocks, > and potentially *multiple* /12 blocks to an organization is ludicrous > if > this protocol is to have any hope for longevity. :( > I think the largest block that should be allocatable should be a /20; > that would still allow for 6rd deployments using /56 allocations for > end sites, which is reasonable for a transition technology; if they > want full /48s, they can start with a /56 during the 6rd period, and > then once their upstream goes fully native, they can get a natively > routed /48. > With a /20 as the shortest prefix allocatable to an ISP, that still > allows for a million such allocations, which is likely to last us > considerably longer than the 4096 /12 blocks espoused by this > proposal. > > Matt > _______________________________________________ > 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 v6ops at globis.net Mon May 2 17:28:25 2011 From: v6ops at globis.net (Ray Hunter) Date: Mon, 02 May 2011 23:28:25 +0200 Subject: [arin-ppml] New Entrants shut out? (Was: ARIN-2011-5: ..., - Last Call Message-ID: <4DBF21F9.2040507@globis.net> This is a wind up right? Just a few links for your edification. There's obviously a lot more if you care to look. http://www.oecd.org/dataoecd/49/28/40839436.pdf http://isoc.org/wp/worldipv6day/participants/ http://www.networkworld.com/news/2010/082410-verizon-ipv6.html http://www.indg.gov.in/e-governance/news-items/national-ipv6-deployment-roadmap-released/?searchterm=india http://digaria.com/postings/b6f3742ce62ac02a8a63d0dd0c7b55da A company that is likely to have more users than US citizens is hardly one I'd call a "small to medium sized business." > It seems that only small to medium sized businesses are taking IPv6 seriously. Advertising IPv6 support seems like more of a marketing gimmick than a realistic push for support by many companies. > -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications - AS32421 >First and Leading in DDoS Protection Solutions -------------- next part -------------- An HTML attachment was scrubbed... URL: From Keith at jcc.com Mon May 2 17:33:24 2011 From: Keith at jcc.com (Keith W. Hare) Date: Mon, 2 May 2011 17:33:24 -0400 Subject: [arin-ppml] Accusation of fundamental conflict ofinterest/IPaddress policy pitched directly to ICANN In-Reply-To: <35F0C71BD6974F21A3C296005F0DDA0F@mike> References: <4DBB208B.4060808@ipinc.net><112FF1070FFF4B7E957E13C757CCB513@vid eo><23B533DB44354E3EA201D0941C47C46C@video><861B310C-7502-49FE-BD13-3D1B123A57EB @delong.com><274D7568A828485B91D64F9308B3A24E@video> <9737f78a74367c4fde16e526d31442304dbec379@jcc.com> <40d2346a1b58436fb0387d165b0c7bee4dbed64a@jcc.com> <34A035C8AB3147919076CC4BB118C83B@mike> <03bbb072c4565685fb86a50e59d5178b4dbefc1f@jcc.com> <35F0C71BD6974F21A3C296005F0DDA0F@mike> Message-ID: <318ab66f66c5a1f233c2597ad1117c194dbf227b@jcc.com> Mike, So, your issues with ARIN are: 1. ARIN has large numbers of netblocks without valid POCs. I was under the impression that ARIN has a process in place to validate POCs. This policy was developed and discussed one while ago on the PPML mailing list. I suspect that if the policy had been developed five years earlier, the POCs would be in better shape. 2. ARIN transfer policies are more restrictive than APNIC transfer policies. The ARIN transfer policies where developed and discussed on the PPML mailing list. I'm sure that a policy proposal that reduced the restrictiveness of the ARIN policies would also get a lot of discussion. 3. ARIN has professed no statutory control over legacy addresses in the Plzak declaration in the Kremen case, and yet attempts to control the registration of legacy resources. I found a lot of information about the Kremen case, but did not immediately find the "Plzak declaration" to which you refer. I did find an interesting article, "LEGAL AND POLICY ASPECTS OF INTERNET NUMBER RESOURCES", by Stephen M. Ryan, Esq., Raymond A. Plzak, & John Curran, apparently from SANTA CLARA COMPUTER & HIGH TECH. L.J. [Vol. 24] in 2008. My take on legacy resources is that ARIN was given the responsibility for legacy resources, but ARIN's authority over legacy resources is fuzzy. There-in lies the tension. I view ARIN's policies over legacy resources as more benevolent than dictator-ish, particularly since I have the ability to participate in that policy development. Keith -----Original Message----- From: Mike Burns [mailto:mike at nationwideinc.com] Sent: Monday, May 02, 2011 3:34 PM To: Keith W. Hare; arin-ppml at arin.net Subject: Re: [arin-ppml] Accusation of fundamental conflict ofinterest/IPaddress policy pitched directly to ICANN >But what is it about ARIN that is broken? What exactly do you think needs >to be fixed? >The only thing I've gotten out of the discussions so far is that some >people think there is money to be made by providing IPv4 addresses based on >willingness and ability to pay rather than ARIN's current >demonstrated >need policies. >Why is it to my benefit if someone else makes money? Particularly if it >perturbs the current mechanisms in a way that costs me money? >Keith Hare Hi Keith, What is broken about ARIN is that scandalously large numbers of netblocks do not have valid POCs, for example. The stewardship of Whois leaves a lot to be desired. Competitive pressures would help to finally decide who controls these addresses and allow them to be transferred to those who would pay for them. Network operators don't really have much of a choice in accessing Whois information to determine the rights to advertise addresses, and competive registries. In my experience they rely on attestation and review of proferred chain-of-custody docs when determining who can advertise which addresses, when confronted with inconsistencies with whois. A competitive registry with a title insurance component will give network operators more security when deciding questionable cases. What is broken about ARIN is that their transfer policies are more restrictive than APNICs, and that will cause a flow of addresses out of ARIN and into APNIC. A competitive registry could presumably have a different transfer policy, as APNICs differs from ARINs. What is broken about ARIN is that ARIN has professed no statutory control over legacy addresses in the Plzak declaration in the Kremen case, and yet attempts to control the registration of legacy resources. With a private registry, the address rights holders can choose to opt-out of ARIN's dictats and choose their registry voluntarily. I don't see how the creation of a private registry will perturb the current mechanisms in a way that costs you money, could you share why you feel that way? Regards, Mike Burns From owen at delong.com Mon May 2 17:28:20 2011 From: owen at delong.com (Owen DeLong) Date: Mon, 2 May 2011 14:28:20 -0700 Subject: [arin-ppml] Accusation of fundamental conflict ofinterest/IPaddress policy pitched directly to ICANN In-Reply-To: <53A513E31BE148B590E399558AA71963@mike> References: <4DBB208B.4060808@ipinc.net> <112FF1070FFF4B7E957E13C757CCB513@video> <23B533DB44354E3EA201D0941C47C46C@video><861B310C-7502-49FE-BD13-3D1B123A57EB@delong.com> <274D7568A828485B91D64F9308B3A24E@video> <53A513E31BE148B590E399558AA71963@mike> Message-ID: If money and authority speak with one voice, then, we have already lost because we have sold the internet off to the economic special interests and abandoned the concept of a free (as in speech) and public forum for the democratization of communication across societies. Owen On May 2, 2011, at 10:35 AM, Mike Burns wrote: > Hi Bill, > > OK, then let the IETF and either the DoC or NTIA hash it out, since they are all entities above the RIRs. > > I think the contracts with the RIRs you reference are not actually contracts but further MoAs. > > I think there is enough separation between the IETF and the RIRs that there would be an honest appraisal of the proposal. > And if money and authority speak with one voice, I suppose it will be heard. > > Regards, > > Mike > > > ----- Original Message ----- From: "William Herrin" > To: "Mike Burns" > Cc: "Jimmy Hess" ; "John Curran" ; > Sent: Monday, May 02, 2011 1:17 PM > Subject: Re: [arin-ppml] Accusation of fundamental conflict ofinterest/IPaddress policy pitched directly to ICANN > > > On Mon, May 2, 2011 at 9:27 AM, Mike Burns wrote: >> The authority flows down from the US Dept of Commerce. It doesn't go from >> there to the RIRs and back up to ICANN. >> ICANN>>RIRs > > Mike, > > This is not accurate. > > ICANN operates IANA under at least two contracts, one to the IETF and > one to the DOC. DOC provides the money. IETF provides the authority. > > http://www.icann.org/en/general/ietf-icann-mou-01mar00.htm > http://www.icann.org/en/general/ietf-iana-agreement-v8.htm > > I could swear there are also contracts with the RIRs themselves which > spell out the RIR's responsibility to the IETF and the IANA's > responsibility to the RIRs but my google-fu is failing me. > > Regardless, the source of authority does not derive from the DOC and > does not pass through ICANN on its way to the RIRs. > > 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 jeffrey.lyon at blacklotus.net Mon May 2 17:30:54 2011 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Mon, 2 May 2011 17:30:54 -0400 Subject: [arin-ppml] New Entrants shut out? (Was: ARIN-2011-5: ..., - Last Call In-Reply-To: <4DBF21F9.2040507@globis.net> References: <4DBF21F9.2040507@globis.net> Message-ID: On Mon, May 2, 2011 at 5:28 PM, Ray Hunter wrote: > This is a wind up right? > > Just a few links for your edification. There's obviously a lot more if you > care to look. > > http://www.oecd.org/dataoecd/49/28/40839436.pdf > http://isoc.org/wp/worldipv6day/participants/ > http://www.networkworld.com/news/2010/082410-verizon-ipv6.html > http://www.indg.gov.in/e-governance/news-items/national-ipv6-deployment-roadmap-released/?searchterm=india > > http://digaria.com/postings/b6f3742ce62ac02a8a63d0dd0c7b55da > > A company that is likely to have more users than US citizens is hardly one > I'd call a "small to medium sized business." > >>? It seems that only small to medium sized businesses are taking IPv6 >> seriously. Advertising IPv6 support seems like more of a marketing gimmick >> than a realistic push for support by many companies. > >> -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | >> http://www.blacklotus.net Black Lotus Communications - AS32421 >First and >> Leading in DDoS Protection Solutions > _______________________________________________ > 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 care to see who is actually offering IPv6 right now, not who is talking about it. Everyone's talking about it, and many are claiming to offer it or offer it soon so that's not really special in my book. -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications - AS32421 First and Leading in DDoS Protection Solutions From scottleibrand at gmail.com Mon May 2 17:23:15 2011 From: scottleibrand at gmail.com (Scott Leibrand) Date: Mon, 2 May 2011 14:23:15 -0700 Subject: [arin-ppml] ARIN-2011-5: Shared Transition Space for IPv4 Address Extension - Last Call In-Reply-To: <0816C508-43EE-46BD-8BC2-D5F1222848FE@matthew.at> References: <4DAC8BCB.2000300@arin.net> <54E900DC635DAB4DB7A6D799B3C4CD8E10C7EF5E@PLSWM12A.ad.sprint.com> <3128593549961341875@unknownmsgid> <54E900DC635DAB4DB7A6D799B3C4CD8E10C899B7@PDAWM12B.ad.sprint.com> <1489147144792938659@unknownmsgid> <54E900DC635DAB4DB7A6D799B3C4CD8E10C89AC7@PDAWM12B.ad.sprint.com> <0816C508-43EE-46BD-8BC2-D5F1222848FE@matthew.at> Message-ID: On Mon, May 2, 2011 at 2:04 PM, Matthew Kaufman wrote: > > Agree. Yet again we have a problem where the needs justification for using > the very last of ARIN's free pool should be totally different than the needs > justification for being the recipient of an expensive resource transfer via > specified transfer, and yet it isn't. > > Can't fix the one without breaking the other in this case... or agreeing > that needs justification for transfers needs fixing. (One of my proposals > today that hasn't received comment yet covers the issue that new recipients > can only get 3 months via specified transfer, given the current text, for > instance.) I have that one on my list to respond to. IMO we should be moving away from having 8.3 requirements depend on section 4 requirements, and instead move toward copying the necessary requirements to section 8, which whatever modifications (like 24 months) are more appropriate for transfers. But that is a bit of a project, which I don't have time for just yet. :-) -Scott -------------- next part -------------- An HTML attachment was scrubbed... URL: From owen at delong.com Mon May 2 17:34:10 2011 From: owen at delong.com (Owen DeLong) Date: Mon, 2 May 2011 14:34:10 -0700 Subject: [arin-ppml] ARIN-prop-140 Business Failure Clarification In-Reply-To: <4DBEF0DF.8060800@arin.net> References: <4DBEF0DF.8060800@arin.net> Message-ID: <01EDA2D1-8774-4794-B778-30D10C3F0A66@delong.com> I do not support the propsal as written. I would support the proposal if Chapter 13 were expemted. However, at the point where an organization is being dissolved under Chapter 13, I believe it is in the best interests of the community for ARIN to reclaim the addresses and distribute them according to consensus developed policy rather than have them treated as assets by the bankruptcy court. Owen On May 2, 2011, at 10:58 AM, ARIN wrote: > ARIN-prop-140 Business Failure Clarification > > 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-140 Business Failure Clarification > > Proposal Originator: Matthew Kaufman > > Proposal Version: 1 > > Date: 2 May 2011 > > Proposal type: new > > Policy term: permanent > > Policy statement: > > Add to end of Section 8.1: "Note that an entity which is reorganizing > under any section of the US bankruptcy code (or foreign equivalent) is > not 'out of business' for the purpose of interpreting this section" > > Rationale: > > Potential confusion exists over the requirement to return address space > from a bankrupt entity. This is a needed clarification to the policy manual. > > 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 owen at delong.com Mon May 2 17:32:03 2011 From: owen at delong.com (Owen DeLong) Date: Mon, 2 May 2011 14:32:03 -0700 Subject: [arin-ppml] ARIN-2011-3: Better IPv6 Allocations for ISPs - Last Call In-Reply-To: References: <4DAC8B7F.2080303@arin.net> Message-ID: On May 2, 2011, at 10:47 AM, Matthew Petach wrote: > On Mon, Apr 18, 2011 at 12:05 PM, ARIN wrote: >> The ARIN Advisory Council (AC) met on 13 April 2011 and decided to >> send a revised version of the following draft policy to last call: >> >> ARIN-2011-3: Better IPv6 Allocations for ISPs >> > ... >> 7. Adds language to limit initial allocations to no more than a /16 >> (6.5.2.1(b)) and to limit subsequent allocations to no larger than a /12 >> (an organization may apply for additional /12s, but, no single >> allocation larger than a /12 can be made at one time) (6.5.2.1(e)) >> (community concern) > > I am opposed to this draft policy. The idea of handing out /12 blocks, > and potentially *multiple* /12 blocks to an organization is ludicrous if > this protocol is to have any hope for longevity. :( > I think the largest block that should be allocatable should be a /20; > that would still allow for 6rd deployments using /56 allocations for > end sites, which is reasonable for a transition technology; if they > want full /48s, they can start with a /56 during the 6rd period, and > then once their upstream goes fully native, they can get a natively > routed /48. > With a /20 as the shortest prefix allocatable to an ISP, that still > allows for a million such allocations, which is likely to last us > considerably longer than the 4096 /12 blocks espoused by this > proposal. > > Matt Under this policy, it is unlikely that anyone not currently in the ARIN XX-Large organizational category would be able to justify a /16, let alone a /12. If I recall correctly (I can't find the slide right now) at a previous ARIN meeting, there were something on the order of 10 such organizations in the entire region. I do not see this as a significant risk and limiting those organizations to /20s will significantly disaggregate IPv6. Owen From fernattj at gmail.com Mon May 2 17:40:03 2011 From: fernattj at gmail.com (Jonathan Fernatt) Date: Mon, 2 May 2011 17:40:03 -0400 Subject: [arin-ppml] Accusation of fundamental conflict ofinterest/IPaddress policy pitched directly to ICANN In-Reply-To: <35F0C71BD6974F21A3C296005F0DDA0F@mike> References: <4DBB208B.4060808@ipinc.net> <23B533DB44354E3EA201D0941C47C46C@video> <274D7568A828485B91D64F9308B3A24E@video> <9737f78a74367c4fde16e526d31442304dbec379@jcc.com> <40d2346a1b58436fb0387d165b0c7bee4dbed64a@jcc.com> <34A035C8AB3147919076CC4BB118C83B@mike> <03bbb072c4565685fb86a50e59d5178b4dbefc1f@jcc.com> <35F0C71BD6974F21A3C296005F0DDA0F@mike> Message-ID: > > What is broken about ARIN is that scandalously large numbers of netblocks > do not have valid POCs, for example. The stewardship of Whois leaves a lot > to be desired. > What steps would a commercial entity take to resolve this that RIRs cannot? > Competitive pressures would help to finally decide who controls these > addresses and allow them to be transferred to those who would pay for them. > Leaving other equally "worthy" entities with less money unable to acquire space despite their need? > Network operators don't really have much of a choice in accessing Whois > information to determine the rights to advertise addresses, and competive > registries. > I'd argue that network operators are the very ones who give the RIR their "power." I also don't see why you seem to claim that they can't? Tell me, what's stopping them from using whatever registry they want? > In my experience they rely on attestation and review of proferred > chain-of-custody docs when determining who can advertise which addresses, > when confronted with inconsistencies with whois. > A competitive registry with a title insurance component will give network > operators more security when deciding questionable cases. > Maybe. > What is broken about ARIN is that their transfer policies are more > restrictive than APNICs, and that will cause a flow of addresses out of ARIN > and into APNIC. > Could you explain why you think this? > A competitive registry could presumably have a different transfer policy, > as APNICs differs from ARINs. What is broken about ARIN is that ARIN has professed no statutory control > over legacy addresses in the Plzak declaration in the Kremen case, and yet > attempts to control the registration of legacy resources. > With a private registry, the address rights holders can choose to opt-out > of ARIN's dictats and choose their registry voluntarily. > As I said above, I don't think there is anything stopping someone from "choosing their registry voluntarily." I don't see how the creation of a private registry will perturb the current > mechanisms in a way that costs you money, could you share why you feel that > way? > Not to speak for him but you *did* say " Competitive pressures would help to finally decide who controls these addresses and allow them to be transferred to those who would pay for them." Were you not suggesting that the folks with the most money would be the ones who got address space registered to their name and the others would be out in the rain? Let me know if I misunderstood. Jon Fernatt -------------- next part -------------- An HTML attachment was scrubbed... URL: From owen at delong.com Mon May 2 17:39:12 2011 From: owen at delong.com (Owen DeLong) Date: Mon, 2 May 2011 14:39:12 -0700 Subject: [arin-ppml] ARIN-prop-145 STLS Listing Immunity In-Reply-To: <4DBEF116.1000400@arin.net> References: <4DBEF116.1000400@arin.net> Message-ID: <8D861213-779F-4E9D-8C73-0B2F7F5D826A@delong.com> I oppose this policy as written. There is no need to turn STLS into a blanket exemption from policy and doing so is contrary to the public interest. Owen On May 2, 2011, at 10:59 AM, ARIN wrote: > ARIN-prop-145 STLS Listing Immunity > > 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-145 STLS Listing Immunity > > Proposal Originator: Matthew Kaufman > > Proposal Version: 1 > > Date: 2 May 2011 > > Proposal type: new > > Policy term: permanent > > Policy statement: > > Add a subsection to Section 12 (Resource Review) of the NRPM: > > ARIN may not revoke any resources issued by ARIN that are presently > listed as "available" on the ARIN Specified Transfer Listing Service > unless there is sufficient reason to believe that the holder does not in > fact intend to transfer these resources. > > Rationale: > > An entity may list space as available and might begin the process of > moving out of that space in order to facilitate the transfer. A review > after such work was in progress might reveal that the addresses are not > sufficiently utilized. > > Additionally, because posting a listing on the STLS signals directly to > ARIN that an entity believes it can use addresses more efficiently, ARIN > might simply use STLS listings in order to trigger audit under 12.2(c). > This would not be fair. (And would be a disincentive to using the ARIN > STLS at all in order to list available space) > > This policy would also serve to increase the value of the ARIN STLS over > other possible transfer listing services, increasing the transparency of > the transfer market, particularly to ARIN, who wishes to ensure that > transfers take place within NRPM 8.3. > > 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 owen at delong.com Mon May 2 17:38:12 2011 From: owen at delong.com (Owen DeLong) Date: Mon, 2 May 2011 14:38:12 -0700 Subject: [arin-ppml] ARIN-prop-144 Remove Single Aggregate requirement from Specified Transfer In-Reply-To: <4DBEF10B.50902@arin.net> References: <4DBEF10B.50902@arin.net> Message-ID: <50906B7C-47BB-4546-855E-38640D389B89@delong.com> I oppose the proposal as written. Adaption policy to staff interpretation rather than revising it to reflect community intent is a step in the wrong direction. Owen On May 2, 2011, at 10:59 AM, ARIN wrote: > ARIN-prop-144 Remove Single Aggregate requirement from Specified Transfer > > 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-144 Remove Single Aggregate requirement from Specified Transfer > > Proposal Originator: Matthew Kaufman > > Proposal Version: 1 > > Date: 2 May 2011 > > Proposal type: new > > Policy term: permanent > > Policy statement: > > Modify Section 8.3 as follows: > Change "can demonstrate the need for such resources, as a single > aggregate, in the exact amount which they can justify under current ARIN > policies" to "can demonstrate the need for such resources in the amount > which they can justify under current ARIN policies" > > Rationale: > > The "as a single aggregate" has been interpreted to apply only to > "demonstrate the need" as opposed to the resources which may be received > by ARIN staff. It is possible that the original intent was to require > than each transfer be of a single aggregate. > > HOWEVER, as multiple Section 8.3 transfers may be executed serially by a > pair of entities which wish to use the specified transfer policy in > order to transfer any number of blocks as long as there is needs > justification for each, it simply saves the transferring entity, the > recipient, AND ARIN paperwork to allow a transfer of multiple blocks to > proceed as a single transfer. > > 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 Mon May 2 17:45:13 2011 From: jcurran at arin.net (John Curran) Date: Mon, 2 May 2011 21:45:13 +0000 Subject: [arin-ppml] NRPN 8.2 & 2.3 In-Reply-To: <61CEAA1048BE416E9BD7FB5C7CBF47FB@mike> References: <61CEAA1048BE416E9BD7FB5C7CBF47FB@mike> Message-ID: <77B52A33-3F2E-45D0-9BA7-65D90FF96144@arin.net> On May 2, 2011, at 9:57 PM, Mike Burns wrote: I don't believe that there has been an answer to those of us who said that while it is grammatically acceptable to decide that a "single aggregate" relates to the needs justification, it is nonsensical to do that, as all needs analyses result in a single aggregate. You don't have a needs analysis at any time where it is found that a need is outside CIDR boundaries. Need assessment has always rounded up to that boundary. Mike - Actually, that is not the case. Internally, we calculate need based on the information provided and that is more granular than a CIDR boundary. No, the only way to interpret the language of 8.3 is that the reception of the addresses should occur as a single aggregate, which is clear has not occurred with 8.3. To say the staff or the board acted outside of policy is correct in the MS/Nortel case. We follow the policies as written and do not have the freedom reinterpret policy contrary to the adopted language. I indicated this before, but am happy to repeat it if that helps you. Thanks! /John John Curran President and CEO ARIn -------------- next part -------------- An HTML attachment was scrubbed... URL: From owen at delong.com Mon May 2 17:42:09 2011 From: owen at delong.com (Owen DeLong) Date: Mon, 2 May 2011 14:42:09 -0700 Subject: [arin-ppml] ARIN-prop-146 Clarify Justified Need for Transfers In-Reply-To: <4DBEF120.4080901@arin.net> References: <4DBEF120.4080901@arin.net> Message-ID: <88F39B20-5C20-45F0-AD61-5FA1E7F84CE3@delong.com> I oppose the policy as written. There are reasons that we have a body of IPv4 policies with a variety of definitions of justified need. ARIN is well versed in identifying the particular categories under which an application should be processed and there is no reason to treat transfers differently from initial allocations and assignments. This proposal would subject end-user transferees to the same policy structures as ISPs which could be very detrimental to such end users. Owen On May 2, 2011, at 11:00 AM, ARIN wrote: > ARIN-prop-146 Clarify Justified Need for Transfers > > 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-146 Clarify Justified Need for Transfers > > Proposal Originator: Matthew Kaufman > > Proposal Version: 1 > > Date: 2 May 2011 > > Proposal type: new > > Policy term: permanent > > Policy statement: > > Add a subsection to Section 8 (Transfers) of the NRPM: > > "Justified Need" for resources associated with a transfer shall be > determined using the "4.2.4 ISP Additional Requests" criteria applied as > though the recipient has been a subscriber member of ARIN for at least > one year (whether or not that is the case). > > Rationale: > > An organization which is not able to obtain its initial IPv4 address > assignment from ARIN post-runout would otherwise be limited to > purchasing only a 3-month supply (because the language in 4.2.4.4 > regarding 8.3 transfers is not triggered). > > An organization which has only recently received its first allocation > under the "last /8" criteria is also otherwise limited to purchasing > only a 3-month supply (because the language in 4.2.4.4 is again not > applicable). > > There is also ambiguity if 4.2.2.1.3 is applied in that a transfer to > a new organization might only need to show need for a /20 (because that > is what is specifically called out) even though they are receiving a > much larger block. > > There is also ambiguity with regard to transfers under 8.2 where the > receiving organization is a new organization... not at all clear how > "justified need" has been or should be determined. > > 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 owen at delong.com Mon May 2 17:43:42 2011 From: owen at delong.com (Owen DeLong) Date: Mon, 2 May 2011 14:43:42 -0700 Subject: [arin-ppml] ARIN-prop-143 Clarify Specified Transfer RSA Requirement In-Reply-To: <4DBEF101.5060407@arin.net> References: <4DBEF101.5060407@arin.net> Message-ID: I oppose this proposal. Transfer recipients should be required to sign the current standard RSA and not a less restrictive RSA. Owen On May 2, 2011, at 10:59 AM, ARIN wrote: > ARIN-prop-143 Clarify Specified Transfer RSA Requirement > > ARIN received the following policy proposal and is posting it to the > Public Policy Mailing List (PPML) in accordance with the Policy > Development Process. > > The ARIN Advisory Council (AC) will review the proposal at their next > regularly scheduled meeting (if the period before the next regularly > scheduled meeting is less than 10 days, then the period may be extended > to the subsequent regularly scheduled meeting). The AC will decide how > to utilize the proposal and announce the decision to the PPML. > > The AC invites everyone to comment on the proposal on the PPML, > particularly their support or non-support and the reasoning > behind their opinion. Such participation contributes to a thorough > vetting and provides important guidance to the AC in their deliberations. > > Draft Policies and Proposals under discussion can be found at: > https://www.arin.net/policy/proposals/index.html > > The ARIN Policy Development Process can be found at: > https://www.arin.net/policy/pdp.html > > Mailing list subscription information can be found > at: https://www.arin.net/mailing_lists/ > > Regards, > > Communications and Member Services > American Registry for Internet Numbers (ARIN) > > > ## * ## > > > ARIN-prop-143 Clarify Specified Transfer RSA Requirement > > Proposal Originator: Matthew Kaufman > > Proposal Version: 1 > > Date: 2 May 2011 > > Proposal type: new > > Policy term: permanent > > Policy statement: > > Replace section 8.3 "Such transferred number resources may only be > received under RSA" with "Such transferred number resources may only be > received under a registration services agreement" > > Add to section 8.3 "It is the intent of this policy that the > registration services agreement under which the transferred resources > are received SHOULD be at least as restrictive as the registration > services agreement that covers these resources prior to the transfer. > Legacy resources that are not currently covered by a registration > services agreement should be received under a Legacy Registration > Services Agreement (or at the recipient's option, the standard > Registration Services Agreement). Legacy resources that are currently > covered by a Legacy Registration Services Agreement should be received > under a Legacy Registration Services Agreement which is at least as > restrictive as the previous LRSA (or at the recipient's option, the > standard Registration Services Agreement). Resources that are currently > covered under the standard Registration Services Agreement should be > received under the standard Registration Services Agreement. ARIN staff > shall report periodically on any required deviation from this paragraph, > including modifications that have been required to either the standard > forms of the LRSA or RSA." > > Rationale: > > Clarifies the NRPM to reflect policy as currently implemented and to > properly reflect that legacy resources may be received, at the option of > the recipient, under either the standard RSA or the legacy RSA. > > Also clarifies the NRPM to reflect that registration services agreements > may be modified from standard if necessary for the purposes of effecting > Section 8.3 transfers. > > Requires transparency for deviations from the recommended policy and/or > customized registration services agreements. > > 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 stephen at sprunk.org Mon May 2 17:50:28 2011 From: stephen at sprunk.org (Stephen Sprunk) Date: Mon, 02 May 2011 16:50:28 -0500 Subject: [arin-ppml] Statistics regarding NRPM 8.3 Transfers to date In-Reply-To: References: <75E9BD24-F12F-42BF-A989-CF6CC282B28E@arin.net> <7406316661701612155@unknownmsgid> <3F57F52B-F1F1-4450-B493-AA4D544D8D15@arin.net> <8740380157159276993@unknownmsgid> <49E26DCB-DAF7-4A0A-912E-F981494979F5@delong.com> <4DBC2AEB.9040307@matthew.at> <4DBCA58D.4060704@sprunk.org> <2344ADD7-616E-4FA7-9552-19735926A952@delong.com> <4DBD9BF5.7050002@sprunk.org> Message-ID: <4DBF2724.6090300@sprunk.org> On 02-May-11 15:41, Owen DeLong wrote: > On May 1, 2011, at 10:44 AM, Stephen Sprunk wrote: >> On 01-May-11 11:05, Owen DeLong wrote: >>> While I would be fine with ARIN fulfilling your request with 2 /24s >>> that were already disjoint, however, I don't want to see someone >>> with, say, 44/8 find a buyer that needs a /20 and sell them >>> 44.0.5/24, 44.0.8/24, 44.15.23/24, 44.28.6/24, etc. >> >> How about this: >> >> "The transferor's resources may be recursively bisected the minimum >> number of times necessary to create one CIDR block equal to the >> transferee's justified need." >> >> So, if someone with a /8 wants to sell you a /20, their /8 would be >> divided into one /9, one /10, one /11, one /12, one /13, one /14, one >> /15, one /16, one /17, one /18, one /19 and two /20s, and then you >> would get one of those /20s. > > I believe that would be acceptable, but I would need to know how staff > would interpret the language and some assurance that said statement of > interpretation would be binding. (Would staff interpretation of the > former paragraph match the example in the latter?) That, of course, would fall to Mr. Curran to answer, but I can't see any valid alternate interpretation. > How would it perform against the examples I posted a few moments ago? 1. Not allowed, because bisecting past /19 would exceed what was necessary to meet Org B's justified need. 2. Not allowed, because bisecting past /19 would exceed what was necessary to meet Org B's justified need. 3. Allowed. Since no division is required, the above text does not activate. 4. Allowed. The /20 would be divided into one /21, one /22, one /23, and two /24s. The two /24s would be transferred to Orgs B and C. The /23 would be divided into two /24s. Those two /24s would be transferred to Orgs D and E. > (Since we thought we understood how staff would interpret 8.3 at the > time and it turned out not to work as we thought). You might have; I knew I didn't understand it, but I also knew that getting a possibly-broken policy passed ASAP was necessary to avoid establishing that going around ARIN was the only way to get things done. >> If you agree with that, I'll figure out how to shoehorn it into the >> existing text of NRPM 8.3, though I'd prefer a complete restructuring. > > This intrigues me. Please elaborate on your desired restructuring? My main priority would be changing it from one long, complicated block of text into something more structured (subsections, lists, etc.) with shorter, simpler sentences. The result would almost certainly be longer, but that's the only way to get clarity. >> I also see several ugly possibilities when the transferor has >> multiple blocks of different sizes available to sell, but I'd need to >> see examples of how you'd want those handled before I could address >> them (no pun intended). However, assuming that aggregation has >> inherent value to buyers, sellers will avoid them out of >> self-interest, so we may not need to put anything into policy. Is >> anyone seriously concerned that assumption is wrong? > > ... > I am very concerned that your assumption about the value of > aggregation to buyers is wrong. The main value, in my view, comes from the greater likelihood of one's prefix being accepted in the DFZ both today and in the future. One /20 is obviously more valuable than sixteen /24s. However, how high could ISPs really raise the bar before their customers screamed about not being able to reach the "entire Internet"? Is one /19 really more valuable than two /20s? S -- Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3646 bytes Desc: S/MIME Cryptographic Signature URL: From owen at delong.com Mon May 2 17:48:43 2011 From: owen at delong.com (Owen DeLong) Date: Mon, 2 May 2011 14:48:43 -0700 Subject: [arin-ppml] ARIN-prop-147 Set Transfer Need to 24 months and Clarify Exception In-Reply-To: <4DBEF12A.2020002@arin.net> References: <4DBEF12A.2020002@arin.net> Message-ID: <03F0539F-6F62-49CD-84F8-9ABC62095596@delong.com> I do not support the proposal as written. First, I don't see a benefit to the community from adding 8.2 to the exemption. 8.2 is for transferring resources already in use as a result of M&A and as such should not require any sort of exemption or time period specification of any type. The resources should already have justified need and be in use at the time of transfer. Adding a 24 month time frame for speculative need only enhances the opportunities for fraudulent transfers and abuse. Second, I think there was value in preserving the 12 month horizon for transfers in that the shortening of the horizon to three months was for the purpose of limiting the extent to which a single organization could "shut out" their competitors by collecting a twelve month supply of addresses right as several of them ran out. No such protection makes sense in the transfer market. However, expanding policy to a 24 month horizon makes no more sense for transfers than it would have for allocations. Owen On May 2, 2011, at 11:00 AM, ARIN wrote: > ARIN-prop-147 Set Transfer Need to 24 months and Clarify Exception > > 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-147 Set Transfer Need to 24 months and Clarify Exception > > Proposal Originator: Matthew Kaufman > > Proposal Version: 1 > > Date: 2 May 2011 > > Proposal type: new > > Policy term: permanent > > Policy statement: > > Change section 4.2.4.4 content as follows: > > Replace: > "This reduction does not apply to resources received via section 8.3. An > organization receiving a transfer under section 8.3 may continue to > request up to a 12-month supply of IP addresses." > > With: > "This reduction does not apply to resources received via transfer. An > organization receiving a transfer under section 8 may request up to a > 24-month supply of IP addresses." > > Rationale: > > The exception should apply to transfers under 8.2 as well as 8.3 (and > any future transfer policies). > > Due to the complexity of the financial transaction that may be > involved and the associated budgeting on the part of the receiving > organization, 24 months is a more reasonable amount of forecast need to > allow to be fulfilled via the transfer process. > > Potential benefit to address aggregation by allowing fewer larger > transfers sooner. > > 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 matthew at matthew.at Mon May 2 17:51:46 2011 From: matthew at matthew.at (Matthew Kaufman) Date: Mon, 2 May 2011 14:51:46 -0700 Subject: [arin-ppml] ARIN-prop-146 Clarify Justified Need for Transfers In-Reply-To: <88F39B20-5C20-45F0-AD61-5FA1E7F84CE3@delong.com> References: <4DBEF120.4080901@arin.net> <88F39B20-5C20-45F0-AD61-5FA1E7F84CE3@delong.com> Message-ID: <3FCD1FDC-ECEE-4C9B-95C6-59E03D3C314E@matthew.at> On May 2, 2011, at 2:42 PM, Owen DeLong wrote: > there is no reason > to treat transfers differently from initial allocations and assignments. Fundamentally disagree. Policy for handing out the last of the free pool of IPv4 (which has already become much MORE restrictive, now that we are subject to the "last /8" policies) should be different than policy for approving transfer recipients. There is no reason to believe, for instance, that we are in the "last /8" of transfers. And no new entrant post-runout will spend the time and money attempting to acquire only what they can justify for a 3-month period. Matthew Kaufman From owen at delong.com Mon May 2 17:54:48 2011 From: owen at delong.com (Owen DeLong) Date: Mon, 2 May 2011 14:54:48 -0700 Subject: [arin-ppml] Accusation of fundamental conflictof interest/IPaddress policy pitched directly to ICANN In-Reply-To: <3770701FD04F4F678AF7188174246730@mike> References: <4DBB208B.4060808@ipinc.net><112FF1070FFF4B7E957E13C757CCB513@vid eo><23B533DB44354E3EA201D0941C47C46C@video><861B310C-7502-49FE-BD13-3D1B123A57EB @delong.com><274D7568A828485B91D64F9308B3A24E@video> <4DBEEC4B.3080602@abenaki.wabanaki.net> <3770701FD04F4F678AF7188174246730@mike> Message-ID: <0EBB3920-D764-4408-AA8C-5CDC7F8203F1@delong.com> On May 2, 2011, at 11:07 AM, Mike Burns wrote: > Hi Eric, > > I don't think it makes sense to view the RIRs, who are latecomers after all, as the top of the totem pole in terms of authority. > As a member who received his allocation prior to ARIN's existence, and all the other RIR's existences, I know there is a higher authority. > Whether the contract is being reviewed or not, the contract with DoC exists. > I'm in the same boat with respect to my IPv4 resources and I still disagree with you about authority. The DoC involvement at this point is largely a historical fluke more than a meaningful authority over the address space or the policies that govern it. I think that if USDoC attempted to instruct APNIC or any of the other non-ARIN RIRs in what they should do with IPv4 policy, you would see them tell the USDoC that it is a very nice thing that there are borders. > I don't understand the paragraph that begins with the word second, but I would like to, could it be rephrased? > I believe he refers to the fact that initially, number policy was the realm of a single person (Jon Postel) who later worked to create a structure under which that authority could be delegated specifically for the purposes of territorial diversity and regional self-governance. > I understand that you support the concept of regionality, but there are those pesky legacy addresses to consider, and they were allocated in a pre-regional Internet. > Not entirely and not so pesky. Each of them have been regionalized already and each RIR has their fraction of legacy resources for which they are responsible. Though they were allocated prior to regions, that is rather irrelevant. Much as the creation of the continents occurred prior to national boundaries is rather irrelevant to the fact that we now have national boundaries. Much as the fact that national boundaries as they existed in 487 A.D. are now largely irrelevant to current national boundaries other than as a historical context. > Would you consider that legacy addresses, at the least, should be portable to an alternate registry? > No. An alternate registry system does nothing to improve the situation for the address using community and only serves to increase confusion, decrease stability and otherwise incorporate motivations other than community consensus into the policy process. Owen > Regards, > > Mike > > > > > > > ----- Original Message ----- From: "Eric Brunner-Williams" > To: > Sent: Monday, May 02, 2011 1:39 PM > Subject: Re: [arin-ppml] Accusation of fundamental conflictof interest/IPaddress policy pitched directly to ICANN > > >> On 5/2/11 9:27 AM, Mike Burns wrote: >>> The authority flows down from the US Dept of Commerce. It doesn't go >>> from there to the RIRs and back up to ICANN. >>> ICANN>>RIRs >> >> what statutory authority? >> >> i see two possible errors in mike's response to owen, john, etc. >> >> first, he characterizes the iana function as an institutional actor, and thereby a "higher authority", rather than as a function currently contained within a set of functions in, or added to, the contract now the subject of review by the department of commerce. see the federal register of february 25th for the notice of inquiry. >> >> second, in an error more generally shared than this specific context, he removes the specific purposes of diversity of territorial jurisdiction and scaling for the initial reformation of the "numbers czar" function to one which permits delegation, creating the rir responsibilities. >> >> these historic purposes are not modernly inoperative, nor replaced without risk by a novel aterritorial responsibility serving no diversity of territorial or scaling interests, however beneficial such a grant of franchise may be to the recipient. >> >> eric >> _______________________________________________ >> 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 Mon May 2 17:59:16 2011 From: owen at delong.com (Owen DeLong) Date: Mon, 2 May 2011 14:59:16 -0700 Subject: [arin-ppml] ARIN-prop-140 Business Failure Clarification In-Reply-To: <4CF8BEEF-4CFB-4EB6-B395-9CB1CEF8326B@matthew.at> References: <11050210594687_A4@oregon.uoregon.edu> <4CF8BEEF-4CFB-4EB6-B395-9CB1CEF8326B@matthew.at> Message-ID: On May 2, 2011, at 11:20 AM, Matthew Kaufman wrote: > > On May 2, 2011, at 10:59 AM, Joe St Sauver wrote: > >> >> I have some concerns with the proposed language. >> >> While I am not a lawyer and this is not legal advice, it is my understanding >> that not all types of US bankruptcies are the same. >> >> For example, while it is true that a company often comes out the other side >> of a Chapter 11 reorganization as a functioning entity, a totally insolvent >> company that files a Chapter 7 liquidation is typically disolved/end-of-life/ >> out-of-business for all intents and purposes. > > Correct. But is it better for their creditors to be paid using the proceeds of an 8.3 transfer, or is it better for ARIN to attempt to reclaim the addresses. It is questionable if the latter would succeed anyway, given that in Chapter 7 the assets (and anything even somewhat like "assets") are frozen... and that the Nortel-Microsoft transfer is an example of how the court treats this. > > Part of the intent here is to bring written policy into agreement with how this is actually being implemented. > I would rather see us lobby for the government to specify that addresses are not assets and that in Chapter 7 or any other liquidation, address resources are returned to the respective RIR for distribution according to community consensus based policies. In short, I see no reason to give up and accept things as they have been rather than attempt to improve them, instead. Owen From matthew at matthew.at Mon May 2 18:04:40 2011 From: matthew at matthew.at (Matthew Kaufman) Date: Mon, 2 May 2011 15:04:40 -0700 Subject: [arin-ppml] ARIN-prop-147 Set Transfer Need to 24 months and Clarify Exception In-Reply-To: <03F0539F-6F62-49CD-84F8-9ABC62095596@delong.com> References: <4DBEF12A.2020002@arin.net> <03F0539F-6F62-49CD-84F8-9ABC62095596@delong.com> Message-ID: <69160560-5FF3-4CEE-B688-84CCB6AD2426@matthew.at> On May 2, 2011, at 2:48 PM, Owen DeLong wrote: > I do not support the proposal as written. > > First, I don't see a benefit to the community from adding 8.2 to the > exemption. 8.2 is for transferring resources already in use as a > result of M&A and as such should not require any sort of exemption > or time period specification of any type. > The resources should already > have justified need and be in use at the time of transfer. Addresses involved in an 8.2 transfer are not necessarily "already in use". The source organization may have a considerable number of legacy addresses and/or have recently qualified for addresses based on a needs justification that is no longer applicable... therefore the new organization must re-qualify. If they are to re-qualify, it doesn't make sense that they be forced to justify only a 3-month supply simply because the free pool is low or empty. > Adding > a 24 month time frame for speculative need only enhances the > opportunities for fraudulent transfers and abuse. It also has other benefits, but perhaps these proposals should be split so we can debate them separately. > > Second, I think there was value in preserving the 12 month horizon > for transfers in that the shortening of the horizon to three months > was for the purpose of limiting the extent to which a single organization > could "shut out" their competitors by collecting a twelve month supply > of addresses right as several of them ran out. No such protection makes > sense in the transfer market. Nor does it make sense in the M&A transfer context, but you just argued the other way above. > However, expanding policy to a 24 > month horizon makes no more sense for transfers than it would have > for allocations. Transfers require considerably more work on the part of two non-ARIN parties. Furthermore, the uncertainty of the IPv4 market makes the inability to acquire additional space that is justified, albeit over a longer interval, a serious problem... how can you get investment for something that you intend to build over the next 2 years if you can only get the first year of space now via transfer and the second one is totally dependent on whether or not there even IS a seller down the road... as opposed to just ponying up the cash now and getting enough space that you can make it all the way to when IPv6 really works for your application. There are also potential benefits to aggregation. See my justification statements. Matthew Kaufman > > Owen > > On May 2, 2011, at 11:00 AM, ARIN wrote: > >> ARIN-prop-147 Set Transfer Need to 24 months and Clarify Exception >> >> 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-147 Set Transfer Need to 24 months and Clarify Exception >> >> Proposal Originator: Matthew Kaufman >> >> Proposal Version: 1 >> >> Date: 2 May 2011 >> >> Proposal type: new >> >> Policy term: permanent >> >> Policy statement: >> >> Change section 4.2.4.4 content as follows: >> >> Replace: >> "This reduction does not apply to resources received via section 8.3. An >> organization receiving a transfer under section 8.3 may continue to >> request up to a 12-month supply of IP addresses." >> >> With: >> "This reduction does not apply to resources received via transfer. An >> organization receiving a transfer under section 8 may request up to a >> 24-month supply of IP addresses." >> >> Rationale: >> >> The exception should apply to transfers under 8.2 as well as 8.3 (and >> any future transfer policies). >> >> Due to the complexity of the financial transaction that may be >> involved and the associated budgeting on the part of the receiving >> organization, 24 months is a more reasonable amount of forecast need to >> allow to be fulfilled via the transfer process. >> >> Potential benefit to address aggregation by allowing fewer larger >> transfers sooner. >> >> 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 stephen at sprunk.org Mon May 2 18:07:44 2011 From: stephen at sprunk.org (Stephen Sprunk) Date: Mon, 02 May 2011 17:07:44 -0500 Subject: [arin-ppml] ARIN-prop-145 STLS Listing Immunity In-Reply-To: <53D491AB-BFBD-442A-A4EE-63FC24160282@matthew.at> References: <4DBEF116.1000400@arin.net> <53D491AB-BFBD-442A-A4EE-63FC24160282@matthew.at> Message-ID: <4DBF2B30.3080405@sprunk.org> On 02-May-11 15:13, Matthew Kaufman wrote: > On May 2, 2011, at 11:50 AM, Scott Leibrand wrote: >> I believe that ARIN has made assurances that this will not be done, >> but I would support such assurances into policy as well if people >> think it's needed. > > I think it should be written down somewhere, preferably in a place > that is changed based on community involvement (rather than simply the > STLS FAQ) in order to keep people from worrying that listing their > addresses might trigger an audit. > > Note that this applies to all listing services, but *particularly* to > STLS, as the listing on STLS is a direct statement TO ARIN that the > org thinks it can use its address space more efficiently (which an > indirect statement, as on eBay, or a hidden statement, as via a 3rd > party soliciting bids does not) I'm not sure I understand this concern. The NRPM allows all sorts of inefficiencies; for instance, you are allowed to put a public IP on every PC, which might justify a /16, even though it is "more efficient" to use NAT, which might justify only a /24. Listing a /16 you obtained years ago to do the former is not an admission of past or present fraud; it's merely an admission that you'd be willing to improve your efficiency /above /the minimum required if someone offered you sufficient financial motivation. (I have some comments on the proposed text I'll post later, but I figured it was more pressing to address the rationale.) S -- Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3646 bytes Desc: S/MIME Cryptographic Signature URL: From owen at delong.com Mon May 2 18:08:38 2011 From: owen at delong.com (Owen DeLong) Date: Mon, 2 May 2011 15:08:38 -0700 Subject: [arin-ppml] ARIN-prop-145 STLS Listing Immunity In-Reply-To: References: <4DBEF116.1000400@arin.net> Message-ID: <2A789C07-5DFD-473C-B6C2-C27704CEEF56@delong.com> On May 2, 2011, at 11:50 AM, Scott Leibrand wrote: > On Mon, May 2, 2011 at 10:59 AM, ARIN wrote: > ARIN-prop-145 STLS Listing Immunity > > > > Add a subsection to Section 12 (Resource Review) of the NRPM: > > ARIN may not revoke any resources issued by ARIN that are presently > listed as "available" on the ARIN Specified Transfer Listing Service > unless there is sufficient reason to believe that the holder does not in > fact intend to transfer these resources. > > Another way to accomplish this would be with the following language from the original transfer policy proposal, 2008-2: > > The fact that an IPv4 address holder is making IPv4 addresses available for transfer, pursuant to this policy, does not, in and of itself, indicate that the address holder lacks the need required for an allocation under ARIN policy. > I could accept this language as it does not create a presumption that listing the addresses exempts them from review. The proposed language in 145 creates a presumption that ARIN has to overcome through greater evidence and/or cost/effort. > > I believe that ARIN has made assurances that this will not be done, but I would support such assurances into policy as well if people think it's needed. > As would I, so long as it is not done in such a way as to turn listing into a presumptive blanket exclusion from policy enforcement. > This policy would also serve to increase the value of the ARIN STLS over > other possible transfer listing services, increasing the transparency of > the transfer market, particularly to ARIN, who wishes to ensure that > transfers take place within NRPM 8.3. > > > I think it's important to make any "Safe Harbor" statement apply to all IPv4 addresses being made available for transfer (including those on eBay etc.) not just those offered through ARIN's Specified Transfer Listing Service. ARIN has repeatedly made clear that the STLS is completely optional, which I believe is the right way to approach it. I don't believe we should be giving the STLS preferential treatment in the transfer policy in any way. > I don't consider it particularly important to extend safe harbor provisions beyond STLS. People can use whichever listing service they wish. Having safe harbor provisions as an advantage to using STLS does not strike me as inherently bad. I'm not opposed to extending them, but I don't think it is particularly important to do so. Owen -------------- next part -------------- An HTML attachment was scrubbed... URL: From owen at delong.com Mon May 2 18:11:02 2011 From: owen at delong.com (Owen DeLong) Date: Mon, 2 May 2011 15:11:02 -0700 Subject: [arin-ppml] Accusation of fundamental conflict ofinterest/IPaddresspolicy pitched directly to ICANN In-Reply-To: <96AF0FBE0B5A40CFB80A34CA2FF86FCA@mike> References: <4DBEE79C.6030007@globis.net> <4DBEFDC0.3070705@globis.net> <96AF0FBE0B5A40CFB80A34CA2FF86FCA@mike> Message-ID: <4FCED89C-2A44-46AF-8D65-35A405D8AB89@delong.com> Look again... They did not sell the addresses. They sold the registration of and the right to use the addresses in a particular manner. Owen On May 2, 2011, at 12:09 PM, Mike Burns wrote: > > > ----- Original Message ----- > From: Ray Hunter > To: Mike Burns > Cc: arin-ppml at arin.net > Sent: Monday, May 02, 2011 2:53 PM > Subject: Re: [arin-ppml] Accusation of fundamental conflict ofinterest/IPaddresspolicy pitched directly to ICANN > > No one owns the addresses today. They're just 32 bit numbers. That's all. Nothing more. Nothing less. No one ever owned the addresses. They have zero intrinsic value. > > Ray, > > That train has left the station. Nortel sold addresses to Microsoft for $7.5 million. > Addresses which have been allocated very obviously have a value different from a random string of 32 bit numbers. > You can argue that they shouldn't, you can argue that correct stewardship would be to establish policies to kill IPv4 and thus transition more swiftly. > > But you can't argue that they have zero value. > > Regards, > Mike > > _______________________________________________ > 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 2 18:18:14 2011 From: owen at delong.com (Owen DeLong) Date: Mon, 2 May 2011 15:18:14 -0700 Subject: [arin-ppml] Analogies In-Reply-To: References: <39209.1303885464@tristatelogic.com> <75822E125BCB994F8446858C4B19F0D7173057C827@SUEX07-MBX-04.ad.syr.edu> <471D76419F9EF642962323D13DF1DF69011E5C@newserver.arneill-py.local> <7348D3C8-4EB7-4440-A152-210CC8B0DA3C@arin.net> <471D76419F9EF642962323D13DF1DF69011E60@newserver.arneill-py.local> <583A067A-B8AE-4026-844E-6769D1D7CF88@arin.net> <471D76419F9EF642962323D13DF1DF69011E61@newserver.arneill-py.local> <7DF2A1C4-1799-486B-A631-2E1119C22A7C@arin.net> <3CCC6D1F-11F4-40BC-B102-CC6744A5E709@virtualized.org> <4DB9BACE.6000307@ipinc.net> <0E134D8B-0A4B-466E-B261-9C7D0ED11867@virtualized.org> <388190E3-08F2-4AC7-870A-621A2FD6EEFE@virtualized.org> <2ABCF380-7866-4ED8-BE43-C789CBEBFE27@delong.com> Message-ID: On May 2, 2011, at 12:33 PM, William Herrin wrote: > On Mon, May 2, 2011 at 3:24 PM, Owen DeLong wrote: >> On Apr 30, 2011, at 5:39 PM, William Herrin wrote: >>> I will suggest that an attempt by ARIN to charge $100/year under a >>> contract simplified to, "We agree to keep your whois data and RDNS >>> delegations intact as is for one year increments until either of us >>> choose to cancel this contract" would meet with at most mild >>> resistance from the legacy registrants. It would also, IMHO, provide >>> an excellent way to weed out the abandoned registrations. >> >> That seems like a reasonable summary of the current LRSA. > > If counsel agrees with that assessment (he doesn't and you didn't > check) then start summarizing and put the result in front of me, > without all the excess baggage in the current LRSA. Please specifically define the term excess baggage and show me in what ways it conflicts with the above summary. Owen From owen at delong.com Mon May 2 18:17:06 2011 From: owen at delong.com (Owen DeLong) Date: Mon, 2 May 2011 15:17:06 -0700 Subject: [arin-ppml] Accusation of fundamental conflict of interest/IPaddress policy pitched directly to ICANN In-Reply-To: <96228BA36D5948208E79184A5D1C0D6A@mike> References: <4DBB208B.4060808@ipinc.net> <112FF1070FFF4B7E957E13C757CCB513@video> <23B533DB44354E3EA201D0941C47C46C@video> <861B310C-7502-49FE-BD13-3D1B123A57EB@delong.com> <274D7568A828485B91D64F9308B3A24E@video> <1EA5AF3B-EE53-4D0B-8F2E-E011A4397497@delong.com> <96228BA36D5948208E79184A5D1C0D6A@mike> Message-ID: On May 2, 2011, at 12:30 PM, Mike Burns wrote: > Owen, > > The salient point was that the document was accepted by the ICANN Board of Directors. I believe that acceptance was a formality at the time. However, at this time, since it has been accepted, it specifies that the ASO/NRO define global policy for number resources and are autonomous and free from interference by the ICANN Board. > My reading of this is that while the ASO recommended a policy, it was decided by ICANN. > You may call that a formality, but to me the relevant positions of authority are clear. > I grant that it would appear better to the world community if the decision were made with expressed community support. > Perhaps, as I suggested earlier, both IETF and DoC should be involved in the decision. > You are welcome to involve whoever you want in the decision. Anyone may propose, comment on, express support for or opposition to any global policy proposal in each fo the 5 regions. However, to make a change to global policy, it has to go through the global policy proposal process documented as I described. > But to ask the RIRs whether to dilute their position by allowing private competing registries is a question asked and answered. > You make this claim and yet I have yet to see a single global proposal to this effect. I'm not saying I would support such a proposal... I would not. However, you haven't even asked as near as I can tell. As such, how can you claim that the question has been asked and answered? Owen > Regards, > Mike > > > ----- Original Message ----- > From: Owen DeLong > To: Mike Burns > Cc: John Curran ; arin-ppml at arin.net > Sent: Monday, May 02, 2011 3:13 PM > Subject: Re: [arin-ppml] Accusation of fundamental conflict of interest/IPaddress policy pitched directly to ICANN > > > On Apr 30, 2011, at 1:48 PM, Mike Burns wrote: > >>> What higher organizational level? >> >>> The Number Resource Organization and Address Supporting Organization roles at the IANA are the collective committee of representatives from the 5 RIRs. >Global address policy results from the same policy being passed by all RIRs and then ratified (a formality) at the IANA level. The "higher level organization" is >completely and directly controlled by the RIRs, as it should be. >> >>> Owen >> >> I think you misconstrue the relationship and have the tail wagging the dog. >> ICANN/IANA is the entity that delegated the roles you describe, the NRO and ASO roles, to committees which are run by representatives from the RIRs. >> > Sort of... > >> "The Internet Assigned Numbers Authority (the IANA), as part of the administrative functions associated with management of the Internet Protocol (IP) address space, is responsible for evaluating applications for approval of new Regional Internet Registries. " >> > Look again at the header for the ICP-2 Document (emphasis mine): > > IMPORTANT NOTICE. The following Internet Coordination Policy is being posted for the information of the Internet community. It contains a statement of policy followed by the Internet Assigned Numbers Authority (IANA) in administering the system for allocation and assignment of Internet Protocol (IP) addresses. > This document was developed through ICANN's Address Supporting Organization (ASO) with the assistance of APNIC, ARIN, and RIPE NCC, was recommended by the ASO's Address Council, and on 4 June 2001 was accepted by the ICANN Board of Directors as a statement of essential requirements for the recognition of new Regional Internet Registries (RIRs), in supplementation to section 9 of the ASO-Memorandum of Understanding, and acknowledged it as a framework for consideration of applications for recognition of new RIRs. > Comments on this document are welcome and should be directed to comments at icann.org. > > Note the emphasized phrase... The document was developed through the ASO (a committee of the RIRs) and was recommended by the ASOs AC (a committee of representatives elected BY the RIR communities). > > The number resource administration portion of IANA is governed entirely by the RIRs and that is, as I said, > the proper bottom-up way things should be managed. > >> All I am saying is that although this is not a new "regional" registry, it is a registry which could compete with the RIRs, and why not have IANA decide, since the representatives of the RIRs may have a vested interest in "regional-only" self-preservation which would affect their votes? >> > Again, what part of IANA would you have decide? IMHO, this would have to rest in the NRO. > > See also: > > http://www.icann.org/en/aso/aso-mou-29oct04.htm > > The NRO (Number Resource Organization) which is a forum of the 5 RIRs is given the role of the ASO > as defined in the ICANN charter. The ASO (Address Supporting Organization) is essentially fully autonomous > with ICANN under the above referenced document. > > There is no authority at ICANN to override the RIRs collective decisions. > >> I have nothing against the RIRs being heard and their case presented, but if their decision is dispositive, it appears as if the fox is guarding the henhouse. >> > > I disagree with your characterization of the RIRs as a fox. In reality, the above referenced documents > make it quite clear that the process is governed by the bottom-up community-consenus policy process. > > You can make changes to any global policy and such changes could override the MOU and/or the > ICP-2 document. However, to make those changes, you must acquire community consensus for them > in each of the 5 RIRs as a global policy proposal. > > Much like getting an amendment to the US constitution requires ratification by 2/3rds of the state > legislatures. > > To me, this seems right and good. > > Owen > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From owen at delong.com Mon May 2 18:28:57 2011 From: owen at delong.com (Owen DeLong) Date: Mon, 2 May 2011 15:28:57 -0700 Subject: [arin-ppml] Fw: Accusation of fundamental conflict ofinterest/IPaddress policy pitched directly to ICANN In-Reply-To: References: Message-ID: So your argument boils down to: I don't like who the communities elected, so, I want to shop for a different forum? Owen On May 2, 2011, at 1:13 PM, Mike Burns wrote: > Hi Tim, > > Just read the names of the committe members. > Enough said. > > Regards, > Mike > > ----- Original Message ----- From: "McTim" > To: "Mike Burns" > Cc: > Sent: Monday, May 02, 2011 4:06 PM > Subject: Re: Fw: [arin-ppml] Accusation of fundamental conflict ofinterest/IPaddress policy pitched directly to ICANN > > > On Mon, May 2, 2011 at 7:48 PM, Mike Burns wrote: >>> Can you be more specific? The ICANN ASO? the ICANN BoT? the IANA? >> >> Hi Tim, >> >> Keep going, all the organizations above are suspect due to the fact that >> they are all comprised of the same basic group of RIR designees. > > The RIRs do not "designate" or appoint anyone to any of the above > bodies. The ASO AC members are elected by their respective RIR > communities. Those ASO AC members do have a role to play in choosing > 2 (IIRC) of the ICANN Board. Neither the RIRs nor the ASO get to > choose IANA staff. > >> >> I would take it to NTIA like DNS. > > I think you overestimate the role of the NTIA in the DNS. > >> >> And I would use DNS as a template for the creation of the global policy >> restrictions John Curran asked about, which restrictions would apply to all >> registries, regional or commercial. >> Just as all DNS registrars must meet certain qualifications, so would >> private registries of number space. >> >> Let the NTIA hear arguments from the proposer and from the ASO, the ICANN >> BoT, and IANA, although I suspect they will all sound the same. > > > Back in the 1990's, the idea was for the USG to divest itself (via > ICANN) of the naming and numbering roles. That process is still > ongoing, and one can see a certain acceleration of divestiture in > recent years. The Affirmation of Commitments is, I think, an example > of this. > > As DF has indicated, this (asking the NTIA to make this kind of > determination) would be a real non-starter for the global Internet > Governance community. > > -- > Cheers, > > McTim > "A name indicates what we seek. An address indicates where it is. A > route indicates how we get there." Jon Postel > _______________________________________________ > 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 2 18:25:36 2011 From: owen at delong.com (Owen DeLong) Date: Mon, 2 May 2011 15:25:36 -0700 Subject: [arin-ppml] NRPN 8.2 & 2.3 In-Reply-To: <61CEAA1048BE416E9BD7FB5C7CBF47FB@mike> References: <61CEAA1048BE416E9BD7FB5C7CBF47FB@mike> Message-ID: <12539DE2-CAC3-4891-9B02-B146AECD3FB6@delong.com> On May 2, 2011, at 12:57 PM, Mike Burns wrote: > >It seems the community is > >rather divided with some advocating a complete abandonment > >of the principles of stewardship in favor of a laissez faire > >address economy while others favor preservation of the > >principles of stewardship and justified need while enabling > >market incentives to free up space. > >Owen > > > Removing artificial restrictions on the transfer of IP address space is not, as Owen persists in characterizing it, an abandonment of the principles of stewardship. Yes... It is. > Stewardship simply means different things pre- and post-exhaust. No, it does not. > Pre-exhaust requires needs analyses to ensure efficient use of address space. > Post-exahust, efficient use is ensured by the same market incentives you claim enables the freeing up of space. > To wit, price. > I don't believe that is a dependable system because without the needs basis, you open up the potential for a new class of organization... The speculator who wants to come in, use vast financial resources to acquire all addresses priced below some threshold he believes to be viable and then wait until the market desire for the resource exceeds that price (potentially by a wide margin). This delays the availability of addresses to a wider set of justified need while increasing the price without benefit to the community. The only entitiy that gains in this environment is the speculator. Everyone else loses. That is, regardless of what else you may think, in my mind an obvious abandonment of the responsibility of stewardship. > I don't believe that there has been an answer to those of us who said that while it is grammatically acceptable to decide that a "single aggregate" relates to the needs justification, it is nonsensical to do that, as all needs analyses result in a single aggregate. You don't have a needs analysis at any time where it is found that a need is outside CIDR boundaries. Need assessment has always rounded up to that boundary. > I agree with you that is the case. > No, the only way to interpret the language of 8.3 is that the reception of the addresses should occur as a single aggregate, which is clear has not occurred with 8.3. > To say the staff or the board acted outside of policy is correct in the MS/Nortel case. > While it is nonsensical, I have found that the law is often nonsensical in its interpretation of plain English. The supreme court has somehow managed to interpret the plain English of the first amendment to include the ability to bankroll a campaign by a corporation as a form of protected free speech. To me, this seems completely nonsensical. So, we can't rule out a nonsensical interpretation and we need to write language that cannot be nonsensically interpreted. Owen > Regards, > Mike > > > > ----- Original Message ----- > From: Owen DeLong > To: Rudolph Daniel > Cc: arin-ppml at arin.net > Sent: Monday, May 02, 2011 3:44 PM > Subject: Re: [arin-ppml] NRPN 8.2 & 2.3 > > At this point, I would agree. However, I would like to wait until I > get a chance to discuss the matter with ARIN Counsel and > further discuss it with staff before I start crafting proposals > to do so. > > I don't feel that staff or the board have acted improperly. I think > that policy failed to express the community intent well enough > as to achieve or goals. > > I will continue to work on finding a way to bring policy better in > line with community intent, but, the hard part will be achieving > consensus on what that intent is. It seems the community is > rather divided with some advocating a complete abandonment > of the principles of stewardship in favor of a laissez faire > address economy while others favor preservation of the > principles of stewardship and justified need while enabling > market incentives to free up space. > > It is most unfortunate that we failed to produce clear policy > in 2009-1. I hope we can correct it at Philadelphia. > > Owen > > On Apr 30, 2011, at 6:48 PM, Rudolph Daniel wrote: > >> It would seem clear to me that at the very least, NRPN 8.2 and 8.3 requires rephrasing. Is that also the view of the ppml? >> >> rd >> >> >> >> for such resources, as a single aggregate", not that a single >> >> aggregate be transferred. >> > >> > ... I do not believe that Stephen's interpretation below matches the >> > meaning or the intent of the policy as I understand it. ... >> >> I don't think it does either, for the record. However, this points out >> how bad wording has left us in a situation where we're not sure /what/ >> the policy text means--much less whether we agree with it. >> >> > I do agree that your interpretation would be a syntactically and >> > grammatically valid construction, but, I believe it is contextually >> > nonsensical and not the intended meaning of the words. >> > >> > If anyone has a suggestion for making the actual intent more clear, I >> > am open to suggestions and would support making an editorial >> > correction for clarity. >> >> If you can provide examples of transfers you both do and don't wish to >> allow, I'll be happy to come up with wording to express your intent. As >> it stands, though, I don't understand your (or anyone else's) intent >> well enough to try. >> >> S >> >> -- >> Stephen Sprunk "God does not play dice." --Albert Einstein >> CCIE #3723 "God is an inveterate gambler, and He throws the >> K5SSS dice at every possible opportunity." --Stephen Hawking >> >> -------------- next part -------------- >> An HTML attachment was scrubbed... >> URL: >> -------------- next part -------------- >> A non-text attachment was scrubbed... >> Name: smime.p7s >> Type: application/pkcs7-signature >> Size: 3646 bytes >> Desc: S/MIME Cryptographic Signature >> URL: >> >> ------------------------------ >> >> Message: 2 >> Date: Sat, 30 Apr 2011 20:28:39 -0400 >> From: William Herrin >> To: John Curran >> Cc: Public Policy Mailing List >> Subject: Re: [arin-ppml] Call for a study & survey to obtain necessary >> information for policy development >> Message-ID: >> Content-Type: text/plain; charset=ISO-8859-1 >> >> On Sat, Apr 30, 2011 at 7:51 AM, John Curran wrote: >> > ? contains a specific call for ARIN to charter a study including >> > ? a survey in order to obtain additional information to assist in >> > ? policy development. >> > >> > ? I've not seen any discussion of this suggestion; would it be >> > ? possible to get feedback from the otherwise shy participants >> > ? on the PPML mailing list? >> > >> > On Apr 29, 2011, at 5:46 PM, Jeffrey Lyon wrote: >> >> what we should do is >> >> charter ARIN to conduct a comprehensive study and: >> >> >> >> - Conduct a survey of the public at large, PPML users, full members, >> >> resource holders, and the AC to gain a clear understanding of >> >> sentiment for or against an open market. >> >> - Determine how many companies actually have IPv6 migration plans and >> >> ascertain road blocks, either legitimate or financial, that are >> >> preventing migration. >> >> - Would resource holders support a model that allowed ARIN to take a >> >> small commission on resource sales and then discontinue the practice >> >> of charging an annual fee to its members who are not buying and >> >> selling resources. >> >> These seem like they could be determined by survey. >> >> >> >> - In the survey, ask IPv4 resource holders to anonymously disclose >> >> their true utilization rates and determine if companies are hoarding >> >> resources either in hopes of future resale or to cover an arbitrary >> >> future need. >> >> - Determine the amount of participants that would come forward if told >> >> they could resell their space on the open market and ultimately >> >> determine how much unneeded space is being locked away in loosely >> >> justified allocations. >> >> - Determine if resource holders would be encouraged to tighten up >> >> internal policies and free up more space if there were a fair market >> >> value assigned to their space. >> >> These strike me as very difficult to determine by anything approaching >> a statistically valid survey. I would want to see a detailed >> methodology proposed before agreeing either that money should be spent >> conducting the survey or that the results would have merit to >> contribute to the policy debate. >> >> >> >> - Determine the economic impact. Would resource holders be better off >> >> selling their resources to more affluent companies who would be able >> >> to put the space to better use? Might there be a host of struggling >> >> small businesses who would like to put their /17 - /21 on the balance >> >> sheet? Are there companies that would purchase IPv4 space at a premium >> >> if allowed to do so? >> >> This would require a cost analysis of a great many factors, only some >> of which have been touched on in the listed survey. Given the abject >> lack of use of cost analysis in the Internet industry, it would >> require at least three independent cost analyses and considerable >> subsequent debate on and validation of the methodologies... >> >> Start here: http://www.sceaonline.net/ >> >> Disclaimer: my father is a crotchety old cost analyst so I get a >> regular earful about this stuff. >> >> Regards, >> Bill Herrin >> >> >> -- >> William D. Herrin ................ herrin at dirtside.com? bill at herrin.us >> 3005 Crane Dr. ...................... Web: >> Falls Church, VA 22042-3004 >> >> >> ------------------------------ >> >> Message: 3 >> Date: Sat, 30 Apr 2011 20:39:08 -0400 >> From: William Herrin >> To: Owen DeLong >> Cc: John Curran , arin-ppml >> Subject: Re: [arin-ppml] Analogies >> Message-ID: >> Content-Type: text/plain; charset=ISO-8859-1 >> >> On Sat, Apr 30, 2011 at 1:31 AM, Owen DeLong wrote: >> > I will point out that ARIN is the only registry that did not start >> > charging their legacy holders shortly after coming into existence. >> > >> > APNIC, RIPE, AfriNIC, and LACNIC all charge their legacy holders >> > annual fees to the best of my knowledge. >> > >> > I do not know whether a contract was required in any or all cases, >> > but, the fee portion of the equation is unique to ARIN to the best >> > of my knowledge. >> >> Hi Owen, >> >> I will suggest that an attempt by ARIN to charge $100/year under a >> contract simplified to, "We agree to keep your whois data and RDNS >> delegations intact as is for one year increments until either of us >> choose to cancel this contract" would meet with at most mild >> resistance from the legacy registrants. It would also, IMHO, provide >> an excellent way to weed out the abandoned registrations. >> >> This hasn't been done in part because we, in this forum, have insisted >> that legacy registrants should not be invited into the fold under such >> terms. >> >> Regards, >> Bill Herrin >> >> >> -- >> William D. Herrin ................ herrin at dirtside.com? bill at herrin.us >> 3005 Crane Dr. ...................... Web: >> Falls Church, VA 22042-3004 >> >> >> ------------------------------ >> >> Message: 4 >> Date: Sat, 30 Apr 2011 20:43:29 -0400 >> From: "Mike Burns" >> To: "Stephen Sprunk" , "Owen DeLong" >> >> Cc: arin-ppml at arin.net >> Subject: Re: [arin-ppml] ARIN / Microsoft press release regarding IP >> addressTransfers >> Message-ID: <7B6110E30D2E40CDA7E10BCB85E290B7 at video> >> Content-Type: text/plain; charset="utf-8" >> >> >If you can provide examples of transfers you both do and don't wish to allow, I'll be happy to come up with wording to express your intent. As it stands, though, I >don't understand your (or anyone else's) intent well enough to try. >> >> >S >> >> Steve, >> >> Here is why I call BS on the claim that these transfers comply with policy: >> >> "Such transferred number resources may only be received under RSA by organizations that are within the ARIN region and can demonstrate the need for such resources, as a single aggregate, in the exact amount which they can justify under current ARIN policies." >> >> That is the text. The comma between resources and "as a single aggregate" can be read to cause the "as a single aggregate" clause to apply to either the verb phrase "be received" or the verb phrase "can demonstrate." >> >> But how would anybody demonstrate a need for multiple netblocks anyway? >> Isn't the need ALWAYS determined as a single aggregate? >> >> Regards, >> >> Mike >> >> >> >> ----- Original Message ----- >> From: Stephen Sprunk >> To: Owen DeLong >> Cc: arin-ppml at arin.net >> Sent: Saturday, April 30, 2011 8:27 PM >> Subject: Re: [arin-ppml] ARIN / Microsoft press release regarding IP addressTransfers >> >> >> On 16-Apr-11 02:19, Owen DeLong wrote: >> >> On Apr 15, 2011, at 9:53 PM, Stephen Sprunk wrote: >> >> On 15-Apr-11 19:00, Matthew Kaufman wrote: >> >> The adopted policies (if they are using the "relatively new policy" as alluded to in the release) require the transfer of *a single aggregate*. >> >> >> Not quite. NRPM 8.3 only requires the receiver "demonstrate the need for such resources, as a single aggregate", not that a single aggregate be transferred. >> >> ... I do not believe that Stephen's interpretation below matches the meaning or the intent of the policy as I understand it. ... >> >> I don't think it does either, for the record. However, this points out how bad wording has left us in a situation where we're not sure what the policy text means--much less whether we agree with it. >> >> >> I do agree that your interpretation would be a syntactically and grammatically valid construction, but, I believe it is contextually nonsensical and not the intended meaning of the words. >> >> >> If anyone has a suggestion for making the actual intent more clear, I am open to suggestions and would support making an editorial correction for clarity. >> >> If you can provide examples of transfers you both do and don't wish to allow, I'll be happy to come up with wording to express your intent. As it stands, though, I don't understand your (or anyone else's) intent well enough to try. >> >> S >> >> >> -- >> Stephen Sprunk "God does not play dice." --Albert Einstein >> CCIE #3723 "God is an inveterate gambler, and He throws the >> K5SSS dice at every possible opportunity." --Stephen Hawking >> >> >> ------------------------------------------------------------------------------ >> >> >> _______________________________________________ >> 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: >> >> ------------------------------ >> >> _______________________________________________ >> ARIN-PPML mailing list >> ARIN-PPML at arin.net >> http://lists.arin.net/mailman/listinfo/arin-ppml >> >> End of ARIN-PPML Digest, Vol 70, Issue 176 >> ****************************************** >> >> >> >> -- >> >> Rudi Daniel >> danielcharles consulting >> 1-784 498 8277 >> >> >> >> _______________________________________________ >> 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 owen at delong.com Mon May 2 18:30:56 2011 From: owen at delong.com (Owen DeLong) Date: Mon, 2 May 2011 15:30:56 -0700 Subject: [arin-ppml] ARIN-prop-144 Remove Single Aggregate requirement from Specified Transfer In-Reply-To: References: <4DBEF10B.50902@arin.net> Message-ID: <41FC4284-48B5-45BD-90B2-2398C4BEC660@delong.com> On May 2, 2011, at 1:16 PM, Matthew Petach wrote: > On Mon, May 2, 2011 at 11:52 AM, William Herrin wrote: >> On Mon, May 2, 2011 at 1:59 PM, ARIN wrote: >>> ARIN-prop-144 Remove Single Aggregate requirement from Specified Transfer >>> Proposal Originator: Matthew Kaufman >>> >>> Modify Section 8.3 as follows: >>> Change "can demonstrate the need for such resources, as a single >>> aggregate, in the exact amount which they can justify under current ARIN >>> policies" to "can demonstrate the need for such resources in the amount >>> which they can justify under current ARIN policies" >> >> Hi Matthew, >> >> IIRC, the source of that gobbledygook was that we didn't want folks >> splitting up aggregates and selling them off piecemeal. Unless we can >> find consensus on a better way to word that requirement, I would >> support the offered change. >> Regards, >> Bill Herrin > > But that's the point I'm making; the aggregates don't exist as such; they've > _already been_ split up: > > mpetach at pat1.sjc> show route terse 4.0.0.0/8 | grep \* | count > Count: 46 lines > > mpetach at pat1.sjc> show route terse 8.0.0.0/8 | grep \* | count > Count: 488 lines > > mpetach at pat1.sjc> > > Almost nobody announces their "pure" aggregate route only; so why would > we insist that address transfers would have to be done in a more pristine > manner than that in which the blocks are already being treated? > > Putting it more simply: 8.0.0.0/8 is already split into almost 500 pieces > in the routing table; allowing those 500 pieces to be transferred to other > companies has no intrinsic impact on the routing table size. > Last I looked, 500 < 65,536. Owen From owen at delong.com Mon May 2 18:34:18 2011 From: owen at delong.com (Owen DeLong) Date: Mon, 2 May 2011 15:34:18 -0700 Subject: [arin-ppml] ARIN-prop-140 Business Failure Clarification In-Reply-To: <9BC4E3EC-E693-44D9-A415-A9E0F97E1BAA@matthew.at> References: <4DBEF0DF.8060800@arin.net> <9BC4E3EC-E693-44D9-A415-A9E0F97E1BAA@matthew.at> Message-ID: <00A60C73-0282-416A-BBF1-D491ADDD18EE@delong.com> On May 2, 2011, at 1:05 PM, Matthew Kaufman wrote: > > On May 2, 2011, at 11:43 AM, William Herrin wrote: > >> On Mon, May 2, 2011 at 1:58 PM, ARIN wrote: >>> ARIN-prop-140 Business Failure Clarification >>> >>> Add to end of Section 8.1: "Note that an entity which is reorganizing >>> under any section of the US bankruptcy code (or foreign equivalent) is >>> not 'out of business' for the purpose of interpreting this section" >>> >>> Rationale: >>> >>> Potential confusion exists over the requirement to return address space >>> from a bankrupt entity. This is a needed clarification to the policy manual. >> >> Hi Matthew, >> >> If I understand properly, the language you object to in section 8.1 is: >> >> "Thus, if a company goes out of business, regardless of the reason, >> the point of contact (POC) listed for the number resource does not >> have the authority to sell, transfer, assign, or give the number >> resource to any other person or organization. The POC must notify ARIN >> if a business fails so the assigned number resources can be returned >> to the available pool of number resources if a transfer is not >> requested and justified." >> >> The main point of that paragraph is that if your company's network is >> terminated (as part of a general company shutdown) you, as the POC, >> don't get to keep the addresses as some kind of severance pay. Your >> suggested text frankly just muddies the waters further. >> >> I would suggest replacing "goes out of business" with "ceases >> operations" and just strike the last sentence entirely. > > My problem with it is actually "The POC must notify ARIN if a business fails so the assigned number resources can be returned to the available pool of number resources". > > Entering, for instance, US Chapter 7 bankruptcy is pretty clear evidence that "a business has failed" and yet there should be neither a requirement on the POC that they notify ARIN in such a case (well, actually, perhaps there should be... but usually the POC is long gone by then) nor a suggestion that ARIN will be returning addresses to the available pool any time soon. > Why not? I was the POC for an organization which failed. When I was informed that my job was being terminated and the company liquidated, the network being shut down, etc. I notified ARIN and the addresses and AS Numbers were reclaimed. This was all well and proper and correct. This was what should happen. As far as I am concerned, ARIN has my permission to disclose the details and the correspondence on this issue. (Vusion, Inc.) Owen From matthew at matthew.at Mon May 2 18:40:00 2011 From: matthew at matthew.at (Matthew Kaufman) Date: Mon, 2 May 2011 15:40:00 -0700 Subject: [arin-ppml] ARIN-prop-140 Business Failure Clarification In-Reply-To: <00A60C73-0282-416A-BBF1-D491ADDD18EE@delong.com> References: <4DBEF0DF.8060800@arin.net> <9BC4E3EC-E693-44D9-A415-A9E0F97E1BAA@matthew.at> <00A60C73-0282-416A-BBF1-D491ADDD18EE@delong.com> Message-ID: On May 2, 2011, at 3:34 PM, Owen DeLong wrote: > > I was the POC for an organization which failed. When I was informed that > my job was being terminated and the company liquidated, the network > being shut down, etc. I notified ARIN and the addresses and AS Numbers > were reclaimed. If you notified ARIN after your date/time of termination, you were probably acting outside of your authority. And these days, if you notified ARIN before talking to your management about the possibility of transferring the addresses in order to pay creditors during the liquidation you wouldn't be upholding your fiduciary responsibility to your employer. > > This was all well and proper and correct. Perhaps at that time. > > This was what should happen. Rarely, these days. Matthew Kaufman -------------- next part -------------- An HTML attachment was scrubbed... URL: From owen at delong.com Mon May 2 18:35:43 2011 From: owen at delong.com (Owen DeLong) Date: Mon, 2 May 2011 15:35:43 -0700 Subject: [arin-ppml] Accusation of fundamental conflictofinterest/IPaddresspolicy pitched directly to ICANN In-Reply-To: References: <4DBEE79C.6030007@globis.net> <4DBEFDC0.3070705@globis.net> <4DBF09D8.7020206@globis.net> <4DBF0BAC.6040703@globis.net> <921C6A7057A94379A7D4267C47D2ABEC@mike> Message-ID: On May 2, 2011, at 1:19 PM, McTim wrote: > On Mon, May 2, 2011 at 11:02 PM, Mike Burns wrote: > > > >> >> Why not an open and transparent marketplace free from artifical and >> easily-scammable justification regimes? > > Because many thousands of people over many years have determined these > policies (your "artifical and easily-scammable justification regimes) > via open, transparent, consensus based processes. They have not > (yet) determined that a open and transparent market is a better > option. I remain unconvinced that a market can be open and transparent, let alone conform to the other assumptions built into such a statement. Owen From owen at delong.com Mon May 2 18:38:03 2011 From: owen at delong.com (Owen DeLong) Date: Mon, 2 May 2011 15:38:03 -0700 Subject: [arin-ppml] Accusation of fundamental conflictofinterest/IPaddresspolicy pitched directly to ICANN In-Reply-To: References: <4DBEE79C.6030007@globis.net> <4DBEFDC0.3070705@globis.net> <4DBF09D8.7020206@globis.net> <4DBF0BAC.6040703@globis.net> <921C6A7057A94379A7D4267C47D2ABEC@mike> Message-ID: <8306EB07-BA22-4B8F-B682-39B6BDEEB7DA@delong.com> On May 2, 2011, at 1:31 PM, Mike Burns wrote: > > >> >> Why not an open and transparent marketplace free from artifical and >> easily-scammable justification regimes? > > Because many thousands of people over many years have determined these > policies (your "artifical and easily-scammable justification regimes) > via open, transparent, consensus based processes. They have not > (yet) determined that a open and transparent market is a better > option. > > -- > Cheers, > Mc Tim > > > > Hi Mc Tim, > > But all these people have acted in a world with a pool of free addresses which is close to dry. > That world is gone. Well going, anyways. > We still have a world of free addresses. Yes, they are IPv6 and not IPv4 addresses, but, the world is neither gone nor going. The world is shifting from one protocol to another. Owen From bill at herrin.us Mon May 2 18:47:29 2011 From: bill at herrin.us (William Herrin) Date: Mon, 2 May 2011 18:47:29 -0400 Subject: [arin-ppml] Analogies In-Reply-To: References: <39209.1303885464@tristatelogic.com> <75822E125BCB994F8446858C4B19F0D7173057C827@SUEX07-MBX-04.ad.syr.edu> <471D76419F9EF642962323D13DF1DF69011E5C@newserver.arneill-py.local> <7348D3C8-4EB7-4440-A152-210CC8B0DA3C@arin.net> <471D76419F9EF642962323D13DF1DF69011E60@newserver.arneill-py.local> <583A067A-B8AE-4026-844E-6769D1D7CF88@arin.net> <471D76419F9EF642962323D13DF1DF69011E61@newserver.arneill-py.local> <7DF2A1C4-1799-486B-A631-2E1119C22A7C@arin.net> <3CCC6D1F-11F4-40BC-B102-CC6744A5E709@virtualized.org> <4DB9BACE.6000307@ipinc.net> <0E134D8B-0A4B-466E-B261-9C7D0ED11867@virtualized.org> <388190E3-08F2-4AC7-870A-621A2FD6EEFE@virtualized.org> <2ABCF380-7866-4ED8-BE43-C789CBEBFE27@delong.com> Message-ID: On Mon, May 2, 2011 at 6:18 PM, Owen DeLong wrote: > On May 2, 2011, at 12:33 PM, William Herrin wrote: >> On Mon, May 2, 2011 at 3:24 PM, Owen DeLong wrote: >>> On Apr 30, 2011, at 5:39 PM, William Herrin wrote: >>>> I will suggest that an attempt by ARIN to charge $100/year under a >>>> contract simplified to, "We agree to keep your whois data and RDNS >>>> delegations intact as is for one year increments until either of us >>>> choose to cancel this contract" would meet with at most mild >>>> resistance from the legacy registrants. It would also, IMHO, provide >>>> an excellent way to weed out the abandoned registrations. >>> >>> That seems like a reasonable summary of the current LRSA. >> >> If counsel agrees with that assessment (he doesn't and you didn't >> check) then start summarizing and put the result in front of me, >> without all the excess baggage in the current LRSA. > > Please specifically define the term excess baggage and show > me in what ways it conflicts with the above summary. Excess baggage: Section 9. Property rights are immaterial to the provision of whois and dns services yet the registrant is asked to quit any such claims as a condition of the LRSA. Section 8. Annual audit. Routine auditing of the registrant's use of IP addresses is immaterial to the provision of whois and dns services. Section 7. Current and future policies. Compliance with tomorrow's NRPM is immaterial to the provision of whois and dns services. Section 14e. Nothing in my "summary" requires ARIN to discontinue whois and rdns services should the registrant decide to stop paying. 14e not only requires ARIN to discontinue services, it requires ARIN to revoke the resources, putting them into a process resulting in reallocation to someone else. And that's just the large and blatantly obvious ways (to anyone with basic English comprehension skills) in which the LRSA is nothing like my "summary." Lots more devils in the details of individual sentences. -Bill -- 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 2 18:48:11 2011 From: owen at delong.com (Owen DeLong) Date: Mon, 2 May 2011 15:48:11 -0700 Subject: [arin-ppml] Accusation of fundamental conflictofinterest/IPaddress policy pitched directly to ICANN In-Reply-To: <7646B57F7F154B028E6722D103BB57C2@mike> References: <7646B57F7F154B028E6722D103BB57C2@mike> Message-ID: On May 2, 2011, at 1:41 PM, Mike Burns wrote: > Hi Dan, > > The existence of competing registries does not imply a requirement on anybody to change, so your argument about expense to existing participants is invalid. > Not true. The chaos and disruption posed by unregulated registries will increase the costs to ARIN, ARIN members, and other participants in the industry regardless of whether they change registries or not. > And yes, the market will sort out bad actors. That's one thing free markets do. > Right... The market sorted out Enron... Eventually. However, non of us in California got our money back and we're all still paying higher electric bills as a result. The market sorted out the CMOs... Eventually. However, my house is now worth 1/3rd of what it was worth and the new restrictive regulations on refinancing prevent me from taking advantage of the new lower interest rates due to my home being devalued too close to the amount I still owe on it. Unfortunately, I wasn't irresponsible enough to be part of the cause of this problem, so, as a good actor, I am not entitled to any of the relief available from the government for the bad actors. I think I've had enough of the way markets sort out bad actors for a while. > Nobody said anything about no oversight, to the contrary I have said the registries should work under the same framework as RIRs. > The only oversight of the RIRs is their community processes and their membership-elected boards. If you are OK with the other registries being overseen by these same bodies, then, I'm not sure why you think they would somehow be run differently from the existing RIRs. > Just like all DNS registrars have to comply with rules setup to govern their behavior. > Before you can be a DNS registrar you have to comply with the rules, and maintain compliance. > There are virtually no policies about how domain names are justified or acquired in those rules. There are provisions for trademark disputes, but, those are not applicable to IP addresses (unless you think that a particular soft drink vendor should be automatically entitled to the address 67.79.75.69). Owen > It's true that I was being forward thinking about the additional services competing registries might offer, but my point is that those services would only be offered if there was a demand for them, if the private registries are to endure. > > > Regards, > > Mike > > ----- Original Message ----- From: "Alexander, Daniel" > To: "Mike Burns" ; > Sent: Monday, May 02, 2011 4:30 PM > Subject: Re: [arin-ppml] Accusation of fundamental conflictofinterest/IPaddress policy pitched directly to ICANN > > > Mike, > > While I can only speak for myself, I can attempt to answer your question > of what may perturb some people. You make several very large assumptions > in your claims, none of which were captured in the opt-in, opt-out, or any > other proposals. > > You speak of title insurance, legal teams, and other items, ensuring that > a competitive registry will provide better services than a community > defined RIR. The problem is none of this is defined or required in any > suggested framework. While some may provide these services, many may not, > and there are no mechanisms to protect the ISP's or end users who rely on > these services. > > While many advocates will quickly reply that the market will sort these > bad actors out, it will be done at the expense of the people who currently > rely on these RIR provided services at a fraction of the cost. If > competitive registries are created without oversight, the burden and > expense of validating registration records will be shifted to the very > people who are supposed to benefit from this new model. > > This begs the question from some as to what purpose a commercial registry > would serve other than to make money. > > My opinion only. > Dan Alexander > > > > > On 5/2/11 3:33 PM, "Mike Burns" wrote: > >> >> >>> But what is it about ARIN that is broken? What exactly do you think >>> needs >>> to be fixed? >> >>> The only thing I've gotten out of the discussions so far is that some >>> people think there is money to be made by providing IPv4 addresses based >>> on >>> willingness and ability to pay rather than ARIN's current >demonstrated >>> need policies. >> >>> Why is it to my benefit if someone else makes money? Particularly if it >>> perturbs the current mechanisms in a way that costs me money? >> >>> Keith Hare >> >> >> Hi Keith, >> >> What is broken about ARIN is that scandalously large numbers of netblocks >> do >> not have valid POCs, for example. The stewardship of Whois leaves a lot >> to >> be desired. >> Competitive pressures would help to finally decide who controls these >> addresses and allow them to be transferred to those who would pay for >> them. >> Network operators don't really have much of a choice in accessing Whois >> information to determine the rights to advertise addresses, and competive >> registries. >> In my experience they rely on attestation and review of proferred >> chain-of-custody docs when determining who can advertise which addresses, >> when confronted with inconsistencies with whois. >> A competitive registry with a title insurance component will give network >> operators more security when deciding questionable cases. >> >> What is broken about ARIN is that their transfer policies are more >> restrictive than APNICs, and that will cause a flow of addresses out of >> ARIN >> and into APNIC. >> A competitive registry could presumably have a different transfer policy, >> as >> APNICs differs from ARINs. >> >> What is broken about ARIN is that ARIN has professed no statutory control >> over legacy addresses in the Plzak declaration in the Kremen case, and >> yet >> attempts to control the registration of legacy resources. >> With a private registry, the address rights holders can choose to opt-out >> of >> ARIN's dictats and choose their registry voluntarily. >> >> I don't see how the creation of a private registry will perturb the >> current >> mechanisms in a way that costs you money, could you share why you feel >> that >> way? >> >> Regards, >> >> Mike Burns >> >> _______________________________________________ >> 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 farmer at umn.edu Mon May 2 19:10:04 2011 From: farmer at umn.edu (David Farmer) Date: Mon, 02 May 2011 18:10:04 -0500 Subject: [arin-ppml] ARIN-prop-140 Business Failure Clarification In-Reply-To: <949B31E1-F496-41B7-B00D-9E7160F3CF8D@matthew.at> References: <4DBEF0DF.8060800@arin.net> <949B31E1-F496-41B7-B00D-9E7160F3CF8D@matthew.at> Message-ID: <4DBF39CC.9080502@umn.edu> On 5/2/11 15:08 CDT, Matthew Kaufman wrote: > > On May 2, 2011, at 12:42 PM, William Herrin wrote: > >> On Mon, May 2, 2011 at 2:43 PM, William Herrin >> wrote: >>> "Thus, if a company goes out of business, regardless of the >>> reason, the point of contact (POC) listed for the number resource >>> does not have the authority to sell, transfer, assign, or give >>> the number resource to any other person or organization. The POC >>> must notify ARIN if a business fails so the assigned number >>> resources can be returned to the available pool of number >>> resources if a transfer is not requested and justified." >>> >>> The main point of that paragraph is that if your company's >>> network is terminated (as part of a general company shutdown) >>> you, as the POC, don't get to keep the addresses as some kind of >>> severance pay. Your suggested text frankly just muddies the >>> waters further. >> >> Another suitable rewrite might replace those two sentences with: >> >> "An individual shall not have the authority to retain, sell, >> transfer, assign, or give the number resource to any other person >> or organization solely because he is listed as the point of contact >> for an otherwise defunct organization, nor shall the organization >> cede such authority to said individual except as is consistent with >> these transfer policies." > > If that's the only point of this section then yes, your rewrite seems > appropriate. But then it might be even better to simply have a > section that explains that when you act as a POC you are acting for > the organization and if you don't have the authority to do so then > you shouldn't be acting as the POC either. Either of those options sounds good to me, but we do need to make this clear > But we'd still need to remove the suggestion that ARIN is able or > supposed to be out reclaiming addresses from "failed" businesses > before they're all the way dead. > > Again, my point being that I want people to be able to read the NRPM > to predict what ARIN will do... in the case of a bankruptcy > proceeding ARIN will NOT be going and reclaiming addresses all on > their own, I suspect. Actually, if all resources were under RSA or LRSA we really wouldn't need this at all, ARIN could reclaim resources for non-payment, following that process defined in the contracts. This works under the theory that if someone isn't paying the bills the organization is no longer functioning, which is more or less usually true. In the case a bankruptcy, the bankruptcy trustee would either need to pay ARIN or seek relief for the terms of the contract, both of which are valid and would be under to supervision of the bankruptcy judge, and in the realm of the lawyers and not really a policy problem. The problem is that most Legacy resources are not under an LRSA or RSA at this time. Therefore we need some kind of mechanism to know when ARIN should look to reclaim Legacy Resource from defunct organizations that do not have an LRSA or RSA to define a process to recover said resources. This is the crux of the issue for the hijacking and several other threads on PPML. -- =============================================== 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 owen at delong.com Mon May 2 19:07:01 2011 From: owen at delong.com (Owen DeLong) Date: Mon, 2 May 2011 16:07:01 -0700 Subject: [arin-ppml] REVISED Statistics regarding NRPM 8.3 Transfers to date In-Reply-To: References: <75E9BD24-F12F-42BF-A989-CF6CC282B28E@arin.net> <6389E6EC-7D1F-4CDA-8370-2ECB83D36029@arin.net> <156290C5-32B9-45C0-941A-ADF93E278149@delong.com> Message-ID: Sigh... Must we play word games? When the 11th one is completed, or, when the data on the 11th is available, whichever is earlier, will you please provide it to the community? Owen On May 2, 2011, at 2:01 PM, John Curran wrote: > There are only 10 completed transfers at this point. > /John > > On May 2, 2011, at 10:37 PM, Owen DeLong wrote: > >> Can you provide the data for the 11th completed transfer along the >> same lines as what was provided for the other 10 below, please? >> >> Thanks, >> >> Owen >> >> On May 1, 2011, at 10:16 AM, John Curran wrote: >> >>> On Apr 29, 2011, at 7:08 PM, John Curran wrote: >>> >>>> To date, there have been 10 completed specified transfers under NRPM 8.3: >>>> >>>> Distribution of IPv4 Resources transferred: >>>> >>>> 1 /17 >>>> 3 /20s >>>> 1 /21 >>>> 1 /23 >>>> 49 /24s >>> >>> PPML Readers - >>> >>> I'm going to expand on the above for sake of clarity, as it occurs to >>> me that the provided summary was not at all useful for analysis as >>> we combined any resources that were not a clean CIDR block >>> boundary into the "49 /24s" entry at the end of the list. >>> >>> There were 10 specified transfers total. The recipients received >>> the following aggregates (one recipient per line, all under RSA) - >>> >>> (1) /24 >>> (1) /24 >>> (1) /23 >>> (1) /17 >>> (2) /20 >>> (1) /22, (2) /23 >>> (1) /20, (1) /21, (2) /22, (2) /23 >>> (1) /20 >>> (1) /21 >>> (1) /23, (1) /24 >>> >>> In some cases, the transfers were record keeping in nature (e.g. >>> an entity recording specified transfer of an address lock already >>> in use by another related entity) Additionally, in many cases the >>> smaller blocks are actually contiguous but not aligned on a CIDR >>> block boundary (e.g. a large block with smaller blocks on either >>> side being reported as 3 distinct transferred aggregates) >>> >>> I hope this helps, and we will keep trying to provide better insight >>> into use of the NRPM 8.3 specified transfer policy. >>> >>> Thanks! >>> /John >>> >>> John Curran >>> President and CEO >>> ARIN >>> >>> >>> >>> _______________________________________________ >>> PPML >>> You are receiving this message because you are subscribed to >>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >>> Unsubscribe or manage your mailing list subscription at: >>> http://lists.arin.net/mailman/listinfo/arin-ppml >>> Please contact info at arin.net if you experience any issues. >> >> _______________________________________________ >> 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 2 19:09:01 2011 From: owen at delong.com (Owen DeLong) Date: Mon, 2 May 2011 16:09:01 -0700 Subject: [arin-ppml] Statistics regarding NRPM 8.3 Transfers to date In-Reply-To: References: <75E9BD24-F12F-42BF-A989-CF6CC282B28E@arin.net> <7406316661701612155@unknownmsgid> <3F57F52B-F1F1-4450-B493-AA4D544D8D15@arin.net> <8740380157159276993@unknownmsgid> <49E26DCB-DAF7-4A0A-912E-F981494979F5@delong.com> <4DBC2AEB.9040307@matthew.at> <4DBCA58D.4060704@sprunk.org> <2344ADD7-616E-4FA7-9552-19735926A952@delong.com><4DBD9BF5.7050002@sprunk.org> <4DBDCFB1.4040105@matthew.at> <8475B258-A979-4C4C-A4D3-C9AAFC649C71@delong.com> Message-ID: <6AE99775-3892-4225-83C8-EF294040B6B5@delong.com> On May 2, 2011, at 2:05 PM, Mike Burns wrote: >> I find your faith in a market leading to people doing the right thing... > > It's called the Invisible Hand, Owen. http://en.wikipedia.org/wiki/Invisible_hand > > Regards, > Mike Call it what you want... I can point to examples of how market self-regulation does not necessarily result in a positive outcome for the people subjected to the process. Whether it is an invisible hand or an invisible fist is largely a matter of where you are in the equation when bad actors manipulate the market for their own gains. Owen From owen at delong.com Mon May 2 19:05:40 2011 From: owen at delong.com (Owen DeLong) Date: Mon, 2 May 2011 16:05:40 -0700 Subject: [arin-ppml] New Entrants shut out? (Was: ARIN-2011-5: ... - Last Call In-Reply-To: References: <4DBAF9E2.80000@globis.net> <4DBB305F.3010205@umn.edu> <4DBB41AE.20007@ipinc.net> <412B69ED-0D49-4F1A-806C-4F250C64EAED@delong.com> <07C619E6-58E3-41FF-81EC-6BA23BDA7391@delong.com> <35A3C7E4-5FA6-46BE-B14C-E2F97579CE8D@delong.com> <79CCE0F1-EF17-495B-AC28-9495052013EB@delong.com> <92CDFD35-7489-4037-A8C7-1CB344A9F091@delong.com> Message-ID: > > Owen, > > I get the feeling that you see IPv4 as a lame horse that needs to be > taken out back. While that's certainly one approach, my logic has > always been to allow the free exchange of IPv4 until such a time that > it becomes naturally cost prohibitive. CxO's talk $, and letting the > market make IPv4 costly is a quick and dirty way to convey the > benefits of IPv6. > Not an entirely accurate characterization of my view. I see IPv4 insufficiency as an inevitable consequence of continued growth of the internet. To claim otherwise is to assume that one of the following sentences must be true: 1. At some point in the very near future, the internet will stop growing and demand for more public addresses will cease. 2. There exists a technology which will provide access to all required internet services without requiring additional address resources to meet the demands of continued growth. or 3. There will exist some combinations of limited growth and technologies which will provide a globally acceptable subset of current internet services so as to remove the need to adapt to a protocol which provides an address larger than 32 bits. I support the exchange of IPv4 until such a time that it becomes naturally cost prohibitive so long as those on the receiving end of that IPv4 exchange meet the same requirements that would exist for them to get space from the RIRs while there is still a free pool. I do not support the creation of market speculation in IPv4 addresses as a way to inflict pain on CxOs as a motivation to deploy IPv6. While I agree it would likely be effective and, indeed, I could probably benefit greatly from such a move, I think it is contrary to the interests of the wider community and would be an unnecessarily disruptive approach to solving the problem. > At the risk of getting too far off track, I give you this scenario. > There may be major ISP's who were early entrants and managed to obtain > more IP's than they ever really needed. Perhaps they have austerity I would say that there definitely are. However, what they ever really needed and what they will need in the coming future are two different metrics. > plans that allow them to keep chugging on IPv4 for years. Perhaps > their fellow competitors will do the same and IPv6 will fail to gain > immediate traction. It seems that only small to medium sized I tend to doubt this. The number of things that are already moving to IPv6, the increase in the IPv6 growth curve since February, and the rate at which IPv6 is being deployed all point to the fallacy of such an argument. Finally, there is not a sufficient critical mass of those organizations to govern the actions of the global internet overall. Instead, they may become islands disconnected from what will rapidly become the majority of the internet until they migrate their environments to IPv6 as well. > businesses are taking IPv6 seriously. Advertising IPv6 support seems > like more of a marketing gimmick than a realistic push for support by > many companies. > Interesting... Care to name some names? (I'm not above a name and shame of vendors that aren't doing the right things with IPv6 at this point). (Are you paying attention, Linksys?) I will point to http://www.he.net as a counter-example. Yes, we're getting lots of marketing mileage out of our IPv6 support, but, it's most definitely a genuine push for support on our part. I think you would be hard pressed to claim that our IPv6 support is in any way incomplete or strictly for purposes of marketing. I gain no marketing advantage of the fact that my home is fully dual stacked (except a few devices that can't do IPv6 yet) other than being able to say so when I give IPv6 talks. What I gained instead is: 1. Assurance that I won't be left behind as the world moves. 2. Experience and knowledge on IPv6 operations. 3. The ability to talk with authority about real world IPv6 deployment experience. (Yes, this took some additional experiences outside my home, too, but, those early experiences dual-stacking my house helped a lot). Owen From jcurran at arin.net Mon May 2 19:13:11 2011 From: jcurran at arin.net (John Curran) Date: Mon, 2 May 2011 23:13:11 +0000 Subject: [arin-ppml] Analogies In-Reply-To: References: <39209.1303885464@tristatelogic.com> <75822E125BCB994F8446858C4B19F0D7173057C827@SUEX07-MBX-04.ad.syr.edu> <471D76419F9EF642962323D13DF1DF69011E5C@newserver.arneill-py.local> <7348D3C8-4EB7-4440-A152-210CC8B0DA3C@arin.net> <471D76419F9EF642962323D13DF1DF69011E60@newserver.arneill-py.local> <583A067A-B8AE-4026-844E-6769D1D7CF88@arin.net> <471D76419F9EF642962323D13DF1DF69011E61@newserver.arneill-py.local> <7DF2A1C4-1799-486B-A631-2E1119C22A7C@arin.net> <3CCC6D1F-11F4-40BC-B102-CC6744A5E709@virtualized.org> <4DB9BACE.6000307@ipinc.net> <0E134D8B-0A4B-466E-B261-9C7D0ED11867@virtualized.org> <388190E3-08F2-4AC7-870A-621A2FD6EEFE@virtualized.org> <2ABCF380-7866-4ED8-BE43-C789CBEBFE27@delong.com> Message-ID: <8D07F7F5-7E60-4176-A5D3-929F160AC608@arin.net> On May 3, 2011, at 12:47 AM, William Herrin wrote: > Excess baggage: > > Section 9. Property rights are immaterial to the provision of whois > and dns services yet the registrant is asked to quit any such claims > as a condition of the LRSA. That is correct, and unlikely to change. It may be possible to adjust slightly to better specify retention of the right of exclusive use in accordance with policy and I shall look into this presently. > Section 8. Annual audit. Routine auditing of the registrant's use of > IP addresses is immaterial to the provision of whois and dns services. I do concede this now to be potential "excess baggage" considering the direction that the community has taken, and it is definitely worth reviewing for removal. > Section 7. Current and future policies. Compliance with tomorrow's > NRPM is immaterial to the provision of whois and dns services. Incorrect. You may be the registrant and have the use of the resource in accordance with policies, but other parties have some rights with respect the same registration records. For example, if the community adopts a policy which adds a new type of contact for resource records, then you are going to get one. Similarly if the community changes the policies regarding the visibility of various fields contained within the registry. While there is contractual protection against policy changes which inhibit your use of the resource, the general case is policy changes to the registry apply, and the registry services are DNS and Whois. > Section 14e. Nothing in my "summary" requires ARIN to discontinue > whois and rdns services should the registrant decide to stop paying. > 14e not only requires ARIN to discontinue services, it requires ARIN > to revoke the resources, putting them into a process resulting in > reallocation to someone else. Correct. A fundamental goal for ARIN is maintaining track of all of the assigned number resources in the region, which clearly precludes us from just deleting registry records. Obviously, that might change but only if structure of the Internet number registry system changes to have some form of overlapping service regions, as noted in other threads on this mailing list. I've got section 8 and 9 review/research tasks and will pursue. Thanks! /John John Curran President and CEO ARIN From jcurran at arin.net Mon May 2 19:14:28 2011 From: jcurran at arin.net (John Curran) Date: Mon, 2 May 2011 23:14:28 +0000 Subject: [arin-ppml] REVISED Statistics regarding NRPM 8.3 Transfers to date In-Reply-To: References: <75E9BD24-F12F-42BF-A989-CF6CC282B28E@arin.net> <6389E6EC-7D1F-4CDA-8370-2ECB83D36029@arin.net> <156290C5-32B9-45C0-941A-ADF93E278149@delong.com> Message-ID: <9A9D972F-25B5-4FB1-8FB7-38F7379729B3@arin.net> On May 3, 2011, at 1:07 AM, Owen DeLong wrote: > When the 11th one is completed, or, when the data on the 11th > is available, whichever is earlier, will you please provide it to the > community? We're going to set up standard (monthly?) reporting for transfers and will include all transfer in the reports. I gave a one-off quick report because I thought it would aid in the policy discussion. /John John Curran President and CEO ARIN From bill at herrin.us Mon May 2 19:14:08 2011 From: bill at herrin.us (William Herrin) Date: Mon, 2 May 2011 19:14:08 -0400 Subject: [arin-ppml] ARIN-2011-5: Shared Transition Space for IPv4 Address Extension - Last Call In-Reply-To: <54E900DC635DAB4DB7A6D799B3C4CD8E10C8D92B@PDAWM12B.ad.sprint.com> References: <4DAC8BCB.2000300@arin.net> <54E900DC635DAB4DB7A6D799B3C4CD8E10C7EF5E@PLSWM12A.ad.sprint.com> <3128593549961341875@unknownmsgid> <54E900DC635DAB4DB7A6D799B3C4CD8E10C899B7@PDAWM12B.ad.sprint.com> <1489147144792938659@unknownmsgid> <54E900DC635DAB4DB7A6D799B3C4CD8E10C89AC7@PDAWM12B.ad.sprint.com> <54E900DC635DAB4DB7A6D799B3C4CD8E10C8D92B@PDAWM12B.ad.sprint.com> Message-ID: On Mon, May 2, 2011 at 4:39 PM, George, Wes E [NTK] wrote: > On Mon, Apr 25, 2011 at 8:46 AM, George, Wes E [NTK] wrote: >> IPv4 addresses used behind a NAT (inside pool) cannot be used for >> justification of new resources nor counted towards utilization >> calculations for existing resources. >> NRPM 4.10.x (Shared Transition Space) defines a specific non-unique >> block to be shared among multiple networks for this purpose. > I don't understand your example, specifically how a transfer would figure into the discussion. Please try to rephrase. Sorry, I was being snarky. Under your wording, once I have placed equipment behind a NAT, I can never move it out in front of a NAT because its existence doesn't justify addresses. You could probably fix that particular problem by saying "addresses _intended to be_ used behind a NAT." But there are more problems. For example, addresses behind a bastion host firewall would still qualify even though that's basically the same use as the NAT. That's fundamentally unfair, which violates a basic precept of any public policy process.. And what about folks who decide to consume public addresses inside their stateful non-translating firewalls even though they've locked it down where the only thing that passes is outbound tcp? Is it fair that folks trying to conserve with NAT should pay an additional policy-level penalty while wasters don't? > I remain convinced that something should make it >into this version of the policy, not wait for subsequent policy action. We're going to have to deal with address revocation for unjustifiable use soon anyway. If this proposal is acceptable with changes to justified use then there's no harm in letting it past and figuring out the right changes on the other side. Regards, Bill Herrin -- 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 Mon May 2 19:20:37 2011 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Mon, 2 May 2011 19:20:37 -0400 Subject: [arin-ppml] New Entrants shut out? (Was: ARIN-2011-5: ... - Last Call In-Reply-To: References: <4DBAF9E2.80000@globis.net> <4DBB305F.3010205@umn.edu> <4DBB41AE.20007@ipinc.net> <412B69ED-0D49-4F1A-806C-4F250C64EAED@delong.com> <07C619E6-58E3-41FF-81EC-6BA23BDA7391@delong.com> <35A3C7E4-5FA6-46BE-B14C-E2F97579CE8D@delong.com> <79CCE0F1-EF17-495B-AC28-9495052013EB@delong.com> <92CDFD35-7489-4037-A8C7-1CB344A9F091@delong.com> Message-ID: On Mon, May 2, 2011 at 7:05 PM, Owen DeLong wrote: >> >> Owen, >> >> I get the feeling that you see IPv4 as a lame horse that needs to be >> taken out back. While that's certainly one approach, my logic has >> always been to allow the free exchange of IPv4 until such a time that >> it becomes naturally cost prohibitive. CxO's talk $, and letting the >> market make IPv4 costly is a quick and dirty way to convey the >> benefits of IPv6. >> > Not an entirely accurate characterization of my view. > > I see IPv4 insufficiency as an inevitable consequence of continued > growth of the internet. To claim otherwise is to assume that one > of the following sentences must be true: > > ? ? ? ?1. ? ? ?At some point in the very near future, the internet will stop > ? ? ? ? ? ? ? ?growing and demand for more public addresses will cease. > > ? ? ? ?2. ? ? ?There exists a technology which will provide access to all > ? ? ? ? ? ? ? ?required internet services without requiring additional address > ? ? ? ? ? ? ? ?resources to meet the demands of continued growth. > > or > > ? ? ? ?3. ? ? ?There will exist some combinations of limited growth and > ? ? ? ? ? ? ? ?technologies which will provide a globally acceptable > ? ? ? ? ? ? ? ?subset of current internet services so as to remove the > ? ? ? ? ? ? ? ?need to adapt to a protocol which provides an address > ? ? ? ? ? ? ? ?larger than 32 bits. > > I support the exchange of IPv4 until such a time that it becomes > naturally cost prohibitive so long as those on the receiving end > of that IPv4 exchange meet the same requirements that would > exist for them to get space from the RIRs while there is still a > free pool. > > I do not support the creation of market speculation in IPv4 addresses > as a way to inflict pain on CxOs as a motivation to deploy IPv6. > While I agree it would likely be effective and, indeed, I could probably > benefit greatly from such a move, I think it is contrary to the interests > of the wider community and would be an unnecessarily disruptive > approach to solving the problem. > >> At the risk of getting too far off track, I give you this scenario. >> There may be major ISP's who were early entrants and managed to obtain >> more IP's than they ever really needed. Perhaps they have austerity > > I would say that there definitely are. However, what they ever really > needed and what they will need in the coming future are two different > metrics. > >> plans that allow them to keep chugging on IPv4 for years. Perhaps >> their fellow competitors will do the same and IPv6 will fail to gain >> immediate traction. It seems that only small to medium sized > > I tend to doubt this. The number of things that are already moving > to IPv6, the increase in the IPv6 growth curve since February, and > the rate at which IPv6 is being deployed all point to the fallacy of > such an argument. > > Finally, there is not a sufficient critical mass of those organizations > to govern the actions of the global internet overall. Instead, they may > become islands disconnected from what will rapidly become the > majority of the internet until they migrate their environments to IPv6 > as well. > >> businesses are taking IPv6 seriously. Advertising IPv6 support seems >> like more of a marketing gimmick than a realistic push for support by >> many companies. >> > > Interesting... Care to name some names? (I'm not above a name > and shame of vendors that aren't doing the right things with IPv6 > at this point). (Are you paying attention, Linksys?) > > I will point to http://www.he.net as a counter-example. > > Yes, we're getting lots of marketing mileage out of our IPv6 support, > but, it's most definitely a genuine push for support on our part. > I think you would be hard pressed to claim that our IPv6 support > is in any way incomplete or strictly for purposes of marketing. > > I gain no marketing advantage of the fact that my home is fully > dual stacked (except a few devices that can't do IPv6 yet) > other than being able to say so when I give IPv6 talks. > What I gained instead is: > > ? ? ? ?1. ? ? ?Assurance that I won't be left behind as the world moves. > ? ? ? ?2. ? ? ?Experience and knowledge on IPv6 operations. > ? ? ? ?3. ? ? ?The ability to talk with authority about real world IPv6 > ? ? ? ? ? ? ? ?deployment experience. (Yes, this took some additional > ? ? ? ? ? ? ? ?experiences outside my home, too, but, those early > ? ? ? ? ? ? ? ?experiences dual-stacking my house helped a lot). > > Owen > > Owen, I concede that there are many advanced users such as yourself and numerous progressive companies such as HE that are fully embracing IPv6 but I do not see the largest and most well known companies taking the same lead. My strategy is to work with my vendors to encourage IPv6 support, but I am not to the point where I feel it appropriate to chastise them. -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications - AS32421 First and Leading in DDoS Protection Solutions From owen at delong.com Mon May 2 19:18:57 2011 From: owen at delong.com (Owen DeLong) Date: Mon, 2 May 2011 16:18:57 -0700 Subject: [arin-ppml] Microsoft receives court approval for transfer asagreed with ARIN In-Reply-To: References: <94030.1304191624@tristatelogic.com> <2F1F43FA-8724-4298-89C3-76ABEA5A3AAF@delong.com> Message-ID: <6DF2DA99-E28C-438D-8B46-8E45D2E9A311@delong.com> On May 2, 2011, at 2:22 PM, Jeffrey Lyon wrote: > On Mon, May 2, 2011 at 3:00 PM, Owen DeLong wrote: >>>> >>> >>> Owen, >>> >>> Could the annual fee be something like $100/yr versus $1250 and up? >> >> For LRSA signatories it already is $100/year. >> >> Owen >> >> > > It would be nice if everyone qualified for that rate. > > -- > Jeffrey Lyon, Leadership Team > jeffrey.lyon at blacklotus.net | http://www.blacklotus.net > Black Lotus Communications - AS32421 > First and Leading in DDoS Protection Solutions ISPs get a greater level of service from ARIN and their annual fees include voting membership in the organization. (An additional $500/year for end user organizations that want membership). Owen From owen at delong.com Mon May 2 19:17:18 2011 From: owen at delong.com (Owen DeLong) Date: Mon, 2 May 2011 16:17:18 -0700 Subject: [arin-ppml] Statistics regarding NRPM 8.3 Transfers to date In-Reply-To: <366DD56E-44DB-40FA-A788-97EFC9288167@matthew.at> References: <75E9BD24-F12F-42BF-A989-CF6CC282B28E@arin.net> <7406316661701612155@unknownmsgid> <3F57F52B-F1F1-4450-B493-AA4D544D8D15@arin.net> <8740380157159276993@unknownmsgid> <49E26DCB-DAF7-4A0A-912E-F981494979F5@delong.com> <4DBC2AEB.9040307@matthew.at> <4DBCA58D.4060704@sprunk.org> <2344ADD7-616E-4FA7-9552-19735926A952@delong.com> <366DD56E-44DB-40FA-A788-97EFC9288167@matthew.at> Message-ID: On May 2, 2011, at 2:04 PM, Matthew Kaufman wrote: > > On May 2, 2011, at 1:32 PM, Owen DeLong wrote: > >> >> >> 1. Org. A has a /8 and wants to transfer 32 of it's constituent /24s to Org. B. >> However, Org. A doesn't want to put any effort into renumbering, >> so, those 32 /24s are each individual non-aggregable /24s. >> >> This transfer should not be allowed. > > 1A. Org A has a /8 and wants to transfer 32 of its /24s to Org B. Org A is already announcing each of these /24s separately at different points around the world, so they've already done the deaggregation. Should the transfer still not be allowed? > Correct... The transfer still shouldn't be allowed. >> >> 2. Org. A has a /20 and a /18. Org. B has need for a /19. Org. A has >> deprecated their use of the /20 and all of their resources are in >> the /18, but, they are using just under 75% of the /18. >> >> Org. A would rather transfer the /20 and the top 1/4 of the /18 than >> renumber that 1/4 of the /18 into the /20. >> >> This transfer should not be allowed (though I admit the case against >> it is weak). >> >> 3. Org. A has four disparate /20s. Org B. has need of a /19. Org. A >> would like to transfer two of their /20s to Org. B, but does not have >> any pair of /20s which can be aggregated. >> >> This transfer should be allowed. The /20s are already disaggregated >> in the routing table and there is no increase in routing table >> size that results. > > Wouldn't it be even better if Org B was forced to find a different Org that can fulfill a /19? > I would hope that Org. B would see incentives to finding a /19, but, I don't think there is any community benefit to forcing them to do so. > (Not that I'm suggesting that this would be good policy) > >> >> 4. Org. A has four disparate /20s. Orgs. B, C, D, and E all have need >> for /24s. Org. A would like to sell individual /24s from one of their >> /20s to each of the above Orgs. (B,C, D, and E). >> >> These transfers should be allowed as there is no significant >> difference between this and transfers where ARIN has >> carved up a block during the initial allocations. The transfer >> sizes comply with community accepted policy. >> > > What is Orgs B, C, D, and E are legal subsidiaries of a single organization? > Then they are Org. B and not Orgs. B, C, D, and E. >> In essence, I'm trying to say that transfers which create unnecessary >> additional disaggregation should be avoided. > > For what definition of "unnecessary" and why is "additional" the criteria? EVERY SINGLE TIME ARIN allocates space to someone, it creates additional disaggregation... and apparently you're ok with that. > You misuse the term disaggregation. ARIN does deaggregation. When an organization needs a /20 and gets 16 separate /24s from a block that was previously treated as a /16 or some other shorter prefix, that is unnecessary disaggregation. Owen From jcurran at arin.net Mon May 2 19:23:38 2011 From: jcurran at arin.net (John Curran) Date: Mon, 2 May 2011 23:23:38 +0000 Subject: [arin-ppml] ARIN-prop-140 Business Failure Clarification In-Reply-To: <4DBF39CC.9080502@umn.edu> References: <4DBEF0DF.8060800@arin.net> <949B31E1-F496-41B7-B00D-9E7160F3CF8D@matthew.at> <4DBF39CC.9080502@umn.edu> Message-ID: <40781567-AD5F-415E-9C52-323D9697C597@arin.net> On May 3, 2011, at 1:10 AM, David Farmer wrote: > Actually, if all resources were under RSA or LRSA we really wouldn't need this at all, ARIN could reclaim resources for non-payment, following that process defined in the contracts. This works under the theory that if someone isn't paying the bills the organization is no longer functioning, which is more or less usually true. In the case a bankruptcy, the bankruptcy trustee would either need to pay ARIN or seek relief for the terms of the contract, both of which are valid and would be under to supervision of the bankruptcy judge, and in the realm of the lawyers and not really a policy problem. > > The problem is that most Legacy resources are not under an LRSA or RSA at this time. Therefore we need some kind of mechanism to know when ARIN should look to reclaim Legacy Resource from defunct organizations that do not have an LRSA or RSA to define a process to recover said resources. This is the crux of the issue for the hijacking and several other threads on PPML. David - This is not correct, even with resources under RSA. A policy which states "ARIN should reclaim resources in bankruptcies" would be *contrary to law* in some cases. Policy which directs ARIN staff contrary to law is unlikely to adopted by the ARIN Board of Trustees. FYI, /John John Curran President and CEO ARIN From jeffrey.lyon at blacklotus.net Mon May 2 19:24:54 2011 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Mon, 2 May 2011 19:24:54 -0400 Subject: [arin-ppml] Microsoft receives court approval for transfer asagreed with ARIN In-Reply-To: <6DF2DA99-E28C-438D-8B46-8E45D2E9A311@delong.com> References: <94030.1304191624@tristatelogic.com> <2F1F43FA-8724-4298-89C3-76ABEA5A3AAF@delong.com> <6DF2DA99-E28C-438D-8B46-8E45D2E9A311@delong.com> Message-ID: On Mon, May 2, 2011 at 7:18 PM, Owen DeLong wrote: > > On May 2, 2011, at 2:22 PM, Jeffrey Lyon wrote: > >> On Mon, May 2, 2011 at 3:00 PM, Owen DeLong wrote: >>>>> >>>> >>>> Owen, >>>> >>>> Could the annual fee be something like $100/yr versus $1250 and up? >>> >>> For LRSA signatories it already is $100/year. >>> >>> Owen >>> >>> >> >> It would be nice if everyone qualified for that rate. >> >> -- >> Jeffrey Lyon, Leadership Team >> jeffrey.lyon at blacklotus.net | http://www.blacklotus.net >> Black Lotus Communications - AS32421 >> First and Leading in DDoS Protection Solutions > > ISPs get a greater level of service from ARIN and their annual fees include > voting membership in the organization. (An additional $500/year for end user > organizations that want membership). > > Owen > > Yes, indeed. I have few legitimate complaints about ARIN, just noting that it would be a nice perk if ARIN were funded predominately from market making of loosely regulated transfers and less so from annual renewal fees. In fact, the entire IPv4 issue could be solved by ramping up pricing on ISP allocations but that is not a position I would support for a number of fairly obvious reasons. -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications - AS32421 First and Leading in DDoS Protection Solutions From owen at delong.com Mon May 2 19:25:02 2011 From: owen at delong.com (Owen DeLong) Date: Mon, 2 May 2011 16:25:02 -0700 Subject: [arin-ppml] ARIN-2011-5: Shared Transition Space for IPv4 Address Extension - Last Call In-Reply-To: References: <4DAC8BCB.2000300@arin.net> <54E900DC635DAB4DB7A6D799B3C4CD8E10C7EF5E@PLSWM12A.ad.sprint.com> <3128593549961341875@unknownmsgid> <54E900DC635DAB4DB7A6D799B3C4CD8E10C899B7@PDAWM12B.ad.sprint.com> <1489147144792938659@unknownmsgid> <54E900DC635DAB4DB7A6D799B3C4CD8E10C89AC7@PDAWM12B.ad.sprint.com> <0816C508-43EE-46BD-8BC2-D5F1222848FE@matthew.at> Message-ID: <0254BEBE-A3D4-45C3-8D8E-09900A11FD57@delong.com> I disagree entirely. Transfers, if they are to be permitted, should be done with the recipient required to meet exactly the same justifications as those under section 4. I see the 3-month timeframe as a temporary abomination to section 4, necessary because of special circumstances of runout. Throwing out the rest of section 4 because of it is absurd. Owen On May 2, 2011, at 2:23 PM, Scott Leibrand wrote: > On Mon, May 2, 2011 at 2:04 PM, Matthew Kaufman wrote: > > Agree. Yet again we have a problem where the needs justification for using the very last of ARIN's free pool should be totally different than the needs justification for being the recipient of an expensive resource transfer via specified transfer, and yet it isn't. > > Can't fix the one without breaking the other in this case... or agreeing that needs justification for transfers needs fixing. (One of my proposals today that hasn't received comment yet covers the issue that new recipients can only get 3 months via specified transfer, given the current text, for instance.) > > I have that one on my list to respond to. IMO we should be moving away from having 8.3 requirements depend on section 4 requirements, and instead move toward copying the necessary requirements to section 8, which whatever modifications (like 24 months) are more appropriate for transfers. But that is a bit of a project, which I don't have time for just yet. :-) > > -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 Mon May 2 19:29:56 2011 From: owen at delong.com (Owen DeLong) Date: Mon, 2 May 2011 16:29:56 -0700 Subject: [arin-ppml] ARIN-prop-146 Clarify Justified Need for Transfers In-Reply-To: <3FCD1FDC-ECEE-4C9B-95C6-59E03D3C314E@matthew.at> References: <4DBEF120.4080901@arin.net> <88F39B20-5C20-45F0-AD61-5FA1E7F84CE3@delong.com> <3FCD1FDC-ECEE-4C9B-95C6-59E03D3C314E@matthew.at> Message-ID: <5598DFC7-E320-42FA-AA0E-C91C076BD725@delong.com> On May 2, 2011, at 2:51 PM, Matthew Kaufman wrote: > > On May 2, 2011, at 2:42 PM, Owen DeLong wrote: >> there is no reason >> to treat transfers differently from initial allocations and assignments. > > Fundamentally disagree. Policy for handing out the last of the free pool of IPv4 (which has already become much MORE restrictive, now that we are subject to the "last /8" policies) should be different than policy for approving transfer recipients. There is no reason to believe, for instance, that we are in the "last /8" of transfers. And no new entrant post-runout will spend the time and money attempting to acquire only what they can justify for a 3-month period. > > Matthew Kaufman The three month restriction is a temporary abomination in the IPv4 policies related to runout. The rest of the policy is not specially restrictive related to runout. That temporary abomination is specifically exempted in 8.3, so, you already have exactly what you have stated is needed above. There is no need for a policy change. Owen From jeffrey.lyon at blacklotus.net Mon May 2 19:34:21 2011 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Mon, 2 May 2011 19:34:21 -0400 Subject: [arin-ppml] NRPN 8.2 & 2.3 In-Reply-To: <12539DE2-CAC3-4891-9B02-B146AECD3FB6@delong.com> References: <61CEAA1048BE416E9BD7FB5C7CBF47FB@mike> <12539DE2-CAC3-4891-9B02-B146AECD3FB6@delong.com> Message-ID: On Mon, May 2, 2011 at 6:25 PM, Owen DeLong wrote: > > On May 2, 2011, at 12:57 PM, Mike Burns wrote: > > >It seems the community is > >rather divided with some advocating a complete abandonment > >of the principles of stewardship in favor of a laissez faire > >address economy while others favor preservation of the > >principles of stewardship and justified need while enabling > >market incentives to free up space. > >Owen > > > Removing artificial restrictions on the transfer of IP address space is > not, as Owen persists in characterizing it, an abandonment of the principles > of stewardship. > > > Yes... It is. > > Stewardship simply means different things pre- and post-exhaust. > > > No, it does not. > > Pre-exhaust requires needs analyses to ensure efficient use of address > space. > Post-exahust, efficient use is ensured by the same market incentives you > claim enables the freeing up of space. > To wit, price. > > > > I don't believe that is a dependable system because without the needs > basis, > you open up the potential for a new class of organization... The speculator > who wants to come in, use vast financial resources to acquire all addresses > priced below some threshold he believes to be viable and then wait until > the market desire for the resource exceeds that price (potentially by a > wide > margin). This delays the availability of addresses to a wider set of > justified > need while increasing the price without benefit to the community. > > The only entitiy that gains in this environment is the speculator. Everyone > else > loses. > > That is, regardless of what else you may think, in my mind an obvious > abandonment > of the responsibility of stewardship. > > I don't believe that there has been an answer to those of us who said that > while it is grammatically acceptable to decide that a "single aggregate" > relates to the needs justification, it is nonsensical to do that, as all > needs analyses result in a single aggregate. You don't have a needs analysis > at any time where it is found that a need is outside CIDR boundaries. Need > assessment has always rounded up to that boundary. > > > > I agree with you that is the case. > > No, the only way to interpret the language of 8.3 is that the reception of > the addresses should occur as a single aggregate, which is clear has not > occurred with 8.3. > To say the staff or the board acted outside of policy is correct in the > MS/Nortel case. > > > While it is nonsensical, I have found that the law is often nonsensical in > its > interpretation of plain English. The supreme court has somehow managed > to interpret the plain English of the first amendment to include the > ability > to bankroll a campaign by a corporation as a form of protected free speech. > To me, this seems completely nonsensical. > > So, we can't rule out a nonsensical interpretation and we need to write > language that cannot be nonsensically interpreted. > > Owen > > Regards, > Mike > > > > > ----- Original Message ----- > *From:* Owen DeLong > *To:* Rudolph Daniel > *Cc:* arin-ppml at arin.net > *Sent:* Monday, May 02, 2011 3:44 PM > *Subject:* Re: [arin-ppml] NRPN 8.2 & 2.3 > > At this point, I would agree. However, I would like to wait until I > get a chance to discuss the matter with ARIN Counsel and > further discuss it with staff before I start crafting proposals > to do so. > > I don't feel that staff or the board have acted improperly. I think > that policy failed to express the community intent well enough > as to achieve or goals. > > I will continue to work on finding a way to bring policy better in > line with community intent, but, the hard part will be achieving > consensus on what that intent is. It seems the community is > rather divided with some advocating a complete abandonment > of the principles of stewardship in favor of a laissez faire > address economy while others favor preservation of the > principles of stewardship and justified need while enabling > market incentives to free up space. > > It is most unfortunate that we failed to produce clear policy > in 2009-1. I hope we can correct it at Philadelphia. > > Owen > > On Apr 30, 2011, at 6:48 PM, Rudolph Daniel wrote: > > It would seem clear to me that at the very least, NRPN 8.2 and 8.3 requires > rephrasing. Is that also the view of the ppml? > > rd > > > >> for such resources, as a single aggregate", not that a single >> >> aggregate be transferred. >> > >> > ... I do not believe that Stephen's interpretation below matches the >> > meaning or the intent of the policy as I understand it. ... >> >> I don't think it does either, for the record. However, this points out >> how bad wording has left us in a situation where we're not sure /what/ >> the policy text means--much less whether we agree with it. >> >> > I do agree that your interpretation would be a syntactically and >> > grammatically valid construction, but, I believe it is contextually >> > nonsensical and not the intended meaning of the words. >> > >> > If anyone has a suggestion for making the actual intent more clear, I >> > am open to suggestions and would support making an editorial >> > correction for clarity. >> >> If you can provide examples of transfers you both do and don't wish to >> allow, I'll be happy to come up with wording to express your intent. As >> it stands, though, I don't understand your (or anyone else's) intent >> well enough to try. >> >> S >> >> -- >> Stephen Sprunk "God does not play dice." --Albert Einstein >> CCIE #3723 "God is an inveterate gambler, and He throws the >> K5SSS dice at every possible opportunity." --Stephen Hawking >> >> -------------- next part -------------- >> An HTML attachment was scrubbed... >> URL: < >> http://lists.arin.net/pipermail/arin-ppml/attachments/20110430/ab367759/attachment-0001.html >> > >> -------------- next part -------------- >> A non-text attachment was scrubbed... >> Name: smime.p7s >> Type: application/pkcs7-signature >> Size: 3646 bytes >> Desc: S/MIME Cryptographic Signature >> URL: < >> http://lists.arin.net/pipermail/arin-ppml/attachments/20110430/ab367759/attachment-0001.bin >> > >> >> ------------------------------ >> >> Message: 2 >> Date: Sat, 30 Apr 2011 20:28:39 -0400 >> From: William Herrin >> To: John Curran >> Cc: Public Policy Mailing List >> Subject: Re: [arin-ppml] Call for a study & survey to obtain necessary >> information for policy development >> Message-ID: >> Content-Type: text/plain; charset=ISO-8859-1 >> >> On Sat, Apr 30, 2011 at 7:51 AM, John Curran wrote: >> > ? contains a specific call for ARIN to charter a study including >> > ? a survey in order to obtain additional information to assist in >> > ? policy development. >> > >> > ? I've not seen any discussion of this suggestion; would it be >> > ? possible to get feedback from the otherwise shy participants >> > ? on the PPML mailing list? >> > >> > On Apr 29, 2011, at 5:46 PM, Jeffrey Lyon wrote: >> >> what we should do is >> >> charter ARIN to conduct a comprehensive study and: >> >> >> >> - Conduct a survey of the public at large, PPML users, full members, >> >> resource holders, and the AC to gain a clear understanding of >> >> sentiment for or against an open market. >> >> - Determine how many companies actually have IPv6 migration plans and >> >> ascertain road blocks, either legitimate or financial, that are >> >> preventing migration. >> >> - Would resource holders support a model that allowed ARIN to take a >> >> small commission on resource sales and then discontinue the practice >> >> of charging an annual fee to its members who are not buying and >> >> selling resources. >> >> These seem like they could be determined by survey. >> >> >> >> - In the survey, ask IPv4 resource holders to anonymously disclose >> >> their true utilization rates and determine if companies are hoarding >> >> resources either in hopes of future resale or to cover an arbitrary >> >> future need. >> >> - Determine the amount of participants that would come forward if told >> >> they could resell their space on the open market and ultimately >> >> determine how much unneeded space is being locked away in loosely >> >> justified allocations. >> >> - Determine if resource holders would be encouraged to tighten up >> >> internal policies and free up more space if there were a fair market >> >> value assigned to their space. >> >> These strike me as very difficult to determine by anything approaching >> a statistically valid survey. I would want to see a detailed >> methodology proposed before agreeing either that money should be spent >> conducting the survey or that the results would have merit to >> contribute to the policy debate. >> >> >> >> - Determine the economic impact. Would resource holders be better off >> >> selling their resources to more affluent companies who would be able >> >> to put the space to better use? Might there be a host of struggling >> >> small businesses who would like to put their /17 - /21 on the balance >> >> sheet? Are there companies that would purchase IPv4 space at a premium >> >> if allowed to do so? >> >> This would require a cost analysis of a great many factors, only some >> of which have been touched on in the listed survey. Given the abject >> lack of use of cost analysis in the Internet industry, it would >> require at least three independent cost analyses and considerable >> subsequent debate on and validation of the methodologies... >> >> Start here: http://www.sceaonline.net/ >> >> Disclaimer: my father is a crotchety old cost analyst so I get a >> regular earful about this stuff. >> >> Regards, >> Bill Herrin >> >> >> -- >> William D. Herrin ................ herrin at dirtside.com? bill at herrin.us >> 3005 Crane Dr. ...................... Web: >> Falls Church, VA 22042-3004 >> >> >> ------------------------------ >> >> Message: 3 >> Date: Sat, 30 Apr 2011 20:39:08 -0400 >> From: William Herrin >> To: Owen DeLong >> Cc: John Curran , arin-ppml >> Subject: Re: [arin-ppml] Analogies >> Message-ID: >> Content-Type: text/plain; charset=ISO-8859-1 >> >> On Sat, Apr 30, 2011 at 1:31 AM, Owen DeLong wrote: >> > I will point out that ARIN is the only registry that did not start >> > charging their legacy holders shortly after coming into existence. >> > >> > APNIC, RIPE, AfriNIC, and LACNIC all charge their legacy holders >> > annual fees to the best of my knowledge. >> > >> > I do not know whether a contract was required in any or all cases, >> > but, the fee portion of the equation is unique to ARIN to the best >> > of my knowledge. >> >> Hi Owen, >> >> I will suggest that an attempt by ARIN to charge $100/year under a >> contract simplified to, "We agree to keep your whois data and RDNS >> delegations intact as is for one year increments until either of us >> choose to cancel this contract" would meet with at most mild >> resistance from the legacy registrants. It would also, IMHO, provide >> an excellent way to weed out the abandoned registrations. >> >> This hasn't been done in part because we, in this forum, have insisted >> that legacy registrants should not be invited into the fold under such >> terms. >> >> Regards, >> Bill Herrin >> >> >> -- >> William D. Herrin ................ herrin at dirtside.com? bill at herrin.us >> 3005 Crane Dr. ...................... Web: >> Falls Church, VA 22042-3004 >> >> >> ------------------------------ >> >> Message: 4 >> Date: Sat, 30 Apr 2011 20:43:29 -0400 >> From: "Mike Burns" >> To: "Stephen Sprunk" , "Owen DeLong" >> >> Cc: arin-ppml at arin.net >> Subject: Re: [arin-ppml] ARIN / Microsoft press release regarding IP >> addressTransfers >> Message-ID: <7B6110E30D2E40CDA7E10BCB85E290B7 at video> >> Content-Type: text/plain; charset="utf-8" >> >> >If you can provide examples of transfers you both do and don't wish to >> allow, I'll be happy to come up with wording to express your intent. As it >> stands, though, I >don't understand your (or anyone else's) intent well >> enough to try. >> >> >S >> >> Steve, >> >> Here is why I call BS on the claim that these transfers comply with >> policy: >> >> "Such transferred number resources may only be received under RSA by >> organizations that are within the ARIN region and can demonstrate the need >> for such resources, as a single aggregate, in the exact amount which they >> can justify under current ARIN policies." >> >> That is the text. The comma between resources and "as a single aggregate" >> can be read to cause the "as a single aggregate" clause to apply to either >> the verb phrase "be received" or the verb phrase "can demonstrate." >> >> But how would anybody demonstrate a need for multiple netblocks anyway? >> Isn't the need ALWAYS determined as a single aggregate? >> >> Regards, >> >> Mike >> >> >> >> ----- Original Message ----- >> From: Stephen Sprunk >> To: Owen DeLong >> Cc: arin-ppml at arin.net >> Sent: Saturday, April 30, 2011 8:27 PM >> Subject: Re: [arin-ppml] ARIN / Microsoft press release regarding IP >> addressTransfers >> >> >> On 16-Apr-11 02:19, Owen DeLong wrote: >> >> On Apr 15, 2011, at 9:53 PM, Stephen Sprunk wrote: >> >> On 15-Apr-11 19:00, Matthew Kaufman wrote: >> >> The adopted policies (if they are using the "relatively new policy" >> as alluded to in the release) require the transfer of *a single aggregate*. >> >> >> Not quite. NRPM 8.3 only requires the receiver "demonstrate the need >> for such resources, as a single aggregate", not that a single aggregate be >> transferred. >> >> ... I do not believe that Stephen's interpretation below matches the >> meaning or the intent of the policy as I understand it. ... >> >> I don't think it does either, for the record. However, this points out >> how bad wording has left us in a situation where we're not sure what the >> policy text means--much less whether we agree with it. >> >> >> I do agree that your interpretation would be a syntactically and >> grammatically valid construction, but, I believe it is contextually >> nonsensical and not the intended meaning of the words. >> >> >> If anyone has a suggestion for making the actual intent more clear, I >> am open to suggestions and would support making an editorial correction for >> clarity. >> >> If you can provide examples of transfers you both do and don't wish to >> allow, I'll be happy to come up with wording to express your intent. As it >> stands, though, I don't understand your (or anyone else's) intent well >> enough to try. >> >> S >> >> >> -- >> Stephen Sprunk "God does not play dice." --Albert Einstein >> CCIE #3723 "God is an inveterate gambler, and He throws the >> K5SSS dice at every possible opportunity." --Stephen Hawking >> >> >> >> ------------------------------------------------------------------------------ >> >> >> _______________________________________________ >> PPML >> You are receiving this message because you are subscribed to >> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/arin-ppml >> Please contact info at arin.net if you experience any issues. >> -------------- next part -------------- >> An HTML attachment was scrubbed... >> URL: < >> http://lists.arin.net/pipermail/arin-ppml/attachments/20110430/2d387170/attachment.html >> > >> >> ------------------------------ >> >> _______________________________________________ >> ARIN-PPML mailing list >> ARIN-PPML at arin.net >> http://lists.arin.net/mailman/listinfo/arin-ppml >> >> End of ARIN-PPML Digest, Vol 70, Issue 176 >> ****************************************** >> > > > > -- > > Rudi Daniel > *danielcharles consulting > **1-784 498 8277 > * > * > * > > > _______________________________________________ > 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. > Owen, Would you be in support of an open exchange if there were basic controls in place to lockout speculators? -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications - AS32421 First and Leading in DDoS Protection Solutions -------------- next part -------------- An HTML attachment was scrubbed... URL: From owen at delong.com Mon May 2 19:33:45 2011 From: owen at delong.com (Owen DeLong) Date: Mon, 2 May 2011 16:33:45 -0700 Subject: [arin-ppml] Statistics regarding NRPM 8.3 Transfers to date In-Reply-To: <4DBF2724.6090300@sprunk.org> References: <75E9BD24-F12F-42BF-A989-CF6CC282B28E@arin.net> <7406316661701612155@unknownmsgid> <3F57F52B-F1F1-4450-B493-AA4D544D8D15@arin.net> <8740380157159276993@unknownmsgid> <49E26DCB-DAF7-4A0A-912E-F981494979F5@delong.com> <4DBC2AEB.9040307@matthew.at> <4DBCA58D.4060704@sprunk.org> <2344ADD7-616E-4FA7-9552-19735926A952@delong.com> <4DBD9BF5.7050002@sprunk.org> <4DBF2724.6090300@sprunk.org> Message-ID: On May 2, 2011, at 2:50 PM, Stephen Sprunk wrote: > On 02-May-11 15:41, Owen DeLong wrote: >> On May 1, 2011, at 10:44 AM, Stephen Sprunk wrote: >>> On 01-May-11 11:05, Owen DeLong wrote: >>>> While I would be fine with ARIN fulfilling your request with 2 /24s that were already disjoint, however, I don't want to see someone with, say, 44/8 find a buyer that needs a /20 and sell them 44.0.5/24, 44.0.8/24, 44.15.23/24, 44.28.6/24, etc. >>> >>> How about this: >>> >>> "The transferor's resources may be recursively bisected the minimum number of times necessary to create one CIDR block equal to the transferee's justified need." >>> >>> So, if someone with a /8 wants to sell you a /20, their /8 would be divided into one /9, one /10, one /11, one /12, one /13, one /14, one /15, one /16, one /17, one /18, one /19 and two /20s, and then you would get one of those /20s. >> >> I believe that would be acceptable, but I would need to know how staff would interpret the language and some assurance that said statement of interpretation would be binding. (Would staff interpretation of the former paragraph match the example in the latter?) > > That, of course, would fall to Mr. Curran to answer, but I can't see any valid alternate interpretation. > Until it came up, I couldn't see valid alternative interpretations to 8.3 as written. Staff has proven to be rather creative in this regard. >> How would it perform against the examples I posted a few moments ago? > > 1. Not allowed, because bisecting past /19 would exceed what was necessary to meet Org B's justified need. > > 2. Not allowed, because bisecting past /19 would exceed what was necessary to meet Org B's justified need. > > 3. Allowed. Since no division is required, the above text does not activate. > > 4. Allowed. The /20 would be divided into one /21, one /22, one /23, and two /24s. The two /24s would be transferred to Orgs B and C. The /23 would be divided into two /24s. Those two /24s would be transferred to Orgs D and E. > >> (Since we thought we understood how staff would interpret 8.3 at the time and it turned out not to work as we thought). > > You might have; I knew I didn't understand it, but I also knew that getting a possibly-broken policy passed ASAP was necessary to avoid establishing that going around ARIN was the only way to get things done. > I was not so convinced of the latter. >>> If you agree with that, I'll figure out how to shoehorn it into the existing text of NRPM 8.3, though I'd prefer a complete restructuring. >> >> This intrigues me. Please elaborate on your desired restructuring? > > My main priority would be changing it from one long, complicated block of text into something more structured (subsections, lists, etc.) with shorter, simpler sentences. The result would almost certainly be longer, but that's the only way to get clarity. > I'd be interested in working with you on doing so if you would like. >>> I also see several ugly possibilities when the transferor has multiple blocks of different sizes available to sell, but I'd need to see examples of how you'd want those handled before I could address them (no pun intended). However, assuming that aggregation has inherent value to buyers, sellers will avoid them out of self-interest, so we may not need to put anything into policy. Is anyone seriously concerned that assumption is wrong? >> >> ... >> I am very concerned that your assumption about the value of aggregation to buyers is wrong. > > The main value, in my view, comes from the greater likelihood of one's prefix being accepted in the DFZ both today and in the future. One /20 is obviously more valuable than sixteen /24s. However, how high could ISPs really raise the bar before their customers screamed about not being able to reach the "entire Internet"? Is one /19 really more valuable than two /20s? > My concern is that most will perceive that /24s are allowed and there is no benefit to looking for something shorter than a /24 if they can get /24s for cheap or easily. Heaven help the internet if we ever get to a point where /24s are no longer accepted. The number of organizations that would be immediately disenfranchised by such a move would be devastating. Owen -------------- next part -------------- An HTML attachment was scrubbed... URL: From mysidia at gmail.com Mon May 2 19:38:38 2011 From: mysidia at gmail.com (Jimmy Hess) Date: Mon, 2 May 2011 18:38:38 -0500 Subject: [arin-ppml] Accusation of fundamental conflict of interest/IPaddress policy pitched directly to ICANN In-Reply-To: <96228BA36D5948208E79184A5D1C0D6A@mike> References: <4DBB208B.4060808@ipinc.net> <112FF1070FFF4B7E957E13C757CCB513@video> <23B533DB44354E3EA201D0941C47C46C@video> <861B310C-7502-49FE-BD13-3D1B123A57EB@delong.com> <274D7568A828485B91D64F9308B3A24E@video> <1EA5AF3B-EE53-4D0B-8F2E-E011A4397497@delong.com> <96228BA36D5948208E79184A5D1C0D6A@mike> Message-ID: On Mon, May 2, 2011 at 2:30 PM, Mike Burns wrote: > Owen, > The salient point was that the document was accepted by the ICANN Board of > Directors. > My reading of this is that while the ASO recommended a policy, it was > decided by ICANN. The mere acceptance of a memo does not itself provide an authority not specified in the memo. cf. The US senate's approval is required for the US to enter treaties with other states. If the Senate ratifies a treaty with the Canadian government to recognize the "Canadian Government" as a body managing a certain piece of land (Canada); Would you then say that this is proof US Government >> Canada Govt' ? E.g. Taking the official action of recognizing another organization as responsible for something, automatically makes the recognizer superior? I would say no... If the senate don't ratify the treaty, or they later decide to unilaterally repeal or "alter" a treaty, that doesn't mean the Canadian gov'ts right to exist has been removed, or they must abide by whatever new terms may be dictated at US direction. Recognizing the existence of RIRs alone, as responsible for setting addressing policy, doesn't automatically give an organization control over those RIRs, or any right to interfere with their cooperation or mandate policies not agreed upon. Ditto. If the US gov't decides to make a treaty to recognize a rogue "alternative government" in Canada. That act alone does not make the existing administration illegitimate, and the alternative government legitimate. The people, the population, the community responsible for those structures, actually has to accept the change, and cooperate. ICANN chooses to recognize and coordinate with the RIRs. And mutual cooperation is essential, for the entire system to work effectively. That is different from having any authority over RIRs or what policies they may implement; ICANN already provided that it doesn't have authority over RIRs. Yes, the ICANN board could declare war against RIRs, and futz up the IANA function, or otherwise dishonor their agreements, but it would not be the least bit conducive to maintaining a stable internet. > You may call that a formality, but to me the relevant positions of authority > are clear. > I grant that it would appear better to the world community if the decision > were made with expressed community support. > Perhaps, as I suggested earlier, both IETF and DoC should be involved in the > decision. Regards, -- -JH From owen at delong.com Mon May 2 19:39:30 2011 From: owen at delong.com (Owen DeLong) Date: Mon, 2 May 2011 16:39:30 -0700 Subject: [arin-ppml] ARIN-prop-147 Set Transfer Need to 24 months and Clarify Exception In-Reply-To: <69160560-5FF3-4CEE-B688-84CCB6AD2426@matthew.at> References: <4DBEF12A.2020002@arin.net> <03F0539F-6F62-49CD-84F8-9ABC62095596@delong.com> <69160560-5FF3-4CEE-B688-84CCB6AD2426@matthew.at> Message-ID: On May 2, 2011, at 3:04 PM, Matthew Kaufman wrote: > > On May 2, 2011, at 2:48 PM, Owen DeLong wrote: > >> I do not support the proposal as written. >> >> First, I don't see a benefit to the community from adding 8.2 to the >> exemption. 8.2 is for transferring resources already in use as a >> result of M&A and as such should not require any sort of exemption >> or time period specification of any type. > >> The resources should already >> have justified need and be in use at the time of transfer. > > Addresses involved in an 8.2 transfer are not necessarily "already in use". The source organization may have a considerable number of legacy addresses and/or have recently qualified for addresses based on a needs justification that is no longer applicable... therefore the new organization must re-qualify. > In the legacy case, I support ARIN making reclamation of the addresses to bring the recipient into compliance with existing policy. The legacy status of resources should be non-transferrable. In the case of having recently qualified based on a justification that is no longer acceptable, yes, they should have to requalify. > If they are to re-qualify, it doesn't make sense that they be forced to justify only a 3-month supply simply because the free pool is low or empty. > I disagree. >> Adding >> a 24 month time frame for speculative need only enhances the >> opportunities for fraudulent transfers and abuse. > > It also has other benefits, but perhaps these proposals should be split so we can debate them separately. > You view enhancing opportunities fro fraudulent transfers and abuse as a benefit to which you would like to add other benefits? This, perhaps explains a lot of our difference in perspective. I regard fraudulent transfers and abuse of policy as things we should be trying to eliminate, not as benefits to be encouraged. Perhaps I misunderstand what you said in that last sentence. >> >> Second, I think there was value in preserving the 12 month horizon >> for transfers in that the shortening of the horizon to three months >> was for the purpose of limiting the extent to which a single organization >> could "shut out" their competitors by collecting a twelve month supply >> of addresses right as several of them ran out. No such protection makes >> sense in the transfer market. > > Nor does it make sense in the M&A transfer context, but you just argued the other way above. > I think it makes complete sense in the M&A transfer context. > >> However, expanding policy to a 24 >> month horizon makes no more sense for transfers than it would have >> for allocations. > > Transfers require considerably more work on the part of two non-ARIN parties. > So? > Furthermore, the uncertainty of the IPv4 market makes the inability to acquire additional space that is justified, albeit over a longer interval, a serious problem... how can you get investment for something that you intend to build over the next 2 years if you can only get the first year of space now via transfer and the second one is totally dependent on whether or not there even IS a seller down the road... as opposed to just ponying up the cash now and getting enough space that you can make it all the way to when IPv6 really works for your application. > Again, I don't think that we need to support that through policy. IPv4 is reaching its end of life. There is a need to help some organizations limp along with it through transfers while it is deprecated, but, seeking to create new businesses based on IPv4 construction over the next 2 years is not something I favor encouraging or facilitating through policy. > There are also potential benefits to aggregation. See my justification statements. > Yeah, I think those are pretty specious. Owen > Matthew Kaufman > >> >> Owen >> >> On May 2, 2011, at 11:00 AM, ARIN wrote: >> >>> ARIN-prop-147 Set Transfer Need to 24 months and Clarify Exception >>> >>> 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-147 Set Transfer Need to 24 months and Clarify Exception >>> >>> Proposal Originator: Matthew Kaufman >>> >>> Proposal Version: 1 >>> >>> Date: 2 May 2011 >>> >>> Proposal type: new >>> >>> Policy term: permanent >>> >>> Policy statement: >>> >>> Change section 4.2.4.4 content as follows: >>> >>> Replace: >>> "This reduction does not apply to resources received via section 8.3. An >>> organization receiving a transfer under section 8.3 may continue to >>> request up to a 12-month supply of IP addresses." >>> >>> With: >>> "This reduction does not apply to resources received via transfer. An >>> organization receiving a transfer under section 8 may request up to a >>> 24-month supply of IP addresses." >>> >>> Rationale: >>> >>> The exception should apply to transfers under 8.2 as well as 8.3 (and >>> any future transfer policies). >>> >>> Due to the complexity of the financial transaction that may be >>> involved and the associated budgeting on the part of the receiving >>> organization, 24 months is a more reasonable amount of forecast need to >>> allow to be fulfilled via the transfer process. >>> >>> Potential benefit to address aggregation by allowing fewer larger >>> transfers sooner. >>> >>> 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 farmer at umn.edu Mon May 2 19:42:23 2011 From: farmer at umn.edu (David Farmer) Date: Mon, 02 May 2011 18:42:23 -0500 Subject: [arin-ppml] ARIN-prop-140 Business Failure Clarification In-Reply-To: <40781567-AD5F-415E-9C52-323D9697C597@arin.net> References: <4DBEF0DF.8060800@arin.net> <949B31E1-F496-41B7-B00D-9E7160F3CF8D@matthew.at> <4DBF39CC.9080502@umn.edu> <40781567-AD5F-415E-9C52-323D9697C597@arin.net> Message-ID: <4DBF415F.2010403@umn.edu> On 5/2/11 18:23 CDT, John Curran wrote: > On May 3, 2011, at 1:10 AM, David Farmer wrote: > >> Actually, if all resources were under RSA or LRSA we really >> wouldn't need this at all, ARIN could reclaim resources for >> non-payment, following that process defined in the contracts. This >> works under the theory that if someone isn't paying the bills the >> organization is no longer functioning, which is more or less >> usually true. In the case a bankruptcy, the bankruptcy trustee >> would either need to pay ARIN or seek relief for the terms of the >> contract, both of which are valid and would be under to supervision >> of the bankruptcy judge, and in the realm of the lawyers and not >> really a policy problem. >> >> The problem is that most Legacy resources are not under an LRSA or >> RSA at this time. Therefore we need some kind of mechanism to know >> when ARIN should look to reclaim Legacy Resource from defunct >> organizations that do not have an LRSA or RSA to define a process >> to recover said resources. This is the crux of the issue for the >> hijacking and several other threads on PPML. > > David - > > This is not correct, even with resources under RSA. > > A policy which states "ARIN should reclaim resources in bankruptcies" > would be *contrary to law* in some cases. > > Policy which directs ARIN staff contrary to law is unlikely to > adopted by the ARIN Board of Trustees. Yes, I thought I said if everything was under RSA or LRSA we wouldn't need this, that is a policy talking about when ARIN recovers addresses, the contracts deal with it, including when bankruptcy is involved. But, since we don't have all resources under RSA or LRSA we probably need something, and yes it can't be contrary to law. My intent was to point out that the lack of a valid RSA or LRSA with all resource holders is the reason the we need something. What I should have more clearly pointed out, was that we can rely on the RSA or LRSA for all resources under such a contract. and only create a policy for any resources that are not covered by a contract that already defines when resource should be recovered. > FYI, /John > > John Curran President and CEO ARIN > -- =============================================== 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 Mon May 2 19:43:28 2011 From: bill at herrin.us (William Herrin) Date: Mon, 2 May 2011 19:43:28 -0400 Subject: [arin-ppml] Analogies In-Reply-To: <8D07F7F5-7E60-4176-A5D3-929F160AC608@arin.net> References: <39209.1303885464@tristatelogic.com> <75822E125BCB994F8446858C4B19F0D7173057C827@SUEX07-MBX-04.ad.syr.edu> <471D76419F9EF642962323D13DF1DF69011E5C@newserver.arneill-py.local> <7348D3C8-4EB7-4440-A152-210CC8B0DA3C@arin.net> <471D76419F9EF642962323D13DF1DF69011E60@newserver.arneill-py.local> <583A067A-B8AE-4026-844E-6769D1D7CF88@arin.net> <471D76419F9EF642962323D13DF1DF69011E61@newserver.arneill-py.local> <7DF2A1C4-1799-486B-A631-2E1119C22A7C@arin.net> <3CCC6D1F-11F4-40BC-B102-CC6744A5E709@virtualized.org> <4DB9BACE.6000307@ipinc.net> <0E134D8B-0A4B-466E-B261-9C7D0ED11867@virtualized.org> <388190E3-08F2-4AC7-870A-621A2FD6EEFE@virtualized.org> <2ABCF380-7866-4ED8-BE43-C789CBEBFE27@delong.com> <8D07F7F5-7E60-4176-A5D3-929F160AC608@arin.net> Message-ID: On Mon, May 2, 2011 at 7:13 PM, John Curran wrote: > On May 3, 2011, at 12:47 AM, William Herrin wrote: >> Section 7. Current and future policies. Compliance with tomorrow's >> NRPM is immaterial to the provision of whois and dns services. > > Incorrect. ?You may be the registrant and have the use of the > resource in accordance with policies, but other parties have > some rights with respect the same registration records. ?For > example, if the community adopts a policy which adds a new type > of contact for resource records, then you are going to get one. > Similarly if the community changes the policies regarding the > visibility of various fields contained within the registry. > While there is contractual protection against policy changes > which inhibit your use of the resource, the general case is > policy changes to the registry apply, and the registry services > are DNS and Whois. Hypothetical future community-adopted policy: "Any network found to host photoshopped pornography of Republican political candidates is subject to having its number resources revoked." Which part of the LRSA prevents this hypothetical policy from applying to its registrant? Which part shields him from involuntary reclamation of their addresses under LRSA 7 and 14b2? Don't like that one? Let's try another: "Recognizing the IPv4 address shortage, all registrants shall renumber out of and return IP addresses used for all non-public networks such as corporate lans, replacing those networks with RFC1918 space and NATs instead." LRSA 10b doesn't apply -- the addresses for which return is compelled are actually in use. Section 7's scope vastly exceeds any reasonable application to the provision of whois and rdns services. 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 Mon May 2 19:45:48 2011 From: mike at nationwideinc.com (Mike Burns) Date: Mon, 2 May 2011 19:45:48 -0400 Subject: [arin-ppml] Accusation of fundamental conflictofinterest/IPaddress policy pitched directly to ICANN References: <7646B57F7F154B028E6722D103BB57C2@mike> Message-ID: <60F3C7B6BAA34A28B96EC6371A68D723@video> >Not true. The chaos and disruption posed by unregulated registries will >increase the costs to ARIN, ARIN members, and other participants in the >industry regardless of whether they change registries or not. >Owen This is an assertion unsupported by facts. What additional costs will be imposed on ARIN? True they would have to update a field in the whois database to point to the authoritative registry, sort of like the pointers to other RIRs in there now. The letter to ICANN that began this thread included a set of regulations adopted from those used in the creation of private DNS registries. Why do you keep insisting they would be unregulated? Like the RIR's, like DNS Registries, all approved registries do answer to the community through adherence to those community-defined regulations. If you are concerned about groundup or community development, may I suggest revisiting Benson's proposals, which were an attempt to create the policy which would allow for the creation of alternate registries under ARIN policy, but which met with an untimely end based on John Curran's feelings that the decisions had to be made at a global level. Now the argument holds that at that global level decisions should be made by the same small group of individuals running the RIRs, basically. You are right in saying there are no policies about how domain names are justified or acquired in the rules which apply to DNS registries. That's as it should be, and there is a burgeoning set of case law and trademark law that serves to answer those questions. I put more trust in the collective brainpower of worldwide jurisprudence and centuries of commonlaw experience to decide these issues than a tiny cabal of individuals with a vested interest in maintaining their positions in the status quo. Let the DNS registries concentrate on uniqueness and adherence to law as it develops, let number registries concentrate on uniqueness and title. I think we understand your position on free markets, I am trying to avoid discussions of analogies far afield from current topics, so suffice it to say I disagree that the instances you reference resulted from activities in free markets. Regards, Mike ----- Original Message ----- From: Owen DeLong To: Mike Burns Cc: Alexander, Daniel ; arin-ppml at arin.net Sent: Monday, May 02, 2011 6:48 PM Subject: Re: [arin-ppml] Accusation of fundamental conflictofinterest/IPaddress policy pitched directly to ICANN On May 2, 2011, at 1:41 PM, Mike Burns wrote: Hi Dan, The existence of competing registries does not imply a requirement on anybody to change, so your argument about expense to existing participants is invalid. Not true. The chaos and disruption posed by unregulated registries will increase the costs to ARIN, ARIN members, and other participants in the industry regardless of whether they change registries or not. And yes, the market will sort out bad actors. That's one thing free markets do. Right... The market sorted out Enron... Eventually. However, non of us in California got our money back and we're all still paying higher electric bills as a result. The market sorted out the CMOs... Eventually. However, my house is now worth 1/3rd of what it was worth and the new restrictive regulations on refinancing prevent me from taking advantage of the new lower interest rates due to my home being devalued too close to the amount I still owe on it. Unfortunately, I wasn't irresponsible enough to be part of the cause of this problem, so, as a good actor, I am not entitled to any of the relief available from the government for the bad actors. I think I've had enough of the way markets sort out bad actors for a while. Nobody said anything about no oversight, to the contrary I have said the registries should work under the same framework as RIRs. The only oversight of the RIRs is their community processes and their membership-elected boards. If you are OK with the other registries being overseen by these same bodies, then, I'm not sure why you think they would somehow be run differently from the existing RIRs. Just like all DNS registrars have to comply with rules setup to govern their behavior. Before you can be a DNS registrar you have to comply with the rules, and maintain compliance. There are virtually no policies about how domain names are justified or acquired in those rules. There are provisions for trademark disputes, but, those are not applicable to IP addresses (unless you think that a particular soft drink vendor should be automatically entitled to the address 67.79.75.69). Owen It's true that I was being forward thinking about the additional services competing registries might offer, but my point is that those services would only be offered if there was a demand for them, if the private registries are to endure. Regards, Mike ----- Original Message ----- From: "Alexander, Daniel" To: "Mike Burns" ; Sent: Monday, May 02, 2011 4:30 PM Subject: Re: [arin-ppml] Accusation of fundamental conflictofinterest/IPaddress policy pitched directly to ICANN Mike, While I can only speak for myself, I can attempt to answer your question of what may perturb some people. You make several very large assumptions in your claims, none of which were captured in the opt-in, opt-out, or any other proposals. You speak of title insurance, legal teams, and other items, ensuring that a competitive registry will provide better services than a community defined RIR. The problem is none of this is defined or required in any suggested framework. While some may provide these services, many may not, and there are no mechanisms to protect the ISP's or end users who rely on these services. While many advocates will quickly reply that the market will sort these bad actors out, it will be done at the expense of the people who currently rely on these RIR provided services at a fraction of the cost. If competitive registries are created without oversight, the burden and expense of validating registration records will be shifted to the very people who are supposed to benefit from this new model. This begs the question from some as to what purpose a commercial registry would serve other than to make money. My opinion only. Dan Alexander On 5/2/11 3:33 PM, "Mike Burns" wrote: But what is it about ARIN that is broken? What exactly do you think needs to be fixed? The only thing I've gotten out of the discussions so far is that some people think there is money to be made by providing IPv4 addresses based on willingness and ability to pay rather than ARIN's current >demonstrated need policies. Why is it to my benefit if someone else makes money? Particularly if it perturbs the current mechanisms in a way that costs me money? Keith Hare Hi Keith, What is broken about ARIN is that scandalously large numbers of netblocks do not have valid POCs, for example. The stewardship of Whois leaves a lot to be desired. Competitive pressures would help to finally decide who controls these addresses and allow them to be transferred to those who would pay for them. Network operators don't really have much of a choice in accessing Whois information to determine the rights to advertise addresses, and competive registries. In my experience they rely on attestation and review of proferred chain-of-custody docs when determining who can advertise which addresses, when confronted with inconsistencies with whois. A competitive registry with a title insurance component will give network operators more security when deciding questionable cases. What is broken about ARIN is that their transfer policies are more restrictive than APNICs, and that will cause a flow of addresses out of ARIN and into APNIC. A competitive registry could presumably have a different transfer policy, as APNICs differs from ARINs. What is broken about ARIN is that ARIN has professed no statutory control over legacy addresses in the Plzak declaration in the Kremen case, and yet attempts to control the registration of legacy resources. With a private registry, the address rights holders can choose to opt-out of ARIN's dictats and choose their registry voluntarily. I don't see how the creation of a private registry will perturb the current mechanisms in a way that costs you money, could you share why you feel that way? Regards, Mike Burns _______________________________________________ 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 owen at delong.com Mon May 2 19:47:30 2011 From: owen at delong.com (Owen DeLong) Date: Mon, 2 May 2011 16:47:30 -0700 Subject: [arin-ppml] ARIN-prop-140 Business Failure Clarification In-Reply-To: References: <4DBEF0DF.8060800@arin.net> <9BC4E3EC-E693-44D9-A415-A9E0F97E1BAA@matthew.at> <00A60C73-0282-416A-BBF1-D491ADDD18EE@delong.com> Message-ID: <7B10B708-B9B5-4655-A467-4BE74E555EF2@delong.com> On May 2, 2011, at 3:40 PM, Matthew Kaufman wrote: > > On May 2, 2011, at 3:34 PM, Owen DeLong wrote: >> >> I was the POC for an organization which failed. When I was informed that >> my job was being terminated and the company liquidated, the network >> being shut down, etc. I notified ARIN and the addresses and AS Numbers >> were reclaimed. > > If you notified ARIN after your date/time of termination, you were probably acting outside of your authority. > I notified ARIN that the business was being liquidated and that the network had been shut down. I did not tell ARIN to reclaim the addresses (though I expressed a belief that policy might support reclamation). As such, I was not acting in or out of authority. I was conveying information. The information was a matter of public record and so not subject to NDA. > And these days, if you notified ARIN before talking to your management about the possibility of transferring the addresses in order to pay creditors during the liquidation you wouldn't be upholding your fiduciary responsibility to your employer. > If I did so while I had a fiduciary responsibility, perhaps. However, once terminated, I had no such fiduciary responsibility. Further, I do not believe that as an operations person, I have a fiduciary duty to instruct my employer on their opportunities for revenue through the transfer process unless they ask. I was an individual contributor responsible for network operations. I was not in sales, marketing, accounting, or collections and I was not a manager. >> >> This was all well and proper and correct. > > Perhaps at that time. > I would do exactly the same today if I found myself in the same circumstances. >> >> This was what should happen. > > Rarely, these days. we can agree to disagree. Owen -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcurran at arin.net Mon May 2 19:51:18 2011 From: jcurran at arin.net (John Curran) Date: Mon, 2 May 2011 23:51:18 +0000 Subject: [arin-ppml] ARIN-prop-140 Business Failure Clarification In-Reply-To: <4DBF415F.2010403@umn.edu> References: <4DBEF0DF.8060800@arin.net> <949B31E1-F496-41B7-B00D-9E7160F3CF8D@matthew.at> <4DBF39CC.9080502@umn.edu> <40781567-AD5F-415E-9C52-323D9697C597@arin.net> <4DBF415F.2010403@umn.edu> Message-ID: <22DA3BCC-6EF5-40F4-B0B1-15103FC1A022@arin.net> On May 3, 2011, at 1:42 AM, David Farmer wrote: > My intent was to point out that the lack of a valid RSA or LRSA with all resource holders is the reason the we need something. David - Your statement above is NOT correct. Even with all resources under an RSA or LRSA, a policy which states "ARIN should reclaim resources in bankruptcies"would be *contrary to law* in some cases. The fact that the RSA/LRSA covers it does not assure that it is actually applicable; it depends on the exact nature of the bankruptcy and applicable law. Attempting to make policy which purports to clarify the situation for the resource holder, or that directs ARIN staff to take specific actions runs a very real probability of being completely wrong in some circumstances. Thanks, /John John Curran President and CEO ARIN From matthew at matthew.at Mon May 2 19:51:43 2011 From: matthew at matthew.at (Matthew Kaufman) Date: Mon, 2 May 2011 16:51:43 -0700 Subject: [arin-ppml] ARIN-prop-140 Business Failure Clarification In-Reply-To: <4DBF39CC.9080502@umn.edu> References: <4DBEF0DF.8060800@arin.net> <949B31E1-F496-41B7-B00D-9E7160F3CF8D@matthew.at> <4DBF39CC.9080502@umn.edu> Message-ID: <5C870A6C-E149-413D-9661-9EB20ADF4E8E@matthew.at> On May 2, 2011, at 4:10 PM, David Farmer wrote: >> > > Actually, if all resources were under RSA or LRSA we really wouldn't need this at all, ARIN could reclaim resources for non-payment, following that process defined in the contracts. Good point. > This works under the theory that if someone isn't paying the bills the organization is no longer functioning, which is more or less usually true. In the case a bankruptcy, the bankruptcy trustee would either need to pay ARIN or seek relief for the terms of the contract, both of which are valid and would be under to supervision of the bankruptcy judge, and in the realm of the lawyers and not really a policy problem. > > The problem is that most Legacy resources are not under an LRSA or RSA at this time. Therefore we need some kind of mechanism to know when ARIN should look to reclaim Legacy Resource from defunct organizations that do not have an LRSA or RSA to define a process to recover said resources. This is the crux of the issue for the hijacking and several other threads on PPML. So maybe we *just* need a policy to cover reclaim of legacy resources that works for actually-defunct entities and doesn't put at risk anything less than that. Matthew Kaufman From bill at herrin.us Mon May 2 19:52:49 2011 From: bill at herrin.us (William Herrin) Date: Mon, 2 May 2011 19:52:49 -0400 Subject: [arin-ppml] Analogies In-Reply-To: <8D07F7F5-7E60-4176-A5D3-929F160AC608@arin.net> References: <39209.1303885464@tristatelogic.com> <75822E125BCB994F8446858C4B19F0D7173057C827@SUEX07-MBX-04.ad.syr.edu> <471D76419F9EF642962323D13DF1DF69011E5C@newserver.arneill-py.local> <7348D3C8-4EB7-4440-A152-210CC8B0DA3C@arin.net> <471D76419F9EF642962323D13DF1DF69011E60@newserver.arneill-py.local> <583A067A-B8AE-4026-844E-6769D1D7CF88@arin.net> <471D76419F9EF642962323D13DF1DF69011E61@newserver.arneill-py.local> <7DF2A1C4-1799-486B-A631-2E1119C22A7C@arin.net> <3CCC6D1F-11F4-40BC-B102-CC6744A5E709@virtualized.org> <4DB9BACE.6000307@ipinc.net> <0E134D8B-0A4B-466E-B261-9C7D0ED11867@virtualized.org> <388190E3-08F2-4AC7-870A-621A2FD6EEFE@virtualized.org> <2ABCF380-7866-4ED8-BE43-C789CBEBFE27@delong.com> <8D07F7F5-7E60-4176-A5D3-929F160AC608@arin.net> Message-ID: On Mon, May 2, 2011 at 7:13 PM, John Curran wrote: > On May 3, 2011, at 12:47 AM, William Herrin wrote: >> Section 9. Property rights are immaterial to the provision of whois >> and dns services yet the registrant is asked to quit any such claims >> as a condition of the LRSA. > > That is correct, and unlikely to change. It may be possible to adjust > slightly to better specify retention of the right of exclusive use in > accordance with policy and I shall look into this presently. John, If you can't live with "ARIN does not consider number resources to be property; nothing in this Agreement shall be construed to convey property rights in the included number resources to the registrant," then there's a hard upper bound to the number of legacy registrants you're going to attract. 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 2 19:53:57 2011 From: owen at delong.com (Owen DeLong) Date: Mon, 2 May 2011 16:53:57 -0700 Subject: [arin-ppml] Analogies In-Reply-To: References: <39209.1303885464@tristatelogic.com> <75822E125BCB994F8446858C4B19F0D7173057C827@SUEX07-MBX-04.ad.syr.edu> <471D76419F9EF642962323D13DF1DF69011E5C@newserver.arneill-py.local> <7348D3C8-4EB7-4440-A152-210CC8B0DA3C@arin.net> <471D76419F9EF642962323D13DF1DF69011E60@newserver.arneill-py.local> <583A067A-B8AE-4026-844E-6769D1D7CF88@arin.net> <471D76419F9EF642962323D13DF1DF69011E61@newserver.arneill-py.local> <7DF2A1C4-1799-486B-A631-2E1119C22A7C@arin.net> <3CCC6D1F-11F4-40BC-B102-CC6744A5E709@virtualized.org> <4DB9BACE.6000307@ipinc.net> <0E134D8B-0A4B-466E-B261-9C7D0ED11867@virtualized.org> <388190E3-08F2-4AC7-870A-621A2FD6EEFE@virtualized.org> <2ABCF380-7866-4ED8-BE43-C789CBEBFE27@delong.com> Message-ID: <53B633A2-A7F6-4BF3-A11B-4981C9A41130@delong.com> On May 2, 2011, at 3:47 PM, William Herrin wrote: > On Mon, May 2, 2011 at 6:18 PM, Owen DeLong wrote: >> On May 2, 2011, at 12:33 PM, William Herrin wrote: >>> On Mon, May 2, 2011 at 3:24 PM, Owen DeLong wrote: >>>> On Apr 30, 2011, at 5:39 PM, William Herrin wrote: >>>>> I will suggest that an attempt by ARIN to charge $100/year under a >>>>> contract simplified to, "We agree to keep your whois data and RDNS >>>>> delegations intact as is for one year increments until either of us >>>>> choose to cancel this contract" would meet with at most mild >>>>> resistance from the legacy registrants. It would also, IMHO, provide >>>>> an excellent way to weed out the abandoned registrations. >>>> >>>> That seems like a reasonable summary of the current LRSA. >>> >>> If counsel agrees with that assessment (he doesn't and you didn't >>> check) then start summarizing and put the result in front of me, >>> without all the excess baggage in the current LRSA. >> >> Please specifically define the term excess baggage and show >> me in what ways it conflicts with the above summary. > > Excess baggage: > > Section 9. Property rights are immaterial to the provision of whois > and dns services yet the registrant is asked to quit any such claims > as a condition of the LRSA. > They are fundamental to the basis on which ARIN provides the services and are a necessary part of ARIN entering into such an agreement. The are also immaterial to the ability of anyone to exercise any of their rights under ARIN policy. Basically they are altogether immaterial unless you are seeking to destroy the existing system. As such, I think this falls within the summary above and is neither unnecessary, nor baggage. > Section 8. Annual audit. Routine auditing of the registrant's use of > IP addresses is immaterial to the provision of whois and dns services. > I'll review this in greater detail. I don't have the LRSA handy at the moment. > Section 7. Current and future policies. Compliance with tomorrow's > NRPM is immaterial to the provision of whois and dns services. > Given the rather blanket exemption to future NRPM policies contained elsewhere in the agreement which overrides the part of this that you are objecting to, I'm not sure I see your point here. > Section 14e. Nothing in my "summary" requires ARIN to discontinue > whois and rdns services should the registrant decide to stop paying. > 14e not only requires ARIN to discontinue services, it requires ARIN > to revoke the resources, putting them into a process resulting in > reallocation to someone else. > I disagree. Your summary says "we agree to keep your whois and RDNS delegations intact as is for one year increments until either of us choose to cancel this contract". If you cancel, then, you have stopped obliging ARIN to continue the services. Sure, nothing in your summary requires them to revoke them, where the LRSA does. However, your summary ALLOWS them to revoke them, so, I'm not sure I see a meaningful difference here. Owen From matthew at matthew.at Mon May 2 20:05:22 2011 From: matthew at matthew.at (Matthew Kaufman) Date: Mon, 2 May 2011 17:05:22 -0700 Subject: [arin-ppml] ARIN-prop-146 Clarify Justified Need for Transfers In-Reply-To: <5598DFC7-E320-42FA-AA0E-C91C076BD725@delong.com> References: <4DBEF120.4080901@arin.net> <88F39B20-5C20-45F0-AD61-5FA1E7F84CE3@delong.com> <3FCD1FDC-ECEE-4C9B-95C6-59E03D3C314E@matthew.at> <5598DFC7-E320-42FA-AA0E-C91C076BD725@delong.com> Message-ID: <6BA1EAA6-7D9C-44F9-BED7-884720F4B3BE@matthew.at> On May 2, 2011, at 4:29 PM, Owen DeLong wrote: > > On May 2, 2011, at 2:51 PM, Matthew Kaufman wrote: > >> >> On May 2, 2011, at 2:42 PM, Owen DeLong wrote: >>> there is no reason >>> to treat transfers differently from initial allocations and assignments. >> >> Fundamentally disagree. Policy for handing out the last of the free pool of IPv4 (which has already become much MORE restrictive, now that we are subject to the "last /8" policies) should be different than policy for approving transfer recipients. There is no reason to believe, for instance, that we are in the "last /8" of transfers. And no new entrant post-runout will spend the time and money attempting to acquire only what they can justify for a 3-month period. >> >> Matthew Kaufman > > The three month restriction is a temporary abomination in the IPv4 policies related to runout. > > The rest of the policy is not specially restrictive related to runout. > > That temporary abomination is specifically exempted in 8.3, so, you already have exactly what > you have stated is needed above. No it isn't. Section 8.3 has NO language exempting itself from the 3 month rule. That's what I hear on the list, but I looked it up, and it isn't there. That's how I ended up writing this proposal, after all. The only exemption is in 4.2.4.4. That exemption ONLY works if you are not getting an initial assignment through transfer (a likely scenario for new orgs post-runout) AND you are not a new member who only recently got their initial 3 month supply (where you'd be restricted to using transfer in 3-month increments for the first year in order to grow). AND there's other bugs in that 4.2.2.1.1 and 4.2.2.1.3 and 4.2.2.2 (at the very least) call out specific block sizes that might be *smaller* than the block you're trying to qualify under transfer. I hate to say it, but... did you actually *read* my policy proposal text? > > There is no need for a policy change. There clearly is, IF you run through each and every one of the paths in section 4 and see which ones 4.2.4.4 triggers for, and more important, which ones it *doesn't* trigger for. If you qualify for an 8.3 transfer there is NO reason that transfer should fall under the 3-month rules, which right now, in many cases, it does... without a change like the one I have proposed. Matthew Kaufman From bill at herrin.us Mon May 2 20:07:12 2011 From: bill at herrin.us (William Herrin) Date: Mon, 2 May 2011 20:07:12 -0400 Subject: [arin-ppml] Analogies In-Reply-To: <53B633A2-A7F6-4BF3-A11B-4981C9A41130@delong.com> References: <39209.1303885464@tristatelogic.com> <75822E125BCB994F8446858C4B19F0D7173057C827@SUEX07-MBX-04.ad.syr.edu> <471D76419F9EF642962323D13DF1DF69011E5C@newserver.arneill-py.local> <7348D3C8-4EB7-4440-A152-210CC8B0DA3C@arin.net> <471D76419F9EF642962323D13DF1DF69011E60@newserver.arneill-py.local> <583A067A-B8AE-4026-844E-6769D1D7CF88@arin.net> <471D76419F9EF642962323D13DF1DF69011E61@newserver.arneill-py.local> <7DF2A1C4-1799-486B-A631-2E1119C22A7C@arin.net> <3CCC6D1F-11F4-40BC-B102-CC6744A5E709@virtualized.org> <4DB9BACE.6000307@ipinc.net> <0E134D8B-0A4B-466E-B261-9C7D0ED11867@virtualized.org> <388190E3-08F2-4AC7-870A-621A2FD6EEFE@virtualized.org> <2ABCF380-7866-4ED8-BE43-C789CBEBFE27@delong.com> <53B633A2-A7F6-4BF3-A11B-4981C9A41130@delong.com> Message-ID: On Mon, May 2, 2011 at 7:53 PM, Owen DeLong wrote: > On May 2, 2011, at 3:47 PM, William Herrin wrote: >> Section 7. Current and future policies. Compliance with tomorrow's >> NRPM is immaterial to the provision of whois and dns services. >> > Given the rather blanket exemption to future NRPM policies contained > elsewhere in the agreement which overrides the part of this that you > are objecting to, I'm not sure I see your point here. Owen, Which blanket exemption would that be?' Can you find it? Section 2 which says, "must comply with ARIN?s Number Resource Policy Manual [...] as long as the terms of the Policies are not inconsistent with this Legacy Agreement?" Section 7 which says, "Policies shall be binding upon Legacy Applicant immediately after they are posted on the Website," except if they're inconsistent with a specific term in the LRSA? Maybe you mean 10b which is the only obvious thing that sets out a condition that could be inconsistent with the NRPM. It says, "ARIN will take no action to reduce the services provided for Included Number Resources that are not currently being utilized by the Legacy Applicant." And it doesn't even promise to leave all the registrant's addresses intact... just the ones that "are not currently being utilized." Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From matthew at matthew.at Mon May 2 20:07:41 2011 From: matthew at matthew.at (Matthew Kaufman) Date: Mon, 2 May 2011 17:07:41 -0700 Subject: [arin-ppml] Statistics regarding NRPM 8.3 Transfers to date In-Reply-To: References: <75E9BD24-F12F-42BF-A989-CF6CC282B28E@arin.net> <7406316661701612155@unknownmsgid> <3F57F52B-F1F1-4450-B493-AA4D544D8D15@arin.net> <8740380157159276993@unknownmsgid> <49E26DCB-DAF7-4A0A-912E-F981494979F5@delong.com> <4DBC2AEB.9040307@matthew.at> <4DBCA58D.4060704@sprunk.org> <2344ADD7-616E-4FA7-9552-19735926A952@delong.com> <4DBD9BF5.7050002@sprunk.org> <4DBF2724.6090300@sprunk.org> Message-ID: <79A82F38-A2BE-4F9E-851D-4286E0C7CD57@matthew.at> On May 2, 2011, at 4:33 PM, Owen DeLong wrote: > > Heaven help the internet if we ever get to a point where /24s are no longer accepted. The number > of organizations that would be immediately disenfranchised by such a move would be > devastating. Unless of course the people running ISPs were smart enough to figure out how to allow old /24s and not allow new /24s using some sort of well-maintained database... or otherwise apply market pressure against people trying to break up large blocks into many small blocks. Matthew Kaufman From scottleibrand at gmail.com Mon May 2 20:09:39 2011 From: scottleibrand at gmail.com (Scott Leibrand) Date: Mon, 2 May 2011 17:09:39 -0700 Subject: [arin-ppml] ARIN-2011-5: Shared Transition Space for IPv4 Address Extension - Last Call In-Reply-To: <0254BEBE-A3D4-45C3-8D8E-09900A11FD57@delong.com> References: <4DAC8BCB.2000300@arin.net> <54E900DC635DAB4DB7A6D799B3C4CD8E10C7EF5E@PLSWM12A.ad.sprint.com> <3128593549961341875@unknownmsgid> <54E900DC635DAB4DB7A6D799B3C4CD8E10C899B7@PDAWM12B.ad.sprint.com> <1489147144792938659@unknownmsgid> <54E900DC635DAB4DB7A6D799B3C4CD8E10C89AC7@PDAWM12B.ad.sprint.com> <0816C508-43EE-46BD-8BC2-D5F1222848FE@matthew.at> <0254BEBE-A3D4-45C3-8D8E-09900A11FD57@delong.com> Message-ID: <1637669134889946921@unknownmsgid> Well, another approach would be to reconsider all of section 4 in light of the fact that very shortly the only way it will be applied is to transfers, or to a trickle of returned space going against the waiting list. When looked at from that point of view, I think most of section 4 starts to look somewhat dated. For example, in a post-depletion world, does it make sense to require that an ISP use a /20 or /22 of PA space before getting their own space via transfer? What about when most ISPs are doing something like NAT64 or DS-Lite and only need a /23 to serve their entire customer base? Should they be blocked from transferring such a block because it's not big enough? Again, I'm not arguing that we need to change (or "throw out") all of NRPM section 4 at this point. I'm just pointing out that a lot of our restrictions start making a lot less sense in a world of address scarcity that they did when they were first passed, so we need to start thinking about how to keep up with the necessary changes and avoid applying anachronistic rules if they're no longer needed. I think we're doing a good job of rewriting and simplifying IPv6 policy to reflect such realities, and anticipate that we'll need to start simplifying IPv4 policy for a post-depletion world as well. Scott On May 2, 2011, at 4:26 PM, Owen DeLong wrote: I disagree entirely. Transfers, if they are to be permitted, should be done with the recipient required to meet exactly the same justifications as those under section 4. I see the 3-month timeframe as a temporary abomination to section 4, necessary because of special circumstances of runout. Throwing out the rest of section 4 because of it is absurd. Owen On May 2, 2011, at 2:23 PM, Scott Leibrand wrote: On Mon, May 2, 2011 at 2:04 PM, Matthew Kaufman wrote: > > Agree. Yet again we have a problem where the needs justification for using > the very last of ARIN's free pool should be totally different than the needs > justification for being the recipient of an expensive resource transfer via > specified transfer, and yet it isn't. > > Can't fix the one without breaking the other in this case... or agreeing > that needs justification for transfers needs fixing. (One of my proposals > today that hasn't received comment yet covers the issue that new recipients > can only get 3 months via specified transfer, given the current text, for > instance.) I have that one on my list to respond to. IMO we should be moving away from having 8.3 requirements depend on section 4 requirements, and instead move toward copying the necessary requirements to section 8, which whatever modifications (like 24 months) are more appropriate for transfers. But that is a bit of a project, which I don't have time for just yet. :-) -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 jcurran at arin.net Mon May 2 20:12:00 2011 From: jcurran at arin.net (John Curran) Date: Tue, 3 May 2011 00:12:00 +0000 Subject: [arin-ppml] Analogies In-Reply-To: References: <39209.1303885464@tristatelogic.com> <75822E125BCB994F8446858C4B19F0D7173057C827@SUEX07-MBX-04.ad.syr.edu> <471D76419F9EF642962323D13DF1DF69011E5C@newserver.arneill-py.local> <7348D3C8-4EB7-4440-A152-210CC8B0DA3C@arin.net> <471D76419F9EF642962323D13DF1DF69011E60@newserver.arneill-py.local> <583A067A-B8AE-4026-844E-6769D1D7CF88@arin.net> <471D76419F9EF642962323D13DF1DF69011E61@newserver.arneill-py.local> <7DF2A1C4-1799-486B-A631-2E1119C22A7C@arin.net> <3CCC6D1F-11F4-40BC-B102-CC6744A5E709@virtualized.org> <4DB9BACE.6000307@ipinc.net> <0E134D8B-0A4B-466E-B261-9C7D0ED11867@virtualized.org> <388190E3-08F2-4AC7-870A-621A2FD6EEFE@virtualized.org> <2ABCF380-7866-4ED8-BE43-C789CBEBFE27@delong.com> <53B633A2-A7F6-4BF3-A11B-4981C9A41130@delong.com> Message-ID: <20B2220E-A768-46CE-B19D-AF15D02AD08F@arin.net> On May 3, 2011, at 2:07 AM, William Herrin wrote: > Maybe you mean 10b which is the only obvious thing that sets out a > condition that could be inconsistent with the NRPM. It says, "ARIN > will take no action to reduce the services provided for Included > Number Resources that are not currently being utilized by the Legacy > Applicant." And it doesn't even promise to leave all the registrant's > addresses intact... just the ones that "are not currently being > utilized." Bill - I'm currently looking into this precise phrase, as it appears to combine two concepts incorrectly. I'll report back shortly. /John John Curran President and CEO ARIN From matthew at matthew.at Mon May 2 20:13:19 2011 From: matthew at matthew.at (Matthew Kaufman) Date: Mon, 2 May 2011 17:13:19 -0700 Subject: [arin-ppml] ARIN-prop-147 Set Transfer Need to 24 months and Clarify Exception In-Reply-To: References: <4DBEF12A.2020002@arin.net> <03F0539F-6F62-49CD-84F8-9ABC62095596@delong.com> <69160560-5FF3-4CEE-B688-84CCB6AD2426@matthew.at> Message-ID: <2A17CD60-39D2-4784-AAB5-445735FA6143@matthew.at> On May 2, 2011, at 4:39 PM, Owen DeLong wrote: >> If they are to re-qualify, it doesn't make sense that they be forced to justify only a 3-month supply simply because the free pool is low or empty. >> > I disagree. ... > Again, I don't think that we need to support that through policy. IPv4 is reaching its > end of life. There is a need to help some organizations limp along with it through > transfers while it is deprecated, but, seeking to create new businesses based on > IPv4 construction over the next 2 years is not something I favor encouraging or > facilitating through policy. ANY new entity which is built through acquisition of something that exists today will need to serve customers on the IPv4 Internet for at least 2 years. Even if they are fortunate enough to grow. You are arguing that because Facebook has enough IPv4 space to last for another year or two, a new upstart shouldn't be able to use VC money and the transfer market to obtain an existing entity with enough IPv4 space to compete against Facebook on the IPv4 Internet for a year... you'd rather force them into getting only enough for 3 months and then crossing their fingers in hope that another 3 month supply will be available... all because the ARIN free pool ran out?!? Matthew Kaufman From matthew at matthew.at Mon May 2 20:16:14 2011 From: matthew at matthew.at (Matthew Kaufman) Date: Mon, 2 May 2011 17:16:14 -0700 Subject: [arin-ppml] ARIN-prop-140 Business Failure Clarification In-Reply-To: <7B10B708-B9B5-4655-A467-4BE74E555EF2@delong.com> References: <4DBEF0DF.8060800@arin.net> <9BC4E3EC-E693-44D9-A415-A9E0F97E1BAA@matthew.at> <00A60C73-0282-416A-BBF1-D491ADDD18EE@delong.com> <7B10B708-B9B5-4655-A467-4BE74E555EF2@delong.com> Message-ID: On May 2, 2011, at 4:47 PM, Owen DeLong wrote: > > On May 2, 2011, at 3:40 PM, Matthew Kaufman wrote: > >> >> On May 2, 2011, at 3:34 PM, Owen DeLong wrote: >>> >>> I was the POC for an organization which failed. When I was informed that >>> my job was being terminated and the company liquidated, the network >>> being shut down, etc. I notified ARIN and the addresses and AS Numbers >>> were reclaimed. >> >> If you notified ARIN after your date/time of termination, you were probably acting outside of your authority. >> > I notified ARIN that the business was being liquidated and that the network > had been shut down. I did not tell ARIN to reclaim the addresses (though I > expressed a belief that policy might support reclamation). > > As such, I was not acting in or out of authority. I was conveying information. > The information was a matter of public record and so not subject to NDA. > >> And these days, if you notified ARIN before talking to your management about the possibility of transferring the addresses in order to pay creditors during the liquidation you wouldn't be upholding your fiduciary responsibility to your employer. >> > If I did so while I had a fiduciary responsibility, perhaps. However, once > terminated, I had no such fiduciary responsibility. Once terminated you didn't have the authority to report it to ARIN *as the POC* either... you're just another random citizen. Hopefully you made it clear to ARIN that you were no longer an authorized POC when you made the assertion that the business was being liquidated and the network shut down. > > we can agree to disagree. Or not. Matthew Kaufman -------------- next part -------------- An HTML attachment was scrubbed... URL: From owen at delong.com Mon May 2 20:20:12 2011 From: owen at delong.com (Owen DeLong) Date: Mon, 2 May 2011 17:20:12 -0700 Subject: [arin-ppml] ARIN-2011-5: Shared Transition Space for IPv4 Address Extension - Last Call In-Reply-To: References: <4DAC8BCB.2000300@arin.net> <54E900DC635DAB4DB7A6D799B3C4CD8E10C7EF5E@PLSWM12A.ad.sprint.com> <3128593549961341875@unknownmsgid> <54E900DC635DAB4DB7A6D799B3C4CD8E10C899B7@PDAWM12B.ad.sprint.com> <1489147144792938659@unknownmsgid> <54E900DC635DAB4DB7A6D799B3C4CD8E10C89AC7@PDAWM12B.ad.sprint.com> <54E900DC635DAB4DB7A6D799B3C4CD8E10C8D92B@PDAWM12B.ad.sprint.com> Message-ID: <20BCB2A2-84B1-4253-866D-3330C4E051A1@delong.com> On May 2, 2011, at 4:14 PM, William Herrin wrote: > On Mon, May 2, 2011 at 4:39 PM, George, Wes E [NTK] > wrote: >> On Mon, Apr 25, 2011 at 8:46 AM, George, Wes E [NTK] wrote: >>> IPv4 addresses used behind a NAT (inside pool) cannot be used for >>> justification of new resources nor counted towards utilization >>> calculations for existing resources. >>> NRPM 4.10.x (Shared Transition Space) defines a specific non-unique >>> block to be shared among multiple networks for this purpose. > >> I don't understand your example, specifically how a transfer would figure into the discussion. Please try to rephrase. > > Sorry, I was being snarky. > > Under your wording, once I have placed equipment behind a NAT, I can > never move it out in front of a NAT because its existence doesn't > justify addresses. You could probably fix that particular problem by > saying "addresses _intended to be_ used behind a NAT." > > But there are more problems. For example, addresses behind a bastion > host firewall would still qualify even though that's basically the > same use as the NAT. That's fundamentally unfair, which violates a > basic precept of any public policy process.. > Uh, no, it's not at all unusual for addresses behind a bastion for some purposes to be reachable directly for other purposes or to have direct outbound access. I can think of many circumstances where things I placed behind a bastion host needed globally unique addresses. I cannot think of a situation where a host inside an overloaded NAT needed (or had) globally unique addresses. In such a case, what would be the point of using an overloaded NAT? > And what about folks who decide to consume public addresses inside > their stateful non-translating firewalls even though they've locked it > down where the only thing that passes is outbound tcp? Is it fair that > folks trying to conserve with NAT should pay an additional > policy-level penalty while wasters don't? > I don't personally see a problem with this. If you choose to use NAT, you're paying a number of penalties in functionality already, why should you get rewarded with addresses you don't plan to use? Owen From jcurran at arin.net Mon May 2 20:24:54 2011 From: jcurran at arin.net (John Curran) Date: Tue, 3 May 2011 00:24:54 +0000 Subject: [arin-ppml] ARIN-prop-140 Business Failure Clarification In-Reply-To: <5C870A6C-E149-413D-9661-9EB20ADF4E8E@matthew.at> References: <4DBEF0DF.8060800@arin.net> <949B31E1-F496-41B7-B00D-9E7160F3CF8D@matthew.at> <4DBF39CC.9080502@umn.edu> <5C870A6C-E149-413D-9661-9EB20ADF4E8E@matthew.at> Message-ID: <1149E3BA-A650-46DF-971A-3E3857927D0C@arin.net> On May 3, 2011, at 1:51 AM, Matthew Kaufman wrote: > So maybe we *just* need a policy to cover reclaim of legacy resources that works for actually-defunct entities and doesn't put at risk anything less than that. ARIN's existing business practice is to reclaim resources from dissolved businesses. We may have some differences of opinion about whether a business is actually defunct in cases where the business hasn't legally shutdown, but when the business is reported dissolved at state corporate registry, we do reclaim the associated resources. FYI, /John John Curran President and CEO ARIN From mike at nationwideinc.com Mon May 2 20:25:44 2011 From: mike at nationwideinc.com (Mike Burns) Date: Mon, 2 May 2011 20:25:44 -0400 Subject: [arin-ppml] Accusation of fundamental conflict ofinterest/IPaddress policy pitched directly to ICANN References: <4DBB208B.4060808@ipinc.net><23B533DB44354E3EA201D0941C47C46C@video><274D7568A828485B91D64F9308B3A24E@video><9737f78a74367c4fde16e526d31442304dbec379@jcc.com><40d2346a1b58436fb0387d165b0c7bee4dbed64a@jcc.com><34A035C8AB3147919076CC4BB118C83B@mike><03bbb072c4565685fb86a50e59d5178b4dbefc1f@jcc.com><35F0C71BD6974F21A3C296005F0DDA0F@mike> Message-ID: <01BF0F04DB434A38AD49E9D5F3F1E951@video> Hi Jonathan, answers inline. >What is broken about ARIN is that scandalously large numbers of netblocks do not have valid POCs, for example. The stewardship of Whois leaves a lot to be desired. >What steps would a commercial entity take to resolve this that RIRs cannot? A commercial entity could recognize justification-free legacy transfers, and many legacy transfers happened but were not reflected in Whois because of this. Not that the RIRs cannot do this, but they have not. It could well be that changing conditions will cause a realization of the legal realities of these transfers, and induce an RIR community to change policy to turn that registry into a title agency, reviewing evidence of property transfers without reference to the need to transfer networks or customers, or justify a need. >Competitive pressures would help to finally decide who controls these addresses and allow them to be transferred to those who would pay for them. >Leaving other equally "worthy" entities with less money unable to acquire space despite their need? I meant competitive pressures between registries, but sure, poor entities couldn't afford expensive IP addresses. >Network operators don't really have much of a choice in accessing Whois information to determine the rights to advertise addresses, and competive registries. >I'd argue that network operators are the very ones who give the RIR their "power." I also don't see why you seem to claim that they can't? Tell me, what's stopping them from using whatever registry they want? I couldn't agree more. I don't think there really is anything stopping them from using whatever registry they want. I think they have slim pickings in registries now, and use what they have, but they don't trust it unilaterally. If a registry comes along that offers network operators some insurance against conflict or abuse claims, my bet is they would avail themselves of it rather than turn down business. >What is broken about ARIN is that their transfer policies are more restrictive than APNICs, and that will cause a flow of addresses out of ARIN and into APNIC. >Could you explain why you think this? All else being equal, I believe buyers and sellers will migrate towards the freer market. The justification is like a transaction cost. Transactions will go to where the cost is lowest. >Not to speak for him but you did say " Competitive pressures would help to finally decide who controls these addresses and allow them to be transferred to those who would pay for them." >Were you not suggesting that the folks with the most money would be the ones who got address space registered to their name and the others would be out in the rain? >Let me know if I misunderstood. Yes, you misunderstood, I was talking about competitive pressures between registries. If a registry becomes freer, like APNIC did, it puts competitive pressures on the other registries to free their markets up, that's what I was trying to say. Sorry if I was unclear. But yes, eventually it will cost money to get IP addresses. I guess the richer you are, the more easy it will be to acquire addresses in the post-exhaust world. I don't see any honest way around this, but at least this will serve to free up huge swaths of address space currently on the sideline. Wouldn't this buy some time to finally get that orderly V6 transition in motion? Regards, Mike Burns A competitive registry could presumably have a different transfer policy, as APNICs differs from ARINs. What is broken about ARIN is that ARIN has professed no statutory control over legacy addresses in the Plzak declaration in the Kremen case, and yet attempts to control the registration of legacy resources. With a private registry, the address rights holders can choose to opt-out of ARIN's dictats and choose their registry voluntarily. As I said above, I don't think there is anything stopping someone from "choosing their registry voluntarily." I don't see how the creation of a private registry will perturb the current mechanisms in a way that costs you money, could you share why you feel that way? Not to speak for him but you did say " Competitive pressures would help to finally decide who controls these addresses and allow them to be transferred to those who would pay for them." Were you not suggesting that the folks with the most money would be the ones who got address space registered to their name and the others would be out in the rain? Let me know if I misunderstood. Jon Fernatt -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike at nationwideinc.com Mon May 2 20:34:02 2011 From: mike at nationwideinc.com (Mike Burns) Date: Mon, 2 May 2011 20:34:02 -0400 Subject: [arin-ppml] NRPN 8.2 & 2.3 References: <61CEAA1048BE416 E9BD7FB5C7CBF47FB@mike> <77B52A33-3F2E-45D0-9BA7-65D90FF96144@arin.net> Message-ID: <4248BC58FED54CEB84B3F66CF61A046F@video> >Actually, that is not the case. Internally, we calculate need based on the information provided and that is more granular than a CIDR boundary. Yes, the needs assessment is more granular, but since you can't dole out /32s, you round up, isn't that accurate? And since you seek aggregation, you will always allocate as a single netblock? I wonder what the rounding error was on that recent Comcast /9. My example made it clear that the language could be interpreted two ways, why do you say you would need to "reinterpret contrary to the adopted language"? I, and others, have pointed out that the modification of "be received" by the phrase "in a single aggregate" makes eminent sense and conforms to history. But interpreting the clause to apply to the "demonstrated need" section of the predicate leaves one scratching one's head. I mean,. who goes to ARIN and gets justified for anything other than a single aggregate? Isn't that what Owen was saying he believed the intent to be? >We follow the policies as written and do not have the freedom reinterpret policy contrary to the adopted language. I indicated this before, but am happy to repeat it if that helps you. Repeating it doesn't help much, I'm afraid.The phrase digging yourself deeper comes to mind. Regards, Mike ----- Original Message ----- From: John Curran To: Mike Burns Cc: arin-ppml at arin.net List Sent: Monday, May 02, 2011 5:45 PM Subject: Re: [arin-ppml] NRPN 8.2 & 2.3 On May 2, 2011, at 9:57 PM, Mike Burns wrote: I don't believe that there has been an answer to those of us who said that while it is grammatically acceptable to decide that a "single aggregate" relates to the needs justification, it is nonsensical to do that, as all needs analyses result in a single aggregate. You don't have a needs analysis at any time where it is found that a need is outside CIDR boundaries. Need assessment has always rounded up to that boundary. Mike - Actually, that is not the case. Internally, we calculate need based on the information provided and that is more granular than a CIDR boundary. No, the only way to interpret the language of 8.3 is that the reception of the addresses should occur as a single aggregate, which is clear has not occurred with 8.3. To say the staff or the board acted outside of policy is correct in the MS/Nortel case. We follow the policies as written and do not have the freedom reinterpret policy contrary to the adopted language. I indicated this before, but am happy to repeat it if that helps you. Thanks! /John John Curran President and CEO ARIn -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcurran at arin.net Mon May 2 20:39:26 2011 From: jcurran at arin.net (John Curran) Date: Tue, 3 May 2011 00:39:26 +0000 Subject: [arin-ppml] NRPN 8.2 & 2.3 In-Reply-To: <4248BC58FED54CEB84B3F66CF61A046F@video> References: <"61CEAA1048BE416 E9BD7FB5C7CBF47FB"@mike> <77B52A33-3F2E-45D0-9BA7-65D90FF96144@arin.net> <4248BC58FED54CEB84B3F66CF61A046F@video> Message-ID: <3D0DEABD-E85A-4D7F-9EEB-D01CB710470F@arin.net> > On May 3, 2011, at 2:34 AM, Mike Burns wrote: > ... > >We follow the policies as written and do not have the freedom reinterpret policy > > contrary to the adopted language. I indicated this before, but am happy to repeat > >it if that helps you. > > Repeating it doesn't help much, I'm afraid. Alas, I can't help you there. /John John Curran President and CEO ARIN From mike at nationwideinc.com Mon May 2 20:43:58 2011 From: mike at nationwideinc.com (Mike Burns) Date: Mon, 2 May 2011 20:43:58 -0400 Subject: [arin-ppml] Fw: Accusation of fundamental conflict ofinterest/IPaddress policy pitched directly to ICANN References: Message-ID: No, I want the question of whether to allow competitive non-regional registries to be decided by an entity other than one composed of non-competitive regional registries who currently enjoy a monopoly on registration services. There is a conflict of interest there. Let the venue be moved to a higher level. Regards, Mike ----- Original Message ----- From: "Owen DeLong" To: "Mike Burns" Cc: "McTim" ; Sent: Monday, May 02, 2011 6:28 PM Subject: Re: [arin-ppml] Fw: Accusation of fundamental conflict ofinterest/IPaddress policy pitched directly to ICANN So your argument boils down to: I don't like who the communities elected, so, I want to shop for a different forum? Owen On May 2, 2011, at 1:13 PM, Mike Burns wrote: > Hi Tim, > > Just read the names of the committe members. > Enough said. > > Regards, > Mike > > ----- Original Message ----- From: "McTim" > To: "Mike Burns" > Cc: > Sent: Monday, May 02, 2011 4:06 PM > Subject: Re: Fw: [arin-ppml] Accusation of fundamental conflict > ofinterest/IPaddress policy pitched directly to ICANN > > > On Mon, May 2, 2011 at 7:48 PM, Mike Burns wrote: >>> Can you be more specific? The ICANN ASO? the ICANN BoT? the IANA? >> >> Hi Tim, >> >> Keep going, all the organizations above are suspect due to the fact that >> they are all comprised of the same basic group of RIR designees. > > The RIRs do not "designate" or appoint anyone to any of the above > bodies. The ASO AC members are elected by their respective RIR > communities. Those ASO AC members do have a role to play in choosing > 2 (IIRC) of the ICANN Board. Neither the RIRs nor the ASO get to > choose IANA staff. > >> >> I would take it to NTIA like DNS. > > I think you overestimate the role of the NTIA in the DNS. > >> >> And I would use DNS as a template for the creation of the global policy >> restrictions John Curran asked about, which restrictions would apply to >> all >> registries, regional or commercial. >> Just as all DNS registrars must meet certain qualifications, so would >> private registries of number space. >> >> Let the NTIA hear arguments from the proposer and from the ASO, the ICANN >> BoT, and IANA, although I suspect they will all sound the same. > > > Back in the 1990's, the idea was for the USG to divest itself (via > ICANN) of the naming and numbering roles. That process is still > ongoing, and one can see a certain acceleration of divestiture in > recent years. The Affirmation of Commitments is, I think, an example > of this. > > As DF has indicated, this (asking the NTIA to make this kind of > determination) would be a real non-starter for the global Internet > Governance community. > > -- > Cheers, > > McTim > "A name indicates what we seek. An address indicates where it is. A > route indicates how we get there." Jon Postel > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From mysidia at gmail.com Mon May 2 20:46:11 2011 From: mysidia at gmail.com (Jimmy Hess) Date: Mon, 2 May 2011 19:46:11 -0500 Subject: [arin-ppml] Analogies In-Reply-To: References: <39209.1303885464@tristatelogic.com> <75822E125BCB994F8446858C4B19F0D7173057C827@SUEX07-MBX-04.ad.syr.edu> <471D76419F9EF642962323D13DF1DF69011E5C@newserver.arneill-py.local> <7348D3C8-4EB7-4440-A152-210CC8B0DA3C@arin.net> <471D76419F9EF642962323D13DF1DF69011E60@newserver.arneill-py.local> <583A067A-B8AE-4026-844E-6769D1D7CF88@arin.net> <471D76419F9EF642962323D13DF1DF69011E61@newserver.arneill-py.local> <7DF2A1C4-1799-486B-A631-2E1119C22A7C@arin.net> <3CCC6D1F-11F4-40BC-B102-CC6744A5E709@virtualized.org> <4DB9BACE.6000307@ipinc.net> <0E134D8B-0A4B-466E-B261-9C7D0ED11867@virtualized.org> <388190E3-08F2-4AC7-870A-621A2FD6EEFE@virtualized.org> <2ABCF380-7866-4ED8-BE43-C789CBEBFE27@delong.com> <8D07F7F5-7E60-4176-A5D3-929F160AC608@arin.net> Message-ID: On Mon, May 2, 2011 at 6:43 PM, William Herrin wrote: > On Mon, May 2, 2011 at 7:13 PM, John Curran wrote: >> On May 3, 2011, at 12:47 AM, William Herrin wrote: > "Any network found to host photoshopped pornography of Republican > political candidates is subject to having its number resources > revoked." ARIN probably needs to surrender the ability to revoke IP addresses based on censorship grounds back to the community, by putting a clause in the RSA restricting ARIN from revoking resources for that reason, if it even has maintained such an ability, so a policy cannot ever revoke resources for the purpose of targetting content served by hosts using an IP address. ARIN is concerned with stewardship of resources, and management of what content or traffic can be exchanged by hosts assigned those resources, is, and should be out of the scope of IP addressing and DNS policy. That type of policy simply should not be allowed, even if the community finds certain activity hosts using IP or DNS resources can perform to be abhorrent. Any censorship can be determined by the network service providers exchanging the data, and by the relevant jurisdictions the hosts reside in; there is no need for ARIN to intervene there. Would the community actually adopt a policy like that? No... How about "Any network found to be harboring spammers or hackers, will have its number resources revoked and automatically become ineligible to receive any additional resources in the future. Consistent existence of listing by a recognized public DNS RBL of any assigned IP address, for a period of 24 hours or longer, will result in a single warning; if not corrected, all resources will be temporarily revoked after 7 days. If the IP address is not found in good standing with the RBL within 21 days, revokation becomes permanent. " That's probably something more likely to be proposed seriously -- -JH From mike at nationwideinc.com Mon May 2 20:56:20 2011 From: mike at nationwideinc.com (Mike Burns) Date: Mon, 2 May 2011 20:56:20 -0400 Subject: [arin-ppml] NRPN 8.2 & 2.3 References: <61CEAA1048BE416 E9BD7FB5C7CBF47FB@mike><12539DE2-CAC3-4891-9B02-B146AECD3FB6@delong.com> Message-ID: <1E021BD750354DE1B55F36FF0D967ED4@video> >Owen, >Would you be in support of an open exchange if there were basic controls in place to lockout speculators? >Jeffrey Lyon, Leadership Team Jeff, I would think that Owen would support speculation, as given the inevitable transition to IPv6, hoarders and speculators will take it in the shorts, plus driving up the price will drive us towards IPV6 even faster. Some inherent limits on speculation in this market... As far as cornering the market, even the Hunt brothers would be unable to corner a market which is currently valued at close to $50 billion and rising. (4.3 billion addresses times $11) Regards, Mike ----- Original Message ----- From: Jeffrey Lyon To: Owen DeLong Cc: Mike Burns ; arin-ppml at arin.net ; Rudolph Daniel Sent: Monday, May 02, 2011 7:34 PM Subject: Re: [arin-ppml] NRPN 8.2 & 2.3 On Mon, May 2, 2011 at 6:25 PM, Owen DeLong wrote: On May 2, 2011, at 12:57 PM, Mike Burns wrote: >It seems the community is >rather divided with some advocating a complete abandonment >of the principles of stewardship in favor of a laissez faire >address economy while others favor preservation of the >principles of stewardship and justified need while enabling >market incentives to free up space. >Owen Removing artificial restrictions on the transfer of IP address space is not, as Owen persists in characterizing it, an abandonment of the principles of stewardship. Yes... It is. Stewardship simply means different things pre- and post-exhaust. No, it does not. Pre-exhaust requires needs analyses to ensure efficient use of address space. Post-exahust, efficient use is ensured by the same market incentives you claim enables the freeing up of space. To wit, price. I don't believe that is a dependable system because without the needs basis, you open up the potential for a new class of organization... The speculator who wants to come in, use vast financial resources to acquire all addresses priced below some threshold he believes to be viable and then wait until the market desire for the resource exceeds that price (potentially by a wide margin). This delays the availability of addresses to a wider set of justified need while increasing the price without benefit to the community. The only entitiy that gains in this environment is the speculator. Everyone else loses. That is, regardless of what else you may think, in my mind an obvious abandonment of the responsibility of stewardship. I don't believe that there has been an answer to those of us who said that while it is grammatically acceptable to decide that a "single aggregate" relates to the needs justification, it is nonsensical to do that, as all needs analyses result in a single aggregate. You don't have a needs analysis at any time where it is found that a need is outside CIDR boundaries. Need assessment has always rounded up to that boundary. I agree with you that is the case. No, the only way to interpret the language of 8.3 is that the reception of the addresses should occur as a single aggregate, which is clear has not occurred with 8.3. To say the staff or the board acted outside of policy is correct in the MS/Nortel case. While it is nonsensical, I have found that the law is often nonsensical in its interpretation of plain English. The supreme court has somehow managed to interpret the plain English of the first amendment to include the ability to bankroll a campaign by a corporation as a form of protected free speech. To me, this seems completely nonsensical. So, we can't rule out a nonsensical interpretation and we need to write language that cannot be nonsensically interpreted. Owen Regards, Mike ----- Original Message ----- From: Owen DeLong To: Rudolph Daniel Cc: arin-ppml at arin.net Sent: Monday, May 02, 2011 3:44 PM Subject: Re: [arin-ppml] NRPN 8.2 & 2.3 At this point, I would agree. However, I would like to wait until I get a chance to discuss the matter with ARIN Counsel and further discuss it with staff before I start crafting proposals to do so. I don't feel that staff or the board have acted improperly. I think that policy failed to express the community intent well enough as to achieve or goals. I will continue to work on finding a way to bring policy better in line with community intent, but, the hard part will be achieving consensus on what that intent is. It seems the community is rather divided with some advocating a complete abandonment of the principles of stewardship in favor of a laissez faire address economy while others favor preservation of the principles of stewardship and justified need while enabling market incentives to free up space. It is most unfortunate that we failed to produce clear policy in 2009-1. I hope we can correct it at Philadelphia. Owen On Apr 30, 2011, at 6:48 PM, Rudolph Daniel wrote: It would seem clear to me that at the very least, NRPN 8.2 and 8.3 requires rephrasing. Is that also the view of the ppml? rd >> for such resources, as a single aggregate", not that a single >> aggregate be transferred. > > ... I do not believe that Stephen's interpretation below matches the > meaning or the intent of the policy as I understand it. ... I don't think it does either, for the record. However, this points out how bad wording has left us in a situation where we're not sure /what/ the policy text means--much less whether we agree with it. > I do agree that your interpretation would be a syntactically and > grammatically valid construction, but, I believe it is contextually > nonsensical and not the intended meaning of the words. > > If anyone has a suggestion for making the actual intent more clear, I > am open to suggestions and would support making an editorial > correction for clarity. If you can provide examples of transfers you both do and don't wish to allow, I'll be happy to come up with wording to express your intent. As it stands, though, I don't understand your (or anyone else's) intent well enough to try. S -- Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3646 bytes Desc: S/MIME Cryptographic Signature URL: ------------------------------ Message: 2 Date: Sat, 30 Apr 2011 20:28:39 -0400 From: William Herrin To: John Curran Cc: Public Policy Mailing List Subject: Re: [arin-ppml] Call for a study & survey to obtain necessary information for policy development Message-ID: Content-Type: text/plain; charset=ISO-8859-1 On Sat, Apr 30, 2011 at 7:51 AM, John Curran wrote: > ? contains a specific call for ARIN to charter a study including > ? a survey in order to obtain additional information to assist in > ? policy development. > > ? I've not seen any discussion of this suggestion; would it be > ? possible to get feedback from the otherwise shy participants > ? on the PPML mailing list? > > On Apr 29, 2011, at 5:46 PM, Jeffrey Lyon wrote: >> what we should do is >> charter ARIN to conduct a comprehensive study and: >> >> - Conduct a survey of the public at large, PPML users, full members, >> resource holders, and the AC to gain a clear understanding of >> sentiment for or against an open market. >> - Determine how many companies actually have IPv6 migration plans and >> ascertain road blocks, either legitimate or financial, that are >> preventing migration. >> - Would resource holders support a model that allowed ARIN to take a >> small commission on resource sales and then discontinue the practice >> of charging an annual fee to its members who are not buying and >> selling resources. These seem like they could be determined by survey. >> - In the survey, ask IPv4 resource holders to anonymously disclose >> their true utilization rates and determine if companies are hoarding >> resources either in hopes of future resale or to cover an arbitrary >> future need. >> - Determine the amount of participants that would come forward if told >> they could resell their space on the open market and ultimately >> determine how much unneeded space is being locked away in loosely >> justified allocations. >> - Determine if resource holders would be encouraged to tighten up >> internal policies and free up more space if there were a fair market >> value assigned to their space. These strike me as very difficult to determine by anything approaching a statistically valid survey. I would want to see a detailed methodology proposed before agreeing either that money should be spent conducting the survey or that the results would have merit to contribute to the policy debate. >> - Determine the economic impact. Would resource holders be better off >> selling their resources to more affluent companies who would be able >> to put the space to better use? Might there be a host of struggling >> small businesses who would like to put their /17 - /21 on the balance >> sheet? Are there companies that would purchase IPv4 space at a premium >> if allowed to do so? This would require a cost analysis of a great many factors, only some of which have been touched on in the listed survey. Given the abject lack of use of cost analysis in the Internet industry, it would require at least three independent cost analyses and considerable subsequent debate on and validation of the methodologies... Start here: http://www.sceaonline.net/ Disclaimer: my father is a crotchety old cost analyst so I get a regular earful about this stuff. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 ------------------------------ Message: 3 Date: Sat, 30 Apr 2011 20:39:08 -0400 From: William Herrin To: Owen DeLong Cc: John Curran , arin-ppml Subject: Re: [arin-ppml] Analogies Message-ID: Content-Type: text/plain; charset=ISO-8859-1 On Sat, Apr 30, 2011 at 1:31 AM, Owen DeLong wrote: > I will point out that ARIN is the only registry that did not start > charging their legacy holders shortly after coming into existence. > > APNIC, RIPE, AfriNIC, and LACNIC all charge their legacy holders > annual fees to the best of my knowledge. > > I do not know whether a contract was required in any or all cases, > but, the fee portion of the equation is unique to ARIN to the best > of my knowledge. Hi Owen, I will suggest that an attempt by ARIN to charge $100/year under a contract simplified to, "We agree to keep your whois data and RDNS delegations intact as is for one year increments until either of us choose to cancel this contract" would meet with at most mild resistance from the legacy registrants. It would also, IMHO, provide an excellent way to weed out the abandoned registrations. This hasn't been done in part because we, in this forum, have insisted that legacy registrants should not be invited into the fold under such terms. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 ------------------------------ Message: 4 Date: Sat, 30 Apr 2011 20:43:29 -0400 From: "Mike Burns" To: "Stephen Sprunk" , "Owen DeLong" Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] ARIN / Microsoft press release regarding IP addressTransfers Message-ID: <7B6110E30D2E40CDA7E10BCB85E290B7 at video> Content-Type: text/plain; charset="utf-8" >If you can provide examples of transfers you both do and don't wish to allow, I'll be happy to come up with wording to express your intent. As it stands, though, I >don't understand your (or anyone else's) intent well enough to try. >S Steve, Here is why I call BS on the claim that these transfers comply with policy: "Such transferred number resources may only be received under RSA by organizations that are within the ARIN region and can demonstrate the need for such resources, as a single aggregate, in the exact amount which they can justify under current ARIN policies." That is the text. The comma between resources and "as a single aggregate" can be read to cause the "as a single aggregate" clause to apply to either the verb phrase "be received" or the verb phrase "can demonstrate." But how would anybody demonstrate a need for multiple netblocks anyway? Isn't the need ALWAYS determined as a single aggregate? Regards, Mike ----- Original Message ----- From: Stephen Sprunk To: Owen DeLong Cc: arin-ppml at arin.net Sent: Saturday, April 30, 2011 8:27 PM Subject: Re: [arin-ppml] ARIN / Microsoft press release regarding IP addressTransfers On 16-Apr-11 02:19, Owen DeLong wrote: On Apr 15, 2011, at 9:53 PM, Stephen Sprunk wrote: On 15-Apr-11 19:00, Matthew Kaufman wrote: The adopted policies (if they are using the "relatively new policy" as alluded to in the release) require the transfer of *a single aggregate*. Not quite. NRPM 8.3 only requires the receiver "demonstrate the need for such resources, as a single aggregate", not that a single aggregate be transferred. ... I do not believe that Stephen's interpretation below matches the meaning or the intent of the policy as I understand it. ... I don't think it does either, for the record. However, this points out how bad wording has left us in a situation where we're not sure what the policy text means--much less whether we agree with it. I do agree that your interpretation would be a syntactically and grammatically valid construction, but, I believe it is contextually nonsensical and not the intended meaning of the words. If anyone has a suggestion for making the actual intent more clear, I am open to suggestions and would support making an editorial correction for clarity. If you can provide examples of transfers you both do and don't wish to allow, I'll be happy to come up with wording to express your intent. As it stands, though, I don't understand your (or anyone else's) intent well enough to try. S -- Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking ------------------------------------------------------------------------------ _______________________________________________ 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: ------------------------------ _______________________________________________ ARIN-PPML mailing list ARIN-PPML at arin.net http://lists.arin.net/mailman/listinfo/arin-ppml End of ARIN-PPML Digest, Vol 70, Issue 176 ****************************************** -- Rudi Daniel danielcharles consulting 1-784 498 8277 _______________________________________________ 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. Owen, Would you be in support of an open exchange if there were basic controls in place to lockout speculators? -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications - AS32421 First and Leading in DDoS Protection Solutions -------------- next part -------------- An HTML attachment was scrubbed... URL: From jeffrey.lyon at blacklotus.net Mon May 2 20:54:58 2011 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Mon, 2 May 2011 20:54:58 -0400 Subject: [arin-ppml] Analogies In-Reply-To: References: <39209.1303885464@tristatelogic.com> <75822E125BCB994F8446858C4B19F0D7173057C827@SUEX07-MBX-04.ad.syr.edu> <471D76419F9EF642962323D13DF1DF69011E5C@newserver.arneill-py.local> <7348D3C8-4EB7-4440-A152-210CC8B0DA3C@arin.net> <471D76419F9EF642962323D13DF1DF69011E60@newserver.arneill-py.local> <583A067A-B8AE-4026-844E-6769D1D7CF88@arin.net> <471D76419F9EF642962323D13DF1DF69011E61@newserver.arneill-py.local> <7DF2A1C4-1799-486B-A631-2E1119C22A7C@arin.net> <3CCC6D1F-11F4-40BC-B102-CC6744A5E709@virtualized.org> <4DB9BACE.6000307@ipinc.net> <0E134D8B-0A4B-466E-B261-9C7D0ED11867@virtualized.org> <388190E3-08F2-4AC7-870A-621A2FD6EEFE@virtualized.org> <2ABCF380-7866-4ED8-BE43-C789CBEBFE27@delong.com> <8D07F7F5-7E60-4176-A5D3-929F160AC608@arin.net> Message-ID: On Mon, May 2, 2011 at 8:46 PM, Jimmy Hess wrote: > On Mon, May 2, 2011 at 6:43 PM, William Herrin wrote: >> On Mon, May 2, 2011 at 7:13 PM, John Curran wrote: >>> On May 3, 2011, at 12:47 AM, William Herrin wrote: > >> "Any network found to host photoshopped pornography of Republican >> political candidates is subject to having its number resources >> revoked." > > ARIN probably needs to surrender the ability to revoke IP addresses > based on censorship grounds back to the community, by putting a clause > in the RSA restricting ARIN from revoking resources for that reason, > if it even has > maintained such an ability, so a policy cannot ever revoke resources > for the purpose of targetting ?content ?served by hosts using an IP address. > > ARIN is concerned with stewardship of resources, and management > of what content or traffic can be exchanged by hosts assigned those resources, > is, and should be out of the scope of IP addressing and DNS policy. > > That type of policy simply should not be allowed, even if the community finds > certain activity hosts using IP or DNS resources can perform to be abhorrent. > > > Any censorship can be determined by the network service providers exchanging > the data, and by the relevant jurisdictions the hosts reside in; > there is no need > for ARIN to intervene there. > > > Would the community actually adopt a policy like that? No... > How about > > "Any network found to be harboring spammers or hackers, will have its > number resources revoked and automatically become ineligible > to receive any additional resources in the future. > > Consistent existence of listing by a recognized public DNS RBL > of any assigned IP address, for a period of 24 hours or longer, > will result in a single warning; ?if not corrected, all resources will > be temporarily revoked after 7 days. > > If the IP address is not found in good standing with the RBL > within 21 days, revokation becomes permanent. > " > > That's probably something more likely to be proposed seriously > > > -- > -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. > At which point all you would have to do is bribe the RBL's to list your competitors. -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications - AS32421 First and Leading in DDoS Protection Solutions From owen at delong.com Mon May 2 21:05:23 2011 From: owen at delong.com (Owen DeLong) Date: Mon, 2 May 2011 18:05:23 -0700 Subject: [arin-ppml] NRPN 8.2 & 2.3 In-Reply-To: References: <61CEAA1048BE416E9BD7FB5C7CBF47FB@mike> <12539DE2-CAC3-4891-9B02-B146AECD3FB6@delong.com> Message-ID: <0D7208D7-EE99-46DE-8839-A388A6B13F14@delong.com> > > > Owen, > > Would you be in support of an open exchange if there were basic controls in place to lockout speculators? > Perhaps. I would need to feel that the controls were sufficiently adequate to prevent speculation and certain other potential forms of abuse and I would feel that there would have to be a preservation of the principles of stewardship including that resources not be received by those without justified need. Owen From jeffrey.lyon at blacklotus.net Mon May 2 21:13:20 2011 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Mon, 2 May 2011 21:13:20 -0400 Subject: [arin-ppml] NRPN 8.2 & 2.3 In-Reply-To: <0D7208D7-EE99-46DE-8839-A388A6B13F14@delong.com> References: <61CEAA1048BE416E9BD7FB5C7CBF47FB@mike> <12539DE2-CAC3-4891-9B02-B146AECD3FB6@delong.com> <0D7208D7-EE99-46DE-8839-A388A6B13F14@delong.com> Message-ID: On Mon, May 2, 2011 at 9:05 PM, Owen DeLong wrote: >> >> >> Owen, >> >> Would you be in support of an open exchange if there were basic controls in place to lockout speculators? >> > Perhaps. I would need to feel that the controls were sufficiently adequate to prevent > speculation and certain other potential forms of abuse and I would feel that there > would have to be a preservation of the principles of stewardship including that > resources not be received by those without justified need. > > Owen > > Owen, I'm envisioning a compromise where these principles could be mostly maintained, while eliminating a lot of scrutiny that normally accompanies a resource request. For instance, we could give the buyer the option of justifying the space and paying a nominal fee (say $100/yr flat for all resources) or holding space without justification and paying substantially higher fees that would effectively negate any benefit of more than very short term speculation? Just brainstorming.. -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications - AS32421 First and Leading in DDoS Protection Solutions From owen at delong.com Mon May 2 21:41:31 2011 From: owen at delong.com (Owen DeLong) Date: Mon, 2 May 2011 18:41:31 -0700 Subject: [arin-ppml] Accusation of fundamental conflictofinterest/IPaddress policy pitched directly to ICANN In-Reply-To: <60F3C7B6BAA34A28B96EC6371A68D723@video> References: <7646B57F7F154B028E6722D103BB57C2@mike> <60F3C7B6BAA34A28B96EC6371A68D723@video> Message-ID: On May 2, 2011, at 4:45 PM, Mike Burns wrote: > >Not true. The chaos and disruption posed by unregulated registries will > >increase the costs to ARIN, ARIN members, and other participants in the > >industry regardless of whether they change registries or not. > >Owen > > This is an assertion unsupported by facts. What additional costs will be imposed on ARIN? ARIN will have to interact with and provide services to competing registries acting without regard to community derived policies. This will, by definition create costs. > True they would have to update a field in the whois database to point to the authoritative registry, sort of like the pointers to other RIRs in there now. The pointers to other RIRs are very static. The pointers to these competing registries would be very dynamic. That is a cost. > The letter to ICANN that began this thread included a set of regulations adopted from those used in the creation of private DNS registries. > Why do you keep insisting they would be unregulated? I consider the current DNS registries virtually unregulated and the system that has been created to be a haven for abuse, spammers, and all manner of monetization of degenerate behavior. The fact that you have chosen this fundamentally flawed model as your shining example of success is why I continue to refer to it as a recipe for failure. > Like the RIR's, like DNS Registries, all approved registries do answer to the community through adherence to those community-defined regulations. > The DNS registries do not answer to the community. They answer to a very narrow group of people motivated to make money out of creating additional TLDs as near as I can tell. Where is the community forum for DNS activity regarding gTLDs that provides an equivalent open forum to PPML and the ARIN Public Policy Meetings? > If you are concerned about groundup or community development, may I suggest revisiting Benson's proposals, which were an attempt to create the policy which would allow for the creation of alternate registries under ARIN policy, but which met with an untimely end based on John Curran's feelings that the decisions had to be made at a global level. Now the argument holds that at that global level decisions should be made by the same small group of individuals running the RIRs, basically. > Benson's proposals met with a timely end at the hands of the AC based on the facts of the situation and the judgment of the various members of the AC. While I cannot speak for the others, I can say that the reasons I voted to abandon Benson's proposals included: 1. If Benson wanted to bring global policy, the policies needed to be submitted as proposals for global policy and would need to be submitted to each of the 5 regions. The proposals submitted made no mention of global policy and did contain subject matter that would require global policy changes in order to alter the terms of ICP-2 regarding the formation of new registries for number resources. 2. I believe that competing registries are contrary to the community interest and represent bad policy. I have seen no evidence that having them would in any way improve registration services, whois accuracy, or any other aspect of internet number resource administration. 3. Benson's proposals did not receive significant support from the community on PPML and there was significant opposition to them from the community. Benson petitioned the proposals and was not able to get 10 people from 10 different organizations to support either of the petitions. If there is such wide community support for this idea as you seem to perceive, why were there not 10 people willing to step up and say so? > You are right in saying there are no policies about how domain names are justified or acquired in the rules which apply to DNS registries. I'm glad you recognize that domain names are unregulated. > That's as it should be, and there is a burgeoning set of case law and trademark law that serves to answer those questions. The burgeoning set of case law and trademark law is: 1. An example of how regulators will step in when we fail. 2. The result of our failure to maintain the separation between domain names and trademarks that should have been preserved from the early days of internet development. 3. The direct result of caving to the wishes of WIPO instead of first considering the best interests and desires of the wider internet community. > I put more trust in the collective brainpower of worldwide jurisprudence and centuries of commonlaw experience to decide these issues than a tiny cabal of individuals with a vested interest in maintaining their positions in the status quo. Let the DNS registries concentrate on uniqueness and adherence to law as it develops, let number registries concentrate on uniqueness and title. > You keep using terms like "tiny cabal of individals" to describe a process open literally to anyone who chooses to participate. I have tremendous difficulty understanding how you can equate those two and it makes it very difficult to carry on a meaningful discussion of the characteristics of the process when you insist on framing it that way. > I think we understand your position on free markets, I am trying to avoid discussions of analogies far afield from current topics, so suffice it to say I disagree that the instances you reference resulted from activities in free markets. > I'm all for free markets where they make sense. The distribution of number resources is not one of the places where that is true. If you have so much faith in the collective brainpower of worldwide jurisprudence and common law experience, then, you must realize that even the ITU and NANPA have justified need requirements for things like country codes and NPA numbers. These are examples of finite number resources being administered in a manner contrary to a free market and the recognition that free market administration would not serve the public interest in those cases. Why on earth would you consider the administration of IPv4 number resources to be significantly better served by a market? Owen > Regards, > > Mike > > > > > > > ----- Original Message ----- > From: Owen DeLong > To: Mike Burns > Cc: Alexander, Daniel ; arin-ppml at arin.net > Sent: Monday, May 02, 2011 6:48 PM > Subject: Re: [arin-ppml] Accusation of fundamental conflictofinterest/IPaddress policy pitched directly to ICANN > > > On May 2, 2011, at 1:41 PM, Mike Burns wrote: > >> Hi Dan, >> >> The existence of competing registries does not imply a requirement on anybody to change, so your argument about expense to existing participants is invalid. >> > Not true. The chaos and disruption posed by unregulated registries will > increase the costs to ARIN, ARIN members, and other participants in the > industry regardless of whether they change registries or not. > > > > >> And yes, the market will sort out bad actors. That's one thing free markets do. >> > Right... The market sorted out Enron... Eventually. However, non of us in > California got our money back and we're all still paying higher electric > bills as a result. > > The market sorted out the CMOs... Eventually. However, my house is now > worth 1/3rd of what it was worth and the new restrictive regulations on > refinancing prevent me from taking advantage of the new lower interest > rates due to my home being devalued too close to the amount I still owe > on it. Unfortunately, I wasn't irresponsible enough to be part of the cause > of this problem, so, as a good actor, I am not entitled to any of the relief > available from the government for the bad actors. > > I think I've had enough of the way markets sort out bad actors for a while. > >> Nobody said anything about no oversight, to the contrary I have said the registries should work under the same framework as RIRs. >> > The only oversight of the RIRs is their community processes and their > membership-elected boards. If you are OK with the other registries being > overseen by these same bodies, then, I'm not sure why you think they > would somehow be run differently from the existing RIRs. > >> Just like all DNS registrars have to comply with rules setup to govern their behavior. >> Before you can be a DNS registrar you have to comply with the rules, and maintain compliance. >> > There are virtually no policies about how domain names are justified or > acquired in those rules. There are provisions for trademark disputes, but, > those are not applicable to IP addresses (unless you think that a > particular soft drink vendor should be automatically entitled to > the address 67.79.75.69). > > Owen > >> It's true that I was being forward thinking about the additional services competing registries might offer, but my point is that those services would only be offered if there was a demand for them, if the private registries are to endure. >> >> >> Regards, >> >> Mike >> >> ----- Original Message ----- From: "Alexander, Daniel" >> To: "Mike Burns" ; >> Sent: Monday, May 02, 2011 4:30 PM >> Subject: Re: [arin-ppml] Accusation of fundamental conflictofinterest/IPaddress policy pitched directly to ICANN >> >> >> Mike, >> >> While I can only speak for myself, I can attempt to answer your question >> of what may perturb some people. You make several very large assumptions >> in your claims, none of which were captured in the opt-in, opt-out, or any >> other proposals. >> >> You speak of title insurance, legal teams, and other items, ensuring that >> a competitive registry will provide better services than a community >> defined RIR. The problem is none of this is defined or required in any >> suggested framework. While some may provide these services, many may not, >> and there are no mechanisms to protect the ISP's or end users who rely on >> these services. >> >> While many advocates will quickly reply that the market will sort these >> bad actors out, it will be done at the expense of the people who currently >> rely on these RIR provided services at a fraction of the cost. If >> competitive registries are created without oversight, the burden and >> expense of validating registration records will be shifted to the very >> people who are supposed to benefit from this new model. >> >> This begs the question from some as to what purpose a commercial registry >> would serve other than to make money. >> >> My opinion only. >> Dan Alexander >> >> >> >> >> On 5/2/11 3:33 PM, "Mike Burns" wrote: >> >>> >>> >>>> But what is it about ARIN that is broken? What exactly do you think >>>> needs >>>> to be fixed? >>> >>>> The only thing I've gotten out of the discussions so far is that some >>>> people think there is money to be made by providing IPv4 addresses based >>>> on >>>> willingness and ability to pay rather than ARIN's current >demonstrated >>>> need policies. >>> >>>> Why is it to my benefit if someone else makes money? Particularly if it >>>> perturbs the current mechanisms in a way that costs me money? >>> >>>> Keith Hare >>> >>> >>> Hi Keith, >>> >>> What is broken about ARIN is that scandalously large numbers of netblocks >>> do >>> not have valid POCs, for example. The stewardship of Whois leaves a lot >>> to >>> be desired. >>> Competitive pressures would help to finally decide who controls these >>> addresses and allow them to be transferred to those who would pay for >>> them. >>> Network operators don't really have much of a choice in accessing Whois >>> information to determine the rights to advertise addresses, and competive >>> registries. >>> In my experience they rely on attestation and review of proferred >>> chain-of-custody docs when determining who can advertise which addresses, >>> when confronted with inconsistencies with whois. >>> A competitive registry with a title insurance component will give network >>> operators more security when deciding questionable cases. >>> >>> What is broken about ARIN is that their transfer policies are more >>> restrictive than APNICs, and that will cause a flow of addresses out of >>> ARIN >>> and into APNIC. >>> A competitive registry could presumably have a different transfer policy, >>> as >>> APNICs differs from ARINs. >>> >>> What is broken about ARIN is that ARIN has professed no statutory control >>> over legacy addresses in the Plzak declaration in the Kremen case, and >>> yet >>> attempts to control the registration of legacy resources. >>> With a private registry, the address rights holders can choose to opt-out >>> of >>> ARIN's dictats and choose their registry voluntarily. >>> >>> I don't see how the creation of a private registry will perturb the >>> current >>> mechanisms in a way that costs you money, could you share why you feel >>> that >>> way? >>> >>> Regards, >>> >>> Mike Burns >>> >>> _______________________________________________ >>> 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 owen at delong.com Mon May 2 21:56:32 2011 From: owen at delong.com (Owen DeLong) Date: Mon, 2 May 2011 18:56:32 -0700 Subject: [arin-ppml] ARIN-prop-146 Clarify Justified Need for Transfers In-Reply-To: <6BA1EAA6-7D9C-44F9-BED7-884720F4B3BE@matthew.at> References: <4DBEF120.4080901@arin.net> <88F39B20-5C20-45F0-AD61-5FA1E7F84CE3@delong.com> <3FCD1FDC-ECEE-4C9B-95C6-59E03D3C314E@matthew.at> <5598DFC7-E320-42FA-AA0E-C91C076BD725@delong.com> <6BA1EAA6-7D9C-44F9-BED7-884720F4B3BE@matthew.at> Message-ID: <05FAA29B-37BE-411C-95A4-50437602C8ED@delong.com> On May 2, 2011, at 5:05 PM, Matthew Kaufman wrote: > > On May 2, 2011, at 4:29 PM, Owen DeLong wrote: > >> >> On May 2, 2011, at 2:51 PM, Matthew Kaufman wrote: >> >>> >>> On May 2, 2011, at 2:42 PM, Owen DeLong wrote: >>>> there is no reason >>>> to treat transfers differently from initial allocations and assignments. >>> >>> Fundamentally disagree. Policy for handing out the last of the free pool of IPv4 (which has already become much MORE restrictive, now that we are subject to the "last /8" policies) should be different than policy for approving transfer recipients. There is no reason to believe, for instance, that we are in the "last /8" of transfers. And no new entrant post-runout will spend the time and money attempting to acquire only what they can justify for a 3-month period. >>> >>> Matthew Kaufman >> >> The three month restriction is a temporary abomination in the IPv4 policies related to runout. >> >> The rest of the policy is not specially restrictive related to runout. >> >> That temporary abomination is specifically exempted in 8.3, so, you already have exactly what >> you have stated is needed above. > > No it isn't. Section 8.3 has NO language exempting itself from the 3 month rule. That's what I hear on the list, but I looked it up, and it isn't there. That's how I ended up writing this proposal, after all. > > The only exemption is in 4.2.4.4. That exemption ONLY works if you are not getting an initial assignment through transfer (a likely scenario for new orgs post-runout) AND you are not a new member who only recently got their initial 3 month supply (where you'd be restricted to using transfer in 3-month increments for the first year in order to grow). > The only 3 month rule is section 4.2.4.4, so, I'm not sure why you think this needs to be fixed in 8.3 instead of 4.2.4.4. > AND there's other bugs in that 4.2.2.1.1 and 4.2.2.1.3 and 4.2.2.2 (at the very least) call out specific block sizes that might be *smaller* than the block you're trying to qualify under transfer. > Those call out the minimums you must justify, so, again, I don't see that as a bug. > I hate to say it, but... did you actually *read* my policy proposal text? > Yes... Did you actually understand the NRPM you were trying to modify? Either I'm not understanding the change you are attempting to make (it seems you're just trying to eliminate the shortening of justification for 8.3 transfers to 3 months which, as I said, didn't happen anyway), or, you're trying to radically rewrite the justification for transfers. In the former case, you're attempting a policy no-op and I'm not in favor of policy churn for the sake of churn. In the latter case, I don't see the benefit to your proposal. The three-month provision for runout is strictly embodied in 4.2.4.4. It does not trigger for anything other than an ISP additional allocation request and it exempts an ISP acquiring their additional allocation through transfer from that 3-momth shortening. The other 3-month language has been in policy for a long time and does not relate specifically to runout. It provides the requirements for a new entrant to create a justification to obtain addresses and I support the preservation of those requirements into the transfer regime as I think they have been and remain reasonable minimums. >> >> There is no need for a policy change. > > There clearly is, IF you run through each and every one of the paths in section 4 and see which ones 4.2.4.4 triggers for, and more important, which ones it *doesn't* trigger for. > I can't say for certain that I have followed EVERY path, but, I have followed the ones which I am aware of and they seem to result in what I consider to be the desired outcome. > If you qualify for an 8.3 transfer there is NO reason that transfer should fall under the 3-month rules, which right now, in many cases, it does... without a change like the one I have proposed. > Please cite such a case because as it currently stands, I don't believe that to be accurate. Owen > Matthew Kaufman From owen at delong.com Mon May 2 21:59:03 2011 From: owen at delong.com (Owen DeLong) Date: Mon, 2 May 2011 18:59:03 -0700 Subject: [arin-ppml] Statistics regarding NRPM 8.3 Transfers to date In-Reply-To: <79A82F38-A2BE-4F9E-851D-4286E0C7CD57@matthew.at> References: <75E9BD24-F12F-42BF-A989-CF6CC282B28E@arin.net> <7406316661701612155@unknownmsgid> <3F57F52B-F1F1-4450-B493-AA4D544D8D15@arin.net> <8740380157159276993@unknownmsgid> <49E26DCB-DAF7-4A0A-912E-F981494979F5@delong.com> <4DBC2AEB.9040307@matthew.at> <4DBCA58D.4060704@sprunk.org> <2344ADD7-616E-4FA7-9552-19735926A952@delong.com> <4DBD9BF5.7050002@sprunk.org> <4DBF2724.6090300@sprunk.org> <79A82F38-A2BE-4F9E-851D-4286E0C7CD57@matthew.at> Message-ID: <3431DD64-86DF-4EE0-B0FE-75135D277F4B@delong.com> On May 2, 2011, at 5:07 PM, Matthew Kaufman wrote: > > On May 2, 2011, at 4:33 PM, Owen DeLong wrote: > >> >> Heaven help the internet if we ever get to a point where /24s are no longer accepted. The number >> of organizations that would be immediately disenfranchised by such a move would be >> devastating. > > Unless of course the people running ISPs were smart enough to figure out how to allow old /24s and not allow new /24s using some sort of well-maintained database... or otherwise apply market pressure against people trying to break up large blocks into many small blocks. > > Matthew Kaufman Given the abilities demonstrated by many of the ISPs I've subscribed to or had to accept service from, my confidence in this meaningfully happening is, well, very low. Owen From owen at delong.com Mon May 2 22:04:14 2011 From: owen at delong.com (Owen DeLong) Date: Mon, 2 May 2011 19:04:14 -0700 Subject: [arin-ppml] ARIN-prop-147 Set Transfer Need to 24 months and Clarify Exception In-Reply-To: <2A17CD60-39D2-4784-AAB5-445735FA6143@matthew.at> References: <4DBEF12A.2020002@arin.net> <03F0539F-6F62-49CD-84F8-9ABC62095596@delong.com> <69160560-5FF3-4CEE-B688-84CCB6AD2426@matthew.at> <2A17CD60-39D2-4784-AAB5-445735FA6143@matthew.at> Message-ID: <4E20C3B2-2444-4DCD-A580-AEF84F3C96B6@delong.com> On May 2, 2011, at 5:13 PM, Matthew Kaufman wrote: > > On May 2, 2011, at 4:39 PM, Owen DeLong wrote: > > >>> If they are to re-qualify, it doesn't make sense that they be forced to justify only a 3-month supply simply because the free pool is low or empty. >>> >> I disagree. > ... >> Again, I don't think that we need to support that through policy. IPv4 is reaching its >> end of life. There is a need to help some organizations limp along with it through >> transfers while it is deprecated, but, seeking to create new businesses based on >> IPv4 construction over the next 2 years is not something I favor encouraging or >> facilitating through policy. > > > ANY new entity which is built through acquisition of something that exists today will need to serve customers on the IPv4 Internet for at least 2 years. Even if they are fortunate enough to grow. > > You are arguing that because Facebook has enough IPv4 space to last for another year or two, a new upstart shouldn't be able to use VC money and the transfer market to obtain an existing entity with enough IPv4 space to compete against Facebook on the IPv4 Internet for a year... you'd rather force them into getting only enough for 3 months and then crossing their fingers in hope that another 3 month supply will be available... all because the ARIN free pool ran out?!? > Not at all. If they obtain the entity through a section 8.2 transfer, more power to them. If they are using 8.3 to obtain only the addresses, that is a different story. Owen From bill at herrin.us Mon May 2 22:08:33 2011 From: bill at herrin.us (William Herrin) Date: Mon, 2 May 2011 22:08:33 -0400 Subject: [arin-ppml] Fw: Accusation of fundamental conflict ofinterest/IPaddress policy pitched directly to ICANN In-Reply-To: References: Message-ID: On Mon, May 2, 2011 at 8:43 PM, Mike Burns wrote: > No, I want the question of whether to allow competitive non-regional > registries to be decided by an entity other than one composed of > non-competitive regional registries who currently enjoy a monopoly on > registration services. > > There is a conflict of interest there. Let the venue be moved to a higher > level. Mike, The higher level in the authority chain is the community itself (i.e. the folks who participate on lists like this one in each of the regions and at the IETF). ICANN is subservient to the RIRs with respect to addressing, i.e. a lower level in the food chain. In other words, metaphorically speaking you'll have to take this one to the voters. 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 2 22:08:17 2011 From: owen at delong.com (Owen DeLong) Date: Mon, 2 May 2011 19:08:17 -0700 Subject: [arin-ppml] ARIN-prop-140 Business Failure Clarification In-Reply-To: References: <4DBEF0DF.8060800@arin.net> <9BC4E3EC-E693-44D9-A415-A9E0F97E1BAA@matthew.at> <00A60C73-0282-416A-BBF1-D491ADDD18EE@delong.com> <7B10B708-B9B5-4655-A467-4BE74E555EF2@delong.com> Message-ID: <6673AFEC-4125-4F71-AE90-3D5CDE0F152F@delong.com> On May 2, 2011, at 5:16 PM, Matthew Kaufman wrote: > > On May 2, 2011, at 4:47 PM, Owen DeLong wrote: > >> >> On May 2, 2011, at 3:40 PM, Matthew Kaufman wrote: >> >>> >>> On May 2, 2011, at 3:34 PM, Owen DeLong wrote: >>>> >>>> I was the POC for an organization which failed. When I was informed that >>>> my job was being terminated and the company liquidated, the network >>>> being shut down, etc. I notified ARIN and the addresses and AS Numbers >>>> were reclaimed. >>> >>> If you notified ARIN after your date/time of termination, you were probably acting outside of your authority. >>> >> I notified ARIN that the business was being liquidated and that the network >> had been shut down. I did not tell ARIN to reclaim the addresses (though I >> expressed a belief that policy might support reclamation). >> >> As such, I was not acting in or out of authority. I was conveying information. >> The information was a matter of public record and so not subject to NDA. >> >>> And these days, if you notified ARIN before talking to your management about the possibility of transferring the addresses in order to pay creditors during the liquidation you wouldn't be upholding your fiduciary responsibility to your employer. >>> >> If I did so while I had a fiduciary responsibility, perhaps. However, once >> terminated, I had no such fiduciary responsibility. > > Once terminated you didn't have the authority to report it to ARIN *as the POC* either... you're just another random citizen. > I disagree. I had the obligation to report it to ARIN as the listed POC. I did so as part of my request that ARIN terminate my POC status for any records that remained so that ARIN did not incorrectly assume I was still a POC for the organization. Since I was the only listed POC for the organization, the result was an organization (and resource records) with no POCs. > Hopefully you made it clear to ARIN that you were no longer an authorized POC when you made the assertion that the business was being liquidated and the network shut down. > I made it clear to ARIN that I was no longer employed and that my POC handle should be removed from any remaining records for the organization. I believe that is in line with the intent of your statement. >> >> we can agree to disagree. > > Or not. Perhaps. I can't tell at this time whether we agree or not. Owen -------------- next part -------------- An HTML attachment was scrubbed... URL: From farmer at umn.edu Mon May 2 22:14:23 2011 From: farmer at umn.edu (David Farmer) Date: Mon, 02 May 2011 21:14:23 -0500 Subject: [arin-ppml] ARIN-prop-146 Clarify Justified Need for Transfers In-Reply-To: <4DBEF120.4080901@arin.net> References: <4DBEF120.4080901@arin.net> Message-ID: <4DBF64FF.6070604@umn.edu> On 5/2/11 13:00 CDT, ARIN wrote: > ARIN-prop-146 Clarify Justified Need for Transfers > > Proposal Originator: Matthew Kaufman > > Proposal Version: 1 > > Date: 2 May 2011 > > Proposal type: new > > Policy term: permanent > > Policy statement: > > Add a subsection to Section 8 (Transfers) of the NRPM: > > "Justified Need" for resources associated with a transfer shall be > determined using the "4.2.4 ISP Additional Requests" criteria applied as > though the recipient has been a subscriber member of ARIN for at least > one year (whether or not that is the case). Do you indent to eliminate the ability for end users to be the recipient of transfers? You seem to be doing that. Would you please state your intended result for this policy in plain English, because I'm confused as to your intended outcome. Like; "All ISP should be able to get a 12month supply" for example, if that is your intended outcome. > Rationale: > > An organization which is not able to obtain its initial IPv4 address > assignment from ARIN post-runout would otherwise be limited to > purchasing only a 3-month supply (because the language in 4.2.4.4 > regarding 8.3 transfers is not triggered). > > An organization which has only recently received its first allocation > under the "last /8" criteria is also otherwise limited to purchasing > only a 3-month supply (because the language in 4.2.4.4 is again not > applicable). > > There is also ambiguity if 4.2.2.1.3 is applied in that a transfer to > a new organization might only need to show need for a /20 (because that > is what is specifically called out) even though they are receiving a > much larger block. > > There is also ambiguity with regard to transfers under 8.2 where the > receiving organization is a new organization... not at all clear how > "justified need" has been or should be determined. > > 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. -- =============================================== 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 matthew at matthew.at Mon May 2 22:23:35 2011 From: matthew at matthew.at (Matthew Kaufman) Date: Mon, 02 May 2011 19:23:35 -0700 Subject: [arin-ppml] ARIN-prop-146 Clarify Justified Need for Transfers In-Reply-To: <05FAA29B-37BE-411C-95A4-50437602C8ED@delong.com> References: <4DBEF120.4080901@arin.net> <88F39B20-5C20-45F0-AD61-5FA1E7F84CE3@delong.com> <3FCD1FDC-ECEE-4C9B-95C6-59E03D3C314E@matthew.at> <5598DFC7-E320-42FA-AA0E-C91C076BD725@delong.com> <6BA1EAA6-7D9C-44F9-BED7-884720F4B3BE@matthew.at> <05FAA29B-37BE-411C-95A4-50437602C8ED@delong.com> Message-ID: <4DBF6727.1090303@matthew.at> On 5/2/2011 6:56 PM, Owen DeLong wrote: > On May 2, 2011, at 5:05 PM, Matthew Kaufman wrote: > >> If you qualify for an 8.3 transfer there is NO reason that transfer should fall under the 3-month rules, which right now, in many cases, it does... without a change like the one I have proposed. >> > Please cite such a case because as it currently stands, I don't believe that to be > accurate. > A. My hypothetical ISP provides service to a small town. I presently get two /24s of IPv4 space from my upstream provider and I'm using them at about 85%. ARIN has run completely out of addresses. A benefactor arrives and offers to transfer a /22 to me and pay for me to multihome. I attempt to use 4.2.2.2 (Initial Allocation to ISPs, Multihomed) for my justification. I need to demonstrate that I am efficiently using the two /24s. Done. I comply with 4.2.2.2.1 (SWIP). I attempt to comply with 4.2.2.2.2, but my growth shows that I won't really need more than a /23 for about 7 months. Transfer would be denied because 4.2.2.2.2 has a three month rule (as I claimed above). Benefactor takes his space elsewhere, and I lose out. B. My hypothetical ISP provides service to a single data center. I presently have a /20 that I was able to obtain from ARIN a few months ago, and I wasn't an ARIN subscriber member prior to this. I have the opportunity to acquire another ISP in town which has a /20 of its own, but which it isn't using very well because their growth plans failed after I opened up. I can demonstrate that my /20 and the second /20 from the acquisition would be filled within a year if I complete this transfer under section 8.2, but I'll only be able to fill out my existing /20 over the next three months. However, because I am under 4.2.4.3 (Subscriber Members Less Than One Year) my 8.2 transfer is denied, again because 4.2.4.3 has a three month rule (as I claimed above). on the flip side... C. My hypothetical ISP provides service to a small city that is served by only one transit provider, so I cannot multihome. It has been using a /20 from the upstream ISP and is efficiently using 16 /24s worth of space with reassignment documentation (satisfying 4.2.2.1.1 and 4.2.2.1.2). I provide detailed information showing that I can use a /20 within the next three months (satisfying 4.2.2.1.3). Now that I have met all the tests, I complete a section 8.3 transfer for a /14 worth of space (because I have loads of money I won in the lottery). As far as I can tell, there's nothing in the NRPM that blocks that transfer... because I've met all the tests in 4.2.2.1. Matthew Kaufman From matthew at matthew.at Mon May 2 22:30:28 2011 From: matthew at matthew.at (Matthew Kaufman) Date: Mon, 02 May 2011 19:30:28 -0700 Subject: [arin-ppml] ARIN-prop-146 Clarify Justified Need for Transfers In-Reply-To: <4DBF64FF.6070604@umn.edu> References: <4DBEF120.4080901@arin.net> <4DBF64FF.6070604@umn.edu> Message-ID: <4DBF68C4.7050501@matthew.at> On 5/2/2011 7:14 PM, David Farmer wrote: > > > On 5/2/11 13:00 CDT, ARIN wrote: > >> ARIN-prop-146 Clarify Justified Need for Transfers >> >> Proposal Originator: Matthew Kaufman >> >> Proposal Version: 1 >> >> Date: 2 May 2011 >> >> Proposal type: new >> >> Policy term: permanent >> >> Policy statement: >> >> Add a subsection to Section 8 (Transfers) of the NRPM: >> >> "Justified Need" for resources associated with a transfer shall be >> determined using the "4.2.4 ISP Additional Requests" criteria applied as >> though the recipient has been a subscriber member of ARIN for at least >> one year (whether or not that is the case). > > Do you indent to eliminate the ability for end users to be the > recipient of transfers? You seem to be doing that. > > Would you please state your intended result for this policy in plain > English, because I'm confused as to your intended outcome. > > Like; "All ISP should be able to get a 12month supply" for example, if > that is your intended outcome. "Any transfer recipient should be able to get a 12 month supply for an 8.2 or 8.3 transfer as long as they justify it as well as an ISP had to justify additional space back in the old days" Matthew Kaufman From matthew at matthew.at Mon May 2 22:32:29 2011 From: matthew at matthew.at (Matthew Kaufman) Date: Mon, 02 May 2011 19:32:29 -0700 Subject: [arin-ppml] Statistics regarding NRPM 8.3 Transfers to date In-Reply-To: <3431DD64-86DF-4EE0-B0FE-75135D277F4B@delong.com> References: <75E9BD24-F12F-42BF-A989-CF6CC282B28E@arin.net> <7406316661701612155@unknownmsgid> <3F57F52B-F1F1-4450-B493-AA4D544D8D15@arin.net> <8740380157159276993@unknownmsgid> <49E26DCB-DAF7-4A0A-912E-F981494979F5@delong.com> <4DBC2AEB.9040307@matthew.at> <4DBCA58D.4060704@sprunk.org> <2344ADD7-616E-4FA7-9552-19735926A952@delong.com> <4DBD9BF5.7050002@sprunk.org> <4DBF2724.6090300@sprunk.org> <79A82F38-A2BE-4F9E-851D-4286E0C7CD57@matthew.at> <3431DD64-86DF-4EE0-B0FE-75135D277F4B@delong.com> Message-ID: <4DBF693D.7010206@matthew.at> On 5/2/2011 6:59 PM, Owen DeLong wrote: > On May 2, 2011, at 5:07 PM, Matthew Kaufman wrote: > >> On May 2, 2011, at 4:33 PM, Owen DeLong wrote: >> >>> Heaven help the internet if we ever get to a point where /24s are no longer accepted. The number >>> of organizations that would be immediately disenfranchised by such a move would be >>> devastating. >> Unless of course the people running ISPs were smart enough to figure out how to allow old /24s and not allow new /24s using some sort of well-maintained database... or otherwise apply market pressure against people trying to break up large blocks into many small blocks. >> >> Matthew Kaufman > Given the abilities demonstrated by many of the ISPs I've subscribed to or had to accept > service from, my confidence in this meaningfully happening is, well, very low. > Then they'll be the ones who run out of BGP table space and have their routers crash. The ones who want their routers to stay up will improve their practices. Matthew Kaufman ps. Most of the ISPs you don't have confidence in *also* don't have IPv6 support yet either From matthew at matthew.at Mon May 2 22:33:54 2011 From: matthew at matthew.at (Matthew Kaufman) Date: Mon, 02 May 2011 19:33:54 -0700 Subject: [arin-ppml] ARIN-prop-147 Set Transfer Need to 24 months and Clarify Exception In-Reply-To: <4E20C3B2-2444-4DCD-A580-AEF84F3C96B6@delong.com> References: <4DBEF12A.2020002@arin.net> <03F0539F-6F62-49CD-84F8-9ABC62095596@delong.com> <69160560-5FF3-4CEE-B688-84CCB6AD2426@matthew.at> <2A17CD60-39D2-4784-AAB5-445735FA6143@matthew.at> <4E20C3B2-2444-4DCD-A580-AEF84F3C96B6@delong.com> Message-ID: <4DBF6992.5050403@matthew.at> On 5/2/2011 7:04 PM, Owen DeLong wrote: > On May 2, 2011, at 5:13 PM, Matthew Kaufman wrote: > >> On May 2, 2011, at 4:39 PM, Owen DeLong wrote: >> >> >>>> If they are to re-qualify, it doesn't make sense that they be forced to justify only a 3-month supply simply because the free pool is low or empty. >>>> >>> I disagree. >> ... >>> Again, I don't think that we need to support that through policy. IPv4 is reaching its >>> end of life. There is a need to help some organizations limp along with it through >>> transfers while it is deprecated, but, seeking to create new businesses based on >>> IPv4 construction over the next 2 years is not something I favor encouraging or >>> facilitating through policy. >> >> ANY new entity which is built through acquisition of something that exists today will need to serve customers on the IPv4 Internet for at least 2 years. Even if they are fortunate enough to grow. >> >> You are arguing that because Facebook has enough IPv4 space to last for another year or two, a new upstart shouldn't be able to use VC money and the transfer market to obtain an existing entity with enough IPv4 space to compete against Facebook on the IPv4 Internet for a year... you'd rather force them into getting only enough for 3 months and then crossing their fingers in hope that another 3 month supply will be available... all because the ARIN free pool ran out?!? >> > Not at all. If they obtain the entity through a section 8.2 transfer, more power to them. But if the existing entity wasn't using the space efficiently, they'll lose it unless they re-qualify... which is also under the "3-month" rule at present. > If they are using 8.3 to obtain only the addresses, that is a different story. > Why should that be? And doesn't this just mean that there wouldn't be 8.3 transfers, just 8.2 transfers using sham organizations that exist soley to hold the transferred space? Matthew Kaufman From owen at delong.com Mon May 2 22:39:35 2011 From: owen at delong.com (Owen DeLong) Date: Mon, 2 May 2011 19:39:35 -0700 Subject: [arin-ppml] Accusation of fundamental conflict ofinterest/IPaddress policy pitched directly to ICANN In-Reply-To: <01BF0F04DB434A38AD49E9D5F3F1E951@video> References: <4DBB208B.4060808@ipinc.net><23B533DB44354E3EA201D0941C47C46C@video><274D7568A828485B91D64F9308B3A24E@video><9737f78a74367c4fde16e526d31442304dbec379@jcc.com><40d2346a1b58436fb0387d165b0c7bee4dbed64a@jcc.com><34A035C8AB3147919076CC4BB118C83B@mike><03bbb072c4565685fb86a50e59d5178b4dbefc1f@jcc.com><35F0C71BD6974F21A3C296005F0DDA0F@mike> <01BF0F04DB434A38AD49E9D5F3F1E951@video> Message-ID: On May 2, 2011, at 5:25 PM, Mike Burns wrote: > Hi Jonathan, answers inline. > > >What is broken about ARIN is that scandalously large numbers of netblocks do not have valid POCs, for example. The stewardship of Whois leaves a lot to be desired. > > >What steps would a commercial entity take to resolve this that RIRs cannot? > > A commercial entity could recognize justification-free legacy transfers, and many legacy transfers happened but were not reflected in Whois because of this. This assumes that the recording and legitimization of such transfers is in the community interest. I would argue that the identification and reclamation of these blocks is the more appropriate action. > Not that the RIRs cannot do this, but they have not. It could well be that changing conditions will cause a realization of the legal realities of these transfers, and induce an RIR community to change policy to turn that registry into a title agency, reviewing evidence of property transfers without reference to the need to transfer networks or customers, or justify a need. > They have not because community consensus has been that they should not (except in the APNIC region). > > >Competitive pressures would help to finally decide who controls these addresses and allow them to be transferred to those who would pay for them. > >Leaving other equally "worthy" entities with less money unable to acquire space despite their need? > > I meant competitive pressures between registries, but sure, poor entities couldn't afford expensive IP addresses. > Today, this is not an issue as the RIRs operated as non-proffit organizations do not charge excessive fees. There are entities that cannot afford addresses even under the current situation (I'm involved in some), but, generally speaking, the current scope of that issue is much smaller than it will become under a competitive for-profit structure. > >Network operators don't really have much of a choice in accessing Whois information to determine the rights to advertise addresses, and competive registries. > >I'd argue that network operators are the very ones who give the RIR their "power." I also don't see why you seem to claim that they can't? Tell me, what's stopping them from using whatever registry they want? > > I couldn't agree more. I don't think there really is anything stopping them from using whatever registry they want. I think they have slim pickings in registries now, and use what they have, but they don't trust it unilaterally. If a registry comes along that offers network operators some insurance against conflict or abuse claims, my bet is they would avail themselves of it rather than turn down business. > There is nothing preventing a business from attempting to offer those services today. They cannot coordinate their registrations with the existing RIR system, but, they can offer those services. If they can attract enough of the internet, then the RIR system would, de facto, become irrelevant. > >What is broken about ARIN is that their transfer policies are more restrictive than APNICs, and that will cause a flow of addresses out of ARIN and into APNIC. > >Could you explain why you think this? > > All else being equal, I believe buyers and sellers will migrate towards the freer market. The justification is like a transaction cost. Transactions will go to where the cost is lowest. > There is no current possibility for addresses to flow out of ARIN to APNIC as there is no policy supporting such a transfer. Even the APNIC transfer policy only supports transfers within the APNIC region. Any transfer of addresses administered by ARIN would require the consent of ARIN. There is currently no policy to support ARIN giving said consent. The less restrictive policy allows APNIC to make a mess of their own address space, but, it does not allow the world to migrate from the other registries with policies more consistent with proper stewardship and the goals expressed in RFC-2050 to the less restrictive policy regime in APNIC. > > >Not to speak for him but you did say " Competitive pressures would help to finally decide who controls these addresses and allow them to be transferred to those who would pay for them." > > >Were you not suggesting that the folks with the most money would be the ones who got address space registered to their name and the others would be out in the rain? > > >Let me know if I misunderstood. > > Yes, you misunderstood, I was talking about competitive pressures between registries. If a registry becomes freer, like APNIC did, it puts competitive pressures on the other registries to free their markets up, that's what I was trying to say. Sorry if I was unclear. But yes, eventually it will cost money to get IP addresses. I guess the richer you are, the more easy it will be to acquire addresses in the post-exhaust world. I don't see any honest way around this, but at least this will serve to free up huge swaths of address space currently on the sideline. Wouldn't this buy some time to finally get that orderly V6 transition in motion? It wasn't what he intended, but, it is also the inevitable result of what he is proposing. Under the current system, the community in each region (where community is literally defined as anyone in the world who has an email address and chooses to participate) can define policies for that region with limited risk of requests for address resources being "policy shopped" to the most favorable registry. What Mike is proposing is that the theoretical race to the bottom in terms of market pressure creating the least restrictive possible set of policy in favor of "sell 'em all, let the almighty currency sort them out" approach to address distribution would somehow be in the best interests of the community. Owen -------------- next part -------------- An HTML attachment was scrubbed... URL: From owen at delong.com Mon May 2 22:46:44 2011 From: owen at delong.com (Owen DeLong) Date: Mon, 2 May 2011 19:46:44 -0700 Subject: [arin-ppml] Fw: Accusation of fundamental conflict ofinterest/IPaddress policy pitched directly to ICANN In-Reply-To: References: Message-ID: <554D2486-3541-4A8B-ABBF-686A76A6436B@delong.com> On May 2, 2011, at 5:43 PM, Mike Burns wrote: > No, I want the question of whether to allow competitive non-regional registries to be decided by an entity other than one composed of non-competitive regional registries who currently enjoy a monopoly on registration services. > You are in luck. The non-competitive regional registries do not actually do much in the policy process that governs them. Mostly the policies are proposed by and evaluated by the communities (defined as anyone who wants to participate, has an email address, and bothers to show up or participate in the mailing lists), then, managed by the appropriate bodies. In the case of ARIN, this would be the ARIN Advisory Council, which, is not ARIN or even ARIN employees who are specifically precluded from running for or obtaining office. The Advisory Council is elected by the members of ARIN, but, membership in ARIN consists of the union of all ISP Subscriber members (all who hold ISP resource allocations) and all other resource recipients who have elected to join ARIN and paid a $500 annual membership fee. > There is a conflict of interest there. Let the venue be moved to a higher level. > And again, I say there is no higher level to move the venue to. Owen > Regards, > > Mike > > ----- Original Message ----- From: "Owen DeLong" > To: "Mike Burns" > Cc: "McTim" ; > Sent: Monday, May 02, 2011 6:28 PM > Subject: Re: [arin-ppml] Fw: Accusation of fundamental conflict ofinterest/IPaddress policy pitched directly to ICANN > > > So your argument boils down to: > > I don't like who the communities elected, so, I want to shop for a different forum? > > Owen > > On May 2, 2011, at 1:13 PM, Mike Burns wrote: > >> Hi Tim, >> >> Just read the names of the committe members. >> Enough said. >> >> Regards, >> Mike >> >> ----- Original Message ----- From: "McTim" >> To: "Mike Burns" >> Cc: >> Sent: Monday, May 02, 2011 4:06 PM >> Subject: Re: Fw: [arin-ppml] Accusation of fundamental conflict ofinterest/IPaddress policy pitched directly to ICANN >> >> >> On Mon, May 2, 2011 at 7:48 PM, Mike Burns wrote: >>>> Can you be more specific? The ICANN ASO? the ICANN BoT? the IANA? >>> >>> Hi Tim, >>> >>> Keep going, all the organizations above are suspect due to the fact that >>> they are all comprised of the same basic group of RIR designees. >> >> The RIRs do not "designate" or appoint anyone to any of the above >> bodies. The ASO AC members are elected by their respective RIR >> communities. Those ASO AC members do have a role to play in choosing >> 2 (IIRC) of the ICANN Board. Neither the RIRs nor the ASO get to >> choose IANA staff. >> >>> >>> I would take it to NTIA like DNS. >> >> I think you overestimate the role of the NTIA in the DNS. >> >>> >>> And I would use DNS as a template for the creation of the global policy >>> restrictions John Curran asked about, which restrictions would apply to all >>> registries, regional or commercial. >>> Just as all DNS registrars must meet certain qualifications, so would >>> private registries of number space. >>> >>> Let the NTIA hear arguments from the proposer and from the ASO, the ICANN >>> BoT, and IANA, although I suspect they will all sound the same. >> >> >> Back in the 1990's, the idea was for the USG to divest itself (via >> ICANN) of the naming and numbering roles. That process is still >> ongoing, and one can see a certain acceleration of divestiture in >> recent years. The Affirmation of Commitments is, I think, an example >> of this. >> >> As DF has indicated, this (asking the NTIA to make this kind of >> determination) would be a real non-starter for the global Internet >> Governance community. >> >> -- >> Cheers, >> >> McTim >> "A name indicates what we seek. An address indicates where it is. A >> route indicates how we get there." Jon Postel >> _______________________________________________ >> 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 2 22:49:43 2011 From: owen at delong.com (Owen DeLong) Date: Mon, 2 May 2011 19:49:43 -0700 Subject: [arin-ppml] Analogies In-Reply-To: References: <39209.1303885464@tristatelogic.com> <75822E125BCB994F8446858C4B19F0D7173057C827@SUEX07-MBX-04.ad.syr.edu> <471D76419F9EF642962323D13DF1DF69011E5C@newserver.arneill-py.local> <7348D3C8-4EB7-4440-A152-210CC8B0DA3C@arin.net> <471D76419F9EF642962323D13DF1DF69011E60@newserver.arneill-py.local> <583A067A-B8AE-4026-844E-6769D1D7CF88@arin.net> <471D76419F9EF642962323D13DF1DF69011E61@newserver.arneill-py.local> <7DF2A1C4-1799-486B-A631-2E1119C22A7C@arin.net> <3CCC6D1F-11F4-40BC-B102-CC6744A5E709@virtualized.org> <4DB9BACE.6000307@ipinc.net> <0E134D8B-0A4B-466E-B261-9C7D0ED11867@virtualized.org> <388190E3-08F2-4AC7-870A-621A2FD6EEFE@virtualized.org> <2ABCF380-7866-4ED8-BE43-C789CBEBFE27@delong.com> <8D07F7F5-7E60-4176-A5D3-929F160AC608@arin.net> Message-ID: On May 2, 2011, at 5:46 PM, Jimmy Hess wrote: > On Mon, May 2, 2011 at 6:43 PM, William Herrin wrote: >> On Mon, May 2, 2011 at 7:13 PM, John Curran wrote: >>> On May 3, 2011, at 12:47 AM, William Herrin wrote: > >> "Any network found to host photoshopped pornography of Republican >> political candidates is subject to having its number resources >> revoked." > > ARIN probably needs to surrender the ability to revoke IP addresses > based on censorship grounds back to the community, by putting a clause > in the RSA restricting ARIN from revoking resources for that reason, > if it even has > maintained such an ability, so a policy cannot ever revoke resources > for the purpose of targetting content served by hosts using an IP address. > ARIN has never maintained such an ability and policy does not support any creation of such an ability, at least in my interpretation of the current policy. If the community somehow came to consensus in favor of such a policy, the AC and the Board would still have to judge it to be technically sound good policy. I think that is very unlikely. > ARIN is concerned with stewardship of resources, and management > of what content or traffic can be exchanged by hosts assigned those resources, > is, and should be out of the scope of IP addressing and DNS policy. > Agreed. > That type of policy simply should not be allowed, even if the community finds > certain activity hosts using IP or DNS resources can perform to be abhorrent. > Let's be somewhat careful here. Are you saying that we should protect the rights of snowshoe spammers to obtain vast quantities of resources, for example? > > Any censorship can be determined by the network service providers exchanging > the data, and by the relevant jurisdictions the hosts reside in; > there is no need > for ARIN to intervene there. > Mostly I agree. > > Would the community actually adopt a policy like that? No... > How about > > "Any network found to be harboring spammers or hackers, will have its > number resources revoked and automatically become ineligible > to receive any additional resources in the future. > > Consistent existence of listing by a recognized public DNS RBL > of any assigned IP address, for a period of 24 hours or longer, > will result in a single warning; if not corrected, all resources will > be temporarily revoked after 7 days. > > If the IP address is not found in good standing with the RBL > within 21 days, revokation becomes permanent. > " > > That's probably something more likely to be proposed seriously > If such a policy were to pass, do you think that legacy resources should somehow be exempted from it? Owen -------------- next part -------------- An HTML attachment was scrubbed... URL: From owen at delong.com Mon May 2 22:57:04 2011 From: owen at delong.com (Owen DeLong) Date: Mon, 2 May 2011 19:57:04 -0700 Subject: [arin-ppml] NRPN 8.2 & 2.3 In-Reply-To: <1E021BD750354DE1B55F36FF0D967ED4@video> References: <61CEAA1048BE416 E9BD7FB5C7CBF47FB@mike><12539DE2-CAC3-4891-9B02-B146AECD3FB6@delong.com> <1E021BD750354DE1B55F36FF0D967ED4@video> Message-ID: On May 2, 2011, at 5:56 PM, Mike Burns wrote: > > >Owen, > > >Would you be in support of an open exchange if there were basic controls in place to lockout speculators? > >Jeffrey Lyon, Leadership Team > Jeff, > > I would think that Owen would support speculation, as given the inevitable transition to IPv6, hoarders and speculators will take it in the shorts, plus driving up the price will drive us towards IPV6 even faster. Some inherent limits on speculation in this market... > This is where you fail to understand Owen. I agree that speculators would, indeed, advance several goals in line with my own interest. However, I was not elected to the AC to serve my own interests and I do not participate in PPML in order to seek gratification of my own interests. I participate in order to serve and strive for what I believe to be in the best interests of the community. I do not believe that speculators and hoarders provide benefit to the community. I support the adoption of IPv6, not only for my own interests, but, because I believe it to be in the best interests of the internet community overall. I do not advocate the encouragement of IPv6 adoption by increasing the pain level or costs of IPv4 artificially. > As far as cornering the market, even the Hunt brothers would be unable to corner a market which is currently valued at close to $50 billion and rising. > (4.3 billion addresses times $11) Your math is wrong. Yes, you multiplied the numbers you provided correctly, but, you have a GiGo problem... There are less than 3.3 billion unicast IPv4 addresses. Of those, fewer than 50% are likely to hit a transfer market at any price. (Probably closer to 10% and maybe as much as 25% in some of the most optimistic projections I have seen). So, at $5 to $15 billion, cornering the market is not quite so out of reach as you thought. Besides, one does not need to purchase 100% of the supply to effectively corner the market. All one needs to do is develop a way to rapidly purchase anything that comes on the market below your price threshold while continuing to sell well above that point. Owen > > Regards, > > Mike > > > > > ----- Original Message ----- > From: Jeffrey Lyon > To: Owen DeLong > Cc: Mike Burns ; arin-ppml at arin.net ; Rudolph Daniel > Sent: Monday, May 02, 2011 7:34 PM > Subject: Re: [arin-ppml] NRPN 8.2 & 2.3 > > > > On Mon, May 2, 2011 at 6:25 PM, Owen DeLong wrote: > > On May 2, 2011, at 12:57 PM, Mike Burns wrote: > >> >It seems the community is >> >rather divided with some advocating a complete abandonment >> >of the principles of stewardship in favor of a laissez faire >> >address economy while others favor preservation of the >> >principles of stewardship and justified need while enabling >> >market incentives to free up space. >> >Owen >> >> >> Removing artificial restrictions on the transfer of IP address space is not, as Owen persists in characterizing it, an abandonment of the principles of stewardship. > > Yes... It is. > >> Stewardship simply means different things pre- and post-exhaust. > > No, it does not. > >> Pre-exhaust requires needs analyses to ensure efficient use of address space. >> Post-exahust, efficient use is ensured by the same market incentives you claim enables the freeing up of space. >> To wit, price. >> > I don't believe that is a dependable system because without the needs basis, > you open up the potential for a new class of organization... The speculator > who wants to come in, use vast financial resources to acquire all addresses > priced below some threshold he believes to be viable and then wait until > the market desire for the resource exceeds that price (potentially by a wide > margin). This delays the availability of addresses to a wider set of justified > need while increasing the price without benefit to the community. > > The only entitiy that gains in this environment is the speculator. Everyone else > loses. > > That is, regardless of what else you may think, in my mind an obvious abandonment > of the responsibility of stewardship. > >> I don't believe that there has been an answer to those of us who said that while it is grammatically acceptable to decide that a "single aggregate" relates to the needs justification, it is nonsensical to do that, as all needs analyses result in a single aggregate. You don't have a needs analysis at any time where it is found that a need is outside CIDR boundaries. Need assessment has always rounded up to that boundary. >> > I agree with you that is the case. > >> No, the only way to interpret the language of 8.3 is that the reception of the addresses should occur as a single aggregate, which is clear has not occurred with 8.3. >> To say the staff or the board acted outside of policy is correct in the MS/Nortel case. >> > While it is nonsensical, I have found that the law is often nonsensical in its > interpretation of plain English. The supreme court has somehow managed > to interpret the plain English of the first amendment to include the ability > to bankroll a campaign by a corporation as a form of protected free speech. > To me, this seems completely nonsensical. > > So, we can't rule out a nonsensical interpretation and we need to write > language that cannot be nonsensically interpreted. > > Owen > >> Regards, >> Mike >> >> >> >> ----- Original Message ----- >> From: Owen DeLong >> To: Rudolph Daniel >> Cc: arin-ppml at arin.net >> Sent: Monday, May 02, 2011 3:44 PM >> Subject: Re: [arin-ppml] NRPN 8.2 & 2.3 >> >> At this point, I would agree. However, I would like to wait until I >> get a chance to discuss the matter with ARIN Counsel and >> further discuss it with staff before I start crafting proposals >> to do so. >> >> I don't feel that staff or the board have acted improperly. I think >> that policy failed to express the community intent well enough >> as to achieve or goals. >> >> I will continue to work on finding a way to bring policy better in >> line with community intent, but, the hard part will be achieving >> consensus on what that intent is. It seems the community is >> rather divided with some advocating a complete abandonment >> of the principles of stewardship in favor of a laissez faire >> address economy while others favor preservation of the >> principles of stewardship and justified need while enabling >> market incentives to free up space. >> >> It is most unfortunate that we failed to produce clear policy >> in 2009-1. I hope we can correct it at Philadelphia. >> >> Owen >> >> On Apr 30, 2011, at 6:48 PM, Rudolph Daniel wrote: >> >>> It would seem clear to me that at the very least, NRPN 8.2 and 8.3 requires rephrasing. Is that also the view of the ppml? >>> >>> rd >>> >>> >>> >> for such resources, as a single aggregate", not that a single >>> >> aggregate be transferred. >>> > >>> > ... I do not believe that Stephen's interpretation below matches the >>> > meaning or the intent of the policy as I understand it. ... >>> >>> I don't think it does either, for the record. However, this points out >>> how bad wording has left us in a situation where we're not sure /what/ >>> the policy text means--much less whether we agree with it. >>> >>> > I do agree that your interpretation would be a syntactically and >>> > grammatically valid construction, but, I believe it is contextually >>> > nonsensical and not the intended meaning of the words. >>> > >>> > If anyone has a suggestion for making the actual intent more clear, I >>> > am open to suggestions and would support making an editorial >>> > correction for clarity. >>> >>> If you can provide examples of transfers you both do and don't wish to >>> allow, I'll be happy to come up with wording to express your intent. As >>> it stands, though, I don't understand your (or anyone else's) intent >>> well enough to try. >>> >>> S >>> >>> -- >>> Stephen Sprunk "God does not play dice." --Albert Einstein >>> CCIE #3723 "God is an inveterate gambler, and He throws the >>> K5SSS dice at every possible opportunity." --Stephen Hawking >>> >>> -------------- next part -------------- >>> An HTML attachment was scrubbed... >>> URL: >>> -------------- next part -------------- >>> A non-text attachment was scrubbed... >>> Name: smime.p7s >>> Type: application/pkcs7-signature >>> Size: 3646 bytes >>> Desc: S/MIME Cryptographic Signature >>> URL: >>> >>> ------------------------------ >>> >>> Message: 2 >>> Date: Sat, 30 Apr 2011 20:28:39 -0400 >>> From: William Herrin >>> To: John Curran >>> Cc: Public Policy Mailing List >>> Subject: Re: [arin-ppml] Call for a study & survey to obtain necessary >>> information for policy development >>> Message-ID: >>> Content-Type: text/plain; charset=ISO-8859-1 >>> >>> On Sat, Apr 30, 2011 at 7:51 AM, John Curran wrote: >>> > ? contains a specific call for ARIN to charter a study including >>> > ? a survey in order to obtain additional information to assist in >>> > ? policy development. >>> > >>> > ? I've not seen any discussion of this suggestion; would it be >>> > ? possible to get feedback from the otherwise shy participants >>> > ? on the PPML mailing list? >>> > >>> > On Apr 29, 2011, at 5:46 PM, Jeffrey Lyon wrote: >>> >> what we should do is >>> >> charter ARIN to conduct a comprehensive study and: >>> >> >>> >> - Conduct a survey of the public at large, PPML users, full members, >>> >> resource holders, and the AC to gain a clear understanding of >>> >> sentiment for or against an open market. >>> >> - Determine how many companies actually have IPv6 migration plans and >>> >> ascertain road blocks, either legitimate or financial, that are >>> >> preventing migration. >>> >> - Would resource holders support a model that allowed ARIN to take a >>> >> small commission on resource sales and then discontinue the practice >>> >> of charging an annual fee to its members who are not buying and >>> >> selling resources. >>> >>> These seem like they could be determined by survey. >>> >>> >>> >> - In the survey, ask IPv4 resource holders to anonymously disclose >>> >> their true utilization rates and determine if companies are hoarding >>> >> resources either in hopes of future resale or to cover an arbitrary >>> >> future need. >>> >> - Determine the amount of participants that would come forward if told >>> >> they could resell their space on the open market and ultimately >>> >> determine how much unneeded space is being locked away in loosely >>> >> justified allocations. >>> >> - Determine if resource holders would be encouraged to tighten up >>> >> internal policies and free up more space if there were a fair market >>> >> value assigned to their space. >>> >>> These strike me as very difficult to determine by anything approaching >>> a statistically valid survey. I would want to see a detailed >>> methodology proposed before agreeing either that money should be spent >>> conducting the survey or that the results would have merit to >>> contribute to the policy debate. >>> >>> >>> >> - Determine the economic impact. Would resource holders be better off >>> >> selling their resources to more affluent companies who would be able >>> >> to put the space to better use? Might there be a host of struggling >>> >> small businesses who would like to put their /17 - /21 on the balance >>> >> sheet? Are there companies that would purchase IPv4 space at a premium >>> >> if allowed to do so? >>> >>> This would require a cost analysis of a great many factors, only some >>> of which have been touched on in the listed survey. Given the abject >>> lack of use of cost analysis in the Internet industry, it would >>> require at least three independent cost analyses and considerable >>> subsequent debate on and validation of the methodologies... >>> >>> Start here: http://www.sceaonline.net/ >>> >>> Disclaimer: my father is a crotchety old cost analyst so I get a >>> regular earful about this stuff. >>> >>> Regards, >>> Bill Herrin >>> >>> >>> -- >>> William D. Herrin ................ herrin at dirtside.com? bill at herrin.us >>> 3005 Crane Dr. ...................... Web: >>> Falls Church, VA 22042-3004 >>> >>> >>> ------------------------------ >>> >>> Message: 3 >>> Date: Sat, 30 Apr 2011 20:39:08 -0400 >>> From: William Herrin >>> To: Owen DeLong >>> Cc: John Curran , arin-ppml >>> Subject: Re: [arin-ppml] Analogies >>> Message-ID: >>> Content-Type: text/plain; charset=ISO-8859-1 >>> >>> On Sat, Apr 30, 2011 at 1:31 AM, Owen DeLong wrote: >>> > I will point out that ARIN is the only registry that did not start >>> > charging their legacy holders shortly after coming into existence. >>> > >>> > APNIC, RIPE, AfriNIC, and LACNIC all charge their legacy holders >>> > annual fees to the best of my knowledge. >>> > >>> > I do not know whether a contract was required in any or all cases, >>> > but, the fee portion of the equation is unique to ARIN to the best >>> > of my knowledge. >>> >>> Hi Owen, >>> >>> I will suggest that an attempt by ARIN to charge $100/year under a >>> contract simplified to, "We agree to keep your whois data and RDNS >>> delegations intact as is for one year increments until either of us >>> choose to cancel this contract" would meet with at most mild >>> resistance from the legacy registrants. It would also, IMHO, provide >>> an excellent way to weed out the abandoned registrations. >>> >>> This hasn't been done in part because we, in this forum, have insisted >>> that legacy registrants should not be invited into the fold under such >>> terms. >>> >>> Regards, >>> Bill Herrin >>> >>> >>> -- >>> William D. Herrin ................ herrin at dirtside.com? bill at herrin.us >>> 3005 Crane Dr. ...................... Web: >>> Falls Church, VA 22042-3004 >>> >>> >>> ------------------------------ >>> >>> Message: 4 >>> Date: Sat, 30 Apr 2011 20:43:29 -0400 >>> From: "Mike Burns" >>> To: "Stephen Sprunk" , "Owen DeLong" >>> >>> Cc: arin-ppml at arin.net >>> Subject: Re: [arin-ppml] ARIN / Microsoft press release regarding IP >>> addressTransfers >>> Message-ID: <7B6110E30D2E40CDA7E10BCB85E290B7 at video> >>> Content-Type: text/plain; charset="utf-8" >>> >>> >If you can provide examples of transfers you both do and don't wish to allow, I'll be happy to come up with wording to express your intent. As it stands, though, I >don't understand your (or anyone else's) intent well enough to try. >>> >>> >S >>> >>> Steve, >>> >>> Here is why I call BS on the claim that these transfers comply with policy: >>> >>> "Such transferred number resources may only be received under RSA by organizations that are within the ARIN region and can demonstrate the need for such resources, as a single aggregate, in the exact amount which they can justify under current ARIN policies." >>> >>> That is the text. The comma between resources and "as a single aggregate" can be read to cause the "as a single aggregate" clause to apply to either the verb phrase "be received" or the verb phrase "can demonstrate." >>> >>> But how would anybody demonstrate a need for multiple netblocks anyway? >>> Isn't the need ALWAYS determined as a single aggregate? >>> >>> Regards, >>> >>> Mike >>> >>> >>> >>> ----- Original Message ----- >>> From: Stephen Sprunk >>> To: Owen DeLong >>> Cc: arin-ppml at arin.net >>> Sent: Saturday, April 30, 2011 8:27 PM >>> Subject: Re: [arin-ppml] ARIN / Microsoft press release regarding IP addressTransfers >>> >>> >>> On 16-Apr-11 02:19, Owen DeLong wrote: >>> >>> On Apr 15, 2011, at 9:53 PM, Stephen Sprunk wrote: >>> >>> On 15-Apr-11 19:00, Matthew Kaufman wrote: >>> >>> The adopted policies (if they are using the "relatively new policy" as alluded to in the release) require the transfer of *a single aggregate*. >>> >>> >>> Not quite. NRPM 8.3 only requires the receiver "demonstrate the need for such resources, as a single aggregate", not that a single aggregate be transferred. >>> >>> ... I do not believe that Stephen's interpretation below matches the meaning or the intent of the policy as I understand it. ... >>> >>> I don't think it does either, for the record. However, this points out how bad wording has left us in a situation where we're not sure what the policy text means--much less whether we agree with it. >>> >>> >>> I do agree that your interpretation would be a syntactically and grammatically valid construction, but, I believe it is contextually nonsensical and not the intended meaning of the words. >>> >>> >>> If anyone has a suggestion for making the actual intent more clear, I am open to suggestions and would support making an editorial correction for clarity. >>> >>> If you can provide examples of transfers you both do and don't wish to allow, I'll be happy to come up with wording to express your intent. As it stands, though, I don't understand your (or anyone else's) intent well enough to try. >>> >>> S >>> >>> >>> -- >>> Stephen Sprunk "God does not play dice." --Albert Einstein >>> CCIE #3723 "God is an inveterate gambler, and He throws the >>> K5SSS dice at every possible opportunity." --Stephen Hawking >>> >>> >>> ------------------------------------------------------------------------------ >>> >>> >>> _______________________________________________ >>> 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: >>> >>> ------------------------------ >>> >>> _______________________________________________ >>> ARIN-PPML mailing list >>> ARIN-PPML at arin.net >>> http://lists.arin.net/mailman/listinfo/arin-ppml >>> >>> End of ARIN-PPML Digest, Vol 70, Issue 176 >>> ****************************************** >>> >>> >>> >>> -- >>> >>> Rudi Daniel >>> danielcharles consulting >>> 1-784 498 8277 >>> >>> >>> >>> _______________________________________________ >>> 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. > > > Owen, > > Would you be in support of an open exchange if there were basic controls in place to lockout speculators? > > -- > Jeffrey Lyon, Leadership Team > jeffrey.lyon at blacklotus.net | http://www.blacklotus.net > Black Lotus Communications - AS32421 > First and Leading in DDoS Protection Solutions > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From frnkblk at iname.com Mon May 2 23:18:30 2011 From: frnkblk at iname.com (Frank Bulk) Date: Mon, 2 May 2011 22:18:30 -0500 Subject: [arin-ppml] Statistics regarding NRPM 8.3 Transfers to date In-Reply-To: <6AE99775-3892-4225-83C8-EF294040B6B5@delong.com> References: <75E9BD24-F12F-42BF-A989-CF6CC282B28E@arin.net> <7406316661701612155@unknownmsgid> <3F57F52B-F1F1-4450-B493-AA4D544D8D15@arin.net> <8740380157159276993@unknownmsgid> <49E26DCB-DAF7-4A0A-912E-F981494979F5@delong.com> <4DBC2AEB.9040307@matthew.at> <4DBCA58D.4060704@sprunk.org> <2344ADD7-616E-4FA7-9552-19735926A952@delong.com><4DBD9BF5.7050002@sprunk.org> <4DBDCFB1.4040105@matthew.at> <8475B258-A979-4C4C-A4D3-C9AAFC649C71@delong.com> <6AE99775-3892-4225-83C8-EF294040B6B5@delong.com> Message-ID: <006401cc0940$c70719b0$55154d10$@iname.com> To Owen's point, because buyers don't pay for routing slots they may not really care if they buy 2 /24's or a /23. If the "/24's" really are cheaper, they'll buy them if they know their upstream will advertise /24's. Frank -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Owen DeLong Sent: Monday, May 02, 2011 6:09 PM To: Mike Burns Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] Statistics regarding NRPM 8.3 Transfers to date On May 2, 2011, at 2:05 PM, Mike Burns wrote: >> I find your faith in a market leading to people doing the right thing... > > It's called the Invisible Hand, Owen. http://en.wikipedia.org/wiki/Invisible_hand > > Regards, > Mike Call it what you want... I can point to examples of how market self-regulation does not necessarily result in a positive outcome for the people subjected to the process. Whether it is an invisible hand or an invisible fist is largely a matter of where you are in the equation when bad actors manipulate the market for their own gains. 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 matthew at matthew.at Mon May 2 23:20:26 2011 From: matthew at matthew.at (Matthew Kaufman) Date: Mon, 02 May 2011 20:20:26 -0700 Subject: [arin-ppml] Statistics regarding NRPM 8.3 Transfers to date In-Reply-To: <006401cc0940$c70719b0$55154d10$@iname.com> References: <75E9BD24-F12F-42BF-A989-CF6CC282B28E@arin.net> <7406316661701612155@unknownmsgid> <3F57F52B-F1F1-4450-B493-AA4D544D8D15@arin.net> <8740380157159276993@unknownmsgid> <49E26DCB-DAF7-4A0A-912E-F981494979F5@delong.com> <4DBC2AEB.9040307@matthew.at> <4DBCA58D.4060704@sprunk.org> <2344ADD7-616E-4FA7-9552-19735926A952@delong.com><4DBD9BF5.7050002@sprunk.org> <4DBDCFB1.4040105@matthew.at> <8475B258-A979-4C4C-A4D3-C9AAFC649C71@delong.com> <6AE99775-3892-4225-83C8-EF294040B6B5@delong.com> <006401cc0940$c70719b0$55154d10$@iname.com> Message-ID: <4DBF747A.30603@matthew.at> On 5/2/2011 8:18 PM, Frank Bulk wrote: > To Owen's point, because buyers don't pay for routing slots they may not > really care if they buy 2 /24's or a /23. If the "/24's" really are > cheaper, they'll buy them if they know their upstream will advertise /24's. ...and that their upstream's peers will accept the /24 announcements. If that ever stops happening for newly-created /24s, then one /23 would be infinitely more valuable than 2 /24s. Matthew Kaufman From owen at delong.com Mon May 2 23:18:58 2011 From: owen at delong.com (Owen DeLong) Date: Mon, 2 May 2011 20:18:58 -0700 Subject: [arin-ppml] ARIN-prop-147 Set Transfer Need to 24 months and Clarify Exception In-Reply-To: <4DBF6992.5050403@matthew.at> References: <4DBEF12A.2020002@arin.net> <03F0539F-6F62-49CD-84F8-9ABC62095596@delong.com> <69160560-5FF3-4CEE-B688-84CCB6AD2426@matthew.at> <2A17CD60-39D2-4784-AAB5-445735FA6143@matthew.at> <4E20C3B2-2444-4DCD-A580-AEF84F3C96B6@delong.com> <4DBF6992.5050403@matthew.at> Message-ID: On May 2, 2011, at 7:33 PM, Matthew Kaufman wrote: > On 5/2/2011 7:04 PM, Owen DeLong wrote: >> On May 2, 2011, at 5:13 PM, Matthew Kaufman wrote: >> >>> On May 2, 2011, at 4:39 PM, Owen DeLong wrote: >>> >>> >>>>> If they are to re-qualify, it doesn't make sense that they be forced to justify only a 3-month supply simply because the free pool is low or empty. >>>>> >>>> I disagree. >>> ... >>>> Again, I don't think that we need to support that through policy. IPv4 is reaching its >>>> end of life. There is a need to help some organizations limp along with it through >>>> transfers while it is deprecated, but, seeking to create new businesses based on >>>> IPv4 construction over the next 2 years is not something I favor encouraging or >>>> facilitating through policy. >>> >>> ANY new entity which is built through acquisition of something that exists today will need to serve customers on the IPv4 Internet for at least 2 years. Even if they are fortunate enough to grow. >>> >>> You are arguing that because Facebook has enough IPv4 space to last for another year or two, a new upstart shouldn't be able to use VC money and the transfer market to obtain an existing entity with enough IPv4 space to compete against Facebook on the IPv4 Internet for a year... you'd rather force them into getting only enough for 3 months and then crossing their fingers in hope that another 3 month supply will be available... all because the ARIN free pool ran out?!? >>> >> Not at all. If they obtain the entity through a section 8.2 transfer, more power to them. > > But if the existing entity wasn't using the space efficiently, they'll lose it unless they re-qualify... which is also under the "3-month" rule at present. > Which is as it should be. >> If they are using 8.3 to obtain only the addresses, that is a different story. >> > > Why should that be? > Because the community intended to be slightly more liberal with M&A transfers than with market-based transfers. I will refer you to 2008-2 which was the last market-based transfer policy for which I had any meaningful support. > And doesn't this just mean that there wouldn't be 8.3 transfers, just 8.2 transfers using sham organizations that exist soley to hold the transferred space? > Apparently not, as there have already been 10 8.3 transfers completed and we all know about an 11th which is not yet complete. Owen From owen at delong.com Mon May 2 23:16:06 2011 From: owen at delong.com (Owen DeLong) Date: Mon, 2 May 2011 20:16:06 -0700 Subject: [arin-ppml] ARIN-prop-146 Clarify Justified Need for Transfers In-Reply-To: <4DBF6727.1090303@matthew.at> References: <4DBEF120.4080901@arin.net> <88F39B20-5C20-45F0-AD61-5FA1E7F84CE3@delong.com> <3FCD1FDC-ECEE-4C9B-95C6-59E03D3C314E@matthew.at> <5598DFC7-E320-42FA-AA0E-C91C076BD725@delong.com> <6BA1EAA6-7D9C-44F9-BED7-884720F4B3BE@matthew.at> <05FAA29B-37BE-411C-95A4-50437602C8ED@delong.com> <4DBF6727.1090303@matthew.at> Message-ID: <097AAC1C-1F68-4820-9274-3290ADEFA195@delong.com> On May 2, 2011, at 7:23 PM, Matthew Kaufman wrote: > On 5/2/2011 6:56 PM, Owen DeLong wrote: >> On May 2, 2011, at 5:05 PM, Matthew Kaufman wrote: >> >>> If you qualify for an 8.3 transfer there is NO reason that transfer should fall under the 3-month rules, which right now, in many cases, it does... without a change like the one I have proposed. >>> >> Please cite such a case because as it currently stands, I don't believe that to be >> accurate. >> > > A. My hypothetical ISP provides service to a small town. I presently get two /24s of IPv4 space from my upstream provider and I'm using them at about 85%. ARIN has run completely out of addresses. A benefactor arrives and offers to transfer a /22 to me and pay for me to multihome. > > I attempt to use 4.2.2.2 (Initial Allocation to ISPs, Multihomed) for my justification. I need to demonstrate that I am efficiently using the two /24s. Done. I comply with 4.2.2.2.1 (SWIP). I attempt to comply with 4.2.2.2.2, but my growth shows that I won't really need more than a /23 for about 7 months. Transfer would be denied because 4.2.2.2.2 has a three month rule (as I claimed above). Benefactor takes his space elsewhere, and I lose out. > I'm not seeing the problem. You wouldn't have gotten the space from ARIN before runout, I don't see why you should get it now from a transfer. > > B. My hypothetical ISP provides service to a single data center. I presently have a /20 that I was able to obtain from ARIN a few months ago, and I wasn't an ARIN subscriber member prior to this. I have the opportunity to acquire another ISP in town which has a /20 of its own, but which it isn't using very well because their growth plans failed after I opened up. I can demonstrate that my /20 and the second /20 from the acquisition would be filled within a year if I complete this transfer under section 8.2, but I'll only be able to fill out my existing /20 over the next three months. However, because I am under 4.2.4.3 (Subscriber Members Less Than One Year) my 8.2 transfer is denied, again because 4.2.4.3 has a three month rule (as I claimed above). > Again, this was the way things worked before runout or even scarcity and its really a corner case. I don't see why it should work differently just because of runout. > on the flip side... > > C. My hypothetical ISP provides service to a small city that is served by only one transit provider, so I cannot multihome. It has been using a /20 from the upstream ISP and is efficiently using 16 /24s worth of space with reassignment documentation (satisfying 4.2.2.1.1 and 4.2.2.1.2). I provide detailed information showing that I can use a /20 within the next three months (satisfying 4.2.2.1.3). Now that I have met all the tests, I complete a section 8.3 transfer for a /14 worth of space (because I have loads of money I won in the lottery). As far as I can tell, there's nothing in the NRPM that blocks that transfer... because I've met all the tests in 4.2.2.1. > You would need justified need for the /14 within 12 months under the subsequent allocations clause or you would only be able to transfer a fraction of it. This is as intended. Owen From owen at delong.com Mon May 2 23:16:52 2011 From: owen at delong.com (Owen DeLong) Date: Mon, 2 May 2011 20:16:52 -0700 Subject: [arin-ppml] Statistics regarding NRPM 8.3 Transfers to date In-Reply-To: <4DBF693D.7010206@matthew.at> References: <75E9BD24-F12F-42BF-A989-CF6CC282B28E@arin.net> <7406316661701612155@unknownmsgid> <3F57F52B-F1F1-4450-B493-AA4D544D8D15@arin.net> <8740380157159276993@unknownmsgid> <49E26DCB-DAF7-4A0A-912E-F981494979F5@delong.com> <4DBC2AEB.9040307@matthew.at> <4DBCA58D.4060704@sprunk.org> <2344ADD7-616E-4FA7-9552-19735926A952@delong.com> <4DBD9BF5.7050002@sprunk.org> <4DBF2724.6090300@sprunk.org> <79A82F38-A2BE-4F9E-851D-4286E0C7CD57@matthew.at> <3431DD64-86DF-4EE0-B0FE-75135D277F4B@delong.com> <4DBF693D.7010206@matthew.at> Message-ID: <394D65DF-6C47-4805-8679-13202FD39738@delong.com> On May 2, 2011, at 7:32 PM, Matthew Kaufman wrote: > On 5/2/2011 6:59 PM, Owen DeLong wrote: >> On May 2, 2011, at 5:07 PM, Matthew Kaufman wrote: >> >>> On May 2, 2011, at 4:33 PM, Owen DeLong wrote: >>> >>>> Heaven help the internet if we ever get to a point where /24s are no longer accepted. The number >>>> of organizations that would be immediately disenfranchised by such a move would be >>>> devastating. >>> Unless of course the people running ISPs were smart enough to figure out how to allow old /24s and not allow new /24s using some sort of well-maintained database... or otherwise apply market pressure against people trying to break up large blocks into many small blocks. >>> >>> Matthew Kaufman >> Given the abilities demonstrated by many of the ISPs I've subscribed to or had to accept >> service from, my confidence in this meaningfully happening is, well, very low. >> > > Then they'll be the ones who run out of BGP table space and have their routers crash. The ones who want their routers to stay up will improve their practices. > > Matthew Kaufman > > ps. Most of the ISPs you don't have confidence in *also* don't have IPv6 support yet either Why do you think I'm only using them for layer 2 transport these days. Owen From frnkblk at iname.com Mon May 2 23:21:47 2011 From: frnkblk at iname.com (Frank Bulk) Date: Mon, 2 May 2011 22:21:47 -0500 Subject: [arin-ppml] Statistics regarding NRPM 8.3 Transfers to date In-Reply-To: <4DBDCFB1.4040105@matthew.at> References: <75E9BD24-F12F-42BF-A989-CF6CC282B28E@arin.net> <7406316661701612155@unknownmsgid> <3F57F52B-F1F1-4450-B493-AA4D544D8D15@arin.net> <8740380157159276993@unknownmsgid> <49E26DCB-DAF7-4A0A-912E-F981494979F5@delong.com> <4DBC2AEB.9040307@matthew.at> <4DBCA58D.4060704@sprunk.org> <2344ADD7-616E-4FA7-9552-19735926A952@delong.com> <4DBD9BF5.7050002@sprunk.org> <4DBDCFB1.4040105@matthew.at> Message-ID: <006501cc0941$3c16c070$b4444150$@iname.com> On one hand I would prefer an STLS that doesn't allow transferred netblocks to be de-aggregated, either at the time of transfer or in the future. On the other, creating that restriction will give incentive for sellers and buyers to work around ARIN as much as they possibly can. Frank -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Matthew Kaufman Sent: Sunday, May 01, 2011 4:25 PM To: Stephen Sprunk Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] Statistics regarding NRPM 8.3 Transfers to date On 5/1/2011 10:44 AM, Stephen Sprunk wrote: > However, assuming that aggregation has inherent value to > buyers, sellers will avoid them out of self-interest, so we may not need > to put anything into policy. Is anyone seriously concerned that > assumption is wrong? That's exactly why I don't think we need really complicated language that then has lots of associated loopholes. If aggregation is good, providers will encourage it, and addresses that are big aggregates will have more value. Done. Matthew Kaufman _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. From matthew at matthew.at Mon May 2 23:25:43 2011 From: matthew at matthew.at (Matthew Kaufman) Date: Mon, 02 May 2011 20:25:43 -0700 Subject: [arin-ppml] ARIN-prop-146 Clarify Justified Need for Transfers In-Reply-To: <097AAC1C-1F68-4820-9274-3290ADEFA195@delong.com> References: <4DBEF120.4080901@arin.net> <88F39B20-5C20-45F0-AD61-5FA1E7F84CE3@delong.com> <3FCD1FDC-ECEE-4C9B-95C6-59E03D3C314E@matthew.at> <5598DFC7-E320-42FA-AA0E-C91C076BD725@delong.com> <6BA1EAA6-7D9C-44F9-BED7-884720F4B3BE@matthew.at> <05FAA29B-37BE-411C-95A4-50437602C8ED@delong.com> <4DBF6727.1090303@matthew.at> <097AAC1C-1F68-4820-9274-3290ADEFA195@delong.com> Message-ID: <4DBF75B7.3010407@matthew.at> On 5/2/2011 8:16 PM, Owen DeLong wrote: > On May 2, 2011, at 7:23 PM, Matthew Kaufman wrote: > >> On 5/2/2011 6:56 PM, Owen DeLong wrote: >>> On May 2, 2011, at 5:05 PM, Matthew Kaufman wrote: >>> >>>> If you qualify for an 8.3 transfer there is NO reason that transfer should fall under the 3-month rules, which right now, in many cases, it does... without a change like the one I have proposed. >>>> >>> Please cite such a case because as it currently stands, I don't believe that to be >>> accurate. >>> >> A. My hypothetical ISP provides service to a small town. I presently get two /24s of IPv4 space from my upstream provider and I'm using them at about 85%. ARIN has run completely out of addresses. A benefactor arrives and offers to transfer a /22 to me and pay for me to multihome. >> >> I attempt to use 4.2.2.2 (Initial Allocation to ISPs, Multihomed) for my justification. I need to demonstrate that I am efficiently using the two /24s. Done. I comply with 4.2.2.2.1 (SWIP). I attempt to comply with 4.2.2.2.2, but my growth shows that I won't really need more than a /23 for about 7 months. Transfer would be denied because 4.2.2.2.2 has a three month rule (as I claimed above). Benefactor takes his space elsewhere, and I lose out. >> > I'm not seeing the problem. You wouldn't have gotten the space from ARIN before runout, I don't see why you > should get it now from a transfer. Because post-runout is a different world. Pre-runout I get 3 months of space, I use it, I go back to ARIN, I get 3 more months, I use it, I go back to ARIN and this time I get a whole year. Post-runout I get whatever space I can successfully bid for, which takes an indeterminate amount of time, energy, and money and then three months later there may or may not be space available from anyone, and if there is it is quite possibly not at a price I can afford. You come up with a likely post-runout scenario where I can be *guaranteed* to get 3 more months of address space at no higher price than it takes to get the 3 months this time, and with minimal delay once I qualify for the next three months, and I'll support your point of view. >> B. My hypothetical ISP provides service to a single data center. I presently have a /20 that I was able to obtain from ARIN a few months ago, and I wasn't an ARIN subscriber member prior to this. I have the opportunity to acquire another ISP in town which has a /20 of its own, but which it isn't using very well because their growth plans failed after I opened up. I can demonstrate that my /20 and the second /20 from the acquisition would be filled within a year if I complete this transfer under section 8.2, but I'll only be able to fill out my existing /20 over the next three months. However, because I am under 4.2.4.3 (Subscriber Members Less Than One Year) my 8.2 transfer is denied, again because 4.2.4.3 has a three month rule (as I claimed above). >> > Again, this was the way things worked before runout or even scarcity and its really a corner case. > I don't see why it should work differently just because of runout. See above about how post-runout is completely different. >> on the flip side... >> >> C. My hypothetical ISP provides service to a small city that is served by only one transit provider, so I cannot multihome. It has been using a /20 from the upstream ISP and is efficiently using 16 /24s worth of space with reassignment documentation (satisfying 4.2.2.1.1 and 4.2.2.1.2). I provide detailed information showing that I can use a /20 within the next three months (satisfying 4.2.2.1.3). Now that I have met all the tests, I complete a section 8.3 transfer for a /14 worth of space (because I have loads of money I won in the lottery). As far as I can tell, there's nothing in the NRPM that blocks that transfer... because I've met all the tests in 4.2.2.1. >> > You would need justified need for the /14 within 12 months under the subsequent allocations > clause or you would only be able to transfer a fraction of it. This is as intended. What section number are you referring to? There's nothing in 4.2.2.1 that requires that I justify more than a /20 to get that /14. Matthew Kaufman From mysidia at gmail.com Mon May 2 23:30:44 2011 From: mysidia at gmail.com (Jimmy Hess) Date: Mon, 2 May 2011 22:30:44 -0500 Subject: [arin-ppml] Fw: Accusation of fundamental conflict ofinterest/IPaddress policy pitched directly to ICANN In-Reply-To: <554D2486-3541-4A8B-ABBF-686A76A6436B@delong.com> References: <554D2486-3541-4A8B-ABBF-686A76A6436B@delong.com> Message-ID: On Mon, May 2, 2011 at 9:46 PM, Owen DeLong wrote: > And again, I say there is no higher level to move the venue to. > Owen And... there is also not conflict of interest. A conflict of interest exists, where a person/organization is required to make an impartial decision, and a competing interest exists that could render their decision not impartial. The lack of an obligation or requirement to be impartial w.r.t. global policy proposals; eliminates any possibility of ARIN itself being in conflict of interest. The community is under no obligation to make an impartial decision, with regards to policy proposals; community members can consider their interests in taking positions, and supporting/opposing proposals. The ARIN boards are expected, to prefer what the community prefers. The members elect the ARIN boards, and have the wherewithall to elect different board members, if they fail to do their job, or if the community consensus regarding a policy or proposal established and the PDP or other rules are seen to be ignored. -- -JH From frnkblk at iname.com Mon May 2 23:36:19 2011 From: frnkblk at iname.com (Frank Bulk) Date: Mon, 2 May 2011 22:36:19 -0500 Subject: [arin-ppml] Statistics regarding NRPM 8.3 Transfers to date In-Reply-To: <4DBF747A.30603@matthew.at> References: <75E9BD24-F12F-42BF-A989-CF6CC282B28E@arin.net> <7406316661701612155@unknownmsgid> <3F57F52B-F1F1-4450-B493-AA4D544D8D15@arin.net> <8740380157159276993@unknownmsgid> <49E26DCB-DAF7-4A0A-912E-F981494979F5@delong.com> <4DBC2AEB.9040307@matthew.at> <4DBCA58D.4060704@sprunk.org> <2344ADD7-616E-4FA7-9552-19735926A952@delong.com><4DBD9BF5.7050002@sprunk.org> <4DBDCFB1.4040105@matthew.at> <8475B258-A979-4C4C-A4D3-C9AAFC649C71@delong.com> <6AE99775-3892-4225-83C8-EF294040B6B5@delong.com> <006401cc0940$c70719b0$55154d10$@iname.com> <4DBF747A.30603@matthew.at> Message-ID: <006b01cc0943$43e39970$cbaacc50$@iname.com> Correct. I'm guessing we'll see more aggressive filtering based on some characteristic of the netblock before we see the IPv4 advertising threshold change from /24 to /23. If the IPv6 transition is very well along it's possible that transit providers won't be as reluctant to filter more aggressively. Frank -----Original Message----- From: Matthew Kaufman [mailto:matthew at matthew.at] Sent: Monday, May 02, 2011 10:20 PM To: frnkblk at iname.com Cc: Mike Burns; arin-ppml at arin.net Subject: Re: [arin-ppml] Statistics regarding NRPM 8.3 Transfers to date On 5/2/2011 8:18 PM, Frank Bulk wrote: > To Owen's point, because buyers don't pay for routing slots they may not > really care if they buy 2 /24's or a /23. If the "/24's" really are > cheaper, they'll buy them if they know their upstream will advertise /24's. ...and that their upstream's peers will accept the /24 announcements. If that ever stops happening for newly-created /24s, then one /23 would be infinitely more valuable than 2 /24s. Matthew Kaufman From owen at delong.com Mon May 2 23:38:01 2011 From: owen at delong.com (Owen DeLong) Date: Mon, 2 May 2011 20:38:01 -0700 Subject: [arin-ppml] Statistics regarding NRPM 8.3 Transfers to date In-Reply-To: <4DBF747A.30603@matthew.at> References: <75E9BD24-F12F-42BF-A989-CF6CC282B28E@arin.net> <7406316661701612155@unknownmsgid> <3F57F52B-F1F1-4450-B493-AA4D544D8D15@arin.net> <8740380157159276993@unknownmsgid> <49E26DCB-DAF7-4A0A-912E-F981494979F5@delong.com> <4DBC2AEB.9040307@matthew.at> <4DBCA58D.4060704@sprunk.org> <2344ADD7-616E-4FA7-9552-19735926A952@delong.com><4DBD9BF5.7050002@sprunk.org> <4DBDCFB1.4040105@matthew.at> <8475B258-A979-4C4C-A4D3-C9AAFC649C71@delong.com> <6AE99775-3892-4225-83C8-EF294040B6B5@delong.com> <006401cc0940$c70719b0$55154d10$@iname.com> <4DBF747A.30603@matthew.at> Message-ID: On May 2, 2011, at 8:20 PM, Matthew Kaufman wrote: > On 5/2/2011 8:18 PM, Frank Bulk wrote: >> To Owen's point, because buyers don't pay for routing slots they may not >> really care if they buy 2 /24's or a /23. If the "/24's" really are >> cheaper, they'll buy them if they know their upstream will advertise /24's. > ...and that their upstream's peers will accept the /24 announcements. If that ever stops happening for newly-created /24s, then one /23 would be infinitely more valuable than 2 /24s. We will likely be far past IPv4 table meltdown before that meaningfully happens to an extent sufficient to feed back into the market. In the meantime all those /24 purchasers that bought after the door was closed but before the market knew it had been shut will be phoning their anti-trust lawyers and the fun will really begin. Whee!! Owen From mysidia at gmail.com Mon May 2 23:49:10 2011 From: mysidia at gmail.com (Jimmy Hess) Date: Mon, 2 May 2011 22:49:10 -0500 Subject: [arin-ppml] ARIN-prop-147 Set Transfer Need to 24 months and Clarify Exception In-Reply-To: <4DBEF12A.2020002@arin.net> References: <4DBEF12A.2020002@arin.net> Message-ID: On Mon, May 2, 2011 at 1:00 PM, ARIN wrote: > ARIN-prop-147 Set Transfer Need to 24 months and Clarify Exception Opposed to PP147, increasing to 24 month supply for transfers. (1) 12 months supply has been sufficient in the past - it was the long standing standard for normal allocations. (2) 3 months supply is the current maximum for new allocations from ARIN; therefore, 12 months is already a 4x allowance, which is substantial benefit for obtaining resources through 8.3 transfer. (3) IP address exhaustion means that allowing the 24-months further reduces the availability of number resources through specified transfer; and further reduces efficient use of IP addresses; reducing the number of 8.3 transfers that can occur. (4) Widespread IPv6 deployment should render the one benefit of 24-month extension not useful before 12 months after its adoption; due to massive drop in demand for IPv4 addressing. -- -JH From owen at delong.com Mon May 2 23:47:16 2011 From: owen at delong.com (Owen DeLong) Date: Mon, 2 May 2011 20:47:16 -0700 Subject: [arin-ppml] ARIN-prop-146 Clarify Justified Need for Transfers In-Reply-To: <4DBF75B7.3010407@matthew.at> References: <4DBEF120.4080901@arin.net> <88F39B20-5C20-45F0-AD61-5FA1E7F84CE3@delong.com> <3FCD1FDC-ECEE-4C9B-95C6-59E03D3C314E@matthew.at> <5598DFC7-E320-42FA-AA0E-C91C076BD725@delong.com> <6BA1EAA6-7D9C-44F9-BED7-884720F4B3BE@matthew.at> <05FAA29B-37BE-411C-95A4-50437602C8ED@delong.com> <4DBF6727.1090303@matthew.at> <097AAC1C-1F68-4820-9274-3290ADEFA195@delong.com> <4DBF75B7.3010407@matthew.at> Message-ID: <9501EA7E-FDAD-4DDA-B9E8-08C2811FF642@delong.com> On May 2, 2011, at 8:25 PM, Matthew Kaufman wrote: > On 5/2/2011 8:16 PM, Owen DeLong wrote: >> On May 2, 2011, at 7:23 PM, Matthew Kaufman wrote: >> >>> On 5/2/2011 6:56 PM, Owen DeLong wrote: >>>> On May 2, 2011, at 5:05 PM, Matthew Kaufman wrote: >>>> >>>>> If you qualify for an 8.3 transfer there is NO reason that transfer should fall under the 3-month rules, which right now, in many cases, it does... without a change like the one I have proposed. >>>>> >>>> Please cite such a case because as it currently stands, I don't believe that to be >>>> accurate. >>>> >>> A. My hypothetical ISP provides service to a small town. I presently get two /24s of IPv4 space from my upstream provider and I'm using them at about 85%. ARIN has run completely out of addresses. A benefactor arrives and offers to transfer a /22 to me and pay for me to multihome. >>> >>> I attempt to use 4.2.2.2 (Initial Allocation to ISPs, Multihomed) for my justification. I need to demonstrate that I am efficiently using the two /24s. Done. I comply with 4.2.2.2.1 (SWIP). I attempt to comply with 4.2.2.2.2, but my growth shows that I won't really need more than a /23 for about 7 months. Transfer would be denied because 4.2.2.2.2 has a three month rule (as I claimed above). Benefactor takes his space elsewhere, and I lose out. >>> >> I'm not seeing the problem. You wouldn't have gotten the space from ARIN before runout, I don't see why you >> should get it now from a transfer. > > Because post-runout is a different world. Pre-runout I get 3 months of space, I use it, I go back to ARIN, I get 3 more months, I use it, I go back to ARIN and this time I get a whole year. > And you can do that with the market as well. > Post-runout I get whatever space I can successfully bid for, which takes an indeterminate amount of time, energy, and money and then three months later there may or may not be space available from anyone, and if there is it is quite possibly not at a price I can afford. > Welcome to the post-run-out world. Why should we let you acquire more space now and deny that space to someone else who has justified need now? > You come up with a likely post-runout scenario where I can be *guaranteed* to get 3 more months of address space at no higher price than it takes to get the 3 months this time, and with minimal delay once I qualify for the next three months, and I'll support your point of view. > If you expect to be guaranteed anything in terms of availability after runout, you are suffering from hallucinations and I suggest you seek medical or psychological assistance. However, I still don't see anything in your argument that justifies why you should be able to deny space to someone else just because you might need it three months from now. >>> B. My hypothetical ISP provides service to a single data center. I presently have a /20 that I was able to obtain from ARIN a few months ago, and I wasn't an ARIN subscriber member prior to this. I have the opportunity to acquire another ISP in town which has a /20 of its own, but which it isn't using very well because their growth plans failed after I opened up. I can demonstrate that my /20 and the second /20 from the acquisition would be filled within a year if I complete this transfer under section 8.2, but I'll only be able to fill out my existing /20 over the next three months. However, because I am under 4.2.4.3 (Subscriber Members Less Than One Year) my 8.2 transfer is denied, again because 4.2.4.3 has a three month rule (as I claimed above). >>> >> Again, this was the way things worked before runout or even scarcity and its really a corner case. >> I don't see why it should work differently just because of runout. > > See above about how post-runout is completely different. > Except that it isn't. In fact, if anything, it is more critical to preserve these protections for the rest of the community so that the people with more money don't amass larger address blocks just for the sake of preventing their use by more immediate needs with less money. >>> on the flip side... >>> >>> C. My hypothetical ISP provides service to a small city that is served by only one transit provider, so I cannot multihome. It has been using a /20 from the upstream ISP and is efficiently using 16 /24s worth of space with reassignment documentation (satisfying 4.2.2.1.1 and 4.2.2.1.2). I provide detailed information showing that I can use a /20 within the next three months (satisfying 4.2.2.1.3). Now that I have met all the tests, I complete a section 8.3 transfer for a /14 worth of space (because I have loads of money I won in the lottery). As far as I can tell, there's nothing in the NRPM that blocks that transfer... because I've met all the tests in 4.2.2.1. >>> >> You would need justified need for the /14 within 12 months under the subsequent allocations >> clause or you would only be able to transfer a fraction of it. This is as intended. > > What section number are you referring to? There's nothing in 4.2.2.1 that requires that I justify more than a /20 to get that /14. > Section 4.1.5 combined with section 4.2.1 mean that ARIN will review your justified need in determining the size prefix you are able to acquire whether through initial allocation from ARIN or by obtaining your first resources through a transfer request. I admit that on review, the initial allocation policy for IPv4 appears to have a number of flaws and probably should be improved. However, this should be true regardless of the source of the addresses. Owen From matthew at matthew.at Tue May 3 00:22:14 2011 From: matthew at matthew.at (Matthew Kaufman) Date: Mon, 02 May 2011 21:22:14 -0700 Subject: [arin-ppml] ARIN-prop-146 Clarify Justified Need for Transfers In-Reply-To: <9501EA7E-FDAD-4DDA-B9E8-08C2811FF642@delong.com> References: <4DBEF120.4080901@arin.net> <88F39B20-5C20-45F0-AD61-5FA1E7F84CE3@delong.com> <3FCD1FDC-ECEE-4C9B-95C6-59E03D3C314E@matthew.at> <5598DFC7-E320-42FA-AA0E-C91C076BD725@delong.com> <6BA1EAA6-7D9C-44F9-BED7-884720F4B3BE@matthew.at> <05FAA29B-37BE-411C-95A4-50437602C8ED@delong.com> <4DBF6727.1090303@matthew.at> <097AAC1C-1F68-4820-9274-3290ADEFA195@delong.com> <4DBF75B7.3010407@matthew.at> <9501EA7E-FDAD-4DDA-B9E8-08C2811FF642@delong.com> Message-ID: <4DBF82F6.7050608@matthew.at> On 5/2/2011 8:47 PM, Owen DeLong wrote: > > Welcome to the post-run-out world. Why should we let you acquire more space now and deny that > space to someone else who has justified need now? Because I can afford it and have taken the time to find a seller. Or were you planning on enacting price controls on the market as well? Matthew Kaufman From matthew at matthew.at Tue May 3 00:24:57 2011 From: matthew at matthew.at (Matthew Kaufman) Date: Mon, 02 May 2011 21:24:57 -0700 Subject: [arin-ppml] ARIN-prop-146 Clarify Justified Need for Transfers In-Reply-To: <9501EA7E-FDAD-4DDA-B9E8-08C2811FF642@delong.com> References: <4DBEF120.4080901@arin.net> <88F39B20-5C20-45F0-AD61-5FA1E7F84CE3@delong.com> <3FCD1FDC-ECEE-4C9B-95C6-59E03D3C314E@matthew.at> <5598DFC7-E320-42FA-AA0E-C91C076BD725@delong.com> <6BA1EAA6-7D9C-44F9-BED7-884720F4B3BE@matthew.at> <05FAA29B-37BE-411C-95A4-50437602C8ED@delong.com> <4DBF6727.1090303@matthew.at> <097AAC1C-1F68-4820-9274-3290ADEFA195@delong.com> <4DBF75B7.3010407@matthew.at> <9501EA7E-FDAD-4DDA-B9E8-08C2811FF642@delong.com> Message-ID: <4DBF8399.3010908@matthew.at> On 5/2/2011 8:47 PM, Owen DeLong wrote: > > Welcome to the post-run-out world. Why should we let you acquire more space now and deny that > space to someone else who has justified need now? And why, exactly do we have a rule now that you can only get 3 months of space for initial allocations? Everyone who isn't an initial allocation *can* get 12 months via the transfer market... what makes them special or any more deserving of the fruits of a transfer market? What I think will happen is that anyone with enough money to afford 12 months of address space can afford to do something to work around this rule... possibly failing to update the whois database in the process. Matthew Kaufman From farmer at umn.edu Tue May 3 00:32:00 2011 From: farmer at umn.edu (David Farmer) Date: Mon, 02 May 2011 23:32:00 -0500 Subject: [arin-ppml] ARIN-prop-146 Clarify Justified Need for Transfers In-Reply-To: <4DBF68C4.7050501@matthew.at> References: <4DBEF120.4080901@arin.net> <4DBF64FF.6070604@umn.edu> <4DBF68C4.7050501@matthew.at> Message-ID: <4DBF8540.7050302@umn.edu> On 5/2/11 21:30 CDT, Matthew Kaufman wrote: > On 5/2/2011 7:14 PM, David Farmer wrote: >> On 5/2/11 13:00 CDT, ARIN wrote: >>> Policy statement: >>> >>> Add a subsection to Section 8 (Transfers) of the NRPM: >>> >>> "Justified Need" for resources associated with a transfer shall be >>> determined using the "4.2.4 ISP Additional Requests" criteria applied as >>> though the recipient has been a subscriber member of ARIN for at least >>> one year (whether or not that is the case). >> >> Do you indent to eliminate the ability for end users to be the >> recipient of transfers? You seem to be doing that. >> >> Would you please state your intended result for this policy in plain >> English, because I'm confused as to your intended outcome. >> >> Like; "All ISP should be able to get a 12month supply" for example, if >> that is your intended outcome. > > "Any transfer recipient should be able to get a 12 month supply for an > 8.2 or 8.3 transfer as long as they justify it as well as an ISP had to > justify additional space back in the old days" I'd like to get staff's interpretation of how the second paragraph of 8.2 is applied in practice. When policy 2009-8 (the change to 3 month at IANA run-out) was written there wasn't any needs justification related to 8.2 transfers. But I agree with you that the same needs justifications should apply to both 8.2 and 8.3. Maybe the best way to fix that issue is the change the last paragraph of 4.2.4.4 Subscriber members after one year to read This reduction does not apply to resources received via a transfer in Section 8. An organization receiving a transfer under section 8 may continue to request up to a 12-month supply of IP addresses." Instead of the current; This reduction does not apply to resources received via section 8.3. An organization receiving a transfer under section 8.3 may continue to request up to a 12-month supply of IP addresses. You also want to change the rules for new ISP, I think I can support changing this, given that they are going to have to buy addresses on the market maybe we shouldn't tie one hand behind there back too. Life is going to be hard enough for a new ISP even without slow start and all of the other restriction put on them now. However, the reason for slow start (4.2.2.3) was that it is difficult to judge the validity of a 12 month estimate for an organization that doesn't have any history to base it on. Do you have any suggestion on how to deal with that issue? Also, I think you want to drop 4.2.2.1.3 Essentially a three month justification for a /20, that sounds reasonable. But, maybe we should also drop 4.2.2.1.4. Renumber and return expecting an ISP to renumber out of a current upstream block post-run-out seems equally harsh and unrealistic. So I think I support your intent, but not necessarily your prescribed language. We should seriously look at easing up the restrictions on new ISPs as we enter a world of new IPv4 realities. Given these new realities, the old restrictions seem kind of harsh. And I think the needs justification should be the same for both 8.2 and 8.3 Maybe we do this as two different policies, because they really are separate issues, with separate rationales. -- =============================================== 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 mysidia at gmail.com Tue May 3 00:46:55 2011 From: mysidia at gmail.com (Jimmy Hess) Date: Mon, 2 May 2011 23:46:55 -0500 Subject: [arin-ppml] ARIN-prop-146 Clarify Justified Need for Transfers In-Reply-To: <4DBF82F6.7050608@matthew.at> References: <4DBEF120.4080901@arin.net> <88F39B20-5C20-45F0-AD61-5FA1E7F84CE3@delong.com> <3FCD1FDC-ECEE-4C9B-95C6-59E03D3C314E@matthew.at> <5598DFC7-E320-42FA-AA0E-C91C076BD725@delong.com> <6BA1EAA6-7D9C-44F9-BED7-884720F4B3BE@matthew.at> <05FAA29B-37BE-411C-95A4-50437602C8ED@delong.com> <4DBF6727.1090303@matthew.at> <097AAC1C-1F68-4820-9274-3290ADEFA195@delong.com> <4DBF75B7.3010407@matthew.at> <9501EA7E-FDAD-4DDA-B9E8-08C2811FF642@delong.com> <4DBF82F6.7050608@matthew.at> Message-ID: On Mon, May 2, 2011 at 11:22 PM, Matthew Kaufman wrote: > On 5/2/2011 8:47 PM, Owen DeLong wrote: > Because I can afford it and have taken the time to find a seller. > Or were you planning on enacting price controls on the market as well? > Matthew Kaufman 8.3 is not about creating a transfer market. Whether the specified transfer is made for free, or in exchange for some type of payment, is up to transferor and transferee, and is probably kept secret. There's really nothing to stop you from agreeing to transfer a 5 year supply of resources, by completing two sales agreements; or one "master agreement" for the huge chunk of address space bought, with smaller agreements to be executed at later dates in a structured manner for the buyer to take delivery of chunks of addresses, in portions (of the total bought) of their choosing. And delaying the date that you take delivery of IP addresses beyond what you can justify. At the risk that RIR transfer policies might change in the interim; or your 5 year supply of purchased resources might become much less expensive by the time you need them. The 8.3 policy says you can only receive a 12-month supply by specified transfer. It doesn't say anything about addresses you have already bought, or have agreed to buy, but have opted not to receive yet for use on your network. 8.2 doesn't have any stipulation against a buyer entering a contract with a seller to "reserve a 10-year supply"; and every 6 months deliver to the buyer a portion of the sold (but undelivered) addresses, that the buyer will specify, under some sort of structure disbursal structured disbursal to ensure adequate supply. -- -JH From farmer at umn.edu Tue May 3 01:15:18 2011 From: farmer at umn.edu (David Farmer) Date: Tue, 03 May 2011 00:15:18 -0500 Subject: [arin-ppml] ARIN-prop-146 Clarify Justified Need for Transfers In-Reply-To: <9501EA7E-FDAD-4DDA-B9E8-08C2811FF642@delong.com> References: <4DBEF120.4080901@arin.net> <88F39B20-5C20-45F0-AD61-5FA1E7F84CE3@delong.com> <3FCD1FDC-ECEE-4C9B-95C6-59E03D3C314E@matthew.at> <5598DFC7-E320-42FA-AA0E-C91C076BD725@delong.com> <6BA1EAA6-7D9C-44F9-BED7-884720F4B3BE@matthew.at> <05FAA29B-37BE-411C-95A4-50437602C8ED@delong.com> <4DBF6727.1090303@matthew.at> <097AAC1C-1F68-4820-9274-3290ADEFA195@delong.com> <4DBF75B7.3010407@matthew.at> <9501EA7E-FDAD-4DDA-B9E8-08C2811FF642@delong.com> Message-ID: <4DBF8F66.1090708@umn.edu> On 5/2/11 22:47 CDT, Owen DeLong wrote: > > On May 2, 2011, at 8:25 PM, Matthew Kaufman wrote: > >> On 5/2/2011 8:16 PM, Owen DeLong wrote: >>> On May 2, 2011, at 7:23 PM, Matthew Kaufman wrote: >>> >>>> On 5/2/2011 6:56 PM, Owen DeLong wrote: >>>>> On May 2, 2011, at 5:05 PM, Matthew Kaufman wrote: >>>>> >>>>>> If you qualify for an 8.3 transfer there is NO reason that transfer should fall under the 3-month rules, which right now, in many cases, it does... without a change like the one I have proposed. >>>>>> >>>>> Please cite such a case because as it currently stands, I don't believe that to be >>>>> accurate. >>>>> >>>> A. My hypothetical ISP provides service to a small town. I presently get two /24s of IPv4 space from my upstream provider and I'm using them at about 85%. ARIN has run completely out of addresses. A benefactor arrives and offers to transfer a /22 to me and pay for me to multihome. >>>> >>>> I attempt to use 4.2.2.2 (Initial Allocation to ISPs, Multihomed) for my justification. I need to demonstrate that I am efficiently using the two /24s. Done. I comply with 4.2.2.2.1 (SWIP). I attempt to comply with 4.2.2.2.2, but my growth shows that I won't really need more than a /23 for about 7 months. Transfer would be denied because 4.2.2.2.2 has a three month rule (as I claimed above). Benefactor takes his space elsewhere, and I lose out. >>>> >>> I'm not seeing the problem. You wouldn't have gotten the space from ARIN before runout, I don't see why you >>> should get it now from a transfer. >> >> Because post-runout is a different world. Pre-runout I get 3 months of space, I use it, I go back to ARIN, I get 3 more months, I use it, I go back to ARIN and this time I get a whole year. >> > And you can do that with the market as well. Owen, The availability of space in 3-months could be completely different at that time then now, in a market-like situation for address space why should a new ISP not be able to compete on equal footing with an established ISP. I don't buy the nothing should change argument, there are a number of issues we probably should reconsider when you have to compete in a market-like situation for addresses as opposed to having an IANA free pool. I'm not convinced that we should abandon a needs basis, but we do need to reevaluate things and make sure the needs basis we had when there was an IANA free pool is still valid when you are competing in a market-like situation for addresses. I think it is reasonable to reconsider slow-start and other rules for new ISPs in a world where there isn't an IANA free pool. Furthermore, I'm worried that if we are not willing to discuss adjusting a few reasonable things it only strengthens the calls for completely abandoning a needs basis. If we are not going to let new ISPs compete on an equal footing then maybe we need an additional reservation for them to provide them with addresses until they can compete on an equal footing. However, at this point I think it is just easier to relax slow-start and other requirements. -- =============================================== 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 3 09:03:39 2011 From: bill at herrin.us (William Herrin) Date: Tue, 3 May 2011 09:03:39 -0400 Subject: [arin-ppml] Analogies In-Reply-To: <20B2220E-A768-46CE-B19D-AF15D02AD08F@arin.net> References: <39209.1303885464@tristatelogic.com> <75822E125BCB994F8446858C4B19F0D7173057C827@SUEX07-MBX-04.ad.syr.edu> <471D76419F9EF642962323D13DF1DF69011E5C@newserver.arneill-py.local> <7348D3C8-4EB7-4440-A152-210CC8B0DA3C@arin.net> <471D76419F9EF642962323D13DF1DF69011E60@newserver.arneill-py.local> <583A067A-B8AE-4026-844E-6769D1D7CF88@arin.net> <471D76419F9EF642962323D13DF1DF69011E61@newserver.arneill-py.local> <7DF2A1C4-1799-486B-A631-2E1119C22A7C@arin.net> <3CCC6D1F-11F4-40BC-B102-CC6744A5E709@virtualized.org> <4DB9BACE.6000307@ipinc.net> <0E134D8B-0A4B-466E-B261-9C7D0ED11867@virtualized.org> <388190E3-08F2-4AC7-870A-621A2FD6EEFE@virtualized.org> <2ABCF380-7866-4ED8-BE43-C789CBEBFE27@delong.com> <53B633A2-A7F6-4BF3-A11B-4981C9A41130@delong.com> <20B2220E-A768-46CE-B19D-AF15D02AD08F@arin.net> Message-ID: On Mon, May 2, 2011 at 8:12 PM, John Curran wrote: > On May 3, 2011, at 2:07 AM, William Herrin wrote: >> Maybe you mean 10b which [..] doesn't even promise >> to leave all the registrant's >> addresses intact... just the ones that "are not currently being >> utilized." > > ? I'm currently looking into this precise phrase, as it appears > ? to combine two concepts incorrectly. ?I'll report back shortly. Hi John, I appreciate it and I encourage you do dig in to it. But at the same time I have to say: this is all minutiae. If you want to draw in the remainder of the legacy registrants, please target the root of the problem. The root of the problem is this: When you or I or anyone else carefully analyze the LRSA and map out what connects to what, the LRSA boils down to this: "I agree to let ARIN take away my addresses (14b2->14e, the contract's default route) unless {9 pages of exceptions to the default}." Regardless of how you write the "exceptions," that just isn't an acceptable basis for a _mutual_ agreement. It's a basis one accepts under duress when no other rational choice is available. When I said a contract simplified to, "We agree to keep your whois data and RDNS delegations intact as is for one year increments until either of us choose to cancel this contract," what I meant to imply was a contract where the default action is "none" and then we go on to discuss the reasonable exceptions to that 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 Wesley.E.George at sprint.com Tue May 3 09:12:37 2011 From: Wesley.E.George at sprint.com (George, Wes E [NTK]) Date: Tue, 3 May 2011 13:12:37 +0000 Subject: [arin-ppml] ARIN-2011-5: Shared Transition Space for IPv4 Address Extension - Last Call In-Reply-To: References: <4DAC8BCB.2000300@arin.net> <54E900DC635DAB4DB7A6D799B3C4CD8E10C7EF5E@PLSWM12A.ad.sprint.com> <3128593549961341875@unknownmsgid> <54E900DC635DAB4DB7A6D799B3C4CD8E10C899B7@PDAWM12B.ad.sprint.com> <1489147144792938659@unknownmsgid> <54E900DC635DAB4DB7A6D799B3C4CD8E10C89AC7@PDAWM12B.ad.sprint.com> <54E900DC635DAB4DB7A6D799B3C4CD8E10C8D92B@PDAWM12B.ad.sprint.com> Message-ID: <54E900DC635DAB4DB7A6D799B3C4CD8E10C8E1F9@PDAWM12B.ad.sprint.com> -----Original Message----- From: wherrin at gmail.com [mailto:wherrin at gmail.com] On Behalf Of William Herrin Sent: Monday, May 02, 2011 7:14 PM To: George, Wes E [NTK] Cc: Scott Leibrand; arin-ppml at arin.net Subject: Re: [arin-ppml] ARIN-2011-5: Shared Transition Space for IPv4 Address Extension - Last Call On Mon, May 2, 2011 at 4:39 PM, George, Wes E [NTK] wrote: > On Mon, Apr 25, 2011 at 8:46 AM, George, Wes E [NTK] wrote: >> IPv4 addresses used behind a NAT (inside pool) cannot be used for >> justification of new resources nor counted towards utilization >> calculations for existing resources. >> NRPM 4.10.x (Shared Transition Space) defines a specific non-unique >> block to be shared among multiple networks for this purpose. > I don't understand your example, specifically how a transfer would figure into the discussion. Please try to rephrase. Sorry, I was being snarky. Under your wording, once I have placed equipment behind a NAT, I can never move it out in front of a NAT because its existence doesn't justify addresses. You could probably fix that particular problem by saying "addresses _intended to be_ used behind a NAT." ______________ [WEG] I'm not totally opposed to that wording change. I don't really think that it's necessary, because I highly doubt that someone would go to the trouble of putting something behind a NAT and *then* decide that they need to go to the transfer market to get more space to undo all of that work, but it's certainly a case that the AC should consider when they (hopefully) update the wording of this policy to address my concern. But there are more problems. For example, addresses behind a bastion host firewall would still qualify even though that's basically the same use as the NAT. That's fundamentally unfair, which violates a basic precept of any public policy process.. And what about folks who decide to consume public addresses inside their stateful non-translating firewalls even though they've locked it down where the only thing that passes is outbound tcp? Is it fair that folks trying to conserve with NAT should pay an additional policy-level penalty while wasters don't? ______________ [WEG] we're not discussing a policy setting aside a /10 for their use, and based on Owen's reply, I think the same would be true for the bastion host firewall. You continue to bring up examples of things that would certainly be open for discussion if the ARIN community decides to legislate network design in the name of IPv4 address conservation, but in this case, it's a red herring. Like I said, I want this policy to cover enforcement/justification on the specific use case that the policy is using to justify setting aside this space. Nothing more. Wes George -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 6753 bytes Desc: not available URL: From kkargel at polartel.com Tue May 3 10:49:17 2011 From: kkargel at polartel.com (Kevin Kargel) Date: Tue, 3 May 2011 09:49:17 -0500 Subject: [arin-ppml] Statistics regarding NRPM 8.3 Transfers to date In-Reply-To: References: <75E9BD24-F12F-42BF-A989-CF6CC282B28E@arin.net> <7406316661701612155@unknownmsgid> <3F57F52B-F1F1-4450-B493-AA4D544D8D15@arin.net> <8740380157159276993@unknownmsgid> <49E26DCB-DAF7-4A0A-912E-F981494979F5@delong.com> <4DBC2AEB.9040307@matthew.at> <4DBCA58D.4060704@sprunk.org> <2344ADD7-616E-4FA7-9552-19735926A952@delong.com> <4DBD9BF5.7050002@sprunk.org> <4DBF2724.6090300@sprunk.org> Message-ID: <8695009A81378E48879980039EEDAD289D0E5BC5@MAIL1.polartel.local> ________________________________ From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Owen DeLong Sent: Monday, May 02, 2011 6:34 PM To: Stephen Sprunk Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] Statistics regarding NRPM 8.3 Transfers to date On May 2, 2011, at 2:50 PM, Stephen Sprunk wrote: On 02-May-11 15:41, Owen DeLong wrote: On May 1, 2011, at 10:44 AM, Stephen Sprunk wrote: On 01-May-11 11:05, Owen DeLong wrote: While I would be fine with ARIN fulfilling your request with 2 /24s that were already disjoint, however, I don't want to see someone with, say, 44/8 find a buyer that needs a /20 and sell them 44.0.5/24, 44.0.8/24, 44.15.23/24, 44.28.6/24, etc. How about this: "The transferor's resources may be recursively bisected the minimum number of times necessary to create one CIDR block equal to the transferee's justified need." So, if someone with a /8 wants to sell you a /20, their /8 would be divided into one /9, one /10, one /11, one /12, one /13, one /14, one /15, one /16, one /17, one /18, one /19 and two /20s, and then you would get one of those /20s. Would it perhaps be simpler to say that transfers of sub-blocks (partial transfers?) must be done on CIDR boundaries from the edge (extremity?) of the donor block ? Kevin -------------- next part -------------- An HTML attachment was scrubbed... URL: From farmer at umn.edu Tue May 3 12:18:56 2011 From: farmer at umn.edu (David Farmer) Date: Tue, 03 May 2011 11:18:56 -0500 Subject: [arin-ppml] ARIN-prop-147 Set Transfer Need to 24 months and Clarify Exception In-Reply-To: <4DBEF12A.2020002@arin.net> References: <4DBEF12A.2020002@arin.net> Message-ID: <4DC02AF0.9020308@umn.edu> While I'm not yet convinced this change is absolutely necessary, and reserve final judgment until this has been fully discussed. However, I support this proposal moving forward and it should be presented and fully discussed in Philadelphia. I think is important that we carefully reevaluate the criteria we have for the evaluation of needs basis in light of the change to market-like competition for IPv4 address space. I think it is important to retain a needs basis, but the needs basis that worked when there was an IANA free pool may not automatically be valid in a market-like situation. On 5/2/11 13:00 CDT, ARIN wrote: > ARIN-prop-147 Set Transfer Need to 24 months and Clarify Exception > > Proposal Originator: Matthew Kaufman > > Proposal Version: 1 > > Date: 2 May 2011 > > Proposal type: new > > Policy term: permanent > > Policy statement: > > Change section 4.2.4.4 content as follows: > > Replace: > "This reduction does not apply to resources received via section 8.3. An > organization receiving a transfer under section 8.3 may continue to > request up to a 12-month supply of IP addresses." > > With: > "This reduction does not apply to resources received via transfer. An > organization receiving a transfer under section 8 may request up to a > 24-month supply of IP addresses." > > Rationale: > > The exception should apply to transfers under 8.2 as well as 8.3 (and > any future transfer policies). > > Due to the complexity of the financial transaction that may be > involved and the associated budgeting on the part of the receiving > organization, 24 months is a more reasonable amount of forecast need to > allow to be fulfilled via the transfer process. > > Potential benefit to address aggregation by allowing fewer larger > transfers sooner. > > 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. -- =============================================== 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 john.sweeting at gmail.com Tue May 3 12:48:36 2011 From: john.sweeting at gmail.com (John Sweeting) Date: Tue, 3 May 2011 12:48:36 -0400 Subject: [arin-ppml] Fw: Accusation of fundamental conflict ofinterest/IPaddress policy pitched directly to ICANN In-Reply-To: References: Message-ID: It really is as easy as rounding up all the support you can muster, have that support join PPML, submit the proposal that you would like see made policy and then have your support show their support through PPML and the next PPM. Is there a reason you do not want to follow that process? It might help gain support if you provided your underlying motivation(s). On Mon, May 2, 2011 at 8:43 PM, Mike Burns wrote: > No, I want the question of whether to allow competitive non-regional > registries to be decided by an entity other than one composed of > non-competitive regional registries who currently enjoy a monopoly on > registration services. > > There is a conflict of interest there. Let the venue be moved to a higher > level. > > Regards, > > Mike > > ----- Original Message ----- From: "Owen DeLong" > > To: "Mike Burns" > Cc: "McTim" ; > Sent: Monday, May 02, 2011 6:28 PM > Subject: Re: [arin-ppml] Fw: Accusation of fundamental conflict > ofinterest/IPaddress policy pitched directly to ICANN > > > > So your argument boils down to: > > I don't like who the communities elected, so, I want to shop for a > different forum? > > Owen > > On May 2, 2011, at 1:13 PM, Mike Burns wrote: > > Hi Tim, >> >> Just read the names of the committe members. >> Enough said. >> >> Regards, >> Mike >> >> ----- Original Message ----- From: "McTim" >> To: "Mike Burns" >> Cc: >> Sent: Monday, May 02, 2011 4:06 PM >> Subject: Re: Fw: [arin-ppml] Accusation of fundamental conflict >> ofinterest/IPaddress policy pitched directly to ICANN >> >> >> On Mon, May 2, 2011 at 7:48 PM, Mike Burns >> wrote: >> >>> Can you be more specific? The ICANN ASO? the ICANN BoT? the IANA? >>>> >>> >>> Hi Tim, >>> >>> Keep going, all the organizations above are suspect due to the fact that >>> they are all comprised of the same basic group of RIR designees. >>> >> >> The RIRs do not "designate" or appoint anyone to any of the above >> bodies. The ASO AC members are elected by their respective RIR >> communities. Those ASO AC members do have a role to play in choosing >> 2 (IIRC) of the ICANN Board. Neither the RIRs nor the ASO get to >> choose IANA staff. >> >> >>> I would take it to NTIA like DNS. >>> >> >> I think you overestimate the role of the NTIA in the DNS. >> >> >>> And I would use DNS as a template for the creation of the global policy >>> restrictions John Curran asked about, which restrictions would apply to >>> all >>> registries, regional or commercial. >>> Just as all DNS registrars must meet certain qualifications, so would >>> private registries of number space. >>> >>> Let the NTIA hear arguments from the proposer and from the ASO, the ICANN >>> BoT, and IANA, although I suspect they will all sound the same. >>> >> >> >> Back in the 1990's, the idea was for the USG to divest itself (via >> ICANN) of the naming and numbering roles. That process is still >> ongoing, and one can see a certain acceleration of divestiture in >> recent years. The Affirmation of Commitments is, I think, an example >> of this. >> >> As DF has indicated, this (asking the NTIA to make this kind of >> determination) would be a real non-starter for the global Internet >> Governance community. >> >> -- >> Cheers, >> >> McTim >> "A name indicates what we seek. An address indicates where it is. A >> route indicates how we get there." Jon Postel >> _______________________________________________ >> 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 owen at delong.com Tue May 3 13:18:01 2011 From: owen at delong.com (Owen DeLong) Date: Tue, 3 May 2011 10:18:01 -0700 Subject: [arin-ppml] ARIN-prop-146 Clarify Justified Need for Transfers In-Reply-To: <4DBF82F6.7050608@matthew.at> References: <4DBEF120.4080901@arin.net> <88F39B20-5C20-45F0-AD61-5FA1E7F84CE3@delong.com> <3FCD1FDC-ECEE-4C9B-95C6-59E03D3C314E@matthew.at> <5598DFC7-E320-42FA-AA0E-C91C076BD725@delong.com> <6BA1EAA6-7D9C-44F9-BED7-884720F4B3BE@matthew.at> <05FAA29B-37BE-411C-95A4-50437602C8ED@delong.com> <4DBF6727.1090303@matthew.at> <097AAC1C-1F68-4820-9274-3290ADEFA195@delong.com> <4DBF75B7.3010407@matthew.at> <9501EA7E-FDAD-4DDA-B9E8-08C2811FF642@delong.com> <4DBF82F6.7050608@matthew.at> Message-ID: On May 2, 2011, at 9:22 PM, Matthew Kaufman wrote: > On 5/2/2011 8:47 PM, Owen DeLong wrote: >> >> Welcome to the post-run-out world. Why should we let you acquire more space now and deny that >> space to someone else who has justified need now? > > Because I can afford it and have taken the time to find a seller. > > Or were you planning on enacting price controls on the market as well? > No, I think justified need is the only required control on the market. I don't see a need for price controls, but, I do see a need to ensure that people like you do not get excessive address space just because you have greater financial resources vs. others who need it now, but have lesser financial resources. Owen From owen at delong.com Tue May 3 13:20:30 2011 From: owen at delong.com (Owen DeLong) Date: Tue, 3 May 2011 10:20:30 -0700 Subject: [arin-ppml] ARIN-prop-146 Clarify Justified Need for Transfers In-Reply-To: <4DBF8399.3010908@matthew.at> References: <4DBEF120.4080901@arin.net> <88F39B20-5C20-45F0-AD61-5FA1E7F84CE3@delong.com> <3FCD1FDC-ECEE-4C9B-95C6-59E03D3C314E@matthew.at> <5598DFC7-E320-42FA-AA0E-C91C076BD725@delong.com> <6BA1EAA6-7D9C-44F9-BED7-884720F4B3BE@matthew.at> <05FAA29B-37BE-411C-95A4-50437602C8ED@delong.com> <4DBF6727.1090303@matthew.at> <097AAC1C-1F68-4820-9274-3290ADEFA195@delong.com> <4DBF75B7.3010407@matthew.at> <9501EA7E-FDAD-4DDA-B9E8-08C2811FF642@delong.com> <4DBF8399.3010908@matthew.at> Message-ID: <38B522F3-4DEE-431A-97FD-EB959A80915D@delong.com> On May 2, 2011, at 9:24 PM, Matthew Kaufman wrote: > On 5/2/2011 8:47 PM, Owen DeLong wrote: >> >> Welcome to the post-run-out world. Why should we let you acquire more space now and deny that >> space to someone else who has justified need now? > > And why, exactly do we have a rule now that you can only get 3 months of space for initial allocations? Everyone who isn't an initial allocation *can* get 12 months via the transfer market... what makes them special or any more deserving of the fruits of a transfer market? > Because initial recipients (and those without a 12 month track record in ARIN as yet) tend to vastly overestimate their need and often end up using well under the amount for which they express initial justification. The three month rule has proven over time to be a good balance allowing frequent re-evaluation of their progress and building a trend line that staff can use for subsequent allocations. This is not a new rule and not a rule which was related to imminent runout. It has been on the books for a very long time. > What I think will happen is that anyone with enough money to afford 12 months of address space can afford to do something to work around this rule... possibly failing to update the whois database in the process. > I'm sure that's a distinct possibility. Hopefully ARIN will become better at identifying, reclaiming, and re-issuing addresses which are transferred outside of the ARIN process. Owen From mike at nationwideinc.com Tue May 3 13:22:33 2011 From: mike at nationwideinc.com (Mike Burns) Date: Tue, 3 May 2011 13:22:33 -0400 Subject: [arin-ppml] Fw: Accusation of fundamental conflictofinterest/IPaddress policy pitched directly to ICANN References: Message-ID: <9530E12B9CC944FBBF035847C34427B7@mike> It really is as easy as rounding up all the support you can muster, have that support join PPML, submit the proposal that you would like see made policy and then have your support show their support through PPML and the next PPM. Is there a reason you do not want to follow that process? It might help gain support if you provided your underlying motivation(s). -John Sweeting Hi John, My interest is in having a market for the buying and selling of IP addresses free from government and psuedo-government restrictions like taxes and justification requirements. I think this will best serve the interests of a community long held in thrall to the vision of an IPv6 transition that simply has not occurred in anything like the predicted timeframe. I would prefer that any support I find not be motivated by perceptions of my motivations, just my words and ideas. I voiced support for the concept of having a informed higher authority make the decision about competing registries requested in the letter which started the thread. I support competing registries because I believe that their competitive forces will move the market towards freedom, and because presumably a competing registry could decide its own, more liberal transfer policy. My understanding is that one way to get that accomplished, and I will accede it would be the better way, would be for the participants in policy making in all 5 RIRs come together to forge a policy allowing for competing private registries. But I think that is like expecting Network Solutions to have voted for competing DNS registrars. Unlikely to happen due to institutional conflicts of interest. (I understand that NetSol was not a community run org like the RIRs, but I see a natural institutional conflict between those who dominate a closed market and those who seek to expand it.) (And yes, this is also a commentary on the tiny number of participants who seem to people the RIR executive positions, and by extension the tiny groups of vocal participants in the RIR-PPML process.) (And yes, I have lost trust in ARIN staff since the MS/Nortel debacle) But nobody seems too sure what that higher authority is, and of course some participants see the community of RIR-PPML participants as the highest authority of all. I didn't write that letter, nor do I have any relationship with the writer of the letter, to my knowledge I have never met, conversed, or emailed with him. As for changing policy in the ARIN region, that is my intent, and I have heard from another poster who is interested in co-sponsoring a proposal designed to create a free market for ip transfers. So I will work with him to do just as you say, round up support and see if we can get a proposal that passes muster with the PPML and can be included in the next PPM. Regards, Mike Burns -------------- next part -------------- An HTML attachment was scrubbed... URL: From owen at delong.com Tue May 3 13:26:29 2011 From: owen at delong.com (Owen DeLong) Date: Tue, 3 May 2011 10:26:29 -0700 Subject: [arin-ppml] ARIN-prop-146 Clarify Justified Need for Transfers In-Reply-To: <4DBF8F66.1090708@umn.edu> References: <4DBEF120.4080901@arin.net> <88F39B20-5C20-45F0-AD61-5FA1E7F84CE3@delong.com> <3FCD1FDC-ECEE-4C9B-95C6-59E03D3C314E@matthew.at> <5598DFC7-E320-42FA-AA0E-C91C076BD725@delong.com> <6BA1EAA6-7D9C-44F9-BED7-884720F4B3BE@matthew.at> <05FAA29B-37BE-411C-95A4-50437602C8ED@delong.com> <4DBF6727.1090303@matthew.at> <097AAC1C-1F68-4820-9274-3290ADEFA195@delong.com> <4DBF75B7.3010407@matthew.at> <9501EA7E-FDAD-4DDA-B9E8-08C2811FF642@delong.com> <4DBF8F66.1090708@umn.edu> Message-ID: <03DA3371-4B75-47D8-BEF2-4F37EBC5A411@delong.com> On May 2, 2011, at 10:15 PM, David Farmer wrote: > On 5/2/11 22:47 CDT, Owen DeLong wrote: >> >> On May 2, 2011, at 8:25 PM, Matthew Kaufman wrote: >> >>> On 5/2/2011 8:16 PM, Owen DeLong wrote: >>>> On May 2, 2011, at 7:23 PM, Matthew Kaufman wrote: >>>> >>>>> On 5/2/2011 6:56 PM, Owen DeLong wrote: >>>>>> On May 2, 2011, at 5:05 PM, Matthew Kaufman wrote: >>>>>> >>>>>>> If you qualify for an 8.3 transfer there is NO reason that transfer should fall under the 3-month rules, which right now, in many cases, it does... without a change like the one I have proposed. >>>>>>> >>>>>> Please cite such a case because as it currently stands, I don't believe that to be >>>>>> accurate. >>>>>> >>>>> A. My hypothetical ISP provides service to a small town. I presently get two /24s of IPv4 space from my upstream provider and I'm using them at about 85%. ARIN has run completely out of addresses. A benefactor arrives and offers to transfer a /22 to me and pay for me to multihome. >>>>> >>>>> I attempt to use 4.2.2.2 (Initial Allocation to ISPs, Multihomed) for my justification. I need to demonstrate that I am efficiently using the two /24s. Done. I comply with 4.2.2.2.1 (SWIP). I attempt to comply with 4.2.2.2.2, but my growth shows that I won't really need more than a /23 for about 7 months. Transfer would be denied because 4.2.2.2.2 has a three month rule (as I claimed above). Benefactor takes his space elsewhere, and I lose out. >>>>> >>>> I'm not seeing the problem. You wouldn't have gotten the space from ARIN before runout, I don't see why you >>>> should get it now from a transfer. >>> >>> Because post-runout is a different world. Pre-runout I get 3 months of space, I use it, I go back to ARIN, I get 3 more months, I use it, I go back to ARIN and this time I get a whole year. >>> >> And you can do that with the market as well. > > Owen, > > The availability of space in 3-months could be completely different at that time then now, in a market-like situation for address space why should a new ISP not be able to compete on equal footing with an established ISP. I don't buy the nothing should change argument, there are a number of issues we probably should reconsider when you have to compete in a market-like situation for addresses as opposed to having an IANA free pool. > That's true in the pre-runout world of today as well. In three months it could go from available from RIR to not available from RIR. We can agree to disagree, but, I think that slow start should still apply. > I'm not convinced that we should abandon a needs basis, but we do need to reevaluate things and make sure the needs basis we had when there was an IANA free pool is still valid when you are competing in a market-like situation for addresses. > I have considered the situation and I believe it to be still valid. > I think it is reasonable to reconsider slow-start and other rules for new ISPs in a world where there isn't an IANA free pool. Furthermore, I'm worried that if we are not willing to discuss adjusting a few reasonable things it only strengthens the calls for completely abandoning a needs basis. > > If we are not going to let new ISPs compete on an equal footing then maybe we need an additional reservation for them to provide them with addresses until they can compete on an equal footing. However, at this point I think it is just easier to relax slow-start and other requirements. > Post exhaustion, there is no such thing as a new IPv4 service on an equal footing with established ones. Any attempt to create such a situation is based in delusional optimism. Once the RIRs run out, transfers are about limping existing uses of IPv4 along until they can make it to IPv6. Attempting to preserve capabilities for new entrants to build IPv4 based infrastructures is both ill-advised and unlikely to have the desired effect. Owen From Keith at jcc.com Tue May 3 13:56:28 2011 From: Keith at jcc.com (Keith W. Hare) Date: Tue, 3 May 2011 13:56:28 -0400 Subject: [arin-ppml] Fw: Accusation of fundamental conflictofinterest/IPaddress policy pitched directly to ICANN In-Reply-To: <9530E12B9CC944FBBF035847C34427B7@mike> References: <9530E12B9CC944FBBF035847C34427B7@mike> Message-ID: Mike, So far, we have seen only bits of policy proposals that hint at the idea of competing private address registries. Without a policy proposal that covers all of the details, we are left to extrapolate the remaining pieces. This extrapolation may or may not be what competing address registry proponents have in mind, but until we see a full policy proposal, we are left with only perceptions of your (and others) motivations. Keith From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Mike Burns Sent: Tuesday, May 03, 2011 1:23 PM To: John Sweeting Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] Fw: Accusation of fundamental conflictofinterest/IPaddress policy pitched directly to ICANN It really is as easy as rounding up all the support you can muster, have that support join PPML, submit the proposal that you would like see made policy and then have your support show their support through PPML and the next PPM. Is there a reason you do not want to follow that process? It might help gain support if you provided your underlying motivation(s). -John Sweeting Hi John, My interest is in having a market for the buying and selling of IP addresses free from government and psuedo-government restrictions like taxes and justification requirements. I think this will best serve the interests of a community long held in thrall to the vision of an IPv6 transition that simply has not occurred in anything like the predicted timeframe. I would prefer that any support I find not be motivated by perceptions of my motivations, just my words and ideas. I voiced support for the concept of having a informed higher authority make the decision about competing registries requested in the letter which started the thread. I support competing registries because I believe that their competitive forces will move the market towards freedom, and because presumably a competing registry could decide its own, more liberal transfer policy. My understanding is that one way to get that accomplished, and I will accede it would be the better way, would be for the participants in policy making in all 5 RIRs come together to forge a policy allowing for competing private registries. But I think that is like expecting Network Solutions to have voted for competing DNS registrars. Unlikely to happen due to institutional conflicts of interest. (I understand that NetSol was not a community run org like the RIRs, but I see a natural institutional conflict between those who dominate a closed market and those who seek to expand it.) (And yes, this is also a commentary on the tiny number of participants who seem to people the RIR executive positions, and by extension the tiny groups of vocal participants in the RIR-PPML process.) (And yes, I have lost trust in ARIN staff since the MS/Nortel debacle) But nobody seems too sure what that higher authority is, and of course some participants see the community of RIR-PPML participants as the highest authority of all. I didn't write that letter, nor do I have any relationship with the writer of the letter, to my knowledge I have never met, conversed, or emailed with him. As for changing policy in the ARIN region, that is my intent, and I have heard from another poster who is interested in co-sponsoring a proposal designed to create a free market for ip transfers. So I will work with him to do just as you say, round up support and see if we can get a proposal that passes muster with the PPML and can be included in the next PPM. Regards, Mike Burns -------------- next part -------------- An HTML attachment was scrubbed... URL: From v6ops at globis.net Tue May 3 13:56:35 2011 From: v6ops at globis.net (Ray Hunter) Date: Tue, 03 May 2011 19:56:35 +0200 Subject: [arin-ppml] Fw: Accusation of fundamental, conflictofinterest/IPaddress policy pitched directly to ICANN Message-ID: <4DC041D3.7030404@globis.net> Whilst I don't necessarily agree than an IPv4 address has any "value", and it's your idea to create an (artificial) market where address allocations attract a hard dollar value (which they traditionally haven't had), I would note the following concern: Any legal entity that transfers an intangible asset across an (international) border for a payment is almost certainly going to attract the attention of more than one government entity regarding accounting and taxation, not least for Value Added Tax, international transfer pricing, avoidance of income tax ...... See for example http://www.kluwerlaw.com/Catalogue/titleinfo.htm?ProdID=904119925X TheARIN service region includes Canada, many Caribbean and North Atlantic islands, and the United States. The Internet is even bigger. So would your market free of government restrictions and taxes be international, limited to national boundaries? NAFTA? state boundaries? or what? Would corporations and not for profit entities now have to enter an asset value in their annual accounts for the value of an IPv4 allocation? If something has a value, and can therefore be taxed, it's much more likely to attract more government control, not less. Just look at the wireless spectrum allocation auctions. Is this what you want for the Internet? Be careful what you wish for. regards, RayH > My interest is in having a market for the buying and selling of IP addresses free from government and psuedo-government restrictions like taxes and justification requirements. > > Regards, > > Mike Burns -------------- next part -------------- An HTML attachment was scrubbed... URL: From hannigan at gmail.com Tue May 3 14:13:59 2011 From: hannigan at gmail.com (Martin Hannigan) Date: Tue, 3 May 2011 14:13:59 -0400 Subject: [arin-ppml] Fw: Accusation of fundamental, conflictofinterest/IPaddress policy pitched directly to ICANN In-Reply-To: <4DC041D3.7030404@globis.net> References: <4DC041D3.7030404@globis.net> Message-ID: On Tue, May 3, 2011 at 1:56 PM, Ray Hunter wrote: > Whilst I don't necessarily agree than an IPv4 address has any "value", and > it's your idea to create an (artificial) market where address allocations > attract a hard dollar value (which they traditionally haven't had), I would We have seen legacy IPv4 addresses space exchange hands for cash. That's not in question (for most people) and I'm not sure why you think that it may be. > note the following concern: Any legal entity that transfers an intangible > asset across an (international) border for a payment is almost certainly > going to attract the attention of more than one government entity regarding > accounting and taxation, not least for Value Added Tax, international > transfer pricing, avoidance of income tax ...... > > See for example > http://www.kluwerlaw.com/Catalogue/titleinfo.htm?ProdID=904119925X > > The ARIN service region includes Canada, many Caribbean and North Atlantic > islands, and the United States. The Internet is even bigger. > > So would your market free of government restrictions and taxes be > international, limited to national boundaries? NAFTA? state boundaries? or > what? > > Would corporations and not for profit entities now have to enter an asset > value in their annual accounts for the value of an IPv4 allocation? > > If something has a value, and can therefore be taxed, it's much more likely > to attract more government control, not less. Just look at the wireless > spectrum allocation auctions. Is this what you want for the Internet? > > Be careful what you wish for. > [ .. ] > My interest is in having a market for the buying and selling of IP addresses > free from government and psuedo-government restrictions like taxes and > justification requirements. Providing a return on the investment initially provided for by the taxpayers of the United States is not a bad thing. Thinking that one could or even should be able to engage in transactions involving such large sums of money and avoid scrutiny by government is "too good to be true". Best, -M< From mueller at syr.edu Tue May 3 14:26:41 2011 From: mueller at syr.edu (Milton L Mueller) Date: Tue, 3 May 2011 14:26:41 -0400 Subject: [arin-ppml] Analogies In-Reply-To: References: <39209.1303885464@tristatelogic.com> <75822E125BCB994F8446858C4B19F0D7173057C827@SUEX07-MBX-04.ad.syr.edu> <471D76419F9EF642962323D13DF1DF69011E5C@newserver.arneill-py.local> <7348D3C8-4EB7-4440-A152-210CC8B0DA3C@arin.net> <471D76419F9EF642962323D13DF1DF69011E60@newserver.arneill-py.local> <583A067A-B8AE-4026-844E-6769D1D7CF88@arin.net> <471D76419F9EF642962323D13DF1DF69011E61@newserver.arneill-py.local> <7DF2A1C4-1799-486B-A631-2E1119C22A7C@arin.net> <3CCC6D1F-11F4-40BC-B102-CC6744A5E709@virtualized.org> <4DB9BACE.6000307@ipinc.net> <0E134D8B-0A4B-466E-B261-9C7D0ED11867@virtualized.org> <388190E3-08F2-4AC7-870A-621A2FD6EEFE@virtualized.org> <2ABCF380-7866-4ED8-BE43-C789CBEBFE27@delong.com> <8D07F7F5-7E60-4176-A5D3-929F160AC608@arin.net> Message-ID: <75822E125BCB994F8446858C4B19F0D7173051802C@SUEX07-MBX-04.ad.syr.edu> > ARIN probably needs to surrender the ability to revoke IP > Addresses based on censorship grounds back to the community, > by putting a clause in the RSA restricting ARIN from revoking > resources for that reason, if it even has > maintained such an ability, so a policy cannot ever revoke > resources for the purpose of targetting content served by > hosts using an IP address. This is a great idea. I commend you for having it. I would urge that it be a flat prohibition, not a "surrender...back to the community." It involves a separation of functions that should be very clear and rigid. In other words, I agree with this: ARIN is concerned with stewardship of resources, and management of what content or traffic can be exchanged by hosts assigned those resources, is, and should be out of the scope of IP addressing and DNS policy. Let's be somewhat careful here. Are you saying that we should protect the rights of snowshoe spammers to obtain vast quantities of resources, for example? [Milton L Mueller] My understanding of snowshoe spamming is that it constitutes a misappropriation of others' resources; it has nothing to do with content per se. Take it from someone with deep experience of the ICANN environment: you want to avoid loading IP address allocation with extraneous regulatory functions. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike at nationwideinc.com Tue May 3 14:43:10 2011 From: mike at nationwideinc.com (Mike Burns) Date: Tue, 3 May 2011 14:43:10 -0400 Subject: [arin-ppml] Fw: Accusation of fundamentalconflictofinterest/IPaddress policy pitched directly to ICANN References: <9530E12B9CC944FBBF035847C34427B7@mike> Message-ID: <39C6443F1C974EF09CCC764D1CAEA2CD@mike> Hi Keith, I don't care much about private registries, that is not the thrust of my proposal. I do think this nascent market would evolve more robustly in an environment were customers (address holders) could shop for registries who compete on price and performance. But this thread is related to a letter to ICANN proposing to have a decision made at that level in order to counter perceived conflict of interest at the RIR/ASO level. I supported that idea because I believe that private registries are a good idea, and I do think there is a conflict, but there was no proposal involved, ever. I think Mr. McTim posted a notice to the list regarding some rather dated correspondence on ICANN's page. I merely supported the letter writer's position. If I offer a proposal to the ARIN-PPML, it will be to remove all justification requirements for all transfers, while retaining them for the free pool. Per David Farmer advice about repeating, I repeat: This would 1. Level the playing field between RSA and LRSAs, and in combination with the simplified LRSA Mr. Herrin has proposed, will have the effect of bringing many legacy addresses under agreement. 2. Allow for ARIN to accurately depict inevitable MS/Nortel-type future transfers as being done within policy 3. Steward the addresses to their most efficient use as determined by free market price 4. Save ARIN a lot of time and money 5. Encourage accurate POC information for legacy addresses which have changed hands outside ARIN purview. 6. Bring ARIN into compliance with the stewardship policies of the RIR with the highest demand and closest to exhaust 7 End these angels-on-the-head-of-a-pin discussions about single aggregate policy and 3, 12, or 24 month needs analyses for transfers 8 It will moot the need to protect STLS listers from ARIN poaching, increasing supply and reducing price Regards Mike ----- Original Message ----- From: Keith W. Hare To: Mike Burns ; arin-ppml at arin.net Sent: Tuesday, May 03, 2011 1:56 PM Subject: RE: [arin-ppml] Fw: Accusation of fundamentalconflictofinterest/IPaddress policy pitched directly to ICANN Mike, So far, we have seen only bits of policy proposals that hint at the idea of competing private address registries. Without a policy proposal that covers all of the details, we are left to extrapolate the remaining pieces. This extrapolation may or may not be what competing address registry proponents have in mind, but until we see a full policy proposal, we are left with only perceptions of your (and others) motivations. Keith From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Mike Burns Sent: Tuesday, May 03, 2011 1:23 PM To: John Sweeting Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] Fw: Accusation of fundamental conflictofinterest/IPaddress policy pitched directly to ICANN It really is as easy as rounding up all the support you can muster, have that support join PPML, submit the proposal that you would like see made policy and then have your support show their support through PPML and the next PPM. Is there a reason you do not want to follow that process? It might help gain support if you provided your underlying motivation(s). -John Sweeting Hi John, My interest is in having a market for the buying and selling of IP addresses free from government and psuedo-government restrictions like taxes and justification requirements. I think this will best serve the interests of a community long held in thrall to the vision of an IPv6 transition that simply has not occurred in anything like the predicted timeframe. I would prefer that any support I find not be motivated by perceptions of my motivations, just my words and ideas. I voiced support for the concept of having a informed higher authority make the decision about competing registries requested in the letter which started the thread. I support competing registries because I believe that their competitive forces will move the market towards freedom, and because presumably a competing registry could decide its own, more liberal transfer policy. My understanding is that one way to get that accomplished, and I will accede it would be the better way, would be for the participants in policy making in all 5 RIRs come together to forge a policy allowing for competing private registries. But I think that is like expecting Network Solutions to have voted for competing DNS registrars. Unlikely to happen due to institutional conflicts of interest. (I understand that NetSol was not a community run org like the RIRs, but I see a natural institutional conflict between those who dominate a closed market and those who seek to expand it.) (And yes, this is also a commentary on the tiny number of participants who seem to people the RIR executive positions, and by extension the tiny groups of vocal participants in the RIR-PPML process.) (And yes, I have lost trust in ARIN staff since the MS/Nortel debacle) But nobody seems too sure what that higher authority is, and of course some participants see the community of RIR-PPML participants as the highest authority of all. I didn't write that letter, nor do I have any relationship with the writer of the letter, to my knowledge I have never met, conversed, or emailed with him. As for changing policy in the ARIN region, that is my intent, and I have heard from another poster who is interested in co-sponsoring a proposal designed to create a free market for ip transfers. So I will work with him to do just as you say, round up support and see if we can get a proposal that passes muster with the PPML and can be included in the next PPM. Regards, Mike Burns -------------- next part -------------- An HTML attachment was scrubbed... URL: From john.sweeting at gmail.com Tue May 3 14:46:39 2011 From: john.sweeting at gmail.com (John Sweeting) Date: Tue, 3 May 2011 14:46:39 -0400 Subject: [arin-ppml] Fw: Accusation of fundamental conflictofinterest/IPaddress policy pitched directly to ICANN In-Reply-To: <9530E12B9CC944FBBF035847C34427B7@mike> References: <9530E12B9CC944FBBF035847C34427B7@mike> Message-ID: On Tue, May 3, 2011 at 1:22 PM, Mike Burns wrote: > * > It really is as easy as rounding up all the support you can muster, have > that support join PPML, submit the proposal that you would like see made > policy and then have your support show their support through PPML and the > next PPM. Is there a reason you do not want to follow that process? It might > help gain support if you provided your underlying motivation(s). > -John Sweeting > * > Hi John, > > My interest is in having a market for the buying and selling of IP > addresses free from government and psuedo-government restrictions like taxes > and justification requirements. > I think this will best serve the interests of a community long held in > thrall to the vision of an IPv6 transition that simply has not occurred in > anything like the predicted timeframe. > I would prefer that any support I find not be motivated by perceptions of > my motivations, just my words and ideas. > Thanks for sharing this. > > I voiced support for the concept of having a informed higher authority make > the decision about competing registries requested in the letter which > started the thread. I support competing registries because I believe that > their competitive forces will move the market towards freedom, and because > presumably a competing registry could decide its own, more liberal transfer > policy. > > My understanding is that one way to get that accomplished, and I will > accede it would be the better way, would be for the participants in policy > making in all 5 RIRs come together to forge a policy allowing for competing > private registries. > > But I think that is like expecting Network Solutions to have voted > for competing DNS registrars. Unlikely to happen due to institutional > conflicts of interest. > (I understand that NetSol was not a community run org like the RIRs, but I > see a natural institutional conflict between those who dominate a > closed market and those who seek to expand it.) > Understand. > (And yes, this is also a commentary on the tiny number of participants who > seem to people the RIR executive positions, and by extension the tiny groups > of vocal participants in the RIR-PPML process.) > The AC would love to see participation from a greater number of participants as well, it helps us when we are working on policies. One thing I have noticed over the years that when things start to go against the majority's wishes, they do speak up. > (And yes, I have lost trust in ARIN staff since the MS/Nortel debacle) > Sorry to hear that but for me, not knowing all the facts and intricacies involved, my respect and trust for ARIN staff has grown. I do not know of a professional organization that takes their commitment to their members any more seriously than the folks at ARIN. > > But nobody seems too sure what that higher authority is, and of course some > participants see the community of RIR-PPML participants as the highest > authority of all. > I, for one, echo that sentiment but would expand it to the whole of the world community as PPML is just one vehicle for getting your voice heard. > > I didn't write that letter, nor do I have any relationship with the writer > of the letter, to my knowledge I have never met, conversed, or emailed with > him. > > As for changing policy in the ARIN region, that is my intent, and I have > heard from another poster who is interested in co-sponsoring a proposal > designed to create a free market for ip transfers. > That is great, looking forward to seeing your proposal. Thank you for participating. > > So I will work with him to do just as you say, round up support and see if > we can get a proposal that passes muster with the PPML and can be included > in the next PPM. > Very good and thanks again. -john > > Regards, > > Mike Burns > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike at nationwideinc.com Tue May 3 14:46:27 2011 From: mike at nationwideinc.com (Mike Burns) Date: Tue, 3 May 2011 14:46:27 -0400 Subject: [arin-ppml] Fw: Accusation of fundamental, conflictofinterest/IPaddresspolicy pitched directly to ICANN References: <4DC041D3.7030404@globis.net> Message-ID: <250CB859F41D4C6FB7DAA2DFDE59BEB4@mike> Taxation of the Internet is a local government matter. In the States political pressure has resulted in little to no taxation. The same forces will act on these new assets. Taxes are bad, but their existence is no reason to avoid a market. Regards, Mike ----- Original Message ----- From: Ray Hunter To: arin-ppml at arin.net ; Mike Burns Sent: Tuesday, May 03, 2011 1:56 PM Subject: Re: [arin-ppml] Fw: Accusation of fundamental, conflictofinterest/IPaddresspolicy pitched directly to ICANN Whilst I don't necessarily agree than an IPv4 address has any "value", and it's your idea to create an (artificial) market where address allocations attract a hard dollar value (which they traditionally haven't had), I would note the following concern: Any legal entity that transfers an intangible asset across an (international) border for a payment is almost certainly going to attract the attention of more than one government entity regarding accounting and taxation, not least for Value Added Tax, international transfer pricing, avoidance of income tax ...... See for example http://www.kluwerlaw.com/Catalogue/titleinfo.htm?ProdID=904119925X The ARIN service region includes Canada, many Caribbean and North Atlantic islands, and the United States. The Internet is even bigger. So would your market free of government restrictions and taxes be international, limited to national boundaries? NAFTA? state boundaries? or what? Would corporations and not for profit entities now have to enter an asset value in their annual accounts for the value of an IPv4 allocation? If something has a value, and can therefore be taxed, it's much more likely to attract more government control, not less. Just look at the wireless spectrum allocation auctions. Is this what you want for the Internet? Be careful what you wish for. regards, RayH My interest is in having a market for the buying and selling of IP addresses free from government and psuedo-government restrictions like taxes and justification requirements. Regards, Mike Burns -------------- next part -------------- An HTML attachment was scrubbed... URL: From Daniel_Alexander at Cable.Comcast.com Tue May 3 14:49:48 2011 From: Daniel_Alexander at Cable.Comcast.com (Alexander, Daniel) Date: Tue, 3 May 2011 18:49:48 +0000 Subject: [arin-ppml] Fw: Accusation of fundamental conflictofinterest/IPaddress policy pitched directly to ICANN In-Reply-To: Message-ID: Mike, As one of the AC shepherds for the proposals that were abandoned, I would offer one suggestion. Feel free to vet the proposal language you are considering here on this list prior to submitting an actual proposal. That is what this list is for. It would also help refine the scope that Keith mentions, and avoid the confusion that earlier proposals created. It is much easier to refine and evolve policy language on the ppml before it becomes part of the PDP process. If you look back to proposals 133, 134, and 136, they suggested that resource holders could opt-in, opt-out, or find the lowest common denominator to establish claim. While this would allow for what you propose, they offered none of the oversight that you advocate, which is also why there was such a cold reception. You can see how a competing registry, that is operating properly, could do so in a complimentary manner to the RIR. One thing people will have issue with is how the overall model can exist with the individuals who would try to create registries that would not apply similar standards of operation. Without any protections, the ISP's who would have to rely on this data would not be able to depend on the overall system (not referring to any particular registry) which is the shift in burden I mentioned in an earlier post. While people may have issues with the quality of whois, or registration of assignments, there is an upside to the current system. In this region, data points to ARIN and anyone can get involved, change the rules, and try and hold ARIN accountable. In the distributed model that is proposed, accountability is spread out, and the ability to resolve conflicts or issues becomes much harder. These are the kind of concerns that need to be addressed in order to gain momentum on a change of this scale. I hope this helps. Dan Alexander ARIN AC- speaking only for myself From: "Keith W. Hare" > Date: Tue, 3 May 2011 13:56:28 -0400 To: Mike Burns >, "arin-ppml at arin.net" > Subject: Re: [arin-ppml] Fw: Accusation of fundamental conflictofinterest/IPaddress policy pitched directly to ICANN Mike, So far, we have seen only bits of policy proposals that hint at the idea of competing private address registries. Without a policy proposal that covers all of the details, we are left to extrapolate the remaining pieces. This extrapolation may or may not be what competing address registry proponents have in mind, but until we see a full policy proposal, we are left with only perceptions of your (and others) motivations. Keith From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Mike Burns Sent: Tuesday, May 03, 2011 1:23 PM To: John Sweeting Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] Fw: Accusation of fundamental conflictofinterest/IPaddress policy pitched directly to ICANN It really is as easy as rounding up all the support you can muster, have that support join PPML, submit the proposal that you would like see made policy and then have your support show their support through PPML and the next PPM. Is there a reason you do not want to follow that process? It might help gain support if you provided your underlying motivation(s). -John Sweeting Hi John, My interest is in having a market for the buying and selling of IP addresses free from government and psuedo-government restrictions like taxes and justification requirements. I think this will best serve the interests of a community long held in thrall to the vision of an IPv6 transition that simply has not occurred in anything like the predicted timeframe. I would prefer that any support I find not be motivated by perceptions of my motivations, just my words and ideas. I voiced support for the concept of having a informed higher authority make the decision about competing registries requested in the letter which started the thread. I support competing registries because I believe that their competitive forces will move the market towards freedom, and because presumably a competing registry could decide its own, more liberal transfer policy. My understanding is that one way to get that accomplished, and I will accede it would be the better way, would be for the participants in policy making in all 5 RIRs come together to forge a policy allowing for competing private registries. But I think that is like expecting Network Solutions to have voted for competing DNS registrars. Unlikely to happen due to institutional conflicts of interest. (I understand that NetSol was not a community run org like the RIRs, but I see a natural institutional conflict between those who dominate a closed market and those who seek to expand it.) (And yes, this is also a commentary on the tiny number of participants who seem to people the RIR executive positions, and by extension the tiny groups of vocal participants in the RIR-PPML process.) (And yes, I have lost trust in ARIN staff since the MS/Nortel debacle) But nobody seems too sure what that higher authority is, and of course some participants see the community of RIR-PPML participants as the highest authority of all. I didn't write that letter, nor do I have any relationship with the writer of the letter, to my knowledge I have never met, conversed, or emailed with him. As for changing policy in the ARIN region, that is my intent, and I have heard from another poster who is interested in co-sponsoring a proposal designed to create a free market for ip transfers. So I will work with him to do just as you say, round up support and see if we can get a proposal that passes muster with the PPML and can be included in the next PPM. Regards, Mike Burns _______________________________________________ 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 mike at nationwideinc.com Tue May 3 15:02:03 2011 From: mike at nationwideinc.com (Mike Burns) Date: Tue, 3 May 2011 15:02:03 -0400 Subject: [arin-ppml] Fw: Accusation of fundamentalconflictofinterest/IPaddress policy pitched directly to ICANN References: Message-ID: <379DB08FB5564ED88230C1B6D6AE80FE@mike> Hi Dan, Yes, I do support the kind of oversight recommended in the letter, using as a model the requirements to be a DNS registrar. Perhaps this alone is justification for the highest level decisionmaking. Since a competing registry would be on the same level as the existing RIR's, in effect we would be asking the RIRs to oversee themselves if we allowed the RIRs to decide the issue, whether at the RIR or ASO level. Quis custodiet ipsos custodes? I do understand and appreciate the beauty of the non-governmental approach to Internet governance. I think the many kinds of conflicts you reference in your last paragraph are likely to be sorted out around the world in courts and legislatures, which I think are probably better suited to that task than ARIN. Much like the evolution (or de-evolution) of the Domain Name System. I will certainly vet any policy proposal I offer here, though can you give me an idea of the timeframe for proposals to be considered at the next AC meeting, should enough support manifest on the list? Regards, Mike ----- Original Message ----- From: Alexander, Daniel To: arin-ppml at arin.net Sent: Tuesday, May 03, 2011 2:49 PM Subject: Re: [arin-ppml] Fw: Accusation of fundamentalconflictofinterest/IPaddress policy pitched directly to ICANN Mike, As one of the AC shepherds for the proposals that were abandoned, I would offer one suggestion. Feel free to vet the proposal language you are considering here on this list prior to submitting an actual proposal. That is what this list is for. It would also help refine the scope that Keith mentions, and avoid the confusion that earlier proposals created. It is much easier to refine and evolve policy language on the ppml before it becomes part of the PDP process. If you look back to proposals 133, 134, and 136, they suggested that resource holders could opt-in, opt-out, or find the lowest common denominator to establish claim. While this would allow for what you propose, they offered none of the oversight that you advocate, which is also why there was such a cold reception. You can see how a competing registry, that is operating properly, could do so in a complimentary manner to the RIR. One thing people will have issue with is how the overall model can exist with the individuals who would try to create registries that would not apply similar standards of operation. Without any protections, the ISP's who would have to rely on this data would not be able to depend on the overall system (not referring to any particular registry) which is the shift in burden I mentioned in an earlier post. While people may have issues with the quality of whois, or registration of assignments, there is an upside to the current system. In this region, data points to ARIN and anyone can get involved, change the rules, and try and hold ARIN accountable. In the distributed model that is proposed, accountability is spread out, and the ability to resolve conflicts or issues becomes much harder. These are the kind of concerns that need to be addressed in order to gain momentum on a change of this scale. I hope this helps. Dan Alexander ARIN AC- speaking only for myself From: "Keith W. Hare" Date: Tue, 3 May 2011 13:56:28 -0400 To: Mike Burns , "arin-ppml at arin.net" Subject: Re: [arin-ppml] Fw: Accusation of fundamental conflictofinterest/IPaddress policy pitched directly to ICANN Mike, So far, we have seen only bits of policy proposals that hint at the idea of competing private address registries. Without a policy proposal that covers all of the details, we are left to extrapolate the remaining pieces. This extrapolation may or may not be what competing address registry proponents have in mind, but until we see a full policy proposal, we are left with only perceptions of your (and others) motivations. Keith From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Mike Burns Sent: Tuesday, May 03, 2011 1:23 PM To: John Sweeting Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] Fw: Accusation of fundamental conflictofinterest/IPaddress policy pitched directly to ICANN It really is as easy as rounding up all the support you can muster, have that support join PPML, submit the proposal that you would like see made policy and then have your support show their support through PPML and the next PPM. Is there a reason you do not want to follow that process? It might help gain support if you provided your underlying motivation(s). -John Sweeting Hi John, My interest is in having a market for the buying and selling of IP addresses free from government and psuedo-government restrictions like taxes and justification requirements. I think this will best serve the interests of a community long held in thrall to the vision of an IPv6 transition that simply has not occurred in anything like the predicted timeframe. I would prefer that any support I find not be motivated by perceptions of my motivations, just my words and ideas. I voiced support for the concept of having a informed higher authority make the decision about competing registries requested in the letter which started the thread. I support competing registries because I believe that their competitive forces will move the market towards freedom, and because presumably a competing registry could decide its own, more liberal transfer policy. My understanding is that one way to get that accomplished, and I will accede it would be the better way, would be for the participants in policy making in all 5 RIRs come together to forge a policy allowing for competing private registries. But I think that is like expecting Network Solutions to have voted for competing DNS registrars. Unlikely to happen due to institutional conflicts of interest. (I understand that NetSol was not a community run org like the RIRs, but I see a natural institutional conflict between those who dominate a closed market and those who seek to expand it.) (And yes, this is also a commentary on the tiny number of participants who seem to people the RIR executive positions, and by extension the tiny groups of vocal participants in the RIR-PPML process.) (And yes, I have lost trust in ARIN staff since the MS/Nortel debacle) But nobody seems too sure what that higher authority is, and of course some participants see the community of RIR-PPML participants as the highest authority of all. I didn't write that letter, nor do I have any relationship with the writer of the letter, to my knowledge I have never met, conversed, or emailed with him. As for changing policy in the ARIN region, that is my intent, and I have heard from another poster who is interested in co-sponsoring a proposal designed to create a free market for ip transfers. So I will work with him to do just as you say, round up support and see if we can get a proposal that passes muster with the PPML and can be included in the next PPM. Regards, Mike Burns _______________________________________________ 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 hannigan at gmail.com Tue May 3 15:14:40 2011 From: hannigan at gmail.com (Martin Hannigan) Date: Tue, 3 May 2011 15:14:40 -0400 Subject: [arin-ppml] Fw: Accusation of fundamental, conflictofinterest/IPaddresspolicy pitched directly to ICANN In-Reply-To: <250CB859F41D4C6FB7DAA2DFDE59BEB4@mike> References: <4DC041D3.7030404@globis.net> <250CB859F41D4C6FB7DAA2DFDE59BEB4@mike> Message-ID: This is much more complicated than you are letting on. Perhaps *buying addresses on Amazon would be a non tax event. The *seller would realize a profit and that would be considered income. Again, "too good to be true". Collecting tax is different than paying tax. Recent trends suggest that the days of not collecting tax on goods sold via the Internet are fast coming to a close, FWIW. Best, -M< On Tue, May 3, 2011 at 2:46 PM, Mike Burns wrote: > Taxation of the Internet is a local government matter. In the States > political pressure has resulted in little to no taxation. > The same forces will act on these new assets. > Taxes are bad, but their existence is no reason to avoid a market. > > Regards, > Mike > > > > ----- Original Message ----- > From: Ray Hunter > To: arin-ppml at arin.net ; Mike Burns > Sent: Tuesday, May 03, 2011 1:56 PM > Subject: Re: [arin-ppml] Fw: Accusation of fundamental, > conflictofinterest/IPaddresspolicy pitched directly to ICANN > > Whilst I don't necessarily agree than an IPv4 address has any "value", and > it's your idea to create an (artificial) market where address allocations > attract a hard dollar value (which they traditionally haven't had), I would > note the following concern: Any legal entity that transfers an intangible > asset across an (international) border for a payment is almost certainly > going to attract the attention of more than one government entity regarding > accounting and taxation, not least for Value Added Tax, international > transfer pricing, avoidance of income tax ...... > > See for example > http://www.kluwerlaw.com/Catalogue/titleinfo.htm?ProdID=904119925X > > The ARIN service region includes Canada, many Caribbean and North Atlantic > islands, and the United States. The Internet is even bigger. > > So would your market free of government restrictions and taxes be > international, limited to national boundaries? NAFTA? state boundaries? or > what? > > Would corporations and not for profit entities now have to enter an asset > value in their annual accounts for the value of an IPv4 allocation? > > If something has a value, and can therefore be taxed, it's much more likely > to attract more government control, not less. Just look at the wireless > spectrum allocation auctions. Is this what you want for the Internet? > > Be careful what you wish for. > > regards, > RayH > > My interest is in having a market for the buying and selling of IP addresses > free from government and psuedo-government restrictions like taxes and > justification requirements. > > Regards, > > Mike Burns > > > _______________________________________________ > 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 mike at nationwideinc.com Tue May 3 15:17:15 2011 From: mike at nationwideinc.com (Mike Burns) Date: Tue, 3 May 2011 15:17:15 -0400 Subject: [arin-ppml] Fw: Accusation of fundamental, conflictofinterest/IPaddresspolicypitched directly to ICANN References: <4DC041D3.7030404@globis.net> <250CB859F41D4C6FB7DAA2DFDE59BEB4@mike> Message-ID: > This is much more complicated than you are letting on. Perhaps *buying > addresses on Amazon would be a non tax event. The *seller would > realize a profit and that would be considered income. Again, "too > good to be true". Collecting tax is different than paying tax. Recent > trends suggest that the days of not collecting tax on goods sold via > the Internet are fast coming to a close, FWIW. > > Best, > > -M< Yes, I rue the loss of freedom which I think led directly to the explosive growth of the Internet. I don't doubt that taxation is coming. Regards, Mike From ebw at abenaki.wabanaki.net Tue May 3 15:50:13 2011 From: ebw at abenaki.wabanaki.net (Eric Brunner-Williams) Date: Tue, 03 May 2011 15:50:13 -0400 Subject: [arin-ppml] Fw: Accusation of fundamental, conflictofinterest/IPaddresspolicypitched directly to ICANN In-Reply-To: References: <4DC041D3.7030404@globis.net> <250CB859F41D4C6FB7DAA2DFDE59BEB4@mike> Message-ID: <4DC05C75.3010104@abenaki.wabanaki.net> taking a few comments spread over a myrid of notes ... > My interest is in having a market for the buying and selling of IP addresses free from government and psuedo-government ... a [IDEOLOGICAL] tag on the subject line would be appropriate. > ... a informed higher authority ... the existence of which is an assumption that is not actually proved. > I think that is like expecting Network Solutions to have voted for competing DNS registrars the expression of opinion, absent a reference to competition policy, in the late 90s, or the present, is not convincing, nor, in the example offered, correct. > But nobody seems too sure what that higher authority is ... i hadn't observed a question asked, only an assertion that an answer existed, in a specific form. eric From kkargel at polartel.com Tue May 3 16:01:29 2011 From: kkargel at polartel.com (Kevin Kargel) Date: Tue, 3 May 2011 15:01:29 -0500 Subject: [arin-ppml] Fw: Accusation of fundamentalconflictofinterest/IPaddress policy pitched directly to ICANN In-Reply-To: <379DB08FB5564ED88230C1B6D6AE80FE@mike> References: <379DB08FB5564ED88230C1B6D6AE80FE@mike> Message-ID: <8695009A81378E48879980039EEDAD289D0E5BC6@MAIL1.polartel.local> Mike, Really? You think that the DNS registry system that is in place today is a standard to which ARIN should aspire? You think that it will be better when IP addresses are managed in the various courts and by the various governments around the world? Do you realize that when government starts managing a resource they have to pay for that management somehow? Guess how they will do that.. When the US government (not to mention others) gets in to play on this how far do you think we will be from a 'Department of Internet Commerce'? Do you really want to hasten that eventuality? If everyone would play nice and not be driven by greed or power then I would be inclined to agree with some of your propositions. Unfortunately we are living in a far from perfect world. Kevin qui totum vult totum perdit ? ________________________________________ From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Mike Burns Sent: Tuesday, May 03, 2011 2:02 PM To: Alexander, Daniel; arin-ppml at arin.net Subject: Re: [arin-ppml] Fw: Accusation of fundamentalconflictofinterest/IPaddress policy pitched directly to ICANN Hi Dan, ? Yes, I do support the kind of oversight recommended in the letter, using as a model the requirements to be a DNS registrar. Perhaps this alone is justification for the highest level decisionmaking. Since a competing registry would be on the same level as the existing RIR's, in effect we would be asking the RIRs to oversee themselves if we allowed the RIRs to decide the issue, whether at the RIR or ASO level. Quis custodiet ipsos custodes? ? I do understand and appreciate the beauty of the non-governmental approach to Internet governance. ? I think the many kinds of conflicts you reference in your last paragraph are likely to be sorted out around the world in courts and legislatures, which I think are probably better suited to that task than ARIN. Much like the evolution (or de-evolution) of the Domain Name System. ? I will certainly vet any policy proposal I offer here, though can you give me an idea of the timeframe for proposals to be considered at the next AC meeting, should enough support manifest on the list? ? Regards, ? Mike ? ? ----- Original Message ----- From: Alexander, Daniel To: arin-ppml at arin.net Sent: Tuesday, May 03, 2011 2:49 PM Subject: Re: [arin-ppml] Fw: Accusation of fundamentalconflictofinterest/IPaddress policy pitched directly to ICANN Mike, As one of the AC shepherds for the proposals that were abandoned, I would offer one suggestion. Feel free to vet the proposal language you are considering here on this list prior to submitting an actual proposal. That is what this list is for. It would also help refine the scope that Keith mentions, and avoid the confusion that earlier proposals created. It is much easier to refine and evolve policy language on the ppml before it becomes part of the PDP process.? If you look?back to proposals 133, 134, and 136, they suggested that resource holders?could opt-in, opt-out, or find the lowest common denominator to establish?claim.?While this would allow for what you propose, they offered none of the oversight that you advocate, which is also why there was such a cold reception.? You can see how a competing registry, that is operating properly, could do so in a complimentary manner to the RIR. One thing people will have issue with is how the overall model can exist with the individuals who would try to create registries that would not apply similar standards of operation. Without any protections, the ISP's who would have to rely on this data would not be able to depend on the overall system (not referring to any particular registry) which is the shift in burden I mentioned in an earlier post.? While people may have issues with the quality of whois, or registration of assignments, there is an upside to the current system. In this region, data points to ARIN and anyone can get involved, change the rules, and try and hold ARIN accountable. In the distributed model that is proposed, accountability is spread out, and the ability to resolve conflicts or issues becomes much harder. These are the kind of concerns that need to be addressed in order to gain momentum on a change of this scale.? I hope this helps. Dan Alexander ARIN AC- speaking only for myself From: "Keith W. Hare" Date: Tue, 3 May 2011 13:56:28 -0400 To: Mike Burns , "arin-ppml at arin.net" Subject: Re: [arin-ppml] Fw: Accusation of fundamental conflictofinterest/IPaddress policy pitched directly to ICANN Mike, So far, we have seen only bits of policy proposals that hint at the idea of competing private address registries. Without a policy proposal that covers all of the details, we are left to extrapolate the remaining pieces. This extrapolation may or may not be what competing address registry proponents have in mind, but until we see a full policy proposal, we are left with only perceptions of your (and others) motivations. Keith From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Mike Burns Sent: Tuesday, May 03, 2011 1:23 PM To: John Sweeting Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] Fw: Accusation of fundamental conflictofinterest/IPaddress policy pitched directly to ICANN It really is as easy as rounding up all the support you can muster, have that support join PPML, submit the proposal that you would like see made policy and then have your support show their support through PPML and the next PPM. Is there a reason you do not want to follow that process? It might help gain support if you provided your underlying motivation(s). -John Sweeting Hi John, My interest is in having a market for the buying and selling of IP addresses free from government and psuedo-government restrictions like taxes and justification requirements. I think this will best serve the interests of a community long held in thrall to the vision of an IPv6 transition that simply has not occurred in anything like the predicted timeframe. I would prefer that any support I find not be motivated by perceptions of my motivations, just?my words and ideas. I voiced support for the concept of having a informed higher authority make the decision about competing registries requested in the letter which started the thread. I support competing registries because I believe that their competitive forces will move the market towards freedom, and because presumably a competing registry could decide its own, more liberal transfer policy. My understanding is that one way to get that accomplished, and I will accede it would be the better way, would be for?the participants in policy making in all 5 RIRs come together to forge a policy allowing for competing private registries. But I think that is like expecting Network Solutions to have voted for?competing DNS registrars. Unlikely to happen due to institutional conflicts of interest. (I understand that NetSol was not a community run org like the RIRs, but? I see a natural institutional?conflict between those who dominate a closed?market and those who?seek to expand it.) (And yes, this is also a commentary on the tiny number of participants who seem to people the RIR executive positions, and by extension the tiny groups of vocal participants in the RIR-PPML process.) (And yes, I have lost trust in ARIN staff since the MS/Nortel debacle) But nobody seems too sure what that higher authority is, and of course some participants see the community of RIR-PPML participants as the highest authority of all. I didn't write that letter, nor do I have any relationship with the writer of the letter, to my knowledge I have never met, conversed, or emailed with him. As for changing policy in the ARIN region, that is my intent, and I have heard from another poster who is interested in co-sponsoring a proposal designed to create a free market for ip transfers. So I will work with him to do just as you say, round up support and see if we can get a proposal that passes muster with the PPML and can be included in the next PPM. Regards, Mike Burns _______________________________________________ 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 mike at nationwideinc.com Tue May 3 16:01:34 2011 From: mike at nationwideinc.com (Mike Burns) Date: Tue, 3 May 2011 16:01:34 -0400 Subject: [arin-ppml] Fw: Accusation of fundamental, conflictofinterest/IPaddresspolicypitched directly to ICANN References: <4DC041D3.7030404@globis.net> <250CB859F41D4C6FB7DAA2DFDE59BEB4@mike> <4DC05C75.3010104@abenaki.wabanaki.net> Message-ID: <906C41090D524FD0958A1EA742CB8889@mike> Hi Eric, answers inline > taking a few comments spread over a myrid of notes ... > >> My interest is in having a market for the buying and selling of IP >> addresses free from government and psuedo-government ... > > a [IDEOLOGICAL] tag on the subject line would be appropriate. I suppose I am guilty of having an ideology which guides me. Am I the only one on the list? > >> ... a informed higher authority ... > > the existence of which is an assumption that is not actually proved. Or disproved, so why not continue the discussion? > >> I think that is like expecting Network Solutions to have voted for >> competing DNS registrars > > the expression of opinion, absent a reference to competition policy, in > the late 90s, or the present, is not convincing, nor, in the example > offered, correct. > I am assuming a historical perspective from the intelligent posters here, perhaps a remedial lesson is required in some cases. >> But nobody seems too sure what that higher authority is ... > > i hadn't observed a question asked, only an assertion that an answer > existed, in a specific form. > > eric > Huh? Regards, Mike From mike at nationwideinc.com Tue May 3 16:15:06 2011 From: mike at nationwideinc.com (Mike Burns) Date: Tue, 3 May 2011 16:15:06 -0400 Subject: [arin-ppml] Fw: Accusationof fundamentalconflictofinterest/IPaddress policypitched directly to ICANN References: <379DB08FB5564ED88230C1B6D6AE80FE@mike> <8695009A81378E48879980039EEDAD289D0E5BC6@MAIL1.polartel.local> Message-ID: Hi Kevin, answers inline. >Really? >You think that the DNS registry system that is in place today is a standard >to which ARIN should aspire? I remember paying $100 for domain names from Network Solutions that I can get instantly now for $6. >You think that it will be better when IP addresses are managed in the >various courts and by the various governments around the world? Do you >realize that when government starts managing a resource they have to >pay >for that management somehow? Guess how they will do that.. I am not asking governments to manage resources, I am asking them to settle inevitable conflicts of law and custom. For example, witness the issues related to domain names and trademarks. Those kinds of decisions require governments to make them. In the case of ip transfers, all I expect the government to treat them like the assets they are. The government inevitably deals with assets when they tax, for example, and when they handle them in divorce or bankruptcy cases, ahem, for example. >When the US government (not to mention others) gets in to play on this how >far do you think we will be from a 'Department of Internet Commerce'? Do >you really want to hasten that eventuality? I'm not clear on how removing justification requirements (or creating private registries) will lead to the Department of Internet Commerce. By all means, please understand that the very idea is antithetical to my thinking, so you will have to describe the process you are describing. >If everyone would play nice and not be driven by greed or power then I >would be inclined to agree with some of your propositions. Unfortunately >we are living in a far from perfect world. >Kevin >qui totum vult totum perdit My concept of free markets are based on self-interest (greed, if you will). I appealed to the idea of the Invisible Hand as an example of how self-interest leads to the greater good through free markets. I don't know what part of my ideology relies on people playing nice, I think the opposite idea is usually attributed to my ideas. Regards, Mike From Daniel_Alexander at Cable.Comcast.com Tue May 3 16:34:25 2011 From: Daniel_Alexander at Cable.Comcast.com (Alexander, Daniel) Date: Tue, 3 May 2011 20:34:25 +0000 Subject: [arin-ppml] Fw: Accusation of fundamentalconflictofinterest/IPaddress policy pitched directly to ICANN In-Reply-To: <379DB08FB5564ED88230C1B6D6AE80FE@mike> Message-ID: Hey Mike, I will get you the dates shortly. Just confirming some of the deadlines. On a separate point, I have to disagree with one comment below. Quis custodiet ipsos custodes, suggesting the RIR oversee themselves. The problem is that the RIR do not make the policies. It is the thousands of individuals in the Internet technical community around the world (of which you are included) that make the rules. I have seen Internet policy shaped by large corporations, small town ISPs, individuals from all corners of the globe that have no political clout or financial influence, and am watching you shape the discussion right here. This past week I have seen the head of ARIN acknowledge several points made on this list regarding transfer policies, the RSA, and operational procedures that may lead to changes in the future. I have a hard time understanding your question of who is watching the RIR when you are one of the watchmen you are asking about. -Dan From: Mike Burns > Date: Tue, 3 May 2011 15:02:03 -0400 To: Microsoft Office User >, > Subject: Re: [arin-ppml] Fw: Accusation of fundamentalconflictofinterest/IPaddress policy pitched directly to ICANN Hi Dan, Yes, I do support the kind of oversight recommended in the letter, using as a model the requirements to be a DNS registrar. Perhaps this alone is justification for the highest level decisionmaking. Since a competing registry would be on the same level as the existing RIR's, in effect we would be asking the RIRs to oversee themselves if we allowed the RIRs to decide the issue, whether at the RIR or ASO level. Quis custodiet ipsos custodes? I do understand and appreciate the beauty of the non-governmental approach to Internet governance. I think the many kinds of conflicts you reference in your last paragraph are likely to be sorted out around the world in courts and legislatures, which I think are probably better suited to that task than ARIN. Much like the evolution (or de-evolution) of the Domain Name System. I will certainly vet any policy proposal I offer here, though can you give me an idea of the timeframe for proposals to be considered at the next AC meeting, should enough support manifest on the list? Regards, Mike ----- Original Message ----- From: Alexander, Daniel To: arin-ppml at arin.net Sent: Tuesday, May 03, 2011 2:49 PM Subject: Re: [arin-ppml] Fw: Accusation of fundamentalconflictofinterest/IPaddress policy pitched directly to ICANN Mike, As one of the AC shepherds for the proposals that were abandoned, I would offer one suggestion. Feel free to vet the proposal language you are considering here on this list prior to submitting an actual proposal. That is what this list is for. It would also help refine the scope that Keith mentions, and avoid the confusion that earlier proposals created. It is much easier to refine and evolve policy language on the ppml before it becomes part of the PDP process. If you look back to proposals 133, 134, and 136, they suggested that resource holders could opt-in, opt-out, or find the lowest common denominator to establish claim. While this would allow for what you propose, they offered none of the oversight that you advocate, which is also why there was such a cold reception. You can see how a competing registry, that is operating properly, could do so in a complimentary manner to the RIR. One thing people will have issue with is how the overall model can exist with the individuals who would try to create registries that would not apply similar standards of operation. Without any protections, the ISP's who would have to rely on this data would not be able to depend on the overall system (not referring to any particular registry) which is the shift in burden I mentioned in an earlier post. While people may have issues with the quality of whois, or registration of assignments, there is an upside to the current system. In this region, data points to ARIN and anyone can get involved, change the rules, and try and hold ARIN accountable. In the distributed model that is proposed, accountability is spread out, and the ability to resolve conflicts or issues becomes much harder. These are the kind of concerns that need to be addressed in order to gain momentum on a change of this scale. I hope this helps. Dan Alexander ARIN AC- speaking only for myself From: "Keith W. Hare" > Date: Tue, 3 May 2011 13:56:28 -0400 To: Mike Burns >, "arin-ppml at arin.net" > Subject: Re: [arin-ppml] Fw: Accusation of fundamental conflictofinterest/IPaddress policy pitched directly to ICANN Mike, So far, we have seen only bits of policy proposals that hint at the idea of competing private address registries. Without a policy proposal that covers all of the details, we are left to extrapolate the remaining pieces. This extrapolation may or may not be what competing address registry proponents have in mind, but until we see a full policy proposal, we are left with only perceptions of your (and others) motivations. Keith From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Mike Burns Sent: Tuesday, May 03, 2011 1:23 PM To: John Sweeting Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] Fw: Accusation of fundamental conflictofinterest/IPaddress policy pitched directly to ICANN It really is as easy as rounding up all the support you can muster, have that support join PPML, submit the proposal that you would like see made policy and then have your support show their support through PPML and the next PPM. Is there a reason you do not want to follow that process? It might help gain support if you provided your underlying motivation(s). -John Sweeting Hi John, My interest is in having a market for the buying and selling of IP addresses free from government and psuedo-government restrictions like taxes and justification requirements. I think this will best serve the interests of a community long held in thrall to the vision of an IPv6 transition that simply has not occurred in anything like the predicted timeframe. I would prefer that any support I find not be motivated by perceptions of my motivations, just my words and ideas. I voiced support for the concept of having a informed higher authority make the decision about competing registries requested in the letter which started the thread. I support competing registries because I believe that their competitive forces will move the market towards freedom, and because presumably a competing registry could decide its own, more liberal transfer policy. My understanding is that one way to get that accomplished, and I will accede it would be the better way, would be for the participants in policy making in all 5 RIRs come together to forge a policy allowing for competing private registries. But I think that is like expecting Network Solutions to have voted for competing DNS registrars. Unlikely to happen due to institutional conflicts of interest. (I understand that NetSol was not a community run org like the RIRs, but I see a natural institutional conflict between those who dominate a closed market and those who seek to expand it.) (And yes, this is also a commentary on the tiny number of participants who seem to people the RIR executive positions, and by extension the tiny groups of vocal participants in the RIR-PPML process.) (And yes, I have lost trust in ARIN staff since the MS/Nortel debacle) But nobody seems too sure what that higher authority is, and of course some participants see the community of RIR-PPML participants as the highest authority of all. I didn't write that letter, nor do I have any relationship with the writer of the letter, to my knowledge I have never met, conversed, or emailed with him. As for changing policy in the ARIN region, that is my intent, and I have heard from another poster who is interested in co-sponsoring a proposal designed to create a free market for ip transfers. So I will work with him to do just as you say, round up support and see if we can get a proposal that passes muster with the PPML and can be included in the next PPM. Regards, Mike Burns _______________________________________________ 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 mike at nationwideinc.com Tue May 3 16:41:31 2011 From: mike at nationwideinc.com (Mike Burns) Date: Tue, 3 May 2011 16:41:31 -0400 Subject: [arin-ppml] Fw: Accusation offundamentalconflictofinterest/IPaddress policy pitched directly to ICANN References: Message-ID: <2305188FE5E044ECBB236FB6B92D03B7@mike> Hi Dan, It is just that it seems circular to me that RIRs decide whether to extend their own oversight rules to competing registries. If they can decide elements related to their own oversight, who is overseeing them? If they are overseeing themselves, why is IANA approval needed for the creation of new RIRs? (Formality or not.) But I understand the concept you are invoking here about under-sight guarding oversight, if you will. Regards, Mike ----- Original Message ----- From: Alexander, Daniel To: Mike Burns ; arin-ppml at arin.net Sent: Tuesday, May 03, 2011 4:34 PM Subject: Re: [arin-ppml] Fw: Accusation offundamentalconflictofinterest/IPaddress policy pitched directly to ICANN Hey Mike, I will get you the dates shortly. Just confirming some of the deadlines. On a separate point, I have to disagree with one comment below. Quis custodiet ipsos custodes, suggesting the RIR oversee themselves. The problem is that the RIR do not make the policies. It is the thousands of individuals in the Internet technical community around the world (of which you are included) that make the rules. I have seen Internet policy shaped by large corporations, small town ISPs, individuals from all corners of the globe that have no political clout or financial influence, and am watching you shape the discussion right here. This past week I have seen the head of ARIN acknowledge several points made on this list regarding transfer policies, the RSA, and operational procedures that may lead to changes in the future. I have a hard time understanding your question of who is watching the RIR when you are one of the watchmen you are asking about. -Dan From: Mike Burns Date: Tue, 3 May 2011 15:02:03 -0400 To: Microsoft Office User , Subject: Re: [arin-ppml] Fw: Accusation of fundamentalconflictofinterest/IPaddress policy pitched directly to ICANN Hi Dan, Yes, I do support the kind of oversight recommended in the letter, using as a model the requirements to be a DNS registrar. Perhaps this alone is justification for the highest level decisionmaking. Since a competing registry would be on the same level as the existing RIR's, in effect we would be asking the RIRs to oversee themselves if we allowed the RIRs to decide the issue, whether at the RIR or ASO level. Quis custodiet ipsos custodes? I do understand and appreciate the beauty of the non-governmental approach to Internet governance. I think the many kinds of conflicts you reference in your last paragraph are likely to be sorted out around the world in courts and legislatures, which I think are probably better suited to that task than ARIN. Much like the evolution (or de-evolution) of the Domain Name System. I will certainly vet any policy proposal I offer here, though can you give me an idea of the timeframe for proposals to be considered at the next AC meeting, should enough support manifest on the list? Regards, Mike ----- Original Message ----- From: Alexander, Daniel To: arin-ppml at arin.net Sent: Tuesday, May 03, 2011 2:49 PM Subject: Re: [arin-ppml] Fw: Accusation of fundamentalconflictofinterest/IPaddress policy pitched directly to ICANN Mike, As one of the AC shepherds for the proposals that were abandoned, I would offer one suggestion. Feel free to vet the proposal language you are considering here on this list prior to submitting an actual proposal. That is what this list is for. It would also help refine the scope that Keith mentions, and avoid the confusion that earlier proposals created. It is much easier to refine and evolve policy language on the ppml before it becomes part of the PDP process. If you look back to proposals 133, 134, and 136, they suggested that resource holders could opt-in, opt-out, or find the lowest common denominator to establish claim. While this would allow for what you propose, they offered none of the oversight that you advocate, which is also why there was such a cold reception. You can see how a competing registry, that is operating properly, could do so in a complimentary manner to the RIR. One thing people will have issue with is how the overall model can exist with the individuals who would try to create registries that would not apply similar standards of operation. Without any protections, the ISP's who would have to rely on this data would not be able to depend on the overall system (not referring to any particular registry) which is the shift in burden I mentioned in an earlier post. While people may have issues with the quality of whois, or registration of assignments, there is an upside to the current system. In this region, data points to ARIN and anyone can get involved, change the rules, and try and hold ARIN accountable. In the distributed model that is proposed, accountability is spread out, and the ability to resolve conflicts or issues becomes much harder. These are the kind of concerns that need to be addressed in order to gain momentum on a change of this scale. I hope this helps. Dan Alexander ARIN AC- speaking only for myself From: "Keith W. Hare" Date: Tue, 3 May 2011 13:56:28 -0400 To: Mike Burns , "arin-ppml at arin.net" Subject: Re: [arin-ppml] Fw: Accusation of fundamental conflictofinterest/IPaddress policy pitched directly to ICANN Mike, So far, we have seen only bits of policy proposals that hint at the idea of competing private address registries. Without a policy proposal that covers all of the details, we are left to extrapolate the remaining pieces. This extrapolation may or may not be what competing address registry proponents have in mind, but until we see a full policy proposal, we are left with only perceptions of your (and others) motivations. Keith From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Mike Burns Sent: Tuesday, May 03, 2011 1:23 PM To: John Sweeting Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] Fw: Accusation of fundamental conflictofinterest/IPaddress policy pitched directly to ICANN It really is as easy as rounding up all the support you can muster, have that support join PPML, submit the proposal that you would like see made policy and then have your support show their support through PPML and the next PPM. Is there a reason you do not want to follow that process? It might help gain support if you provided your underlying motivation(s). -John Sweeting Hi John, My interest is in having a market for the buying and selling of IP addresses free from government and psuedo-government restrictions like taxes and justification requirements. I think this will best serve the interests of a community long held in thrall to the vision of an IPv6 transition that simply has not occurred in anything like the predicted timeframe. I would prefer that any support I find not be motivated by perceptions of my motivations, just my words and ideas. I voiced support for the concept of having a informed higher authority make the decision about competing registries requested in the letter which started the thread. I support competing registries because I believe that their competitive forces will move the market towards freedom, and because presumably a competing registry could decide its own, more liberal transfer policy. My understanding is that one way to get that accomplished, and I will accede it would be the better way, would be for the participants in policy making in all 5 RIRs come together to forge a policy allowing for competing private registries. But I think that is like expecting Network Solutions to have voted for competing DNS registrars. Unlikely to happen due to institutional conflicts of interest. (I understand that NetSol was not a community run org like the RIRs, but I see a natural institutional conflict between those who dominate a closed market and those who seek to expand it.) (And yes, this is also a commentary on the tiny number of participants who seem to people the RIR executive positions, and by extension the tiny groups of vocal participants in the RIR-PPML process.) (And yes, I have lost trust in ARIN staff since the MS/Nortel debacle) But nobody seems too sure what that higher authority is, and of course some participants see the community of RIR-PPML participants as the highest authority of all. I didn't write that letter, nor do I have any relationship with the writer of the letter, to my knowledge I have never met, conversed, or emailed with him. As for changing policy in the ARIN region, that is my intent, and I have heard from another poster who is interested in co-sponsoring a proposal designed to create a free market for ip transfers. So I will work with him to do just as you say, round up support and see if we can get a proposal that passes muster with the PPML and can be included in the next PPM. Regards, Mike Burns _______________________________________________ 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 v6ops at globis.net Tue May 3 17:24:26 2011 From: v6ops at globis.net (Ray Hunter) Date: Tue, 03 May 2011 23:24:26 +0200 Subject: [arin-ppml] Fw: Accusation of fundamental, conflictofinterest/IPaddress policy pitched directly to ICANN In-Reply-To: References: <4DC041D3.7030404@globis.net> Message-ID: <4DC0728A.6000208@globis.net> Again I assert my neutrality, and just want to point out some facts and interpretations and explore possibilities for your consideration. There were approx 2^32 IPv4 addresses allocated on as needed basis (give or take a few blocks left over), out of which 41% went to the US according to the stats I've seen from http://www.bgpexpert.com/addressespercountry.php = 1760936591 or so addresses. That's about a /2 in round numbers. I'm not doubting that there may been some IPv4 ranges that have been exchanged for cash. What I question is how many, whether this is significant, and whether they should be considered as the norm or as exceptions. I've seen 10 documented transfers (Statistics regarding NRPM 8.3 Transfers to date). Maybe 11 now. Hardly a large sample. > > Distribution of IPv4 Resources transferred: >> >> 1 /17 >> 3 /20s >> 1 /21 >> 1 /23 >> 49 /24s = 60160 addresses. Certainly less than a /16. if I've done my maths right that's approx 0.0034% of the address space in the US. Even if you add in the Microsoft transfer (rumored to be 666K addresses) as a done deal, it's still a miniscule amount compared to the ARIN community as a whole. The combined total that I know of is also still much smaller than the current proposed /10 for NAT444 cgn use, again which would be given on an "as-needed" basis "free of charge" (although I've registered my personal objection to this proposed allocation, I'll respect the decision of ARIN, which is what being on a consensus based Internet is all about) Not sure therefore how you can claim that the majority view of "most people" is that these transactions are and should be the norm. I don't make any such claim that I speak on behalf of the majority, but the stats are pretty one sided so far, and suggests that they are exceptions. I don't think a lot of people have properly thought through the consequences of equating or confusing ownership with allocation and registration. Here's a theoretical scenario, based on reality. I have a fixed /32 allocated from my ISP for business use. I think I'm gonna ask a fortune if they ever want that back (I never signed any contract to the contrary as far as I'm concerned, and I've registered that address for use on my website domain in DNS, which is also registered in whois). They better also not prevent me from routing my /32 into BGP because that would probably be denying my right to free trade. "What utter tosh" you'd say (or perhaps something stronger). And rightly so. But what's the difference between my allocation from my ISP, and the ISP's allocation from the RIR, and the RIR's allocation from ICANN? We live on a consensus based Internet. I might yet be surprised and see one or more network operators call foul on a deal like one we've recently observed, consensus breaks down, and some network operators refuse to route the address blocks that have been sold on a commercial basis (maybe the research nets, or competitor networks, I don't know), just like some football clubs block a few tickets that are known to have been sold on the black market at inflated prices. What happens then? It'll be a mess. Good luck with your suggestions on improving ARIN policies. I think everyone will welcome and appreciate new and improved policy if they see that there is a clear consensus that the changes will benefit the ARIN community. best regards, RayH Martin Hannigan wrote: > We have seen legacy IPv4 addresses space exchange hands for cash. > That's not in question (for most people) and I'm not sure why you > think that it may be. > From brandon at dodecatec.com Tue May 3 17:37:54 2011 From: brandon at dodecatec.com (Brandon Thetford) Date: Tue, 3 May 2011 17:37:54 -0400 Subject: [arin-ppml] Accusation of fundamental conflict of interest/IP address policy pitched directly to ICANN Message-ID: <00b801cc09da$5cebf5b0$16c3e110$@dodecatec.com> >>Really? >>You think that the DNS registry system that is in place today is a >>standard to which ARIN should aspire? >I remember paying $100 for domain names from Network Solutions that I can get instantly now for $6. We need to be careful how far we take this line of thought, though. DNS != IP space for a very critical reason: IP space is finite. DNS is effectively infinite. I don't think comparing NetSol or any DNS registry to ARIN is a remotely fair comparison based solely on this fact. -Brandon From springer at inlandnet.com Tue May 3 18:33:59 2011 From: springer at inlandnet.com (John Springer) Date: Tue, 3 May 2011 15:33:59 -0700 (PDT) Subject: [arin-ppml] ARIN-prop-146 Clarify Justified Need for Transfers In-Reply-To: References: <4DBEF120.4080901@arin.net> <88F39B20-5C20-45F0-AD61-5FA1E7F84CE3@delong.com> <3FCD1FDC-ECEE-4C9B-95C6-59E03D3C314E@matthew.at> <5598DFC7-E320-42FA-AA0E-C91C076BD725@delong.com> <6BA1EAA6-7D9C-44F9-BED7-884720F4B3BE@matthew.at> <05FAA29B-37BE-411C-95A4-50437602C8ED@delong.com> <4DBF6727.1090303@matthew.at> <097AAC1C-1F68-4820-9274-3290ADEFA195@delong.com> <4DBF75B7.3010407@matthew.at> <9501EA7E-FDAD-4DDA-B9E8-08C2811FF642@delong.com> <4DBF82F6.7050608@matthew.at> Message-ID: <20110503145144.N15967@mail.inlandnet.com> I oppose proposal ARIN-prop-146. Comments inline. On Tue, 3 May 2011, Owen DeLong wrote: > > On May 2, 2011, at 9:22 PM, Matthew Kaufman wrote: > >> On 5/2/2011 8:47 PM, Owen DeLong wrote: >>> >>> Welcome to the post-run-out world. Why should we let you acquire more space now and deny that >>> space to someone else who has justified need now? >> >> Because I can afford it and have taken the time to find a seller. >> >> Or were you planning on enacting price controls on the market as well? >> > > No, I think justified need is the only required control on the market. I don't see a need for price > controls, but, I do see a need to ensure that people like you do not get excessive address > space just because you have greater financial resources vs. others who need it now, but > have lesser financial resources. I see a need to ensure that people who have greater resources do not get more additional address space than others who also need it, but have lesser resources. Basically, what is being proposed here, stripped of a lot of heat and light is an environment where more resources is a much better advantage than currently. Who wouldn't want that? John Springer > 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 matthew at matthew.at Tue May 3 18:42:47 2011 From: matthew at matthew.at (Matthew Kaufman) Date: Tue, 03 May 2011 15:42:47 -0700 Subject: [arin-ppml] ARIN-prop-146 Clarify Justified Need for Transfers In-Reply-To: <20110503145144.N15967@mail.inlandnet.com> References: <4DBEF120.4080901@arin.net> <88F39B20-5C20-45F0-AD61-5FA1E7F84CE3@delong.com> <3FCD1FDC-ECEE-4C9B-95C6-59E03D3C314E@matthew.at> <5598DFC7-E320-42FA-AA0E-C91C076BD725@delong.com> <6BA1EAA6-7D9C-44F9-BED7-884720F4B3BE@matthew.at> <05FAA29B-37BE-411C-95A4-50437602C8ED@delong.com> <4DBF6727.1090303@matthew.at> <097AAC1C-1F68-4820-9274-3290ADEFA195@delong.com> <4DBF75B7.3010407@matthew.at> <9501EA7E-FDAD-4DDA-B9E8-08C2811FF642@delong.com> <4DBF82F6.7050608@matthew.at> <20110503145144.N15967@mail.inlandnet.com> Message-ID: <4DC084E7.5000302@matthew.at> On 5/3/2011 3:33 PM, John Springer wrote: > I oppose proposal ARIN-prop-146. > Comments inline. > > On Tue, 3 May 2011, Owen DeLong wrote: >> >> On May 2, 2011, at 9:22 PM, Matthew Kaufman wrote: >> >>> On 5/2/2011 8:47 PM, Owen DeLong wrote: >>>> >>>> Welcome to the post-run-out world. Why should we let you acquire >>>> more space now and deny that >>>> space to someone else who has justified need now? >>> >>> Because I can afford it and have taken the time to find a seller. >>> >>> Or were you planning on enacting price controls on the market as well? >>> >> >> No, I think justified need is the only required control on the >> market. I don't see a need for price >> controls, but, I do see a need to ensure that people like you do not >> get excessive address >> space just because you have greater financial resources vs. others >> who need it now, but >> have lesser financial resources. > > > > I see a need to ensure that people who have greater resources do not > get more additional address space than others who also need it, but > have lesser resources. > > Basically, what is being proposed here, stripped of a lot of heat and > light is an environment where more resources is a much better > advantage than currently. > > Who wouldn't want that? I don't have a problem with justified need for transfers. I *do* have a problem with creating large sets of people who can't even *use* transfers to fulfill their needs because the 3-month limit *they* are subject to is a lot different operationally than the 12-month limit the rest of the transfer recipients are subject to. I do not see how someone can operate a business that will still need IPv4 addresses in order to function and yet be limited to only getting three months at a time via transfer when their competitors are allowed to get 12 months at a time via transfer. Sure... back when there was a free pool, making them jump through the extra hoops every 3 months to show that they're doing the right thing makes (some) sense... but once there isn't, every time they get space might be their last. Matthew Kaufman From bill at herrin.us Tue May 3 18:47:10 2011 From: bill at herrin.us (William Herrin) Date: Tue, 3 May 2011 18:47:10 -0400 Subject: [arin-ppml] Fw: Accusationof fundamentalconflictofinterest/IPaddress policypitched directly to ICANN In-Reply-To: References: <379DB08FB5564ED88230C1B6D6AE80FE@mike> <8695009A81378E48879980039EEDAD289D0E5BC6@MAIL1.polartel.local> Message-ID: On Tue, May 3, 2011 at 4:15 PM, Mike Burns wrote: > Hi Kevin, answers inline. >> Really? > >> You think that the DNS registry system that is in place today is a >> standard to which ARIN should aspire? > > I remember paying $100 for domain names from Network Solutions that I can > get instantly now for $6. Unless of course I want herrin.net. The squatter sitting on it wants $2000. He's not using it for anything and never was. He's just sitting on it waiting to make a buck. On Tue, May 3, 2011 at 4:41 PM, Mike Burns wrote: > If [the RIRs] are overseeing themselves, why is IANA approval needed for the > creation of new RIRs? Because IANA has been charged by the RIRs with verifying the RIRs' compliance with the rules the public created for the RIRs through the policy development process. IANA functions as an auditor in this respect, transparency being critical to keeping the public in control of the process (bottum-up) instead of some central authority. On Tue, May 3, 2011 at 4:34 PM, Alexander, Daniel wrote: > I have seen Internet policy shaped by large corporations, small town ISPs, > individuals from all corners of the globe that have no political clout or > financial influence, and am watching you shape the discussion right here. > This past week I have seen the head of ARIN acknowledge several points made > on this list regarding transfer policies, the RSA, and operational > procedures that may lead to changes in the future. I have a hard time > understanding your question of who is watching the RIR when you are one of > the watchmen you are asking about. Hear hear! Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From matthew at matthew.at Tue May 3 18:49:08 2011 From: matthew at matthew.at (Matthew Kaufman) Date: Tue, 03 May 2011 15:49:08 -0700 Subject: [arin-ppml] ARIN-prop-146 Clarify Justified Need for Transfers In-Reply-To: <4DC084E7.5000302@matthew.at> References: <4DBEF120.4080901@arin.net> <88F39B20-5C20-45F0-AD61-5FA1E7F84CE3@delong.com> <3FCD1FDC-ECEE-4C9B-95C6-59E03D3C314E@matthew.at> <5598DFC7-E320-42FA-AA0E-C91C076BD725@delong.com> <6BA1EAA6-7D9C-44F9-BED7-884720F4B3BE@matthew.at> <05FAA29B-37BE-411C-95A4-50437602C8ED@delong.com> <4DBF6727.1090303@matthew.at> <097AAC1C-1F68-4820-9274-3290ADEFA195@delong.com> <4DBF75B7.3010407@matthew.at> <9501EA7E-FDAD-4DDA-B9E8-08C2811FF642@delong.com> <4DBF82F6.7050608@matthew.at> <20110503145144.N15967@mail.inlandnet.com> <4DC084E7.5000302@matthew.at> Message-ID: <4DC08664.4060905@matthew.at> On 5/3/2011 3:42 PM, Matthew Kaufman wrote: > > Sure... back when there was a free pool, making them jump through the > extra hoops every 3 months to show that they're doing the right thing > makes (some) sense... but once there isn't, every time they get space > might be their last. Oh, and since the "ARIN Community" is mostly made up of the "haves" and has almost no representation (if any) from the "have nots" I have no expectation that there will be widespread support for fixing transfer policies for the "have nots". Not the only organization I'm involved with right now that suffers from this policy-making flaw, I might add. Matthew Kaufman From hannigan at gmail.com Tue May 3 20:30:47 2011 From: hannigan at gmail.com (Martin Hannigan) Date: Tue, 3 May 2011 20:30:47 -0400 Subject: [arin-ppml] ARIN-prop-146 Clarify Justified Need for Transfers In-Reply-To: <4DC08664.4060905@matthew.at> References: <4DBEF120.4080901@arin.net> <88F39B20-5C20-45F0-AD61-5FA1E7F84CE3@delong.com> <3FCD1FDC-ECEE-4C9B-95C6-59E03D3C314E@matthew.at> <5598DFC7-E320-42FA-AA0E-C91C076BD725@delong.com> <6BA1EAA6-7D9C-44F9-BED7-884720F4B3BE@matthew.at> <05FAA29B-37BE-411C-95A4-50437602C8ED@delong.com> <4DBF6727.1090303@matthew.at> <097AAC1C-1F68-4820-9274-3290ADEFA195@delong.com> <4DBF75B7.3010407@matthew.at> <9501EA7E-FDAD-4DDA-B9E8-08C2811FF642@delong.com> <4DBF82F6.7050608@matthew.at> <20110503145144.N15967@mail.inlandnet.com> <4DC084E7.5000302@matthew.at> <4DC08664.4060905@matthew.at> Message-ID: On Tue, May 3, 2011 at 6:49 PM, Matthew Kaufman wrote: > On 5/3/2011 3:42 PM, Matthew Kaufman wrote: >> >> Sure... back when there was a free pool, making them jump through the >> extra hoops every 3 months to show that they're doing the right thing makes >> (some) sense... but once there isn't, every time they get space might be >> their last. > > Oh, and since the "ARIN Community" is mostly made up of the "haves" and has > almost no representation (if any) from the "have nots" I have no expectation > that there will be widespread support for fixing transfer policies for the > "have nots". Mathew, How did you determine that the average ARIN member is under-represented here? Best, -M< From matthew at matthew.at Tue May 3 20:33:43 2011 From: matthew at matthew.at (Matthew Kaufman) Date: Tue, 03 May 2011 17:33:43 -0700 Subject: [arin-ppml] ARIN-prop-146 Clarify Justified Need for Transfers In-Reply-To: References: <4DBEF120.4080901@arin.net> <88F39B20-5C20-45F0-AD61-5FA1E7F84CE3@delong.com> <3FCD1FDC-ECEE-4C9B-95C6-59E03D3C314E@matthew.at> <5598DFC7-E320-42FA-AA0E-C91C076BD725@delong.com> <6BA1EAA6-7D9C-44F9-BED7-884720F4B3BE@matthew.at> <05FAA29B-37BE-411C-95A4-50437602C8ED@delong.com> <4DBF6727.1090303@matthew.at> <097AAC1C-1F68-4820-9274-3290ADEFA195@delong.com> <4DBF75B7.3010407@matthew.at> <9501EA7E-FDAD-4DDA-B9E8-08C2811FF642@delong.com> <4DBF82F6.7050608@matthew.at> <20110503145144.N15967@mail.inlandnet.com> <4DC084E7.5000302@matthew.at> <4DC08664.4060905@matthew.at> Message-ID: <4DC09EE7.2010806@matthew.at> On 5/3/2011 5:30 PM, Martin Hannigan wrote: > On Tue, May 3, 2011 at 6:49 PM, Matthew Kaufman wrote: >> On 5/3/2011 3:42 PM, Matthew Kaufman wrote: >>> Sure... back when there was a free pool, making them jump through the >>> extra hoops every 3 months to show that they're doing the right thing makes >>> (some) sense... but once there isn't, every time they get space might be >>> their last. >> Oh, and since the "ARIN Community" is mostly made up of the "haves" and has >> almost no representation (if any) from the "have nots" I have no expectation >> that there will be widespread support for fixing transfer policies for the >> "have nots". > Mathew, > > How did you determine that the average ARIN member is under-represented here? > I'm not sure what you're asking. The people this policy change protects currently have no IPv4 space (as if they did they'd be processed under the policy which does have the 12-month exemption), but will need to acquire some after ARIN runout. I have yet to see a single person who appears like they might fall into that category post on the list this week. Matthew Kaufman From lsawyer at gci.com Tue May 3 20:52:59 2011 From: lsawyer at gci.com (Leif Sawyer) Date: Tue, 3 May 2011 16:52:59 -0800 Subject: [arin-ppml] ARIN-prop-147 Set Transfer Need to 24 months and Clarify Exception In-Reply-To: <4DC02AF0.9020308@umn.edu> References: <4DBEF12A.2020002@arin.net> <4DC02AF0.9020308@umn.edu> Message-ID: <18B2C6E38A3A324986B392B2D18ABC51F3D0CC11@fnb1mbx01.gci.com> I do support this proposal: I live in Alaska, and unfortunately for Alaskan businesses, there is no year-round construction season. What this means for us is that we Alaskan LIRs/ISPs have two-to-three-year construction schedules based on ground-thaw dates and tundra-freeze dates. Geographically speaking, this can translate into a construction "season" of less than 5 months. It was hard enough with the 12-month need, but we managed. 3-month need can break a company, depending on where/when/how new expansion takes place. 24-month need would help tremendously in these situations, not just in terms of guaranteeing available address space, but also in terms of keeping the number of advertised netblocks down to the minimum required to support the area. > -----Original Message----- > From: arin-ppml-bounces at arin.net > [mailto:arin-ppml-bounces at arin.net] On Behalf Of David Farmer > Sent: Tuesday, May 03, 2011 8:19 AM > To: arin-ppml at arin.net > Subject: Re: [arin-ppml] ARIN-prop-147 Set Transfer Need to > 24 months and Clarify Exception > > While I'm not yet convinced this change is absolutely necessary, and > reserve final judgment until this has been fully discussed. > However, I > support this proposal moving forward and it should be presented and > fully discussed in Philadelphia. I think is important that > we carefully > reevaluate the criteria we have for the evaluation of needs basis in > light of the change to market-like competition for IPv4 > address space. > I think it is important to retain a needs basis, but the needs basis > that worked when there was an IANA free pool may not automatically be > valid in a market-like situation. > > On 5/2/11 13:00 CDT, ARIN wrote: > > > ARIN-prop-147 Set Transfer Need to 24 months and Clarify Exception > > > > Proposal Originator: Matthew Kaufman > > > > Proposal Version: 1 > > > > Date: 2 May 2011 > > > > Proposal type: new > > > > Policy term: permanent > > > > Policy statement: > > > > Change section 4.2.4.4 content as follows: > > > > Replace: > > "This reduction does not apply to resources received via > section 8.3. An > > organization receiving a transfer under section 8.3 may continue to > > request up to a 12-month supply of IP addresses." > > > > With: > > "This reduction does not apply to resources received via > transfer. An > > organization receiving a transfer under section 8 may > request up to a > > 24-month supply of IP addresses." > > > > Rationale: > > > > The exception should apply to transfers under 8.2 as well > as 8.3 (and > > any future transfer policies). > > > > Due to the complexity of the financial transaction that may be > > involved and the associated budgeting on the part of the receiving > > organization, 24 months is a more reasonable amount of > forecast need to > > allow to be fulfilled via the transfer process. > > > > Potential benefit to address aggregation by allowing fewer larger > > transfers sooner. > > > > 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. > > > -- > =============================================== > 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 mysidia at gmail.com Tue May 3 21:07:35 2011 From: mysidia at gmail.com (Jimmy Hess) Date: Tue, 3 May 2011 20:07:35 -0500 Subject: [arin-ppml] Fw: Accusationof fundamentalconflictofinterest/IPaddress policypitched directly to ICANN In-Reply-To: References: <379DB08FB5564ED88230C1B6D6AE80FE@mike> <8695009A81378E48879980039EEDAD289D0E5BC6@MAIL1.polartel.local> Message-ID: On Tue, May 3, 2011 at 5:47 PM, William Herrin wrote: > On Tue, May 3, 2011 at 4:15 PM, Mike Burns wrote: >> I remember paying $100 for domain names from Network Solutions that I can >> get instantly now for $6. > Unless of course I want herrin.net. The squatter sitting on it wants > $2000. He's not using it for anything and never was. He's just sitting > on it waiting to make a buck. Hey, wait a minute... another thing that resulted from competitive registries was a UDRP process for dealing with such squatters, which should let you take the domain without handing the squatter the extortionate amount. You'll just need $9000 or $10000 in arbitration fees to get started.... -- -JH From bill at herrin.us Tue May 3 21:49:48 2011 From: bill at herrin.us (William Herrin) Date: Tue, 3 May 2011 21:49:48 -0400 Subject: [arin-ppml] ARIN-prop-147 Set Transfer Need to 24 months and Clarify Exception In-Reply-To: <4DBEF12A.2020002@arin.net> References: <4DBEF12A.2020002@arin.net> Message-ID: On Mon, May 2, 2011 at 2:00 PM, ARIN wrote: > ARIN-prop-147 Set Transfer Need to 24 months and Clarify Exception > Proposal Originator: Matthew Kaufman > > Policy statement: > > Change section 4.2.4.4 content as follows: > > Replace: > "This reduction does not apply to resources received via section 8.3. An > organization receiving a transfer under section 8.3 may continue to > request up to a 12-month supply of IP addresses." > > With: > "This reduction does not apply to resources received via transfer. An > organization receiving a transfer under section 8 may request up to a > 24-month supply of IP addresses." > > Timetable for implementation: immediate Hi Matthew, In principle, I support allowing recipients of addresses under section 8.3 to justify their use on a 24-month horizon. The shorter horizons were intended to dissuade folks from asking for more than they really need of a dwindling free resource. Under 8.3, that resource is no longer free. The cost will be sufficient to provide the backpressure that the short estimating horizons provide now. I don't like this wording. For one thing, 4.2.4.4 is the wrong place for this -- it should apply evenly to ISPs and end-users and should apply regardless of the length of time the registrant has been a "subscriber member." And by the way, how the heck did when end up with such an odd term, "subscriber member," which is not defined anywhere and used nowhere else in the document. How is it intended to be different than the term "LIR?" Also, I'm not convinced that such a policy should be implemented prior to the exhaustion of ARIN's normal allocation pool. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From springer at inlandnet.com Tue May 3 22:46:35 2011 From: springer at inlandnet.com (John Springer) Date: Tue, 3 May 2011 19:46:35 -0700 (PDT) Subject: [arin-ppml] ARIN-prop-146 Clarify Justified Need for Transfers In-Reply-To: <4DC084E7.5000302@matthew.at> References: <4DBEF120.4080901@arin.net> <88F39B20-5C20-45F0-AD61-5FA1E7F84CE3@delong.com> <3FCD1FDC-ECEE-4C9B-95C6-59E03D3C314E@matthew.at> <5598DFC7-E320-42FA-AA0E-C91C076BD725@delong.com> <6BA1EAA6-7D9C-44F9-BED7-884720F4B3BE@matthew.at> <05FAA29B-37BE-411C-95A4-50437602C8ED@delong.com> <4DBF6727.1090303@matthew.at> <097AAC1C-1F68-4820-9274-3290ADEFA195@delong.com> <4DBF75B7.3010407@matthew.at> <9501EA7E-FDAD-4DDA-B9E8-08C2811FF642@delong.com> <4DBF82F6.7050608@matthew.at> <20110503145144.N15967@mail.inlandnet.com> <4DC084E7.5000302@matthew.at> Message-ID: <20110503170508.A15967@mail.inlandnet.com> Hi Mathew, Thank you for the response(s), but I remain unpersuaded. More comments inline. On Tue, 3 May 2011, Matthew Kaufman wrote: > On 5/3/2011 3:33 PM, John Springer wrote: >> I oppose proposal ARIN-prop-146. >> Comments inline. >> >> On Tue, 3 May 2011, Owen DeLong wrote: >>> >>> On May 2, 2011, at 9:22 PM, Matthew Kaufman wrote: >>> >>>> On 5/2/2011 8:47 PM, Owen DeLong wrote: >>>>> >>>>> Welcome to the post-run-out world. Why should we let you acquire more >>>>> space now and deny that >>>>> space to someone else who has justified need now? >>>> >>>> Because I can afford it and have taken the time to find a seller. >>>> >>>> Or were you planning on enacting price controls on the market as well? >>>> >>> >>> No, I think justified need is the only required control on the market. I >>> don't see a need for price >>> controls, but, I do see a need to ensure that people like you do not get >>> excessive address >>> space just because you have greater financial resources vs. others who >>> need it now, but >>> have lesser financial resources. >> >> >> >> I see a need to ensure that people who have greater resources do not get >> more additional address space than others who also need it, but have lesser >> resources. OK, I responded to a comment, not a proposal or a thread. My bad. Still. >> Basically, what is being proposed here, stripped of a lot of heat and light >> is an environment where more resources is a much better advantage than >> currently. >> >> Who wouldn't want that? > > I don't have a problem with justified need for transfers. I *do* have a > problem with creating large sets of people who can't even *use* transfers to > fulfill their needs because the 3-month limit *they* are subject to is a lot > different operationally than the 12-month limit the rest of the transfer > recipients are subject to. > I do not see how someone can operate a business that will still need IPv4 > addresses in order to function and yet be limited to only getting three > months at a time via transfer when their competitors are allowed to get 12 > months at a time via transfer. Not still need, need for the first time. According to your subsequent comment to Marty: "The people this policy change protects currently have no IPv4 space (as if they did they'd be processed under the policy which does have the 12-month exemption), but will need to acquire some after ARIN runout." People who have no IPv4 space, but will need to acquire some after ARIN runout. This is exceptional advocacy. It also seems like a self limiting problem. I am not sure whether giving them 12 months instead of 3 will help that. ??? In any case, why on earth would you answer the question "Why should we let you acquire more space now and deny that space to someone else..." (meaning someone just now needing IPV4 space versus someone already in the business) with "Because I can afford it and have taken the time to find a seller." Some of us here on PPML, (eternally vituperated), puzzled by wording and motive, wait until discussion seems to resolve upon something that galvanizes us, to respond. I don't think in my case you did your cause any favors with that response. I believe now that I misunderstood at least the context of your statements. Would you please do me the favor to identify, if you will, what party getting into the IPV4 business after ARIN runout, other than speculators, deserves favors such as this? > Sure... back when there was a free pool, making them jump through the extra > hoops every 3 months to show that they're doing the right thing makes (some) > sense... but once there isn't, every time they get space might be their last. While I admit that my initial opposition to this was based on a completely unprecedented misunderstanding, now that I think I am clear(er) I am still opposed. Give bigger chunks of scarce IPV4 space to _NEW_ entrants simply "Because I can afford it and have taken the time to find a seller."? Insufficient information, at best. John Springer > Matthew Kaufman > > From matthew at matthew.at Tue May 3 22:58:03 2011 From: matthew at matthew.at (Matthew Kaufman) Date: Tue, 03 May 2011 19:58:03 -0700 Subject: [arin-ppml] ARIN-prop-146 Clarify Justified Need for Transfers In-Reply-To: <20110503170508.A15967@mail.inlandnet.com> References: <4DBEF120.4080901@arin.net> <88F39B20-5C20-45F0-AD61-5FA1E7F84CE3@delong.com> <3FCD1FDC-ECEE-4C9B-95C6-59E03D3C314E@matthew.at> <5598DFC7-E320-42FA-AA0E-C91C076BD725@delong.com> <6BA1EAA6-7D9C-44F9-BED7-884720F4B3BE@matthew.at> <05FAA29B-37BE-411C-95A4-50437602C8ED@delong.com> <4DBF6727.1090303@matthew.at> <097AAC1C-1F68-4820-9274-3290ADEFA195@delong.com> <4DBF75B7.3010407@matthew.at> <9501EA7E-FDAD-4DDA-B9E8-08C2811FF642@delong.com> <4DBF82F6.7050608@matthew.at> <20110503145144.N15967@mail.inlandnet.com> <4DC084E7.5000302@matthew.at> <20110503170508.A15967@mail.inlandnet.com> Message-ID: <4DC0C0BB.3010505@matthew.at> On 5/3/2011 7:46 PM, John Springer wrote: > Hi Mathew, > > Thank you for the response(s), but I remain unpersuaded. > More comments inline. More responses inline. > > On Tue, 3 May 2011, Matthew Kaufman wrote: > >> On 5/3/2011 3:33 PM, John Springer wrote: >>> I oppose proposal ARIN-prop-146. >>> Comments inline. >>> >>> On Tue, 3 May 2011, Owen DeLong wrote: >>>> >>>> On May 2, 2011, at 9:22 PM, Matthew Kaufman wrote: >>>> >>>>> On 5/2/2011 8:47 PM, Owen DeLong wrote: >>>>>> >>>>>> Welcome to the post-run-out world. Why should we let you acquire >>>>>> more space now and deny that >>>>>> space to someone else who has justified need now? >>>>> >>>>> Because I can afford it and have taken the time to find a seller. >>>>> >>>>> Or were you planning on enacting price controls on the market as >>>>> well? >>>>> >>>> >>>> No, I think justified need is the only required control on the >>>> market. I don't see a need for price >>>> controls, but, I do see a need to ensure that people like you do >>>> not get excessive address >>>> space just because you have greater financial resources vs. others >>>> who need it now, but >>>> have lesser financial resources. >>> >>> >>> >>> I see a need to ensure that people who have greater resources do not >>> get more additional address space than others who also need it, but >>> have lesser resources. > > OK, I responded to a comment, not a proposal or a thread. My bad. Still. > >>> Basically, what is being proposed here, stripped of a lot of heat >>> and light is an environment where more resources is a much better >>> advantage than currently. >>> >>> Who wouldn't want that? >> >> I don't have a problem with justified need for transfers. I *do* have >> a problem with creating large sets of people who can't even *use* >> transfers to fulfill their needs because the 3-month limit *they* are >> subject to is a lot different operationally than the 12-month limit >> the rest of the transfer recipients are subject to. > >> I do not see how someone can operate a business that will still need >> IPv4 addresses in order to function and yet be limited to only >> getting three months at a time via transfer when their competitors >> are allowed to get 12 months at a time via transfer. > > Not still need, need for the first time. > According to your subsequent comment to Marty: "The people this policy > change protects currently have no IPv4 space (as if they did they'd be > processed under the policy which does have the 12-month exemption), > but will need to acquire some after ARIN runout." Them *and* the folks who haven't had ARIN space for a full 12 months prior to when runout happens. This proposal gives both of those cases the same benefit when it comes to acquiring space via transfer that those who've had space from ARIN for >12 months at runout have... the ability to transfer a full 12 months worth of justified space, if they can find a seller and afford the price. > > People who have no IPv4 space, but will need to acquire some after > ARIN runout. This is exceptional advocacy. It also seems like a self > limiting problem. I am not sure whether giving them 12 months instead > of 3 will help that. ??? It helps in that 12 (or 24) months might be enough to get through the IPv6 transition. 3 is most certainly not. And the volatility of the transfer market means that those who are unable to get more than a 3 month supply are at a vast disadvantage, as opposed to pre-runout when it is simply a bit of extra paperwork. > > In any case, why on earth would you answer the question "Why should we > let you acquire more space now and deny that space to someone else..." > (meaning someone just now needing IPV4 space versus someone already in > the business) with "Because I can afford it and have taken the time to > find a seller." Some of us here on PPML, (eternally vituperated), > puzzled by wording and motive, wait until discussion seems to resolve > upon something that galvanizes us, to respond. I don't think in my > case you did your cause any favors with that response. I believe now > that I misunderstood at least the context of your statements. Would > you please do me the favor to identify, if you will, what party > getting into the IPV4 business after ARIN runout, other than > speculators, deserves favors such as this? Any party that wishes to offer services to both the IPv4 and IPv6 Internet who wasn't holding space for at least 12 months prior to runout (see below for the details). > >> Sure... back when there was a free pool, making them jump through the >> extra hoops every 3 months to show that they're doing the right thing >> makes (some) sense... but once there isn't, every time they get space >> might be their last. > > While I admit that my initial opposition to this was based on a > completely unprecedented misunderstanding, now that I think I > am clear(er) I am still opposed. Give bigger chunks of scarce IPV4 > space to _NEW_ entrants simply "Because I can afford it and have taken > the time to find a seller."? Insufficient information, at best. The proposal simply makes the justification required (12 months) identical for both new entrants (which includes folks who are getting space any time up to 12 months before ARIN runout) and those who have held ARIN space for more than 12 months already. That simply establishes WHO is allowed to bid for HOW MUCH space and then hopefully acquire it via the transfer market. As it stands, "new entrants" will be at a disadvantage in bidding for address space *even if they can afford it and have taken the time to find a seller* because they will only be allowed to bid for and transfer space that meets three months of future need, and then they're forced back to the transfer market then... as opposed to their competitors who have been around for 12 months or more at runout, who are able to bid for and transfer space that meets 12 (or 24, if my other proposal passes) months of space requirements... which might be long enough that they never need to come back to the transfer market again. In no way does it "give bigger chunks of scarce IPv4 space to new entrants"... they get to bid for space exactly the way everyone else does. What it eliminates is "forcing new entrants to take much smaller chunks of scarce IPv4 space via transfer simply because they're new" which I believe is equivalent to "makes the transfer market nearly useless for new entrants because the odds of being able to come back in three months and get more space is so uncertain as to pose a business risk too large for their investors". Matthew Kaufman From farmer at umn.edu Tue May 3 23:03:42 2011 From: farmer at umn.edu (David Farmer) Date: Tue, 03 May 2011 22:03:42 -0500 Subject: [arin-ppml] ARIN-prop-146 Clarify Justified Need for Transfers In-Reply-To: <4DC08664.4060905@matthew.at> References: <4DBEF120.4080901@arin.net> <88F39B20-5C20-45F0-AD61-5FA1E7F84CE3@delong.com> <3FCD1FDC-ECEE-4C9B-95C6-59E03D3C314E@matthew.at> <5598DFC7-E320-42FA-AA0E-C91C076BD725@delong.com> <6BA1EAA6-7D9C-44F9-BED7-884720F4B3BE@matthew.at> <05FAA29B-37BE-411C-95A4-50437602C8ED@delong.com> <4DBF6727.1090303@matthew.at> <097AAC1C-1F68-4820-9274-3290ADEFA195@delong.com> <4DBF75B7.3010407@matthew.at> <9501EA7E-FDAD-4DDA-B9E8-08C2811FF642@delong.com> <4DBF82F6.7050608@matthew.at> <20110503145144.N15967@mail.inlandnet.com> <4DC084E7.5000302@matthew.at> <4DC08664.4060905@matthew.at> Message-ID: <4DC0C20E.8020908@umn.edu> On 5/3/11 17:49 CDT, Matthew Kaufman wrote: > On 5/3/2011 3:42 PM, Matthew Kaufman wrote: >> >> Sure... back when there was a free pool, making them jump through the >> extra hoops every 3 months to show that they're doing the right thing >> makes (some) sense... but once there isn't, every time they get space >> might be their last. > > Oh, and since the "ARIN Community" is mostly made up of the "haves" and > has almost no representation (if any) from the "have nots" I have no > expectation that there will be widespread support for fixing transfer > policies for the "have nots". > > Not the only organization I'm involved with right now that suffers from > this policy-making flaw, I might add. You can count at least one Internet have as supporting this proposal, I know a few more that probably will to, it is just the kind of people we are and organizations we represent. :) However, while I support the concept of the proposal, I would like some thought given to how you verify a 12 month, or 24 month if this and 147 go forward, projection for an organization that has no history to back up the projection with. You probably need to replace the current slow start with some kind of concept, if we are going to call it a needs basis with a straight face. How about something like this, currently we are willing to allow a /20 on a 3 month basis, what if we allowed a /18 on a 12 month basis. It relaxes the restrictions on a new entrants, without throwing them completely out. I suppose you could go to a /16 on a 24 month basis, but I'm not sure I'm willing to go quite that far. I kind of like the idea of changing slow start for new entrants in this proposal to a /18 over 12 months and changing Subscriber Members After One Year to a 24 month supply in PP147. -- =============================================== 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 matthew at matthew.at Tue May 3 23:14:50 2011 From: matthew at matthew.at (Matthew Kaufman) Date: Tue, 03 May 2011 20:14:50 -0700 Subject: [arin-ppml] ARIN-prop-146 Clarify Justified Need for Transfers In-Reply-To: <4DC0C20E.8020908@umn.edu> References: <4DBEF120.4080901@arin.net> <88F39B20-5C20-45F0-AD61-5FA1E7F84CE3@delong.com> <3FCD1FDC-ECEE-4C9B-95C6-59E03D3C314E@matthew.at> <5598DFC7-E320-42FA-AA0E-C91C076BD725@delong.com> <6BA1EAA6-7D9C-44F9-BED7-884720F4B3BE@matthew.at> <05FAA29B-37BE-411C-95A4-50437602C8ED@delong.com> <4DBF6727.1090303@matthew.at> <097AAC1C-1F68-4820-9274-3290ADEFA195@delong.com> <4DBF75B7.3010407@matthew.at> <9501EA7E-FDAD-4DDA-B9E8-08C2811FF642@delong.com> <4DBF82F6.7050608@matthew.at> <20110503145144.N15967@mail.inlandnet.com> <4DC084E7.5000302@matthew.at> <4DC08664.4060905@matthew.at> <4DC0C20E.8020908@umn.edu> Message-ID: <4DC0C4AA.3050502@matthew.at> On 5/3/2011 8:03 PM, David Farmer wrote: > On 5/3/11 17:49 CDT, Matthew Kaufman wrote: >> On 5/3/2011 3:42 PM, Matthew Kaufman wrote: >>> >>> Sure... back when there was a free pool, making them jump through the >>> extra hoops every 3 months to show that they're doing the right thing >>> makes (some) sense... but once there isn't, every time they get space >>> might be their last. >> >> Oh, and since the "ARIN Community" is mostly made up of the "haves" and >> has almost no representation (if any) from the "have nots" I have no >> expectation that there will be widespread support for fixing transfer >> policies for the "have nots". >> >> Not the only organization I'm involved with right now that suffers from >> this policy-making flaw, I might add. > > You can count at least one Internet have as supporting this proposal, > I know a few more that probably will to, it is just the kind of people > we are and organizations we represent. :) > > However, while I support the concept of the proposal, I would like > some thought given to how you verify a 12 month, or 24 month if this > and 147 go forward, projection for an organization that has no history > to back up the projection with. You probably need to replace the > current slow start with some kind of concept, if we are going to call > it a needs basis with a straight face. Here I have been assuming that ARIN staff, who now have several years of experience evaluating the space justifications for both existing and new entrants, will be able to review these adequately. > > How about something like this, currently we are willing to allow a /20 > on a 3 month basis, what if we allowed a /18 on a 12 month basis. It > relaxes the restrictions on a new entrants, without throwing them > completely out. I suppose you could go to a /16 on a 24 month basis, > but I'm not sure I'm willing to go quite that far. > I would be ok with some sort of upper bound as long as it is reasonably high to accommodate legitimate new entrants, or with some guideline for staff to follow. > I kind of like the idea of changing slow start for new entrants in > this proposal to a /18 over 12 months and changing Subscriber Members > After One Year to a 24 month supply in PP147. > > > > Something like that, sure. Matthew Kaufman From v6ops at globis.net Wed May 4 02:42:11 2011 From: v6ops at globis.net (Ray Hunter) Date: Wed, 04 May 2011 08:42:11 +0200 Subject: [arin-ppml] ARIN-prop-146 Clarify Justified Need for, Transfers Message-ID: <4DC0F543.100@globis.net> > > I'm not sure what you're asking. > > The people this policy change protects currently have no IPv4 space (as > if they did they'd be processed under the policy which does have the > 12-month exemption), but will need to acquire some after ARIN runout. I > have yet to see a single person who appears like they might fall into > that category post on the list this week. > > Matthew Kaufman > My company's current IPv4 space consists of 1 fixed /32 PA space outside the ARIN space. Not a lot I know, but enough for a single NAT4 gateway and to be able to provide some inbound services too (mail, web, ssh, admin system etc,) The people I provide consultancy for are similarly mostly outside of ARIN. One day I or one my customers might (who can predict the future) start offering IPv6 migration services in the US (since the US seems to be lagging in this respect it could turn out to be good business.) Then we'd probably need some space for an IPv6 NAT64 DNS64 to IPv4 gateway. The reason I'm reading this list is that ARIN's policy for the last few IPv4 blocks will also almost certainly have a direct knock on effect for me and my customers in Europe, Africa, and Asia Pacific. I'm very grateful that the arin-ppml list is open to all. I'm sure there are a lot more lurkers too. Does that count? regards, RayH From jeffrey.lyon at blacklotus.net Wed May 4 03:24:24 2011 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Wed, 4 May 2011 03:24:24 -0400 Subject: [arin-ppml] ARIN-prop-147 Set Transfer Need to 24 months and Clarify Exception In-Reply-To: References: <4DBEF12A.2020002@arin.net> Message-ID: On Tue, May 3, 2011 at 9:49 PM, William Herrin wrote: > On Mon, May 2, 2011 at 2:00 PM, ARIN wrote: >> ARIN-prop-147 Set Transfer Need to 24 months and Clarify Exception >> Proposal Originator: Matthew Kaufman >> >> Policy statement: >> >> Change section 4.2.4.4 content as follows: >> >> Replace: >> "This reduction does not apply to resources received via section 8.3. An >> organization receiving a transfer under section 8.3 may continue to >> request up to a 12-month supply of IP addresses." >> >> With: >> "This reduction does not apply to resources received via transfer. An >> organization receiving a transfer under section 8 may request up to a >> 24-month supply of IP addresses." >> >> Timetable for implementation: immediate > > Hi Matthew, > > In principle, I support allowing recipients of addresses under section > 8.3 to justify their use on a 24-month horizon. The shorter horizons > were intended to dissuade folks from asking for more than they really > need of a dwindling free resource. Under 8.3, that resource is no > longer free. The cost will be sufficient to provide the backpressure > that the short estimating horizons provide now. > > I don't like this wording. For one thing, 4.2.4.4 is the wrong place > for this -- it should apply evenly to ISPs and end-users and should > apply regardless of the length of time the registrant has been a > "subscriber member." And by the way, how the heck did when end up with > such an odd term, "subscriber member," which is not defined anywhere > and used nowhere else in the document. How is it intended to be > different than the term "LIR?" > > Also, I'm not convinced that such a policy should be implemented prior > to the exhaustion of ARIN's normal allocation pool. > > 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. > I would support this. I would support it even more if it were 36 months. -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications - AS32421 First and Leading in DDoS Protection Solutions From hannigan at gmail.com Wed May 4 08:52:32 2011 From: hannigan at gmail.com (Martin Hannigan) Date: Wed, 4 May 2011 08:52:32 -0400 Subject: [arin-ppml] ARIN-prop-147 Set Transfer Need to 24 months and Clarify Exception In-Reply-To: References: <4DBEF12A.2020002@arin.net> Message-ID: I think that 36 months is probably a realistic target. A three year planning horizon with respect to such an important issue is probably not unreasonable. Best, -M< On Wed, May 4, 2011 at 3:24 AM, Jeffrey Lyon wrote: > On Tue, May 3, 2011 at 9:49 PM, William Herrin wrote: >> On Mon, May 2, 2011 at 2:00 PM, ARIN wrote: >>> ARIN-prop-147 Set Transfer Need to 24 months and Clarify Exception >>> Proposal Originator: Matthew Kaufman >>> >>> Policy statement: >>> >>> Change section 4.2.4.4 content as follows: >>> >>> Replace: >>> "This reduction does not apply to resources received via section 8.3. An >>> organization receiving a transfer under section 8.3 may continue to >>> request up to a 12-month supply of IP addresses." >>> >>> With: >>> "This reduction does not apply to resources received via transfer. An >>> organization receiving a transfer under section 8 may request up to a >>> 24-month supply of IP addresses." >>> >>> Timetable for implementation: immediate >> >> Hi Matthew, >> >> In principle, I support allowing recipients of addresses under section >> 8.3 to justify their use on a 24-month horizon. The shorter horizons >> were intended to dissuade folks from asking for more than they really >> need of a dwindling free resource. Under 8.3, that resource is no >> longer free. The cost will be sufficient to provide the backpressure >> that the short estimating horizons provide now. >> >> I don't like this wording. For one thing, 4.2.4.4 is the wrong place >> for this -- it should apply evenly to ISPs and end-users and should >> apply regardless of the length of time the registrant has been a >> "subscriber member." And by the way, how the heck did when end up with >> such an odd term, "subscriber member," which is not defined anywhere >> and used nowhere else in the document. How is it intended to be >> different than the term "LIR?" >> >> Also, I'm not convinced that such a policy should be implemented prior >> to the exhaustion of ARIN's normal allocation pool. >> >> 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. >> > > I would support this. I would support it even more if it were 36 months. > > -- > Jeffrey Lyon, Leadership Team > jeffrey.lyon at blacklotus.net | http://www.blacklotus.net > Black Lotus Communications - AS32421 > First and Leading in DDoS Protection Solutions > _______________________________________________ > 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 4 12:31:16 2011 From: owen at delong.com (Owen DeLong) Date: Wed, 4 May 2011 09:31:16 -0700 Subject: [arin-ppml] Fw: Accusationof fundamentalconflictofinterest/IPaddress policypitched directly to ICANN In-Reply-To: References: <379DB08FB5564ED88230C1B6D6AE80FE@mike> <8695009A81378E48879980039EEDAD289D0E5BC6@MAIL1.polartel.local> Message-ID: On May 3, 2011, at 1:15 PM, Mike Burns wrote: > Hi Kevin, answers inline. > > >> Really? > >> You think that the DNS registry system that is in place today is a standard to which ARIN should aspire? > > I remember paying $100 for domain names from Network Solutions that I can get instantly now for $6. > I remember domain names being free and based on first-come, first-served without regard to copyright or trademark issues as they were not considered linked or intersecting namespaces. The privatization of DNS with a for-profit entity (Network Solutions) was the first step down the slide into today's degenerate chaos. The fact that modern degenerate chaos is less expensive than early degenerate chaos does not change the fact that it is still degenerate chaos. I remember requirements which prevented companies from polluting the namespace with every possible or perceived possible random spelling, misspelling, and permutation of TLD they could think of to point to the exact same RHS information. I remember a civilized system without domain tasting and several other tools currently providing tremendous assistance to spammers. > >> You think that it will be better when IP addresses are managed in the various courts and by the various governments around the world? Do you realize that when government starts managing a resource they have to >pay for that management somehow? Guess how they will do that.. > > I am not asking governments to manage resources, I am asking them to settle inevitable conflicts of law and custom. For example, witness the issues related to domain names and trademarks. > Those kinds of decisions require governments to make them. In the case of ip transfers, all I expect the government to treat them like the assets they are. The government inevitably deals with assets when they tax, for example, and when they handle them in divorce or bankruptcy cases, ahem, for example. > If we had simply stuck to the idea that domain names are a separate namespace from trademarks and are issued first-come-first-serve with limits on the number of domain names an organization could possess (as used to be the case), those issues would not have really existed. It was when ICANN brought WIPO into the process and started putting policies in place for the mapping of trademarks onto domain names that this problem manifested itself and we began on the road to the mess we have today. >> When the US government (not to mention others) gets in to play on this how far do you think we will be from a 'Department of Internet Commerce'? Do you really want to hasten that eventuality? > > I'm not clear on how removing justification requirements (or creating private registries) will lead to the Department of Internet Commerce. By all means, please understand that the very idea is antithetical to my thinking, so you will have to describe the process you are describing. > You seem to be unclear on how removing community based policy from address administration will result in a destabilization of the internet which would inevitably lead to greater regulation. I suspect your "sell 'em all and let the market sort 'em out" ideology provides such a different base frame of reference from my "central management of address resources in accordance with community consensus based policies creates and preserves stability and rational resource distribution" ideology that I'm not sure I know how to clarify it in a way that you would be able to internalize. The current internet is the result of the current system. I believe that it is working reasonably well for a great many people. Admittedly, we have no data on how your approach would affect number resource management because nobody that I know of in history has ever attempted such an approach. IMHO, this is because of the extreme risks associated with such an approach. I can point to examples of where I think your philosophy has led in other non-number resource environments: Enron Worldcom Collateralized Mortgage Obligations Savings and Loans/Charles Keating Union Carbide/Bhopal, India British Petroleum/Gulf of Mexico Exxon/Valdez, Alaska and finally, your own example: The current state of ICANN managed DNS structures The fact that you consider this last example some sort of shining beacon of how things should be (obviously I have a very different perspective) is, I believe, indicative of the chasm between our perspectives which makes it difficult to find a common frame of reference for the discussion. > >> If everyone would play nice and not be driven by greed or power then I would be inclined to agree with some of your propositions. Unfortunately we are living in a far from perfect world. >> Kevin >> qui totum vult totum perdit > > My concept of free markets are based on self-interest (greed, if you will). > I appealed to the idea of the Invisible Hand as an example of how self-interest leads to the greater good through free markets. > I don't know what part of my ideology relies on people playing nice, I think the opposite idea is usually attributed to my ideas. > > The problem with free markets is that they rarely actually tie greed to the common good, but, rather assume that the common good is the inevitable result of greed in the market. Most (all) functional markets end up with rather large bodies of regulation that are constantly being adapted to new and different mechanisms used to "game the system". Even with such bodies of regulation, markets tend, over time, to become increasingly dysfunctional and more and more disconnected from actually achieving any common good. Owen -------------- next part -------------- An HTML attachment was scrubbed... URL: From owen at delong.com Wed May 4 12:40:38 2011 From: owen at delong.com (Owen DeLong) Date: Wed, 4 May 2011 09:40:38 -0700 Subject: [arin-ppml] Fw: Accusation offundamentalconflictofinterest/IPaddress policy pitched directly to ICANN In-Reply-To: <2305188FE5E044ECBB236FB6B92D03B7@mike> References: <2305188FE5E044ECBB236FB6B92D03B7@mike> Message-ID: <27B8133F-B2AC-49F8-BA91-B448379C291E@delong.com> On May 3, 2011, at 1:41 PM, Mike Burns wrote: > Hi Dan, > > It is just that it seems circular to me that RIRs decide whether to extend their own oversight rules to competing registries. Repeating a false assumption does not make it true. The RIRs don't decide, the RIR communities decide. The RIRs act on the basis of the policies developed by their communities. Currently there is no provision for "competing" registries and so there is no such structure against which to base such an assertion. Indeed, in order to create competing registries, a global policy specifying the structure by which those would be managed and/or regulated would need to be adopted. Such a global policy would need the assent of all 5 RIR communities and would then be adopted by the ASO AC and, essentially, rubber-stamped by the ICANN board. The ICANN board role is (as noted in the documents) primarily to act as a check and balance to ensure that global policies were developed through the correct process and can be feasibly implemented at the ICANN level. > If they can decide elements related to their own oversight, who is overseeing them? Again, you have repeated the same invalid assumption and are asking questions based on that assumption. The RIRs do not decide their own oversight. The RIR communities decide the oversight. The communities oversee the RIRs. The RIRs oversee only the address resources under their administration. The elected members of the ARIN AC and the ARIN BoT oversee the policy development process by which the community expresses those policies. Those members are overseen by the members of ARIN who elect them. > If they are overseeing themselves, why is IANA approval needed for the creation of new RIRs? > (Formality or not.) > Look at how IANA is governed in this regard. It is, essentially, the collective of the RIRs. The NRO NC (comprised of members elected by the RIR communities) serves as the ASO AC and is the body that does this approval. Owen > But I understand the concept you are invoking here about under-sight guarding oversight, if you will. > > Regards, > > Mike > > ----- Original Message ----- > From: Alexander, Daniel > To: Mike Burns ; arin-ppml at arin.net > Sent: Tuesday, May 03, 2011 4:34 PM > Subject: Re: [arin-ppml] Fw: Accusation offundamentalconflictofinterest/IPaddress policy pitched directly to ICANN > > Hey Mike, > > I will get you the dates shortly. Just confirming some of the deadlines. > > On a separate point, I have to disagree with one comment below. Quis custodiet ipsos custodes, suggesting the RIR oversee themselves. The problem is that the RIR do not make the policies. It is the thousands of individuals in the Internet technical community around the world (of which you are included) that make the rules. > > I have seen Internet policy shaped by large corporations, small town ISPs, individuals from all corners of the globe that have no political clout or financial influence, and am watching you shape the discussion right here. This past week I have seen the head of ARIN acknowledge several points made on this list regarding transfer policies, the RSA, and operational procedures that may lead to changes in the future. I have a hard time understanding your question of who is watching the RIR when you are one of the watchmen you are asking about. > > -Dan > > From: Mike Burns > Date: Tue, 3 May 2011 15:02:03 -0400 > To: Microsoft Office User , > Subject: Re: [arin-ppml] Fw: Accusation of fundamentalconflictofinterest/IPaddress policy pitched directly to ICANN > > Hi Dan, > > Yes, I do support the kind of oversight recommended in the letter, using as a model the requirements to be a DNS registrar. > Perhaps this alone is justification for the highest level decisionmaking. > Since a competing registry would be on the same level as the existing RIR's, in effect we would be asking the RIRs to oversee themselves if we allowed the RIRs to decide the issue, whether at the RIR or ASO level. > Quis custodiet ipsos custodes? > > I do understand and appreciate the beauty of the non-governmental approach to Internet governance. > > I think the many kinds of conflicts you reference in your last paragraph are likely to be sorted out around the world in courts and legislatures, which I think are probably better suited to that task than ARIN. > Much like the evolution (or de-evolution) of the Domain Name System. > > I will certainly vet any policy proposal I offer here, though can you give me an idea of the timeframe for proposals to be considered at the next AC meeting, should enough support manifest on the list? > > Regards, > > Mike > > > ----- Original Message ----- > From: Alexander, Daniel > To: arin-ppml at arin.net > Sent: Tuesday, May 03, 2011 2:49 PM > Subject: Re: [arin-ppml] Fw: Accusation of fundamentalconflictofinterest/IPaddress policy pitched directly to ICANN > > Mike, > > As one of the AC shepherds for the proposals that were abandoned, I would offer one suggestion. Feel free to vet the proposal language you are considering here on this list prior to submitting an actual proposal. That is what this list is for. It would also help refine the scope that Keith mentions, and avoid the confusion that earlier proposals created. It is much easier to refine and evolve policy language on the ppml before it becomes part of the PDP process. > > If you look back to proposals 133, 134, and 136, they suggested that resource holders could opt-in, opt-out, or find the lowest common denominator to establish claim. While this would allow for what you propose, they offered none of the oversight that you advocate, which is also why there was such a cold reception. > > You can see how a competing registry, that is operating properly, could do so in a complimentary manner to the RIR. One thing people will have issue with is how the overall model can exist with the individuals who would try to create registries that would not apply similar standards of operation. Without any protections, the ISP's who would have to rely on this data would not be able to depend on the overall system (not referring to any particular registry) which is the shift in burden I mentioned in an earlier post. > > While people may have issues with the quality of whois, or registration of assignments, there is an upside to the current system. In this region, data points to ARIN and anyone can get involved, change the rules, and try and hold ARIN accountable. In the distributed model that is proposed, accountability is spread out, and the ability to resolve conflicts or issues becomes much harder. These are the kind of concerns that need to be addressed in order to gain momentum on a change of this scale. > > I hope this helps. > > Dan Alexander > ARIN AC- speaking only for myself > > From: "Keith W. Hare" > Date: Tue, 3 May 2011 13:56:28 -0400 > To: Mike Burns , "arin-ppml at arin.net" > Subject: Re: [arin-ppml] Fw: Accusation of fundamental conflictofinterest/IPaddress policy pitched directly to ICANN > > Mike, > So far, we have seen only bits of policy proposals that hint at the idea of competing private address registries. Without a policy proposal that covers all of the details, we are left to extrapolate the remaining pieces. This extrapolation may or may not be what competing address registry proponents have in mind, but until we see a full policy proposal, we are left with only perceptions of your (and others) motivations. > Keith > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Mike Burns > Sent: Tuesday, May 03, 2011 1:23 PM > To: John Sweeting > Cc: arin-ppml at arin.net > Subject: Re: [arin-ppml] Fw: Accusation of fundamental conflictofinterest/IPaddress policy pitched directly to ICANN > It really is as easy as rounding up all the support you can muster, have that support join PPML, submit the proposal that you would like see made policy and then have your support show their support through PPML and the next PPM. Is there a reason you do not want to follow that process? It might help gain support if you provided your underlying motivation(s). > -John Sweeting > Hi John, > My interest is in having a market for the buying and selling of IP addresses free from government and psuedo-government restrictions like taxes and justification requirements. > I think this will best serve the interests of a community long held in thrall to the vision of an IPv6 transition that simply has not occurred in anything like the predicted timeframe. > I would prefer that any support I find not be motivated by perceptions of my motivations, just my words and ideas. > I voiced support for the concept of having a informed higher authority make the decision about competing registries requested in the letter which started the thread. I support competing registries because I believe that their competitive forces will move the market towards freedom, and because presumably a competing registry could decide its own, more liberal transfer policy. > My understanding is that one way to get that accomplished, and I will accede it would be the better way, would be for the participants in policy making in all 5 RIRs come together to forge a policy allowing for competing private registries. > But I think that is like expecting Network Solutions to have voted for competing DNS registrars. Unlikely to happen due to institutional conflicts of interest. > (I understand that NetSol was not a community run org like the RIRs, but I see a natural institutional conflict between those who dominate a closed market and those who seek to expand it.) > (And yes, this is also a commentary on the tiny number of participants who seem to people the RIR executive positions, and by extension the tiny groups of vocal participants in the RIR-PPML process.) > (And yes, I have lost trust in ARIN staff since the MS/Nortel debacle) > But nobody seems too sure what that higher authority is, and of course some participants see the community of RIR-PPML participants as the highest authority of all. > I didn't write that letter, nor do I have any relationship with the writer of the letter, to my knowledge I have never met, conversed, or emailed with him. > As for changing policy in the ARIN region, that is my intent, and I have heard from another poster who is interested in co-sponsoring a proposal designed to create a free market for ip transfers. > So I will work with him to do just as you say, round up support and see if we can get a proposal that passes muster with the PPML and can be included in the next PPM. > Regards, > Mike Burns > _______________________________________________ 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 owen at delong.com Wed May 4 12:47:37 2011 From: owen at delong.com (Owen DeLong) Date: Wed, 4 May 2011 09:47:37 -0700 Subject: [arin-ppml] ARIN-prop-146 Clarify Justified Need for Transfers In-Reply-To: <4DC084E7.5000302@matthew.at> References: <4DBEF120.4080901@arin.net> <88F39B20-5C20-45F0-AD61-5FA1E7F84CE3@delong.com> <3FCD1FDC-ECEE-4C9B-95C6-59E03D3C314E@matthew.at> <5598DFC7-E320-42FA-AA0E-C91C076BD725@delong.com> <6BA1EAA6-7D9C-44F9-BED7-884720F4B3BE@matthew.at> <05FAA29B-37BE-411C-95A4-50437602C8ED@delong.com> <4DBF6727.1090303@matthew.at> <097AAC1C-1F68-4820-9274-3290ADEFA195@delong.com> <4DBF75B7.3010407@matthew.at> <9501EA7E-FDAD-4DDA-B9E8-08C2811FF642@delong.com> <4DBF82F6.7050608@matthew.at> <20110503145144.N15967@mail.inlandnet.com> <4DC084E7.5000302@matthew.at> Message-ID: <850851FF-378A-417B-A081-35D619F8CD8F@delong.com> On May 3, 2011, at 3:42 PM, Matthew Kaufman wrote: > On 5/3/2011 3:33 PM, John Springer wrote: >> I oppose proposal ARIN-prop-146. >> Comments inline. >> >> On Tue, 3 May 2011, Owen DeLong wrote: >>> >>> On May 2, 2011, at 9:22 PM, Matthew Kaufman wrote: >>> >>>> On 5/2/2011 8:47 PM, Owen DeLong wrote: >>>>> >>>>> Welcome to the post-run-out world. Why should we let you acquire more space now and deny that >>>>> space to someone else who has justified need now? >>>> >>>> Because I can afford it and have taken the time to find a seller. >>>> >>>> Or were you planning on enacting price controls on the market as well? >>>> >>> >>> No, I think justified need is the only required control on the market. I don't see a need for price >>> controls, but, I do see a need to ensure that people like you do not get excessive address >>> space just because you have greater financial resources vs. others who need it now, but >>> have lesser financial resources. >> >> >> >> I see a need to ensure that people who have greater resources do not get more additional address space than others who also need it, but have lesser resources. >> >> Basically, what is being proposed here, stripped of a lot of heat and light is an environment where more resources is a much better advantage than currently. >> >> Who wouldn't want that? > > I don't have a problem with justified need for transfers. I *do* have a problem with creating large sets of people who can't even *use* transfers to fulfill their needs because the 3-month limit *they* are subject to is a lot different operationally than the 12-month limit the rest of the transfer recipients are subject to. > > I do not see how someone can operate a business that will still need IPv4 addresses in order to function and yet be limited to only getting three months at a time via transfer when their competitors are allowed to get 12 months at a time via transfer. > > Sure... back when there was a free pool, making them jump through the extra hoops every 3 months to show that they're doing the right thing makes (some) sense... but once there isn't, every time they get space might be their last. > > Matthew Kaufman I don't see how someone can expect to operate a business that will still need additional IPv4 addresses. Owen From owen at delong.com Wed May 4 12:51:47 2011 From: owen at delong.com (Owen DeLong) Date: Wed, 4 May 2011 09:51:47 -0700 Subject: [arin-ppml] ARIN-prop-146 Clarify Justified Need for Transfers In-Reply-To: <4DC08664.4060905@matthew.at> References: <4DBEF120.4080901@arin.net> <88F39B20-5C20-45F0-AD61-5FA1E7F84CE3@delong.com> <3FCD1FDC-ECEE-4C9B-95C6-59E03D3C314E@matthew.at> <5598DFC7-E320-42FA-AA0E-C91C076BD725@delong.com> <6BA1EAA6-7D9C-44F9-BED7-884720F4B3BE@matthew.at> <05FAA29B-37BE-411C-95A4-50437602C8ED@delong.com> <4DBF6727.1090303@matthew.at> <097AAC1C-1F68-4820-9274-3290ADEFA195@delong.com> <4DBF75B7.3010407@matthew.at> <9501EA7E-FDAD-4DDA-B9E8-08C2811FF642@delong.com> <4DBF82F6.7050608@matthew.at> <20110503145144.N15967@mail.inlandnet.com> <4DC084E7.5000302@matthew.at> <4DC08664.4060905@matthew.at> Message-ID: <4791A59E-8864-483C-9BB0-03A6A5B8D50C@delong.com> On May 3, 2011, at 3:49 PM, Matthew Kaufman wrote: > On 5/3/2011 3:42 PM, Matthew Kaufman wrote: >> >> Sure... back when there was a free pool, making them jump through the extra hoops every 3 months to show that they're doing the right thing makes (some) sense... but once there isn't, every time they get space might be their last. > > Oh, and since the "ARIN Community" is mostly made up of the "haves" and has almost no representation (if any) from the "have nots" I have no expectation that there will be widespread support for fixing transfer policies for the "have nots". > If this is true, it is only because the have-nots have, thus far, chosen not to subscribe to the list and participate. If you know them and feel they are being substantially disadvantaged in this debate, the rational solution is to encourage them to subscribe and chime in. If you are claiming that the "have nots" also "have not" e-mail addresses, then, I have to wonder if they also "have not" internet connections. If they "have not" internet connections, then, I'm not sure how far we need to go on incorporating them into the policy making community for users of the internet. I would agree that if you truly believe the reason they "have not" internet connections is due to policies made by this body, that should be expressed and examined carefully. I certainly support the idea of making the internet available to the widest possible number of people and if the policies we have adopted are somehow contrary to that, I would be interested in correcting that fact. Owen From mike at nationwideinc.com Wed May 4 14:16:49 2011 From: mike at nationwideinc.com (Mike Burns) Date: Wed, 4 May 2011 14:16:49 -0400 Subject: [arin-ppml] Fw: Accusationof fundamentalconflictofinterest/IPaddress policypitched directly to ICANN References: <379DB08FB5564ED88230C1B6D6AE80FE@mike> <8695009A81378E48879980039EEDAD289D0E5BC6@MAIL1.polartel.local> Message-ID: <6B65D21B9B7543208304CC44EDD22444@mike> Hi Owen, I think private registries are a good idea. I think Benson's proposals would have led to them, but were voted down by the ARIN community. One of the reasons given was the lack of oversight which would result from the implementation of Benson's proposals. To my mind, such oversight can only come from a higher level. The proposed private registry after all, would be on the same level and performing the same function as the RIRs. ICANN is the higher level, in my mind, based on their clear approval responsiblity for new RIRs, and their predating the RIRs. ICANN has a policymaking apparatus which is being appealed to by the writer of the letter which started this thread. Here is a document I found which proposes that ICANN adopts a set of requirements for those who wish to provide private registry services: http://www.icann.org/en/correspondence/statement-ip-address-registrar-accreditation-policy-31mar11-en.pdf I just skimmed it, but if the community decided that Benson's proposals suffered only from a lack of oversight, and required action at a global level, then perhaps they will add their voice to the support which I offered. If the action happens at this level as a result of an informed decisionmaking process at ICANN, then I am happy because it will expedite the appearance of competing registries. And why do I want competing registries? Is it because ARIN charges too much, or their website is hard to navigate? Is it because I wish to take my business elsewhere as a statement against ARIN staff? Is it their response time? Is it because I am a buyer who requires more than officer attestation for determining the right to sell addresses? Is it because I am a buyer who does not wish to sign an LRSA or RSA? Is it because I choose a 5 year planning horizon? Do I want to transfer out of region? No, none of those reasons, although are all, in my mind, potentially valid reasons for somebody to change registries. It is because I think a competing registrar would naturally reduce barriers to transfers. And that is my underlying goal. In fact, ARIN could probably pull the rug out from under a private registry by beating them to the punch and removing restrictions for all transfers. (I think needs analysis should be done on free-pool allocations, though. I hope that goes without saying.) As for the talk about the perils or benefits of free markets, I will leave that aside in the belief that the readers have internalized our different perspectives. Regards, Mike -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthew at matthew.at Wed May 4 14:18:33 2011 From: matthew at matthew.at (Matthew Kaufman) Date: Wed, 4 May 2011 11:18:33 -0700 Subject: [arin-ppml] ARIN-prop-146 Clarify Justified Need for Transfers In-Reply-To: <850851FF-378A-417B-A081-35D619F8CD8F@delong.com> References: <4DBEF120.4080901@arin.net> <88F39B20-5C20-45F0-AD61-5FA1E7F84CE3@delong.com> <3FCD1FDC-ECEE-4C9B-95C6-59E03D3C314E@matthew.at> <5598DFC7-E320-42FA-AA0E-C91C076BD725@delong.com> <6BA1EAA6-7D9C-44F9-BED7-884720F4B3BE@matthew.at> <05FAA29B-37BE-411C-95A4-50437602C8ED@delong.com> <4DBF6727.1090303@matthew.at> <097AAC1C-1F68-4820-9274-3290ADEFA195@delong.com> <4DBF75B7.3010407@matthew.at> <9501EA7E-FDAD-4DDA-B9E8-08C2811FF642@delong.com> <4DBF82F6.7050608@matthew.at> <20110503145144.N15967@mail.inlandnet.com> <4DC084E7.5000302@matthew.at> <850851FF-378A-417B-A081-35D619F8CD8F@delong.com> Message-ID: <295A51D9-36F8-49A2-A811-27837E404D57@matthew.at> On May 4, 2011, at 9:47 AM, Owen DeLong wrote: > > On May 3, 2011, at 3:42 PM, Matthew Kaufman wrote: >> >> I do not see how someone can operate a business that will still need IPv4 addresses in order to function and yet be limited to only getting three months at a time via transfer when their competitors are allowed to get 12 months at a time via transfer. >> >> Sure... back when there was a free pool, making them jump through the extra hoops every 3 months to show that they're doing the right thing makes (some) sense... but once there isn't, every time they get space might be their last. >> >> > > I don't see how someone can expect to operate a business that will still need additional IPv4 addresses. So then why do you care what the needs criteria is for IPv4? For the next several years there will be businesses, existing and new, that will need IPv4 addresses in order to be reachable on the IPv4 Internet. There are addresses out there, that for enough money people would take the time to part with in order to fulfill the requirements during these next several years. Your position is that we should make it as unfair as possible to as many people as possible who might be on the "need" side of this equation, as far as I can tell. Matthew Kaufman -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthew at matthew.at Wed May 4 14:22:25 2011 From: matthew at matthew.at (Matthew Kaufman) Date: Wed, 4 May 2011 11:22:25 -0700 Subject: [arin-ppml] ARIN-prop-146 Clarify Justified Need for Transfers In-Reply-To: <4791A59E-8864-483C-9BB0-03A6A5B8D50C@delong.com> References: <4DBEF120.4080901@arin.net> <88F39B20-5C20-45F0-AD61-5FA1E7F84CE3@delong.com> <3FCD1FDC-ECEE-4C9B-95C6-59E03D3C314E@matthew.at> <5598DFC7-E320-42FA-AA0E-C91C076BD725@delong.com> <6BA1EAA6-7D9C-44F9-BED7-884720F4B3BE@matthew.at> <05FAA29B-37BE-411C-95A4-50437602C8ED@delong.com> <4DBF6727.1090303@matthew.at> <097AAC1C-1F68-4820-9274-3290ADEFA195@delong.com> <4DBF75B7.3010407@matthew.at> <9501EA7E-FDAD-4DDA-B9E8-08C2811FF642@delong.com> <4DBF82F6.7050608@matthew.at> <20110503145144.N15967@mail.inlandnet.com> <4DC084E7.5000302@matthew.at> <4DC08664.4060905@matthew.at> <4791A59E-8864-483C-9BB0-03A6A5B8D50C@delong.com> Message-ID: On May 4, 2011, at 9:51 AM, Owen DeLong wrote: > > On May 3, 2011, at 3:49 PM, Matthew Kaufman wrote: > >> On 5/3/2011 3:42 PM, Matthew Kaufman wrote: >>> >>> Sure... back when there was a free pool, making them jump through the extra hoops every 3 months to show that they're doing the right thing makes (some) sense... but once there isn't, every time they get space might be their last. >> >> Oh, and since the "ARIN Community" is mostly made up of the "haves" and has almost no representation (if any) from the "have nots" I have no expectation that there will be widespread support for fixing transfer policies for the "have nots". >> > If this is true, it is only because the have-nots have, thus far, chosen not to subscribe to the list and > participate. If you know them and feel they are being substantially disadvantaged in this debate, the > rational solution is to encourage them to subscribe and chime in. I am claiming that the future "have nots" are totally unaware today that they need to participate in order to be able to do what they haven't yet started in the future. My 7 year old isn't lobbying for rollbacks on the new restrictions for teen drivers this week either, because he simply hasn't thought about driving himself around enough to realize that his ability to take his brother out with him when he turns 16 has been eliminated in this state. Matthew Kaufman From owen at delong.com Wed May 4 14:59:47 2011 From: owen at delong.com (Owen DeLong) Date: Wed, 4 May 2011 11:59:47 -0700 Subject: [arin-ppml] ARIN-prop-146 Clarify Justified Need for Transfers In-Reply-To: <295A51D9-36F8-49A2-A811-27837E404D57@matthew.at> References: <4DBEF120.4080901@arin.net> <88F39B20-5C20-45F0-AD61-5FA1E7F84CE3@delong.com> <3FCD1FDC-ECEE-4C9B-95C6-59E03D3C314E@matthew.at> <5598DFC7-E320-42FA-AA0E-C91C076BD725@delong.com> <6BA1EAA6-7D9C-44F9-BED7-884720F4B3BE@matthew.at> <05FAA29B-37BE-411C-95A4-50437602C8ED@delong.com> <4DBF6727.1090303@matthew.at> <097AAC1C-1F68-4820-9274-3290ADEFA195@delong.com> <4DBF75B7.3010407@matthew.at> <9501EA7E-FDAD-4DDA-B9E8-08C2811FF642@delong.com> <4DBF82F6.7050608@matthew.at> <20110503145144.N15967@mail.inlandnet.com> <4DC084E7.5000302@matthew.at> <850851FF-378A-417B-A081-35D619F8CD8F@delong.com> <295A51D9-36F8-49A2-A811-27837E404D57@matthew.at> Message-ID: <0B8E630B-857C-49AB-B55A-896D276A9C9C@delong.com> On May 4, 2011, at 11:18 AM, Matthew Kaufman wrote: > > On May 4, 2011, at 9:47 AM, Owen DeLong wrote: > >> >> On May 3, 2011, at 3:42 PM, Matthew Kaufman wrote: >>> >>> I do not see how someone can operate a business that will still need IPv4 addresses in order to function and yet be limited to only getting three months at a time via transfer when their competitors are allowed to get 12 months at a time via transfer. >>> >>> Sure... back when there was a free pool, making them jump through the extra hoops every 3 months to show that they're doing the right thing makes (some) sense... but once there isn't, every time they get space might be their last. >>> >>> >> >> I don't see how someone can expect to operate a business that will still need additional IPv4 addresses. > > So then why do you care what the needs criteria is for IPv4? > > For the next several years there will be businesses, existing and new, that will need IPv4 addresses in order to be reachable on the IPv4 Internet. There are addresses out there, that for enough money people would take the time to part with in order to fulfill the requirements during these next several years. Your position is that we should make it as unfair as possible to as many people as possible who might be on the "need" side of this equation, as far as I can tell. > > Matthew Kaufman I suppose I should have been less succinct and more clear. I don't think that bring a new business that is IPv4-dependent forth and counting on some form of continued availability of IPv4 resources is in any way going to be a viable business plan beyond IPv4 free pool exhaustion. Your assertion that there are addresses out there for the right price is true for a rather limited time and a relatively small quantity of addresses in my estimation. My position is that we should make it as fair as possible to as many people as possible who might be on the need side of this equation by limiting the amount that any one organization can obtain at a time through this process to their reasonably projected need for a limited time in much the same way we have also limited the distribution of the pre-runout free pool. Your argument is that we should allow anyone with enough money to grab as much of the resources as they can as quickly as they can and preclude any future entrants. As such, I'm finding it hard to understand how you consider my argument to maximize unfairness or believe that yours is in any way more fair. Owen -------------- next part -------------- An HTML attachment was scrubbed... URL: From wavetossed at googlemail.com Sun May 1 17:43:46 2011 From: wavetossed at googlemail.com (Michael Dillon) Date: Sun, 1 May 2011 14:43:46 -0700 Subject: [arin-ppml] New Entrants shut out? (Was: ARIN-2011-5: ... - Last Call In-Reply-To: <4DBB41AE.20007@ipinc.net> References: <4DBAF9E2.80000@globis.net> <4DBB305F.3010205@umn.edu> <4DBB41AE.20007@ipinc.net> Message-ID: > In the meantime, during the time period that IPv4 is "out" yet IPv4 > still remains the dominant method of connection to the Internet, then > yes, new ISP entrants will be "shut out" ?This will not last - but > wanna-be ISPs should probably shelve their business plans for another > decade and go find something else to do until the issue sorts itself out. That's a bit harsh. First of all, I don't think that the "shut out" will last anything close to a decade. More like a year or two. And most importantly, you will get a head start if you already have IP network expertise, and the way to do that is to build up some other IP network related business today, and then exand into ISP services when you are ready. If you can put your thinking cap on, gaze into the future a decade or more, and see what kind of additional services a successful ISP would have in addition the current model. Then build a business around one of those additional services, use pure IPv6 in your internal infrastructure and access the Internet through some form of gateway for the time being. --Michael Dillon From wavetossed at googlemail.com Sun May 1 22:52:56 2011 From: wavetossed at googlemail.com (Michael Dillon) Date: Sun, 1 May 2011 19:52:56 -0700 Subject: [arin-ppml] Microsoft receives court approval for transfer as agreed with ARIN In-Reply-To: <35688.1303866514@tristatelogic.com> References: <35688.1303866514@tristatelogic.com> Message-ID: > So, um help me out here. ?I just want to make sure I understand this. > > So with respect to all the space being transfered, Microsoft will demonstrate > need and ARIN will review need? > How exactly does one go about demonstrating an immediate need for 10 /16s? Do you realise how dumb this question is? Some of us think before we speak, and even do a bit of research. You don't have to be a rocket scientist to know that Microsoft is a very big company operating in virtually every country on the planet, that they dominate their market niche, and that their customer base tends to be multinational companies, very large companies and other big companies. They may not be a telecomms company on the face of it, but they do supply many of the same services as ISPs. For instance MSN is still an important supplier of dialup Internet access, which in turn, is an important class of service in the USA where broadband deployment is restricted to the largest cities and even there may not cover 100% of neighborhoods. In addition, Microsoft operates a number of very large data centers to support various services that they offer such as Windows Live, and now they are busy expanding those data centers to offer cloud computing services under the brand Windows Azure. Their customer base is very important in this analysis because when you have lots of very large customers, it doesn't take a whole lot of signed contracts before you have to deliver new network services on a scale that dwarfs all but the top 10 or 20 telecoms companies. I worked for a global telecomms company and regularly picked up /15 blocks from ARIN, so I am not at all surprised that the company pushing hosted Sharepoint, hosted Office 2010 and Windows Azure, was able to come up with a real technical justification for only 5 times what I used to get. They say that you should pick your battles, and I think you are all wasting your time nitpicking any IP address exchanges where the recipient clearly is in the ISP business. --Michael Dillon From owen at delong.com Wed May 4 15:19:04 2011 From: owen at delong.com (Owen DeLong) Date: Wed, 4 May 2011 12:19:04 -0700 Subject: [arin-ppml] ARIN-prop-146 Clarify Justified Need for Transfers In-Reply-To: References: <4DBEF120.4080901@arin.net> <88F39B20-5C20-45F0-AD61-5FA1E7F84CE3@delong.com> <3FCD1FDC-ECEE-4C9B-95C6-59E03D3C314E@matthew.at> <5598DFC7-E320-42FA-AA0E-C91C076BD725@delong.com> <6BA1EAA6-7D9C-44F9-BED7-884720F4B3BE@matthew.at> <05FAA29B-37BE-411C-95A4-50437602C8ED@delong.com> <4DBF6727.1090303@matthew.at> <097AAC1C-1F68-4820-9274-3290ADEFA195@delong.com> <4DBF75B7.3010407@matthew.at> <9501EA7E-FDAD-4DDA-B9E8-08C2811FF642@delong.com> <4DBF82F6.7050608@matthew.at> <20110503145144.N15967@mail.inlandnet.com> <4DC084E7.5000302@matthew.at> <4DC08664.4060905@matthew.at> <4791A59E-8864-483C-9BB0-03A6A5B8D50C@delong.com> Message-ID: <66466F57-4365-4ADB-94EB-E023F01B17CB@delong.com> On May 4, 2011, at 11:22 AM, Matthew Kaufman wrote: > > On May 4, 2011, at 9:51 AM, Owen DeLong wrote: > >> >> On May 3, 2011, at 3:49 PM, Matthew Kaufman wrote: >> >>> On 5/3/2011 3:42 PM, Matthew Kaufman wrote: >>>> >>>> Sure... back when there was a free pool, making them jump through the extra hoops every 3 months to show that they're doing the right thing makes (some) sense... but once there isn't, every time they get space might be their last. >>> >>> Oh, and since the "ARIN Community" is mostly made up of the "haves" and has almost no representation (if any) from the "have nots" I have no expectation that there will be widespread support for fixing transfer policies for the "have nots". >>> >> If this is true, it is only because the have-nots have, thus far, chosen not to subscribe to the list and >> participate. If you know them and feel they are being substantially disadvantaged in this debate, the >> rational solution is to encourage them to subscribe and chime in. > > I am claiming that the future "have nots" are totally unaware today that they need to participate in order to be able to do what they haven't yet started in the future. > > My 7 year old isn't lobbying for rollbacks on the new restrictions for teen drivers this week either, because he simply hasn't thought about driving himself around enough to realize that his ability to take his brother out with him when he turns 16 has been eliminated in this state. > > Matthew Kaufman So you are saying that some group of (potentially non-existent as yet) companies that will be run by people who are not yet adults could be disadvantaged in the IPv4 world by the policies we are adopting, and, so, we should sell address space to the highest bidders on longer-term time horizons in order to somehow prevent that from happening? I'm sorry, I just can't equate the outcome of the proposal to the protection of the parties you are describing. I also think it is unlikely your 7 year old will be in charge of a company in less than 9 years. As such, I'm inclined to believe that by the time he is, any potential for meaningful IPv4 based companies will be long passed by that time. Owen From owen at delong.com Wed May 4 15:16:01 2011 From: owen at delong.com (Owen DeLong) Date: Wed, 4 May 2011 12:16:01 -0700 Subject: [arin-ppml] Fw: Accusationof fundamentalconflictofinterest/IPaddress policypitched directly to ICANN In-Reply-To: <6B65D21B9B7543208304CC44EDD22444@mike> References: <379DB08FB5564ED88230C1B6D6AE80FE@mike> <8695009A81378E48879980039EEDAD289D0E5BC6@MAIL1.polartel.local> <6B65D21B9B7543208304CC44EDD22444@mike> Message-ID: <3DA6DC8B-ADC6-4BCB-83BA-5F07BC5682C7@delong.com> On May 4, 2011, at 11:16 AM, Mike Burns wrote: > Hi Owen, > > > I think private registries are a good idea. And I disagree, but, this is not a surprise to you. > I think Benson's proposals would have led to them, but were voted down by the ARIN community. Agreed. > One of the reasons given was the lack of oversight which would result from the implementation of Benson's proposals. Yes. > To my mind, such oversight can only come from a higher level. What higher level is there than the community which is being governed? > The proposed private registry after all, would be on the same level and performing the same function as the RIRs. > Yes... You once again conflate the RIR and the RIR community. > ICANN is the higher level, in my mind, based on their clear approval responsiblity for new RIRs, and their predating the RIRs. > ICANN has a policymaking apparatus which is being appealed to by the writer of the letter which started this thread. > Your mind is clearly confused on multiple levels... ICANN does not predate RIRs. Both RIPE and APNIC, as does ARIN. ICAN was formed in October of 1998. APNIC was formed in 1992. RIPE NCC was formed in 1992 ARIN was formed in 1993 Their approval responsibility for new RIRs is delegated to them by the RIRs and serves as a self-imposed check-and-balance on the RIR system. ICANN cannot approve a new RIR without the consent of the RIRs (as expressed through the NRO which is comprised of the RIRs and members elected by the RIR communities). Neither can ICANN withhold such approval except in a case where they feel that some aspect of the documented policy and procedures has not been met. ICANN has no apparatus for making number policy other than the ASO AC/NRO NC which is made up of members elected by the RIR communities. The ASO AC/NRO NC process for making policy is the global policy process which I have explained to you before and for which the first step is to pass substantially identical policy in all 5 RIR policy processes as a proposed global policy. > Here is a document I found which proposes that ICANN adopts a set of requirements for those who wish to provide private registry services: > http://www.icann.org/en/correspondence/statement-ip-address-registrar-accreditation-policy-31mar11-en.pdf Given that this is shown as "correspondence" and not attributed to a source but also does not contain any information about it having been adopted, to the best of my knowledge, this is just a suggestion from some random source which has not necessarily received any community support for implementation. > > I just skimmed it, but if the community decided that Benson's proposals suffered only from a lack of oversight, and required action at a global level, then perhaps they will add their voice to the support which I offered. > Perhaps, but, you would still need a global policy proposal to voice support for. > If the action happens at this level as a result of an informed decisionmaking process at ICANN, then I am happy because it will expedite the appearance of competing registries. > I'm not sure I can parse what you are saying here in the context of the current way decisions are made by either ICANN (with the limitations that exist on their decision making ability) or the RIR level. > And why do I want competing registries? Is it because ARIN charges too much, or their website is hard to navigate? > Is it because I wish to take my business elsewhere as a statement against ARIN staff? Is it their response time? > Is it because I am a buyer who requires more than officer attestation for determining the right to sell addresses? > Is it because I am a buyer who does not wish to sign an LRSA or RSA? > Is it because I choose a 5 year planning horizon? > Do I want to transfer out of region? > > No, none of those reasons, although are all, in my mind, potentially valid reasons for somebody to change registries. > It is because I think a competing registrar would naturally reduce barriers to transfers. > It is, perhaps, exactly this reduction of barriers that leads me to believe that competing registries would be a bad idea. I believe that the barriers that exist in the transfer process today were considered by the community and have the support of the vast majority of community members. I believe they were placed there for good reason and represent appropriate safeguards in the proper stewardship of number resources. > And that is my underlying goal. In fact, ARIN could probably pull the rug out from under a private registry by beating them to the punch and removing restrictions for all transfers. > Q.E.D... "If ARIN merely abandons its stewardship role, we wouldn't need other registries to do that instead." In my opinion, stewardship is a good thing that should not be abandoned. > (I think needs analysis should be done on free-pool allocations, though. I hope that goes without saying.) > I fail to see a reason that needs analysis should not be done on transfer recipients. Nothing you have said so far makes the case for that. If you could get the community to come to consensus that needs basis should be abandoned, a simple ARIN policy proposal could cause ARIN to do so. I believe that the community consensus is against such an abandonment of stewardship and so development of competing registries to override that community judgment strikes me as inappropriate at best. > As for the talk about the perils or benefits of free markets, I will leave that aside in the belief that the readers have internalized our different perspectives. > Likely true. Owen -------------- next part -------------- An HTML attachment was scrubbed... URL: From JOHN at egh.com Wed May 4 14:58:16 2011 From: JOHN at egh.com (John Santos) Date: Wed, 4 May 2011 14:58:16 -0400 Subject: [arin-ppml] ARIN-prop-146 Clarify Justified Need for Transfers Message-ID: <1110504145220.5819A-100000@Ives.egh.com> On 4 May 2011 matthew at matthew.at wrote: > On May 4, 2011, at 9:51 AM, Owen DeLong wrote: > > > > > On May 3, 2011, at 3:49 PM, Matthew Kaufman wrote: > > > >> On 5/3/2011 3:42 PM, Matthew Kaufman wrote: > >>> > >>> Sure... back when there was a free pool, making them jump through the extra hoops every 3 months to show that they're doing the right thing makes (some) sense... but once there isn't, every time they get space might be their last. > >> > >> Oh, and since the "ARIN Community" is mostly made up of the "haves" and has almost no representation (if any) from the "have nots" I have no expectation that there will be widespread support for fixing transfer policies for the "have nots". > >> > > If this is true, it is only because the have-nots have, thus far, chosen not to subscribe to the list and > > participate. If you know them and feel they are being substantially disadvantaged in this debate, the > > rational solution is to encourage them to subscribe and chime in. > > I am claiming that the future "have nots" are totally unaware today that they need to participate in order to be able to do what they haven't yet started in the future. > > My 7 year old isn't lobbying for rollbacks on the new restrictions for teen drivers this week either, because he simply hasn't thought about driving himself around enough to realize that his ability to take his brother out with him when he turns 16 has be > en eliminated in this state. > > Matthew Kaufman If your 7 year old is desperately seeking IPv4 space 10 years from now, then we got much bigger problems than the reputed benefits of a free market in IPv4 could either solve or cause. This whole thread is based on a free market ideology that collapses when feed-back mechinisms fail due to a hard limit on supply. Ask any engineer what happens to a negative feedback mechanism (which is all the "invisible hand" actually is), when it is driven against hard limits. (Hint: it fails catastrophically.) -- John Santos Evans Griffiths & Hart, Inc. 781-861-0670 ext 539 From matthew at matthew.at Wed May 4 15:42:23 2011 From: matthew at matthew.at (Matthew Kaufman) Date: Wed, 4 May 2011 12:42:23 -0700 Subject: [arin-ppml] ARIN-prop-146 Clarify Justified Need for Transfers In-Reply-To: <66466F57-4365-4ADB-94EB-E023F01B17CB@delong.com> References: <4DBEF120.4080901@arin.net> <88F39B20-5C20-45F0-AD61-5FA1E7F84CE3@delong.com> <3FCD1FDC-ECEE-4C9B-95C6-59E03D3C314E@matthew.at> <5598DFC7-E320-42FA-AA0E-C91C076BD725@delong.com> <6BA1EAA6-7D9C-44F9-BED7-884720F4B3BE@matthew.at> <05FAA29B-37BE-411C-95A4-50437602C8ED@delong.com> <4DBF6727.1090303@matthew.at> <097AAC1C-1F68-4820-9274-3290ADEFA195@delong.com> <4DBF75B7.3010407@matthew.at> <9501EA7E-FDAD-4DDA-B9E8-08C2811FF642@delong.com> <4DBF82F6.7050608@matthew.at> <20110503145144.N15967@mail.inlandnet.com> <4DC084E7.5000302@matthew.at> <4DC08664.4060905@matthew.at> <4791A59E-8864-483C-9BB0-03A6A5B8D50C@delong.com> <66466F57-4365-4ADB-94EB-E023F01B17CB@delong.com> Message-ID: <30D12BA8-9A6C-4E62-9A67-8B4FEA0EA8C1@matthew.at> On May 4, 2011, at 12:19 PM, Owen DeLong wrote: > > On May 4, 2011, at 11:22 AM, Matthew Kaufman wrote: > >> >> On May 4, 2011, at 9:51 AM, Owen DeLong wrote: >> >>> >>> On May 3, 2011, at 3:49 PM, Matthew Kaufman wrote: >>> >>>> On 5/3/2011 3:42 PM, Matthew Kaufman wrote: >>>>> >>>>> Sure... back when there was a free pool, making them jump through the extra hoops every 3 months to show that they're doing the right thing makes (some) sense... but once there isn't, every time they get space might be their last. >>>> >>>> Oh, and since the "ARIN Community" is mostly made up of the "haves" and has almost no representation (if any) from the "have nots" I have no expectation that there will be widespread support for fixing transfer policies for the "have nots". >>>> >>> If this is true, it is only because the have-nots have, thus far, chosen not to subscribe to the list and >>> participate. If you know them and feel they are being substantially disadvantaged in this debate, the >>> rational solution is to encourage them to subscribe and chime in. >> >> I am claiming that the future "have nots" are totally unaware today that they need to participate in order to be able to do what they haven't yet started in the future. >> >> My 7 year old isn't lobbying for rollbacks on the new restrictions for teen drivers this week either, because he simply hasn't thought about driving himself around enough to realize that his ability to take his brother out with him when he turns 16 has been eliminated in this state. >> >> Matthew Kaufman > > So you are saying that some group of (potentially non-existent as yet) companies that will > be run by people who are not yet adults could be disadvantaged in the IPv4 world by the > policies we are adopting I was making an analogy to a similar situation with different time scales. The companies probably already exist, and are run by adults, but haven't yet started growing such that they need additional IPv4 space during the transition. Or are about to be started, by adults, and will need IPv4 space during the transition. > , and, so, we should sell address space to the highest bidders > on longer-term time horizons in order to somehow prevent that from happening? > We should make the difficulty of acquiring space as equal as possible for both these new or recent entrants as it is for the more established (who already have the advantage that they can compress down their own usage of space they already hold). Before runout the "only 3 months" serves to make the organization come back repeatedly to ARIN as a documentation process, but the addresses are just as available every 3 months as they are every 12. After runout, the "only 3 months" serves to put one class of orgs at a significant disadvantage when it comes to acquiring the space they will legitimately need for their own growth. > I'm sorry, I just can't equate the outcome of the proposal to the protection of the > parties you are describing. > > I also think it is unlikely your 7 year old will be in charge of a company in less than > 9 years. As such, I'm inclined to believe that by the time he is, any potential for > meaningful IPv4 based companies will be long passed by that time. Again, I was making an analogy. (And you don't know my 7 year old.) But there's definitely companies that have been launched just this year that, if successful, will need more IPv4 space than they have now in order to get through the transition... likewise, there are numerous companies that are going to find that selling off their space is a better business plan than continuing to slowly fail because their idea wasn't as popular. Friendster's space goes to the next Facebook, as it were. Matthew Kaufman From dogwallah at gmail.com Wed May 4 16:12:12 2011 From: dogwallah at gmail.com (McTim) Date: Wed, 4 May 2011 23:12:12 +0300 Subject: [arin-ppml] ARIN-prop-146 Clarify Justified Need for Transfers In-Reply-To: <30D12BA8-9A6C-4E62-9A67-8B4FEA0EA8C1@matthew.at> References: <4DBEF120.4080901@arin.net> <88F39B20-5C20-45F0-AD61-5FA1E7F84CE3@delong.com> <3FCD1FDC-ECEE-4C9B-95C6-59E03D3C314E@matthew.at> <5598DFC7-E320-42FA-AA0E-C91C076BD725@delong.com> <6BA1EAA6-7D9C-44F9-BED7-884720F4B3BE@matthew.at> <05FAA29B-37BE-411C-95A4-50437602C8ED@delong.com> <4DBF6727.1090303@matthew.at> <097AAC1C-1F68-4820-9274-3290ADEFA195@delong.com> <4DBF75B7.3010407@matthew.at> <9501EA7E-FDAD-4DDA-B9E8-08C2811FF642@delong.com> <4DBF82F6.7050608@matthew.at> <20110503145144.N15967@mail.inlandnet.com> <4DC084E7.5000302@matthew.at> <4DC08664.4060905@matthew.at> <4791A59E-8864-483C-9BB0-03A6A5B8D50C@delong.com> <66466F57-4365-4ADB-94EB-E023F01B17CB@delong.com> <30D12BA8-9A6C-4E62-9A67-8B4FEA0EA8C1@matthew.at> Message-ID: On Wed, May 4, 2011 at 10:42 PM, Matthew Kaufman wrote: > Again, I was making an analogy. (And you don't know my 7 year old.) But there's definitely companies that have been launched just this year that, if successful, will need more IPv4 space than they have now in order to get through the transition... likewise, there are numerous companies that are going to find that selling off their space is a better business plan than continuing to slowly fail because their idea wasn't as popular. Friendster's space goes to the next Facebook, as it were. Exactly. However allowing Friendster to flog their space to the next FB without ascertaining if this new entity really has the need for it isn't exactly fair to the dozens of other "next FBs" being conceived of now. . The notion that resource allocation should be based solely on wealth is not a value I am trying to instill in MY 7 yr old! -- Cheers, McTim "A name indicates what we seek. An address indicates where it is. A route indicates how we get there."? Jon Postel From matthew at matthew.at Wed May 4 16:17:08 2011 From: matthew at matthew.at (Matthew Kaufman) Date: Wed, 4 May 2011 13:17:08 -0700 Subject: [arin-ppml] ARIN-prop-146 Clarify Justified Need for Transfers In-Reply-To: References: <4DBEF120.4080901@arin.net> <88F39B20-5C20-45F0-AD61-5FA1E7F84CE3@delong.com> <3FCD1FDC-ECEE-4C9B-95C6-59E03D3C314E@matthew.at> <5598DFC7-E320-42FA-AA0E-C91C076BD725@delong.com> <6BA1EAA6-7D9C-44F9-BED7-884720F4B3BE@matthew.at> <05FAA29B-37BE-411C-95A4-50437602C8ED@delong.com> <4DBF6727.1090303@matthew.at> <097AAC1C-1F68-4820-9274-3290ADEFA195@delong.com> <4DBF75B7.3010407@matthew.at> <9501EA7E-FDAD-4DDA-B9E8-08C2811FF642@delong.com> <4DBF82F6.7050608@matthew.at> <20110503145144.N15967@mail.inlandnet.com> <4DC084E7.5000302@matthew.at> <4DC08664.4060905@matthew.at> <4791A59E-8864-483C-9BB0-03A6A5B8D50C@delong.com> <66466F57-4365-4ADB-94EB-E023F01B17CB@delong.com> <30D12BA8-9A6C-4E62-9A67-8B4FEA0EA8C1@matthew.at> Message-ID: <2CB26FFC-CB87-4E59-AD4C-F1CB6CA127D6@matthew.at> On May 4, 2011, at 1:12 PM, McTim wrote: > On Wed, May 4, 2011 at 10:42 PM, Matthew Kaufman wrote: > > > >> Again, I was making an analogy. (And you don't know my 7 year old.) But there's definitely companies that have been launched just this year that, if successful, will need more IPv4 space than they have now in order to get through the transition... likewise, there are numerous companies that are going to find that selling off their space is a better business plan than continuing to slowly fail because their idea wasn't as popular. Friendster's space goes to the next Facebook, as it were. > > > Exactly. > > However allowing Friendster to flog their space to the next FB without > ascertaining if this new entity really has the need for it isn't > exactly fair to the dozens of other "next FBs" being conceived of now. > . Agreed. That's why I'm not arguing for eliminating the needs basis. I'm simply arguing for the needs basis to be a 12-month forecast for all, rather than a 12-month for some and 3-month for others, when it comes to transfers. > > The notion that resource allocation should be based solely on wealth > is not a value I am trying to instill in MY 7 yr old! It wouldn't be based solely on wealth under this proposal. Matthew Kaufman From mike at nationwideinc.com Wed May 4 16:21:57 2011 From: mike at nationwideinc.com (Mike Burns) Date: Wed, 4 May 2011 16:21:57 -0400 Subject: [arin-ppml] Fw: Accusationof fundamentalconflictofinterest/IPaddress policypitched directly to ICANN References: <379DB08FB5564ED88230C1B6D6AE80FE@mike> <8695009A81378E48879980039EEDAD289D0E5BC6@MAIL1.polartel.local> <6B65D21B9B7543208304CC44EDD22444@mike> <3DA6DC8B-ADC6-4BCB-83BA-5F07BC5682C7@delong.com> Message-ID: <9D762F7D6FE3419790C6E47F58A1D4D5@mike> Hi Owen, What higher level is there than the community which is being governed? This can get so tedious and semantic. Is the governor higher than the governed? I say yes, you say no. Since he derives his power from the consent of the governed, and answers to them via elections, you could say he is lower than the governed. But if you want something adjudicated between yourself and your neighbor, then the governor is the higher authority. You can go around and around. If you think the DoC is the source of authority, you view things in one direction. If you think the community is the source of authority, you view things in the other direction. What is clear is that there is a level that is called to approve (rubberstamp) the decisions related to new registries. This level is being asked to make the decision about allowing a new private registry. If that level is answerable to the community in one way or another, let the community use it's authority over that level. If the ICANN board does decide the issue and you don't like that, I guess you could try to change ICANN policy through community participation. The proposed private registry after all, would be on the same level and performing the same function as the RIRs. Yes... You once again conflate the RIR and the RIR community. I don't see the problem with my statement. The new private registry would be performing the same functions as the RIRs, would you accede that? ICANN is the higher level, in my mind, based on their clear approval responsiblity for new RIRs, and their predating the RIRs. ICANN has a policymaking apparatus which is being appealed to by the writer of the letter which started this thread. Your mind is clearly confused on multiple levels... ICANN does not predate RIRs. Both RIPE and APNIC, as does ARIN. ICAN was formed in October of 1998. APNIC was formed in 1992. RIPE NCC was formed in 1992 ARIN was formed in 1993 Their approval responsibility for new RIRs is delegated to them by the RIRs and serves as a self-imposed check-and-balance on the RIR system. ICANN cannot approve a new RIR without the consent of the RIRs (as expressed through the NRO which is comprised of the RIRs and members elected by the RIR communities). Neither can ICANN withhold such approval except in a case where they feel that some aspect of the documented policy and procedures has not been met. ICANN has no apparatus for making number policy other than the ASO AC/NRO NC which is made up of members elected by the RIR communities. The ASO AC/NRO NC process for making policy is the global policy process which I have explained to you before and for which the first step is to pass substantially identical policy in all 5 RIR policy processes as a proposed global policy. If the letter asking the ICANN board to decide was written to an entity without decisionmaking capability, then you don't have to worry about them making a decision, I guess. Sorry, meant to say IANA preceded the RIRs. Here is a document I found which proposes that ICANN adopts a set of requirements for those who wish to provide private registry services: http://www.icann.org/en/correspondence/statement-ip-address-registrar-accreditation-policy-31mar11-en.pdf Given that this is shown as "correspondence" and not attributed to a source but also does not contain any information about it having been adopted, to the best of my knowledge, this is just a suggestion from some random source which has not necessarily received any community support for implementation. I never said it was adopted, I figured the source would be in the document, which I found on the icann.org site. But it spells out the kinds of requirements a new registry would be required to meet. I just skimmed it, but if the community decided that Benson's proposals suffered only from a lack of oversight, and required action at a global level, then perhaps they will add their voice to the support which I offered. Perhaps, but, you would still need a global policy proposal to voice support for. Unless ICANN board actually does make the decision they are being asked to make. The link above is policy proposal on the ICANN correspondence page, and it is referenced in this letter: http://www.icann.org/en/correspondence/holtzman-to-olive-02mar11-en.pdf providing reasons for requesting the decision at the ICANN board level. Based on the appeal to the authority of the DoC contract, I expect there could be a further appeal to the DoC or NTIA level if the ICANN board decides not to make a decision. It is interesting that ICANN requested information from ARIN instead of summarily dismissing the request as coming outside of policy. ARIN's reply to ICANN is on the same site. If the action happens at this level as a result of an informed decisionmaking process at ICANN, then I am happy because it will expedite the appearance of competing registries. I'm not sure I can parse what you are saying here in the context of the current way decisions are made by either ICANN (with the limitations that exist on their decision making ability) or the RIR level. If the ICANN board decides the issue than I am happy because I think competing registries will be allowed, and because I think ICANN is a higher level than ARIN and can mandate that ARIN share bulk whois data with competing registries. And why do I want competing registries? Is it because ARIN charges too much, or their website is hard to navigate? Is it because I wish to take my business elsewhere as a statement against ARIN staff? Is it their response time? Is it because I am a buyer who requires more than officer attestation for determining the right to sell addresses? Is it because I am a buyer who does not wish to sign an LRSA or RSA? Is it because I choose a 5 year planning horizon? Do I want to transfer out of region? No, none of those reasons, although are all, in my mind, potentially valid reasons for somebody to change registries. It is because I think a competing registrar would naturally reduce barriers to transfers. It is, perhaps, exactly this reduction of barriers that leads me to believe that competing registries would be a bad idea. I believe that the barriers that exist in the transfer process today were considered by the community and have the support of the vast majority of community members. I believe they were placed there for good reason and represent appropriate safeguards in the proper stewardship of number resources. Proper stewardship is to make policy that will increase the supply of addresses and bring down their price, while increasing whois reliability and removing the biggest distinction between legacy and non-legacy addresses. And that is my underlying goal. In fact, ARIN could probably pull the rug out from under a private registry by beating them to the punch and removing restrictions for all transfers. Q.E.D... "If ARIN merely abandons its stewardship role, we wouldn't need other registries to do that instead." In my opinion, stewardship is a good thing that should not be abandoned. Are you accusing the APNIC community of abandoning stewardship, and if they did, why do you think they did that? Is the region largely peopled by IPv4 profiteers? (I think needs analysis should be done on free-pool allocations, though. I hope that goes without saying.) I fail to see a reason that needs analysis should not be done on transfer recipients. Nothing you have said so far makes the case for that. If you could get the community to come to consensus that needs basis should be abandoned, a simple ARIN policy proposal could cause ARIN to do so. I believe that the community consensus is against such an abandonment of stewardship and so development of competing registries to override that community judgment strikes me as inappropriate at best. I think I have made my case to the community that maintaining a needs requirement in a post-exhaust world is not a requirement of stewardship. I suppose the discussion part has ended its productive phase and that it is time for a proposal so the community's voice can be heard one way or the other. I will try to get a proposal knocked together. I looked at the template last night. Owen, is it better to provide three examples of proposals with slightly different language, or one more general one that can be modified through discussion? As in, should I make separate proposals to remove needs justification from legacy transfers only, and one for non-legacy, and one for both? Regards, Mike As for the talk about the perils or benefits of free markets, I will leave that aside in the belief that the readers have internalized our different perspectives. Likely true. Owen -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcurran at arin.net Wed May 4 16:23:59 2011 From: jcurran at arin.net (John Curran) Date: Wed, 4 May 2011 20:23:59 +0000 Subject: [arin-ppml] ARIN-prop-146 Clarify Justified Need for Transfers In-Reply-To: <66466F57-4365-4ADB-94EB-E023F01B17CB@delong.com> References: <4DBEF120.4080901@arin.net> <88F39B20-5C20-45F0-AD61-5FA1E7F84CE3@delong.com> <3FCD1FDC-ECEE-4C9B-95C6-59E03D3C314E@matthew.at> <5598DFC7-E320-42FA-AA0E-C91C076BD725@delong.com> <6BA1EAA6-7D9C-44F9-BED7-884720F4B3BE@matthew.at> <05FAA29B-37BE-411C-95A4-50437602C8ED@delong.com> <4DBF6727.1090303@matthew.at> <097AAC1C-1F68-4820-9274-3290ADEFA195@delong.com> <4DBF75B7.3010407@matthew.at> <9501EA7E-FDAD-4DDA-B9E8-08C2811FF642@delong.com> <4DBF82F6.7050608@matthew.at> <20110503145144.N15967@mail.inlandnet.com> <4DC084E7.5000302@matthew.at> <4DC08664.4060905@matthew.at> <4791A59E-8864-483C-9BB0-03A6A5B8D50C@delong.com> <66466F57-4365-4ADB-94EB-E023F01B17CB@delong.com> Message-ID: <254C740A-AB37-4D57-A71B-B939E7041CFD@arin.net> On May 4, 2011, at 3:19 PM, Owen DeLong wrote: > So you are saying that some group of (potentially non-existent as yet) companies that will > be run by people who are not yet adults could be disadvantaged in the IPv4 world by the > policies we are adopting Despite ARIN's significant efforts in outreach, it is remains quite likely that tens of thousands of present address holders (both legacy and ARIN-issued) do not realize today they now have the option of transferring their address resources in accordance with established policy, and similarly numerous businesses will be formed in the coming years that may not think about "IPv4 Addresses" in their initial planning activities. Transfer requests submitted by these organizations in the future will be subject to the policies being developed by this community in this discussion today, and I believe that Matthew's point is we should recognize that these policies will have an effect on tens of thousands of organizations that do not know that that this discussion is occurring today with potential impact their plans. To the extent that we can minimize impact for those not in the discussion (and manage to still keep the Internet running in the process), it's indeed a major win. I am not speaking in favor or opposition to any policy changes, but highlighting the importance of the fully considering changes to the transfer policy as it may be heavily utilized in the coming years. Thanks! /John John Curran President and CEO ARIN From owen at delong.com Wed May 4 17:13:27 2011 From: owen at delong.com (Owen DeLong) Date: Wed, 4 May 2011 14:13:27 -0700 Subject: [arin-ppml] ARIN-prop-146 Clarify Justified Need for Transfers In-Reply-To: <254C740A-AB37-4D57-A71B-B939E7041CFD@arin.net> References: <4DBEF120.4080901@arin.net> <88F39B20-5C20-45F0-AD61-5FA1E7F84CE3@delong.com> <3FCD1FDC-ECEE-4C9B-95C6-59E03D3C314E@matthew.at> <5598DFC7-E320-42FA-AA0E-C91C076BD725@delong.com> <6BA1EAA6-7D9C-44F9-BED7-884720F4B3BE@matthew.at> <05FAA29B-37BE-411C-95A4-50437602C8ED@delong.com> <4DBF6727.1090303@matthew.at> <097AAC1C-1F68-4820-9274-3290ADEFA195@delong.com> <4DBF75B7.3010407@matthew.at> <9501EA7E-FDAD-4DDA-B9E8-08C2811FF642@delong.com> <4DBF82F6.7050608@matthew.at> <20110503145144.N15967@mail.inlandnet.com> <4DC084E7.5000302@matthew.at> <4DC08664.4060905@matthew.at> <4791A59E-8864-483C-9BB0-03A6A5B8D50C@delong.com> <66466F57-4365-4ADB-94EB-E023F01B17CB@delong.com> <254C740A-AB37-4D57-A71B-B939E7041CFD@arin.net> Message-ID: <2174F66C-20BA-4683-B6F3-901A50FCB6D0@delong.com> On May 4, 2011, at 1:23 PM, John Curran wrote: > On May 4, 2011, at 3:19 PM, Owen DeLong wrote: >> So you are saying that some group of (potentially non-existent as yet) companies that will >> be run by people who are not yet adults could be disadvantaged in the IPv4 world by the >> policies we are adopting > > Despite ARIN's significant efforts in outreach, it is remains quite > likely that tens of thousands of present address holders (both legacy > and ARIN-issued) do not realize today they now have the option of > transferring their address resources in accordance with established > policy, and similarly numerous businesses will be formed in the coming > years that may not think about "IPv4 Addresses" in their initial > planning activities. > > Transfer requests submitted by these organizations in the future will > be subject to the policies being developed by this community in this > discussion today, and I believe that Matthew's point is we should > recognize that these policies will have an effect on tens of thousands > of organizations that do not know that that this discussion is occurring > today with potential impact their plans. To the extent that we can > minimize impact for those not in the discussion (and manage to still > keep the Internet running in the process), it's indeed a major win. > > I am not speaking in favor or opposition to any policy changes, but > highlighting the importance of the fully considering changes to the > transfer policy as it may be heavily utilized in the coming years. > I'm all for considering that, so long as we don't do so to the exclusion of the justified needs of those companies that have immediate and documented need today. My point is that taking into account some arbitrary speculative number of organization's theoretical future needs is difficult at best and should not override what we know about real organizations with real and present need today. Owen From owen at delong.com Wed May 4 17:59:12 2011 From: owen at delong.com (Owen DeLong) Date: Wed, 4 May 2011 14:59:12 -0700 Subject: [arin-ppml] Fw: Accusationof fundamentalconflictofinterest/IPaddress policypitched directly to ICANN In-Reply-To: <9D762F7D6FE3419790C6E47F58A1D4D5@mike> References: <379DB08FB5564ED88230C1B6D6AE80FE@mike> <8695009A81378E48879980039EEDAD289D0E5BC6@MAIL1.polartel.local> <6B65D21B9B7543208304CC44EDD22444@mike> <3DA6DC8B-ADC6-4BCB-83BA-5F07BC5682C7@delong.com> <9D762F7D6FE3419790C6E47F58A1D4D5@mike> Message-ID: On May 4, 2011, at 1:21 PM, Mike Burns wrote: > Hi Owen, > > > What higher level is there than the community which is being governed? > > This can get so tedious and semantic. Is the governor higher than the governed? I say yes, you say no. Uh, nice of you to presume to answer for me. My real answer (if you care what I actually think) is that it depends on the structure of the government in question. In the united States of America, the federal government is subservient to the corporations which can afford to purchase it and to the people who get to vote for the candidates chosen by the corporations. In a democracy, the government is subservient to the people. In a republic, the government is subservient to the elected representatives of the people. In a dictatorship, the government is subservient to the dictator who is generally subservient to no-one unless they possess the means and the will to overthrow the dictatorship in question. In the case of California, the governor is subservient to the combined will of the senate and legislature as well as the state and federal judiciary, federal laws, and the will of the people of the California Republic as expressed in the state constitution, various codes of the State of California, and of course the potential for a recall petition (such as happened to Governor Davis), the standard four-year election cycle, and finally, term limits. > Since he derives his power from the consent of the governed, and answers to them via elections, you could say he is lower than the governed. Correct. The governor himself is actually quite powerless. He has no ability to introduce new laws, no ability to change existing laws, and no ability to make new policy other than that granted to him by the senate, legislature, and the people. I cannot see any way in which he can be considered a higher authority than the governed. > But if you want something adjudicated between yourself and your neighbor, then the governor is the higher authority. No, actually, my neighbor and I have much more ability to affect an adjudication between us than the governor. Now, if you mentioned the judiciary, you might have a point, but, you did not. You chose the governor. > You can go around and around. If you think the DoC is the source of authority, you view things in one direction. The DoC is a participant largely as the result of historical accident more than anything else and I do not consider them to be an authority of any real basis in this equation. I think they have chosen (wisely) to ensure that reasonable structures of self governance were put in place and then butt out to the greatest extent possible. I think this is good and I hope they will continue to abide by that decision. I do not think that interference in the community consensus process from DoC other than as individuals having an equal participation to that of any other individuals would benefit the process or improve the situation in any way. > If you think the community is the source of authority, you view things in the other direction. Correct. > What is clear is that there is a level that is called to approve (rubberstamp) the decisions related to new registries. > This level is being asked to make the decision about allowing a new private registry. A request upon which they have no authority to act and which is more properly brought to them as a global proposal AFTER it has been ratified by the PDP of each of the existing RIRs. > If that level is answerable to the community in one way or another, let the community use it's authority over that level. > If the ICANN board does decide the issue and you don't like that, I guess you could try to change ICANN policy through community participation. > The mechanism for the community to do so is the fact that the community has the right to review any such changes through their respective RIR policy development processes before such is put in front of the ICANN board for consideration. You are attempting to short-circuit that process and bypass that mechanism and then saying that you still want to let the community use its authority. I actually doubt that the ICANN board will act on such a request if it did not come through the process that is defined for making such a request (global policy development), but, if they do, indeed, we have a serious problem because the ICANN board will have overstepped its authority with unpredictable and likely disastrously disruptive effects of fragmentation of the very fabric that holds the internet together. I don't need to change ICANN policy as it currently stands. However, I will continue to oppose your attempts to circumvent it by bypassing the RIR communities and their respective policy development processes in an effort to get what you want no matter how the communities feel about it. > >> The proposed private registry after all, would be on the same level and performing the same function as the RIRs. >> > Yes... You once again conflate the RIR and the RIR community. > > I don't see the problem with my statement. The new private registry would be performing the same functions as the RIRs, would you accede that? > To the extent that you consider same function to mean strictly their address registration functions, yes. To the extent that such competing registries appear to be established for the purpose of eliminating community developed policies (or at least creating an ability to bypass them entirely), then, obviously, they would not only fail to perform the same function, but, would work to prevent the RIRs from effectively performing that function. As to the other functions performed by RIRs such as outreach, education, maintaining forums for the community to come together, etc., it is undefined whether competing registries as you have proposed them would do so or not. I am inclined to think that they are unlikely to do so in most cases. However, my response was to more than the single sentence of your previous message that you quoted above it. I was responding to the fact that you conflate the RIR as a body with the community when claiming that the RIR (which has no significant influence over the content of the policy process) has a meaningful conflict of interest in evaluating a policy proposal (which other than for clarity and understanding, they do not do) vs. the role of the community (which does actually discuss, propose, develop, and support policy) and its elected representatives (the AC and the BoT in ARIN's case) which do actually evaluate policies and the community consensus for said policies in their role in the policy development process. > >> ICANN is the higher level, in my mind, based on their clear approval responsiblity for new RIRs, and their predating the RIRs. >> ICANN has a policymaking apparatus which is being appealed to by the writer of the letter which started this thread. >> > Your mind is clearly confused on multiple levels... > > ICANN does not predate RIRs. Both RIPE and APNIC, as does ARIN. > > ICAN was formed in October of 1998. > > APNIC was formed in 1992. > RIPE NCC was formed in 1992 > ARIN was formed in 1993 > > Their approval responsibility for new RIRs is delegated to them by the RIRs and serves as a > self-imposed check-and-balance on the RIR system. ICANN cannot approve a new RIR without > the consent of the RIRs (as expressed through the NRO which is comprised of the RIRs and > members elected by the RIR communities). Neither can ICANN withhold such approval > except in a case where they feel that some aspect of the documented policy and procedures > has not been met. > > ICANN has no apparatus for making number policy other than the ASO AC/NRO NC which > is made up of members elected by the RIR communities. The ASO AC/NRO NC process for > making policy is the global policy process which I have explained to you before and for which > the first step is to pass substantially identical policy in all 5 RIR policy processes as a proposed > global policy. > > If the letter asking the ICANN board to decide was written to an entity without decisionmaking capability, then you don't have to worry about them making a decision, I guess. > Sorry, meant to say IANA preceded the RIRs. > The IANA as it existed before the RIRs actively worked to establish the RIR system and I would be surprised if you can find a single person who believes that the person serving in that role up to the point where the RIRs were established would support the idea of competing address registries for the purpose of bypassing community developed policies. > > >> Here is a document I found which proposes that ICANN adopts a set of requirements for those who wish to provide private registry services: >> http://www.icann.org/en/correspondence/statement-ip-address-registrar-accreditation-policy-31mar11-en.pdf > > Given that this is shown as "correspondence" and not attributed to a source but also does not > contain any information about it having been adopted, to the best of my knowledge, this is > just a suggestion from some random source which has not necessarily received any > community support for implementation. > > I never said it was adopted, I figured the source would be in the document, which I found on the icann.org site. But it spells out the kinds of requirements a new registry would be required to meet. > No, it proffers one possible set of requirements which could be used to do so. That is (and was) my point. Other than the author, there is no reliable evidence that anyone has reviewed or accepted this as the way such a thing should be done, let alone the way they would be done if such a structure were to be created. >> >> I just skimmed it, but if the community decided that Benson's proposals suffered only from a lack of oversight, and required action at a global level, then perhaps they will add their voice to the support which I offered. >> > Perhaps, but, you would still need a global policy proposal to voice support for. > > Unless ICANN board actually does make the decision they are being asked to make. The link above is policy proposal on the ICANN correspondence page, and it is referenced in this letter: > http://www.icann.org/en/correspondence/holtzman-to-olive-02mar11-en.pdf providing reasons for requesting the decision at the ICANN board level. Based on the appeal to the authority of the DoC contract, I expect there could be a further appeal to the DoC or NTIA level if the ICANN board decides not to make a decision. It is interesting that ICANN requested information from ARIN instead of summarily dismissing the request as coming outside of policy. ARIN's reply to ICANN is on the same site. > I cannot see any correspondence that shows ICANN board requesting information from ARIN that was done after ICANN received this letter. Can you point to a link to such? I also don't see any replies from ARIN that were submitted to ICANN after this letter. Can you provide a link to such? Indeed, I don't see any indication after the letter that ICANN has done anything with it other than post it on the correspondence page. I do see a letter from Depository on 15 March regarding ARIN's bulk whois denial, but, that relates to a thread of letters that well predates the letter you mention above and which is only somewhat loosely related. > > If the action happens at this level as a result of an informed decisionmaking process at ICANN, then I am happy because it will expedite the appearance of competing registries. > > I'm not sure I can parse what you are saying here in the context of the current way > decisions are made by either ICANN (with the limitations that exist on their > decision making ability) or the RIR level. > > If the ICANN board decides the issue than I am happy because I think competing registries will be allowed, and because I think ICANN is a higher level than ARIN and can mandate that ARIN share bulk whois data with competing registries. > I suspect that the ICANN board is most likely to deny the request and push it back as something which should go through the global policy development process. I still don't see how you can consider ICANN a higher level than ARIN or state that they have any ability to mandate that ARIN share bulk whois data with competing registries. Can you please provide some basis for this perceived authority? Where is such authority documented? >> And why do I want competing registries? Is it because ARIN charges too much, or their website is hard to navigate? >> Is it because I wish to take my business elsewhere as a statement against ARIN staff? Is it their response time? >> Is it because I am a buyer who requires more than officer attestation for determining the right to sell addresses? >> Is it because I am a buyer who does not wish to sign an LRSA or RSA? >> Is it because I choose a 5 year planning horizon? >> Do I want to transfer out of region? >> >> No, none of those reasons, although are all, in my mind, potentially valid reasons for somebody to change registries. >> It is because I think a competing registrar would naturally reduce barriers to transfers. >> > It is, perhaps, exactly this reduction of barriers that leads me to believe that competing registries > would be a bad idea. I believe that the barriers that exist in the transfer process today were > considered by the community and have the support of the vast majority of community members. > I believe they were placed there for good reason and represent appropriate safeguards in the > proper stewardship of number resources. > > Proper stewardship is to make policy that will increase the supply of addresses and bring down their price, while increasing whois reliability and removing the biggest distinction between legacy and non-legacy addresses. > In general, I would agree with you about the goals of proper stewardship. Obviously, I do not think that is the effect competing registries would have. >> And that is my underlying goal. In fact, ARIN could probably pull the rug out from under a private registry by beating them to the punch and removing restrictions for all transfers. >> > Q.E.D... "If ARIN merely abandons its stewardship role, we wouldn't need other registries to > do that instead." In my opinion, stewardship is a good thing that should not be abandoned. > > Are you accusing the APNIC community of abandoning stewardship, and if they did, why do you think they did that? Is the region largely peopled by IPv4 profiteers? > Yes. I believe that the transfer policy in the APNIC region was an abandonment of their stewardship role and I have said as much on their policy development mailing list. Why? Because Geoff Huston and a few other leaders in that community pushed long and hard to get that position adopted mainly by creating fear that failing to do so would render all RIR policy meaningless because the RIR policy would simply be bypassed in favor of people doing what they wanted anyway. Personally, I think that argument is absurd. Making theft legal just because you can't stop people from stealing makes no sense to me. > >> (I think needs analysis should be done on free-pool allocations, though. I hope that goes without saying.) >> > I fail to see a reason that needs analysis should not be done on transfer recipients. Nothing > you have said so far makes the case for that. If you could get the community to come to > consensus that needs basis should be abandoned, a simple ARIN policy proposal could > cause ARIN to do so. I believe that the community consensus is against such an abandonment > of stewardship and so development of competing registries to override that community > judgment strikes me as inappropriate at best. > > I think I have made my case to the community that maintaining a needs requirement in a post-exhaust world is not a requirement of stewardship. I think you have presented your case. I remain unconvinced. I have not seen a great deal of support for the idea come from the community, either. Some, but, not a lot. > I suppose the discussion part has ended its productive phase and that it is time for a proposal so the community's voice can be heard one way or the other. Makes sense. > I will try to get a proposal knocked together. I looked at the template last night. Let me know if you need any help. While I don't agree with your goals and think they would be bad policy, I am happy to help bring such proposal before the community for their consideration. > Owen, is it better to provide three examples of proposals with slightly different language, or one more general one that can be modified through discussion? > As in, should I make separate proposals to remove needs justification from legacy transfers only, and one for non-legacy, and one for both? > I think a more general one that can be modified through discussion. Usually when I write a proposal, I try to identify a specific problem and work with a few other knowledgeable folks to flesh it out into a relatively complete set of language before submitting it. I think for removing needs basis from all transfers, you should make one proposal to modify section 8 as needed. Owen -------------- next part -------------- An HTML attachment was scrubbed... URL: From dogwallah at gmail.com Thu May 5 02:59:26 2011 From: dogwallah at gmail.com (McTim) Date: Thu, 5 May 2011 09:59:26 +0300 Subject: [arin-ppml] ARIN-prop-146 Clarify Justified Need for Transfers In-Reply-To: <00af01cc0aa7$845a5330$8d0ef990$@net> References: <4DBEF120.4080901@arin.net> <88F39B20-5C20-45F0-AD61-5FA1E7F84CE3@delong.com> <3FCD1FDC-ECEE-4C9B-95C6-59E03D3C314E@matthew.at> <5598DFC7-E320-42FA-AA0E-C91C076BD725@delong.com> <6BA1EAA6-7D9C-44F9-BED7-884720F4B3BE@matthew.at> <05FAA29B-37BE-411C-95A4-50437602C8ED@delong.com> <4DBF6727.1090303@matthew.at> <097AAC1C-1F68-4820-9274-3290ADEFA195@delong.com> <4DBF75B7.3010407@matthew.at> <9501EA7E-FDAD-4DDA-B9E8-08C2811FF642@delong.com> <4DBF82F6.7050608@matthew.at> <20110503145144.N15967@mail.inlandnet.com> <4DC084E7.5000302@matthew.at> <4DC08664.4060905@matthew.at> <4791A59E-8864-483C-9BB0-03A6A5B8D50C@delong.com> <66466F57-4365-4ADB-94EB-E023F01B17CB@delong.com> <30D12BA8-9A6C-4E62-9A67-8B4FEA0EA8C1@matthew.at> <00af01cc0aa7$845a5330$8d0ef990$@net> Message-ID: On Thu, May 5, 2011 at 1:06 AM, Warren Johnson wrote: > I respect that. But just because you don't want to teach your child that > doesn't mean it isn't true. ?It's not like OIL is allocated based on need. Hmm, well my experience yesterday waiting in line for 2.5 hrs to get a limited amount of petrol suggests that occasionally, the petroleum market fails catastrophically, and when that happens, you can't buy whatever you want/need from "the market". > It's allocated based on who can pay for it and who can get to the pump first, based on my recent experience. and the market sorts out that > price. ?IP addresses are a unique resource that happens to be allocated > based on need. That's right, and I think it should stay that way. Needs based resource allocation has been a "crowdsourced" policy for several decades. I see no reason to junk the "wisdom of the crowd" because we are approaching scarcity. ?There's not many limited resources out there that are like > that. 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 jeffrey.lyon at blacklotus.net Thu May 5 06:24:06 2011 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Thu, 5 May 2011 06:24:06 -0400 Subject: [arin-ppml] ARIN-prop-146 Clarify Justified Need for Transfers In-Reply-To: References: <4DBEF120.4080901@arin.net> <88F39B20-5C20-45F0-AD61-5FA1E7F84CE3@delong.com> <3FCD1FDC-ECEE-4C9B-95C6-59E03D3C314E@matthew.at> <5598DFC7-E320-42FA-AA0E-C91C076BD725@delong.com> <6BA1EAA6-7D9C-44F9-BED7-884720F4B3BE@matthew.at> <05FAA29B-37BE-411C-95A4-50437602C8ED@delong.com> <4DBF6727.1090303@matthew.at> <097AAC1C-1F68-4820-9274-3290ADEFA195@delong.com> <4DBF75B7.3010407@matthew.at> <9501EA7E-FDAD-4DDA-B9E8-08C2811FF642@delong.com> <4DBF82F6.7050608@matthew.at> <20110503145144.N15967@mail.inlandnet.com> <4DC084E7.5000302@matthew.at> <4DC08664.4060905@matthew.at> <4791A59E-8864-483C-9BB0-03A6A5B8D50C@delong.com> <66466F57-4365-4ADB-94EB-E023F01B17CB@delong.com> <30D12BA8-9A6C-4E62-9A67-8B4FEA0EA8C1@matthew.at> <00af01cc0aa7$845a5330$8d0ef990$@net> Message-ID: On Thu, May 5, 2011 at 2:59 AM, McTim wrote: > On Thu, May 5, 2011 at 1:06 AM, Warren Johnson > wrote: >> I respect that. But just because you don't want to teach your child that >> doesn't mean it isn't true. ?It's not like OIL is allocated based on need. > > Hmm, well my experience yesterday waiting in line for 2.5 hrs to get a > limited amount of petrol suggests that occasionally, the petroleum > market fails catastrophically, and when that happens, you can't buy > whatever you want/need from "the market". > > >> It's allocated based on who can pay for it > > and who can get to the pump first, based on my recent experience. > > > ?and the market sorts out that >> price. ?IP addresses are a unique resource that happens to be allocated >> based on need. > > That's right, and I think it should stay that way. ?Needs based > resource allocation has been a "crowdsourced" policy for several > decades. ?I see no reason to junk the "wisdom of the crowd" because we > are approaching scarcity. > > > ?There's not many limited resources out there that are like >> that. > > Agreed. > > > -- > Cheers, > > McTim > "A name indicates what we seek. An address indicates where it is. A > route indicates how we get there."? Jon Postel > _______________________________________________ > 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. > Based on the fact that you call it "petrol," i'll assume you're not in the United States. My trips to the gas station take about < 5 minutes. I would call that a testament to the free market. But in all fairness, all governments have their hands in the cookie jar. Your government more so from what I can tell. -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications - AS32421 First and Leading in DDoS Protection Solutions From dogwallah at gmail.com Thu May 5 09:16:50 2011 From: dogwallah at gmail.com (McTim) Date: Thu, 5 May 2011 16:16:50 +0300 Subject: [arin-ppml] ARIN-prop-146 Clarify Justified Need for Transfers In-Reply-To: References: <4DBEF120.4080901@arin.net> <88F39B20-5C20-45F0-AD61-5FA1E7F84CE3@delong.com> <3FCD1FDC-ECEE-4C9B-95C6-59E03D3C314E@matthew.at> <5598DFC7-E320-42FA-AA0E-C91C076BD725@delong.com> <6BA1EAA6-7D9C-44F9-BED7-884720F4B3BE@matthew.at> <05FAA29B-37BE-411C-95A4-50437602C8ED@delong.com> <4DBF6727.1090303@matthew.at> <097AAC1C-1F68-4820-9274-3290ADEFA195@delong.com> <4DBF75B7.3010407@matthew.at> <9501EA7E-FDAD-4DDA-B9E8-08C2811FF642@delong.com> <4DBF82F6.7050608@matthew.at> <20110503145144.N15967@mail.inlandnet.com> <4DC084E7.5000302@matthew.at> <4DC08664.4060905@matthew.at> <4791A59E-8864-483C-9BB0-03A6A5B8D50C@delong.com> <66466F57-4365-4ADB-94EB-E023F01B17CB@delong.com> <30D12BA8-9A6C-4E62-9A67-8B4FEA0EA8C1@matthew.at> <00af01cc0aa7$845a5330$8d0ef990$@net> Message-ID: On Thu, May 5, 2011 at 1:24 PM, Jeffrey Lyon wrote: > > Based on the fact that you call it "petrol," i'll assume you're not in > the United States. My trips to the gas station take about < 5 minutes. > I would call that a testament to the free market. I guess you aren't old enough to remember long lines and rationing in the USA. > > But in all fairness, all governments have their hands in the cookie > jar. Your government more so from what I can tell. The current petrol shortage here has little to do with gov't and everything to do with speculators buying stocks of fuel, despite them having no retail outlets. See any resemblance to IP addressing? -- Cheers, McTim "A name indicates what we seek. An address indicates where it is. A route indicates how we get there."? Jon Postel From mike at nationwideinc.com Thu May 5 10:04:02 2011 From: mike at nationwideinc.com (Mike Burns) Date: Thu, 5 May 2011 10:04:02 -0400 Subject: [arin-ppml] Fw: Accusationof fundamentalconflictofinterest/IPaddress policypitched directly to ICANN References: <379DB08FB5564ED88230C1B6D6AE80FE@mike> <8695009A81378E48879980039EEDAD289D0E5BC6@MAIL1.polartel.local> <6B65D21B9B7543208304CC44EDD22444@mike> <3DA6DC8B-ADC6-4BCB-83BA-5F07BC5682C7@delong.com> <9D762F7D6FE3419790C6E47F58A1D4D5@mike> Message-ID: <4BEDC361E6D04A7292F5A294FA4FC2FE@mike> Hi Owen, answers in italics Now, if you mentioned the judiciary, you might have a point, but, you did not. You chose the governor. Small case "g" governor, see how semantic this can get. I think with your response, my concept is clear. If you pretend I mentioned judiciary, then maybe you can sense that what I am trying to say is that it can be argued either way in terms of authority. And that argument is boring. I don't think the authority structure is as clear as you describe. Or as I conceive it. Could be that is uniquely murky, and seems to be in the midst of transition away from US government control, in any case, leading to further murkiness. > > No, it proffers one possible set of requirements which could be used to do so. That is (and was) my point. Other than the author, there is no reliable evidence that anyone has reviewed or accepted this as the way such a thing should be done, let alone the way they would be done if such a structure were to be created. OK, we can read the letter. It's pretty clear it's a proposed (not ratified) set of standards for private ip registries, based on those existing for DNS registries. I never said it was reviewed or accepted, just that Benson's proposals lacked these kinds of regulations on new registry entities. I don't pretend to know what would happen if the author of the letter's proposals were accepted, and the Board of ICANN decided to implement them. My suspicion is that they would somehow become policy, though through what mechanism, I don't know. I just skimmed it, but if the community decided that Benson's proposals suffered only from a lack of oversight, and required action at a global level, then perhaps they will add their voice to the support which I offered. Perhaps, but, you would still need a global policy proposal to voice support for. Unless ICANN board actually does make the decision they are being asked to make. The link above is policy proposal on the ICANN correspondence page, and it is referenced in this letter: http://www.icann.org/en/correspondence/holtzman-to-olive-02mar11-en.pdf providing reasons for requesting the decision at the ICANN board level. Based on the appeal to the authority of the DoC contract, I expect there could be a further appeal to the DoC or NTIA level if the ICANN board decides not to make a decision. It is interesting that ICANN requested information from ARIN instead of summarily dismissing the request as coming outside of policy. ARIN's reply to ICANN is on the same site. I cannot see any correspondence that shows ICANN board requesting information from ARIN that was done after ICANN received this letter. Can you point to a link to such? Here is the sequence http://icann.org/en/correspondence/holtzman-to-beckstrom-27jan11-en.pdf T This was a letter of complaint to ICANN and a request for an appeal at the ICANN level based on authority derived from the DoC contract. http://icann.org/en/correspondence/beckstrom-to-curran-01mar11-en.pdf This is the letter from ICANN to ARIN which requests more information instead of summarily dismissing the request as coming outside of normal policy development channels. http://icann.org/en/correspondence/curran-to-beckstrom-02mar11-en.pdf This is John Curran's reply to ICANN http://icann.org/en/correspondence/holtzman-to-olive-02mar11-en.pdf This is the letter which includes the proposed regulations on new registries. I'm pretty sure that's the flow. A request last year from Depository to ARIN for bulk whois data in order to provide directory services. ARIN denies it and says it violates the AUP, it's not a valid purpose for bulk access. Then the letters above start, the first one is an appeal to ICANN, which I took as a means of going over ARIN's head, although such talk of levels is like a verbal Escher drawing, apparently. You seem certain that ICANN both won't and can't make this decision and make it apply to ARIN's sharing of whois data. I'm not so sanguine. I think courts seem more likely to deal with contracts then Memorandums and Agreements of Understanding. My guess, and I'm not a lawyer, is that should push come to shove in a legal arena, the courts may decide that the authority comes from the DoC contract. It could be as you say, that ICANN has no authority to dictate anything to ARIN; the letters say there is no contract between ARIN and ICANN. Just a guess, and I could be wrong. If it turns out that ICANN either can't or won't make the decision, as John points out in his letter, (or maybe elsewhere) that there remains the ability to change the global policy which specifies regional registry properties which he believes preclude private registries. Perhaps ICANN has power to make those changes, and the ARIN MoU would then require ARIN to submit? >Proper stewardship is to make policy that will increase the supply of addresses and bring down their price, while increasing whois reliability and removing the biggest distinction between legacy and >non-legacy addresses. >In general, I would agree with you about the goals of proper stewardship. Obviously, I do not >think that is the effect competing registries would have. Maybe I have found an appealing argument in the idea that increasing supply will reduce price. Since in a post-exhaust world, even those with need will have to pay for IP addresses, maybe the best stewardship is the policy which will lead to the lowest price? Should frame the debate in that way? Which policies should be implemented which will create the greatest supply to replace the free pool, in order that price be driven down? Which types of markets lead to lowest prices, those with fewer regulations or those with more regulations? Is low price to be desired by the proper steward? Now we are stewards of the rules and not the addresses. Are you accusing the APNIC community of abandoning stewardship, and if they did, why do you think they did that? Is the region largely peopled by IPv4 profiteers? >Yes. I believe that the transfer policy in the APNIC region was an abandonment of their >stewardship role and I have said as much on their policy development mailing list. >Why? Because Geoff Huston and a few other leaders in that community pushed long >and hard to get that position adopted mainly by creating fear that failing to do so would >render all RIR policy meaningless because the RIR policy would simply be bypassed >in favor of people doing what they wanted anyway. >Personally, I think that argument is absurd. Making theft legal just because you can't >stop people from stealing makes no sense to me. Well, that information leads me to discount the deaggregation argument against removing need requirements. I consider Geoff Huston to be en expert on BGP tables and defer to his judgement here. Clearly he did not see the risk of BGP table growth as a cause to retain needs requirements. I hope the ARIN community can take away the idea that it is not just a few IPv4 profiteers who have different visions of stewardship. Let me know if you need any help. While I don't agree with your goals and think they would be bad policy, I am happy to help bring such proposal before the community for their consideration. Owen Thanks, I appreciate the help and the advice. Regards, Mike -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike at nationwideinc.com Thu May 5 10:12:47 2011 From: mike at nationwideinc.com (Mike Burns) Date: Thu, 5 May 2011 10:12:47 -0400 Subject: [arin-ppml] ARIN-prop-146 Clarify Justified Need for Transfers References: <4DBEF120.4080901@arin.net><88F39B20-5C20-45F0-AD61-5FA1E7F84CE3@delong.com><3FCD1FDC-ECEE-4C9B-95C6-59E03D3C314E@mat 5A4-50437602C8ED@delong.com><4DBF6727.1090303@matthew.at><097AAC1C-1F68-4820-9274-3290ADEFA195@delong.com><4DBF75B7.3010407@mat thew.at><9501EA7E-FDAD-4DDA-B9E8-08C2811FF642@delong.com><4DBF82F6.7050608@matthew.at><20110503145144.N15967@mail.inlandnet.com><4DC084E7.5000302@matthew.at> <4DC08664.4060905@matthew.at><4791A59E-8864-483C-9BB0-03A6A5B8D50C@delong.com> <66466F57-4365-4ADB-94EB-E023F01B17CB@delong.com><30D12BA8-9A6C-4E62-9A67-8B4FEA0EA8C1@matthew.at><00af01cc0aa7$845a5330$8d0ef990$@net> Message-ID: <43F39974056A419E9E68A7B2219B04A4@mike> Speculators can buy addresses now, but ipv4trading.com doesn't seem awash in them. Speculators can buy legacy addresses now, too. Speculators and market-cornerers are naturally bound by the existence of IPv6. If they drive the price above transition cost, they will kill their own golden goose. Maybe this fear of speculators, of whom there is no evidence, is not justified. Regards, Mike ----- Original Message ----- From: "McTim" To: "Jeffrey Lyon" Cc: "Warren Johnson" ; Sent: Thursday, May 05, 2011 9:16 AM Subject: Re: [arin-ppml] ARIN-prop-146 Clarify Justified Need for Transfers On Thu, May 5, 2011 at 1:24 PM, Jeffrey Lyon wrote: > > Based on the fact that you call it "petrol," i'll assume you're not in > the United States. My trips to the gas station take about < 5 minutes. > I would call that a testament to the free market. I guess you aren't old enough to remember long lines and rationing in the USA. > > But in all fairness, all governments have their hands in the cookie > jar. Your government more so from what I can tell. The current petrol shortage here has little to do with gov't and everything to do with speculators buying stocks of fuel, despite them having no retail outlets. See any resemblance to IP addressing? -- Cheers, McTim "A name indicates what we seek. An address indicates where it is. A route indicates how we get there." Jon Postel _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. From Daniel_Alexander at Cable.Comcast.com Thu May 5 11:03:45 2011 From: Daniel_Alexander at Cable.Comcast.com (Alexander, Daniel) Date: Thu, 5 May 2011 15:03:45 +0000 Subject: [arin-ppml] Fw: Accusation of fundamentalconflictofinterest/IPaddress policy pitched directly to ICANN In-Reply-To: <379DB08FB5564ED88230C1B6D6AE80FE@mike> Message-ID: Mike, ARIN staff will be posting the proposal deadlines on the ARIN web site, but I should be able to give you an idea of timelines here. The AC meets by teleconference on the third Thursday of each month where we discuss the status of proposals, motions, and other business. At a high level, the three main stages are accepting a proposal onto the docket, making it a draft to be discussed at the public policy meeting, and forward to the Board or abandon. The details can be found here. https://www.arin.net/policy/pdp.html There are other steps, but I'm trying to keep this email from becoming a process doc. If we line the deadlines up with the AC meetings, it would be best to have a proposal submitted at least 10 days before the June 16th AC call. This would allow ARIN staff to provide their clarity and understanding review prior to the call. Then on the June call it becomes possible to accept it onto the docket. This provides the month between calls to work on the proposal and meet the July 22 deadline for staff and legal review on our July conference call. That leaves the August call to meet the deadline to determine the proposals that will be on the agenda for consideration during the Public Policy Meeting. I hope this helps. -Dan From: Mike Burns > Date: Tue, 3 May 2011 15:02:03 -0400 To: Microsoft Office User >, > Subject: Re: [arin-ppml] Fw: Accusation of fundamentalconflictofinterest/IPaddress policy pitched directly to ICANN Hi Dan, Yes, I do support the kind of oversight recommended in the letter, using as a model the requirements to be a DNS registrar. Perhaps this alone is justification for the highest level decisionmaking. Since a competing registry would be on the same level as the existing RIR's, in effect we would be asking the RIRs to oversee themselves if we allowed the RIRs to decide the issue, whether at the RIR or ASO level. Quis custodiet ipsos custodes? I do understand and appreciate the beauty of the non-governmental approach to Internet governance. I think the many kinds of conflicts you reference in your last paragraph are likely to be sorted out around the world in courts and legislatures, which I think are probably better suited to that task than ARIN. Much like the evolution (or de-evolution) of the Domain Name System. I will certainly vet any policy proposal I offer here, though can you give me an idea of the timeframe for proposals to be considered at the next AC meeting, should enough support manifest on the list? Regards, Mike ----- Original Message ----- From: Alexander, Daniel To: arin-ppml at arin.net Sent: Tuesday, May 03, 2011 2:49 PM Subject: Re: [arin-ppml] Fw: Accusation of fundamentalconflictofinterest/IPaddress policy pitched directly to ICANN Mike, As one of the AC shepherds for the proposals that were abandoned, I would offer one suggestion. Feel free to vet the proposal language you are considering here on this list prior to submitting an actual proposal. That is what this list is for. It would also help refine the scope that Keith mentions, and avoid the confusion that earlier proposals created. It is much easier to refine and evolve policy language on the ppml before it becomes part of the PDP process. If you look back to proposals 133, 134, and 136, they suggested that resource holders could opt-in, opt-out, or find the lowest common denominator to establish claim. While this would allow for what you propose, they offered none of the oversight that you advocate, which is also why there was such a cold reception. You can see how a competing registry, that is operating properly, could do so in a complimentary manner to the RIR. One thing people will have issue with is how the overall model can exist with the individuals who would try to create registries that would not apply similar standards of operation. Without any protections, the ISP's who would have to rely on this data would not be able to depend on the overall system (not referring to any particular registry) which is the shift in burden I mentioned in an earlier post. While people may have issues with the quality of whois, or registration of assignments, there is an upside to the current system. In this region, data points to ARIN and anyone can get involved, change the rules, and try and hold ARIN accountable. In the distributed model that is proposed, accountability is spread out, and the ability to resolve conflicts or issues becomes much harder. These are the kind of concerns that need to be addressed in order to gain momentum on a change of this scale. I hope this helps. Dan Alexander ARIN AC- speaking only for myself From: "Keith W. Hare" > Date: Tue, 3 May 2011 13:56:28 -0400 To: Mike Burns >, "arin-ppml at arin.net" > Subject: Re: [arin-ppml] Fw: Accusation of fundamental conflictofinterest/IPaddress policy pitched directly to ICANN Mike, So far, we have seen only bits of policy proposals that hint at the idea of competing private address registries. Without a policy proposal that covers all of the details, we are left to extrapolate the remaining pieces. This extrapolation may or may not be what competing address registry proponents have in mind, but until we see a full policy proposal, we are left with only perceptions of your (and others) motivations. Keith From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Mike Burns Sent: Tuesday, May 03, 2011 1:23 PM To: John Sweeting Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] Fw: Accusation of fundamental conflictofinterest/IPaddress policy pitched directly to ICANN It really is as easy as rounding up all the support you can muster, have that support join PPML, submit the proposal that you would like see made policy and then have your support show their support through PPML and the next PPM. Is there a reason you do not want to follow that process? It might help gain support if you provided your underlying motivation(s). -John Sweeting Hi John, My interest is in having a market for the buying and selling of IP addresses free from government and psuedo-government restrictions like taxes and justification requirements. I think this will best serve the interests of a community long held in thrall to the vision of an IPv6 transition that simply has not occurred in anything like the predicted timeframe. I would prefer that any support I find not be motivated by perceptions of my motivations, just my words and ideas. I voiced support for the concept of having a informed higher authority make the decision about competing registries requested in the letter which started the thread. I support competing registries because I believe that their competitive forces will move the market towards freedom, and because presumably a competing registry could decide its own, more liberal transfer policy. My understanding is that one way to get that accomplished, and I will accede it would be the better way, would be for the participants in policy making in all 5 RIRs come together to forge a policy allowing for competing private registries. But I think that is like expecting Network Solutions to have voted for competing DNS registrars. Unlikely to happen due to institutional conflicts of interest. (I understand that NetSol was not a community run org like the RIRs, but I see a natural institutional conflict between those who dominate a closed market and those who seek to expand it.) (And yes, this is also a commentary on the tiny number of participants who seem to people the RIR executive positions, and by extension the tiny groups of vocal participants in the RIR-PPML process.) (And yes, I have lost trust in ARIN staff since the MS/Nortel debacle) But nobody seems too sure what that higher authority is, and of course some participants see the community of RIR-PPML participants as the highest authority of all. I didn't write that letter, nor do I have any relationship with the writer of the letter, to my knowledge I have never met, conversed, or emailed with him. As for changing policy in the ARIN region, that is my intent, and I have heard from another poster who is interested in co-sponsoring a proposal designed to create a free market for ip transfers. So I will work with him to do just as you say, round up support and see if we can get a proposal that passes muster with the PPML and can be included in the next PPM. Regards, Mike Burns _______________________________________________ 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 mike at nationwideinc.com Thu May 5 11:05:24 2011 From: mike at nationwideinc.com (Mike Burns) Date: Thu, 5 May 2011 11:05:24 -0400 Subject: [arin-ppml] Fw: Accusation offundamentalconflictofinterest/IPaddress policy pitched directly to ICANN References: Message-ID: <90590D22D2AF4EF5A8EDA20C4B8A5606@mike> Thanks, Daniel. Prior to generating a proposal to remove needs justification for ARIN transfers, I found this site with a history of APNIC's similar proposal. http://www.apnic.net/policy/proposals/prop-050 I can see that it was a years-long journey from proposal to policy. Being that we are closer to exhaust than was APNIC in July of 2007, it behooves us to move with more alacrity if this is a proposal that finds favor with the ARIN community. Towards that end I include this link as a succinct review of the discussion points raised by the APNIC community, and some responses, as a primer to those interested. It is the proposal that was ultimately implemented. I think it's worth reading. http://mailman.apnic.net/mailing-lists/sig-policy/archive/2009/07/msg00041.html Considering that this last document is the polished result of years of prior consideration and discussion, I plan to use it as a model for my proposal. One of the benefits I plan to argue is compliance with APNIC policy, so I advance that in the hope that it provides a prior excuse for some cutting and pasting! (The compressed timeframe you describe being another.) Regards, Mike Burns ----- Original Message ----- From: Alexander, Daniel To: arin-ppml at arin.net ; Mike Burns Sent: Thursday, May 05, 2011 11:03 AM Subject: Re: [arin-ppml] Fw: Accusation offundamentalconflictofinterest/IPaddress policy pitched directly to ICANN Mike, ARIN staff will be posting the proposal deadlines on the ARIN web site, but I should be able to give you an idea of timelines here. The AC meets by teleconference on the third Thursday of each month where we discuss the status of proposals, motions, and other business. At a high level, the three main stages are accepting a proposal onto the docket, making it a draft to be discussed at the public policy meeting, and forward to the Board or abandon. The details can be found here. https://www.arin.net/policy/pdp.html There are other steps, but I'm trying to keep this email from becoming a process doc. If we line the deadlines up with the AC meetings, it would be best to have a proposal submitted at least 10 days before the June 16th AC call. This would allow ARIN staff to provide their clarity and understanding review prior to the call. Then on the June call it becomes possible to accept it onto the docket. This provides the month between calls to work on the proposal and meet the July 22 deadline for staff and legal review on our July conference call. That leaves the August call to meet the deadline to determine the proposals that will be on the agenda for consideration during the Public Policy Meeting. I hope this helps. -Dan From: Mike Burns Date: Tue, 3 May 2011 15:02:03 -0400 To: Microsoft Office User , Subject: Re: [arin-ppml] Fw: Accusation of fundamentalconflictofinterest/IPaddress policy pitched directly to ICANN Hi Dan, Yes, I do support the kind of oversight recommended in the letter, using as a model the requirements to be a DNS registrar. Perhaps this alone is justification for the highest level decisionmaking. Since a competing registry would be on the same level as the existing RIR's, in effect we would be asking the RIRs to oversee themselves if we allowed the RIRs to decide the issue, whether at the RIR or ASO level. Quis custodiet ipsos custodes? I do understand and appreciate the beauty of the non-governmental approach to Internet governance. I think the many kinds of conflicts you reference in your last paragraph are likely to be sorted out around the world in courts and legislatures, which I think are probably better suited to that task than ARIN. Much like the evolution (or de-evolution) of the Domain Name System. I will certainly vet any policy proposal I offer here, though can you give me an idea of the timeframe for proposals to be considered at the next AC meeting, should enough support manifest on the list? Regards, Mike ----- Original Message ----- From: Alexander, Daniel To: arin-ppml at arin.net Sent: Tuesday, May 03, 2011 2:49 PM Subject: Re: [arin-ppml] Fw: Accusation of fundamentalconflictofinterest/IPaddress policy pitched directly to ICANN Mike, As one of the AC shepherds for the proposals that were abandoned, I would offer one suggestion. Feel free to vet the proposal language you are considering here on this list prior to submitting an actual proposal. That is what this list is for. It would also help refine the scope that Keith mentions, and avoid the confusion that earlier proposals created. It is much easier to refine and evolve policy language on the ppml before it becomes part of the PDP process. If you look back to proposals 133, 134, and 136, they suggested that resource holders could opt-in, opt-out, or find the lowest common denominator to establish claim. While this would allow for what you propose, they offered none of the oversight that you advocate, which is also why there was such a cold reception. You can see how a competing registry, that is operating properly, could do so in a complimentary manner to the RIR. One thing people will have issue with is how the overall model can exist with the individuals who would try to create registries that would not apply similar standards of operation. Without any protections, the ISP's who would have to rely on this data would not be able to depend on the overall system (not referring to any particular registry) which is the shift in burden I mentioned in an earlier post. While people may have issues with the quality of whois, or registration of assignments, there is an upside to the current system. In this region, data points to ARIN and anyone can get involved, change the rules, and try and hold ARIN accountable. In the distributed model that is proposed, accountability is spread out, and the ability to resolve conflicts or issues becomes much harder. These are the kind of concerns that need to be addressed in order to gain momentum on a change of this scale. I hope this helps. Dan Alexander ARIN AC- speaking only for myself From: "Keith W. Hare" Date: Tue, 3 May 2011 13:56:28 -0400 To: Mike Burns , "arin-ppml at arin.net" Subject: Re: [arin-ppml] Fw: Accusation of fundamental conflictofinterest/IPaddress policy pitched directly to ICANN Mike, So far, we have seen only bits of policy proposals that hint at the idea of competing private address registries. Without a policy proposal that covers all of the details, we are left to extrapolate the remaining pieces. This extrapolation may or may not be what competing address registry proponents have in mind, but until we see a full policy proposal, we are left with only perceptions of your (and others) motivations. Keith From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Mike Burns Sent: Tuesday, May 03, 2011 1:23 PM To: John Sweeting Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] Fw: Accusation of fundamental conflictofinterest/IPaddress policy pitched directly to ICANN It really is as easy as rounding up all the support you can muster, have that support join PPML, submit the proposal that you would like see made policy and then have your support show their support through PPML and the next PPM. Is there a reason you do not want to follow that process? It might help gain support if you provided your underlying motivation(s). -John Sweeting Hi John, My interest is in having a market for the buying and selling of IP addresses free from government and psuedo-government restrictions like taxes and justification requirements. I think this will best serve the interests of a community long held in thrall to the vision of an IPv6 transition that simply has not occurred in anything like the predicted timeframe. I would prefer that any support I find not be motivated by perceptions of my motivations, just my words and ideas. I voiced support for the concept of having a informed higher authority make the decision about competing registries requested in the letter which started the thread. I support competing registries because I believe that their competitive forces will move the market towards freedom, and because presumably a competing registry could decide its own, more liberal transfer policy. My understanding is that one way to get that accomplished, and I will accede it would be the better way, would be for the participants in policy making in all 5 RIRs come together to forge a policy allowing for competing private registries. But I think that is like expecting Network Solutions to have voted for competing DNS registrars. Unlikely to happen due to institutional conflicts of interest. (I understand that NetSol was not a community run org like the RIRs, but I see a natural institutional conflict between those who dominate a closed market and those who seek to expand it.) (And yes, this is also a commentary on the tiny number of participants who seem to people the RIR executive positions, and by extension the tiny groups of vocal participants in the RIR-PPML process.) (And yes, I have lost trust in ARIN staff since the MS/Nortel debacle) But nobody seems too sure what that higher authority is, and of course some participants see the community of RIR-PPML participants as the highest authority of all. I didn't write that letter, nor do I have any relationship with the writer of the letter, to my knowledge I have never met, conversed, or emailed with him. As for changing policy in the ARIN region, that is my intent, and I have heard from another poster who is interested in co-sponsoring a proposal designed to create a free market for ip transfers. So I will work with him to do just as you say, round up support and see if we can get a proposal that passes muster with the PPML and can be included in the next PPM. Regards, Mike Burns _______________________________________________ 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 5 11:53:42 2011 From: bill at herrin.us (William Herrin) Date: Thu, 5 May 2011 11:53:42 -0400 Subject: [arin-ppml] Fw: Accusationof fundamentalconflictofinterest/IPaddress policypitched directly to ICANN In-Reply-To: <3DA6DC8B-ADC6-4BCB-83BA-5F07BC5682C7@delong.com> References: <379DB08FB5564ED88230C1B6D6AE80FE@mike> <8695009A81378E48879980039EEDAD289D0E5BC6@MAIL1.polartel.local> <6B65D21B9B7543208304CC44EDD22444@mike> <3DA6DC8B-ADC6-4BCB-83BA-5F07BC5682C7@delong.com> Message-ID: On Wed, May 4, 2011 at 3:16 PM, Owen DeLong wrote: > Your mind is clearly confused on multiple levels... > ICANN does not predate RIRs. Both RIPE and APNIC, as does ARIN. > ICAN was formed in October of 1998. > APNIC was formed in 1992. > RIPE NCC was formed in 1992 > ARIN was formed in 1993 Owen, Although your timeline is correct (APNIC, then RIPE, ARIN and finally ICANN) you may be confused about some of the dates. ARIN, for example, was incorporated in April 1997 and did not take on responsibility for managing IP addresses until later that year. Although the experiment that became APNIC started in 1992, it didn't take on anything approaching full responsibility for the region's IP addresses until at least 1995. You are correct, however, that by the time ICANN was formed in 1998 it was clearly understood that IANA was to be operated per the IETF RFCs which placed the RIRs in the driver's seat. Mike would do well to understand that neither ICANN nor DOC is empowered to act on complaints other than about the RIRs' non-compliance with the RIR's own policies or non-compliance with the relevant RFCs. The Depository folks would do well to understand that too. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From farmer at umn.edu Thu May 5 12:07:21 2011 From: farmer at umn.edu (David Farmer) Date: Thu, 05 May 2011 11:07:21 -0500 Subject: [arin-ppml] Fw: Accusation offundamentalconflictofinterest/IPaddress policy pitched directly to ICANN In-Reply-To: <90590D22D2AF4EF5A8EDA20C4B8A5606@mike> References: <90590D22D2AF4EF5A8EDA20C4B8A5606@mike> Message-ID: <4DC2CB39.3010300@umn.edu> On 5/5/11 10:05 CDT, Mike Burns wrote: > Thanks, Daniel. Prior to generating a proposal to remove needs > justification for ARIN transfers, I found this site with a history of > APNIC's similar proposal. > http://www.apnic.net/policy/proposals/prop-050 > > I can see that it was a years-long journey from proposal to policy. > Being that we are closer to exhaust than was APNIC in July of 2007, > it behooves us to move with more alacrity if this is a proposal that > finds favor with the ARIN community. > > Towards that end I include this link as a succinct review of the > discussion points raised by the APNIC community, and some responses, > as a primer to those interested. It is the proposal that was > ultimately implemented. I think it's worth reading. > http://mailman.apnic.net/mailing-lists/sig-policy/archive/2009/07/msg00041.html For additional background and preparation, you should review review the discussions surrounding ARIN policies 2008-2, 2008-8, and 2009-1, that took place in the ARIN community more or less concurrently with APNIC's discussion of its prop-50. https://www.arin.net/policy/proposals/2008_2.html https://www.arin.net/policy/proposals/2008_6.html https://www.arin.net/policy/proposals/2009_1.html > Considering that this last document is the polished result of years of > prior consideration and discussion, I plan to use it as a model for > my proposal. > > One of the benefits I plan to argue is compliance with APNIC policy, > so I advance that in the hope that it provides a prior excuse for > some cutting and pasting! (The compressed timeframe you describe > being another.) Compliance with another RIR's policies is nether a benefit nor necessary in my opinion. However, harmony among the policies of the RIRs on a global basis could be and I believe is a benefit. This is an important nuance, you would do well to pay attention to it. :) > Regards, Mike Burns While I am yet to be convinced that the elimination of the needs basis is the correct direction for the ARIN community; I want to personally thank you for taking up the important challenge of leading the advocacy for this position. I believe this is an important and necessary discussion. Furthermore, I want to beseech the community as a whole regardless to your opinion on this subject to participate in this important debate and to do so in a respectful manner. Thank you. -- =============================================== 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 matthew at matthew.at Thu May 5 12:14:20 2011 From: matthew at matthew.at (Matthew Kaufman) Date: Thu, 05 May 2011 09:14:20 -0700 Subject: [arin-ppml] ARIN-prop-146 Clarify Justified Need for Transfers In-Reply-To: References: <4DBEF120.4080901@arin.net> <88F39B20-5C20-45F0-AD61-5FA1E7F84CE3@delong.com> <3FCD1FDC-ECEE-4C9B-95C6-59E03D3C314E@matthew.at> <5598DFC7-E320-42FA-AA0E-C91C076BD725@delong.com> <6BA1EAA6-7D9C-44F9-BED7-884720F4B3BE@matthew.at> <05FAA29B-37BE-411C-95A4-50437602C8ED@delong.com> <4DBF6727.1090303@matthew.at> <097AAC1C-1F68-4820-9274-3290ADEFA195@delong.com> <4DBF75B7.3010407@matthew.at> <9501EA7E-FDAD-4DDA-B9E8-08C2811FF642@delong.com> <4DBF82F6.7050608@matthew.at> <20110503145144.N15967@mail.inlandnet.com> <4DC084E7.5000302@matthew.at> <4DC08664.4060905@matthew.at> <4791A59E-8864-483C-9BB0-03A6A5B8D50C@delong.com> <66466F57-4365-4ADB-94EB-E023F01B17CB@delong.com> <30D12BA8-9A6C-4E62-9A67-8B4FEA0EA8C1@matthew.at> <00af01cc0aa7$845a5330$8d0ef990$@net> Message-ID: <4DC2CCDC.3030103@matthew.at> On 5/4/2011 11:59 PM, McTim wrote: > > That's right, and I think it should stay that way. Needs based > resource allocation has been a "crowdsourced" policy for several > decades. I see no reason to junk the "wisdom of the crowd" because we > are approaching scarcity. And this proposal is NOT to "junk" the concept of needs based allocation. Matthew Kaufman From mike at nationwideinc.com Thu May 5 12:16:31 2011 From: mike at nationwideinc.com (Mike Burns) Date: Thu, 5 May 2011 12:16:31 -0400 Subject: [arin-ppml] Fw: Accusationof fundamentalconflictofinterest/IPaddress policypitched directly to ICANN References: <379DB08FB5564ED88230C1B6D6AE80FE@mike> <8695009A81378E48879980039EEDAD289D0E5BC6@MAIL1.polartel.local> <6B65D21B9B7543208304CC44EDD22444@mike> <3DA6DC8B-ADC6-4BCB-83BA-5F07BC5682C7@delong.com> Message-ID: <4A4FE574E42F4C64A2A498A6A1FF89F2@mike> >You are correct, however, that by the time ICANN was formed in 1998 it >was clearly understood that IANA was to be operated per the IETF RFCs >which placed the RIRs in the driver's seat. Mike would do well to >understand that neither ICANN nor DOC is empowered to act on >complaints other than about the RIRs' non-compliance with the RIR's >own policies or non-compliance with the relevant RFCs. The Depository >folks would do well to understand that too. >Regards, >Bill Herrin Hi Bill, If your interpretation is correct, then the request from Depository will die due to lack of authority at ICANN. Maybe that has already happened, as Owen noted there is no evidence that they have acted in any way except asking for input from ARIN at some earlier point. But this may end up in a court that doesn't care as much about the internal policies of entities as it does about interpreting contract law. Contracts are few and far between at this level, which seems littered with MoAs and other non-contractual agreements. I'm no lawyer, I merely state that as a possibility. I have learned enough about governance at that level to think that the environment is fluid, with some precendents still waiting to be set. In any case, as I said before, private registries are a means to an end for me, the end being a free market in IPv4 transfers. And I guess there is some mechanism to change the ICP-2, so perhaps private registries will emerge through that process. I encourage that because I believe competing registries will be good for market efficiencies and innovations over time. In the meantime, the thrust of my discussion here was the alignment of ARIN policy with APNIC policy related to IPv4 transfers, and I am overdue with a draft proposal to that end. So on the issue of private registries and the issue of who is authoritative, I am going to sit back and watch what happens, if anything, with the Depository appeal, and spare the list more tendentious discussion. Regards, Mike From mike at nationwideinc.com Thu May 5 12:49:53 2011 From: mike at nationwideinc.com (Mike Burns) Date: Thu, 5 May 2011 12:49:53 -0400 Subject: [arin-ppml] Serious question for the list. References: Message-ID: <723D48A257C34BA0BD60F16130F4844F@mike> Hi all, I have had an idea. Since it has been determined that everybody in the ARIN community with an email address may participate in policy development, how does the list feel about soliciting the input from a broader group of participants? Suppose I posted to a site like Reason magazine, which is Libertarian, inviting people to join the ARIN ppml in order to support my proposal to end needs requirements for IPv4 transfers? And those who oppose could post to HuffPo or some other site where opposing views might be expected to be courted. Is this a horrible idea? I have not acted on it, there could be large implications. What are your thoughts? Regards, Mike Burns -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill at herrin.us Thu May 5 13:02:38 2011 From: bill at herrin.us (William Herrin) Date: Thu, 5 May 2011 13:02:38 -0400 Subject: [arin-ppml] Serious question for the list. In-Reply-To: <723D48A257C34BA0BD60F16130F4844F@mike> References: <723D48A257C34BA0BD60F16130F4844F@mike> Message-ID: On Thu, May 5, 2011 at 12:49 PM, Mike Burns wrote: > Since it has been determined that everybody in the ARIN community with an > email address may participate in policy development, how does the list feel > about soliciting the input from a broader group of participants? > > Suppose I posted to a site like Reason magazine, which is Libertarian, > inviting people to join the ARIN ppml in order to support my proposal to end > needs requirements for IPv4 transfers? > > What are your thoughts? Hi Mike, Go for it. The discussion gets in to arcane technical details, but anyone willing to invest the time and effort is more than welcome. Beware, though, that statements of support and dissent are just that: statements. Both the AC and the board weigh those statements when considering proposals, but they don't treat them as votes. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From Keith at jcc.com Thu May 5 13:08:01 2011 From: Keith at jcc.com (Keith W. Hare) Date: Thu, 5 May 2011 13:08:01 -0400 Subject: [arin-ppml] Serious question for the list. In-Reply-To: References: <723D48A257C34BA0BD60F16130F4844F@mike> Message-ID: Mike, My guess is that such a posting would flood the list with opinionated people who don't have a clue what the real issues are. I suspect that there would be some amount of explanation about why competing registries couldn't just manufacture more IPv4 addresses. About four years ago, someone (ARIN, I suppose) sent an invitation to POCs inviting them to join ARIN PPML. A number of people joined followed by a rash of "How do I get off of this list" questions. It was this invitation that prompted me to join the list - you can decide for yourself whether that was a good or bad thing. Keith -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of William Herrin Sent: Thursday, May 05, 2011 1:03 PM To: Mike Burns Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] Serious question for the list. On Thu, May 5, 2011 at 12:49 PM, Mike Burns wrote: > Since it has been determined that everybody in the ARIN community with an > email address may participate in policy development, how does the list feel > about soliciting the input from a broader group of participants? > > Suppose I posted to a site like Reason magazine, which is Libertarian, > inviting people to join the ARIN ppml in order to support my proposal to end > needs requirements for IPv4 transfers? > > What are your thoughts? Hi Mike, Go for it. The discussion gets in to arcane technical details, but anyone willing to invest the time and effort is more than welcome. Beware, though, that statements of support and dissent are just that: statements. Both the AC and the board weigh those statements when considering proposals, but they don't treat them as votes. 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 jeffrey.lyon at blacklotus.net Thu May 5 13:07:02 2011 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Thu, 5 May 2011 13:07:02 -0400 Subject: [arin-ppml] Serious question for the list. In-Reply-To: <723D48A257C34BA0BD60F16130F4844F@mike> References: <723D48A257C34BA0BD60F16130F4844F@mike> Message-ID: On Thu, May 5, 2011 at 12:49 PM, Mike Burns wrote: > Hi all, > > I have had an idea. > > Since it has been determined that everybody in the ARIN community with an > email address may participate in policy development, how does the list feel > about soliciting the input from a broader group of participants? > > Suppose I posted to a site like Reason magazine, which is Libertarian, > inviting people to join the ARIN ppml in order to support my proposal to end > needs requirements for IPv4 transfers? > > And those who oppose could post to HuffPo or some other site where opposing > views might be expected to be courted. > > Is this a horrible idea? > > I have not acted on it, there could be large implications. > > What are your thoughts? > > Regards, > > Mike Burns > > > _______________________________________________ > 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. > Mike, I dislike the idea. PPML is compromised primarily of the olde guard that seems intent upon blocking any efforts to commercialize registration services. Even with substantial support, at this point it seems those who are actually in charge of voting on policy would block these attempts until (in an extreme case) they're completely voted out of office. Even with AC support, there has to be concurrence within the Board of Trustees. You can, however, use your own resources to create a grassroots campaign for supporters of this idea (for which I am one, as you're aware) to voice their opinions to ARIN and the PPML. Even better, you could run for office. My immediate focus is on a recent proposal that would the specified transfer process more palatable. http://lists.arin.net/pipermail/arin-ppml/2011-May/021419.html . I made the suggestion that the justified need be extended to 36 months, which hopefully will gain traction. Best regards, -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications - AS32421 First and Leading in DDoS Protection Solutions From mike at nationwideinc.com Thu May 5 13:15:46 2011 From: mike at nationwideinc.com (Mike Burns) Date: Thu, 5 May 2011 13:15:46 -0400 Subject: [arin-ppml] ARIN-prop-147 Set Transfer Need to 24 months andClarify Exception References: <4DBEF12A.2020002@arin.net> Message-ID: Support, as it moves in the right direction. Regards, Mike ----- Original Message ----- From: "ARIN" To: Sent: Monday, May 02, 2011 2:00 PM Subject: [arin-ppml] ARIN-prop-147 Set Transfer Need to 24 months andClarify Exception > ARIN-prop-147 Set Transfer Need to 24 months and Clarify Exception > > 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-147 Set Transfer Need to 24 months and Clarify Exception > > Proposal Originator: Matthew Kaufman > > Proposal Version: 1 > > Date: 2 May 2011 > > Proposal type: new > > Policy term: permanent > > Policy statement: > > Change section 4.2.4.4 content as follows: > > Replace: > "This reduction does not apply to resources received via section 8.3. An > organization receiving a transfer under section 8.3 may continue to > request up to a 12-month supply of IP addresses." > > With: > "This reduction does not apply to resources received via transfer. An > organization receiving a transfer under section 8 may request up to a > 24-month supply of IP addresses." > > Rationale: > > The exception should apply to transfers under 8.2 as well as 8.3 (and > any future transfer policies). > > Due to the complexity of the financial transaction that may be > involved and the associated budgeting on the part of the receiving > organization, 24 months is a more reasonable amount of forecast need to > allow to be fulfilled via the transfer process. > > Potential benefit to address aggregation by allowing fewer larger > transfers sooner. > > 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 Thu May 5 13:17:15 2011 From: farmer at umn.edu (David Farmer) Date: Thu, 05 May 2011 12:17:15 -0500 Subject: [arin-ppml] Serious question for the list. In-Reply-To: <723D48A257C34BA0BD60F16130F4844F@mike> References: <723D48A257C34BA0BD60F16130F4844F@mike> Message-ID: <4DC2DB9B.2020908@umn.edu> On 5/5/11 11:49 CDT, Mike Burns wrote: > Hi all, > I have had an idea. > Since it has been determined that everybody in the ARIN community with > an email address may participate in policy development, how does the > list feel about soliciting the input from a broader group of participants? While not an absolute requirement, I believe there is an understanding that some minimal level of technical expertise and interest in the details of the subject matter are necessary in order to provide useful or meaningful contribution to the process. > Suppose I posted to a site like Reason magazine, which is Libertarian, > inviting people to join the ARIN ppml in order to support my proposal to > end needs requirements for IPv4 transfers? > And those who oppose could post to HuffPo or some other site where > opposing views might be expected to be courted. > Is this a horrible idea? > I have not acted on it, there could be large implications. > What are your thoughts? If you honestly believe it will bring useful or meaningful contributions to the debate then sure, go ahead. But, if it is simply being done to overload the process, that will become obvious and it will not provide the intended results. If you bog-down the process, your ability to effect the meaningful changes you would like to see will be hampered as much as anything else. > Regards, > Mike Burns -- =============================================== 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 jeffrey.lyon at blacklotus.net Thu May 5 13:21:27 2011 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Thu, 5 May 2011 13:21:27 -0400 Subject: [arin-ppml] ARIN-prop-146 Clarify Justified Need for Transfers In-Reply-To: References: <4DBEF120.4080901@arin.net> <88F39B20-5C20-45F0-AD61-5FA1E7F84CE3@delong.com> <3FCD1FDC-ECEE-4C9B-95C6-59E03D3C314E@matthew.at> <5598DFC7-E320-42FA-AA0E-C91C076BD725@delong.com> <6BA1EAA6-7D9C-44F9-BED7-884720F4B3BE@matthew.at> <05FAA29B-37BE-411C-95A4-50437602C8ED@delong.com> <4DBF6727.1090303@matthew.at> <097AAC1C-1F68-4820-9274-3290ADEFA195@delong.com> <4DBF75B7.3010407@matthew.at> <9501EA7E-FDAD-4DDA-B9E8-08C2811FF642@delong.com> <4DBF82F6.7050608@matthew.at> <20110503145144.N15967@mail.inlandnet.com> <4DC084E7.5000302@matthew.at> <4DC08664.4060905@matthew.at> <4791A59E-8864-483C-9BB0-03A6A5B8D50C@delong.com> <66466F57-4365-4ADB-94EB-E023F01B17CB@delong.com> <30D12BA8-9A6C-4E62-9A67-8B4FEA0EA8C1@matthew.at> <00af01cc0aa7$845a5330$8d0ef990$@net> Message-ID: Response inline. On Thu, May 5, 2011 at 9:16 AM, McTim wrote: > On Thu, May 5, 2011 at 1:24 PM, Jeffrey Lyon > wrote: > >> >> Based on the fact that you call it "petrol," i'll assume you're not in >> the United States. My trips to the gas station take about < 5 minutes. >> I would call that a testament to the free market. > > > I guess you aren't old enough to remember long lines and rationing in the USA. > President Nixon was also one of the biggest black eyes to the U.S. economy to occur in the 20th century. There is less control on the market now and we no longer have these issues. Basic supply and demand principles ensure that no one will ever be stuck in a line waiting for anything so long as there is minimal government regulation or collusion. Even President Obama hasn't managed to cause this level of economic damage. > See any resemblance to IP addressing? Yes, I do. ARIN restricts and rations access to IP resources which keeps prices artificially low while putting long lines on the near horizon. Anyone who isn't satisfied with their fuel being rationed shouldn't be satisfied with their IP space being rationed. > > -- > Cheers, > > McTim > "A name indicates what we seek. An address indicates where it is. A > route indicates how we get there."? Jon Postel > -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications - AS32421 First and Leading in DDoS Protection Solutions From hannigan at gmail.com Thu May 5 13:25:14 2011 From: hannigan at gmail.com (Martin Hannigan) Date: Thu, 5 May 2011 13:25:14 -0400 Subject: [arin-ppml] Serious question for the list. In-Reply-To: <4DC2DB9B.2020908@umn.edu> References: <723D48A257C34BA0BD60F16130F4844F@mike> <4DC2DB9B.2020908@umn.edu> Message-ID: On Thu, May 5, 2011 at 1:17 PM, David Farmer wrote: > On 5/5/11 11:49 CDT, Mike Burns wrote: >> >> Hi all, >> I have had an idea. >> Since it has been determined that everybody in the ARIN community with >> an email address may participate in policy development, how does the >> list feel about soliciting the input from a broader group of participants? > > While not an absolute requirement, I believe there is an understanding that > some minimal ?level of technical expertise and interest in the details of > the subject matter are necessary in order to provide useful or meaningful > contribution to the process. > So we would exclude members of the general public (users) then? Best, -M< From owen at delong.com Thu May 5 13:24:50 2011 From: owen at delong.com (Owen DeLong) Date: Thu, 5 May 2011 10:24:50 -0700 Subject: [arin-ppml] ARIN-prop-146 Clarify Justified Need for Transfers In-Reply-To: References: <4DBEF120.4080901@arin.net> <88F39B20-5C20-45F0-AD61-5FA1E7F84CE3@delong.com> <3FCD1FDC-ECEE-4C9B-95C6-59E03D3C314E@matthew.at> <5598DFC7-E320-42FA-AA0E-C91C076BD725@delong.com> <6BA1EAA6-7D9C-44F9-BED7-884720F4B3BE@matthew.at> <05FAA29B-37BE-411C-95A4-50437602C8ED@delong.com> <4DBF6727.1090303@matthew.at> <097AAC1C-1F68-4820-9274-3290ADEFA195@delong.com> <4DBF75B7.3010407@matthew.at> <9501EA7E-FDAD-4DDA-B9E8-08C2811FF642@delong.com> <4DBF82F6.7050608@matthew.at> <20110503145144.N15967@mail.inlandnet.com> <4DC084E7.5000302@matthew.at> <4DC08664.4060905@matthew.at> <4791A59E-8864-483C-9BB0-03A6A5B8D50C@delong.com> <66466F57-4365-4ADB-94EB-E023F01B17CB@delong.com> <30D12BA8-9A6C-4E62-9A67-8B4FEA0EA8C1@matthew.at> <00af01cc0aa7$845a5330$8d0ef990$@net> Message-ID: <3E874CBF-24C5-4481-A52F-7F8BE64F27C9@delong.com> > > Based on the fact that you call it "petrol," i'll assume you're not in > the United States. My trips to the gas station take about < 5 minutes. > I would call that a testament to the free market. > As near as I can tell based on significant travel, gasoline or petrol prices are quite artificially low in the united States compared to the rest of the world. I don't actually know why that is, but, I would say that the energy companies in the US are some of the best examples of free market dysfunction that are available. My trips to the gas station take between 5 and 45 minutes, depending on the length of the line. The price of gasoline fluctuates randomly and is obviously detached from the realities of the costs of the raw materials. The price only drops significantly after it has risen so much so rapidly that there is public outcry and congress starts to seriously consider additional regulation of the industry. Then it drops just enough to silence the cries for regulation. > But in all fairness, all governments have their hands in the cookie > jar. Your government more so from what I can tell. > There are a number of possible explanations outside of the government's hand in the cookie jar for the disparity in experiences at the gas pump. Owen From bill at herrin.us Thu May 5 13:33:47 2011 From: bill at herrin.us (William Herrin) Date: Thu, 5 May 2011 13:33:47 -0400 Subject: [arin-ppml] Fw: Accusationof fundamentalconflictofinterest/IPaddress policypitched directly to ICANN In-Reply-To: <4A4FE574E42F4C64A2A498A6A1FF89F2@mike> References: <379DB08FB5564ED88230C1B6D6AE80FE@mike> <8695009A81378E48879980039EEDAD289D0E5BC6@MAIL1.polartel.local> <6B65D21B9B7543208304CC44EDD22444@mike> <3DA6DC8B-ADC6-4BCB-83BA-5F07BC5682C7@delong.com> <4A4FE574E42F4C64A2A498A6A1FF89F2@mike> Message-ID: On Thu, May 5, 2011 at 12:16 PM, Mike Burns wrote: > If your interpretation is correct, then the request from Depository will die > due to lack of authority at ICANN. > Maybe that has already happened, as Owen noted there is no evidence that > they have acted in any way except asking for input from ARIN at some earlier > point. Bingo. Apropos nothing, I wonder if the NRO is mature enough to take over the IANA function from ICANN entirely, including the funding. IANA long predates ICANN. It's current presence at ICANN is more an artifact of history than a conscious design choice... in 1998 it was a hot potato that had to go somewhere. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From Keith at jcc.com Thu May 5 13:46:25 2011 From: Keith at jcc.com (Keith W. Hare) Date: Thu, 5 May 2011 13:46:25 -0400 Subject: [arin-ppml] Serious question for the list. In-Reply-To: References: <723D48A257C34BA0BD60F16130F4844F@mike> <4DC2DB9B.2020908@umn.edu> Message-ID: > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf Of Martin Hannigan > Sent: Thursday, May 05, 2011 1:25 PM > To: David Farmer > Cc: arin-ppml at arin.net > Subject: Re: [arin-ppml] Serious question for the list. > > On Thu, May 5, 2011 at 1:17 PM, David Farmer wrote: > > On 5/5/11 11:49 CDT, Mike Burns wrote: > >> > >> Hi all, > >> I have had an idea. > >> Since it has been determined that everybody in the ARIN community > with > >> an email address may participate in policy development, how does the > >> list feel about soliciting the input from a broader group of > participants? > > > > While not an absolute requirement, I believe there is an understanding > that > > some minimal ?level of technical expertise and interest in the details > of > > the subject matter are necessary in order to provide useful or > meaningful > > contribution to the process. > > > > > So we would exclude members of the general public (users) then? > Nope, we wouldn't exclude members of the general public, we would just bore them to death. Keith From farmer at umn.edu Thu May 5 13:45:14 2011 From: farmer at umn.edu (David Farmer) Date: Thu, 05 May 2011 12:45:14 -0500 Subject: [arin-ppml] Serious question for the list. In-Reply-To: References: <723D48A257C34BA0BD60F16130F4844F@mike> <4DC2DB9B.2020908@umn.edu> Message-ID: <4DC2E22A.50708@umn.edu> On 5/5/11 12:25 CDT, Martin Hannigan wrote: > On Thu, May 5, 2011 at 1:17 PM, David Farmer wrote: >> On 5/5/11 11:49 CDT, Mike Burns wrote: >>> >>> Hi all, >>> I have had an idea. >>> Since it has been determined that everybody in the ARIN community with >>> an email address may participate in policy development, how does the >>> list feel about soliciting the input from a broader group of participants? >> >> While not an absolute requirement, I believe there is an understanding that >> some minimal level of technical expertise and interest in the details of >> the subject matter are necessary in order to provide useful or meaningful >> contribution to the process. >> > > So we would exclude members of the general public (users) then? Where did I say exclude? "not an absolute requirement", an "interest in the details" are needed for a "meaningful contribution". None of that means exclude in my book, it simply means that participation takes effort and if you want people to take you seriously you need to make a effort. That is true in many parts of civil society. -- =============================================== 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 farmer at umn.edu Thu May 5 13:47:45 2011 From: farmer at umn.edu (David Farmer) Date: Thu, 05 May 2011 12:47:45 -0500 Subject: [arin-ppml] Serious question for the list. In-Reply-To: References: <723D48A257C34BA0BD60F16130F4844F@mike> <4DC2DB9B.2020908@umn.edu> Message-ID: <4DC2E2C1.7010903@umn.edu> On 5/5/11 12:46 CDT, Keith W. Hare wrote: > > >> -----Original Message----- >> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On >> Behalf Of Martin Hannigan >> Sent: Thursday, May 05, 2011 1:25 PM >> To: David Farmer >> Cc: arin-ppml at arin.net >> Subject: Re: [arin-ppml] Serious question for the list. >> >> On Thu, May 5, 2011 at 1:17 PM, David Farmer wrote: >>> On 5/5/11 11:49 CDT, Mike Burns wrote: >>>> >>>> Hi all, >>>> I have had an idea. >>>> Since it has been determined that everybody in the ARIN community >> with >>>> an email address may participate in policy development, how does the >>>> list feel about soliciting the input from a broader group of >> participants? >>> >>> While not an absolute requirement, I believe there is an understanding >> that >>> some minimal level of technical expertise and interest in the details >> of >>> the subject matter are necessary in order to provide useful or >> meaningful >>> contribution to the process. >>> >> >> >> So we would exclude members of the general public (users) then? >> > > Nope, we wouldn't exclude members of the general public, we would just bore them to death. +11111111111 :) (laughing until I can't breath anymore) -- =============================================== 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 warren at wholesaleinternet.com Thu May 5 13:58:17 2011 From: warren at wholesaleinternet.com (Warren Johnson) Date: Thu, 5 May 2011 12:58:17 -0500 Subject: [arin-ppml] ARIN-prop-146 Clarify Justified Need for Transfers In-Reply-To: <3E874CBF-24C5-4481-A52F-7F8BE64F27C9@delong.com> References: <4DBEF120.4080901@arin.net> <88F39B20-5C20-45F0-AD61-5FA1E7F84CE3@delong.com> <3FCD1FDC-ECEE-4C9B-95C6-59E03D3C314E@matthew.at> <5598DFC7-E320-42FA-AA0E-C91C076BD725@delong.com> <6BA1EAA6-7D9C-44F9-BED7-884720F4B3BE@matthew.at> <05FAA29B-37BE-411C-95A4-50437602C8ED@delong.com> <4DBF6727.1090303@matthew.at> <097AAC1C-1F68-4820-9274-3290ADEFA195@delong.com> <4DBF75B7.3010407@matthew.at> <9501EA7E-FDAD-4DDA-B9E8-08C2811FF642@delong.com> <4DBF82F6.7050608@matthew.at> <20110503145144.N15967@mail.inlandnet.com> <4DC084E7.5000302@matthew.at> <4DC08664.4060905@matthew.at> <4791A59E-8864-483C-9BB0-03A6A5B8D50C@delong.com> <66466F57-4365-4ADB-94EB-E023F01B17CB@delong.com> <30D12BA8-9A6C-4E62-9A67-8B4FEA0EA8C1@matthew.at> <00af01cc0aa7$845a5330$8d0ef990$@net> <3E874CBF-24C5-4481-A52F-7F8BE64F27C9@delong.com> Message-ID: <04eb01cc0b4e$04477bd0$0cd67370$@com> > > Based on the fact that you call it "petrol," i'll assume you're not in > the United States. My trips to the gas station take about < 5 minutes. > I would call that a testament to the free market. > >As near as I can tell based on significant travel, gasoline or petrol >>prices are quite artificially low in the united States compared to the >rest of the world. I don't actually know why that is, but, I would say >that the energy companies in the US are some of the best examples >of free market dysfunction that are available. If you don't know WHY they are artificially low, then you can't rightly make the conclusion that they ARE "artificially" low. >My trips to the gas station take between 5 and 45 minutes, depending >on the length of the line. The price of gasoline fluctuates randomly >and is obviously detached from the realities of the costs of the raw >materials. The price only drops significantly after it has risen so much >so rapidly that there is public outcry and congress starts to seriously >consider additional regulation of the industry. Then it drops just enough >to silence the cries for regulation. They are not "detached" from the price of the raw material. There are simply more factors that adjust the cost like supply, demand, speculation, refining, which way the wind blows and the color of the fairies in the Wizard of Oz. > But in all fairness, all governments have their hands in the cookie > jar. Your government more so from what I can tell. > >There are a number of possible explanations outside of the government's >hand in the cookie jar for the disparity in experiences at the gas pump. I agree. One thing is for sure, someone is making a lot of money and that can't just be supply and demand. -------------- next part -------------- A non-text attachment was scrubbed... Name: winmail.dat Type: application/ms-tnef Size: 3006 bytes Desc: not available URL: From warren at wholesaleinternet.com Thu May 5 14:00:44 2011 From: warren at wholesaleinternet.com (Warren Johnson) Date: Thu, 5 May 2011 13:00:44 -0500 Subject: [arin-ppml] Serious question for the list. In-Reply-To: <723D48A257C34BA0BD60F16130F4844F@mike> References: <723D48A257C34BA0BD60F16130F4844F@mike> Message-ID: <04ef01cc0b4e$5ba2c3d0$12e84b70$@com> Bad idea. You want a lot of non-technical people who don't even know what an IP is flooding this list? From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Mike Burns Sent: Thursday, May 05, 2011 11:50 AM To: arin-ppml at arin.net Subject: [arin-ppml] Serious question for the list. Hi all, I have had an idea. Since it has been determined that everybody in the ARIN community with an email address may participate in policy development, how does the list feel about soliciting the input from a broader group of participants? Suppose I posted to a site like Reason magazine, which is Libertarian, inviting people to join the ARIN ppml in order to support my proposal to end needs requirements for IPv4 transfers? And those who oppose could post to HuffPo or some other site where opposing views might be expected to be courted. Is this a horrible idea? I have not acted on it, there could be large implications. What are your thoughts? Regards, Mike Burns -------------- next part -------------- A non-text attachment was scrubbed... Name: winmail.dat Type: application/ms-tnef Size: 6670 bytes Desc: not available URL: From tedm at ipinc.net Thu May 5 14:01:45 2011 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Thu, 05 May 2011 11:01:45 -0700 Subject: [arin-ppml] Serious question for the list. In-Reply-To: References: <723D48A257C34BA0BD60F16130F4844F@mike> Message-ID: <4DC2E609.6070006@ipinc.net> On 5/5/2011 10:07 AM, Jeffrey Lyon wrote: > On Thu, May 5, 2011 at 12:49 PM, Mike Burns wrote: >> Hi all, >> >> I have had an idea. >> >> Since it has been determined that everybody in the ARIN community with an >> email address may participate in policy development, how does the list feel >> about soliciting the input from a broader group of participants? >> >> Suppose I posted to a site like Reason magazine, which is Libertarian, >> inviting people to join the ARIN ppml in order to support my proposal to end >> needs requirements for IPv4 transfers? >> >> And those who oppose could post to HuffPo or some other site where opposing >> views might be expected to be courted. >> >> Is this a horrible idea? >> >> I have not acted on it, there could be large implications. >> >> What are your thoughts? >> >> Regards, >> >> Mike Burns >> >> >> _______________________________________________ >> 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. >> > > Mike, > > I dislike the idea. PPML is compromised primarily of the olde guard > that seems intent upon blocking any efforts to commercialize > registration services. You can't commercialize something that is not a limited resource. clean water is a limited resource oil is a limited resource IPv4 is a limited resource air is not a limited resource IPv6 is not a limited resource. Any attempt to allow commercialization and you would find the commercial entities would only be interested in IPv4 resources. I own a business, trust me, I would never get involved in commercialization of IPv6 registrations. There's just no money in it. And to have IP addressing where half of it is commercial and half is not commercial would be extremely confusing. Worse, because the commercial entites would want to continue to support the artificial scarcity of IPv4 and not see their market disintegrated by IPv6, they would advertise to the general public about how IPv4 numbers were better, more compatible, than IPv6 and we would likely end up causing huge problems for the Internet. You would end up with regions like ARIN mostly IPv4 and the rest of the world (which has far greater demands for additional IP addressing) going to IPv6. You might as well put a fence around the United States if that were to happen. You would also have tremendous pressure from commercial entities to lower the minimum block size because they would make more money renting smaller blocks of numbers than larger blocks of numbers and the DFZ would explode out of control. > Even with substantial support, at this point it > seems those who are actually in charge of voting on policy would block > these attempts until (in an extreme case) they're completely voted out > of office. Even with AC support, there has to be concurrence within > the Board of Trustees. > Vote all of them out of office, I guarantee that when the new ones come in after about 3 months they will see it my way, and not your way, and you will be right back to where you started. This is one area where the Olde Guard has it right. And with the disaster of commercialization of the DNS system as an example, the RIR system will never go that way now. (if you don't think DNS naming is a disaster, look at the proliferation of TLD's and example of abusers like Domain Registry of America which has been sued multiple times and is still to this day engaged in deceptive advertising) > You can, however, use your own resources to create a grassroots > campaign for supporters of this idea (for which I am one, as you're > aware) to voice their opinions to ARIN and the PPML. Even better, you > could run for office. > I think it would be better if YOU were to run and be elected and serve. Once you had some real responsibility for the numbering you might grow up and quit wasting your brainpower on these sorts of unworkable proposals. Ted > My immediate focus is on a recent proposal that would the specified > transfer process more palatable. > http://lists.arin.net/pipermail/arin-ppml/2011-May/021419.html . I > made the suggestion that the justified need be extended to 36 months, > which hopefully will gain traction. > > Best regards, From mike at nationwideinc.com Thu May 5 14:02:19 2011 From: mike at nationwideinc.com (Mike Burns) Date: Thu, 5 May 2011 14:02:19 -0400 Subject: [arin-ppml] Serious question for the list. References: <723D48A257C34BA0BD60F16130F4844F@mike> <4DC2DB9B.2020908@umn.edu> <4DC2E22A.50708@umn.edu> Message-ID: It seems to me that the decision about needs analysis for transfers may have some large non-technical components, like one's view of the role of markets in allocating scarce resources. Yes, there are issues of deaggregation, which are too technical for the layman. Yes, there is a danger of overburdening the policy development system, not something anyone would want. But do we want a technical elite making decisions that are not really technical, like the value of unrestricted versus restricted markets? Are we inside an ivory tower? Regards, Mike ----- Original Message ----- From: "David Farmer" To: "Martin Hannigan" Cc: "Mike Burns" ; ; "David Farmer" Sent: Thursday, May 05, 2011 1:45 PM Subject: Re: [arin-ppml] Serious question for the list. > On 5/5/11 12:25 CDT, Martin Hannigan wrote: >> On Thu, May 5, 2011 at 1:17 PM, David Farmer wrote: >>> On 5/5/11 11:49 CDT, Mike Burns wrote: >>>> >>>> Hi all, >>>> I have had an idea. >>>> Since it has been determined that everybody in the ARIN community with >>>> an email address may participate in policy development, how does the >>>> list feel about soliciting the input from a broader group of >>>> participants? >>> >>> While not an absolute requirement, I believe there is an understanding >>> that >>> some minimal level of technical expertise and interest in the details >>> of >>> the subject matter are necessary in order to provide useful or >>> meaningful >>> contribution to the process. >>> >> >> So we would exclude members of the general public (users) then? > > Where did I say exclude? "not an absolute requirement", an "interest in > the details" are needed for a "meaningful contribution". None of that > means exclude in my book, it simply means that participation takes effort > and if you want people to take you seriously you need to make a effort. > That is true in many parts of civil society. > > -- > =============================================== > 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 jeffrey.lyon at blacklotus.net Thu May 5 14:05:29 2011 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Thu, 5 May 2011 14:05:29 -0400 Subject: [arin-ppml] ARIN-prop-146 Clarify Justified Need for Transfers In-Reply-To: <04eb01cc0b4e$04477bd0$0cd67370$@com> References: <4DBEF120.4080901@arin.net> <88F39B20-5C20-45F0-AD61-5FA1E7F84CE3@delong.com> <3FCD1FDC-ECEE-4C9B-95C6-59E03D3C314E@matthew.at> <5598DFC7-E320-42FA-AA0E-C91C076BD725@delong.com> <6BA1EAA6-7D9C-44F9-BED7-884720F4B3BE@matthew.at> <05FAA29B-37BE-411C-95A4-50437602C8ED@delong.com> <4DBF6727.1090303@matthew.at> <097AAC1C-1F68-4820-9274-3290ADEFA195@delong.com> <4DBF75B7.3010407@matthew.at> <9501EA7E-FDAD-4DDA-B9E8-08C2811FF642@delong.com> <4DBF82F6.7050608@matthew.at> <20110503145144.N15967@mail.inlandnet.com> <4DC084E7.5000302@matthew.at> <4DC08664.4060905@matthew.at> <4791A59E-8864-483C-9BB0-03A6A5B8D50C@delong.com> <66466F57-4365-4ADB-94EB-E023F01B17CB@delong.com> <30D12BA8-9A6C-4E62-9A67-8B4FEA0EA8C1@matthew.at> <00af01cc0aa7$845a5330$8d0ef990$@net> <3E874CBF-24C5-4481-A52F-7F8BE64F27C9@delong.com> <04eb01cc0b4e$04477bd0$0cd67370$@com> Message-ID: On Thu, May 5, 2011 at 1:58 PM, Warren Johnson wrote: >> >> Based on the fact that you call it "petrol," i'll assume you're not in >> the United States. My trips to the gas station take about < 5 minutes. >> I would call that a testament to the free market. >> >>As near as I can tell based on significant travel, gasoline or petrol >>>prices are quite artificially low in the united States compared to the >>rest of the world. I don't actually know why that is, but, I would say >>that the energy companies in the US are some of the best examples >>of free market dysfunction that are available. > > If you don't know WHY they are artificially low, then you can't rightly make > the conclusion that they ARE "artificially" low. > > >>My trips to the gas station take between 5 and 45 minutes, depending >>on the length of the line. The price of gasoline fluctuates randomly >>and is obviously ?detached from the realities of the costs of the raw >>materials. The price only drops significantly after it has risen so much >>so rapidly that there is public outcry and congress starts to seriously >>consider additional regulation of the industry. Then it drops just enough >>to silence the cries for regulation. > > > They are not "detached" from the price of the raw material. There are simply > more factors that adjust the cost like supply, demand, speculation, > refining, which way the wind blows and the color of the fairies in the > Wizard of Oz. > > >> But in all fairness, all governments have their hands in the cookie >> jar. Your government more so from what I can tell. >> >>There are a number of possible explanations outside of the government's >>hand in the cookie jar for the disparity in experiences at the gas pump. > > I agree. ?One thing is for sure, someone is making a lot of money and that > can't just be supply and demand. > > > > > _______________________________________________ > 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 recall reading that the oil company profits are equal to about $0.20 - 0.30/gal. < 10% net margin isn't really anything to become upset about. Congressional regulation has never actually fixed anything. I'll try to bring this back on topic by saying that some people genuinely believe that regulation is good and have other related left leaning ideologies. That's fine. My intent is not to dissuade you from those opinions or to spark political debate on the PPML. -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications - AS32421 First and Leading in DDoS Protection Solutions From owen at delong.com Thu May 5 14:04:46 2011 From: owen at delong.com (Owen DeLong) Date: Thu, 5 May 2011 11:04:46 -0700 Subject: [arin-ppml] Fw: Accusationof fundamentalconflictofinterest/IPaddress policypitched directly to ICANN In-Reply-To: <4BEDC361E6D04A7292F5A294FA4FC2FE@mike> References: <379DB08FB5564ED88230C1B6D6AE80FE@mike> <8695009A81378E48879980039EEDAD289D0E5BC6@MAIL1.polartel.local> <6B65D21B9B7543208304CC44EDD22444@mike> <3DA6DC8B-ADC6-4BCB-83BA-5F07BC5682C7@delong.com> <9D762F7D6FE3419790C6E47F58A1D4D5@mike> <4BEDC361E6D04A7292F5A294FA4FC2FE@mike> Message-ID: <197A4DE3-3155-4411-B5EE-7A0A74D05A4A@delong.com> On May 5, 2011, at 7:04 AM, Mike Burns wrote: > Hi Owen, answers in italics > Now, if you mentioned the judiciary, you might have a point, but, you did not. You chose > the governor. > > Small case "g" governor, see how semantic this can get. I think with your response, my concept is clear. > If you pretend I mentioned judiciary, then maybe you can sense that what I am trying to say is that it can be argued either way in terms of authority. > And that argument is boring. I don't think the authority structure is as clear as you describe. Or as I conceive it. > Could be that is uniquely murky, and seems to be in the midst of transition away from US government control, in any case, leading to further murkiness. I was not intending or considering that Governor vs. governor was significant to the discussion. There is no parallel to the judiciary in the IP number resource policy world. Perhaps there should be, but, as it currently stands, there is not. > > > > > No, it proffers one possible set of requirements which could be used to do so. > That is (and was) my point. Other than the author, there is no reliable evidence > that anyone has reviewed or accepted this as the way such a thing should > be done, let alone the way they would be done if such a structure were to be > created. > > OK, we can read the letter. It's pretty clear it's a proposed (not ratified) set of standards for private ip registries, based on those existing for DNS registries. > I never said it was reviewed or accepted, just that Benson's proposals lacked these kinds of regulations on new registry entities. > I don't pretend to know what would happen if the author of the letter's proposals were accepted, and the Board of ICANN decided to implement them. > My suspicion is that they would somehow become policy, though through what mechanism, I don't know. I agree that the lack of these specifications was one of the shortcomings of Benson's proposals. For them to become policy, they would have to go through the global policy development process. That is the only currently defined mechanism for the creation of IANA level policy. That has been my point from the beginning. I realize it is an answer you don't like to hear, but, it really is the true and correct answer. >>> >>> I just skimmed it, but if the community decided that Benson's proposals suffered only from a lack of oversight, and required action at a global level, then perhaps they will add their voice to the support which I offered. >>> >> Perhaps, but, you would still need a global policy proposal to voice support for. >> >> Unless ICANN board actually does make the decision they are being asked to make. The link above is policy proposal on the ICANN correspondence page, and it is referenced in this letter: >> http://www.icann.org/en/correspondence/holtzman-to-olive-02mar11-en.pdf providing reasons for requesting the decision at the ICANN board level. Based on the appeal to the authority of the DoC contract, I expect there could be a further appeal to the DoC or NTIA level if the ICANN board decides not to make a decision. It is interesting that ICANN requested information from ARIN instead of summarily dismissing the request as coming outside of policy. ARIN's reply to ICANN is on the same site. >> > I cannot see any correspondence that shows ICANN board requesting information from ARIN that was done after ICANN received this letter. > Can you point to a link to such? > > Here is the sequence > http://icann.org/en/correspondence/holtzman-to-beckstrom-27jan11-en.pdf T > This was a letter of complaint to ICANN and a request for an appeal at the ICANN level based on authority derived from the DoC contract. > > http://icann.org/en/correspondence/beckstrom-to-curran-01mar11-en.pdf > This is the letter from ICANN to ARIN which requests more information instead of summarily dismissing the request as coming outside of normal policy development channels. > > http://icann.org/en/correspondence/curran-to-beckstrom-02mar11-en.pdf > This is John Curran's reply to ICANN > > http://icann.org/en/correspondence/holtzman-to-olive-02mar11-en.pdf > This is the letter which includes the proposed regulations on new registries. > I'm pretty sure that's the flow. A request last year from Depository to ARIN for bulk whois data in order to provide directory services. > ARIN denies it and says it violates the AUP, it's not a valid purpose for bulk access. > Then the letters above start, the first one is an appeal to ICANN, which I took as a means of going over ARIN's head, although such talk of levels is like a verbal Escher drawing, apparently. > You seem certain that ICANN both won't and can't make this decision and make it apply to ARIN's sharing of whois data. I'm not so sanguine. > I think courts seem more likely to deal with contracts then Memorandums and Agreements of Understanding. > My guess, and I'm not a lawyer, is that should push come to shove in a legal arena, the courts may decide that the authority comes from the DoC contract. > It could be as you say, that ICANN has no authority to dictate anything to ARIN; the letters say there is no contract between ARIN and ICANN. > Just a guess, and I could be wrong. If it turns out that ICANN either can't or won't make the decision, as John points out in his letter, (or maybe elsewhere) that there remains the ability to change the global policy which specifies regional registry properties which he believes preclude private registries. Perhaps ICANN has power to make those changes, and the ARIN MoU would then require ARIN to submit? > Yes, the first letter is an appeal to ICANN to override ARIN's decision about ARIN's implementation of ARIN's bulk whois policy. It is not clear that ICANN has any such ability, but, I suspect that ARIN will probably cooperate with ICANN in clarifying any misunderstandings about the ARIN bulk whois policy. If it is somehow agreed that ARIN did not act according to their own policy, I suspect ARIN will modify their behavior accordingly until such time as the policy is changed either by the emergency authority of the BoT or by the community. There is no contract between ICANN and ARIN that would force ARIN to do ICANN's bidding, so, I'm not sure what your statement about courts giving preference to contracts is intended to accomplish. I'm not a lawyer, either, but I suspect that the courts may well decide that authority comes from the DoC contract. The question, however, is authority over what. The DoC contract only specifies the IANA function as it relates to IP addresses to my understanding. The IANA function in this regard is to delegate large blocks of IP addresses to the RIRs, to keep track of those allocations, and to manage the in-addr.arpa zone accordingly. IANA doesn't even operate a whois server to the best of my knowledge. There's no contract stating that IANA retains any authority over addresses once they have been issued to RIRs or any authority over the behavior of the RIRs. The ability to change the global policy is specified in the global policy development process. It might be worth considering the following from the MoU between the RIRs and ICANN: 5. Global Policy Development Process Global policies are defined within the scope of this agreement as Internet number resource policies that have the agreement of all RIRs according to their policy development processes and ICANN, and require specific actions or outcomes on the part of IANA or any other external ICANN-related body in order to be implemented. Global policies will be developed in the context of this agreement, according to the processes defined by attachment A to this MoU. Under this agreement the ICANN Board will ratify proposed global policies in accordance with the Global Policy Development Process, using review procedures as determined by ICANN. ICANN will publish these procedures no later than ninety (90) days from the date of the signature of this agreement by all parties. 6. Service Regions The regions serviced by each RIR shall be defined by the RIRs in a manner of their choosing. The NRO shall ensure that all possible service areas are encompassed. 7. Arbitration In the event that the NRO is in dispute with ICANN relating to activities described in this MoU, the NRO shall arrange arbitration via ICC rules in the jurisdiction of Bermuda or such other location as is agreed between the NRO and ICANN. The location of the arbitration shall not decide the laws to be applied in evaluating this agreement or such dispute. As you can see from the above text: 1. Global policies require the agreement of all RIRs according to their policy development processes _AND_ ICANN. 2. Global policies are developed according to the processes defined by attachment A (at the bottom of the same web page): Worth noting especially are paragraphs 2, 3, and 4 which define the way that the text emerges from the collective policy processes of the five RIRs and their communities. For reference, the NRO NC is comprised of the elected representatives from each of the RIR regions. They are elected by the communities of those regions. The NRO EC is comprised of the 5 RIR CEOs. The ASO AC is comprised of the NRO NC and is essentially synonymous with the NRO NC. Paragraphs 5 and 6 define the way the ASO AC reviews the process and ratifies the policy proposal (or not). Paragraph 7 specifies that the ASO AC forwards a ratified proposal to the ICANN board. Paragraphs 8-10 govern the ICANN board's actions with respect to a proposal which has completed paragraph 7. Note that there is a strong bias built in to this step towards accept and that rejection requires a supermajority (2/3rds) of the ICANN board. In other words, there is a global policy development process. That process was agreed to by the RIRs _AND_ ICANN in the MoU. The policy is designed to clearly ensure that the global policy process is governed by the collective agreement of the RIR communities. There is no provision for appeal outside of this process to create or change global policies. > > >Proper stewardship is to make policy that will increase the supply of addresses and bring down their price, while increasing whois reliability and removing the biggest distinction between legacy and >non-legacy addresses. > >In general, I would agree with you about the goals of proper stewardship. Obviously, I do not > >think that is the effect competing registries would have. > > Maybe I have found an appealing argument in the idea that increasing supply will reduce price. Since in a post-exhaust world, even those with need will have to pay for IP addresses, maybe the best stewardship is the policy which will lead to the lowest price? Should frame the debate in that way? Which policies should be implemented which will create the greatest supply to replace the free pool, in order that price be driven down? Which types of markets lead to lowest prices, those with fewer regulations or those with more regulations? Is low price to be desired by the proper steward? Now we are stewards of the rules and not the addresses. > Since I believe that a free market is open to speculators and speculators only serve to increase the price, it is hard to say that a completely free market would reduce price. Additionally, there is a dichotomy in the particular market scenario in question in that increased price will likely lead to increased supply (to some extent) and increased supply _MIGHT_ lead to decreased price. I suspect for the latter to be true, it would require a vastly increased supply which will not be possible until IPv4 addresses are largely irrelevant, at which time they will again be readily available anyway. > > >> Are you accusing the APNIC community of abandoning stewardship, and if they did, why do you think they did that? Is the region largely peopled by IPv4 profiteers? >> > >Yes. I believe that the transfer policy in the APNIC region was an abandonment of their > >stewardship role and I have said as much on their policy development mailing list. > >Why? Because Geoff Huston and a few other leaders in that community pushed long > >and hard to get that position adopted mainly by creating fear that failing to do so would > >render all RIR policy meaningless because the RIR policy would simply be bypassed > >in favor of people doing what they wanted anyway. > > >Personally, I think that argument is absurd. Making theft legal just because you can't > >stop people from stealing makes no sense to me. > > Well, that information leads me to discount the deaggregation argument against removing need requirements. > I consider Geoff Huston to be en expert on BGP tables and defer to his judgement here. > Clearly he did not see the risk of BGP table growth as a cause to retain needs requirements. > I hope the ARIN community can take away the idea that it is not just a few IPv4 profiteers who have different visions of stewardship. Quite the contrary... You should listen to or read Geoff's entire argument before drawing such (IMHO erroneous) conclusions about his statements. Geoff has recognized that a market will create aggregation concerns in the BGP tables. However, his argument is that these are inevitable and the RIRs refusing to recognize transfers in whois will not reduce them. Obviously I don't completely agree with him that the number of transfers taking place will not or can not be reduced by RIR policy. Geoff's theory is that all policy can accomplish is to prevent the transfers from being visible in whois. My belief is that most organizations will choose to play by the rules and will not want space that is not visible in whois. Further that most ISPs (at least the majority of the very large ones) will actually consider whois registrations in the process of deciding what is or is not an acceptable prefix to route for a given customer. Obviously, Geoff and I disagree on this matter. However, we both agree that transfers are and will be detrimental to the BGP table. Owen -------------- next part -------------- An HTML attachment was scrubbed... URL: From ebw at abenaki.wabanaki.net Thu May 5 14:07:32 2011 From: ebw at abenaki.wabanaki.net (Eric Brunner-Williams) Date: Thu, 05 May 2011 14:07:32 -0400 Subject: [arin-ppml] Fw: Accusationof fundamentalconflictofinterest/IPaddress policypitched directly to ICANN In-Reply-To: References: <379DB08FB5564ED88230C1B6D6AE80FE@mike> <8695009A81378E48879980039EEDAD289D0E5BC6@MAIL1.polartel.local> <6B65D21B9B7543208304CC44EDD22444@mike> <3DA6DC8B-ADC6-4BCB-83BA-5F07BC5682C7@delong.com> <4A4FE574E42F4C64A2A498A6A1FF89F2@mike> Message-ID: <4DC2E764.6030803@abenaki.wabanaki.net> > ... > Apropos nothing, I wonder if the NRO is mature enough to take over the > IANA function from ICANN entirely, including the funding. ... a recommendation of that form was made in response to the recent notice of inquiry. of course, recommendations that the set of functions remain within a single contract, executed by the incumbent, were also made in response to the same notice of inquiry. different subject line please. From jeffrey.lyon at blacklotus.net Thu May 5 14:10:28 2011 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Thu, 5 May 2011 14:10:28 -0400 Subject: [arin-ppml] Serious question for the list. In-Reply-To: <4DC2E609.6070006@ipinc.net> References: <723D48A257C34BA0BD60F16130F4844F@mike> <4DC2E609.6070006@ipinc.net> Message-ID: > I think it would be better if YOU were to run and be elected and > serve. ?Once you had some real responsibility for the numbering you > might grow up and quit wasting your brainpower on these sorts of > unworkable proposals. > > Ted Ted, I don't feel the personal attack is warranted. I'm merely furthering discussion and expressing opinions, hopefully without attacking anyone as an individual. I'm certain that the majority of us here have a lot of experience with significant amounts of responsibility, albeit in various fields. Your experience is not necessarily better than my experience, or vice versa. Please also note that I have not made any proposals, i've been stopping short at voicing support for proposals of others and testing the waters on new ideas. Best regards, -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications - AS32421 First and Leading in DDoS Protection Solutions From owen at delong.com Thu May 5 14:08:09 2011 From: owen at delong.com (Owen DeLong) Date: Thu, 5 May 2011 11:08:09 -0700 Subject: [arin-ppml] ARIN-prop-146 Clarify Justified Need for Transfers In-Reply-To: <43F39974056A419E9E68A7B2219B04A4@mike> References: <4DBEF120.4080901@arin.net><88F39B20-5C20-45F0-AD61-5FA1E7F84CE3@delong.com><3FCD1FDC-ECEE-4C9B-95C6-59E03D3C314E@mat 5A4-50437602C8ED@delong.com><4DBF6727.1090303@matthew.at><097AAC1C-1F68-4820-9274-3290ADEFA195@delong.com><4DBF75B7.3010407@mat thew.at><9501EA7E-FDAD-4DDA-B9E8-08C2811FF642@delong.com><4DBF82F6.7050608@matthew.at><20110503145144.N15967@mail.inlandnet.com><4DC084E7.5000302@matthew.at> <4DC08664.4060905@matthew.at><4791A59E-8864-483C-9BB0-03A6A5B8D50C@delong.com> <66466F57-4365-4ADB-94EB-E023F01B17CB@delong.com><30D12BA8-9A6C-4E62-9A67-8B4FEA0EA8C1@matthew.at><00af01cc0aa7$845a5330$8d0ef990$@net> <43F39974056A419E9E68A7B2219B04A4@mike> Message-ID: On May 5, 2011, at 7:12 AM, Mike Burns wrote: > Speculators can buy addresses now, but ipv4trading.com doesn't seem awash in them. Not under current policy. They would have to be going outside of policy to do so as it currently stands. It is early. There are still RIR free pools. > Speculators can buy legacy addresses now, too. Again, not within the bounds of policy. > Speculators and market-cornerers are naturally bound by the existence of IPv6. True, but, this bound may be quite high compared to the price at which IPv4 addresses would be available to legitimate users without speculators. There are also worse possibilities than speculators. Imagine anti-competitive purchases of vast amounts of IP addresses by large organizations wanting to gain a competitive advantage over much smaller providers where service areas overlap. > If they drive the price above transition cost, they will kill their own golden goose. > Maybe this fear of speculators, of whom there is no evidence, is not justified. > I don't fear speculators, I oppose them. I do, to a certain extent, fear anticompetitive purchases and I oppose them, too. True, none of these things has materialized yet. Perhaps this is an indication that the current policy is working to prevent them. However, I do not believe it is a good reason to change policy to enable them. Owen > Regards, > Mike > > > > ----- Original Message ----- From: "McTim" > To: "Jeffrey Lyon" > Cc: "Warren Johnson" ; > Sent: Thursday, May 05, 2011 9:16 AM > Subject: Re: [arin-ppml] ARIN-prop-146 Clarify Justified Need for Transfers > > > On Thu, May 5, 2011 at 1:24 PM, Jeffrey Lyon > wrote: > >> >> Based on the fact that you call it "petrol," i'll assume you're not in >> the United States. My trips to the gas station take about < 5 minutes. >> I would call that a testament to the free market. > > > I guess you aren't old enough to remember long lines and rationing in the USA. > >> >> But in all fairness, all governments have their hands in the cookie >> jar. Your government more so from what I can tell. > > The current petrol shortage here has little to do with gov't and > everything to do with speculators buying stocks of fuel, despite them > having no retail outlets. > > See any resemblance to IP addressing? > > -- > Cheers, > > McTim > "A name indicates what we seek. An address indicates where it is. A > route indicates how we get there." Jon Postel > _______________________________________________ > 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 john.sweeting at twcable.com Thu May 5 14:12:14 2011 From: john.sweeting at twcable.com (Sweeting, John) Date: Thu, 5 May 2011 14:12:14 -0400 Subject: [arin-ppml] ARIN-prop-146 Clarify Justified Need for Transfers In-Reply-To: <3E874CBF-24C5-4481-A52F-7F8BE64F27C9@delong.com> Message-ID: A large percentage of the price of a gallon of gas is attributable to Speculators, companies that never even take ownership of the oil, they just buy it and sell before it is even shipped. +++ On 5/5/11 1:24 PM, "Owen DeLong" wrote: > > Based on the fact that you call it "petrol," i'll assume you're not in > the United States. My trips to the gas station take about < 5 minutes. > I would call that a testament to the free market. > As near as I can tell based on significant travel, gasoline or petrol prices are quite artificially low in the united States compared to the rest of the world. I don't actually know why that is, but, I would say that the energy companies in the US are some of the best examples of free market dysfunction that are available. My trips to the gas station take between 5 and 45 minutes, depending on the length of the line. The price of gasoline fluctuates randomly and is obviously detached from the realities of the costs of the raw materials. The price only drops significantly after it has risen so much so rapidly that there is public outcry and congress starts to seriously consider additional regulation of the industry. Then it drops just enough to silence the cries for regulation. > But in all fairness, all governments have their hands in the cookie > jar. Your government more so from what I can tell. > There are a number of possible explanations outside of the government's hand in the cookie jar for the disparity in experiences at the gas pump. 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. ________________________________ This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. From mike at nationwideinc.com Thu May 5 14:20:29 2011 From: mike at nationwideinc.com (Mike Burns) Date: Thu, 5 May 2011 14:20:29 -0400 Subject: [arin-ppml] Fw: Accusationof fundamentalconflictofinterest/IPaddress policypitched directly to ICANN References: <379DB08FB5564ED88230C1B6D6AE80FE@mike> <8695009A81378E48879980039EEDAD289D0E5BC6@MAIL1.polartel.local> <6B65D21B9B7543208304CC44EDD22444@mike> <3DA6DC8B-ADC6-4BCB-83BA-5F07BC5682C7@delong.com> <9D762F7D6FE3419790C6E47F58A1D4D5@mike> <4BEDC361E6D04A7292F5A294FA4FC2FE@mike> <197A4DE3-3155-4411-B5EE-7A0A74D05A4A@delong.com> Message-ID: Hi Owen Well, that information leads me to discount the deaggregation argument against removing need requirements. I consider Geoff Huston to be en expert on BGP tables and defer to his judgement here. Clearly he did not see the risk of BGP table growth as a cause to retain needs requirements. I hope the ARIN community can take away the idea that it is not just a few IPv4 profiteers who have different visions of stewardship. Quite the contrary... You should listen to or read Geoff's entire argument before drawing such (IMHO erroneous) conclusions about his statements. Geoff has recognized that a market will create aggregation concerns in the BGP tables. However, his argument is that these are inevitable and the RIRs refusing to recognize transfers in whois will not reduce them. Obviously I don't completely agree with him that the number of transfers taking place will not or can not be reduced by RIR policy. Geoff's theory is that all policy can accomplish is to prevent the transfers from being visible in whois. My belief is that most organizations will choose to play by the rules and will not want space that is not visible in whois. Further that most ISPs (at least the majority of the very large ones) will actually consider whois registrations in the process of deciding what is or is not an acceptable prefix to route for a given customer. Obviously, Geoff and I disagree on this matter. However, we both agree that transfers are and will be detrimental to the BGP table. Owen What I wrote is that Geoff does not see the risk of increased BGP table growth as a cause to retain needs requirements. I think that is accurate. Regards, Mike -------------- next part -------------- An HTML attachment was scrubbed... URL: From jeffrey.lyon at blacklotus.net Thu May 5 14:18:16 2011 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Thu, 5 May 2011 14:18:16 -0400 Subject: [arin-ppml] ARIN-prop-146 Clarify Justified Need for Transfers In-Reply-To: References: <3E874CBF-24C5-4481-A52F-7F8BE64F27C9@delong.com> Message-ID: On Thu, May 5, 2011 at 2:12 PM, Sweeting, John wrote: > A large percentage of the price of a gallon of gas is attributable to Speculators, companies that never even take ownership of the oil, they just buy it and sell before it is even shipped. > It's a gamble. Derivatives markets can protect sellers or they can protect buyers. A forward contract for delivery in 3 months at $110/barrel might allow the buyer to take delivery at a time when the actual market price is $150/barrel, or it might result in the buyer overpaying if the market price drops to $90/barrel. Speculators have to tread cautiously to prevent from taking serious losses in doing so. Speculators are not an evil force that merely drives prices up, although this happens sometimes. Their primary benefit is to create liquidity. In an IP market, buyers and sellers could complete transactions same day, thanks to speculators. Without them, these transactions could take days, weeks, or months. -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications - AS32421 First and Leading in DDoS Protection Solutions From tedm at ipinc.net Thu May 5 14:23:18 2011 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Thu, 05 May 2011 11:23:18 -0700 Subject: [arin-ppml] Serious question for the list. In-Reply-To: References: <723D48A257C34BA0BD60F16130F4844F@mike> <4DC2DB9B.2020908@umn.edu> <4DC2E22A.50708@umn.edu> Message-ID: <4DC2EB16.4070904@ipinc.net> On 5/5/2011 11:02 AM, Mike Burns wrote: > It seems to me that the decision about needs analysis for transfers may > have some large non-technical components, like one's view of the role of > markets in allocating scarce resources. > Yes, there are issues of deaggregation, which are too technical for the > layman. > Yes, there is a danger of overburdening the policy development system, > not something anyone would want. > But do we want a technical elite making decisions that are not really > technical, like the value of unrestricted versus restricted markets? No, we do not. > Are we inside an ivory tower? > No, but there is a proper way to bring the general public into the decision making in a large volume. There isn't (in my opinion) a problem with posting in a rag like the Libertarian Times or some such, that a mailing list like ppml EXISTS. The very few members of the general public who waste their time with that stuff and who are at all competent and really care about the issue will investigate, make themselves fully aware of all of the arguments on all sides of the issue, as well as look up the rules for the ppml list (which I will remind everyone, ARIN owns and makes the rules on) then join and contribute in a positive way. But the majority of the members of the general public who waste their time with that stuff and who are NOT competent will find the bar of actually having to look up the instructions for posting and rules for joining too difficult to master, and will stay away. Unless, that is, the poster of the article in the Libertarian Times gives an explicit step-by-step set of instructions for how to go about subscribing, that a blind monkey could follow. If you really and truly want to bring people into the decision making process who are too ignorant to google up "ppml mailing list" then the proper way is via publishing a survey in the ragazine. The author of the article in the Libertarian Times can create a dumbed-down survey on someplace like survey.com or whatever, that the ignoramuses can comprehend. Then we can get the feedback from the unwashed masses without being drowned in an onslaught of 5000 fools wanting to know what an IP address is and why we can't make more of them. But, to save you the time I can predict what the general public will say in advance - boiled down: "I want what I have to stay the same and I don't give a damn if it staying the same prevents 3/4 of the people in the world who aren't on the Internet now, from ever getting on it. I got mine, Jack, and screw the rest of them." Ted > Regards, > Mike > > > > > > ----- Original Message ----- From: "David Farmer" > To: "Martin Hannigan" > Cc: "Mike Burns" ; ; "David > Farmer" > Sent: Thursday, May 05, 2011 1:45 PM > Subject: Re: [arin-ppml] Serious question for the list. > > >> On 5/5/11 12:25 CDT, Martin Hannigan wrote: >>> On Thu, May 5, 2011 at 1:17 PM, David Farmer wrote: >>>> On 5/5/11 11:49 CDT, Mike Burns wrote: >>>>> >>>>> Hi all, >>>>> I have had an idea. >>>>> Since it has been determined that everybody in the ARIN community with >>>>> an email address may participate in policy development, how does the >>>>> list feel about soliciting the input from a broader group of >>>>> participants? >>>> >>>> While not an absolute requirement, I believe there is an >>>> understanding that >>>> some minimal level of technical expertise and interest in the >>>> details of >>>> the subject matter are necessary in order to provide useful or >>>> meaningful >>>> contribution to the process. >>>> >>> >>> So we would exclude members of the general public (users) then? >> >> Where did I say exclude? "not an absolute requirement", an "interest >> in the details" are needed for a "meaningful contribution". None of >> that means exclude in my book, it simply means that participation >> takes effort and if you want people to take you seriously you need to >> make a effort. That is true in many parts of civil society. >> >> -- >> =============================================== >> 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 tedm at ipinc.net Thu May 5 14:25:16 2011 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Thu, 05 May 2011 11:25:16 -0700 Subject: [arin-ppml] Serious question for the list. In-Reply-To: References: <723D48A257C34BA0BD60F16130F4844F@mike> <4DC2E609.6070006@ipinc.net> Message-ID: <4DC2EB8C.1080407@ipinc.net> On 5/5/2011 11:10 AM, Jeffrey Lyon wrote: >> I think it would be better if YOU were to run and be elected and >> serve. Once you had some real responsibility for the numbering you >> might grow up and quit wasting your brainpower on these sorts of >> unworkable proposals. >> >> Ted > > Ted, > > I don't feel the personal attack is warranted. I didn't start the personal attack. Use of the emotionally loaded term "Olde Guard" started that. However, I WILL end it. Ted From mike at nationwideinc.com Thu May 5 14:30:21 2011 From: mike at nationwideinc.com (Mike Burns) Date: Thu, 5 May 2011 14:30:21 -0400 Subject: [arin-ppml] Serious question for the list. References: <723D48A257C34BA0BD60F16130F4844F@mike><4DC2DB9B.2020908@umn.edu> <4DC2E22A.50708@umn.edu> <4DC2EB16.4070904@ipinc.net> Message-ID: Hi Ted, Thanks for the input. I understand what you are saying about the dangers of the unwashed. What about a blog? Do you think it would be okay to advocate a position in blog and solicit participation on the list? Regards, Mike ----- Original Message ----- From: "Ted Mittelstaedt" To: Sent: Thursday, May 05, 2011 2:23 PM Subject: Re: [arin-ppml] Serious question for the list. > On 5/5/2011 11:02 AM, Mike Burns wrote: >> It seems to me that the decision about needs analysis for transfers may >> have some large non-technical components, like one's view of the role of >> markets in allocating scarce resources. >> Yes, there are issues of deaggregation, which are too technical for the >> layman. >> Yes, there is a danger of overburdening the policy development system, >> not something anyone would want. >> But do we want a technical elite making decisions that are not really >> technical, like the value of unrestricted versus restricted markets? > > No, we do not. > >> Are we inside an ivory tower? >> > > No, but there is a proper way to bring the general public into the > decision making in a large volume. > > There isn't (in my opinion) a problem with posting in a rag like > the Libertarian Times or some such, that a mailing list like ppml > EXISTS. The very few members of the general public who waste their > time with that stuff and who are at all competent and really care > about the issue will investigate, make themselves fully aware of > all of the arguments on all sides of the issue, as well as look > up the rules for the ppml list (which I will remind everyone, > ARIN owns and makes the rules on) then join and contribute in > a positive way. > > But the majority of the members of the general public who waste > their time with that stuff and who are NOT competent will find the > bar of actually having to look up the instructions for posting > and rules for joining too difficult to master, and will stay away. > > Unless, that is, the poster of the article in the Libertarian Times > gives an explicit step-by-step set of instructions for how to > go about subscribing, that a blind monkey could follow. > > If you really and truly want to bring people into the decision > making process who are too ignorant to google up "ppml mailing list" > then the proper way is via publishing a survey in the ragazine. > > The author of the article in the Libertarian Times can create a > dumbed-down survey on someplace like survey.com or whatever, that > the ignoramuses can comprehend. > > Then we can get the feedback from the unwashed masses without > being drowned in an onslaught of 5000 fools wanting to know what > an IP address is and why we can't make more of them. > > But, to save you the time I can predict what the general public > will say in advance - boiled down: > > "I want what I have to stay the same and I don't give a damn > if it staying the same prevents 3/4 of the people in the world > who aren't on the Internet now, from ever getting on it. I > got mine, Jack, and screw the rest of them." > > Ted > >> Regards, >> Mike >> >> >> >> >> >> ----- Original Message ----- From: "David Farmer" >> To: "Martin Hannigan" >> Cc: "Mike Burns" ; ; "David >> Farmer" >> Sent: Thursday, May 05, 2011 1:45 PM >> Subject: Re: [arin-ppml] Serious question for the list. >> >> >>> On 5/5/11 12:25 CDT, Martin Hannigan wrote: >>>> On Thu, May 5, 2011 at 1:17 PM, David Farmer wrote: >>>>> On 5/5/11 11:49 CDT, Mike Burns wrote: >>>>>> >>>>>> Hi all, >>>>>> I have had an idea. >>>>>> Since it has been determined that everybody in the ARIN community >>>>>> with >>>>>> an email address may participate in policy development, how does the >>>>>> list feel about soliciting the input from a broader group of >>>>>> participants? >>>>> >>>>> While not an absolute requirement, I believe there is an >>>>> understanding that >>>>> some minimal level of technical expertise and interest in the >>>>> details of >>>>> the subject matter are necessary in order to provide useful or >>>>> meaningful >>>>> contribution to the process. >>>>> >>>> >>>> So we would exclude members of the general public (users) then? >>> >>> Where did I say exclude? "not an absolute requirement", an "interest >>> in the details" are needed for a "meaningful contribution". None of >>> that means exclude in my book, it simply means that participation >>> takes effort and if you want people to take you seriously you need to >>> make a effort. That is true in many parts of civil society. >>> >>> -- >>> =============================================== >>> 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. > > _______________________________________________ > 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 5 14:32:31 2011 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Thu, 5 May 2011 14:32:31 -0400 Subject: [arin-ppml] Serious question for the list. In-Reply-To: <4DC2EB8C.1080407@ipinc.net> References: <723D48A257C34BA0BD60F16130F4844F@mike> <4DC2E609.6070006@ipinc.net> <4DC2EB8C.1080407@ipinc.net> Message-ID: On Thu, May 5, 2011 at 2:25 PM, Ted Mittelstaedt wrote: > On 5/5/2011 11:10 AM, Jeffrey Lyon wrote: >>> >>> I think it would be better if YOU were to run and be elected and >>> serve. ?Once you had some real responsibility for the numbering you >>> might grow up and quit wasting your brainpower on these sorts of >>> unworkable proposals. >>> >>> Ted >> >> Ted, >> >> I don't feel the personal attack is warranted. > > I didn't start the personal attack. ?Use of the emotionally loaded > term "Olde Guard" started that. > > However, I WILL end it. > > Ted > Ted, There was no ill intent in that term which I use in this sense: "may refer generally to a veteran or group of veterans, a conservative faction, or an older segment of a population." (source: Wikipedia). -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications - AS32421 First and Leading in DDoS Protection Solutions From owen at delong.com Thu May 5 14:33:25 2011 From: owen at delong.com (Owen DeLong) Date: Thu, 5 May 2011 11:33:25 -0700 Subject: [arin-ppml] Serious question for the list. In-Reply-To: References: <723D48A257C34BA0BD60F16130F4844F@mike> Message-ID: <830EB477-D03E-41B9-A5D7-125B957A8B29@delong.com> > > Mike, > > I dislike the idea. PPML is compromised primarily of the olde guard > that seems intent upon blocking any efforts to commercialize > registration services. Even with substantial support, at this point it > seems those who are actually in charge of voting on policy would block > these attempts until (in an extreme case) they're completely voted out > of office. Even with AC support, there has to be concurrence within > the Board of Trustees. > Huh? Who do you think is in charge of voting on policy? The members of ARIN elect the board and the AC. The AC votes on policies and if they make it past last call and the AC favors their adoption, the BoT gets a final vote on them. The AC does pay close attention to PPML and to our perceived will of the community. Yes, our perceived will of the community is a somewhat nebulous concept, but, I think that is unavoidable in a consensus-based bottom-up process. However, if the community expresses strong support for a direction contrary to the current policy, that support would definitely be considered by the AC. Owen From john.sweeting at twcable.com Thu May 5 14:38:00 2011 From: john.sweeting at twcable.com (Sweeting, John) Date: Thu, 5 May 2011 14:38:00 -0400 Subject: [arin-ppml] ARIN-prop-146 Clarify Justified Need for Transfers In-Reply-To: Message-ID: I realize that this site is probably a little one sided but not by that much, check out the site www.stopoilspeculationnow.com. It does not put a very good light on speculators. On 5/5/11 2:18 PM, "Jeffrey Lyon" wrote: On Thu, May 5, 2011 at 2:12 PM, Sweeting, John wrote: > A large percentage of the price of a gallon of gas is attributable to Speculators, companies that never even take ownership of the oil, they just buy it and sell before it is even shipped. > It's a gamble. Derivatives markets can protect sellers or they can protect buyers. A forward contract for delivery in 3 months at $110/barrel might allow the buyer to take delivery at a time when the actual market price is $150/barrel, or it might result in the buyer overpaying if the market price drops to $90/barrel. Speculators have to tread cautiously to prevent from taking serious losses in doing so. Speculators are not an evil force that merely drives prices up, although this happens sometimes. Their primary benefit is to create liquidity. In an IP market, buyers and sellers could complete transactions same day, thanks to speculators. Without them, these transactions could take days, weeks, or months. -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications - AS32421 First and Leading in DDoS Protection Solutions ________________________________ This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. From jeffrey.lyon at blacklotus.net Thu May 5 14:40:06 2011 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Thu, 5 May 2011 14:40:06 -0400 Subject: [arin-ppml] Serious question for the list. In-Reply-To: <830EB477-D03E-41B9-A5D7-125B957A8B29@delong.com> References: <723D48A257C34BA0BD60F16130F4844F@mike> <830EB477-D03E-41B9-A5D7-125B957A8B29@delong.com> Message-ID: On Thu, May 5, 2011 at 2:33 PM, Owen DeLong wrote: >> >> Mike, >> >> I dislike the idea. PPML is compromised primarily of the olde guard >> that seems intent upon blocking any efforts to commercialize >> registration services. Even with substantial support, at this point it >> seems those who are actually in charge of voting on policy would block >> these attempts until (in an extreme case) they're completely voted out >> of office. Even with AC support, there has to be concurrence within >> the Board of Trustees. >> > Huh? > > Who do you think is in charge of voting on policy? > > The members of ARIN elect the board and the AC. > > The AC votes on policies and if they make it past last call and the AC > favors their adoption, the BoT gets a final vote on them. > > The AC does pay close attention to PPML and to our perceived will > of the community. Yes, our perceived will of the community is a > somewhat nebulous concept, but, I think that is unavoidable in > a consensus-based bottom-up process. However, if the community > expresses strong support for a direction contrary to the current > policy, that support would definitely be considered by the AC. > > Owen > > Owen, This is correct, and mutually understood. The current AC perception of the Burns-Lyon ideology is that the community does not support. It would take substantial influence and discussion to change gears in that respect. A bunch of new faces popping up on PPML and supporting this idea would not change the AC perception of community support or lack thereof. Best regards, Jeff -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications - AS32421 First and Leading in DDoS Protection Solutions From owen at delong.com Thu May 5 14:35:47 2011 From: owen at delong.com (Owen DeLong) Date: Thu, 5 May 2011 11:35:47 -0700 Subject: [arin-ppml] ARIN-prop-146 Clarify Justified Need for Transfers In-Reply-To: References: <4DBEF120.4080901@arin.net> <88F39B20-5C20-45F0-AD61-5FA1E7F84CE3@delong.com> <3FCD1FDC-ECEE-4C9B-95C6-59E03D3C314E@matthew.at> <5598DFC7-E320-42FA-AA0E-C91C076BD725@delong.com> <6BA1EAA6-7D9C-44F9-BED7-884720F4B3BE@matthew.at> <05FAA29B-37BE-411C-95A4-50437602C8ED@delong.com> <4DBF6727.1090303@matthew.at> <097AAC1C-1F68-4820-9274-3290ADEFA195@delong.com> <4DBF75B7.3010407@matthew.at> <9501EA7E-FDAD-4DDA-B9E8-08C2811FF642@delong.com> <4DBF82F6.7050608@matthew.at> <20110503145144.N15967@mail.inlandnet.com> <4DC084E7.5000302@matthew.at> <4DC08664.4060905@matthew.at> <4791A59E-8864-483C-9BB0-03A6A5B8D50C@delong.com> <66466F57-4365-4ADB-94EB-E023F01B17CB@delong.com> <30D12BA8-9A6C-4E62-9A67-8B4FEA0EA8C1@matthew.at> <00af01cc0aa7$845a5330$8d0ef990$@net> Message-ID: On May 5, 2011, at 10:21 AM, Jeffrey Lyon wrote: > Response inline. > > On Thu, May 5, 2011 at 9:16 AM, McTim wrote: >> On Thu, May 5, 2011 at 1:24 PM, Jeffrey Lyon >> wrote: >> >>> >>> Based on the fact that you call it "petrol," i'll assume you're not in >>> the United States. My trips to the gas station take about < 5 minutes. >>> I would call that a testament to the free market. >> >> >> I guess you aren't old enough to remember long lines and rationing in the USA. >> > > President Nixon was also one of the biggest black eyes to the U.S. > economy to occur in the 20th century. There is less control on the > market now and we no longer have these issues. Basic supply and demand > principles ensure that no one will ever be stuck in a line waiting for > anything so long as there is minimal government regulation or > collusion. Even President Obama hasn't managed to cause this level of > economic damage. > You clearly haven't been to a grocery store in San Jose on a Saturday or Sunday evening recently. I do not believe that the checkout lines have anything to do with regulation. >> See any resemblance to IP addressing? > > Yes, I do. ARIN restricts and rations access to IP resources which > keeps prices artificially low while putting long lines on the near > horizon. Anyone who isn't satisfied with their fuel being rationed > shouldn't be satisfied with their IP space being rationed. > I was fine with the fuel rationing. I would be fine with it again if I could get my fuel for $0.79/gallon again. Owen From mike at nationwideinc.com Thu May 5 14:40:22 2011 From: mike at nationwideinc.com (Mike Burns) Date: Thu, 5 May 2011 14:40:22 -0400 Subject: [arin-ppml] ARIN-prop-146 Clarify Justified Need for Transfers References: Message-ID: >I realize that this site is probably a little one sided but not by that >much, check out the site www.stopoilspeculationnow.com. It does not put a >very good light on speculators. > Again this goes to my point about non-technical components to these decisions. Regards, Mike From john.sweeting at twcable.com Thu May 5 14:41:25 2011 From: john.sweeting at twcable.com (Sweeting, John) Date: Thu, 5 May 2011 14:41:25 -0400 Subject: [arin-ppml] Serious question for the list. In-Reply-To: <830EB477-D03E-41B9-A5D7-125B957A8B29@delong.com> Message-ID: +1 On 5/5/11 2:33 PM, "Owen DeLong" wrote: > > Mike, > > I dislike the idea. PPML is compromised primarily of the olde guard > that seems intent upon blocking any efforts to commercialize > registration services. Even with substantial support, at this point it > seems those who are actually in charge of voting on policy would block > these attempts until (in an extreme case) they're completely voted out > of office. Even with AC support, there has to be concurrence within > the Board of Trustees. > Huh? Who do you think is in charge of voting on policy? The members of ARIN elect the board and the AC. The AC votes on policies and if they make it past last call and the AC favors their adoption, the BoT gets a final vote on them. The AC does pay close attention to PPML and to our perceived will of the community. Yes, our perceived will of the community is a somewhat nebulous concept, but, I think that is unavoidable in a consensus-based bottom-up process. However, if the community expresses strong support for a direction contrary to the current policy, that support would definitely be considered by the AC. 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. ________________________________ This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. From mike at nationwideinc.com Thu May 5 14:44:20 2011 From: mike at nationwideinc.com (Mike Burns) Date: Thu, 5 May 2011 14:44:20 -0400 Subject: [arin-ppml] Serious question for the list. References: Message-ID: > The AC does pay close attention to PPML and to our perceived will > of the community. Yes, our perceived will of the community is a > somewhat nebulous concept, but, I think that is unavoidable in > a consensus-based bottom-up process. However, if the community > expresses strong support for a direction contrary to the current > policy, that support would definitely be considered by the AC. > > Owen > Would the AC give more weight to expressions of support from long term list members than from newcomers? Regards, Mike From jeffrey.lyon at blacklotus.net Thu May 5 14:45:22 2011 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Thu, 5 May 2011 14:45:22 -0400 Subject: [arin-ppml] ARIN-prop-146 Clarify Justified Need for Transfers In-Reply-To: References: <4DBEF120.4080901@arin.net> <88F39B20-5C20-45F0-AD61-5FA1E7F84CE3@delong.com> <3FCD1FDC-ECEE-4C9B-95C6-59E03D3C314E@matthew.at> <5598DFC7-E320-42FA-AA0E-C91C076BD725@delong.com> <6BA1EAA6-7D9C-44F9-BED7-884720F4B3BE@matthew.at> <05FAA29B-37BE-411C-95A4-50437602C8ED@delong.com> <4DBF6727.1090303@matthew.at> <097AAC1C-1F68-4820-9274-3290ADEFA195@delong.com> <4DBF75B7.3010407@matthew.at> <9501EA7E-FDAD-4DDA-B9E8-08C2811FF642@delong.com> <4DBF82F6.7050608@matthew.at> <20110503145144.N15967@mail.inlandnet.com> <4DC084E7.5000302@matthew.at> <4DC08664.4060905@matthew.at> <4791A59E-8864-483C-9BB0-03A6A5B8D50C@delong.com> <66466F57-4365-4ADB-94EB-E023F01B17CB@delong.com> <30D12BA8-9A6C-4E62-9A67-8B4FEA0EA8C1@matthew.at> <00af01cc0aa7$845a5330$8d0ef990$@net> Message-ID: > I was fine with the fuel rationing. I would be fine with it again if I could > get my fuel for $0.79/gallon again. > > Owen > > Owen, Would it be fair to say that you don't support free markets and leave it alone there? I could spend all day expressing my thoughts on how horribly bad that would be, but it's not entirely relevant to PPML. I'm really not trying to attack your political values, just establish your particular flavor of bias. Thanks, -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications - AS32421 First and Leading in DDoS Protection Solutions From owen at delong.com Thu May 5 14:43:11 2011 From: owen at delong.com (Owen DeLong) Date: Thu, 5 May 2011 11:43:11 -0700 Subject: [arin-ppml] ARIN-prop-146 Clarify Justified Need for Transfers In-Reply-To: <04eb01cc0b4e$04477bd0$0cd67370$@com> References: <4DBEF120.4080901@arin.net> <88F39B20-5C20-45F0-AD61-5FA1E7F84CE3@delong.com> <3FCD1FDC-ECEE-4C9B-95C6-59E03D3C314E@matthew.at> <5598DFC7-E320-42FA-AA0E-C91C076BD725@delong.com> <6BA1EAA6-7D9C-44F9-BED7-884720F4B3BE@matthew.at> <05FAA29B-37BE-411C-95A4-50437602C8ED@delong.com> <4DBF6727.1090303@matthew.at> <097AAC1C-1F68-4820-9274-3290ADEFA195@delong.com> <4DBF75B7.3010407@matthew.at> <9501EA7E-FDAD-4DDA-B9E8-08C2811FF642@delong.com> <4DBF82F6.7050608@matthew.at> <20110503145144.N15967@mail.inlandnet.com> <4DC084E7.5000302@matthew.at> <4DC08664.4060905@matthew.at> <4791A59E-8864-483C-9BB0-03A6A5B8D50C@delong.com> <66466F57-4365-4ADB-94EB-E023F01B17CB@delong.com> <30D12BA8-9A6C-4E62-9A67-8B4FEA0EA8C1@matthew.at> <00af01cc0aa7$845a5330$8d0ef990$@net> <3E874CBF-24C5-4481-A52F-7F8BE64F27C9@delong.com> <04eb01cc0b4e$04477bd0$0cd67370$@com> Message-ID: <847E43DB-7200-46CB-8EFD-A499B356C71B@delong.com> On May 5, 2011, at 10:58 AM, Warren Johnson wrote: >> >> Based on the fact that you call it "petrol," i'll assume you're not in >> the United States. My trips to the gas station take about < 5 minutes. >> I would call that a testament to the free market. >> >> As near as I can tell based on significant travel, gasoline or petrol >>> prices are quite artificially low in the united States compared to the >> rest of the world. I don't actually know why that is, but, I would say >> that the energy companies in the US are some of the best examples >> of free market dysfunction that are available. > > If you don't know WHY they are artificially low, then you can't rightly make > the conclusion that they ARE "artificially" low. > I said as near as I can tell. What I do know is that they are lower in the US than virtually anywhere else in the world. > >> My trips to the gas station take between 5 and 45 minutes, depending >> on the length of the line. The price of gasoline fluctuates randomly >> and is obviously detached from the realities of the costs of the raw >> materials. The price only drops significantly after it has risen so much >> so rapidly that there is public outcry and congress starts to seriously >> consider additional regulation of the industry. Then it drops just enough >> to silence the cries for regulation. > > > They are not "detached" from the price of the raw material. There are simply > more factors that adjust the cost like supply, demand, speculation, > refining, which way the wind blows and the color of the fairies in the > Wizard of Oz. > Uh, right... I think that paragraph speaks for itself. The net effect is detachment from predictable or expected factors. > >> But in all fairness, all governments have their hands in the cookie >> jar. Your government more so from what I can tell. >> >> There are a number of possible explanations outside of the government's >> hand in the cookie jar for the disparity in experiences at the gas pump. > > I agree. One thing is for sure, someone is making a lot of money and that > can't just be supply and demand. Indeed. It's not clear that the "someone" is necessarily the oil companies, though I tend to doubt the voracity of their claims on the amount of their profits that are from gasoline or their claimed "$.10/gallon". Owen From owen at delong.com Thu May 5 14:44:15 2011 From: owen at delong.com (Owen DeLong) Date: Thu, 5 May 2011 11:44:15 -0700 Subject: [arin-ppml] ARIN-prop-146 Clarify Justified Need for Transfers In-Reply-To: References: <3E874CBF-24C5-4481-A52F-7F8BE64F27C9@delong.com> Message-ID: On May 5, 2011, at 11:18 AM, Jeffrey Lyon wrote: > On Thu, May 5, 2011 at 2:12 PM, Sweeting, John > wrote: >> A large percentage of the price of a gallon of gas is attributable to Speculators, companies that never even take ownership of the oil, they just buy it and sell before it is even shipped. >> > > It's a gamble. Derivatives markets can protect sellers or they can > protect buyers. A forward contract for delivery in 3 months at A third possibility is that speculators can use derivative markets to just screw everyone and extract money from the process while not providing any benefit. This is often the case. Owen From tedm at ipinc.net Thu May 5 14:45:39 2011 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Thu, 05 May 2011 11:45:39 -0700 Subject: [arin-ppml] Serious question for the list. In-Reply-To: References: <723D48A257C34BA0BD60F16130F4844F@mike><4DC2DB9B.2020908@umn.edu> <4DC2E22A.50708@umn.edu> <4DC2EB16.4070904@ipinc.net> Message-ID: <4DC2F053.2090002@ipinc.net> On 5/5/2011 11:30 AM, Mike Burns wrote: > Hi Ted, > > Thanks for the input. > I understand what you are saying about the dangers of the unwashed. > What about a blog? > Do you think it would be okay to advocate a position in blog and solicit > participation on the list? > It's always OK to solicit participation in the list. But the key word here is "participation" Writing an article to tell people to subscribe just over some point issue and flood the mailing list isn't participation. If they are going to participate, then they better be here for the long run. There's a lot of other stuff that we deal with. Ted > Regards, > Mike > > ----- Original Message ----- From: "Ted Mittelstaedt" > To: > Sent: Thursday, May 05, 2011 2:23 PM > Subject: Re: [arin-ppml] Serious question for the list. > > >> On 5/5/2011 11:02 AM, Mike Burns wrote: >>> It seems to me that the decision about needs analysis for transfers may >>> have some large non-technical components, like one's view of the role of >>> markets in allocating scarce resources. >>> Yes, there are issues of deaggregation, which are too technical for the >>> layman. >>> Yes, there is a danger of overburdening the policy development system, >>> not something anyone would want. >>> But do we want a technical elite making decisions that are not really >>> technical, like the value of unrestricted versus restricted markets? >> >> No, we do not. >> >>> Are we inside an ivory tower? >>> >> >> No, but there is a proper way to bring the general public into the >> decision making in a large volume. >> >> There isn't (in my opinion) a problem with posting in a rag like >> the Libertarian Times or some such, that a mailing list like ppml >> EXISTS. The very few members of the general public who waste their >> time with that stuff and who are at all competent and really care >> about the issue will investigate, make themselves fully aware of >> all of the arguments on all sides of the issue, as well as look >> up the rules for the ppml list (which I will remind everyone, >> ARIN owns and makes the rules on) then join and contribute in >> a positive way. >> >> But the majority of the members of the general public who waste >> their time with that stuff and who are NOT competent will find the >> bar of actually having to look up the instructions for posting >> and rules for joining too difficult to master, and will stay away. >> >> Unless, that is, the poster of the article in the Libertarian Times >> gives an explicit step-by-step set of instructions for how to >> go about subscribing, that a blind monkey could follow. >> >> If you really and truly want to bring people into the decision >> making process who are too ignorant to google up "ppml mailing list" >> then the proper way is via publishing a survey in the ragazine. >> >> The author of the article in the Libertarian Times can create a >> dumbed-down survey on someplace like survey.com or whatever, that >> the ignoramuses can comprehend. >> >> Then we can get the feedback from the unwashed masses without >> being drowned in an onslaught of 5000 fools wanting to know what >> an IP address is and why we can't make more of them. >> >> But, to save you the time I can predict what the general public >> will say in advance - boiled down: >> >> "I want what I have to stay the same and I don't give a damn >> if it staying the same prevents 3/4 of the people in the world >> who aren't on the Internet now, from ever getting on it. I >> got mine, Jack, and screw the rest of them." >> >> Ted >> >>> Regards, >>> Mike >>> >>> >>> >>> >>> >>> ----- Original Message ----- From: "David Farmer" >>> To: "Martin Hannigan" >>> Cc: "Mike Burns" ; ; "David >>> Farmer" >>> Sent: Thursday, May 05, 2011 1:45 PM >>> Subject: Re: [arin-ppml] Serious question for the list. >>> >>> >>>> On 5/5/11 12:25 CDT, Martin Hannigan wrote: >>>>> On Thu, May 5, 2011 at 1:17 PM, David Farmer wrote: >>>>>> On 5/5/11 11:49 CDT, Mike Burns wrote: >>>>>>> >>>>>>> Hi all, >>>>>>> I have had an idea. >>>>>>> Since it has been determined that everybody in the ARIN community >>>>>>> with >>>>>>> an email address may participate in policy development, how does the >>>>>>> list feel about soliciting the input from a broader group of >>>>>>> participants? >>>>>> >>>>>> While not an absolute requirement, I believe there is an >>>>>> understanding that >>>>>> some minimal level of technical expertise and interest in the >>>>>> details of >>>>>> the subject matter are necessary in order to provide useful or >>>>>> meaningful >>>>>> contribution to the process. >>>>>> >>>>> >>>>> So we would exclude members of the general public (users) then? >>>> >>>> Where did I say exclude? "not an absolute requirement", an "interest >>>> in the details" are needed for a "meaningful contribution". None of >>>> that means exclude in my book, it simply means that participation >>>> takes effort and if you want people to take you seriously you need to >>>> make a effort. That is true in many parts of civil society. >>>> >>>> -- >>>> =============================================== >>>> 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. >> >> _______________________________________________ >> 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 5 14:47:37 2011 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Thu, 5 May 2011 14:47:37 -0400 Subject: [arin-ppml] ARIN-prop-146 Clarify Justified Need for Transfers In-Reply-To: References: <3E874CBF-24C5-4481-A52F-7F8BE64F27C9@delong.com> Message-ID: > A third possibility is that speculators can use derivative markets > to just screw everyone and extract money from the process while > not providing any benefit. > > This is often the case. > > Owen > > I must have been asleep for that part of Corporate Finance. -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications - AS32421 First and Leading in DDoS Protection Solutions From mike at nationwideinc.com Thu May 5 14:51:30 2011 From: mike at nationwideinc.com (Mike Burns) Date: Thu, 5 May 2011 14:51:30 -0400 Subject: [arin-ppml] Serious question for the list. References: <723D48A257C34BA0BD60F16130F4844F@mike><4DC2DB9B.2020908@umn.edu> <4DC2E22A.50708@umn.edu> <4DC2EB16.4070904@ipinc.net> <4DC2F053.2090002@ipinc.net> Message-ID: Hi Ted, Okay, I understand what you mean, and where the line should be drawn in terms of solicitation for participation. I shouldn't go out and make mass mailings or robotic postings or go to specific forums and try to stir up the population to jump on and vote for my proposal. But if I had a blog or something, I could write about the issue and ask the readers to participate in the list generally, but not just to jump on one proposal that might suit them ideologically or emotionally. I would say that is pretty close to my own opinion. Regards, Mike ----- Original Message ----- From: "Ted Mittelstaedt" To: "Mike Burns" Cc: Sent: Thursday, May 05, 2011 2:45 PM Subject: Re: [arin-ppml] Serious question for the list. > On 5/5/2011 11:30 AM, Mike Burns wrote: >> Hi Ted, >> >> Thanks for the input. >> I understand what you are saying about the dangers of the unwashed. >> What about a blog? >> Do you think it would be okay to advocate a position in blog and solicit >> participation on the list? >> > > It's always OK to solicit participation in the list. But the key word > here is "participation" > > Writing an article to tell people to subscribe just over some point issue > and flood the mailing list isn't participation. If they are going > to participate, then they better be here for the long run. There's a > lot of other stuff that we deal with. > > Ted > >> Regards, >> Mike >> >> ----- Original Message ----- From: "Ted Mittelstaedt" >> To: >> Sent: Thursday, May 05, 2011 2:23 PM >> Subject: Re: [arin-ppml] Serious question for the list. >> >> >>> On 5/5/2011 11:02 AM, Mike Burns wrote: >>>> It seems to me that the decision about needs analysis for transfers may >>>> have some large non-technical components, like one's view of the role >>>> of >>>> markets in allocating scarce resources. >>>> Yes, there are issues of deaggregation, which are too technical for the >>>> layman. >>>> Yes, there is a danger of overburdening the policy development system, >>>> not something anyone would want. >>>> But do we want a technical elite making decisions that are not really >>>> technical, like the value of unrestricted versus restricted markets? >>> >>> No, we do not. >>> >>>> Are we inside an ivory tower? >>>> >>> >>> No, but there is a proper way to bring the general public into the >>> decision making in a large volume. >>> >>> There isn't (in my opinion) a problem with posting in a rag like >>> the Libertarian Times or some such, that a mailing list like ppml >>> EXISTS. The very few members of the general public who waste their >>> time with that stuff and who are at all competent and really care >>> about the issue will investigate, make themselves fully aware of >>> all of the arguments on all sides of the issue, as well as look >>> up the rules for the ppml list (which I will remind everyone, >>> ARIN owns and makes the rules on) then join and contribute in >>> a positive way. >>> >>> But the majority of the members of the general public who waste >>> their time with that stuff and who are NOT competent will find the >>> bar of actually having to look up the instructions for posting >>> and rules for joining too difficult to master, and will stay away. >>> >>> Unless, that is, the poster of the article in the Libertarian Times >>> gives an explicit step-by-step set of instructions for how to >>> go about subscribing, that a blind monkey could follow. >>> >>> If you really and truly want to bring people into the decision >>> making process who are too ignorant to google up "ppml mailing list" >>> then the proper way is via publishing a survey in the ragazine. >>> >>> The author of the article in the Libertarian Times can create a >>> dumbed-down survey on someplace like survey.com or whatever, that >>> the ignoramuses can comprehend. >>> >>> Then we can get the feedback from the unwashed masses without >>> being drowned in an onslaught of 5000 fools wanting to know what >>> an IP address is and why we can't make more of them. >>> >>> But, to save you the time I can predict what the general public >>> will say in advance - boiled down: >>> >>> "I want what I have to stay the same and I don't give a damn >>> if it staying the same prevents 3/4 of the people in the world >>> who aren't on the Internet now, from ever getting on it. I >>> got mine, Jack, and screw the rest of them." >>> >>> Ted >>> >>>> Regards, >>>> Mike >>>> >>>> >>>> >>>> >>>> >>>> ----- Original Message ----- From: "David Farmer" >>>> To: "Martin Hannigan" >>>> Cc: "Mike Burns" ; ; "David >>>> Farmer" >>>> Sent: Thursday, May 05, 2011 1:45 PM >>>> Subject: Re: [arin-ppml] Serious question for the list. >>>> >>>> >>>>> On 5/5/11 12:25 CDT, Martin Hannigan wrote: >>>>>> On Thu, May 5, 2011 at 1:17 PM, David Farmer wrote: >>>>>>> On 5/5/11 11:49 CDT, Mike Burns wrote: >>>>>>>> >>>>>>>> Hi all, >>>>>>>> I have had an idea. >>>>>>>> Since it has been determined that everybody in the ARIN community >>>>>>>> with >>>>>>>> an email address may participate in policy development, how does >>>>>>>> the >>>>>>>> list feel about soliciting the input from a broader group of >>>>>>>> participants? >>>>>>> >>>>>>> While not an absolute requirement, I believe there is an >>>>>>> understanding that >>>>>>> some minimal level of technical expertise and interest in the >>>>>>> details of >>>>>>> the subject matter are necessary in order to provide useful or >>>>>>> meaningful >>>>>>> contribution to the process. >>>>>>> >>>>>> >>>>>> So we would exclude members of the general public (users) then? >>>>> >>>>> Where did I say exclude? "not an absolute requirement", an "interest >>>>> in the details" are needed for a "meaningful contribution". None of >>>>> that means exclude in my book, it simply means that participation >>>>> takes effort and if you want people to take you seriously you need to >>>>> make a effort. That is true in many parts of civil society. >>>>> >>>>> -- >>>>> =============================================== >>>>> 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. >>> >>> _______________________________________________ >>> 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 5 14:52:16 2011 From: owen at delong.com (Owen DeLong) Date: Thu, 5 May 2011 11:52:16 -0700 Subject: [arin-ppml] Serious question for the list. In-Reply-To: References: Message-ID: On May 5, 2011, at 11:44 AM, Mike Burns wrote: >> The AC does pay close attention to PPML and to our perceived will >> of the community. Yes, our perceived will of the community is a >> somewhat nebulous concept, but, I think that is unavoidable in >> a consensus-based bottom-up process. However, if the community >> expresses strong support for a direction contrary to the current >> policy, that support would definitely be considered by the AC. >> >> Owen >> > > Would the AC give more weight to expressions of support from long term list members than from newcomers? > > Regards, > Mike Generally I would not. I cannot speak for the majority of the AC. However, I would give more support to someone who expressed not only support, but, a cogent reason for their support showing that they clearly understood the issues than someone who merely expressed support. If it is someone who I know (directly or through their list participation) has a good understanding of the issues in general, their +1 might carry more weight than someone else's unknown +1, but, that would depend on the subtlety or complexity of the issues at hand. Owen From owen at delong.com Thu May 5 14:54:53 2011 From: owen at delong.com (Owen DeLong) Date: Thu, 5 May 2011 11:54:53 -0700 Subject: [arin-ppml] ARIN-prop-146 Clarify Justified Need for Transfers In-Reply-To: References: <4DBEF120.4080901@arin.net> <88F39B20-5C20-45F0-AD61-5FA1E7F84CE3@delong.com> <3FCD1FDC-ECEE-4C9B-95C6-59E03D3C314E@matthew.at> <5598DFC7-E320-42FA-AA0E-C91C076BD725@delong.com> <6BA1EAA6-7D9C-44F9-BED7-884720F4B3BE@matthew.at> <05FAA29B-37BE-411C-95A4-50437602C8ED@delong.com> <4DBF6727.1090303@matthew.at> <097AAC1C-1F68-4820-9274-3290ADEFA195@delong.com> <4DBF75B7.3010407@matthew.at> <9501EA7E-FDAD-4DDA-B9E8-08C2811FF642@delong.com> <4DBF82F6.7050608@matthew.at> <20110503145144.N15967@mail.inlandnet.com> <4DC084E7.5000302@matthew.at> <4DC08664.4060905@matthew.at> <4791A59E-8864-483C-9BB0-03A6A5B8D50C@delong.com> <66466F57-4365-4ADB-94EB-E023F01B17CB@delong.com> <30D12BA8-9A6C-4E62-9A67-8B4FEA0EA8C1@matthew.at> <00af01cc0aa7$845a5330$8d0ef990$@net> Message-ID: <4E2819E2-DFF8-4A4E-AEC8-0BF07977EE5B@delong.com> On May 5, 2011, at 11:45 AM, Jeffrey Lyon wrote: >> I was fine with the fuel rationing. I would be fine with it again if I could >> get my fuel for $0.79/gallon again. >> >> Owen >> >> > > Owen, > > Would it be fair to say that you don't support free markets and leave > it alone there? I could spend all day expressing my thoughts on how > horribly bad that would be, but it's not entirely relevant to PPML. > Not at all... I fully support properly regulated free markets where they make sense and can be functional. I simply don't believe that IPv4 policy is such a case. > I'm really not trying to attack your political values, just establish > your particular flavor of bias. > Understood. I like to think that I am not particularly biased, but, rather considering the issue based on what I perceive the implications of the policy changes to be and their likely outcomes. I am the first to admit I may well be imperfect in this regard, but, my opposition to free-er market transfers comes from my anticipation that they will lead to increased pain for the members of the community rather than my own particular political leanings. If you can somehow convince me that more open transfer policies would reduce, rather than inflict pain upon the community, then, I would support them. Owen From tedm at ipinc.net Thu May 5 14:58:01 2011 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Thu, 05 May 2011 11:58:01 -0700 Subject: [arin-ppml] Serious question for the list. In-Reply-To: References: <723D48A257C34BA0BD60F16130F4844F@mike> <4DC2E609.6070006@ipinc.net> <4DC2EB8C.1080407@ipinc.net> Message-ID: <4DC2F339.2080907@ipinc.net> On 5/5/2011 11:32 AM, Jeffrey Lyon wrote: > On Thu, May 5, 2011 at 2:25 PM, Ted Mittelstaedt wrote: >> On 5/5/2011 11:10 AM, Jeffrey Lyon wrote: >>>> >>>> I think it would be better if YOU were to run and be elected and >>>> serve. Once you had some real responsibility for the numbering you >>>> might grow up and quit wasting your brainpower on these sorts of >>>> unworkable proposals. >>>> >>>> Ted >>> >>> Ted, >>> >>> I don't feel the personal attack is warranted. >> >> I didn't start the personal attack. Use of the emotionally loaded >> term "Olde Guard" started that. >> >> However, I WILL end it. >> >> Ted >> > > Ted, > > There was no ill intent in that term which I use in this sense: "may > refer generally to a veteran or group of veterans, a conservative > faction, or an older segment of a population." (source: Wikipedia). > Generally when I see someone putting an "e" on the end of a word they are either trying to open a Bed and Breakfast and look quaint or they are making a joke of the people trying to look quaint. Your use of the term was embedded in a post that was not that supportive of the AC so I took it as the second meaning, ie: sarcastic. I'm glad no ill intent was intended. But I am serious when I say that you should run. If you really do think the AC is not in touch then your obligated to run. I certainly don't agree with all their decisions all the time, myself. Any of them on the AC could tell you that. But if your going to advocate privatization of the RIR system you won't get my vote. I'll disagree with what you say but I'll defend to the death your right to say it. Ted From jeffrey.lyon at blacklotus.net Thu May 5 15:03:18 2011 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Thu, 5 May 2011 15:03:18 -0400 Subject: [arin-ppml] ARIN-prop-146 Clarify Justified Need for Transfers In-Reply-To: <4E2819E2-DFF8-4A4E-AEC8-0BF07977EE5B@delong.com> References: <4DBEF120.4080901@arin.net> <88F39B20-5C20-45F0-AD61-5FA1E7F84CE3@delong.com> <3FCD1FDC-ECEE-4C9B-95C6-59E03D3C314E@matthew.at> <5598DFC7-E320-42FA-AA0E-C91C076BD725@delong.com> <6BA1EAA6-7D9C-44F9-BED7-884720F4B3BE@matthew.at> <05FAA29B-37BE-411C-95A4-50437602C8ED@delong.com> <4DBF6727.1090303@matthew.at> <097AAC1C-1F68-4820-9274-3290ADEFA195@delong.com> <4DBF75B7.3010407@matthew.at> <9501EA7E-FDAD-4DDA-B9E8-08C2811FF642@delong.com> <4DBF82F6.7050608@matthew.at> <20110503145144.N15967@mail.inlandnet.com> <4DC084E7.5000302@matthew.at> <4DC08664.4060905@matthew.at> <4791A59E-8864-483C-9BB0-03A6A5B8D50C@delong.com> <66466F57-4365-4ADB-94EB-E023F01B17CB@delong.com> <30D12BA8-9A6C-4E62-9A67-8B4FEA0EA8C1@matthew.at> <00af01cc0aa7$845a5330$8d0ef990$@net> <4E2819E2-DFF8-4A4E-AEC8-0BF07977EE5B@delong.com> Message-ID: > If you can somehow convince me that more open transfer policies > would reduce, rather than inflict pain upon the community, then, I > would support them. > > Owen > > The basic arguments in support of free markets, generally, have been made. You're accustomed to a system which has always worked well, so you don't see a reason to change it. I don't really see a benefit to trying to change your mind as I don't believe that you will view this as a good idea unless you actually were to see it at work. You are perhaps one of the most substantial and well known IPv6 proponents in the world, as is your employer. Naturally, you're going to see IPv6 as the solution rather than free markets. Your employer is going to be one of the very few companies that will not suffer from IPv4 exhaustion so I don't expect you to want to support a measure that would prolong the life of IPv4. We both support IPv6. The major difference is that you started a decade ago and I started one year ago. Accordingly, I am more sympathetic to companies who have not made the appropriate plans. -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications - AS32421 First and Leading in DDoS Protection Solutions From tedm at ipinc.net Thu May 5 15:04:12 2011 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Thu, 05 May 2011 12:04:12 -0700 Subject: [arin-ppml] Serious question for the list. In-Reply-To: References: <723D48A257C34BA0BD60F16130F4844F@mike><4DC2DB9B.2020908@umn.edu> <4DC2E22A.50708@umn.edu> <4DC2EB16.4070904@ipinc.net> <4DC2F053.2090002@ipinc.net> Message-ID: <4DC2F4AC.2060704@ipinc.net> Precisely. In US politics the term is "single issue politics" and the slang is "gunners, baggers, or dittoheads" I don't want their kind in here and I expect neither does anyone else. Ted On 5/5/2011 11:51 AM, Mike Burns wrote: > Hi Ted, > > Okay, I understand what you mean, and where the line should be drawn in > terms of solicitation for participation. > I shouldn't go out and make mass mailings or robotic postings or go to > specific forums and try to stir up the population to jump on and vote > for my proposal. > But if I had a blog or something, I could write about the issue and ask > the readers to participate in the list generally, but not just to jump > on one proposal that might suit them ideologically or emotionally. > > I would say that is pretty close to my own opinion. > > Regards, > > Mike > > > ----- Original Message ----- From: "Ted Mittelstaedt" > To: "Mike Burns" > Cc: > Sent: Thursday, May 05, 2011 2:45 PM > Subject: Re: [arin-ppml] Serious question for the list. > > >> On 5/5/2011 11:30 AM, Mike Burns wrote: >>> Hi Ted, >>> >>> Thanks for the input. >>> I understand what you are saying about the dangers of the unwashed. >>> What about a blog? >>> Do you think it would be okay to advocate a position in blog and solicit >>> participation on the list? >>> >> >> It's always OK to solicit participation in the list. But the key word >> here is "participation" >> >> Writing an article to tell people to subscribe just over some point >> issue and flood the mailing list isn't participation. If they are going >> to participate, then they better be here for the long run. There's a >> lot of other stuff that we deal with. >> >> Ted >> >>> Regards, >>> Mike >>> >>> ----- Original Message ----- From: "Ted Mittelstaedt" >>> To: >>> Sent: Thursday, May 05, 2011 2:23 PM >>> Subject: Re: [arin-ppml] Serious question for the list. >>> >>> >>>> On 5/5/2011 11:02 AM, Mike Burns wrote: >>>>> It seems to me that the decision about needs analysis for transfers >>>>> may >>>>> have some large non-technical components, like one's view of the >>>>> role of >>>>> markets in allocating scarce resources. >>>>> Yes, there are issues of deaggregation, which are too technical for >>>>> the >>>>> layman. >>>>> Yes, there is a danger of overburdening the policy development system, >>>>> not something anyone would want. >>>>> But do we want a technical elite making decisions that are not really >>>>> technical, like the value of unrestricted versus restricted markets? >>>> >>>> No, we do not. >>>> >>>>> Are we inside an ivory tower? >>>>> >>>> >>>> No, but there is a proper way to bring the general public into the >>>> decision making in a large volume. >>>> >>>> There isn't (in my opinion) a problem with posting in a rag like >>>> the Libertarian Times or some such, that a mailing list like ppml >>>> EXISTS. The very few members of the general public who waste their >>>> time with that stuff and who are at all competent and really care >>>> about the issue will investigate, make themselves fully aware of >>>> all of the arguments on all sides of the issue, as well as look >>>> up the rules for the ppml list (which I will remind everyone, >>>> ARIN owns and makes the rules on) then join and contribute in >>>> a positive way. >>>> >>>> But the majority of the members of the general public who waste >>>> their time with that stuff and who are NOT competent will find the >>>> bar of actually having to look up the instructions for posting >>>> and rules for joining too difficult to master, and will stay away. >>>> >>>> Unless, that is, the poster of the article in the Libertarian Times >>>> gives an explicit step-by-step set of instructions for how to >>>> go about subscribing, that a blind monkey could follow. >>>> >>>> If you really and truly want to bring people into the decision >>>> making process who are too ignorant to google up "ppml mailing list" >>>> then the proper way is via publishing a survey in the ragazine. >>>> >>>> The author of the article in the Libertarian Times can create a >>>> dumbed-down survey on someplace like survey.com or whatever, that >>>> the ignoramuses can comprehend. >>>> >>>> Then we can get the feedback from the unwashed masses without >>>> being drowned in an onslaught of 5000 fools wanting to know what >>>> an IP address is and why we can't make more of them. >>>> >>>> But, to save you the time I can predict what the general public >>>> will say in advance - boiled down: >>>> >>>> "I want what I have to stay the same and I don't give a damn >>>> if it staying the same prevents 3/4 of the people in the world >>>> who aren't on the Internet now, from ever getting on it. I >>>> got mine, Jack, and screw the rest of them." >>>> >>>> Ted >>>> >>>>> Regards, >>>>> Mike >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> ----- Original Message ----- From: "David Farmer" >>>>> To: "Martin Hannigan" >>>>> Cc: "Mike Burns" ; ; >>>>> "David >>>>> Farmer" >>>>> Sent: Thursday, May 05, 2011 1:45 PM >>>>> Subject: Re: [arin-ppml] Serious question for the list. >>>>> >>>>> >>>>>> On 5/5/11 12:25 CDT, Martin Hannigan wrote: >>>>>>> On Thu, May 5, 2011 at 1:17 PM, David Farmer wrote: >>>>>>>> On 5/5/11 11:49 CDT, Mike Burns wrote: >>>>>>>>> >>>>>>>>> Hi all, >>>>>>>>> I have had an idea. >>>>>>>>> Since it has been determined that everybody in the ARIN community >>>>>>>>> with >>>>>>>>> an email address may participate in policy development, how >>>>>>>>> does the >>>>>>>>> list feel about soliciting the input from a broader group of >>>>>>>>> participants? >>>>>>>> >>>>>>>> While not an absolute requirement, I believe there is an >>>>>>>> understanding that >>>>>>>> some minimal level of technical expertise and interest in the >>>>>>>> details of >>>>>>>> the subject matter are necessary in order to provide useful or >>>>>>>> meaningful >>>>>>>> contribution to the process. >>>>>>>> >>>>>>> >>>>>>> So we would exclude members of the general public (users) then? >>>>>> >>>>>> Where did I say exclude? "not an absolute requirement", an "interest >>>>>> in the details" are needed for a "meaningful contribution". None of >>>>>> that means exclude in my book, it simply means that participation >>>>>> takes effort and if you want people to take you seriously you need to >>>>>> make a effort. That is true in many parts of civil society. >>>>>> >>>>>> -- >>>>>> =============================================== >>>>>> 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. >>>> >>>> _______________________________________________ >>>> 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 matthew at matthew.at Thu May 5 15:08:03 2011 From: matthew at matthew.at (Matthew Kaufman) Date: Thu, 05 May 2011 12:08:03 -0700 Subject: [arin-ppml] ARIN-prop-146 Clarify Justified Need for Transfers In-Reply-To: <4E2819E2-DFF8-4A4E-AEC8-0BF07977EE5B@delong.com> References: <4DBEF120.4080901@arin.net> <4DBF6727.1090303@matthew.at> <097AAC1C-1F68-4820-9274-3290ADEFA195@delong.com> <4DBF75B7.3010407@matthew.at> <9501EA7E-FDAD-4DDA-B9E8-08C2811FF642@delong.com> <4DBF82F6.7050608@matthew.at> <20110503145144.N15967@mail.inlandnet.com> <4DC084E7.5000302@matthew.at> <4DC08664.4060905@matthew.at> <4791A59E-8864-483C-9BB0-03A6A5B8D50C@delong.com> <66466F57-4365-4ADB-94EB-E023F01B17CB@delong.com> <30D12BA8-9A6C-4E62-9A67-8B4FEA0EA8C1@matthew.at> <00af01cc0aa7$845a5330$8d0ef990$@net> <4E2819E2-DFF8-4A4E-AEC8-0BF07977EE5B@delong.com> Message-ID: <4DC2F593.40006@matthew.at> On 5/5/2011 11:54 AM, Owen DeLong wrote: > > If you can somehow convince me that more open transfer policies > would reduce, rather than inflict pain upon the community, then, I > would support them. This particular policy proposal reduces the pain on recent and new entrants in exchange for what might be a very slight additional pain (in that the recent and new entrants would be bidding against them) on the existing holders of IPv4 space who might need more. I'm concerned that when you say "the community" you mean "people who've had IPv4 space for a long time" or even "ISP members of ARIN". Note that even concerns about routing table size increases (which this policy either won't affect or will actually cause reductions by reducing the number of transfers needed by a new or existing entrant) are really a pain experienced primarily by long-time ISP members (who have more routers holding full tables)... and so any talk about how routing table size increases hurt "the community" clearly shows this bias. Matthew Kaufman From gary.buhrmaster at gmail.com Thu May 5 15:09:36 2011 From: gary.buhrmaster at gmail.com (Gary Buhrmaster) Date: Thu, 5 May 2011 19:09:36 +0000 Subject: [arin-ppml] Serious question for the list. In-Reply-To: References: Message-ID: On Thu, May 5, 2011 at 18:44, Mike Burns wrote: .... > Would the AC give more weight to expressions of support from long term list > members than from newcomers? My experience is that the AC give more weight to well reasoned positions than how long one has been a subscriber. But to provide that well reasoned position, one does need to have some understanding of the issues and process (and that, in practice, does mean one is going to have to participate(*), and not provide drive-by support/disapproval on point issues). I personally think the more that want to participate the better. I also wish more of the "legacy" holders would participate. I also recognize the life is short, and PPML is sometimes one fire hose too many. Gary (*) Participation does *not* have to mean commenting on every issue. "Lurkers" who follow the discussions can still be participating, saving their wisdom for when it matters the most. From Daniel_Alexander at Cable.Comcast.com Thu May 5 15:19:12 2011 From: Daniel_Alexander at Cable.Comcast.com (Alexander, Daniel) Date: Thu, 5 May 2011 19:19:12 +0000 Subject: [arin-ppml] Serious question for the list. In-Reply-To: Message-ID: Tenure on the list is irrelevant. It is the value of the comments that carry weight. While I don't know how long he has subscribed to the list, I think Leif Sawyer is a good example. I haven't seen many posts from him, but he made a very relevant point in the discussion regarding prop-147. I am confident few people thought about how the time requirements in policy impacted his business, given a very limited construction season in Alaska. -Dan On 5/5/11 2:44 PM, "Mike Burns" wrote: >> The AC does pay close attention to PPML and to our perceived will >> of the community. Yes, our perceived will of the community is a >> somewhat nebulous concept, but, I think that is unavoidable in >> a consensus-based bottom-up process. However, if the community >> expresses strong support for a direction contrary to the current >> policy, that support would definitely be considered by the AC. >> >> Owen >> > >Would the AC give more weight to expressions of support from long term >list >members than from newcomers? > >Regards, >Mike > >_______________________________________________ >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 5 15:23:16 2011 From: jcurran at arin.net (John Curran) Date: Thu, 5 May 2011 19:23:16 +0000 Subject: [arin-ppml] Serious question for the list. In-Reply-To: <723D48A257C34BA0BD60F16130F4844F@mike> References: <723D48A257C34BA0BD60F16130F4844F@mike> Message-ID: Mike - To the extent that you encourage new folks who are unaware of Internet numbering, ARIN, or the Policy Development Process to participate in the PPML discussions, it would be good if you could arrange some form on orientation for them - e.g. on nature of IPv4 and IPv6, ICANN/IANA/RIR overview, and ARIN specific information such as the ARIN Advisory Council, Policy Development Process, and Public Policy Meeting (PPM) We provide a First-Time attendees overview at each ARIN PPM, and pointing them at those slides might make a good start for folks relatively new to ARIN. The Public Policy Mailing List and Policy Development Process is open to all. Thanks! /John John Curran President and CEO ARIN From farmer at umn.edu Thu May 5 15:23:36 2011 From: farmer at umn.edu (David Farmer) Date: Thu, 05 May 2011 14:23:36 -0500 Subject: [arin-ppml] Serious question for the list. In-Reply-To: References: <723D48A257C34BA0BD60F16130F4844F@mike> <830EB477-D03E-41B9-A5D7-125B957A8B29@delong.com> Message-ID: <4DC2F938.4010701@umn.edu> On 5/5/11 13:40 CDT, Jeffrey Lyon wrote: > This is correct, and mutually understood. The current AC perception of > the Burns-Lyon ideology is that the community does not support. It > would take substantial influence and discussion to change gears in > that respect. A bunch of new faces popping up on PPML and supporting > this idea would not change the AC perception of community support or > lack thereof. I can't speak for the whole AC, but yes a bunch of anonymous faces popping up simply saying that they support the proposal, or not, would have less wait with me. However, a number of people who seem to articulate a real understanding of both the technical and/or broader issues would have sway with me. To me it really does count more if you can explain why you support something. I'm not saying that you always have too. Only that, if you are new somewhere and you want people to take you seriously, being articulate can't hurt. Besides the world would be every boring if everyone agreed with you. :) -- =============================================== 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 scottleibrand at gmail.com Thu May 5 15:34:15 2011 From: scottleibrand at gmail.com (Scott Leibrand) Date: Thu, 5 May 2011 12:34:15 -0700 Subject: [arin-ppml] Serious question for the list. In-Reply-To: References: <723D48A257C34BA0BD60F16130F4844F@mike> <4DC2DB9B.2020908@umn.edu> <4DC2E22A.50708@umn.edu> <4DC2EB16.4070904@ipinc.net> <4DC2F053.2090002@ipinc.net> Message-ID: <1583157374717311612@unknownmsgid> On May 5, 2011, at 11:52 AM, "Mike Burns" wrote: > Hi Ted, > > Okay, I understand what you mean, and where the line should be drawn in terms of solicitation for participation. > I shouldn't go out and make mass mailings or robotic postings or go to specific forums and try to stir up the population to jump on and vote for my proposal. > But if I had a blog or something, I could write about the issue and ask the readers to participate in the list generally, but not just to jump on one proposal that might suit them ideologically or emotionally. > > I would say that is pretty close to my own opinion. I would agree with that summary, and would encourage anyone with the time and willingness to invest in such a project to do exactly that. As John just mentioned, it would also be good to point new participants to resources that would help them meaningfully participate. But I think the key is that anyone who wishes to participate, by posting well-reasoned arguments and opinions (technical or not) is welcome to do so. As others have mentioned, quality of such arguments is what matters, not quantity, but there are a number of perspectives we are undoubtedly missing, so it would be good to have meaningful participation from such folks. Thanks for your efforts to help increase participation levels, and your commitment to doing so in such a way as to improve the signal to noise ratio here. :-) -Scott > > > > ----- Original Message ----- From: "Ted Mittelstaedt" > To: "Mike Burns" > Cc: > Sent: Thursday, May 05, 2011 2:45 PM > Subject: Re: [arin-ppml] Serious question for the list. > > >> On 5/5/2011 11:30 AM, Mike Burns wrote: >>> Hi Ted, >>> >>> Thanks for the input. >>> I understand what you are saying about the dangers of the unwashed. >>> What about a blog? >>> Do you think it would be okay to advocate a position in blog and solicit >>> participation on the list? >>> >> >> It's always OK to solicit participation in the list. But the key word >> here is "participation" >> >> Writing an article to tell people to subscribe just over some point issue and flood the mailing list isn't participation. If they are going >> to participate, then they better be here for the long run. There's a >> lot of other stuff that we deal with. >> >> Ted >> >>> Regards, >>> Mike >>> >>> ----- Original Message ----- From: "Ted Mittelstaedt" >>> To: >>> Sent: Thursday, May 05, 2011 2:23 PM >>> Subject: Re: [arin-ppml] Serious question for the list. >>> >>> >>>> On 5/5/2011 11:02 AM, Mike Burns wrote: >>>>> It seems to me that the decision about needs analysis for transfers may >>>>> have some large non-technical components, like one's view of the role of >>>>> markets in allocating scarce resources. >>>>> Yes, there are issues of deaggregation, which are too technical for the >>>>> layman. >>>>> Yes, there is a danger of overburdening the policy development system, >>>>> not something anyone would want. >>>>> But do we want a technical elite making decisions that are not really >>>>> technical, like the value of unrestricted versus restricted markets? >>>> >>>> No, we do not. >>>> >>>>> Are we inside an ivory tower? >>>>> >>>> >>>> No, but there is a proper way to bring the general public into the >>>> decision making in a large volume. >>>> >>>> There isn't (in my opinion) a problem with posting in a rag like >>>> the Libertarian Times or some such, that a mailing list like ppml >>>> EXISTS. The very few members of the general public who waste their >>>> time with that stuff and who are at all competent and really care >>>> about the issue will investigate, make themselves fully aware of >>>> all of the arguments on all sides of the issue, as well as look >>>> up the rules for the ppml list (which I will remind everyone, >>>> ARIN owns and makes the rules on) then join and contribute in >>>> a positive way. >>>> >>>> But the majority of the members of the general public who waste >>>> their time with that stuff and who are NOT competent will find the >>>> bar of actually having to look up the instructions for posting >>>> and rules for joining too difficult to master, and will stay away. >>>> >>>> Unless, that is, the poster of the article in the Libertarian Times >>>> gives an explicit step-by-step set of instructions for how to >>>> go about subscribing, that a blind monkey could follow. >>>> >>>> If you really and truly want to bring people into the decision >>>> making process who are too ignorant to google up "ppml mailing list" >>>> then the proper way is via publishing a survey in the ragazine. >>>> >>>> The author of the article in the Libertarian Times can create a >>>> dumbed-down survey on someplace like survey.com or whatever, that >>>> the ignoramuses can comprehend. >>>> >>>> Then we can get the feedback from the unwashed masses without >>>> being drowned in an onslaught of 5000 fools wanting to know what >>>> an IP address is and why we can't make more of them. >>>> >>>> But, to save you the time I can predict what the general public >>>> will say in advance - boiled down: >>>> >>>> "I want what I have to stay the same and I don't give a damn >>>> if it staying the same prevents 3/4 of the people in the world >>>> who aren't on the Internet now, from ever getting on it. I >>>> got mine, Jack, and screw the rest of them." >>>> >>>> Ted >>>> >>>>> Regards, >>>>> Mike >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> ----- Original Message ----- From: "David Farmer" >>>>> To: "Martin Hannigan" >>>>> Cc: "Mike Burns" ; ; "David >>>>> Farmer" >>>>> Sent: Thursday, May 05, 2011 1:45 PM >>>>> Subject: Re: [arin-ppml] Serious question for the list. >>>>> >>>>> >>>>>> On 5/5/11 12:25 CDT, Martin Hannigan wrote: >>>>>>> On Thu, May 5, 2011 at 1:17 PM, David Farmer wrote: >>>>>>>> On 5/5/11 11:49 CDT, Mike Burns wrote: >>>>>>>>> >>>>>>>>> Hi all, >>>>>>>>> I have had an idea. >>>>>>>>> Since it has been determined that everybody in the ARIN community >>>>>>>>> with >>>>>>>>> an email address may participate in policy development, how does the >>>>>>>>> list feel about soliciting the input from a broader group of >>>>>>>>> participants? >>>>>>>> >>>>>>>> While not an absolute requirement, I believe there is an >>>>>>>> understanding that >>>>>>>> some minimal level of technical expertise and interest in the >>>>>>>> details of >>>>>>>> the subject matter are necessary in order to provide useful or >>>>>>>> meaningful >>>>>>>> contribution to the process. >>>>>>>> >>>>>>> >>>>>>> So we would exclude members of the general public (users) then? >>>>>> >>>>>> Where did I say exclude? "not an absolute requirement", an "interest >>>>>> in the details" are needed for a "meaningful contribution". None of >>>>>> that means exclude in my book, it simply means that participation >>>>>> takes effort and if you want people to take you seriously you need to >>>>>> make a effort. That is true in many parts of civil society. >>>>>> >>>>>> -- >>>>>> =============================================== >>>>>> 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. >>>> >>>> _______________________________________________ >>>> 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 ebw at abenaki.wabanaki.net Thu May 5 15:38:46 2011 From: ebw at abenaki.wabanaki.net (Eric Brunner-Williams) Date: Thu, 05 May 2011 15:38:46 -0400 Subject: [arin-ppml] Fw: Accusationof fundamentalconflictofinterest/IPaddress policypitched directly to ICANN In-Reply-To: <197A4DE3-3155-4411-B5EE-7A0A74D05A4A@delong.com> References: <379DB08FB5564ED88230C1B6D6AE80FE@mike> <8695009A81378E48879980039EEDAD289D0E5BC6@MAIL1.polartel.local> <6B65D21B9B7543208304CC44EDD22444@mike> <3DA6DC8B-ADC6-4BCB-83BA-5F07BC5682C7@delong.com> <9D762F7D6FE3419790C6E47F58A1D4D5@mike> <4BEDC361E6D04A7292F5A294FA4FC2FE@mike> <197A4DE3-3155-4411-B5EE-7A0A74D05A4A@delong.com> Message-ID: <4DC2FCC6.8040509@abenaki.wabanaki.net> On 5/5/11 2:04 PM, Owen DeLong wrote: > > I'm not a lawyer, either, but I suspect that the courts may well > decide that authority comes from > the DoC contract. The question, however, is ... i suggest that prior to the contractual interpretive question there is a question we've let lie for a decade. what is the nature of the new entity? is it exercising delegated rule making authority, and so subject to the administrative procedure act of 1946, and if not, what is the nature of that authority? -e From jcurran at arin.net Thu May 5 15:41:35 2011 From: jcurran at arin.net (John Curran) Date: Thu, 5 May 2011 19:41:35 +0000 Subject: [arin-ppml] Outstanding policy proposals Message-ID: <732B2DE4-31DC-4CE1-9B46-F20F5D5A3377@arin.net> Folks - As part of discussing the policy proposals, it's sometimes particularly helpful for people in opposition to one to note any changes that would change their view and make them support a given policy proposal. Please keep this in mind when considering the large number of policy proposals presently under discussion. Thanks! /John John Curran President and CEO ARIN From george.herbert at gmail.com Thu May 5 15:59:55 2011 From: george.herbert at gmail.com (George Herbert) Date: Thu, 5 May 2011 12:59:55 -0700 Subject: [arin-ppml] Serious question for the list. In-Reply-To: References: <723D48A257C34BA0BD60F16130F4844F@mike> <4DC2DB9B.2020908@umn.edu> Message-ID: On Thu, May 5, 2011 at 10:25 AM, Martin Hannigan wrote: > On Thu, May 5, 2011 at 1:17 PM, David Farmer wrote: >> On 5/5/11 11:49 CDT, Mike Burns wrote: >>> >>> Hi all, >>> I have had an idea. >>> Since it has been determined that everybody in the ARIN community with >>> an email address may participate in policy development, how does the >>> list feel about soliciting the input from a broader group of participants? >> >> While not an absolute requirement, I believe there is an understanding that >> some minimal ?level of technical expertise and interest in the details of >> the subject matter are necessary in order to provide useful or meaningful >> contribution to the process. >> > > > So we would exclude members of the general public (users) then? For what it's worth - I am currently in the user side of things, and have spent much more professional life in non-ISP work than ISP work. Some other members are at least between ISPs... I also count as "old guard" in one sense - my first ISP was in 1992, and I've been on NANOG for decades - though I just joined PPML recently. I personally am not against rethinking the status quo on address ownership, but I am against half-assed paradigm shifts. That way lies madness. The proponents here have not answered my questions regarding the fundamental issues and goals and I won't support any changes that have not had an open and honest in-depth discussion of both goals and consequences of such shifts. -- -george william herbert george.herbert at gmail.com From kkargel at polartel.com Thu May 5 16:02:26 2011 From: kkargel at polartel.com (Kevin Kargel) Date: Thu, 5 May 2011 15:02:26 -0500 Subject: [arin-ppml] ARIN-prop-146 Clarify Justified Need for Transfers In-Reply-To: References: <4DBEF120.4080901@arin.net> <88F39B20-5C20-45F0-AD61-5FA1E7F84CE3@delong.com> <3FCD1FDC-ECEE-4C9B-95C6-59E03D3C314E@matthew.at> <5598DFC7-E320-42FA-AA0E-C91C076BD725@delong.com> <6BA1EAA6-7D9C-44F9-BED7-884720F4B3BE@matthew.at> <05FAA29B-37BE-411C-95A4-50437602C8ED@delong.com> <4DBF6727.1090303@matthew.at> <097AAC1C-1F68-4820-9274-3290ADEFA195@delong.com> <4DBF75B7.3010407@matthew.at> <9501EA7E-FDAD-4DDA-B9E8-08C2811FF642@delong.com> <4DBF82F6.7050608@matthew.at> <20110503145144.N15967@mail.inlandnet.com> <4DC084E7.5000302@matthew.at> <4DC08664.4060905@matthew.at> <4791A59E-8864-483C-9BB0-03A6A5B8D50C@delong.com> <66466F57-4365-4ADB-94EB-E023F01B17CB@delong.com> <30D12BA8-9A6C-4E62-9A67-8B4FEA0EA8C1@matthew.at> <00af01cc0aa7$845a5330$8d0ef990$@net> Message-ID: <8695009A81378E48879980039EEDAD289D0E5BD9@MAIL1.polartel.local> > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf Of McTim > Sent: Thursday, May 05, 2011 1:59 AM > To: Warren Johnson > Cc: arin-ppml at arin.net > Subject: Re: [arin-ppml] ARIN-prop-146 Clarify Justified Need for > Transfers > > On Thu, May 5, 2011 at 1:06 AM, Warren Johnson > wrote: > > I respect that. But just because you don't want to teach your child that > > doesn't mean it isn't true. ?It's not like OIL is allocated based on > need. > > Hmm, well my experience yesterday waiting in line for 2.5 hrs to get a > limited amount of petrol suggests that occasionally, the petroleum > market fails catastrophically, and when that happens, you can't buy > whatever you want/need from "the market". And in times of serious shortage government resorted to "needs based" distribution of petrol and other resources (coffee, sugar, wood). There have been times where people got gasoline vouchers or chits that they could use to purchase a rationed amount of gasoline. The average family guy got so many, a furniture store got more, and a farmer got even more. This would suggest to me that when there is an actual shortage even our venerable US government saw the need of "needs based" distribution rather than just making resources available to the wealthy. > > > > It's allocated based on who can pay for it > > and who can get to the pump first, based on my recent experience. > > > and the market sorts out that > > price. ?IP addresses are a unique resource that happens to be allocated > > based on need. > > That's right, and I think it should stay that way. Needs based > resource allocation has been a "crowdsourced" policy for several > decades. I see no reason to junk the "wisdom of the crowd" because we > are approaching scarcity. > > > ?There's not many limited resources out there that are like > > that. > > Agreed. > > > -- > Cheers, > > McTim > "A name indicates what we seek. An address indicates where it is. A > route indicates how we get there."? Jon Postel > _______________________________________________ > 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 Thu May 5 16:18:41 2011 From: kkargel at polartel.com (Kevin Kargel) Date: Thu, 5 May 2011 15:18:41 -0500 Subject: [arin-ppml] Serious question for the list. In-Reply-To: References: <723D48A257C34BA0BD60F16130F4844F@mike><4DC2DB9B.2020908@umn.edu> <4DC2E22A.50708@umn.edu> <4DC2EB16.4070904@ipinc.net> <4DC2F053.2090002@ipinc.net> Message-ID: <8695009A81378E48879980039EEDAD289D0E5BDA@MAIL1.polartel.local> Mike, I agree and wholeheartedly support your privilege if not responsibility to educate the public on matters you consider important, whether that be IP/ARIN or AIDS or animal rights or whatever is important to you. Organizing a protest flood to swamp the list would be tantamount to a verbal DoS and while probably legal would be ethically wrong and counterproductive. Just my humble opinion. Kevin > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf Of Mike Burns > Sent: Thursday, May 05, 2011 1:51 PM > To: Ted Mittelstaedt > Cc: arin-ppml at arin.net > Subject: Re: [arin-ppml] Serious question for the list. > > Hi Ted, > > Okay, I understand what you mean, and where the line should be drawn in > terms of solicitation for participation. > I shouldn't go out and make mass mailings or robotic postings or go to > specific forums and try to stir up the population to jump on and vote for > my > proposal. > But if I had a blog or something, I could write about the issue and ask > the > readers to participate in the list generally, but not just to jump on one > proposal that might suit them ideologically or emotionally. > > I would say that is pretty close to my own opinion. > > Regards, > > Mike > > > ----- Original Message ----- > From: "Ted Mittelstaedt" > To: "Mike Burns" > Cc: > Sent: Thursday, May 05, 2011 2:45 PM > Subject: Re: [arin-ppml] Serious question for the list. > > > > On 5/5/2011 11:30 AM, Mike Burns wrote: > >> Hi Ted, > >> > >> Thanks for the input. > >> I understand what you are saying about the dangers of the unwashed. > >> What about a blog? > >> Do you think it would be okay to advocate a position in blog and > solicit > >> participation on the list? > >> > > > > It's always OK to solicit participation in the list. But the key word > > here is "participation" > > > > Writing an article to tell people to subscribe just over some point > issue > > and flood the mailing list isn't participation. If they are going > > to participate, then they better be here for the long run. There's a > > lot of other stuff that we deal with. > > > > Ted > > > >> Regards, > >> Mike > >> > >> ----- Original Message ----- From: "Ted Mittelstaedt" > >> To: > >> Sent: Thursday, May 05, 2011 2:23 PM > >> Subject: Re: [arin-ppml] Serious question for the list. > >> > >> > >>> On 5/5/2011 11:02 AM, Mike Burns wrote: > >>>> It seems to me that the decision about needs analysis for transfers > may > >>>> have some large non-technical components, like one's view of the role > >>>> of > >>>> markets in allocating scarce resources. > >>>> Yes, there are issues of deaggregation, which are too technical for > the > >>>> layman. > >>>> Yes, there is a danger of overburdening the policy development > system, > >>>> not something anyone would want. > >>>> But do we want a technical elite making decisions that are not really > >>>> technical, like the value of unrestricted versus restricted markets? > >>> > >>> No, we do not. > >>> > >>>> Are we inside an ivory tower? > >>>> > >>> > >>> No, but there is a proper way to bring the general public into the > >>> decision making in a large volume. > >>> > >>> There isn't (in my opinion) a problem with posting in a rag like > >>> the Libertarian Times or some such, that a mailing list like ppml > >>> EXISTS. The very few members of the general public who waste their > >>> time with that stuff and who are at all competent and really care > >>> about the issue will investigate, make themselves fully aware of > >>> all of the arguments on all sides of the issue, as well as look > >>> up the rules for the ppml list (which I will remind everyone, > >>> ARIN owns and makes the rules on) then join and contribute in > >>> a positive way. > >>> > >>> But the majority of the members of the general public who waste > >>> their time with that stuff and who are NOT competent will find the > >>> bar of actually having to look up the instructions for posting > >>> and rules for joining too difficult to master, and will stay away. > >>> > >>> Unless, that is, the poster of the article in the Libertarian Times > >>> gives an explicit step-by-step set of instructions for how to > >>> go about subscribing, that a blind monkey could follow. > >>> > >>> If you really and truly want to bring people into the decision > >>> making process who are too ignorant to google up "ppml mailing list" > >>> then the proper way is via publishing a survey in the ragazine. > >>> > >>> The author of the article in the Libertarian Times can create a > >>> dumbed-down survey on someplace like survey.com or whatever, that > >>> the ignoramuses can comprehend. > >>> > >>> Then we can get the feedback from the unwashed masses without > >>> being drowned in an onslaught of 5000 fools wanting to know what > >>> an IP address is and why we can't make more of them. > >>> > >>> But, to save you the time I can predict what the general public > >>> will say in advance - boiled down: > >>> > >>> "I want what I have to stay the same and I don't give a damn > >>> if it staying the same prevents 3/4 of the people in the world > >>> who aren't on the Internet now, from ever getting on it. I > >>> got mine, Jack, and screw the rest of them." > >>> > >>> Ted > >>> > >>>> Regards, > >>>> Mike > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> ----- Original Message ----- From: "David Farmer" > >>>> To: "Martin Hannigan" > >>>> Cc: "Mike Burns" ; ; > "David > >>>> Farmer" > >>>> Sent: Thursday, May 05, 2011 1:45 PM > >>>> Subject: Re: [arin-ppml] Serious question for the list. > >>>> > >>>> > >>>>> On 5/5/11 12:25 CDT, Martin Hannigan wrote: > >>>>>> On Thu, May 5, 2011 at 1:17 PM, David Farmer wrote: > >>>>>>> On 5/5/11 11:49 CDT, Mike Burns wrote: > >>>>>>>> > >>>>>>>> Hi all, > >>>>>>>> I have had an idea. > >>>>>>>> Since it has been determined that everybody in the ARIN community > >>>>>>>> with > >>>>>>>> an email address may participate in policy development, how does > >>>>>>>> the > >>>>>>>> list feel about soliciting the input from a broader group of > >>>>>>>> participants? > >>>>>>> > >>>>>>> While not an absolute requirement, I believe there is an > >>>>>>> understanding that > >>>>>>> some minimal level of technical expertise and interest in the > >>>>>>> details of > >>>>>>> the subject matter are necessary in order to provide useful or > >>>>>>> meaningful > >>>>>>> contribution to the process. > >>>>>>> > >>>>>> > >>>>>> So we would exclude members of the general public (users) then? > >>>>> > >>>>> Where did I say exclude? "not an absolute requirement", an "interest > >>>>> in the details" are needed for a "meaningful contribution". None of > >>>>> that means exclude in my book, it simply means that participation > >>>>> takes effort and if you want people to take you seriously you need > to > >>>>> make a effort. That is true in many parts of civil society. > >>>>> > >>>>> -- > >>>>> =============================================== > >>>>> 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. > >>> > >>> _______________________________________________ > >>> 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 jeffrey.lyon at blacklotus.net Thu May 5 16:19:56 2011 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Thu, 5 May 2011 16:19:56 -0400 Subject: [arin-ppml] ARIN-prop-146 Clarify Justified Need for Transfers In-Reply-To: <8695009A81378E48879980039EEDAD289D0E5BD9@MAIL1.polartel.local> References: <4DBEF120.4080901@arin.net> <88F39B20-5C20-45F0-AD61-5FA1E7F84CE3@delong.com> <3FCD1FDC-ECEE-4C9B-95C6-59E03D3C314E@matthew.at> <5598DFC7-E320-42FA-AA0E-C91C076BD725@delong.com> <6BA1EAA6-7D9C-44F9-BED7-884720F4B3BE@matthew.at> <05FAA29B-37BE-411C-95A4-50437602C8ED@delong.com> <4DBF6727.1090303@matthew.at> <097AAC1C-1F68-4820-9274-3290ADEFA195@delong.com> <4DBF75B7.3010407@matthew.at> <9501EA7E-FDAD-4DDA-B9E8-08C2811FF642@delong.com> <4DBF82F6.7050608@matthew.at> <20110503145144.N15967@mail.inlandnet.com> <4DC084E7.5000302@matthew.at> <4DC08664.4060905@matthew.at> <4791A59E-8864-483C-9BB0-03A6A5B8D50C@delong.com> <66466F57-4365-4ADB-94EB-E023F01B17CB@delong.com> <30D12BA8-9A6C-4E62-9A67-8B4FEA0EA8C1@matthew.at> <00af01cc0aa7$845a5330$8d0ef990$@net> <8695009A81378E48879980039EEDAD289D0E5BD9@MAIL1.polartel.local> Message-ID: On Thu, May 5, 2011 at 4:02 PM, Kevin Kargel wrote > This would suggest to me that when there is an actual shortage even our venerable US government saw the need of "needs based" distribution rather than just making resources available to the wealthy. Then there are those of us who believe that we would all be a lot more affluent if the government would stop reacting to market conditions and let them sort themselves out. -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications - AS32421 First and Leading in DDoS Protection Solutions From mike at nationwideinc.com Thu May 5 16:30:48 2011 From: mike at nationwideinc.com (Mike Burns) Date: Thu, 5 May 2011 16:30:48 -0400 Subject: [arin-ppml] ARIN-prop-146 Clarify Justified Need for Transfers References: <4DBEF120.4080901@arin.net><88F39B20-5C20-45F0-AD61-5FA1E7F84CE3@delong.com><3FCD1FDC-ECEE-4C9B-95C6-59E03D3C314E@mat 5A4-50437602C8ED@delong.com><4DBF6727.1090303@matthew.at><097AAC1C-1F68-4820-9274-3290ADEFA195@delong.com><4DBF75B7.3010407@mat thew.at><9501EA7E-FDAD-4DDA-B9E8-08C2811FF642@delong.com><4DBF82F6.7050608@matthew.at><20110503145144.N15967@mail.inlandnet.com> <4DC084E7.5000302@matthew.at><4DC08664.4060905@matthew.at><4791A59E-8864-483C-9BB0-03A6A5B8D50C@delong.com><66466F57-4365-4ADB-94EB-E023F01B17CB@delong.com><30D12BA8-9A6C-4E62-9A67-8B4FEA0EA8C1@matthew.at> <00af01cc0aa7$845a5330$8d0ef990$@net> <8695009A81378E48879980039EEDAD289D0E5BD9@MAIL1.polartel.local> Message-ID: <5542F2FC72CC4995A4205A4C1C844F5E@mike> >And in times of serious shortage government resorted to "needs based" >distribution of petrol and other resources (coffee, sugar, wood). There >have been times where people got gasoline vouchers or chits that they > >could use to purchase a rationed amount of gasoline. The average family >guy got so many, a furniture store got more, and a farmer got even more. >This would suggest to me that when there is an actual shortage even our >venerable US government saw the need of "needs based" distribution rather >than just making resources available to the wealthy. >Mc Tim When exhaust happens, even if you have need, you are going to have to pay the price required for somebody to sell to you instead of to another person with need, according to current policy. Attested need will only be the price of entry to the "ARIN auction". It won't change the fact that you will have to outbid all the other needers. Unless you are proposing that ARIN go to a policy like at APNIC where the remains of the free pool are rationed, and you can only get a certain maximum amount. Regards, Mike From mike at nationwideinc.com Thu May 5 16:43:05 2011 From: mike at nationwideinc.com (Mike Burns) Date: Thu, 5 May 2011 16:43:05 -0400 Subject: [arin-ppml] Draft proposal that needs some wordsmithing Message-ID: <9638601B94304E4392112CF98CDE757C@mike> Hi list, I tried to put together a proposal to end needs requirements for transfers and I used the APNIC policy as a framework. The problem is that as the proposal is structured below, there is a problem with the application of ARIN Resource Review policies in section 12. Even if the transfer happens without regard to need, since the transferred resources would be received by an ARIN account holder and would be subject to ARIN's policies, then ARIN could feasibly do a resource review immediately post transfer to effectively retain a needs requirement. My intent is that ARIN resource reviews continue to happen for purposes other than need. So for fraud, for hijackings, for failure to pay ARIN's bills, I support resource review and recovery. But not for need. I was hoping not to have to mess with section 12 of the NRPM. Can somebody suggest a way to modify my draft proposal to effect my intent in a graceful manner which doesn't require modifications to section 12? Thanks for any help you can offer on this matter or any other issues related to this draft. Regards, Mike 1. Policy Proposal Name: New IPv4 Transfer policy 2. Proposal Originator: a. Name: Mike Burns b. Email: mike at sum.net c. Phone: 1-863-494-7692 x105 d. Organization: Nationwide Computer Systems 3. Proposal Version: 1 4. Date: May 5th, 2011 5. Proposal type: modify 6. Policy term: permanent 7. Policy statement: Replace Section 8 with 8.ARIN will process and record IPv4 address transfer requests. Conditions on the IPv4 address block: - The minimum transfer size is a /24 - The address block must be in the range of addresses administered by ARIN Conditions on source of the transfer: - The source entity must be the current rights 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 the transfer, or until the exhaustion of ARIN's IPv4 space, whichever occurs first. Conditions on recipient of the transfer: - The recipient entity must be a current ARIN account holder. - The recipient entity of the transferred resources will be subject to current ARIN policies. In particular, in any subsequent ARIN IPv4 address allocation request, the recipient will be required to account for the efficient utilization of all IPv4 address space held, including all transferred resources. 8. Rationale: Current ARIN policies relating to the registration of transfer of address holdings limit the eligibility of registration of transfers to those relating to mergers and acquisitions of entities that are administering an operational network, or to those who agree to sign either an RSA or LRSA with ARIN and subject the buyer to needs analysis and the seller to a potential ARIN audit. It is currently anticipated that the IPv4 unallocated address pool will be exhausted within a couple of years at ARIN, and earlier than that in other regions, and the transition to IPv6-based service delivery is likely to take longer than the remaining period of unallocated address availability. Accordingly, it is likely that demand for IPv4 addresses will continue beyond the time of unallocated address pool exhaustion, leading to a period of movement of IPv4 address blocks between address holders to meet such continuing demand for IPv4 address blocks. The underlying proposition behind this policy proposal is that the registry of IPv4 addresses operated by ARIN is of general utility and value only while it accurately describes the current state of address distribution. If a class of address movement transactions are excluded from being entered in the registry, then the registry will have decreasing value to the broader community, and the integrity of the network itself is thereby compromised. This proposal's central aim is to ensure the continuing utility and value of the ARIN address registry by allowing the registry to record transactions where IPv4 addresses are transfered between ARIN account holders. It proposes that ARIN will recognise and register a transfer of addresses where the parties to the transfer are 'known' to ARIN and that the address block being transferred is part of ARIN's current address set. The proposal does not prescribe how such transfers may occur, nor impose any further constraints on the transfer or on the parties involved other than those described in this proposal. 9. Timetable for implementation: immediate. -------------- next part -------------- An HTML attachment was scrubbed... URL: From lar at mwtcorp.net Thu May 5 16:55:09 2011 From: lar at mwtcorp.net (Larry Ash) Date: Thu, 05 May 2011 14:55:09 -0600 Subject: [arin-ppml] ARIN-prop-146 Clarify Justified Need for Transfers In-Reply-To: References: Message-ID: On Thu, 5 May 2011 14:12:14 -0400 "Sweeting, John" wrote: > A large percentage of the price of a gallon of gas is attributable to >Speculators, companies that never even take ownership of the oil, they just >buy it and sell before it is even shipped. > > +++ > > > On 5/5/11 1:24 PM, "Owen DeLong" wrote: > >> >> Based on the fact that you call it "petrol," i'll assume you're not in >> the United States. My trips to the gas station take about < 5 minutes. >> I would call that a testament to the free market. >> > As near as I can tell based on significant travel, gasoline or petrol > prices are quite artificially low in the united States compared to the > rest of the world. I don't actually know why that is, but, I would say > that the energy companies in the US are some of the best examples > of free market dysfunction that are available. > Actually there is nothing to be learned about free markets in the oil industry as it stands today. It is heavily regulated and manipulated by many of the governments of the world (and others). The oil markets have been raided by speculators at times but their effect is very difficult to determine. Most (but not all) oil speculators end up broke. Fuel prices are a political consideration in almost every country in the world. If ip was oil there would still be a /2 left and we would have this argument in a different context. (There is a LOT more oil than you might think.) > My trips to the gas station take between 5 and 45 minutes, depending > on the length of the line. The price of gasoline fluctuates randomly > and is obviously detached from the realities of the costs of the raw > materials. The price only drops significantly after it has risen so much > so rapidly that there is public outcry and congress starts to seriously > consider additional regulation of the industry. Then it drops just enough > to silence the cries for regulation. > >> But in all fairness, all governments have their hands in the cookie >> jar. Your government more so from what I can tell. >> > There are a number of possible explanations outside of the government's > hand in the cookie jar for the disparity in experiences at the gas pump. > > Owen > The real problem here is that some people don't like the policies that control IPv4 number assignments/transfers. They were derived by community consensus and the alternative registry is just a way to get around that. Sorry but that shouldn't happen. Even if competing registries were allowed they should be bound by regional policies. Personally I can't say I like all of the policies either but that is how consensus works. In it's simplest form a registry is a "spreadsheet" of assigned and unassigned numbers and who has them. We long ago added a method for the community to "look-up" that information and added contact information for ease of administration and as part of the "deal" we all have. "I'll let your traffic on my network if you'll let mine on yours" Obviously things are a bit more complex now but the idea is the same. A bunch of competing spreadsheets is chaos not a free market (IMHO). The hue and cry that arose from the recent IPv4 transfer shows that community consensus has not been reached for transfers. Do we really want a free market for IPv4 transfers? If so we need to look carefully at: a)Single aggregate requirement (if it exists) b)What level of need is necessary when IPv4 addresses have a real cost. c)Exactly what happens if a transfer fails. It seems to me that this is where we need to concentrate and let the "competitive spreadsheets" go. As for Prop-146 and Prop-147 +1 POC CBS-129 Larry Ash Network Administrator Mountain West Telephone 123 W 1st St. Casper, WY 82601 Office 307 233-8387 From owen at delong.com Thu May 5 17:40:15 2011 From: owen at delong.com (Owen DeLong) Date: Thu, 5 May 2011 14:40:15 -0700 Subject: [arin-ppml] ARIN-prop-146 Clarify Justified Need for Transfers In-Reply-To: <4DC2F593.40006@matthew.at> References: <4DBEF120.4080901@arin.net> <4DBF6727.1090303@matthew.at> <097AAC1C-1F68-4820-9274-3290ADEFA195@delong.com> <4DBF75B7.3010407@matthew.at> <9501EA7E-FDAD-4DDA-B9E8-08C2811FF642@delong.com> <4DBF82F6.7050608@matthew.at> <20110503145144.N15967@mail.inlandnet.com> <4DC084E7.5000302@matthew.at> <4DC08664.4060905@matthew.at> <4791A59E-8864-483C-9BB0-03A6A5B8D50C@delong.com> <66466F57-4365-4ADB-94EB-E023F01B17CB@delong.com> <30D12BA8-9A6C-4E62-9A67-8B4FEA0EA8C1@matthew.at> <00af01cc0aa7$845a5330$8d0ef990$@net> <4E2819E2-DFF8-4A4E-AEC8-0BF07977EE5B@delong.com> Message-ID: <80DC3F45-49FE-4C48-853B-2916E2B3F894@delong.com> On May 5, 2011, at 12:08 PM, Matthew Kaufman wrote: > On 5/5/2011 11:54 AM, Owen DeLong wrote: >> >> If you can somehow convince me that more open transfer policies >> would reduce, rather than inflict pain upon the community, then, I >> would support them. > > This particular policy proposal reduces the pain on recent and new entrants in exchange for what might be a very slight additional pain (in that the recent and new entrants would be bidding against them) on the existing holders of IPv4 space who might need more. > I am not convinced this is entirely accurate, but, I can at least see why you believe it to be true. > I'm concerned that when you say "the community" you mean "people who've had IPv4 space for a long time" or even "ISP members of ARIN". > I assure you that is not the case. When I say "the community" I do literally mean anyone who has or needs an address. However, I do give greater weight to present need than to future theoretical need. This policy proposal would reverse that weighting. > Note that even concerns about routing table size increases (which this policy either won't affect or will actually cause reductions by reducing the number of transfers needed by a new or existing entrant) are really a pain experienced primarily by long-time ISP members (who have more routers holding full tables)... and so any talk about how routing table size increases hurt "the community" clearly shows this bias. > Generally, I consider this particular proposal to be mostly routing-table neutral. My comments about routing table size impacts have been related to the free-market argument that has gotten conflated in this subject thread. Owen From owen at delong.com Thu May 5 17:35:42 2011 From: owen at delong.com (Owen DeLong) Date: Thu, 5 May 2011 14:35:42 -0700 Subject: [arin-ppml] ARIN-prop-146 Clarify Justified Need for Transfers In-Reply-To: References: <4DBEF120.4080901@arin.net> <88F39B20-5C20-45F0-AD61-5FA1E7F84CE3@delong.com> <3FCD1FDC-ECEE-4C9B-95C6-59E03D3C314E@matthew.at> <5598DFC7-E320-42FA-AA0E-C91C076BD725@delong.com> <6BA1EAA6-7D9C-44F9-BED7-884720F4B3BE@matthew.at> <05FAA29B-37BE-411C-95A4-50437602C8ED@delong.com> <4DBF6727.1090303@matthew.at> <097AAC1C-1F68-4820-9274-3290ADEFA195@delong.com> <4DBF75B7.3010407@matthew.at> <9501EA7E-FDAD-4DDA-B9E8-08C2811FF642@delong.com> <4DBF82F6.7050608@matthew.at> <20110503145144.N15967@mail.inlandnet.com> <4DC084E7.5000302@matthew.at> <4DC08664.4060905@matthew.at> <4791A59E-8864-483C-9BB0-03A6A5B8D50C@delong.com> <66466F57-4365-4ADB-94EB-E023F01B17CB@delong.com> <30D12BA8-9A6C-4E62-9A67-8B4FEA0EA8C1@matthew.at> <00af01cc0aa7$845a5330$8d0ef990$@net> <4E2819E2-DFF8-4A4E-AEC8-0BF07977EE5B@delong.com> Message-ID: <79A64504-298A-4B4C-8B12-A87B17EA2BE0@delong.com> On May 5, 2011, at 12:03 PM, Jeffrey Lyon wrote: >> If you can somehow convince me that more open transfer policies >> would reduce, rather than inflict pain upon the community, then, I >> would support them. >> >> Owen >> >> > > The basic arguments in support of free markets, generally, have been > made. You're accustomed to a system which has always worked well, so > you don't see a reason to change it. I don't really see a benefit to > trying to change your mind as I don't believe that you will view this > as a good idea unless you actually were to see it at work. > I think this is likely correct. In general, however, I think that my experience with market dysfunction and my perspective there is not limited to IPv4 markets. > You are perhaps one of the most substantial and well known IPv6 > proponents in the world, as is your employer. Naturally, you're going > to see IPv6 as the solution rather than free markets. Your employer is > going to be one of the very few companies that will not suffer from > IPv4 exhaustion so I don't expect you to want to support a measure > that would prolong the life of IPv4. > Au contraire. I am all for reducing the pain of IPv4 as much as possible and my role on the AC is not governed by what will benefit me personally or what will benefit my employer. I think if you review my record on PPML and on the AC you will find that I have consistently voted for what I thought was best for the community even when I have expressed the fact that a contrary vote would benefit myself or my employer. If I thought that a more open IPv4 market would reduce pain in the industry in general, I would support it. However, my observation and experience with laissez faire markets in other endeavors has led me to believe that as applied to this situation such a market would increase, not reduce the pain felt by the community overall. > We both support IPv6. The major difference is that you started a > decade ago and I started one year ago. Accordingly, I am more > sympathetic to companies who have not made the appropriate plans. You may be more sympathetic, but, I doubt you are any more willing to help them in any way feasible. I would be happy to help them through more liberalized transfer policies if I felt that would help them. My belief at this time is that the reverse is true, that it would harm more than help. Owen From farmer at umn.edu Thu May 5 17:48:49 2011 From: farmer at umn.edu (David Farmer) Date: Thu, 05 May 2011 16:48:49 -0500 Subject: [arin-ppml] Draft proposal that needs some wordsmithing In-Reply-To: <9638601B94304E4392112CF98CDE757C@mike> References: <9638601B94304E4392112CF98CDE757C@mike> Message-ID: <4DC31B41.3090001@umn.edu> On 5/5/11 15:43 CDT, Mike Burns wrote: > Hi list, > I tried to put together a proposal to end needs requirements for > transfers and I used the APNIC policy as a framework. > The problem is that as the proposal is structured below, there is a > problem with the application of ARIN Resource Review policies in section 12. > Even if the transfer happens without regard to need, since the > transferred resources would be received by an ARIN account holder and > would be subject to ARIN's policies, then ARIN could feasibly do a > resource review immediately post transfer to effectively retain a needs > requirement. > My intent is that ARIN resource reviews continue to happen for purposes > other than need. > So for fraud, for hijackings, for failure to pay ARIN's bills, I support > resource review and recovery. > But not for need. > I was hoping not to have to mess with section 12 of the NRPM. Can > somebody suggest a way to modify my draft proposal to effect my intent > in a graceful manner which doesn't require modifications to section 12? What if we don't eliminate resource reviews for IPv4, but in the case of a finding of unused IPv4 resource the resource must be transferred to someone who will put them into use within 12 month or they must be returned. Basically allow the market to operate freely, but enforce results based regulation on the system. Use the resources, find someone else who will, or return them to the pool so ARIN can allocate them. Just trying to think outside the box here. If we could find a way to make something like that work I might I might be willing to go for non-needs based transfers. You get the intent of the needs basis on the backside instead of on the front-side. I think we might end up with what we both want in a system like that. But, there is another issue too; You are completely replacing all of section 8 with something that only allow for the the transfer of IPv4 addresses. We need to retain the general M&A transfer policy because that allows for transfer of IPv6 and ASNs in those cases. Even if we were to completely abandon needs basis for IPv4, which I'm not convinced of yet, I'm completely unconvinced that we want to do that for IPv6 and ASNs, and I haven't heard you arguing for that anyway. -- =============================================== 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 owen at delong.com Thu May 5 17:52:13 2011 From: owen at delong.com (Owen DeLong) Date: Thu, 5 May 2011 14:52:13 -0700 Subject: [arin-ppml] Fw: Accusationof fundamentalconflictofinterest/IPaddress policypitched directly to ICANN In-Reply-To: <4DC2FCC6.8040509@abenaki.wabanaki.net> References: <379DB08FB5564ED88230C1B6D6AE80FE@mike> <8695009A81378E48879980039EEDAD289D0E5BC6@MAIL1.polartel.local> <6B65D21B9B7543208304CC44EDD22444@mike> <3DA6DC8B-ADC6-4BCB-83BA-5F07BC5682C7@delong.com> <9D762F7D6FE3419790C6E47F58A1D4D5@mike> <4BEDC361E6D04A7292F5A294FA4FC2FE@mike> <197A4DE3-3155-4411-B5EE-7A0A74D05A4A@delong.com> <4DC2FCC6.8040509@abenaki.wabanaki.net> Message-ID: <25EEF0D8-C11D-47F3-A210-41F25E3F1C60@delong.com> On May 5, 2011, at 12:38 PM, Eric Brunner-Williams wrote: > On 5/5/11 2:04 PM, Owen DeLong wrote: >> >> I'm not a lawyer, either, but I suspect that the courts may well >> decide that authority comes from >> the DoC contract. The question, however, is ... > > i suggest that prior to the contractual interpretive question there is a question we've let lie for a decade. what is the nature of the new entity? is it exercising delegated rule making authority, and so subject to the administrative procedure act of 1946, and if not, what is the nature of that authority? For ICANN, I have no idea. For ARIN and the other RIRs, I believe they are standard non-profit business organizations which are common in many different industries such as the Compressed Gas Association which defines, among other things, standards for compressed gas cylinder valves and fittings. Owen From hannigan at gmail.com Thu May 5 17:58:17 2011 From: hannigan at gmail.com (Martin Hannigan) Date: Thu, 5 May 2011 17:58:17 -0400 Subject: [arin-ppml] Serious question for the list. In-Reply-To: <4DC2E22A.50708@umn.edu> References: <723D48A257C34BA0BD60F16130F4844F@mike> <4DC2DB9B.2020908@umn.edu> <4DC2E22A.50708@umn.edu> Message-ID: On Thu, May 5, 2011 at 1:45 PM, David Farmer wrote: > On 5/5/11 12:25 CDT, Martin Hannigan wrote: >> >> On Thu, May 5, 2011 at 1:17 PM, David Farmer ?wrote: >>> >>> On 5/5/11 11:49 CDT, Mike Burns wrote: >>>> >>>> Hi all, >>>> I have had an idea. >>>> Since it has been determined that everybody in the ARIN community with >>>> an email address may participate in policy development, how does the >>>> list feel about soliciting the input from a broader group of >>>> participants? >>> >>> While not an absolute requirement, I believe there is an understanding >>> that >>> some minimal ?level of technical expertise and interest in the details of >>> the subject matter are necessary in order to provide useful or meaningful >>> contribution to the process. >>> >> >> So we would exclude members of the general public (users) then? > > Where did I say exclude? ?"not an absolute requirement", an "interest in the > details" are needed for a "meaningful contribution". ?None of that means > exclude in my book, it simply means that participation takes effort and if > you want people to take you seriously you need to make a effort. ?That is > true in many parts of civil society. "Not an absolute requirement" would generally translate to "not important". Not all proposals related to IP addressing require technical knowledge. Some are business oriented such as the proposal to provide address for critical infrastructure for 36 mos. I would argue that technical contributions are "not an absolute requirement" to proposals such as M&A and a few others and are actually harmful when co-mingled with most technical requirements beyond extremely simply and straight forward non engineering concepts like utilization. Best, -M< From owen at delong.com Thu May 5 18:02:10 2011 From: owen at delong.com (Owen DeLong) Date: Thu, 5 May 2011 15:02:10 -0700 Subject: [arin-ppml] ARIN-prop-146 Clarify Justified Need for Transfers In-Reply-To: References: <4DBEF120.4080901@arin.net> <88F39B20-5C20-45F0-AD61-5FA1E7F84CE3@delong.com> <3FCD1FDC-ECEE-4C9B-95C6-59E03D3C314E@matthew.at> <5598DFC7-E320-42FA-AA0E-C91C076BD725@delong.com> <6BA1EAA6-7D9C-44F9-BED7-884720F4B3BE@matthew.at> <05FAA29B-37BE-411C-95A4-50437602C8ED@delong.com> <4DBF6727.1090303@matthew.at> <097AAC1C-1F68-4820-9274-3290ADEFA195@delong.com> <4DBF75B7.3010407@matthew.at> <9501EA7E-FDAD-4DDA-B9E8-08C2811FF642@delong.com> <4DBF82F6.7050608@matthew.at> <20110503145144.N15967@mail.inlandnet.com> <4DC084E7.5000302@matthew.at> <4DC08664.4060905@matthew.at> <4791A59E-8864-483C-9BB0-03A6A5B8D50C@delong.com> <66466F57-4365-4ADB-94EB-E023F01B17CB@delong.com> <30D12BA8-9A6C-4E62-9A67-8B4FEA0EA8C1@matthew.at> <00af01cc0aa7$845a5330$8d0ef990$@net> <8695009A813! 78E48879980039EEDAD289D0E5BD9@MAIL1.polartel.local> Message-ID: On May 5, 2011, at 1:19 PM, Jeffrey Lyon wrote: > On Thu, May 5, 2011 at 4:02 PM, Kevin Kargel wrote >> This would suggest to me that when there is an actual shortage even our venerable US government saw the need of "needs based" distribution rather than just making resources available to the wealthy. > > Then there are those of us who believe that we would all be a lot more > affluent if the government would stop reacting to market conditions > and let them sort themselves out. > There are also those that believe in the Easter Bunny, Santa Clause, and the Bogey-Man. There are those who favor "enhanced interrogation techniques" and those who believe that torture is wrong no matter what euphemism you choose to apply. Of all of these, only the last paragraph lacks overwhelming contradictory evidence in as it is more a moral choice than a question of measurable efficacy, though the efficacy of torture is also subject to debate. Owen From owen at delong.com Thu May 5 18:04:54 2011 From: owen at delong.com (Owen DeLong) Date: Thu, 5 May 2011 15:04:54 -0700 Subject: [arin-ppml] ARIN-prop-146 Clarify Justified Need for Transfers In-Reply-To: <5542F2FC72CC4995A4205A4C1C844F5E@mike> References: <4DBEF120.4080901@arin.net><88F39B20-5C20-45F0-AD61-5FA1E7F84CE3@delong.com><3FCD1FDC-ECEE-4C9B-95C6-59E03D3C314E@mat 5A4-50437602C8ED@delong.com><4DBF6727.1090303@matthew.at><097AAC1C-1F68-4820-9274-3290ADEFA195@delong.com><4DBF75B7.3010407@mat thew.at><9501EA7E-FDAD-4DDA-B9E8-08C2811FF642@delong.com><4DBF82F6.7050608@matthew.at><20110503145144.N15967@mail.inlandnet.com> <4DC084E7.5000302@matthew.at><4DC08664.4060905@matthew.at><4791A59E-8864-483C-9BB0-03A6A5B8D50C@delong.com><66466F57-4365-4ADB-94EB-E023F01B17CB@delong.com><30D12BA8-9A6C-4E62-9A67-8B4FEA0EA8C1@matthew.at> <00af01cc0aa7$845a5330$8d0ef990$@net> <8695009A81378E48879980039EEDAD289D0E5BD9@MAIL1.polartel.local> <5542F2FC72CC4995A4205A4C1C844F5E@mike> Message-ID: <143F9033-E24B-45A9-870C-3678B5E42398@delong.com> On May 5, 2011, at 1:30 PM, Mike Burns wrote: > >> And in times of serious shortage government resorted to "needs based" distribution of petrol and other resources (coffee, sugar, wood). There have been times where people got gasoline vouchers or chits that they >could use to purchase a rationed amount of gasoline. The average family guy got so many, a furniture store got more, and a farmer got even more. > >> This would suggest to me that when there is an actual shortage even our venerable US government saw the need of "needs based" distribution rather than just making resources available to the wealthy. > >> Mc Tim > > > When exhaust happens, even if you have need, you are going to have to pay the price required for somebody to sell to you instead of to another person with need, according to current policy. Yes, vs. the price required to prevent sale to a speculator without need which will likely be significantly higher. > Attested need will only be the price of entry to the "ARIN auction". I would say it is the requirement to walk away from the auction with the goods rather than the entry into the auction. Additionally, I would say that it is not the ARIN auction, ARIN is merely the company registering the transactions as they are completed. > It won't change the fact that you will have to outbid all the other needers. True. What it does is remove the non-needers from the pool of people you have to out-bid. What I don't understand is how adding non-needers to the pool would help. Owen From jeffrey.lyon at blacklotus.net Thu May 5 18:09:03 2011 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Thu, 5 May 2011 18:09:03 -0400 Subject: [arin-ppml] ARIN-prop-146 Clarify Justified Need for Transfers In-Reply-To: <143F9033-E24B-45A9-870C-3678B5E42398@delong.com> References: <4DBEF120.4080901@arin.net> <88F39B20-5C20-45F0-AD61-5FA1E7F84CE3@delong.com> <4DBF6727.1090303@matthew.at> <097AAC1C-1F68-4820-9274-3290ADEFA195@delong.com> <9501EA7E-FDAD-4DDA-B9E8-08C2811FF642@delong.com> <4DBF82F6.7050608@matthew.at> <20110503145144.N15967@mail.inlandnet.com> <4DC084E7.5000302@matthew.at> <4DC08664.4060905@matthew.at> <4791A59E-8864-483C-9BB0-03A6A5B8D50C@delong.com> <66466F57-4365-4ADB-94EB-E023F01B17CB@delong.com> <30D12BA8-9A6C-4E62-9A67-8B4FEA0EA8C1@matthew.at> <00af01cc0aa7$845a5330$8d0ef990$@net> <8695009A81378E48879980039EEDAD289D0E5BD9@MAIL1.polartel.local> <5542F2FC72CC4995A4205A4C1C844F5E@mike> <143F9033-E24B-45A9-870C-3678B5E42398@delong.com> Message-ID: > True. What it does is remove the non-needers from the pool of people you > have to out-bid. What I don't understand is how adding non-needers to the > pool would help. Speculators aid market liquidity. -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications - AS32421 First and Leading in DDoS Protection Solutions From owen at delong.com Thu May 5 18:10:04 2011 From: owen at delong.com (Owen DeLong) Date: Thu, 5 May 2011 15:10:04 -0700 Subject: [arin-ppml] Draft proposal that needs some wordsmithing In-Reply-To: <9638601B94304E4392112CF98CDE757C@mike> References: <9638601B94304E4392112CF98CDE757C@mike> Message-ID: <2886446B-00AB-4A17-B0D4-9B7D85C6B6C8@delong.com> On May 5, 2011, at 1:43 PM, Mike Burns wrote: > Hi list, > > I tried to put together a proposal to end needs requirements for transfers and I used the APNIC policy as a framework. > The problem is that as the proposal is structured below, there is a problem with the application of ARIN Resource Review policies in section 12. I would call it a feature rather than a problem, but I agree that it is contrary to your intent. > Even if the transfer happens without regard to need, since the transferred resources would be received by an ARIN account holder and would be subject to ARIN's policies, then ARIN could feasibly do a resource review immediately post transfer to effectively retain a needs requirement. > > My intent is that ARIN resource reviews continue to happen for purposes other than need. > So for fraud, for hijackings, for failure to pay ARIN's bills, I support resource review and recovery. > But not for need. > I was hoping not to have to mess with section 12 of the NRPM. Can somebody suggest a way to modify my draft proposal to effect my intent in a graceful manner which doesn't require modifications to section 12? > You could affect your intent by adding the following to your proposal: Audit: - Resources received under this policy are subject to the audits specified in section twelve, except that the needs-basis shall not constitute an ability for ARIN to reclaim or request return of resources received under this policy. However, that could have the effect on organizations that have a mixture of section 8 resources and other resources being forced to renumber into the section 8 resources to support the reclamation of their other resources that are no longer justified. I'm not sure of a good or clean way to address the case where you have resources subject to need and resources not subject to need, preserve the ability to audit, but somehow only audit need on the resources received outside of section 8 and preserve the needs-basis consideration for future resources expressed in this policy. It gets very messy very quickly trying to surgically remove needs basis from a single part of a body of policy where it has been an integral construct for the duration of that body of policy's existence. Owen > Thanks for any help you can offer on this matter or any other issues related to this draft. > > Regards, > > Mike > > > > 1. Policy Proposal Name: New IPv4 Transfer policy > > 2. Proposal Originator: > a. Name: Mike Burns > b. Email: mike at sum.net > c. Phone: 1-863-494-7692 x105 > d. Organization: Nationwide Computer Systems > > 3. Proposal Version: 1 > > 4. Date: May 5th, 2011 > > 5. Proposal type: modify > > 6. Policy term: permanent > > 7. Policy statement: > > Replace Section 8 with > > 8.ARIN will process and record IPv4 address transfer requests. > > Conditions on the IPv4 address block: > > - The minimum transfer size is a /24 > > - The address block must be in the range of addresses administered > by ARIN > > Conditions on source of the transfer: > > - The source entity must be the current rights 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 the transfer, or until the exhaustion of ARIN's > IPv4 space, whichever occurs first. > > Conditions on recipient of the transfer: > > - The recipient entity must be a current ARIN account holder. > > - The recipient entity of the transferred resources will be subject > to current ARIN policies. In particular, in any subsequent ARIN > IPv4 address allocation request, the recipient will be required > to account for the efficient utilization of all IPv4 address > space held, including all transferred resources. > > 8. Rationale: > Current ARIN policies relating to the registration of transfer of > address holdings limit the eligibility of registration of transfers to > those relating to mergers and acquisitions of entities that are > administering an operational network, or to those who agree to > sign either an RSA or LRSA with ARIN and subject the buyer > to needs analysis and the seller to a potential ARIN audit. > > It is currently anticipated that the IPv4 unallocated address pool > will be exhausted within a couple of years at ARIN, and earlier > than that in other regions, and the transition to IPv6-based service delivery > is likely to take longer than the remaining period of unallocated > address availability. Accordingly, it is likely that demand for IPv4 > addresses will continue beyond the time of unallocated address pool > exhaustion, leading to a period of movement of IPv4 address blocks > between address holders to meet such continuing demand for IPv4 > address blocks. > > The underlying proposition behind this policy proposal is that the > registry of IPv4 addresses operated by ARIN is of general utility and > value only while it accurately describes the current state of address > distribution. If a class of address movement transactions are excluded > from being entered in the registry, then the registry will have > decreasing value to the broader community, and the integrity of the > network itself is thereby compromised. This proposal's central aim is > to ensure the continuing utility and value of the ARIN address > registry by allowing the registry to record transactions where IPv4 > addresses are transfered between ARIN account holders. > > It proposes that ARIN will recognise and register a transfer of > addresses where the parties to the transfer are 'known' to ARIN and > that the address block being transferred is part of ARIN's current address set. > > The proposal does not prescribe how such transfers may occur, nor > impose any further constraints on the transfer or on the parties > involved other than those described in this proposal. > > 9. 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 mike at nationwideinc.com Thu May 5 18:12:36 2011 From: mike at nationwideinc.com (Mike Burns) Date: Thu, 5 May 2011 18:12:36 -0400 Subject: [arin-ppml] Draft proposal that needs some wordsmithing References: <9638601B94304E4392112CF98CDE757C@mike> <4DC31B41.3090001@umn.edu> Message-ID: Hi David and thanks, What about a time limit to simply sell to a separate entity upon a resource review finding of no need? Although theoretically that sale could be made to an entity who was not subject to needs analysis, if the entity is separate, I assume that most addreses in the market will find their way into use. True they could sell to a speculator, but I don't believe speculators will make up a majority of the market, which I believe will be mostly people who geniunely need IPv4 addresses. If we ensure the buyer is separate, at least they couldn't sell it to themselves, effectively. This would be a tool for ARIN to force hoarders to sell. The price for these addresses is estimated to be around $10 now, in an age of free addresses for the asking ( you know what I mean) from our RIR. If prices go up after free pool exhaust, as classic economics predicts, these things will, through sheer power of thier value, find their way to use, if the market allows them to flow freely. I just don't think the problem of hoarders is so great that it requires ARIN's energies to do resource reviews for need at all. I think the price of addresses will do that far better than the history of Section 12 recoveries suggests would happen, without the expenditure of any ARIN time or treasure. But I would call your rule the "anti-hoarding rule" for future reference, meaning the imposition of some time to transfer after a determination of no-need through existing recovery policies. You are right that I do not wish to do away with needs requirements for IPv6 or ASNs, or the 8.2 transfer policies that apply to those resources. Regards, Mike ----- Original Message ----- From: "David Farmer" To: "Mike Burns" Cc: ; "David Farmer" Sent: Thursday, May 05, 2011 5:48 PM Subject: Re: [arin-ppml] Draft proposal that needs some wordsmithing > On 5/5/11 15:43 CDT, Mike Burns wrote: >> Hi list, >> I tried to put together a proposal to end needs requirements for >> transfers and I used the APNIC policy as a framework. >> The problem is that as the proposal is structured below, there is a >> problem with the application of ARIN Resource Review policies in section >> 12. >> Even if the transfer happens without regard to need, since the >> transferred resources would be received by an ARIN account holder and >> would be subject to ARIN's policies, then ARIN could feasibly do a >> resource review immediately post transfer to effectively retain a needs >> requirement. >> My intent is that ARIN resource reviews continue to happen for purposes >> other than need. >> So for fraud, for hijackings, for failure to pay ARIN's bills, I support >> resource review and recovery. >> But not for need. >> I was hoping not to have to mess with section 12 of the NRPM. Can >> somebody suggest a way to modify my draft proposal to effect my intent >> in a graceful manner which doesn't require modifications to section 12? > > What if we don't eliminate resource reviews for IPv4, but in the case of a > finding of unused IPv4 resource the resource must be transferred to > someone who will put them into use within 12 month or they must be > returned. > > Basically allow the market to operate freely, but enforce results based > regulation on the system. Use the resources, find someone else who will, > or return them to the pool so ARIN can allocate them. Just trying to > think outside the box here. If we could find a way to make something like > that work I might I might be willing to go for non-needs based transfers. > You get the intent of the needs basis on the backside instead of on the > front-side. I think we might end up with what we both want in a system > like that. > > But, there is another issue too; > > You are completely replacing all of section 8 with something that only > allow for the the transfer of IPv4 addresses. We need to retain the > general M&A transfer policy because that allows for transfer of IPv6 and > ASNs in those cases. Even if we were to completely abandon needs basis > for IPv4, which I'm not convinced of yet, I'm completely unconvinced that > we want to do that for IPv6 and ASNs, and I haven't heard you arguing for > that anyway. > > > > -- > =============================================== > 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 matthew at matthew.at Thu May 5 18:17:46 2011 From: matthew at matthew.at (Matthew Kaufman) Date: Thu, 05 May 2011 15:17:46 -0700 Subject: [arin-ppml] ARIN-prop-146 Clarify Justified Need for Transfers In-Reply-To: <143F9033-E24B-45A9-870C-3678B5E42398@delong.com> References: <4DBEF120.4080901@arin.net><88F39B20-5C20-45F0-AD61-5FA1E7F84CE3@delong.com><3FCD1FDC-ECEE-4C9B-95C6-59E03D3C314E@mat 5A4-50437602C8ED@delong.com><4DBF6727.1090303@matthew.at><097AAC1C-1F68-4820-9274-3290ADEFA195@delong.com><4DBF75B7.3010407@mat thew.at><9501EA7E-FDAD-4DDA-B9E8-08C2811FF642@delong.com><4DBF82F6.7050608@matthew.at><20110503145144.N15967@mail.inlandnet.com> <4DC084E7.5000302@matthew.at><4DC08664.4060905@matthew.at><4791A59E-8864-483C-9BB0-03A6A5B8D50C@delong.com><66466F57-4365-4ADB-94EB-E023F01B17CB@delong.com><30D12BA8-9A6C-4E62-9A67-8B4FEA0EA8C1@matthew.at> <00af01cc0aa7$845a5330$8d0ef990$@net> <8695009A81378E48879980039EEDAD289D0E5BD9@MAIL1.polartel.local> <5542F2FC72CC4995A4205A4C1C844F5E@mike> <143F9033-E24B-45A9-870C-3678B5E42398@delong.com> Message-ID: <4DC3220A.5060801@matthew.at> On 5/5/2011 3:04 PM, Owen DeLong wrote: > > True. What it does is remove the non-needers from the pool of people you > have to out-bid. What I don't understand is how adding non-needers to the > pool would help. Please clarify how Proposal 146 adds "non-needers" to the pool, as that certainly is not the intent of the policy proposal I wrote. Matthew Kaufman From owen at delong.com Thu May 5 18:16:54 2011 From: owen at delong.com (Owen DeLong) Date: Thu, 5 May 2011 15:16:54 -0700 Subject: [arin-ppml] ARIN-prop-146 Clarify Justified Need for Transfers In-Reply-To: References: <4DBEF120.4080901@arin.net> <88F39B20-5C20-45F0-AD61-5FA1E7F84CE3@delong.com> <4DBF6727.1090303@matthew.at> <097AAC1C-1F68-4820-9274-3290ADEFA195@delong.com> <9501EA7E-FDAD-4DDA-B9E8-08C2811FF642@delong.com> <4DBF82F6.7050608@matthew.at> <20110503145144.N15967@mail.inlandnet.com> <4DC084E7.5000302@matthew.at> <4DC08664.4060905@matthew.at> <4791A59E-8864-483C-9BB0-03A6A5B8D50C@delong.com> <66466F57-4365-4ADB-94EB-E023F01B17CB@delong.com> <30D12BA8-9A6C-4E62-9A67-8B4FEA0EA8C1@matthew.at> <00af01cc0aa7$845a5330$8d0ef990$@net> <8695009A81378E48879980039EEDAD289D0E5BD9@MAIL1.polartel.local> <5542F2FC72CC4995A4205A4C1C844F5E@mike> <143F9033-E24B-45A9-870C-3678B5E42398@delong.com> Message-ID: <9296FBB7-EFA7-491B-8F20-7AC1BFD60535@delong.com> On May 5, 2011, at 3:09 PM, Jeffrey Lyon wrote: >> True. What it does is remove the non-needers from the pool of people you >> have to out-bid. What I don't understand is how adding non-needers to the >> pool would help. > > Speculators aid market liquidity. Which is a nice euphemism for "Speculators increase prices". Owen From owen at delong.com Thu May 5 18:16:16 2011 From: owen at delong.com (Owen DeLong) Date: Thu, 5 May 2011 15:16:16 -0700 Subject: [arin-ppml] Serious question for the list. In-Reply-To: References: <723D48A257C34BA0BD60F16130F4844F@mike> <4DC2DB9B.2020908@umn.edu> <4DC2E22A.50708@umn.edu> Message-ID: On May 5, 2011, at 2:58 PM, Martin Hannigan wrote: > On Thu, May 5, 2011 at 1:45 PM, David Farmer wrote: >> On 5/5/11 12:25 CDT, Martin Hannigan wrote: >>> >>> On Thu, May 5, 2011 at 1:17 PM, David Farmer wrote: >>>> >>>> On 5/5/11 11:49 CDT, Mike Burns wrote: >>>>> >>>>> Hi all, >>>>> I have had an idea. >>>>> Since it has been determined that everybody in the ARIN community with >>>>> an email address may participate in policy development, how does the >>>>> list feel about soliciting the input from a broader group of >>>>> participants? >>>> >>>> While not an absolute requirement, I believe there is an understanding >>>> that >>>> some minimal level of technical expertise and interest in the details of >>>> the subject matter are necessary in order to provide useful or meaningful >>>> contribution to the process. >>>> >>> >>> So we would exclude members of the general public (users) then? >> >> Where did I say exclude? "not an absolute requirement", an "interest in the >> details" are needed for a "meaningful contribution". None of that means >> exclude in my book, it simply means that participation takes effort and if >> you want people to take you seriously you need to make a effort. That is >> true in many parts of civil society. > > "Not an absolute requirement" would generally translate to "not important". > > Not all proposals related to IP addressing require technical > knowledge. Some are business oriented such as the proposal to provide > address for critical infrastructure for 36 mos. I would argue that While that is business related, it does require a certain minimal technical knowledge to properly evaluate the implications of the proposal to the larger system. > technical contributions are "not an absolute requirement" to proposals > such as M&A and a few others and are actually harmful when co-mingled > with most technical requirements beyond extremely simply and straight > forward non engineering concepts like utilization. > I disagree. Evaluating policy requires context. Part of that context for IP address policy is an understanding of the technology and the strengths, weaknesses, and limitations of the technology. Part of it is understanding the implications to the larger system of various actions and the likely reactions to those actions. Owen From owen at delong.com Thu May 5 18:24:30 2011 From: owen at delong.com (Owen DeLong) Date: Thu, 5 May 2011 15:24:30 -0700 Subject: [arin-ppml] ARIN-prop-146 Clarify Justified Need for Transfers In-Reply-To: <4DC3220A.5060801@matthew.at> References: <4DBEF120.4080901@arin.net><88F39B20-5C20-45F0-AD61-5FA1E7F84CE3@delong.com><3FCD1FDC-ECEE-4C9B-95C6-59E03D3C314E@mat 5A4-50437602C8ED@delong.com><4DBF6727.1090303@matthew.at><097AAC1C-1F68-4820-9274-3290ADEFA195@delong.com><4DBF75B7.3010407@mat thew.at><9501EA7E-FDAD-4DDA-B9E8-08C2811FF642@delong.com><4DBF82F6.7050608@matthew.at><20110503145144.N15967@mail.inlandnet.com> <4DC084E7.5000302@matthew.at><4DC08664.4060905@matthew.at><4791A59E-8864-483C-9BB0-03A6A5B8D50C@delong.com><66466F57-4365-4ADB-94EB-E023F01B17CB@delong.com><30D12BA8-9A6C-4E62-9A67-8B4FEA0EA8C1@matthew.at> <00af01cc0aa7$845a5330$8d0ef990$@net> <8695009A81378E48879980039EEDAD289D0E5BD9@MAIL1.polartel.local> <5542F2FC72CC4995A4205A4C1C844F5E@mike> <143F9033-E24B-45A9-870C-3678B5E42398@delong.com>! <4DC3220A.5060801@matthew.at> Message-ID: On May 5, 2011, at 3:17 PM, Matthew Kaufman wrote: > On 5/5/2011 3:04 PM, Owen DeLong wrote: >> >> True. What it does is remove the non-needers from the pool of people you >> have to out-bid. What I don't understand is how adding non-needers to the >> pool would help. > > Please clarify how Proposal 146 adds "non-needers" to the pool, as that certainly is not the intent of the policy proposal I wrote. > > Matthew Kaufman Sorry... Conflation of multiple discussions.... Prop. 146 doesn't add non-needers, it adds optimistic speculative need. Owen From jeffrey.lyon at blacklotus.net Thu May 5 18:41:24 2011 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Thu, 5 May 2011 18:41:24 -0400 Subject: [arin-ppml] ARIN-prop-146 Clarify Justified Need for Transfers In-Reply-To: <9296FBB7-EFA7-491B-8F20-7AC1BFD60535@delong.com> References: <4DBEF120.4080901@arin.net> <88F39B20-5C20-45F0-AD61-5FA1E7F84CE3@delong.com> <4DBF6727.1090303@matthew.at> <097AAC1C-1F68-4820-9274-3290ADEFA195@delong.com> <9501EA7E-FDAD-4DDA-B9E8-08C2811FF642@delong.com> <4DBF82F6.7050608@matthew.at> <20110503145144.N15967@mail.inlandnet.com> <4DC084E7.5000302@matthew.at> <4DC08664.4060905@matthew.at> <4791A59E-8864-483C-9BB0-03A6A5B8D50C@delong.com> <66466F57-4365-4ADB-94EB-E023F01B17CB@delong.com> <30D12BA8-9A6C-4E62-9A67-8B4FEA0EA8C1@matthew.at> <00af01cc0aa7$845a5330$8d0ef990$@net> <8695009A81378E48879980039EEDAD289D0E5BD9@MAIL1.polartel.local> <5542F2FC72CC4995A4205A4C1C844F5E@mike> <143F9033-E24B-45A9-870C-3678B5E42398@delong.com> <9296FBB7-EFA7-491B-8F20-7AC1BFD60535@delong.com> Message-ID: > Which is a nice euphemism for "Speculators increase prices". > > Owen > > This is not necessarily true. Speculators can spark an influx of supply and crash the price of a commodity. Providing liquidity allows for transactions to execute quickly and increases the supply of a commodity that is readily available for purchase by those in need. When speculators buy, prices increase, then supply increases, then speculators sell, which causes a price decrease. -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications - AS32421 First and Leading in DDoS Protection Solutions From george.herbert at gmail.com Thu May 5 18:42:12 2011 From: george.herbert at gmail.com (George Herbert) Date: Thu, 5 May 2011 15:42:12 -0700 Subject: [arin-ppml] ARIN-prop-146 Clarify Justified Need for Transfers In-Reply-To: References: <4DBEF120.4080901@arin.net> <88F39B20-5C20-45F0-AD61-5FA1E7F84CE3@delong.com> <4DBF6727.1090303@matthew.at> <097AAC1C-1F68-4820-9274-3290ADEFA195@delong.com> <9501EA7E-FDAD-4DDA-B9E8-08C2811FF642@delong.com> <4DBF82F6.7050608@matthew.at> <20110503145144.N15967@mail.inlandnet.com> <4DC084E7.5000302@matthew.at> <4DC08664.4060905@matthew.at> <4791A59E-8864-483C-9BB0-03A6A5B8D50C@delong.com> <66466F57-4365-4ADB-94EB-E023F01B17CB@delong.com> <30D12BA8-9A6C-4E62-9A67-8B4FEA0EA8C1@matthew.at> <00af01cc0aa7$845a5330$8d0ef990$@net> <8695009A81378E48879980039EEDAD289D0E5BD9@MAIL1.polartel.local> <5542F2FC72CC4995A4205A4C1C844F5E@mike> <143F9033-E24B-45A9-870C-3678B5E42398@delong.com> <4DC3220A.5060801@matthew.at> Message-ID: On Thu, May 5, 2011 at 3:24 PM, Owen DeLong wrote: > > On May 5, 2011, at 3:17 PM, Matthew Kaufman wrote: > >> On 5/5/2011 3:04 PM, Owen DeLong wrote: >>> >>> True. What it does is remove the non-needers from the pool of people you >>> have to out-bid. What I don't understand is how adding non-needers to the >>> pool would help. >> >> Please clarify how Proposal 146 adds "non-needers" to the pool, as that certainly is not the intent of the policy proposal I wrote. >> >> Matthew Kaufman > > Sorry... Conflation of multiple discussions.... > > > Prop. 146 doesn't add non-needers, it adds optimistic speculative need. It refines the definition of speculation; all requests are at least 3 month speculation or extrapolations now, and those of existing holders w/records are longer. This just levels the bar (i.e., new entrants are more speculative, but we put their speculation on the same level as that of existing holders who are extrapolating). I'm not sure that I support 146 as written, but I think that the intent is good (level the playing field in terms of resource use time scale) as long as we ensure that there are reasonable limits to keep this useful to new entrants but not someone who's outright speculating / hoarding and not using. Perhaps a clause allowing for ARIN staff to evaluate if credible multihoming need or other legitimate justification exists, in which case the time scales are leveled, or a clause allowing prior non-direct-allocation usage to be considered for needs justification for a longer timescale, in which case the time scales are leveled. -- -george william herbert george.herbert at gmail.com From hannigan at gmail.com Thu May 5 19:01:28 2011 From: hannigan at gmail.com (Martin Hannigan) Date: Thu, 5 May 2011 19:01:28 -0400 Subject: [arin-ppml] Serious question for the list. In-Reply-To: References: <723D48A257C34BA0BD60F16130F4844F@mike> <4DC2DB9B.2020908@umn.edu> <4DC2E22A.50708@umn.edu> Message-ID: On Thu, May 5, 2011 at 6:16 PM, Owen DeLong wrote: > > On May 5, 2011, at 2:58 PM, Martin Hannigan wrote: > >> On Thu, May 5, 2011 at 1:45 PM, David Farmer wrote: >>> On 5/5/11 12:25 CDT, Martin Hannigan wrote: >>>> >>>> On Thu, May 5, 2011 at 1:17 PM, David Farmer ?wrote: >>>>> >>>>> On 5/5/11 11:49 CDT, Mike Burns wrote: >>>>>> >>>>>> Hi all, >>>>>> I have had an idea. >>>>>> Since it has been determined that everybody in the ARIN community with >>>>>> an email address may participate in policy development, how does the >>>>>> list feel about soliciting the input from a broader group of >>>>>> participants? >>>>> >>>>> While not an absolute requirement, I believe there is an understanding >>>>> that >>>>> some minimal ?level of technical expertise and interest in the details of >>>>> the subject matter are necessary in order to provide useful or meaningful >>>>> contribution to the process. >>>>> >>>> >>>> So we would exclude members of the general public (users) then? >>> >>> Where did I say exclude? ?"not an absolute requirement", an "interest in the >>> details" are needed for a "meaningful contribution". ?None of that means >>> exclude in my book, it simply means that participation takes effort and if >>> you want people to take you seriously you need to make a effort. ?That is >>> true in many parts of civil society. >> >> "Not an absolute requirement" would generally translate to "not important". >> >> Not all proposals related to IP addressing require technical >> knowledge. Some are business oriented such as the proposal to provide >> address for critical infrastructure for 36 mos. ?I would argue that > > While that is business related, it does require a certain minimal technical > knowledge to properly evaluate the implications of the proposal to the larger > system. > >> technical contributions are "not an absolute requirement" to proposals >> such as M&A and a few others and are actually harmful when co-mingled >> with most technical requirements beyond extremely simply and straight >> forward non engineering concepts like utilization. >> > I disagree. Evaluating policy requires context. Part of that context for IP > address policy is an understanding of the technology and the strengths, > weaknesses, and limitations of the technology. Part of it is understanding > the implications to the larger system of various actions and the likely > reactions to those actions. > Context does not require an engineering degree or a shred of experience as a technician. The fact that you disagree underscores the potential of the problem that we seem to have with IP number policy. People who are currently writing them seem to be trying to legislate the technology instead of stewarding the numbers for the greater overall good of the community which includes the end users. This would seem to be an even greater argument to insure that the general public has continued easy access. Creating classes of participants does nothing except create harmful inequities. Best, -M< From owen at delong.com Thu May 5 19:02:30 2011 From: owen at delong.com (Owen DeLong) Date: Thu, 5 May 2011 16:02:30 -0700 Subject: [arin-ppml] ARIN-prop-146 Clarify Justified Need for Transfers In-Reply-To: References: <4DBEF120.4080901@arin.net> <88F39B20-5C20-45F0-AD61-5FA1E7F84CE3@delong.com> <4DBF6727.1090303@matthew.at> <097AAC1C-1F68-4820-9274-3290ADEFA195@delong.com> <9501EA7E-FDAD-4DDA-B9E8-08C2811FF642@delong.com> <4DBF82F6.7050608@matthew.at> <20110503145144.N15967@mail.inlandnet.com> <4DC084E7.5000302@matthew.at> <4DC08664.4060905@matthew.at> <4791A59E-8864-483C-9BB0-03A6A5B8D50C@delong.com> <66466F57-4365-4ADB-94EB-E023F01B17CB@delong.com> <30D12BA8-9A6C-4E62-9A67-8B4FEA0EA8C1@matthew.at> <00af01cc0aa7$845a5330$8d0ef990$@net> <8695009A81378E48879980039EEDAD289D0E5BD9@MAIL1.polartel.local> <5542F2FC72CC4995A4205A4C1C844F5E@mike> <143F9033-E24B-45A9-870C-3678B5E42398@delong.com> <9296FBB7-EFA7-491B-8F20-7AC1BFD60535@delong.com> Message-ID: On May 5, 2011, at 3:41 PM, Jeffrey Lyon wrote: >> Which is a nice euphemism for "Speculators increase prices". >> >> Owen >> >> > > This is not necessarily true. Speculators can spark an influx of > supply and crash the price of a commodity. Providing liquidity allows > for transactions to execute quickly and increases the supply of a > commodity that is readily available for purchase by those in need. > When speculators buy, prices increase, then supply increases, then > speculators sell, which causes a price decrease. > For a market where additional supply can be created, this dynamic sometimes works out. For a market where there is on additional supply which can be created and only the movement of the finite quantities from one holder to another, as is the case with IPv4 addresses, it tends to operate more along the lines of what I stated. If the market feels additional liquidity is needed, I'm sure that those who need addresses will be perfectly capable of offering higher prices without the help of speculators. Owen From owen at delong.com Thu May 5 19:08:06 2011 From: owen at delong.com (Owen DeLong) Date: Thu, 5 May 2011 16:08:06 -0700 Subject: [arin-ppml] ARIN-prop-146 Clarify Justified Need for Transfers In-Reply-To: References: <4DBEF120.4080901@arin.net> <88F39B20-5C20-45F0-AD61-5FA1E7F84CE3@delong.com> <4DBF6727.1090303@matthew.at> <097AAC1C-1F68-4820-9274-3290ADEFA195@delong.com> <9501EA7E-FDAD-4DDA-B9E8-08C2811FF642@delong.com> <4DBF82F6.7050608@matthew.at> <20110503145144.N15967@mail.inlandnet.com> <4DC084E7.5000302@matthew.at> <4DC08664.4060905@matthew.at> <4791A59E-8864-483C-9BB0-03A6A5B8D50C@delong.com> <66466F57-4365-4ADB-94EB-E023F01B17CB@delong.com> <30D12BA8-9A6C-4E62-9A67-8B4FEA0EA8C1@matthew.at> <00af01cc0aa7$845a5330$8d0ef990$@net> <8695009A81378E48879980039EEDAD289D0E5BD9@MAIL1.polartel.local> <5542F2FC72CC4995A4205A4C1C844F5E@mike> <143F9033-E24B-45A9-870C-3678B5E42398@delong.com> <4DC3220A.5060801@matthew.at> Message-ID: <1B7BAA22-52E9-4E47-8D25-3D48E7AA7B9D@delong.com> On May 5, 2011, at 3:42 PM, George Herbert wrote: > On Thu, May 5, 2011 at 3:24 PM, Owen DeLong wrote: >> >> On May 5, 2011, at 3:17 PM, Matthew Kaufman wrote: >> >>> On 5/5/2011 3:04 PM, Owen DeLong wrote: >>>> >>>> True. What it does is remove the non-needers from the pool of people you >>>> have to out-bid. What I don't understand is how adding non-needers to the >>>> pool would help. >>> >>> Please clarify how Proposal 146 adds "non-needers" to the pool, as that certainly is not the intent of the policy proposal I wrote. >>> >>> Matthew Kaufman >> >> Sorry... Conflation of multiple discussions.... >> >> >> Prop. 146 doesn't add non-needers, it adds optimistic speculative need. > > It refines the definition of speculation; all requests are at least 3 > month speculation or extrapolations now, and those of existing holders > w/records are longer. This just levels the bar (i.e., new entrants > are more speculative, but we put their speculation on the same level > as that of existing holders who are extrapolating). > It replaces three month speculation with 12 month speculation to place it on what you call an equal footing with 12 month extrapolation. > I'm not sure that I support 146 as written, but I think that the > intent is good (level the playing field in terms of resource use time > scale) as long as we ensure that there are reasonable limits to keep > this useful to new entrants but not someone who's outright speculating > / hoarding and not using. > The problem is that elevating speculation to the same level as extrapolation of past performance in the evaluation of needs basis strikes me not as a level playing field, but, rather tilting the game in the opposite direction. Owen From matthew at matthew.at Thu May 5 19:23:23 2011 From: matthew at matthew.at (Matthew Kaufman) Date: Thu, 05 May 2011 16:23:23 -0700 Subject: [arin-ppml] ARIN-prop-146 Clarify Justified Need for Transfers In-Reply-To: <1B7BAA22-52E9-4E47-8D25-3D48E7AA7B9D@delong.com> References: <4DBEF120.4080901@arin.net> <88F39B20-5C20-45F0-AD61-5FA1E7F84CE3@delong.com> <4DBF6727.1090303@matthew.at> <097AAC1C-1F68-4820-9274-3290ADEFA195@delong.com> <9501EA7E-FDAD-4DDA-B9E8-08C2811FF642@delong.com> <4DBF82F6.7050608@matthew.at> <20110503145144.N15967@mail.inlandnet.com> <4DC084E7.5000302@matthew.at> <4DC08664.4060905@matthew.at> <4791A59E-8864-483C-9BB0-03A6A5B8D50C@delong.com> <66466F57-4365-4ADB-94EB-E023F01B17CB@delong.com> <30D12BA8-9A6C-4E62-9A67-8B4FEA0EA8C1@matthew.at> <00af01cc0aa7$845a5330$8d0ef990$@net> <8695009A81378E48879980039EEDAD289D0E5BD9@MAIL1.polartel.local> <5542F2FC72CC4995A4205A4C1C844F5E@mike> <143F9033-E24B-45A9-870C-3678B5E42398@delong.com> <4DC3220A.5060801@matthew.at> <1B7BAA22-52E9-4E47-8D25-3D48E7AA7B9D@delong.com> Message-ID: <4DC3316B.6020700@matthew.at> On 5/5/2011 4:08 PM, Owen DeLong wrote: > > The problem is that elevating speculation to the same level as > extrapolation of past performance in the evaluation of needs > basis strikes me not as a level playing field, but, rather tilting the > game in the opposite direction. Only if you don't think ARIN staff has experience evaluating requests for demonstration of need. Apparently I have more faith in ARIN staff than you do. Would you be happier with 12 months for new/recent and 24 or 36 months for existing holders? The problem I'm trying to solve is that 3 months is a ridiculously small amount of justification window when the pain of getting the space at all is so much higher than it is pre-runout. Matthew Kaufman From bill at herrin.us Thu May 5 19:44:52 2011 From: bill at herrin.us (William Herrin) Date: Thu, 5 May 2011 19:44:52 -0400 Subject: [arin-ppml] Serious question for the list. In-Reply-To: <4DC2F938.4010701@umn.edu> References: <723D48A257C34BA0BD60F16130F4844F@mike> <830EB477-D03E-41B9-A5D7-125B957A8B29@delong.com> <4DC2F938.4010701@umn.edu> Message-ID: On Thu, May 5, 2011 at 3:23 PM, David Farmer wrote: > To me it really does count more if you can explain why you support > something. ?I'm not saying that you always have too. ?Only that, if you are > new somewhere and you want people to take you seriously, being articulate > can't hurt. And in the inverse, it really does count more to the PPML's participants when a member of the AC explains why he or she supports or disagrees with a proposal. We'll take you seriously anyway because you get to vote but being articulate about your choices can't hurt. 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 Thu May 5 19:45:23 2011 From: owen at delong.com (Owen DeLong) Date: Thu, 5 May 2011 16:45:23 -0700 Subject: [arin-ppml] ARIN-prop-146 Clarify Justified Need for Transfers In-Reply-To: <4DC3316B.6020700@matthew.at> References: <4DBEF120.4080901@arin.net> <88F39B20-5C20-45F0-AD61-5FA1E7F84CE3@delong.com> <4DBF6727.1090303@matthew.at> <097AAC1C-1F68-4820-9274-3290ADEFA195@delong.com> <9501EA7E-FDAD-4DDA-B9E8-08C2811FF642@delong.com> <4DBF82F6.7050608@matthew.at> <20110503145144.N15967@mail.inlandnet.com> <4DC084E7.5000302@matthew.at> <4DC08664.4060905@matthew.at> <4791A59E-8864-483C-9BB0-03A6A5B8D50C@delong.com> <66466F57-4365-4ADB-94EB-E023F01B17CB@delong.com> <30D12BA8-9A6C-4E62-9A67-8B4FEA0EA8C1@matthew.at> <00af01cc0aa7$845a5330$8d0ef990$@net> <8695009A81378E48879980039EEDAD289D0E5BD9@MAIL1.polartel.local> <5542F2FC72CC4995A4205A4C1C844F5E@mike> <143F9033-E24B-45A9-870C-3678B5E42398@delong.com> <4DC3220A.5060801@matthew.at> <1B7BAA22-52E9-4E47-8D25-3D48E7AA7B9D@delong.com> <4DC3316B.6020700@matthew.at> Message-ID: <1B147AB1-0718-4313-9289-C66C24F18F4A@delong.com> On May 5, 2011, at 4:23 PM, Matthew Kaufman wrote: > On 5/5/2011 4:08 PM, Owen DeLong wrote: >> >> The problem is that elevating speculation to the same level as >> extrapolation of past performance in the evaluation of needs >> basis strikes me not as a level playing field, but, rather tilting the >> game in the opposite direction. > > Only if you don't think ARIN staff has experience evaluating requests for demonstration of need. Apparently I have more faith in ARIN staff than you do. > ARIN is quite good at that. However, one of the most important components of that evaluation is the past track record. The 3 month limit applies for exactly that reason to organizations that do not have a track record. > Would you be happier with 12 months for new/recent and 24 or 36 months for existing holders? The problem I'm trying to solve is that 3 months is a ridiculously small amount of justification window when the pain of getting the space at all is so much higher than it is pre-runout. > No, I would not support 24 or 36 months in any case. Owen From george.herbert at gmail.com Thu May 5 19:48:55 2011 From: george.herbert at gmail.com (George Herbert) Date: Thu, 5 May 2011 16:48:55 -0700 Subject: [arin-ppml] ARIN-prop-146 Clarify Justified Need for Transfers In-Reply-To: <1B7BAA22-52E9-4E47-8D25-3D48E7AA7B9D@delong.com> References: <4DBEF120.4080901@arin.net> <88F39B20-5C20-45F0-AD61-5FA1E7F84CE3@delong.com> <4DBF6727.1090303@matthew.at> <097AAC1C-1F68-4820-9274-3290ADEFA195@delong.com> <9501EA7E-FDAD-4DDA-B9E8-08C2811FF642@delong.com> <4DBF82F6.7050608@matthew.at> <20110503145144.N15967@mail.inlandnet.com> <4DC084E7.5000302@matthew.at> <4DC08664.4060905@matthew.at> <4791A59E-8864-483C-9BB0-03A6A5B8D50C@delong.com> <66466F57-4365-4ADB-94EB-E023F01B17CB@delong.com> <30D12BA8-9A6C-4E62-9A67-8B4FEA0EA8C1@matthew.at> <00af01cc0aa7$845a5330$8d0ef990$@net> <8695009A81378E48879980039EEDAD289D0E5BD9@MAIL1.polartel.local> <5542F2FC72CC4995A4205A4C1C844F5E@mike> <143F9033-E24B-45A9-870C-3678B5E42398@delong.com> <4DC3220A.5060801@matthew.at> <1B7BAA22-52E9-4E47-8D25-3D48E7AA7B9D@delong.com> Message-ID: On Thu, May 5, 2011 at 4:08 PM, Owen DeLong wrote: > > On May 5, 2011, at 3:42 PM, George Herbert wrote: > >> On Thu, May 5, 2011 at 3:24 PM, Owen DeLong wrote: >>> >>> On May 5, 2011, at 3:17 PM, Matthew Kaufman wrote: >>> >>>> On 5/5/2011 3:04 PM, Owen DeLong wrote: >>>>> >>>>> True. What it does is remove the non-needers from the pool of people you >>>>> have to out-bid. What I don't understand is how adding non-needers to the >>>>> pool would help. >>>> >>>> Please clarify how Proposal 146 adds "non-needers" to the pool, as that certainly is not the intent of the policy proposal I wrote. >>>> >>>> Matthew Kaufman >>> >>> Sorry... Conflation of multiple discussions.... >>> >>> >>> Prop. 146 doesn't add non-needers, it adds optimistic speculative need. >> >> It refines the definition of speculation; all requests are at least 3 >> month speculation or extrapolations now, and those of existing holders >> w/records are longer. ?This just levels the bar (i.e., new entrants >> are more speculative, but we put their speculation on the same level >> as that of existing holders who are extrapolating). >> > It replaces three month speculation with 12 month speculation to place > it on what you call an equal footing with 12 month extrapolation. > > >> I'm not sure that I support 146 as written, but I think that the >> intent is good (level the playing field in terms of resource use time >> scale) as long as we ensure that there are reasonable limits to keep >> this useful to new entrants but not someone who's outright speculating >> / hoarding and not using. >> > The problem is that elevating speculation to the same level as > extrapolation of past performance in the evaluation of needs > basis strikes me not as a level playing field, but, rather tilting the > game in the opposite direction. The part of my mail you snipped tried to address this: >> Perhaps a clause allowing for ARIN staff to evaluate if credible >> multihoming need or other legitimate justification exists, in which >> case the time scales are leveled, or a clause allowing prior >> non-direct-allocation usage to be considered for needs justification >> for a longer timescale, in which case the time scales are leveled. Credible (and ARIN-approved well justified) multihoming need, prior non-direct-allocation utilization, or another community-derived needs based criterion seems entirely reasonable to me as being a way to avoid rampant fiction or unjustified speculation, in determining if we extend past the 3 months for a particular request and allow them to go out to the same as existing players get. This is a bit more work for ARIN for the exceptions, but I don't think it tilts the playing field back towards the new entrants in any significant way. I would hope and expect there won't be many exceptions, and am not suggesting we overload ARIN with ludicrous speculation exception requests, but it seems that somewhere in there lies a credible and fair balance point. Matthew's suggestions related to size limits on this are also motion towards a credible and fair balance point. -- -george william herbert george.herbert at gmail.com From george.herbert at gmail.com Thu May 5 19:52:20 2011 From: george.herbert at gmail.com (George Herbert) Date: Thu, 5 May 2011 16:52:20 -0700 Subject: [arin-ppml] ARIN-prop-146 Clarify Justified Need for Transfers In-Reply-To: <1B147AB1-0718-4313-9289-C66C24F18F4A@delong.com> References: <4DBEF120.4080901@arin.net> <88F39B20-5C20-45F0-AD61-5FA1E7F84CE3@delong.com> <4DBF6727.1090303@matthew.at> <097AAC1C-1F68-4820-9274-3290ADEFA195@delong.com> <9501EA7E-FDAD-4DDA-B9E8-08C2811FF642@delong.com> <4DBF82F6.7050608@matthew.at> <20110503145144.N15967@mail.inlandnet.com> <4DC084E7.5000302@matthew.at> <4DC08664.4060905@matthew.at> <4791A59E-8864-483C-9BB0-03A6A5B8D50C@delong.com> <66466F57-4365-4ADB-94EB-E023F01B17CB@delong.com> <30D12BA8-9A6C-4E62-9A67-8B4FEA0EA8C1@matthew.at> <00af01cc0aa7$845a5330$8d0ef990$@net> <8695009A81378E48879980039EEDAD289D0E5BD9@MAIL1.polartel.local> <5542F2FC72CC4995A4205A4C1C844F5E@mike> <143F9033-E24B-45A9-870C-3678B5E42398@delong.com> <4DC3220A.5060801@matthew.at> <1B7BAA22-52E9-4E47-8D25-3D48E7AA7B9D@delong.com> <4DC3316B.6020700@matthew.at> <1B147AB1-0718-4313-9289-C66C24F18F4A@delong.com> Message-ID: On Thu, May 5, 2011 at 4:45 PM, Owen DeLong wrote: > > On May 5, 2011, at 4:23 PM, Matthew Kaufman wrote: > >> On 5/5/2011 4:08 PM, Owen DeLong wrote: >>> >>> The problem is that elevating speculation to the same level as >>> extrapolation of past performance in the evaluation of needs >>> basis strikes me not as a level playing field, but, rather tilting the >>> game in the opposite direction. >> >> Only if you don't think ARIN staff has experience evaluating requests for demonstration of need. Apparently I have more faith in ARIN staff than you do. >> > ARIN is quite good at that. However, one of the most important components of that evaluation > is the past track record. The 3 month limit applies for exactly that reason to organizations that > do not have a track record. You're implicitly equating two very different statements - "Organizations that do not have a track record (at all)" vs "Organizations that do not have a track record (with ARIN)" There are many ways to demonstrate prior use history and good stewardship of IP space that was not directly ARIN allocated that COULD be considered by ARIN in an allocation request, for someone who's new to the ARIN game but has been in existence long enough. The current policy replaces COULD with NOT. Fundamentally I think COULD is a better (fairer to new entrants, at this time, under final /8 conditions, not an automatic open gate for speculation beyond current policy root goals etc). -- -george william herbert george.herbert at gmail.com From farmer at umn.edu Thu May 5 19:55:40 2011 From: farmer at umn.edu (David Farmer) Date: Thu, 05 May 2011 18:55:40 -0500 Subject: [arin-ppml] Serious question for the list. In-Reply-To: References: <723D48A257C34BA0BD60F16130F4844F@mike> <4DC2DB9B.2020908@umn.edu> <4DC2E22A.50708@umn.edu> Message-ID: <4DC338FC.6020300@umn.edu> On 5/5/11 18:01 CDT, Martin Hannigan wrote: > Context does not require an engineering degree or a shred of > experience as a technician. The fact that you disagree underscores the > potential of the problem that we seem to have with IP number policy. > People who are currently writing them seem to be trying to legislate > the technology instead of stewarding the numbers for the greater > overall good of the community which includes the end users. > > This would seem to be an even greater argument to insure that the > general public has continued easy access. Creating classes of > participants does nothing except create harmful inequities. I think I see the problem here, first I think I didn't say exactly what I meant. I said "minimal level of technical expertise and interest in the details of the subject matter", when I really meant "minimal level of technical expertise and/or interest in the details of the subject matter." In fact you could probably even eliminate the first phrase and just go with "interest in the details of the subject matter." Now the fact is that a great majority of the people with sufficient interest are probably from the networking industry or more generally Information Technology. But that is by no means a requirement, it is more a correlation then anything else. Furthermore, "technical expertise" isn't limited to network engineers, or engineers at all. One of your examples from earlier, M&A contract law is a highly technical field too. Something doesn't need to be about Information Technology to be technical, the word has a much broader meaning. ------ tech?ni?cal adjective?/?teknik?l/? 1. Of or relating to a particular subject, art, or craft, or its techniques * - technical terms * - a test of an artist's technical skill 2. (esp. of a book or article) Requiring special knowledge to be understood * - a technical report 3. Of, involving, or concerned with applied and industrial sciences * - an important technical achievement 4. Resulting from mechanical failure * - a technical fault 5. According to a strict application or interpretation of the law or rules * - the arrest was a technical violation of the treaty -- =============================================== 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 owen at delong.com Thu May 5 19:57:45 2011 From: owen at delong.com (Owen DeLong) Date: Thu, 5 May 2011 16:57:45 -0700 Subject: [arin-ppml] ARIN-prop-146 Clarify Justified Need for Transfers In-Reply-To: References: <4DBEF120.4080901@arin.net> <88F39B20-5C20-45F0-AD61-5FA1E7F84CE3@delong.com> <4DBF6727.1090303@matthew.at> <097AAC1C-1F68-4820-9274-3290ADEFA195@delong.com> <9501EA7E-FDAD-4DDA-B9E8-08C2811FF642@delong.com> <4DBF82F6.7050608@matthew.at> <20110503145144.N15967@mail.inlandnet.com> <4DC084E7.5000302@matthew.at> <4DC08664.4060905@matthew.at> <4791A59E-8864-483C-9BB0-03A6A5B8D50C@delong.com> <66466F57-4365-4ADB-94EB-E023F01B17CB@delong.com> <30D12BA8-9A6C-4E62-9A67-8B4FEA0EA8C1@matthew.at> <00af01cc0aa7$845a5330$8d0ef990$@net> <8695009A81378E48879980039EEDAD289D0E5BD9@MAIL1.polartel.local> <5542F2FC72CC4995A4205A4C1C844F5E@mike> <143F9033-E24B-45A9-870C-3678B5E42398@delong.com> <4DC3220A.5060801@matthew.at> <1B7BAA22-52E9-4E47-8D25-3D48E7AA7B9D@delong.com> <4DC3316B.6020700@matthew.at> <1B147AB1-0718-4313-9289-C66! C24F18F4A@delong.com> Message-ID: > > There are many ways to demonstrate prior use history and good > stewardship of IP space that was not directly ARIN allocated that > COULD be considered by ARIN in an allocation request, for someone > who's new to the ARIN game but has been in existence long enough. > > The current policy replaces COULD with NOT. Fundamentally I think > COULD is a better (fairer to new entrants, at this time, under final > /8 conditions, not an automatic open gate for speculation beyond > current policy root goals etc). I would need to see the proposal details, but, I might be able to get behind a policy that did that. That is not what 146 does in its current form. Owen From owen at delong.com Thu May 5 20:04:02 2011 From: owen at delong.com (Owen DeLong) Date: Thu, 5 May 2011 17:04:02 -0700 Subject: [arin-ppml] Serious question for the list. In-Reply-To: References: <723D48A257C34BA0BD60F16130F4844F@mike> <4DC2DB9B.2020908@umn.edu> <4DC2E22A.50708@umn.edu> Message-ID: <98903126-7541-4CE6-B2D2-580C9717BEBB@delong.com> >> >>> technical contributions are "not an absolute requirement" to proposals >>> such as M&A and a few others and are actually harmful when co-mingled >>> with most technical requirements beyond extremely simply and straight >>> forward non engineering concepts like utilization. >>> >> I disagree. Evaluating policy requires context. Part of that context for IP >> address policy is an understanding of the technology and the strengths, >> weaknesses, and limitations of the technology. Part of it is understanding >> the implications to the larger system of various actions and the likely >> reactions to those actions. >> > > Context does not require an engineering degree or a shred of > experience as a technician. The fact that you disagree underscores the > potential of the problem that we seem to have with IP number policy. I did not say that it requires an engineering degree or experience as a technician. I said it requires an understanding of the technology and its strengths and weaknesses. > People who are currently writing them seem to be trying to legislate > the technology instead of stewarding the numbers for the greater > overall good of the community which includes the end users. > Indeed in my participation in ARIN and my time on the AC, the stewarding of the resources for the greater overall good of the community, especially the end users has, indeed, been my goal. However, I do not believe that one can achieve that if one does not pay proper attention to the technical realities of how policies are implemented and how they affect the real world deployments of the number resources. One cannot pay proper attention to those factors if one does not have at least a basic understanding of the technology and its strengths and weaknesses as I sated above. One need look no further than the various unintended or undesired consequences of public policies like the DMCA and the Telecom Reform Bill to see examples of what happens when people ignorant of the subject matter they are regulating pass regulations without appropriate expertise. > This would seem to be an even greater argument to insure that the > general public has continued easy access. Creating classes of > participants does nothing except create harmful inequities. > I have not advocated creating classes of participants and would not do so. I am all for the general public having continued easy access to PPML. However, I still oppose the idea that policy does not have to be technically sound. Owen From mike at nationwideinc.com Thu May 5 20:07:27 2011 From: mike at nationwideinc.com (Mike Burns) Date: Thu, 5 May 2011 20:07:27 -0400 Subject: [arin-ppml] ARIN-prop-146 Clarify Justified Need for Transfers References: <4DBEF120.4080901@arin.net> <88F39B20-5C20-45F0-AD61-5FA1E7F84CE3@delong.com> <4DBF6727.1090303@matthew.at> <097AAC1C-1F68-4820-9274-3290ADEFA195@delong.com> <9501EA7E-FDAD-4DDA-B9E8-08C2811FF642@delong.com> <4DBF82F6.7050608@matthew.at> <20110503145144.N15967@mail.inlandnet.com> <4DC084E7.5000302@matthew.at> <4DC08664.4060905@matthew.at> <4791A59E-8864-483C-9BB0-03A6A5B8D50C@delong.com> <66466F57-4365-4ADB-94EB-E023F01B17CB@delong.com> <30D12BA8-9A6C-4E62-9A67-8B4FEA0EA8C1@matthew.at> <00af01cc0aa7$845a5330$8d0ef990$@net> <8695009A81378E48879980039EEDAD289D0E5BD9@MAIL1.polartel.local> <5542F2FC72CC4995A4205A4C1C844F5E@mike> <143F9033-E24B-45A9-870C-3678B5E42398@delong.com> <9296FBB7-EFA7-491B-8F20-7AC1BFD60535@delong.com> Message-ID: <617F7AB1A6144CEFB232374E5C73AE60@video> > For a market where there is an additional supply which can be created > and only the movement of the finite quantities from one holder to another, > as is the case with IPv4 addresses >Owen Hi Owen, There is an upper bound, but there could also be quite an influx of supply. http://resources.potaroo.net/iso3166/v4cc.html According to the site above, advertised space is equivalent to just over 2.4 billion addresses. Leaving aside RFC1918 and the space above 240/8, there are what, 3.8 billion addresses? Even with unusable boundary space there are a billion addresses unadvertised. And plenty that are advertised but not used. When you add up addresses freed up by CGN and the like, there could be quite an influx indeed. These addresses will be sucked off the sidelines by the greed of their rights holders, and directed to the most efficient overall use by the mechanics of the transfer market. They will be sold to greedy individuals who think they can use them profitably at whatever application they envision. The Invisible Hand will move addresses to the greater social good, efficient use, using individual greed as the underlying motive. And you can always rely on greed. Regards, Mike From george.herbert at gmail.com Thu May 5 20:26:12 2011 From: george.herbert at gmail.com (George Herbert) Date: Thu, 5 May 2011 17:26:12 -0700 Subject: [arin-ppml] ARIN-prop-146 Clarify Justified Need for Transfers In-Reply-To: References: <4DBEF120.4080901@arin.net> <88F39B20-5C20-45F0-AD61-5FA1E7F84CE3@delong.com> <4DBF6727.1090303@matthew.at> <097AAC1C-1F68-4820-9274-3290ADEFA195@delong.com> <9501EA7E-FDAD-4DDA-B9E8-08C2811FF642@delong.com> <4DBF82F6.7050608@matthew.at> <20110503145144.N15967@mail.inlandnet.com> <4DC084E7.5000302@matthew.at> <4DC08664.4060905@matthew.at> <4791A59E-8864-483C-9BB0-03A6A5B8D50C@delong.com> <66466F57-4365-4ADB-94EB-E023F01B17CB@delong.com> <30D12BA8-9A6C-4E62-9A67-8B4FEA0EA8C1@matthew.at> <00af01cc0aa7$845a5330$8d0ef990$@net> <8695009A81378E48879980039EEDAD289D0E5BD9@MAIL1.polartel.local> <5542F2FC72CC4995A4205A4C1C844F5E@mike> <143F9033-E24B-45A9-870C-3678B5E42398@delong.com> <4DC3220A.5060801@matthew.at> <1B7BAA22-52E9-4E47-8D25-3D48E7AA7B9D@delong.com> <4DC3316B.6020700@matthew.at> Message-ID: On Thu, May 5, 2011 at 4:57 PM, Owen DeLong wrote: >> >> There are many ways to demonstrate prior use history and good >> stewardship of IP space that was not directly ARIN allocated that >> COULD be considered by ARIN in an allocation request, for someone >> who's new to the ARIN game but has been in existence long enough. >> >> The current policy replaces COULD with NOT. ?Fundamentally I think >> COULD is a better (fairer to new entrants, at this time, under final >> /8 conditions, not an automatic open gate for speculation beyond >> current policy root goals etc). > > I would need to see the proposal details, but, I might be able to get > behind a policy that did that. That is not what 146 does in its > current form. I think that's what 146 was intended to do and was how I read it, but I can't read Matthew's mind. Matthew - if that was the intent, are you open to alternate language proposals that won't cause Owen to break out in hives? -- -george william herbert george.herbert at gmail.com From rbf+arin-ppml at panix.com Thu May 5 21:55:34 2011 From: rbf+arin-ppml at panix.com (Brett Frankenberger) Date: Thu, 5 May 2011 20:55:34 -0500 Subject: [arin-ppml] Statistics regarding NRPM 8.3 Transfers to date In-Reply-To: References: <49E26DCB-DAF7-4A0A-912E-F981494979F5@delong.com> <4DBC2AEB.9040307@matthew.at> <4DBCA58D.4060704@sprunk.org> <2344ADD7-616E-4FA7-9552-19735926A952@delong.com> Message-ID: <20110506015533.GA17557@panix.com> On Mon, May 02, 2011 at 01:32:43PM -0700, Owen DeLong wrote: > > So... I'll try to provide some examples of what should and shouldn't > be allowed... The following questions aren't intended to be argumentative, but rather, to define the line more clearly. > 1. Org. A has a /8 and wants to transfer 32 of it's constituent /24s to Org. B. > However, Org. A doesn't want to put any effort into renumbering, > so, those 32 /24s are each individual non-aggregable /24s. > > This transfer should not be allowed. > > 2. Org. A has a /20 and a /18. Org. B has need for a /19. Org. A has > deprecated their use of the /20 and all of their resources are in > the /18, but, they are using just under 75% of the /18. > > Org. A would rather transfer the /20 and the top 1/4 of the /18 than > renumber that 1/4 of the /18 into the /20. > > This transfer should not be allowed (though I admit the case against > it is weak). > > 3. Org. A has four disparate /20s. Org B. has need of a /19. Org. A > would like to transfer two of their /20s to Org. B, but does not have > any pair of /20s which can be aggregated. > > This transfer should be allowed. The /20s are already disaggregated > in the routing table and there is no increase in routing table > size that results. > > 4. Org. A has four disparate /20s. Orgs. B, C, D, and E all have need > for /24s. Org. A would like to sell individual /24s from one of their > /20s to each of the above Orgs. (B,C, D, and E). > > These transfers should be allowed as there is no significant > difference between this and transfers where ARIN has > carved up a block during the initial allocations. The transfer > sizes comply with community accepted policy. As part of your #4 above, which of the following disaggregations would you allow: #1 (this is the most efficient possible, so I'm assuming you'd allow this): Org. A splits /20 #1 into 4 /24s all from one /22 (and transfers the four /24s), leaving it with a /22 and a /21 and the other three /20s it startd with. #2: Org. A splits /20 #1 such that one /24 can be transferred from each /22, so four /24s are transferred, leaving Org. A with four /24s and four /23 (from /20 #1) and the other three /20s it started with. #3: Org. A splits each /20 and transfers one /24 from each, leaving it with a /24, /23, /22, and a /21 from each /20. So the result is 4 /24s transferred, and Org. A has 5 /24s, 4 /23s, 4 /22s, and 4 /21s remaining. (If the answer to #2 or #3 is "no", is it dependant on Orgs B, C, D, and E all coming at the same time. Would the answer change if the Org B transfer were completed, then a few months later, Org C came along (and a transfer completed), then Org D a few months later, and so on.) Also, separately, suppose Org A. has one /20, and Org. B has a need for a /23. Org. A splits the /20 into two /23s, a /22, and a /21, and transfers one of the /23s. (Presumably this would be allowed.) Now, a few months after that Org. C comes along and demonstrates a need for a /24. What is Org. A allowed to do? Can they split the /23 they have left and transfer half of it? (Presuambly yes). But would they have to split the /23? Or could they split the /22 or the /21 instead? Suppose that, instead of needing a /24, Org. C needed a /23. Does the answer change? (That is, is Org. A allowed only to transfer the /23? Or can they split the /22 or the /21?) Finally, suppose that Org. A has two /23, a /22, and a /21, but they didn't get there by splitting a /20. Instead, it's four separate allocations they received from ARIN several years in the past. (Assume that's possible. Or, if you prefer, subtract 3 from the mask length of every prefix in my examples to keep everything at /21 and longer.) Does that change the answers to what happens when Org. C comes along wanting a /23 or a /24? > In essence, I'm trying to say that transfers which create unnecessary > additional disaggregation should be avoided. The devil is in the details, though. -- Brett From cgrundemann at gmail.com Thu May 5 22:38:03 2011 From: cgrundemann at gmail.com (Chris Grundemann) Date: Thu, 5 May 2011 20:38:03 -0600 Subject: [arin-ppml] Draft proposal that needs some wordsmithing In-Reply-To: References: <9638601B94304E4392112CF98CDE757C@mike> <4DC31B41.3090001@umn.edu> Message-ID: Mike, Thanks for putting this together and floating it here for input, I think that sharing proposals for feedback and input before officially proposing them is the best way to end up with sound policy. That being said, I still have major doubts about the utility and necessity of removing the needs requirement from policy. I will admit that I am quite a ways behind in PPML messages so my apologies if any of my questions here have already been asked and answered. Comments and questions below. Cheers, ~Chris On Thu, May 5, 2011 at 14:43, Mike Burns wrote: > 8. Rationale: > Current ARIN policies relating to the registration of transfer of > address holdings limit the eligibility of registration of transfers to > those relating to mergers and acquisitions of entities that are > administering an operational network, or to those who agree to > sign either an RSA or LRSA with ARIN and subject the buyer > to needs analysis and the seller to a potential ARIN audit. True. > It is currently anticipated that the IPv4 unallocated address pool > will be exhausted within a couple of years at ARIN, and earlier > than that in other regions, and the transition to IPv6-based service > delivery > is likely to take longer than the remaining period of unallocated > address availability. Accordingly, it is likely that demand for IPv4 > addresses will continue beyond the time of unallocated address pool > exhaustion, leading to a period of movement of IPv4 address blocks > between address holders to meet such continuing demand for IPv4 > address blocks. I'm still with you. > The underlying proposition behind this policy proposal is that the > registry of IPv4 addresses operated by ARIN is of general utility and > value only while it accurately describes the current state of address > distribution. If a class of address movement transactions are excluded > from being entered in the registry, then the registry will have > decreasing value to the broader community, and the integrity of the > network itself is thereby compromised. This proposal's central aim is > to ensure the continuing utility and value of the ARIN address > registry by allowing the registry to record transactions where IPv4 > addresses are transfered between ARIN account holders. Here is where you lose me. The first two sentences are fundamentally true and the third sentence is a valuable and noble goal. The piece of the puzzle that I am still missing is this: Why would organizations choose to "move addresses" in an excluded manner? A few facts that I find important: 1) IPv4 addresses have value for Internet routing only if they are unique. 2) The best way to ensure uniqueness on this scale is to maintain a public record or database of some form. 3) ARIN (and the other RIRs, in cooperation with the IANA) maintains entries in such a database (plus a couple other services provided) for a nominal fee. 4) Because spots in this database are limited, for at least the last decade (it can be argued that this was true from the very beginning, with increasing oversight over time), receiving a spot in this database has required a justification of need. You've had to demonstrate that you were actually going to use the spot that you wanted to occupy to add value to the global network. 5) Completely new spots in the database (unused IPv4 addresses) are about to run out. Based on those facts, I end up with two questions: 1) How/why does fact number five change any of the preceding facts? (i.e. Why should the realization of scarcity change our stewardship behavior, behavior that was based on an understanding of scarcity?) 2) Why would any organization with need for unique IPv4 addresses choose to not have those addresses recorded in the database which guarantees their value in order to escape stating their need? (i.e. What class of organization with legitimate need would be hurt by having to demonstrate that need before receiving addresses?) On Thu, May 5, 2011 at 16:12, Mike Burns wrote: > I don't believe speculators will make up a majority of the market > I just don't think the problem of hoarders is so great Are you willing to bet the future of the Internet on those assumptions? Do you have any evidence that might convince others to make the same gamble? > > _______________________________________________ > 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 weblog.chrisgrundemann.com www.burningwiththebush.com www.theIPv6experts.net www.coisoc.org From matthew at matthew.at Thu May 5 22:48:07 2011 From: matthew at matthew.at (Matthew Kaufman) Date: Thu, 05 May 2011 19:48:07 -0700 Subject: [arin-ppml] Draft proposal that needs some wordsmithing In-Reply-To: References: <9638601B94304E4392112CF98CDE757C@mike> <4DC31B41.3090001@umn.edu> Message-ID: <4DC36167.9020000@matthew.at> On 5/5/2011 7:38 PM, Chris Grundemann wrote: > > 1) How/why does fact number five change any of the preceding facts? > (i.e. Why should the realization of scarcity change our stewardship > behavior, behavior that was based on an understanding of scarcity?) One argument might be that once the price is high enough, price will discourage those without need. > 2) Why would any organization with need for unique IPv4 addresses > choose to not have those addresses recorded in the database which > guarantees their value in order to escape stating their need? (i.e. > What class of organization with legitimate need would be hurt by > having to demonstrate that need before receiving addresses?) Well, I've already answered that in my proposal... organizations that are new or which have had ARIN addresses for less than 12 months are only allowed to demonstrate need for a 3-month supply of addresses, whereas existing orgs can simply demonstrate need for a 12-month supply. In a fairly illiquid transfer market, the odds of finding any addresses at all will be difficult... and being restricted to only getting 3 months worth once they're found will likely be a much larger hardship for those orgs than it is today, when the 3 month supply is simply replenished with an email showing they've been used. Matthew Kaufman From dogwallah at gmail.com Fri May 6 00:38:17 2011 From: dogwallah at gmail.com (McTim) Date: Fri, 6 May 2011 07:38:17 +0300 Subject: [arin-ppml] ARIN-prop-146 Clarify Justified Need for Transfers In-Reply-To: <5542F2FC72CC4995A4205A4C1C844F5E@mike> References: <4DBEF120.4080901@arin.net> <88F39B20-5C20-45F0-AD61-5FA1E7F84CE3@delong.com> <4DBF6727.1090303@matthew.at> <097AAC1C-1F68-4820-9274-3290ADEFA195@delong.com> <9501EA7E-FDAD-4DDA-B9E8-08C2811FF642@delong.com> <4DBF82F6.7050608@matthew.at> <20110503145144.N15967@mail.inlandnet.com> <4DC084E7.5000302@matthew.at> <4DC08664.4060905@matthew.at> <4791A59E-8864-483C-9BB0-03A6A5B8D50C@delong.com> <66466F57-4365-4ADB-94EB-E023F01B17CB@delong.com> <30D12BA8-9A6C-4E62-9A67-8B4FEA0EA8C1@matthew.at> <00af01cc0aa7$845a5330$8d0ef990$@net> <8695009A81378E48879980039EEDAD289D0E5BD9@MAIL1.polartel.local> <5542F2FC72CC4995A4205A4C1C844F5E@mike> Message-ID: Hi Mike, On Thu, May 5, 2011 at 11:30 PM, Mike Burns wrote: > > > > When exhaust happens, even if you have need, ?you are going to have to pay > the price required for somebody to sell to you instead of to another person > with need, according to current policy. or wait inline until ARIN gets some more, or use private addressing, or move to IPv6.... > Attested need will only be the price of entry to the "ARIN auction". > It won't change the fact that you will have to outbid all the other needers. > Unless you are proposing that ARIN go to a policy like at APNIC where the > remains of the free pool are rationed, and you can only get a certain > maximum amount. Most of the RIR communities have set a maximum allocation size historically. They are becoming smaller as we get closer to runout. For the record, I am against all attempts in whatever form to monetise address distribution. -- Cheers, McTim "A name indicates what we seek. An address indicates where it is. A route indicates how we get there."? Jon Postel From narten at us.ibm.com Fri May 6 00:53:02 2011 From: narten at us.ibm.com (Thomas Narten) Date: Fri, 06 May 2011 00:53:02 -0400 Subject: [arin-ppml] Weekly posting summary for ppml@arin.net Message-ID: <201105060453.p464r2Ro024033@rotala.raleigh.ibm.com> Total of 582 messages in the last 7 days. script run at: Fri May 6 00:53:02 EDT 2011 Messages | Bytes | Who --------+------+--------+----------+------------------------ 21.65% | 126 | 25.83% | 1436599 | owen at delong.com 11.68% | 68 | 15.86% | 881733 | mike at nationwideinc.com 8.42% | 49 | 6.59% | 366480 | matthew at matthew.at 7.56% | 44 | 5.40% | 300307 | jcurran at arin.net 6.53% | 38 | 6.11% | 339558 | jeffrey.lyon at blacklotus.net 5.33% | 31 | 3.88% | 215560 | bill at herrin.us 3.09% | 18 | 2.31% | 128712 | farmer at umn.edu 1.89% | 11 | 2.84% | 157721 | v6ops at globis.net 2.58% | 15 | 1.87% | 103863 | mysidia at gmail.com 2.23% | 13 | 1.50% | 83549 | dogwallah at gmail.com 1.37% | 8 | 2.23% | 124178 | stephen at sprunk.org 2.06% | 12 | 1.41% | 78556 | drc at virtualized.org 1.72% | 10 | 1.71% | 94826 | scottleibrand at gmail.com 0.86% | 5 | 2.05% | 113892 | daniel_alexander at cable.comcast.com 1.55% | 9 | 1.27% | 70667 | tedm at ipinc.net 1.37% | 8 | 1.04% | 58087 | hannigan at gmail.com 1.37% | 8 | 0.98% | 54648 | frnkblk at iname.com 1.20% | 7 | 1.09% | 60891 | keith at jcc.com 1.37% | 8 | 0.89% | 49550 | info at arin.net 1.20% | 7 | 0.88% | 48884 | cgrundemann at gmail.com 0.69% | 4 | 1.29% | 71875 | rudi.daniel at gmail.com 1.03% | 6 | 0.81% | 45309 | george.herbert at gmail.com 1.03% | 6 | 0.65% | 35887 | mpetach at netflight.com 0.69% | 4 | 0.83% | 46412 | kkargel at polartel.com 0.52% | 3 | 0.99% | 54812 | wesley.e.george at sprint.com 0.69% | 4 | 0.76% | 42061 | william.c.hale at windstream.com 0.86% | 5 | 0.53% | 29538 | rfg at tristatelogic.com 0.52% | 3 | 0.84% | 46700 | warren at wholesaleinternet.com 0.69% | 4 | 0.55% | 30335 | bicknell at ufp.org 0.69% | 4 | 0.44% | 24682 | michel at arneill-py.sacramento.ca.us 0.69% | 4 | 0.37% | 20501 | ebw at abenaki.wabanaki.net 0.34% | 2 | 0.59% | 32627 | john.sweeting at gmail.com 0.52% | 3 | 0.36% | 19972 | john.sweeting at twcable.com 0.52% | 3 | 0.31% | 17301 | gary.buhrmaster at gmail.com 0.34% | 2 | 0.38% | 20959 | mueller at syr.edu 0.17% | 1 | 0.54% | 30212 | kevin.billings at spirittelecom.com 0.17% | 1 | 0.53% | 29733 | john.kuhn at ontario.ca 0.34% | 2 | 0.27% | 15073 | springer at inlandnet.com 0.34% | 2 | 0.26% | 14394 | marka at isc.org 0.34% | 2 | 0.23% | 12966 | wavetossed at googlemail.com 0.17% | 1 | 0.22% | 12376 | fernattj at gmail.com 0.17% | 1 | 0.21% | 11852 | anadarajah at primustel.ca 0.17% | 1 | 0.17% | 9176 | bret at getjive.com 0.17% | 1 | 0.15% | 8442 | rbf+arin-ppml at panix.com 0.17% | 1 | 0.15% | 8285 | lsawyer at gci.com 0.17% | 1 | 0.15% | 8264 | narten at us.ibm.com 0.17% | 1 | 0.15% | 8093 | carlosm3011 at gmail.com 0.17% | 1 | 0.14% | 7855 | lar at mwtcorp.net 0.17% | 1 | 0.12% | 6723 | tvest at eyeconomics.com 0.17% | 1 | 0.12% | 6525 | lea.roberts at stanford.edu 0.17% | 1 | 0.11% | 6190 | rcarpen at network1.net 0.17% | 1 | 0.10% | 5792 | tony.li at tony.li 0.17% | 1 | 0.10% | 5743 | john at egh.com 0.17% | 1 | 0.10% | 5460 | aservin at lacnic.net 0.17% | 1 | 0.09% | 5273 | fw at deneb.enyo.de 0.17% | 1 | 0.09% | 5264 | jbates at brightok.net 0.17% | 1 | 0.09% | 5245 | ggm at apnic.net 0.17% | 1 | 0.09% | 5200 | john at cv.net 0.17% | 1 | 0.09% | 5098 | brandon at dodecatec.com 0.17% | 1 | 0.09% | 5040 | jcurran at istaff.org 0.17% | 1 | 0.09% | 5019 | joe at oregon.uoregon.edu 0.17% | 1 | 0.08% | 4372 | dave at connetrix.com --------+------+--------+----------+------------------------ 100.00% | 582 |100.00% | 5560897 | Total From owen at delong.com Fri May 6 02:12:29 2011 From: owen at delong.com (Owen DeLong) Date: Thu, 5 May 2011 23:12:29 -0700 Subject: [arin-ppml] Statistics regarding NRPM 8.3 Transfers to date In-Reply-To: <20110506015533.GA17557@panix.com> References: <49E26DCB-DAF7-4A0A-912E-F981494979F5@delong.com> <4DBC2AEB.9040307@matthew.at> <4DBCA58D.4060704@sprunk.org> <2344ADD7-616E-4FA7-9552-19735926A952@delong.com> <20110506015533.GA17557@panix.com> Message-ID: <47F3750B-DEC9-4393-A90C-4109E24BB248@delong.com> On May 5, 2011, at 6:55 PM, Brett Frankenberger wrote: > On Mon, May 02, 2011 at 01:32:43PM -0700, Owen DeLong wrote: >> >> So... I'll try to provide some examples of what should and shouldn't >> be allowed... > > The following questions aren't intended to be argumentative, but > rather, to define the line more clearly. > >> 1. Org. A has a /8 and wants to transfer 32 of it's constituent /24s to Org. B. >> However, Org. A doesn't want to put any effort into renumbering, >> so, those 32 /24s are each individual non-aggregable /24s. >> >> This transfer should not be allowed. >> >> 2. Org. A has a /20 and a /18. Org. B has need for a /19. Org. A has >> deprecated their use of the /20 and all of their resources are in >> the /18, but, they are using just under 75% of the /18. >> >> Org. A would rather transfer the /20 and the top 1/4 of the /18 than >> renumber that 1/4 of the /18 into the /20. >> >> This transfer should not be allowed (though I admit the case against >> it is weak). >> >> 3. Org. A has four disparate /20s. Org B. has need of a /19. Org. A >> would like to transfer two of their /20s to Org. B, but does not have >> any pair of /20s which can be aggregated. >> >> This transfer should be allowed. The /20s are already disaggregated >> in the routing table and there is no increase in routing table >> size that results. >> >> 4. Org. A has four disparate /20s. Orgs. B, C, D, and E all have need >> for /24s. Org. A would like to sell individual /24s from one of their >> /20s to each of the above Orgs. (B,C, D, and E). >> >> These transfers should be allowed as there is no significant >> difference between this and transfers where ARIN has >> carved up a block during the initial allocations. The transfer >> sizes comply with community accepted policy. > > As part of your #4 above, which of the following disaggregations would > you allow: > > #1 (this is the most efficient possible, so I'm assuming you'd allow > this): Org. A splits /20 #1 into 4 /24s all from one /22 (and > transfers the four /24s), leaving it with a /22 and a /21 and the other > three /20s it startd with. > Yes > #2: Org. A splits /20 #1 such that one /24 can be transferred from > each /22, so four /24s are transferred, leaving Org. A with four /24s > and four /23 (from /20 #1) and the other three /20s it started with. > Depending on chronology, I'm not sure this could be avoided, but, I agree it is not ideal. > #3: Org. A splits each /20 and transfers one /24 from each, leaving it > with a /24, /23, /22, and a /21 from each /20. So the result is 4 > /24s transferred, and Org. A has 5 /24s, 4 /23s, 4 /22s, and 4 /21s > remaining. > Same answer as #2. > (If the answer to #2 or #3 is "no", is it dependant on Orgs B, C, D, > and E all coming at the same time. Would the answer change if the Org > B transfer were completed, then a few months later, Org C came along > (and a transfer completed), then Org D a few months later, and so on.) > It would. Not because I want it that way, so much as I'm not sure there is an effective mechanism by which to enforce solution #1 over a longer chronology. > Also, separately, suppose Org A. has one /20, and Org. B has a need > for a /23. Org. A splits the /20 into two /23s, a /22, and a /21, > and transfers one of the /23s. (Presumably this would be allowed.) > Now, a few months after that Org. C comes along and demonstrates a need > for a /24. What is Org. A allowed to do? Can they split the /23 they > have left and transfer half of it? (Presuambly yes). But would they > have to split the /23? Or could they split the /22 or the /21 instead? > Ideally they'd split the /23, but, I don't see how we can usefully prevent the other solutions without making the policy overly complex or accidentally blocking transfers that should succeed. > Suppose that, instead of needing a /24, Org. C needed a /23. Does the > answer change? (That is, is Org. A allowed only to transfer the /23? > Or can they split the /22 or the /21?) > Ideally, they would transfer the /23, but, this is also subject to the same caveats as above. > Finally, suppose that Org. A has two /23, a /22, and a /21, but they > didn't get there by splitting a /20. Instead, it's four separate > allocations they received from ARIN several years in the past. > (Assume that's possible. Or, if you prefer, subtract 3 from the mask > length of every prefix in my examples to keep everything at /21 and > longer.) Does that change the answers to what happens when Org. C comes > along wanting a /23 or a /24? > No. >> In essence, I'm trying to say that transfers which create unnecessary >> additional disaggregation should be avoided. > > The devil is in the details, though. > Agreed. Owen From jeffrey.lyon at blacklotus.net Fri May 6 09:58:00 2011 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Fri, 6 May 2011 09:58:00 -0400 Subject: [arin-ppml] ARIN-prop-146 Clarify Justified Need for Transfers In-Reply-To: References: <4DBEF120.4080901@arin.net> <88F39B20-5C20-45F0-AD61-5FA1E7F84CE3@delong.com> <4DBF6727.1090303@matthew.at> <097AAC1C-1F68-4820-9274-3290ADEFA195@delong.com> <9501EA7E-FDAD-4DDA-B9E8-08C2811FF642@delong.com> <4DBF82F6.7050608@matthew.at> <20110503145144.N15967@mail.inlandnet.com> <4DC084E7.5000302@matthew.at> <4DC08664.4060905@matthew.at> <4791A59E-8864-483C-9BB0-03A6A5B8D50C@delong.com> <66466F57-4365-4ADB-94EB-E023F01B17CB@delong.com> <30D12BA8-9A6C-4E62-9A67-8B4FEA0EA8C1@matthew.at> <00af01cc0aa7$845a5330$8d0ef990$@net> <8695009A81378E48879980039EEDAD289D0E5BD9@MAIL1.polartel.local> <5542F2FC72CC4995A4205A4C1C844F5E@mike> Message-ID: On Fri, May 6, 2011 at 12:38 AM, McTim wrote: > Hi Mike, > > On Thu, May 5, 2011 at 11:30 PM, Mike Burns wrote: >> > >> >> >> When exhaust happens, even if you have need, ?you are going to have to pay >> the price required for somebody to sell to you instead of to another person >> with need, according to current policy. > > or wait inline until ARIN gets some more, or use private addressing, > or move to IPv6.... This is the meat of the issue. Those who wish to restrict ownership or transferability of IPv4 are generally advocating migration to IPv6 as the end all solution to any IPv4 problem. It most likely is, long term, but that does not fix the near term issue of companies that have not migrated for various reasons. Naturally, your rebuttal will be something to the effect of "their fault, not mine," but keep in mind that some of us actually want to see IPv4 continue to survive for a period of time for those who do rely on it and do not want to incur the substantial costs to upgrade their networks or do not wish to fight through early compatibility issues. Let's refer to this chart: http://en.wikipedia.org/wiki/File:DiffusionOfInnovation.png . By this assertion, ~50% of resource holders are going to be late to adopt and will inevitably be hurt by IPv4 policies that are in place today. -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications - AS32421 First and Leading in DDoS Protection Solutions From jcurran at arin.net Fri May 6 10:34:34 2011 From: jcurran at arin.net (John Curran) Date: Fri, 6 May 2011 14:34:34 +0000 Subject: [arin-ppml] ARIN-prop-146 Clarify Justified Need for Transfers In-Reply-To: References: <4DBEF120.4080901@arin.net> <88F39B20-5C20-45F0-AD61-5FA1E7F84CE3@delong.com> <4DBF6727.1090303@matthew.at> <097AAC1C-1F68-4820-9274-3290ADEFA195@delong.com> <9501EA7E-FDAD-4DDA-B9E8-08C2811FF642@delong.com> <4DBF82F6.7050608@matthew.at> <20110503145144.N15967@mail.inlandnet.com> <4DC084E7.5000302@matthew.at> <4DC08664.4060905@matthew.at> <4791A59E-8864-483C-9BB0-03A6A5B8D50C@delong.com> <66466F57-4365-4ADB-94EB-E023F01B17CB@delong.com> <30D12BA8-9A6C-4E62-9A67-8B4FEA0EA8C1@matthew.at> <00af01cc0aa7$845a5330$8d0ef990$@net> <8695009A81378E48879980039EEDAD289D0E5BD9@MAIL1.polartel.local> <5542F2FC72CC4995A4205A4C1C844F5E@mike> Message-ID: <0492060B-A00F-4C1E-9722-90F6A00ABD94@arin.net> On May 6, 2011, at 9:58 AM, Jeffrey Lyon wrote: > Let's refer to this chart: > http://en.wikipedia.org/wiki/File:DiffusionOfInnovation.png . By this > assertion, ~50% of resource holders are going to be late to adopt and > will inevitably be hurt by IPv4 policies that are in place today. To the extent that any of the those parties need resources, that's provided by having a specified transfer policy (which is already present in the ARIN region). Can you better characterize how they will be "hurt" by present policies? Thanks! /John John Curran President and CEO ARIN From jeffrey.lyon at blacklotus.net Fri May 6 10:51:55 2011 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Fri, 6 May 2011 10:51:55 -0400 Subject: [arin-ppml] ARIN-prop-146 Clarify Justified Need for Transfers In-Reply-To: <0492060B-A00F-4C1E-9722-90F6A00ABD94@arin.net> References: <4DBEF120.4080901@arin.net> <88F39B20-5C20-45F0-AD61-5FA1E7F84CE3@delong.com> <4DBF6727.1090303@matthew.at> <097AAC1C-1F68-4820-9274-3290ADEFA195@delong.com> <9501EA7E-FDAD-4DDA-B9E8-08C2811FF642@delong.com> <4DBF82F6.7050608@matthew.at> <20110503145144.N15967@mail.inlandnet.com> <4DC084E7.5000302@matthew.at> <4DC08664.4060905@matthew.at> <4791A59E-8864-483C-9BB0-03A6A5B8D50C@delong.com> <66466F57-4365-4ADB-94EB-E023F01B17CB@delong.com> <30D12BA8-9A6C-4E62-9A67-8B4FEA0EA8C1@matthew.at> <00af01cc0aa7$845a5330$8d0ef990$@net> <8695009A81378E48879980039EEDAD289D0E5BD9@MAIL1.polartel.local> <5542F2FC72CC4995A4205A4C1C844F5E@mike> <0492060B-A00F-4C1E-9722-90F6A00ABD94@arin.net> Message-ID: On Fri, May 6, 2011 at 10:34 AM, John Curran wrote: > On May 6, 2011, at 9:58 AM, Jeffrey Lyon wrote: > >> Let's refer to this chart: >> http://en.wikipedia.org/wiki/File:DiffusionOfInnovation.png . By this >> assertion, ~50% of resource holders are going to be late to adopt and >> will inevitably be hurt by IPv4 policies that are in place today. > > To the extent that any of the those parties need resources, that's > provided by having a specified transfer policy (which is already > present in the ARIN region). ?Can you better characterize how they > will be "hurt" by present policies? > > Thanks! > /John > > John Curran > President and CEO > ARIN > > John, I was referring to the current limitations of 12 month supply, justified need, and so forth. In contrast, the /32 we were recently issued is more like a 12 year supply. Once we fully migrate to IPv6 we most likely will never have to come back to ARIN for more resources, at least not in the foreseeable future. Unfortunately, migrating to IPv6 is very costly. I'm spending thousands in engineering time migrating our network to dual stack, carriers don't have sufficient experience in IPv6 to avoid annoying problems, and many vendors don't have IPv6 support, yet. We have some hardware that we will not be able to use on our v6 net and even cPanel doesn't have IPv6 support, yet. Once we stop breathing the IPv6 fumes the reality sets in that 4-to-6 migration will continue to be a long and painful process. In the near term, there will be companies who wish to secure enough IPv4 resources to support not only current, but future need. Conservation measures in place right now make this more difficult. Prop-147 should help relieve some pressure, especially if my recommendation to extend need to 36 months is implemented. Ultimately, allowing resource holders to opt out of the current system and freely exchange resources, much like premium domain names, would go even further to not only solve this issue but to make IPv6 look way more attractive. If ARIN declines to allow justification-less transfers, would be resource vendors will stay on the black market. I hear a lot of gouge in C-squad circles about how acquisitions are being conducted just to conduct illicit transfers of /17 - /20 allocations. The justifications that are being used to hold on to resources seem really loose. I made one fraud report last year and it was closed without action. I won't criticize ARIN for that action; I merely wish to point out that the black market and false resource justifications are alive and well. We can eliminate the IP black market by allowing justification-less transfers. -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications - AS32421 First and Leading in DDoS Protection Solutions From jcurran at arin.net Fri May 6 11:04:25 2011 From: jcurran at arin.net (John Curran) Date: Fri, 6 May 2011 15:04:25 +0000 Subject: [arin-ppml] ARIN-prop-146 Clarify Justified Need for Transfers In-Reply-To: References: <4DBEF120.4080901@arin.net> <88F39B20-5C20-45F0-AD61-5FA1E7F84CE3@delong.com> <4DBF6727.1090303@matthew.at> <097AAC1C-1F68-4820-9274-3290ADEFA195@delong.com> <9501EA7E-FDAD-4DDA-B9E8-08C2811FF642@delong.com> <4DBF82F6.7050608@matthew.at> <20110503145144.N15967@mail.inlandnet.com> <4DC084E7.5000302@matthew.at> <4DC08664.4060905@matthew.at> <4791A59E-8864-483C-9BB0-03A6A5B8D50C@delong.com> <66466F57-4365-4ADB-94EB-E023F01B17CB@delong.com> <30D12BA8-9A6C-4E62-9A67-8B4FEA0EA8C1@matthew.at> <00af01cc0aa7$845a5330$8d0ef990$@net> <8695009A81378E48879980039EEDAD289D0E5BD9@MAIL1.polartel.local> <5542F2FC72CC4995A4205A4C1C844F5E@mike> <0492060B-A00F-4C1E-9722-90F6A00ABD94@arin.net> Message-ID: On May 6, 2011, at 10:51 AM, Jeffrey Lyon wrote: > On Fri, May 6, 2011 at 10:34 AM, John Curran wrote: >> On May 6, 2011, at 9:58 AM, Jeffrey Lyon wrote: >> >>> Let's refer to this chart: >>> http://en.wikipedia.org/wiki/File:DiffusionOfInnovation.png . By this >>> assertion, ~50% of resource holders are going to be late to adopt and >>> will inevitably be hurt by IPv4 policies that are in place today. >> >> To the extent that any of the those parties need resources, that's >> provided by having a specified transfer policy (which is already >> present in the ARIN region). Can you better characterize how they >> will be "hurt" by present policies? > > John, > > I was referring to the current limitations of 12 month supply, > justified need, and so forth. You note the limitations, but I am still trying to understand out how these constraints would "hurt" someone who needs IPv4 address space. I see how they may pose an administrative burden, but there will be some additional administrative burden in going to the market to obtain IPv4 space in any case. Are you saying that this additional administrative hassle is the "harm" that late adopters will experience, or something more than that? Thanks, /John John Curran President and CEO ARIN From jeffrey.lyon at blacklotus.net Fri May 6 11:11:15 2011 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Fri, 6 May 2011 11:11:15 -0400 Subject: [arin-ppml] ARIN-prop-146 Clarify Justified Need for Transfers In-Reply-To: References: <4DBEF120.4080901@arin.net> <88F39B20-5C20-45F0-AD61-5FA1E7F84CE3@delong.com> <4DBF6727.1090303@matthew.at> <097AAC1C-1F68-4820-9274-3290ADEFA195@delong.com> <9501EA7E-FDAD-4DDA-B9E8-08C2811FF642@delong.com> <4DBF82F6.7050608@matthew.at> <20110503145144.N15967@mail.inlandnet.com> <4DC084E7.5000302@matthew.at> <4DC08664.4060905@matthew.at> <4791A59E-8864-483C-9BB0-03A6A5B8D50C@delong.com> <66466F57-4365-4ADB-94EB-E023F01B17CB@delong.com> <30D12BA8-9A6C-4E62-9A67-8B4FEA0EA8C1@matthew.at> <00af01cc0aa7$845a5330$8d0ef990$@net> <8695009A81378E48879980039EEDAD289D0E5BD9@MAIL1.polartel.local> <5542F2FC72CC4995A4205A4C1C844F5E@mike> <0492060B-A00F-4C1E-9722-90F6A00ABD94@arin.net> Message-ID: On Fri, May 6, 2011 at 11:04 AM, John Curran wrote: > On May 6, 2011, at 10:51 AM, Jeffrey Lyon wrote: > >> On Fri, May 6, 2011 at 10:34 AM, John Curran wrote: >>> On May 6, 2011, at 9:58 AM, Jeffrey Lyon wrote: >>> >>>> Let's refer to this chart: >>>> http://en.wikipedia.org/wiki/File:DiffusionOfInnovation.png . By this >>>> assertion, ~50% of resource holders are going to be late to adopt and >>>> will inevitably be hurt by IPv4 policies that are in place today. >>> >>> To the extent that any of the those parties need resources, that's >>> provided by having a specified transfer policy (which is already >>> present in the ARIN region). ?Can you better characterize how they >>> will be "hurt" by present policies? >> >> John, >> >> I was referring to the current limitations of 12 month supply, >> justified need, and so forth. > > You note the limitations, but I am still trying to understand out how these > constraints would "hurt" someone who needs IPv4 address space. ?I see how > they may pose an administrative burden, but there will be some additional > administrative burden in going to the market to obtain IPv4 space in any > case. ?Are you saying that this additional administrative hassle is the > "harm" that late adopters will experience, or something more than that? > > Thanks, > /John > > John Curran > President and CEO > ARIN > > > > > John, Administrative burden is one element. I also presume there are an abundance of companies who are a) very profitable and b) require significant amounts of IPv4 space to remain profitable. They could easily buy this space from those with lesser need, if permitted. Instead, the community is saying "stop, don't do that, put your operations on hold for a while until your vendors figure out how to support IPv6." STLS is a step in the right direction and making this program less restrictive is even better. Ideally, if I have a /20 now and decide I need a /18 to satisfy all future need prior to completing a full migration to IPv6, and I have the cash to do it, then it should be allowed. -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications - AS32421 First and Leading in DDoS Protection Solutions From mike at nationwideinc.com Fri May 6 11:47:12 2011 From: mike at nationwideinc.com (Mike Burns) Date: Fri, 6 May 2011 11:47:12 -0400 Subject: [arin-ppml] Draft proposal that needs some wordsmithing References: <9638601B94304E4392112CF98CDE757C@mike><4DC31B41.3090001@umn.edu> Message-ID: <940FF59153304663A8094B5EEB172AD3@mike> Hi Chris, > >> The underlying proposition behind this policy proposal is that the >> registry of IPv4 addresses operated by ARIN is of general utility and >> value only while it accurately describes the current state of address >> distribution. If a class of address movement transactions are excluded >> from being entered in the registry, then the registry will have >> decreasing value to the broader community, and the integrity of the >> network itself is thereby compromised. This proposal's central aim is >> to ensure the continuing utility and value of the ARIN address >> registry by allowing the registry to record transactions where IPv4 >> addresses are transfered between ARIN account holders. > > Here is where you lose me. The first two sentences are fundamentally > true and the third sentence is a valuable and noble goal. The piece of > the puzzle that I am still missing is this: Why would organizations > choose to "move addresses" in an excluded manner? A few facts that I > find important: > > 1) IPv4 addresses have value for Internet routing only if they are unique. Yes, good stewardship should have reliable registry service as a primary goal. > 2) The best way to ensure uniqueness on this scale is to maintain a > public record or database of some form. Yes, a publilcy queryable database to determine routing authority and to maintain uniqueness of registry. > 3) ARIN (and the other RIRs, in cooperation with the IANA) maintains > entries in such a database (plus a couple other services provided) for > a nominal fee. Yes. > 4) Because spots in this database are limited, for at least the last > decade (it can be argued that this was true from the very beginning, > with increasing oversight over time), receiving a spot in this > database has required a justification of need. You've had to > demonstrate that you were actually going to use the spot that you > wanted to occupy to add value to the global network. Yes, it made obvious sense to apply a needs requirement to the allocation of addresses from the free pool. > 5) Completely new spots in the database (unused IPv4 addresses) are > about to run out. Yes. > > Based on those facts, I end up with two questions: > > 1) How/why does fact number five change any of the preceding facts? > (i.e. Why should the realization of scarcity change our stewardship > behavior, behavior that was based on an understanding of scarcity?) Because prior to exhaust there was no other mechanism to ensure addresses were allocated and used efficiently. After exhaust a free market is the appropriate mechanism to ensure addresses are allocated and used efficiently. Prior to exhaust, without such a mechanism, I could have walked up and asked for a /2. Obviously to anybody, I hope, that would have been unworkable. The system that was devised and implemented was a needs analysis which simply made allocations according to demonstrated need. The ensured that at least at the start, addresses would not be frivolously wasted. After exhaust and in the presence of a free market, the price of the addresses will fill the role that needs analysis filled before. They will cause addresses to move to efficient usage. We know the needs requirement was not a perfect way to ensure efficiencies. We know that from the number or allocated and not advertised space, if nothing else. A market will not be perfect either, but unlike the prior needs analysis, we seem to be judging the free market by the exceptions. > 2) Why would any organization with need for unique IPv4 addresses > choose to not have those addresses recorded in the database which > guarantees their value in order to escape stating their need? (i.e. > What class of organization with legitimate need would be hurt by > having to demonstrate that need before receiving addresses?) > An aggregator buying unroutable bits to aggregate to a routable size?. Somebody who has a different view on the IPv6 transition timeframe and has a longer planning horizon for IPv4? A reseller of vanity addresses, like 100.100.100.100? A wholesaler of addresses who caters to those who need instant availability (needs analysis takes time)? A speculator, who could have a positive role in free markets? An organization that does not want to undergo an ARIN analysis for fear it will lead to a review and recovery procedure? An organization from another region? A buyer of a /24 who thinks an ARIN needs analysis isn't worth the expense? Microsoft? They didn't seem to want or need a needs analysis until ARIN began negotiating with them after the original asset agreement with Nortel had been negotiated. I don't pretend to be able to able to identify all the types of transactions for which an ARIN needs analysis seems an unnecessary intrusion into a transaction between two private entities. The point is that many prior transfers have taken place, particularly with legacy space, that have not been reflected in whois. One of the problems relates to the requirement for a needs analysis. If a holder of legacy space acquired through an asset sale approached ARIN to reflect that transfer, ARIN would not update whois without a needs analysis. In addition, the requirement for ARIN to do a needs analysis and the potential for review and recovery on either the buyer or seller increases the FUD factor in the market. For a market to function efficiently, Fear, Uncertainty, and Doubt need to be assuaged, and this proposal does that. I copied liberally, almost entirely, from the APNIC policy to allow needs-free transfers. The rationale which was most effective in that regions's deliberations may have been the concern that by imposing the needs requirement, transactions would be more likely to occur outside the system, leading to a decay in whois reliability. By structuring my proposal in this way, I am trying to get people to consider whether the original and laudable needs requirement should be maintained when keeping it could lead to whois degradation. My argument is that proper stewardship recognizes the existence of a market which will fulfill the original stewarship role of ensuring efficient use, and we can direct our stewardship best to policies which help to ensure whois veracity. Regards, Mike From owen at delong.com Fri May 6 11:48:42 2011 From: owen at delong.com (Owen DeLong) Date: Fri, 6 May 2011 08:48:42 -0700 Subject: [arin-ppml] ARIN-prop-146 Clarify Justified Need for Transfers In-Reply-To: References: <4DBEF120.4080901@arin.net> <88F39B20-5C20-45F0-AD61-5FA1E7F84CE3@delong.com> <4DBF6727.1090303@matthew.at> <097AAC1C-1F68-4820-9274-3290ADEFA195@delong.com> <9501EA7E-FDAD-4DDA-B9E8-08C2811FF642@delong.com> <4DBF82F6.7050608@matthew.at> <20110503145144.N15967@mail.inlandnet.com> <4DC084E7.5000302@matthew.at> <4DC08664.4060905@matthew.at> <4791A59E-8864-483C-9BB0-03A6A5B8D50C@delong.com> <66466F57-4365-4ADB-94EB-E023F01B17CB@delong.com> <30D12BA8-9A6C-4E62-9A67-8B4FEA0EA8C1@matthew.at> <00af01cc0aa7$845a5330$8d0ef990$@net> <8695009A81378E48879980039EEDAD289D0E5BD9@MAIL1.polartel.local> <5542F2FC72CC4995A4205A4C1C844F5E@mike> Message-ID: <0FA3D011-11CE-4926-B9F8-3F6940DC0742@delong.com> On May 6, 2011, at 6:58 AM, Jeffrey Lyon wrote: > On Fri, May 6, 2011 at 12:38 AM, McTim wrote: >> Hi Mike, >> >> On Thu, May 5, 2011 at 11:30 PM, Mike Burns wrote: >>> >> >>> >>> >>> When exhaust happens, even if you have need, you are going to have to pay >>> the price required for somebody to sell to you instead of to another person >>> with need, according to current policy. >> >> or wait inline until ARIN gets some more, or use private addressing, >> or move to IPv6.... > > This is the meat of the issue. Those who wish to restrict ownership or > transferability of IPv4 are generally advocating migration to IPv6 as > the end all solution to any IPv4 problem. It most likely is, long > term, but that does not fix the near term issue of companies that have > not migrated for various reasons. > You can not and should not infer from my advocacy of IPv6 as the real solution any idea that I have any desire to inflict additional pain on those attempting to eek additional life out of IPv4. That simply is not the case. In fact, I want to restrict ownership transferability in order to reduce the amount of pain and increase the efficiency of the utilization of IPv4 space. Unrestricted transfers allow manipulations and hoarding of the IPv4 space by parties with commercial interests outside of the efficient use of IPv4. > Naturally, your rebuttal will be something to the effect of "their > fault, not mine," but keep in mind that some of us actually want to > see IPv4 continue to survive for a period of time for those who do > rely on it and do not want to incur the substantial costs to upgrade > their networks or do not wish to fight through early compatibility > issues. Let's refer to this chart: > http://en.wikipedia.org/wiki/File:DiffusionOfInnovation.png . By this > assertion, ~50% of resource holders are going to be late to adopt and > will inevitably be hurt by IPv4 policies that are in place today. > I always enjoy when people want to put words in my mouth. Especially when what they claim I will say is completely contrary to what I would actually say. I would love to see IPv4 be viable for decades to come. However, I also see the reality that that possibility is about as remote as a rainforest in the middle of Nevada. You assert that 50% of resource holders will be late and will be hurt by today's IPv4 policies. Since you don't provide any data or assertions, I'll arbitrarily say that I would expect 75% of resource holders to be hurt by more liberalized transfer policies. I'm not sure how that is relevant to the discussion, however. Speaking of the pain of existing policies is meaningless without the comparative context of how proposed policy would affect that pain. I have not seen anything to convince me that more relaxed transfer policies would reduce pain overall. Every indication is that it will increase pain for those without financial resources while providing somewhat better relief for those with financial resources if everyone is a good actor and there are no manipulations. I see several potentials for manipulations in a more liberalized environment, however, and many opportunities for those with the interest in doing so to inflict tremendous harm on their smaller competitors through market manipulation. This would significantly increase the overall pain while failing to effectively extend the useful life of IPv4 for any but a handful of very large ISPs. Owen From owen at delong.com Fri May 6 11:54:22 2011 From: owen at delong.com (Owen DeLong) Date: Fri, 6 May 2011 08:54:22 -0700 Subject: [arin-ppml] ARIN-prop-146 Clarify Justified Need for Transfers In-Reply-To: References: <4DBEF120.4080901@arin.net> <88F39B20-5C20-45F0-AD61-5FA1E7F84CE3@delong.com> <4DBF6727.1090303@matthew.at> <097AAC1C-1F68-4820-9274-3290ADEFA195@delong.com> <9501EA7E-FDAD-4DDA-B9E8-08C2811FF642@delong.com> <4DBF82F6.7050608@matthew.at> <20110503145144.N15967@mail.inlandnet.com> <4DC084E7.5000302@matthew.at> <4DC08664.4060905@matthew.at> <4791A59E-8864-483C-9BB0-03A6A5B8D50C@delong.com> <66466F57-4365-4ADB-94EB-E023F01B17CB@delong.com> <30D12BA8-9A6C-4E62-9A67-8B4FEA0EA8C1@matthew.at> <00af01cc0aa7$845a5330$8d0ef990$@net> <8695009A81378E48879980039EEDAD289D0E5BD9@MAIL1.polartel.local> <5542F2FC72CC4995A4205A4C1C844F5E@mike> <0492060B-A00F-4C1E-9722-90F6A00ABD94@arin.net> Message-ID: <7BDE0C6C-E500-413C-9D60-96552490D902@delong.com> On May 6, 2011, at 7:51 AM, Jeffrey Lyon wrote: > On Fri, May 6, 2011 at 10:34 AM, John Curran wrote: >> On May 6, 2011, at 9:58 AM, Jeffrey Lyon wrote: >> >>> Let's refer to this chart: >>> http://en.wikipedia.org/wiki/File:DiffusionOfInnovation.png . By this >>> assertion, ~50% of resource holders are going to be late to adopt and >>> will inevitably be hurt by IPv4 policies that are in place today. >> >> To the extent that any of the those parties need resources, that's >> provided by having a specified transfer policy (which is already >> present in the ARIN region). Can you better characterize how they >> will be "hurt" by present policies? >> >> Thanks! >> /John >> >> John Curran >> President and CEO >> ARIN >> >> > > John, > > I was referring to the current limitations of 12 month supply, > justified need, and so forth. In contrast, the /32 we were recently > issued is more like a 12 year supply. Once we fully migrate to IPv6 we > most likely will never have to come back to ARIN for more resources, > at least not in the foreseeable future. > Interesting... Even with IPv6 being a limited deployment until very recently (limited by customer demand, not by our network), HE has consumed our /32 to the point of an HD ratio well above 1.0 in less than 10 years. > Unfortunately, migrating to IPv6 is very costly. I'm spending > thousands in engineering time migrating our network to dual stack, > carriers don't have sufficient experience in IPv6 to avoid annoying > problems, and many vendors don't have IPv6 support, yet. We have some > hardware that we will not be able to use on our v6 net and even cPanel > doesn't have IPv6 support, yet. > Perhaps you should be talking to better carriers. There are some with significant experience and very few annoying problems. > Once we stop breathing the IPv6 fumes the reality sets in that 4-to-6 > migration will continue to be a long and painful process. In the near > term, there will be companies who wish to secure enough IPv4 resources > to support not only current, but future need. Conservation measures in > place right now make this more difficult. Prop-147 should help relieve > some pressure, especially if my recommendation to extend need to 36 > months is implemented. Ultimately, allowing resource holders to opt > out of the current system and freely exchange resources, much like > premium domain names, would go even further to not only solve this > issue but to make IPv6 look way more attractive. > We found that the further along the process we got, the less painful it became. Today, it's pretty painless. > If ARIN declines to allow justification-less transfers, would be > resource vendors will stay on the black market. I hear a lot of gouge > in C-squad circles about how acquisitions are being conducted just to > conduct illicit transfers of /17 - /20 allocations. The justifications > that are being used to hold on to resources seem really loose. I made > one fraud report last year and it was closed without action. I won't > criticize ARIN for that action; I merely wish to point out that the > black market and false resource justifications are alive and well. > > We can eliminate the IP black market by allowing justification-less transfers. > We could eliminate criminal murder by making murder legal, too. I'm just not sure what the advantage is. We could eliminate the crime of theft by simply making it legal to steal. Again, I'm not seeing an advantage. The argument that a black market can be eliminated by legitimizing a market without rules is just such a tautology. Owen From jeffrey.lyon at blacklotus.net Fri May 6 11:56:36 2011 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Fri, 6 May 2011 11:56:36 -0400 Subject: [arin-ppml] ARIN-prop-146 Clarify Justified Need for Transfers In-Reply-To: <0FA3D011-11CE-4926-B9F8-3F6940DC0742@delong.com> References: <4DBEF120.4080901@arin.net> <88F39B20-5C20-45F0-AD61-5FA1E7F84CE3@delong.com> <4DBF6727.1090303@matthew.at> <097AAC1C-1F68-4820-9274-3290ADEFA195@delong.com> <9501EA7E-FDAD-4DDA-B9E8-08C2811FF642@delong.com> <4DBF82F6.7050608@matthew.at> <20110503145144.N15967@mail.inlandnet.com> <4DC084E7.5000302@matthew.at> <4DC08664.4060905@matthew.at> <4791A59E-8864-483C-9BB0-03A6A5B8D50C@delong.com> <66466F57-4365-4ADB-94EB-E023F01B17CB@delong.com> <30D12BA8-9A6C-4E62-9A67-8B4FEA0EA8C1@matthew.at> <00af01cc0aa7$845a5330$8d0ef990$@net> <8695009A81378E48879980039EEDAD289D0E5BD9@MAIL1.polartel.local> <5542F2FC72CC4995A4205A4C1C844F5E@mike> <0FA3D011-11CE-4926-B9F8-3F6940DC0742@delong.com> Message-ID: On Fri, May 6, 2011 at 11:48 AM, Owen DeLong wrote: > > On May 6, 2011, at 6:58 AM, Jeffrey Lyon wrote: > >> On Fri, May 6, 2011 at 12:38 AM, McTim wrote: >>> Hi Mike, >>> >>> On Thu, May 5, 2011 at 11:30 PM, Mike Burns wrote: >>>> >>> >>>> >>>> >>>> When exhaust happens, even if you have need, ?you are going to have to pay >>>> the price required for somebody to sell to you instead of to another person >>>> with need, according to current policy. >>> >>> or wait inline until ARIN gets some more, or use private addressing, >>> or move to IPv6.... >> >> This is the meat of the issue. Those who wish to restrict ownership or >> transferability of IPv4 are generally advocating migration to IPv6 as >> the end all solution to any IPv4 problem. It most likely is, long >> term, but that does not fix the near term issue of companies that have >> not migrated for various reasons. >> > You can not and should not infer from my advocacy of IPv6 as > the real solution any idea that I have any desire to inflict additional > pain on those attempting to eek additional life out of IPv4. > > That simply is not the case. > > In fact, I want to restrict ownership transferability in order to reduce > the amount of pain and increase the efficiency of the utilization of > IPv4 space. Unrestricted transfers allow manipulations and hoarding > of the IPv4 space by parties with commercial interests outside of the > efficient use of IPv4. > >> Naturally, your rebuttal will be something to the effect of "their >> fault, not mine," but keep in mind that some of us actually want to >> see IPv4 continue to survive for a period of time for those who do >> rely on it and do not want to incur the substantial costs to upgrade >> their networks or do not wish to fight through early compatibility >> issues. Let's refer to this chart: >> http://en.wikipedia.org/wiki/File:DiffusionOfInnovation.png . By this >> assertion, ~50% of resource holders are going to be late to adopt and >> will inevitably be hurt by IPv4 policies that are in place today. >> > I always enjoy when people want to put words in my mouth. Especially > when what they claim I will say is completely contrary to what I would > actually say. > > I would love to see IPv4 be viable for decades to come. However, > I also see the reality that that possibility is about as remote as a > rainforest in the middle of Nevada. > > You assert that 50% of resource holders will be late and will be hurt > by today's IPv4 policies. Since you don't provide any data or assertions, > I'll arbitrarily say that I would expect 75% of resource holders to be > hurt by more liberalized transfer policies. > > I'm not sure how that is relevant to the discussion, however. > > Speaking of the pain of existing policies is meaningless without the > comparative context of how proposed policy would affect that > pain. I have not seen anything to convince me that more relaxed > transfer policies would reduce pain overall. Every indication is that > it will increase pain for those without financial resources while > providing somewhat better relief for those with financial resources > if everyone is a good actor and there are no manipulations. > > I see several potentials for manipulations in a more liberalized > environment, however, and many opportunities for those with > the interest in doing so to inflict tremendous harm on their > smaller competitors through market manipulation. This would > significantly increase the overall pain while failing to effectively > extend the useful life of IPv4 for any but a handful of very large > ISPs. > > > Owen > > Owen, I think most my replies were to McTim, so I wasn't trying to put words in *your* mouth. Regardless, i'll agree that those without financial resources would be hurt by more liberal transfers. I'll also counter that those with financial resources will be hurt by the current process which ties up space to benefit what i'll refer to as the less fortunate. -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications - AS32421 First and Leading in DDoS Protection Solutions From owen at delong.com Fri May 6 11:56:46 2011 From: owen at delong.com (Owen DeLong) Date: Fri, 6 May 2011 08:56:46 -0700 Subject: [arin-ppml] ARIN-prop-146 Clarify Justified Need for Transfers In-Reply-To: References: <4DBEF120.4080901@arin.net> <88F39B20-5C20-45F0-AD61-5FA1E7F84CE3@delong.com> <4DBF6727.1090303@matthew.at> <097AAC1C-1F68-4820-9274-3290ADEFA195@delong.com> <9501EA7E-FDAD-4DDA-B9E8-08C2811FF642@delong.com> <4DBF82F6.7050608@matthew.at> <20110503145144.N15967@mail.inlandnet.com> <4DC084E7.5000302@matthew.at> <4DC08664.4060905@matthew.at> <4791A59E-8864-483C-9BB0-03A6A5B8D50C@delong.com> <66466F57-4365-4ADB-94EB-E023F01B17CB@delong.com> <30D12BA8-9A6C-4E62-9A67-8B4FEA0EA8C1@matthew.at> <00af01cc0aa7$845a5330$8d0ef990$@net> <8695009A81378E48879980039EEDAD289D0E5BD9@MAIL1.polartel.local> <5542F2FC72CC4995A4205A4C1C844F5E@mike> <0492060B-A00F-4C1E-9722-90F6A00ABD94@arin.net> Message-ID: <61AAC8E6-F419-4792-95DB-2D5CE485580D@delong.com> > > STLS is a step in the right direction and making this program less > restrictive is even better. Ideally, if I have a /20 now and decide I > need a /18 to satisfy all future need prior to completing a full > migration to IPv6, and I have the cash to do it, then it should be > allowed. > What if you need a /18, but, know that by purchasing the equivalent of a /6, you can cause significantly larger additional costs to your competitors, possibly even pricing some of them out of the market? You have the cash to do it, should this be allowed? (Hint... I think some of your competitors can afford that /6 to keep you from getting your /18). Owen From jeffrey.lyon at blacklotus.net Fri May 6 12:02:13 2011 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Fri, 6 May 2011 12:02:13 -0400 Subject: [arin-ppml] ARIN-prop-146 Clarify Justified Need for Transfers In-Reply-To: <7BDE0C6C-E500-413C-9D60-96552490D902@delong.com> References: <4DBEF120.4080901@arin.net> <88F39B20-5C20-45F0-AD61-5FA1E7F84CE3@delong.com> <4DBF6727.1090303@matthew.at> <097AAC1C-1F68-4820-9274-3290ADEFA195@delong.com> <9501EA7E-FDAD-4DDA-B9E8-08C2811FF642@delong.com> <4DBF82F6.7050608@matthew.at> <20110503145144.N15967@mail.inlandnet.com> <4DC084E7.5000302@matthew.at> <4DC08664.4060905@matthew.at> <4791A59E-8864-483C-9BB0-03A6A5B8D50C@delong.com> <66466F57-4365-4ADB-94EB-E023F01B17CB@delong.com> <30D12BA8-9A6C-4E62-9A67-8B4FEA0EA8C1@matthew.at> <00af01cc0aa7$845a5330$8d0ef990$@net> <8695009A81378E48879980039EEDAD289D0E5BD9@MAIL1.polartel.local> <5542F2FC72CC4995A4205A4C1C844F5E@mike> <0492060B-A00F-4C1E-9722-90F6A00ABD94@arin.net> <7BDE0C6C-E500-413C-9D60-96552490D902@delong.com> Message-ID: On Fri, May 6, 2011 at 11:54 AM, Owen DeLong wrote: > > On May 6, 2011, at 7:51 AM, Jeffrey Lyon wrote: > >> On Fri, May 6, 2011 at 10:34 AM, John Curran wrote: >>> On May 6, 2011, at 9:58 AM, Jeffrey Lyon wrote: >>> >>>> Let's refer to this chart: >>>> http://en.wikipedia.org/wiki/File:DiffusionOfInnovation.png . By this >>>> assertion, ~50% of resource holders are going to be late to adopt and >>>> will inevitably be hurt by IPv4 policies that are in place today. >>> >>> To the extent that any of the those parties need resources, that's >>> provided by having a specified transfer policy (which is already >>> present in the ARIN region). ?Can you better characterize how they >>> will be "hurt" by present policies? >>> >>> Thanks! >>> /John >>> >>> John Curran >>> President and CEO >>> ARIN >>> >>> >> >> John, >> >> I was referring to the current limitations of 12 month supply, >> justified need, and so forth. In contrast, the /32 we were recently >> issued is more like a 12 year supply. Once we fully migrate to IPv6 we >> most likely will never have to come back to ARIN for more resources, >> at least not in the foreseeable future. >> > Interesting... Even with IPv6 being a limited deployment until very > recently (limited by customer demand, not by our network), > HE has consumed our /32 to the point of an HD ratio well > above 1.0 in less than 10 years. > >> Unfortunately, migrating to IPv6 is very costly. I'm spending >> thousands in engineering time migrating our network to dual stack, >> carriers don't have sufficient experience in IPv6 to avoid annoying >> problems, and many vendors don't have IPv6 support, yet. We have some >> hardware that we will not be able to use on our v6 net and even cPanel >> doesn't have IPv6 support, yet. >> > Perhaps you should be talking to better carriers. There are some > with significant experience and very few annoying problems. > >> Once we stop breathing the IPv6 fumes the reality sets in that 4-to-6 >> migration will continue to be a long and painful process. In the near >> term, there will be companies who wish to secure enough IPv4 resources >> to support not only current, but future need. Conservation measures in >> place right now make this more difficult. Prop-147 should help relieve >> some pressure, especially if my recommendation to extend need to 36 >> months is implemented. Ultimately, allowing resource holders to opt >> out of the current system and freely exchange resources, much like >> premium domain names, would go even further to not only solve this >> issue but to make IPv6 look way more attractive. >> > We found that the further along the process we got, the less painful > it became. Today, it's pretty painless. > >> If ARIN declines to allow justification-less transfers, would be >> resource vendors will stay on the black market. I hear a lot of gouge >> in C-squad circles about how acquisitions are being conducted just to >> conduct illicit transfers of /17 - /20 allocations. The justifications >> that are being used to hold on to resources seem really loose. I made >> one fraud report last year and it was closed without action. I won't >> criticize ARIN for that action; I merely wish to point out that the >> black market and false resource justifications are alive and well. >> >> We can eliminate the IP black market by allowing justification-less transfers. >> > We could eliminate criminal murder by making murder legal, too. > I'm just not sure what the advantage is. > > We could eliminate the crime of theft by simply making it legal > to steal. Again, I'm not seeing an advantage. > > The argument that a black market can be eliminated by legitimizing > a market without rules ?is just such a tautology. > > Owen > > > Owen, I'm talking about deregulating a civil process, not legalizing crimes. HE also provides IPv6 services to basically everyone in the world who is currently using IPv6 in some capacity. As it stands, if you're using IPv6 you almost have to be peered to HE. This is a massive contrast to a company like Black Lotus that will be hard pressed to ever fully utilize a /32. On the carrier front, our current carriers are working out but none have substantial experience in IPv6. Your employer is probably the only company in the world that has really mastered IPv6 carrier sales. Even the major carriers we deal with now are having small issues here and there, simply due to inexperience. That aside, we don't have a lot of options. How many carriers do you know of that will sell 10G's with unmetered ingress (for sinking DDoS) at a very low rate. From my research, I can count them on one hand. -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications - AS32421 First and Leading in DDoS Protection Solutions From matthew at matthew.at Fri May 6 12:22:08 2011 From: matthew at matthew.at (Matthew Kaufman) Date: Fri, 06 May 2011 09:22:08 -0700 Subject: [arin-ppml] ARIN-prop-146 Clarify Justified Need for Transfers In-Reply-To: <61AAC8E6-F419-4792-95DB-2D5CE485580D@delong.com> References: <4DBEF120.4080901@arin.net> <097AAC1C-1F68-4820-9274-3290ADEFA195@delong.com> <9501EA7E-FDAD-4DDA-B9E8-08C2811FF642@delong.com> <4DBF82F6.7050608@matthew.at> <20110503145144.N15967@mail.inlandnet.com> <4DC084E7.5000302@matthew.at> <4DC08664.4060905@matthew.at> <4791A59E-8864-483C-9BB0-03A6A5B8D50C@delong.com> <66466F57-4365-4ADB-94EB-E023F01B17CB@delong.com> <30D12BA8-9A6C-4E62-9A67-8B4FEA0EA8C1@matthew.at> <00af01cc0aa7$845a5330$8d0ef990$@net> <8695009A81378E48879980039EEDAD289D0E5BD9@MAIL1.polartel.local> <5542F2FC72CC4995A4205A4C1C844F5E@mike> <0492060B-A00F-4C1E-9722-90F6A00ABD94@arin.net> <61AAC8E6-F419-4792-95DB-2D5CE485580D@delong.com> Message-ID: <4DC42030.60806@matthew.at> On 5/6/2011 8:56 AM, Owen DeLong wrote: >> STLS is a step in the right direction and making this program less >> restrictive is even better. Ideally, if I have a /20 now and decide I >> need a /18 to satisfy all future need prior to completing a full >> migration to IPv6, and I have the cash to do it, then it should be >> allowed. >> > What if you need a /18, but, know that by purchasing the equivalent > of a /6, you can cause significantly larger additional costs to your > competitors, possibly even pricing some of them out of the market? > > You have the cash to do it, should this be allowed? No, but this policy proposal doesn't allow it, so I'm still not clear on why you're using arguments like this in order to object to the policy proposal. Matthew Kaufman From owen at delong.com Fri May 6 12:22:49 2011 From: owen at delong.com (Owen DeLong) Date: Fri, 6 May 2011 09:22:49 -0700 Subject: [arin-ppml] Draft proposal that needs some wordsmithing In-Reply-To: <940FF59153304663A8094B5EEB172AD3@mike> References: <9638601B94304E4392112CF98CDE757C@mike><4DC31B41.3090001@umn.edu> <940FF59153304663A8094B5EEB172AD3@mike> Message-ID: <468BF725-3BA3-423F-A98E-3CC762344D63@delong.com> >> >> Based on those facts, I end up with two questions: >> >> 1) How/why does fact number five change any of the preceding facts? >> (i.e. Why should the realization of scarcity change our stewardship >> behavior, behavior that was based on an understanding of scarcity?) > > Because prior to exhaust there was no other mechanism to ensure addresses were allocated and used efficiently. If a market was the best mechanism, we could have adopted policy to auction IPv4 addresses off to the highest bidders before exhaustion. Exhaustion would likely have come much earlier in such a case, but, it was possible, so, your assertion that no other mechanism existed is false. No other mechanism was chosen, but, it did exist. > After exhaust a free market is the appropriate mechanism to ensure addresses are allocated and used efficiently. This is an assertion or your opinion stated as fact. I believe that a market moderated by need is more appropriate than an unmoderated market. That is the mechanism that has been chosen by the community in this region and which came to consensus some time ago. It's possible the community may want to change that at some point, but, the presumption until some new consensus is reached is that the appropriate mechanism is the one around which the community achieved consensus. > Prior to exhaust, without such a mechanism, I could have walked up and asked for a /2. What prevents you from doing so post exhaustion in an unmoderated market if you think that purchasing all (or as much as you can) of the available address space will have a sufficient negative impact on your competitors as to be worth the investment? > Obviously to anybody, I hope, that would have been unworkable. Indeed... Hence my difficulty in seeing how it would be somehow more workable in a post exhaustion environment. > The system that was devised and implemented was a needs analysis which simply made allocations according to demonstrated need. > The ensured that at least at the start, addresses would not be frivolously wasted. It also ensured that address registrations did not become an artificially valuable commodity. Exhaustion will force this artificial valuation on such registrations, but, removing the justified need restriction from this forced market will not help the situation as it would still have the same effect of allowing waste. Admittedly, the degree of frivolity may be more a matter of perspective at that point, but, waste through capture for competitive advantage is still waste as far as I am concerned. > After exhaust and in the presence of a free market, the price of the addresses will fill the role that needs analysis filled before. I remain unconvinced of this. Indeed, I believe that the role price will pay is to substantially change that mechanism and not for the better. > They will cause addresses to move to efficient usage. Depends on how you define efficiency and assumes only good actors in the market. > We know the needs requirement was not a perfect way to ensure efficiencies. > We know that from the number or allocated and not advertised space, if nothing else. No, we do not. Allocated and not advertised DOES NOT mean underutilized. There are many legitimate reasons IP resources may be unadvertised while still fully utilized (or more accurately, utilized but not visible in any routing table to which you particularly have access). > A market will not be perfect either, but unlike the prior needs analysis, we seem to be judging the free market by the exceptions. > Since the misdeeds (which you claim will be "exceptions") in the market have the potential to overwhelm the market, where no such risk existed in the needs analysis, I think that is a legitimate approach. > >> 2) Why would any organization with need for unique IPv4 addresses >> choose to not have those addresses recorded in the database which >> guarantees their value in order to escape stating their need? (i.e. >> What class of organization with legitimate need would be hurt by >> having to demonstrate that need before receiving addresses?) >> > > An aggregator buying unroutable bits to aggregate to a routable size?. I see no reason this couldn't be done by an organization with need just as effectively as by some random aggregator intending to resell the result. > Somebody who has a different view on the IPv6 transition timeframe and has a longer planning horizon for IPv4? Then they come to the market multiple times. > A reseller of vanity addresses, like 100.100.100.100? I see no reason to promote or create these. They offer no meaningful benefit to the community at large. > A wholesaler of addresses who caters to those who need instant availability (needs analysis takes time)? My last needs analysis took less than 24 hours. The average of my last 5 needs analysis is less than 36 hours. That's real-time, not resource analyst or my hours. I think that 1-3 days to get addresses is well within reason. Frankly, the non-needs-analysis portion of my applications usually takes more time than the needs-analysis portion. > A speculator, who could have a positive role in free markets? ROFL -- The concept of speculator in the same sentence with "positive role" amuses me. > An organization that does not want to undergo an ARIN analysis for fear it will lead to a review and recovery procedure? An organization which has reason to fear this is an organization which probably shouldn't be getting additional resources from the community. > An organization from another region? You say this as if it is somehow a benefit. > A buyer of a /24 who thinks an ARIN needs analysis isn't worth the expense? Again, not seeing the benefit to the community in providing this person the opportunity to take that /24 out of the hands of some more deserving organization with documented need. > Microsoft? They didn't seem to want or need a needs analysis until ARIN began negotiating with them after the original asset agreement with Nortel had been negotiated. > This, also, strikes me as an indication that removing needs basis would have a negative impact on the overall outcome. > I don't pretend to be able to able to identify all the types of transactions for which an ARIN needs analysis seems an unnecessary intrusion into a transaction between two private entities. > What you call unnecessary, I call vital to the overall interests of the community. > The point is that many prior transfers have taken place, particularly with legacy space, that have not been reflected in whois. Hopefully as these can be identified, the space can be revoked and reallocated to organizations that comply with policy. The original legacy holder has some protections. A third party as a result of an unauthorized transfer should not have any protections in this regard. > One of the problems relates to the requirement for a needs analysis. No, the problem is the belief that community resources can be transferred outside of community policy. > If a holder of legacy space acquired through an asset sale approached ARIN to reflect that transfer, ARIN would not update whois without a needs analysis. As it should be. > In addition, the requirement for ARIN to do a needs analysis and the potential for review and recovery on either the buyer or seller increases the FUD factor in the market. Only for those attempting to circumvent policies constructed by the consensus of the community. > For a market to function efficiently, Fear, Uncertainty, and Doubt need to be assuaged, and this proposal does that. > I have tremendous fear and uncertainty about the effects of this proposal. I doubt that it will function as advertised. Indeed, I believe this proposal increases each of those things from my perspective. > I copied liberally, almost entirely, from the APNIC policy to allow needs-free transfers. The rationale which was most effective in that regions's deliberations may have been the concern that by imposing the needs requirement, transactions would be more likely to occur outside the system, leading to a decay in whois reliability. > That is the argument Geoff used which appears to have had sway in that region. Geoff has repeatedly made that argument in the ARIN and RIPE regions (and I'm not sure that he has not made it in LACNIC or AfriNIC as well). So far, it has not been found to be convincing outside of APNIC. > By structuring my proposal in this way, I am trying to get people to consider whether the original and laudable needs requirement should be maintained when keeping it could lead to whois degradation. This question has been asked and answered as part of the debate around 2008-2, its successor 2008-15 (IIRC) and the boards reconstruction of that into 2009-1. You are welcome to ask the question again, but, I'm not inclined to believe the answer has changed. > My argument is that proper stewardship recognizes the existence of a market which will fulfill the original stewarship role of ensuring efficient use, and we can direct our stewardship best to policies which help to ensure whois veracity. My argument is that the market alone is not a good steward and a regulated market is necessary to ensure the vital interests of the community. Owen From v6ops at globis.net Fri May 6 12:32:34 2011 From: v6ops at globis.net (Ray Hunter) Date: Fri, 06 May 2011 18:32:34 +0200 Subject: [arin-ppml] Draft proposal that needs some wordsmithing Message-ID: <4DC422A2.6030908@globis.net> > > From: "Mike Burns" > After exhaust a free market is the appropriate mechanism to ensure addresses > are allocated and used efficiently. > A claim completely unsupported by any credible evidence whatsoever. Repeating this like a mantra doesn't it make any more true IMHO. [and yes I think I have read all of the many posts exploring this issue] [And no, I am not against free markets per se.] > Prior to exhaust, without such a mechanism, I could have walked up and asked > for a /2. > You seem to ignore the fact for convenience that this is *almost exactly* what happened at the top level allocation split of the 2^32 globally unique IPv4 address space between US based entities versus the rest of the world. The US has approx a /2. The rest of the World (who came rather late to the party) have to make do with the rest of the 2^32 addresses. One address space does not exist without the other. We live on a global Internet. ARIN allocates addresses from a proper subset of the globally unique IPv4 space. ARIN members communicate with nodes located in other RIR regions. If you're going to claim that a free market is the best practice for handling the ARIN space upon exhaustion, then it would be completely illogical to conclude anything other than that this market would also have to be a global market covering all of the RIR regions and all of the IPv4 address space [because the 2^32 addresses of the globally unique IPv4 address space is a single contiguous global resource]. Especially as demand for address space in APNIC has consistently grown so much faster than in the US in the recent past. The real crunch with IPv4 address exhaustion is not going to hit US companies internally, or even communication between ARIN members: it's going to hit US companies and ARIN members who want to communicate with suppliers, customers etc. located in APNIC. It's no good you having 20 addresses if your communication partner doesn't have any. [20:1 is the current ratio of addresses per capita between the US and CN] You can't have your cake and eat it. regards, RayH From owen at delong.com Fri May 6 12:36:31 2011 From: owen at delong.com (Owen DeLong) Date: Fri, 6 May 2011 09:36:31 -0700 Subject: [arin-ppml] ARIN-prop-146 Clarify Justified Need for Transfers In-Reply-To: References: <4DBEF120.4080901@arin.net> <88F39B20-5C20-45F0-AD61-5FA1E7F84CE3@delong.com> <4DBF6727.1090303@matthew.at> <097AAC1C-1F68-4820-9274-3290ADEFA195@delong.com> <9501EA7E-FDAD-4DDA-B9E8-08C2811FF642@delong.com> <4DBF82F6.7050608@matthew.at> <20110503145144.N15967@mail.inlandnet.com> <4DC084E7.5000302@matthew.at> <4DC08664.4060905@matthew.at> <4791A59E-8864-483C-9BB0-03A6A5B8D50C@delong.com> <66466F57-4365-4ADB-94EB-E023F01B17CB@delong.com> <30D12BA8-9A6C-4E62-9A67-8B4FEA0EA8C1@matthew.at> <00af01cc0aa7$845a5330$8d0ef990$@net> <8695009A81378E48879980039EEDAD289D0E5BD9@MAIL1.polartel.local> <5542F2FC72CC4995A4205A4C1C844F5E@mike> <0492060B-A00F-4C1E-9722-90F6A00ABD94@arin.net> <7BDE0C6C-E500-413C-9D60-96552490D902@delong.com> Message-ID: <7CAF7871-8D0A-4236-9A69-431D8F109E57@delong.com> >> >>> If ARIN declines to allow justification-less transfers, would be >>> resource vendors will stay on the black market. I hear a lot of gouge >>> in C-squad circles about how acquisitions are being conducted just to >>> conduct illicit transfers of /17 - /20 allocations. The justifications >>> that are being used to hold on to resources seem really loose. I made >>> one fraud report last year and it was closed without action. I won't >>> criticize ARIN for that action; I merely wish to point out that the >>> black market and false resource justifications are alive and well. >>> >>> We can eliminate the IP black market by allowing justification-less transfers. >>> >> We could eliminate criminal murder by making murder legal, too. >> I'm just not sure what the advantage is. >> >> We could eliminate the crime of theft by simply making it legal >> to steal. Again, I'm not seeing an advantage. >> >> The argument that a black market can be eliminated by legitimizing >> a market without rules is just such a tautology. >> >> Owen >> >> >> > > Owen, > > I'm talking about deregulating a civil process, not legalizing crimes. > We could eliminate divorce if we simply banned marriage? We could eliminate product tort claims if we simply eliminated product liability laws? Does the difference between criminal and civil really matter in this discussion? > HE also provides IPv6 services to basically everyone in the world who > is currently using IPv6 in some capacity. As it stands, if you're > using IPv6 you almost have to be peered to HE. This is a massive > contrast to a company like Black Lotus that will be hard pressed to > ever fully utilize a /32. > When HE started on the IPv6 road, we thought a /32 was more than we could ever conceivably use, too. We had no expectation that IPv6 would lead us to where we are now. We're glad it has, but, that wasn't what we initially expected. That was my point. Until you get more fully deployed, you really don't know what your IPv6 world will look like. > On the carrier front, our current carriers are working out but none > have substantial experience in IPv6. Your employer is probably the > only company in the world that has really mastered IPv6 carrier sales. You are welcome to buy from us. ;-) There are a couple of others, but, I'm not here to promote HE, let alone our competition. > Even the major carriers we deal with now are having small issues here > and there, simply due to inexperience. That aside, we don't have a lot > of options. How many carriers do you know of that will sell 10G's with > unmetered ingress (for sinking DDoS) at a very low rate. From my > research, I can count them on one hand. That's probably true... I can think of one I know for sure that can do that for you on IPv6 and one I think is likely. If you look at where AS1734 is homed, you'll probably be able to identify both. Owen From owen at delong.com Fri May 6 12:37:42 2011 From: owen at delong.com (Owen DeLong) Date: Fri, 6 May 2011 09:37:42 -0700 Subject: [arin-ppml] ARIN-prop-146 Clarify Justified Need for Transfers In-Reply-To: <4DC42030.60806@matthew.at> References: <4DBEF120.4080901@arin.net> <097AAC1C-1F68-4820-9274-3290ADEFA195@delong.com> <9501EA7E-FDAD-4DDA-B9E8-08C2811FF642@delong.com> <4DBF82F6.7050608@matthew.at> <20110503145144.N15967@mail.inlandnet.com> <4DC084E7.5000302@matthew.at> <4DC08664.4060905@matthew.at> <4791A59E-8864-483C-9BB0-03A6A5B8D50C@delong.com> <66466F57-4365-4ADB-94EB-E023F01B17CB@delong.com> <30D12BA8-9A6C-4E62-9A67-8B4FEA0EA8C1@matthew.at> <00af01cc0aa7$845a5330$8d0ef990$@net> <8695009A81378E48879980039EEDAD289D0E5BD9@MAIL1.polartel.local> <5542F2FC72CC4995A4205A4C1C844F5E@mike> <0492060B-A00F-4C1E-9722-90F6A00ABD94@arin.net> <61AAC8E6-F419-4792-95DB-2D5CE485580D@delong.com> <4DC42030.6! 0806@matthew.at> Message-ID: <7B8C6B82-CFAA-4653-AE13-709755C6D0B6@delong.com> On May 6, 2011, at 9:22 AM, Matthew Kaufman wrote: > On 5/6/2011 8:56 AM, Owen DeLong wrote: >>> STLS is a step in the right direction and making this program less >>> restrictive is even better. Ideally, if I have a /20 now and decide I >>> need a /18 to satisfy all future need prior to completing a full >>> migration to IPv6, and I have the cash to do it, then it should be >>> allowed. >>> >> What if you need a /18, but, know that by purchasing the equivalent >> of a /6, you can cause significantly larger additional costs to your >> competitors, possibly even pricing some of them out of the market? >> >> You have the cash to do it, should this be allowed? > No, but this policy proposal doesn't allow it, so I'm still not clear on why you're using arguments like this in order to object to the policy proposal. > > Matthew Kaufman Because I keep responding to others who have conflated the larger free market/unrestricted transfer idea into this discussion. This type of abuse, however, is also a reason not to expand the justified need horizon. Owen From mike at nationwideinc.com Fri May 6 13:20:04 2011 From: mike at nationwideinc.com (Mike Burns) Date: Fri, 6 May 2011 13:20:04 -0400 Subject: [arin-ppml] Draft proposal that needs some wordsmithing References: <4DC422A2.6030908@globis.net> Message-ID: <28AA88B965034F1097AA0B6746409DEC@mike> Hi Ray, >> After exhaust a free market is the appropriate mechanism to ensure >> addresses >> are allocated and used efficiently. >> > A claim completely unsupported by any credible evidence whatsoever. > > Repeating this like a mantra doesn't it make any more true IMHO. > I'm sorry for repeating it without providing background. Why the market would work to bring addresses into productive use, is that people are motivated by personal self-interest. So a person (organization, entity) who had addresses which were dis- or under-used would be motivated by the money he could get by selling the addresses. The buyer of addresses would be establishing, through his willingness to part with money for them, that he thought he could profit by having them. If the buyer is putting these addresses to some use which is profitable to him, they will have moved from disuse to use through the operations, in a free market, of people motivated by their own self interest. These are the basic forces at action, and I think these would be the basic transactions of the ip address transfer market. Yes, a speculator or hoarder could purchase addresses and not put them to use, but he would only do that if he thought he could profit by selling them later, or profit in some other way. A speculator or hoarder (or any other buyer) could also lose money if he is unable to profit from his acquisition for whatever reason. > [and yes I think I have read all of the many posts exploring this issue] > > [And no, I am not against free markets per se.] >> Prior to exhaust, without such a mechanism, I could have walked up and >> asked >> for a /2. >> > You seem to ignore the fact for convenience that this is *almost exactly* > what happened at the top level allocation split of the 2^32 globally > unique IPv4 address space between US based entities versus the rest of the > world. The US has approx a /2. The rest of the World (who came rather late > to the party) have to make do with the rest of the 2^32 addresses. > > One address space does not exist without the other. We live on a global > Internet. ARIN allocates addresses from a proper subset of the globally > unique IPv4 space. ARIN members communicate with nodes located in other > RIR regions. > > If you're going to claim that a free market is the best practice for > handling the ARIN space upon exhaustion, then it would be completely > illogical to conclude anything other than that this market would also have > to be a global market covering all of the RIR regions and all of the IPv4 > address space [because the 2^32 addresses of the globally unique IPv4 > address space is a single contiguous global resource]. > > Especially as demand for address space in APNIC has consistently grown so > much faster than in the US in the recent past. > > The real crunch with IPv4 address exhaustion is not going to hit US > companies internally, or even communication between ARIN members: it's > going to hit US companies and ARIN members who want to communicate with > suppliers, customers etc. located in APNIC. It's no good you having 20 > addresses if your communication partner doesn't have any. [20:1 is the > current ratio of addresses per capita between the US and CN] > > You can't have your cake and eat it. > > > > regards, > RayH I understand that you feel the global address allocation is unfair, but I don't understand its context in this discussion about markets, except to say that I agree with you that the market should be global. I believe with the work at APNIC to remove needs requirements for transfers, coupled with the Global Policy Proposal to allow Inter-RIR transfer, are steps in this direction. Concerning APNIC, I think the probability of unregistered Inter-RIR transfer is one of the reasons why they placed whois integrity over the other negative concerns about the implications of markets, like disaggregation. They decided that they had better just register the transfers as they occur, because they are likely to occur, in order to server the greater good of making sure the whois actually documented reality. The stewards there made some basic decisions about regional demand, IPv6 transition, and perhaps historical global allocation inequities that led them to approve the elimination of needs-tested transfers. My argument is that retaining needs analysis to approve transfers is no longer required to ensure efficiency, and maintaining it can cause transactions to go off-books, to the detriment of all. Regards, Mike From info at arin.net Fri May 6 14:13:09 2011 From: info at arin.net (ARIN) Date: Fri, 06 May 2011 14:13:09 -0400 Subject: [arin-ppml] Advisory Council Meeting Results - April 2011 In-Reply-To: <4DAC8B62.9070005@arin.net> References: <4DAC8B62.9070005@arin.net> Message-ID: <4DC43A35.2020406@arin.net> The minutes of the April meeting of the ARIN Advisory Council are available at: https://www.arin.net/about_us/ac/index.html > The deadline to begin a petition will be five business days after the > AC's draft meeting minutes are published. The deadline for petitions is 13 May 2011. Regards, Communications and Member Services American Registry for Internet Numbers (ARIN) ARIN wrote: > In accordance with the ARIN Policy Development Process the ARIN Advisory > Council (AC) held a meeting on 13 April 2011 and made decisions about > several draft policies and proposals. > > The AC moved the following draft policies to last call (they will be > posted separately to last call): > > ARIN-2011-3: Better IPv6 Allocations for ISPs > ARIN-2011-4: Reserved Pool for Critical Infrastructure > ARIN-2011-5: Shared Transition Space for IPv4 Address Extension > ARIN-2011-6: Returned IPv4 Addresses > > The AC abandoned the following draft policy: > > ARIN-2011-2: Protecting Number Resources > > The AC postponed making a decision about the following draft policy > until the AC's next meeting: > > ARIN-2011-1: Globally Coordinated Transfer Policy > > The AC accepted the following proposal on to the AC's docket for > development and evaluation: > > ARIN-Prop-137: Global Policy for Post-Exhaustion IPv4 Allocation > Mechanisms by the IANA > > The AC abandoned the following proposal: > > ARIN-prop-138 IPv6 Size Category Alignment > > The AC stated, "The advisory council voted to abandon prop 138 IPv6 Size > Category Alignment because it was the majority opinion that this was a > pricing matter. We encourage the authors to start a discussion on > ARIN-discuss list and perhaps send a recommendation via the ARIN > Suggestion and Consultation process. Note that suggestion 2011.3 is > already in process and appears to meet most of the needs expressed in > this proposal." ACSP Suggestion 2011.3 is available at: > https://www.arin.net/participate/acsp/suggestions/2011-3.html > > The AC abandoned ARIN-2011-2 and ARIN-prop-138. Anyone dissatisfied with > these decisions may initiate a petition. The petition to advance > ARIN-2011-2 would be the "Last Call Petition." The petition to advance > prop-138 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 mike at nationwideinc.com Fri May 6 14:13:02 2011 From: mike at nationwideinc.com (Mike Burns) Date: Fri, 6 May 2011 14:13:02 -0400 Subject: [arin-ppml] Draft proposal that needs some wordsmithing References: <9638601B94304E4392112CF98CDE757C@mike><4DC31B41.3090001@umn.edu> <940FF59153304663A8094B5EEB172AD3@mike> <468BF725-3BA3-423F-A98E-3CC762344D63@delong.com> Message-ID: <5A3A69A575A04812BB8985D1CCCFADAD@mike> Hi Owen, >> Because prior to exhaust there was no other mechanism to ensure addresses >> were allocated and used efficiently. >If a market was the best mechanism, we could have adopted policy to auction >IPv4 addresses off to the highest bidders before exhaustion. Exhaustion >would >likely have come much earlier in such a case, but, it was possible, so, >your >assertion that no other mechanism existed is false. No other mechanism was >chosen, but, it did exist. I think arguments about who would have kept the auction money would have ended that option pretty swiftly. >> Prior to exhaust, without such a mechanism, I could have walked up and >> asked for a /2. >What prevents you from doing so post exhaustion in an unmoderated market if >you think >that purchasing all (or as much as you can) of the available address space >will have >a sufficient negative impact on your competitors as to be worth the >investment? Nothing prevents me from asking. In the prior case, I would have been turned down for lack of need. In the post-exhaust case, I would have been turned down for lack of money (or supply, obviously). I doubt that there will be a /2 for sale any time soon, but maybe in the End of Days for IPv4. (When the value approaches zero.) > The system that was devised and implemented was a needs analysis which > simply made allocations according to demonstrated need. > The ensured that at least at the start, addresses would not be frivolously > wasted. >It also ensured that address registrations did not become an artificially >valuable >commodity. Exhaustion will force this artificial valuation on such >registrations, but, >removing the justified need restriction from this forced market will not >help >the situation as it would still have the same effect of allowing waste. >Admittedly, >the degree of frivolity may be more a matter of perspective at that point, >but, >waste through capture for competitive advantage is still waste as far as I >am >concerned. Is it your contention that the current system has not allowed waste, or just that a private market will allow for more waste? > We know the needs requirement was not a perfect way to ensure > efficiencies. > We know that from the number or allocated and not advertised space, if > nothing else. >No, we do not. Allocated and not advertised DOES NOT mean underutilized. >There are many legitimate reasons IP resources may be unadvertised while >still >fully utilized (or more accurately, utilized but not visible in any routing >table to which >you particularly have access). I am of the opinion that there is a lot of waste in legacy space, and only slightly less waste in RSA space. Everyone here can make their own decision on that using their own experience to guide them. This is all space that has been allocated outside functioning market environments. > A market will not be perfect either, but unlike the prior needs analysis, > we seem to be judging the free market by the exceptions. > >Since the misdeeds (which you claim will be "exceptions") in the market >have the >potential to overwhelm the market, where no such risk existed in the needs >analysis, I think that is a legitimate approach. The stewards of APNIC decided otherwise, and your assertions, like mine, about the dangers of allowing free individuals voluntarily engaging in trade, are unsupported. > >> 2) Why would any organization with need for unique IPv4 addresses >> choose to not have those addresses recorded in the database which >> guarantees their value in order to escape stating their need? (i.e. >> What class of organization with legitimate need would be hurt by >> having to demonstrate that need before receiving addresses?) >> > > An aggregator buying unroutable bits to aggregate to a routable size?. >I see no reason this couldn't be done by an organization with need just as >effectively >as by some random aggregator intending to resell the result. What if his need is to buy snippets of space in order to aggregate it into sizes acceptable to the network operator community and then sell them? How would he describe that need to ARIN? > Somebody who has a different view on the IPv6 transition timeframe and has > a longer planning horizon for IPv4? >Then they come to the market multiple times. Each time involves a cost of waiting, an uncertainty cost of the addresses in the future which some companies may find unacceptable, supply uncertainty,as well as transactional and deaggregation costs. Is good stewardship to result in increased costs for consumers of ip address space? > A reseller of vanity addresses, like 100.100.100.100? >I see no reason to promote or create these. They offer no meaningful >benefit to the >community at large. Is it ARIN's role to decide this? Doesn't the history of the Internet suggest allowing volunteer private organizations to make these kinds of decisions? > A wholesaler of addresses who caters to those who need instant > availability (needs analysis takes time)? >My last needs analysis took less than 24 hours. The average of my last 5 >needs analysis is less than 36 hours. >That's real-time, not resource analyst or my hours. Microsoft got turned down recently from APNIC for a temporary allocation for some technical symposium in Australia. Why can't they look to a wholesaler for rapid, and maybe temporary deployment? Surely you can understand that transfers will likely increase in number, and ARIN's needs analyses could take longer? But no such wholesaler can exist if you require him to demonstrate need. Think of a Quik-E-Mart for IP addresses. Are you certain there would never be a call for that kind of convenience? What if there are supply problems on STLS? A wholesaler with inventory on hand is often a valuable resource in times like that, even though he is going to make a buck on the deal. > A speculator, who could have a positive role in free markets? >ROFL -- The concept of speculator in the same sentence with "positive role" >amuses me. Suggested reading for when you arise from the floor http://mises.org/daily/320 > An organization that does not want to undergo an ARIN analysis for fear it > will lead to a review and recovery procedure? >An organization which has reason to fear this is an organization which >probably shouldn't >be getting additional resources from the community. They would be buying them from the rights holder, not getting them from the community. > An organization from another region? >You say this as if it is somehow a benefit. I was asked by Chris why anybody would transfer addresses and fail to have them registered, and these were just examples. I don't think this is a benefit, but I support a global free market for IP addresses, so they can flow to wherever they are needed most, as measured by their price. In this way I feel I am extending the definition of community wider than the region of abode. > A buyer of a /24 who thinks an ARIN needs analysis isn't worth the > expense? >Again, not seeing the benefit to the community in providing this person the >opportunity to take >that /24 out of the hands of some more deserving organization with >documented need. You miss my point, they may have need, but for a small transaction, having to negotiate ARIN hurdles could be viewed as unworth the effort. Again this is in response to the request for examples of potential buyers who would not take the steps to register. > Microsoft? They didn't seem to want or need a needs analysis until ARIN > began negotiating with them after the original asset agreement with Nortel > had been negotiated. > >This, also, strikes me as an indication that removing needs basis would >have a negative impact >on the overall outcome. ARIN ran in and got the transfer reflected in whois through shenanigans with the needs justification, in my opinion. If there were no needs requirement, I think Microsoft would have asked ARIN to make the updates to whois as the normal course of business, but without knowing how accomodating ARIN would be on a needs analysis, they pointedly left ARIN agreements out of the first negotiated asset sale with Nortel. > I don't pretend to be able to able to identify all the types of > transactions for which an ARIN needs analysis seems an unnecessary > intrusion into a transaction between two private entities. > >What you call unnecessary, I call vital to the overall interests of the >community. It was vital when there was no other free and voluntary mechanism to ensure efficient use, but I am trying to show that the needs mechanism is now outdated and poses a problem for whois. > The point is that many prior transfers have taken place, particularly with > legacy space, that have not been reflected in whois. >Hopefully as these can be identified, the space can be revoked and >reallocated >to organizations that comply with policy. The original legacy holder has >some >protections. A third party as a result of an unauthorized transfer should >not have >any protections in this regard. Microsoft was the third party here. Addresses were transferred to Nortel from their acquisitions, the original legacy holders here. By your definitions, since ARIN was not involved, these transfers were unauthorized. And yet a bankruptcy judge saw no problems with Microsoft buying them from Nortel. I haven't stressed this, but the legal facts as I see them are that legacy holdings can be transferred without ARIN notice or needs requirements. By removing needs requirements for transfers, we bring policy in line with developing law, and this is sure to reduce future conflict. > One of the problems relates to the requirement for a needs analysis. >No, the problem is the belief that community resources can be transferred >outside >of community policy. For legacy addresses, these transfers have occurred in reality, it's time for belief to catch up. > If a holder of legacy space acquired through an asset sale approached ARIN > to reflect that transfer, ARIN would not update whois without a needs > analysis. >As it should be. You are arrogating needs requirements over whois accuracy by taking that stance. > In addition, the requirement for ARIN to do a needs analysis and the > potential for review and recovery on either the buyer or seller increases > the FUD factor in the market. >Only for those attempting to circumvent policies constructed by the >consensus of the community. If I want to buy and the seller want to sell, and we have reached an agreement on price, then having to undergo an audit before we can process the sale, or being subject to one thereafter, is most certainly an added uncertainty. > For a market to function efficiently, Fear, Uncertainty, and Doubt need to > be assuaged, and this proposal does that. > >I have tremendous fear and uncertainty about the effects of this proposal. >I doubt that it will function as >advertised. Indeed, I believe this proposal increases each of those things >from my perspective. So you see how FUD works to prevent action. > I copied liberally, almost entirely, from the APNIC policy to allow > needs-free transfers. The rationale which was most effective in that > regions's deliberations may have been the concern that by imposing the > needs requirement, transactions would be more likely to occur outside the > system, leading to a decay in whois reliability. > >That is the argument Geoff used which appears to have had sway in that >region. >Geoff has repeatedly made that argument in the ARIN and RIPE regions (and >I'm not sure >that he has not made it in LACNIC or AfriNIC as well). So far, it has not >been found to be >convincing outside of APNIC. > By structuring my proposal in this way, I am trying to get people to > consider whether the original and laudable needs requirement should be > maintained when keeping it could lead to whois degradation. >This question has been asked and answered as part of the debate around >2008-2, its successor >2008-15 (IIRC) and the boards reconstruction of that into 2009-1. You are >welcome to ask the >question again, but, I'm not inclined to believe the answer has changed. Things have changed since then in terms of continued failure to transition and the MS/Nortel deal, and APNIC reaching exhaustion and approving their new transfer policy. > My argument is that proper stewardship recognizes the existence of a > market which will fulfill the original stewarship role of ensuring > efficient use, and we can direct our stewardship best to policies which > help to ensure whois veracity. >My argument is that the market alone is not a good steward and a regulated >market is necessary >to ensure the vital interests of the community. And I counter that the vital interest in address-use-efficiencies are better offloaded to the market, and the vital interest in maintaining whois veracity is retained. Regards, Mike From springer at inlandnet.com Fri May 6 14:20:53 2011 From: springer at inlandnet.com (John Springer) Date: Fri, 6 May 2011 11:20:53 -0700 (PDT) Subject: [arin-ppml] Serious question for the list. In-Reply-To: <723D48A257C34BA0BD60F16130F4844F@mike> References: <723D48A257C34BA0BD60F16130F4844F@mike> Message-ID: <20110506102523.O57144@mail.inlandnet.com> Hi Mike, First of all, please let me thank you for bring up a most interesting topic. I have read the thread through Owen's post of 5 May 2011 17:04:02, but I want to respond to the original post, if I may, which I will do inline. On Thu, 5 May 2011, Mike Burns wrote: > Hi all, > > I have had an idea. > > Since it has been determined that everybody in the ARIN community with an email address may participate in policy development, how does the list feel about soliciting the input from a broader group of participants? ARIN has spent quite some effort on outreach regarding IPV6 adoption. To the extent that anyone wishes to pick up that banner and assist in getting "the word" out to groups that have not received attention before, Outstanding! However, I have the uneasy feeling that that is not exactly what you are talking about here. > Suppose I posted to a site like Reason magazine, which is Libertarian, inviting people to join the ARIN ppml in order to support my proposal to end needs requirements for IPv4 transfers? This sounds like astroturfing to me. http://en.wikipedia.org/wiki/Astroturfing from the wiki: "Astroturfing is a form of propaganda whose techniques usually consist of a few people attempting to give the impression that mass numbers of enthusiasts advocate some specific cause." It looks like some self regulating professional groups have and attempt to enforce policies against this type of behavior. OTOH, what would be the harm? Anyone with a pulse on the planet is invited to participate in the PDP. Having followed the larger contexts of proposals and petitions that this question seems to be posed to counter, it looks like the only effect, might be to enable easy override of proposal abandonment through assured petition passage. Masses of "me too" PPML posts, remote comments at meetings and at the mike comments, unsupported by clue would seem to be obvious. And the AC seems well armed to deal with that. Since what appears to be going on lately is a kind of value orthogonality (free markets good everywhere, free markets not good here), I'm not sure a million +1s is going to have the right kind of weight to force a policy past the AC and board in the face of widespread articulate reasoning. We might want to guard against lots of input from say, robocallers: http://en.wikipedia.org/wiki/Robocalling or the dead: http://en.wikipedia.org/wiki/Ballot_stuffing > And those who oppose could post to HuffPo or some other site where opposing views might be expected to be courted. I don't find this idea attractive myself. If I have something to say about ARIN (rare, I know), I think I will do it here on PPML or at a meeting. I note that a number of public advocacy industry groups have policies against astroturfing and one that while it "does not specifically mention astroturfing, it does require honest communication." Perhaps ARIN might wish to formally eschew this behavior itself, while allowing it for others. > Is this a horrible idea? No. The idea itself seems unbaked. It is certainly possible and may even be acceptable. > I have not acted on it, there could be large implications. Could indeed. In a quick search I find no particular policy or PPML AUP that addresses this proposed behavior, although the following might pertain: # Postings by fictional or non-identifiable names and addresses. # Posting false or fictitious statements. # Actions, that while not described specifically here, are similar to the conduct described. AC, staff, Board or list, where would the appropriate place to address this be? Policy proposal, ACSP, AUP edit? Or someone more lofty than me just telling Mike to go for it? :) > What are your thoughts? Thanks again for a thought provoking question. John Springer > Regards, > > Mike Burns > > From mike at nationwideinc.com Fri May 6 14:21:12 2011 From: mike at nationwideinc.com (Mike Burns) Date: Fri, 6 May 2011 14:21:12 -0400 Subject: [arin-ppml] Draft proposal that needs some wordsmithing References: <4DC422A2.6030908@globis.net><28AA88B965034F1097AA0B6746409DEC@mike> Message-ID: <7976AD6A784F4472A0A89BA146446A50@mike> > > While a market does bring the benefit of an address holder becoming > more efficient in their use of addresses due to potential gains for > freeing space, I do not see where the removal of needs justification > further enhances this market. Even with our current policies in-place, > including justification, a market is developing that will meet this > enhanced efficiency. > Hi Andy, I have given some examples in other threads about potential buyers who could not meet ARIN's needs requirements. > > > > >> My argument is that retaining needs analysis to approve transfers is no >> longer required to ensure efficiency, and maintaining it can cause >> transactions to go off-books, to the detriment of all. > > True, needs justification is no longer necessary to improve > efficiency. However, it does prevent price inflation due to > speculation and hoarding. As such, I do not support removing needs > justification from policy. > > Andrew Koch > andrew.koch at gmail.com I believe, as I said to Owen, that you are arrogating the fear of hoarding and speculation over the stewardship value of maintaining whois accuracy. Whereas there are no examples of IP address hoarders or speculators, there is plenty of evidence that whois suffers when real legal transactions happen outside ARIN's purview. Regards, Mike From scottleibrand at gmail.com Fri May 6 14:33:37 2011 From: scottleibrand at gmail.com (Scott Leibrand) Date: Fri, 6 May 2011 11:33:37 -0700 Subject: [arin-ppml] Draft proposal that needs some wordsmithing In-Reply-To: <9638601B94304E4392112CF98CDE757C@mike> References: <9638601B94304E4392112CF98CDE757C@mike> Message-ID: Mike, Another approach to accomplish what you're trying to do here might be to see what minimal modifications you can make to the existing NRPM to do the same thing. For example: In 8.3: Such transferred number resources may only be received under RSA by organizations that are within the ARIN region. (Strike "and can demonstrate the need for such resources, as a single aggregate, in the exact amount which they can justify under current ARIN policies".) In 12.4: (Add "or transfer"): Organizations found by ARIN to be materially out of compliance with current ARIN policy shall be requested or required to return or transfer resources as needed to bring them into (or reasonably close to) compliance. Some of the other conditions might be good to keep (and add to section 8.3) as well, as they're not directly covered by existing language in the NRPM: > - The source entity will be ineligible to receive any further IPv4 > address allocations or assignments from ARIN for a period of 12 > months after the transfer, or until the exhaustion of ARIN's > IPv4 space, whichever occurs first. > - The recipient entity of the transferred resources will be subject > to current ARIN policies. In particular, in any subsequent ARIN > IPv4 address allocation request, the recipient will be required > to account for the efficient utilization of all IPv4 address > space held, including all transferred resources. Hope that helps, Scott On Thu, May 5, 2011 at 1:43 PM, Mike Burns wrote: > Hi list, > > I tried to put together a proposal to end needs requirements for transfers > and I used the APNIC policy as a framework. > The problem is that as the proposal is structured below, there is a problem > with the application of ARIN Resource Review policies in section 12. > Even if the transfer happens without regard to need, since the transferred > resources would be received by an ARIN account holder and would be subject > to ARIN's policies, then ARIN could feasibly do a resource review > immediately post transfer to effectively retain a needs requirement. > > My intent is that ARIN resource reviews continue to happen for purposes > other than need. > So for fraud, for hijackings, for failure to pay ARIN's bills, I support > resource review and recovery. > But not for need. > I was hoping not to have to mess with section 12 of the NRPM. Can somebody > suggest a way to modify my draft proposal to effect my intent in a graceful > manner which doesn't require modifications to section 12? > > Thanks for any help you can offer on this matter or any other issues related > to this draft. > > Regards, > > Mike > > > > 1. Policy Proposal Name: New IPv4 Transfer policy > > 2. Proposal Originator: > a. Name: Mike Burns > b. Email: mike at sum.net > c. Phone: 1-863-494-7692 x105 > d. Organization: Nationwide Computer Systems > > 3. Proposal Version: 1 > > 4. Date: May 5th, 2011 > > 5. Proposal type: modify > > 6. Policy term: permanent > > 7. Policy statement: > > Replace Section 8 with > > 8.ARIN will process and record IPv4 address transfer requests. > Conditions on the IPv4 address block: > > - The minimum transfer size is a /24 > > - The address block must be in the range of addresses administered > by ARIN > > Conditions on source of the transfer: > > - The source entity must be the current rights 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 the transfer, or until the exhaustion of ARIN's > IPv4 space, whichever occurs first. > > Conditions on recipient of the transfer: > > - The recipient entity must be a current ARIN account holder. > > - The recipient entity of the transferred resources will be subject > to current ARIN policies. In particular, in any subsequent ARIN > IPv4 address allocation request, the recipient will be required > to account for the efficient utilization of all IPv4 address > space held, including all transferred resources. > > 8. Rationale: > Current ARIN policies relating to the registration of transfer of > address holdings limit the eligibility of registration of transfers to > those relating to mergers and acquisitions of entities that are > administering an operational network, or to those who agree to > sign either an RSA or LRSA with ARIN and subject the buyer > to needs analysis and the seller to a potential ARIN audit. > > It is currently anticipated that the IPv4 unallocated address pool > will be exhausted within a couple of years at ARIN, and earlier > than that in other regions, and the transition to IPv6-based service > delivery > is likely to take longer than the remaining period of unallocated > address availability. Accordingly, it is likely that demand for IPv4 > addresses will continue beyond the time of unallocated address pool > exhaustion, leading to a period of movement of IPv4 address blocks > between address holders to meet such continuing demand for IPv4 > address blocks. > > The underlying proposition behind this policy proposal is that the > registry of IPv4 addresses operated by ARIN is of general utility and > value only while it accurately describes the current state of address > distribution. If a class of address movement transactions are excluded > from being entered in the registry, then the registry will have > decreasing value to the broader community, and the integrity of the > network itself is thereby compromised. This proposal's central aim is > to ensure the continuing utility and value of the ARIN address > registry by allowing the registry to record transactions where IPv4 > addresses are transfered between ARIN account holders. > > It proposes that ARIN will recognise and register a transfer of > addresses where the parties to the transfer are 'known' to ARIN and > that the address block being transferred is part of ARIN's current address > set. > > The proposal does not prescribe how such transfers may occur, nor > impose any further constraints on the transfer or on the parties > involved other than those described in this proposal. > > 9. 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 mike at nationwideinc.com Fri May 6 14:38:33 2011 From: mike at nationwideinc.com (Mike Burns) Date: Fri, 6 May 2011 14:38:33 -0400 Subject: [arin-ppml] Serious question for the list. References: <723D48A257C34BA0BD60F16130F4844F@mike> <20110506102523.O57144@mail.inlandnet.com> Message-ID: Hi John, Thanks for your thoughtful reply and those that came from others on this issue. Although I think we all see that some of these decisions are made not on technical, but on philosophical or economic grounds. I think there is an obvious danger in determining policy for billions based on the participation of tens. Upon further baking of my idea, (Unbaked you called it. Don't I get credit at least for half-baking?) I decided not to act on it, but I remain in two minds about the question. I consider it a topic for further discussion if anybody is interested, and if the debate here grows increasingly non-technical-but-partisan, then maybe it can be re-examined. Regards, Mike ----- Original Message ----- From: "John Springer" To: "Mike Burns" Cc: Sent: Friday, May 06, 2011 2:20 PM Subject: Re: [arin-ppml] Serious question for the list. > Hi Mike, > > First of all, please let me thank you for bring up a most interesting > topic. I have read the thread through Owen's post of 5 May 2011 17:04:02, > but I want to respond to the original post, if I may, which I will do > inline. > > On Thu, 5 May 2011, Mike Burns wrote: > >> Hi all, >> >> I have had an idea. >> >> Since it has been determined that everybody in the ARIN community with an >> email address may participate in policy development, how does the list >> feel about soliciting the input from a broader group of participants? > > ARIN has spent quite some effort on outreach regarding IPV6 adoption. To > the extent that anyone wishes to pick up that banner and assist in getting > "the word" out to groups that have not received attention before, > Outstanding! However, I have the uneasy feeling that that is not exactly > what you are talking about here. > >> Suppose I posted to a site like Reason magazine, which is Libertarian, >> inviting people to join the ARIN ppml in order to support my proposal to >> end needs requirements for IPv4 transfers? > > This sounds like astroturfing to me. > http://en.wikipedia.org/wiki/Astroturfing > from the wiki: "Astroturfing is a form of propaganda whose techniques > usually consist of a few people attempting to give the impression that > mass numbers of enthusiasts advocate some specific cause." > > It looks like some self regulating professional groups have and attempt to > enforce policies against this type of behavior. OTOH, what would be the > harm? Anyone with a pulse on the planet is invited to participate in the > PDP. Having followed the larger contexts of proposals and petitions that > this question seems to be posed to counter, it looks like the only effect, > might be to enable easy override of proposal abandonment through assured > petition passage. Masses of "me too" PPML posts, remote comments at > meetings and at the mike comments, unsupported by clue would seem to be > obvious. And the AC seems well armed to deal with that. Since what appears > to be going on lately is a kind of value orthogonality (free markets good > everywhere, free markets not good here), I'm not sure a million +1s is > going to have the right kind of weight to force a policy past the AC and > board in the face of widespread articulate reasoning. We might want to > guard against lots of input from say, robocallers: > http://en.wikipedia.org/wiki/Robocalling or the dead: > http://en.wikipedia.org/wiki/Ballot_stuffing > >> And those who oppose could post to HuffPo or some other site where >> opposing views might be expected to be courted. > > I don't find this idea attractive myself. If I have something to say about > ARIN (rare, I know), I think I will do it here on PPML or at a meeting. I > note that a number of public advocacy industry groups have policies > against astroturfing and one that while it "does not specifically mention > astroturfing, it does require honest communication." Perhaps ARIN might > wish to formally eschew this behavior itself, while allowing it for > others. > >> Is this a horrible idea? > > No. The idea itself seems unbaked. It is certainly possible and may even > be acceptable. > >> I have not acted on it, there could be large implications. > > Could indeed. In a quick search I find no particular policy or PPML AUP > that addresses this proposed behavior, although the following might > pertain: > # Postings by fictional or non-identifiable names and addresses. > # Posting false or fictitious statements. > # Actions, that while not described specifically here, are similar to the > conduct described. > > AC, staff, Board or list, where would the appropriate place to address > this be? Policy proposal, ACSP, AUP edit? Or someone more lofty than me > just telling Mike to go for it? :) > >> What are your thoughts? > > Thanks again for a thought provoking question. > > John Springer > >> Regards, >> >> Mike Burns >> >> From v6ops at globis.net Fri May 6 15:09:08 2011 From: v6ops at globis.net (Ray Hunter) Date: Fri, 06 May 2011 21:09:08 +0200 Subject: [arin-ppml] Draft proposal that needs some wordsmithing In-Reply-To: <28AA88B965034F1097AA0B6746409DEC@mike> References: <4DC422A2.6030908@globis.net> <28AA88B965034F1097AA0B6746409DEC@mike> Message-ID: <4DC44754.7070302@globis.net> Mike Burns wrote: > > I understand that you feel the global address allocation is unfair, > > Regards, > Mike It's not just that I think it's unfair: I think this is very likely going to harm US corporations and ARIN members. If your potential customers in APNIC haven't got any IPv4 address, they're likely to migrate to IPv6. If US corporations have not gone dual stack IPv6 on their external web sites, and instead are obtaining and hoarding IPv4 addresses within the ARIN region to make IPv4 "last forever," they're not going to be able to advertise or sell or download any products to those potential customers in APNIC. Communication takes two parties. Attempting to keep all the IPv4 addresses in the US is not going to help international communication, which is an essential precursor to international trade. This should also be naked self interest and free market thinking by the US corporations (and anyone else who wants to reduce the trade deficit via International trade) As I said, no need to put me in the anti-free-market camp. From warren at wholesaleinternet.com Fri May 6 15:17:11 2011 From: warren at wholesaleinternet.com (Warren Johnson) Date: Fri, 6 May 2011 14:17:11 -0500 Subject: [arin-ppml] ARIN-prop-146 Clarify Justified Need for Transfers In-Reply-To: <7BDE0C6C-E500-413C-9D60-96552490D902@delong.com> References: <4DBEF120.4080901@arin.net> <88F39B20-5C20-45F0-AD61-5FA1E7F84CE3@delong.com> <4DBF6727.1090303@matthew.at> <097AAC1C-1F68-4820-9274-3290ADEFA195@delong.com> <9501EA7E-FDAD-4DDA-B9E8-08C2811FF642@delong.com> <4DBF82F6.7050608@matthew.at> <20110503145144.N15967@mail.inlandnet.com> <4DC084E7.5000302@matthew.at> <4DC08664.4060905@matthew.at> <4791A59E-8864-483C-9BB0-03A6A5B8D50C@delong.com> <66466F57-4365-4ADB-94EB-E023F01B17CB@delong.com> <30D12BA8-9A6C-4E62-9A67-8B4FEA0EA8C1@matthew.at> <00af01cc0aa7$845a5330$8d0ef990$@net> <8695009A81378E48879980039EEDAD289D0E5BD9@MAIL1.polartel.local> <5542F2FC72CC4995A4205A4C1C844F5E@mike> <0492060B-A00F-4C1E-9722-90F6A00ABD94@arin.net> <7BDE0C6C-E500-413C-9D60-96552490D902@delong.com> Message-ID: <0a9a01cc0c22$34149fd0$9c3ddf70$@com> You're not comparing apples to apples. You can hardly compare legalizing murder to legalizing the sales of address resources. Perhaps a more realistic comparison would be legalizing marijuana and cocaine to stem the drug war related violence we see in Mexico. Loosening transfer rules serves to help ensure transfers go through the RIR and are properly cataloged. More stringent transfer rules help to promote alternative approaches to acquiring IP resources that don't necessarily get cataloged. You would be surprised how creative people get when the resource is scarce and they need it (or the resource is scarce and they want to monetize it). This decreases the accuracy of the WHOIS database; not something we want. P.S. Finally, you got to use the word tautology in a sentence! ;-) > We can eliminate the IP black market by allowing justification-less transfers. > We could eliminate criminal murder by making murder legal, too. I'm just not sure what the advantage is. We could eliminate the crime of theft by simply making it legal to steal. Again, I'm not seeing an advantage. The argument that a black market can be eliminated by legitimizing a market without rules is just such a tautology. 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. -------------- next part -------------- A non-text attachment was scrubbed... Name: winmail.dat Type: application/ms-tnef Size: 2910 bytes Desc: not available URL: From mike at nationwideinc.com Fri May 6 15:26:16 2011 From: mike at nationwideinc.com (Mike Burns) Date: Fri, 6 May 2011 15:26:16 -0400 Subject: [arin-ppml] Draft proposal that needs some wordsmithing References: <4DC422A2.6030908@globis.net> <28AA88B965034F1097AA0B6746409DEC@mike> <4DC44754.7070302@globis.net> Message-ID: Hi Ray, > > If your potential customers in APNIC haven't got any IPv4 address, they're > likely to migrate to IPv6. > Or likely to try to buy some wherever they can and use them without registration if they have to. > If US corporations have not gone dual stack IPv6 on their external web > sites, and instead are obtaining and hoarding IPv4 addresses within the > ARIN region to make IPv4 "last forever," they're not going to be able to > advertise or sell or download any products to those potential customers in > APNIC. Correct, and this would incentivize them to add IPv6 capabilities to reach unreachable customers. > > Communication takes two parties. Attempting to keep all the IPv4 addresses > in the US is not going to help international communication, which is an > essential precursor to international trade. > I agree, and I hope nothing I have done is construed as an attempt to keep all the IPv4 addresses in the US. I'm on record here as supporting a global free market. > This should also be naked self interest and free market thinking by the US > corporations (and anyone else who wants to reduce the trade deficit via > International trade) > > As I said, no need to put me in the anti-free-market camp. I agree that self-interest should be expected of every party when developing policy. Regards, Mike From matthew at matthew.at Fri May 6 15:55:52 2011 From: matthew at matthew.at (Matthew Kaufman) Date: Fri, 06 May 2011 12:55:52 -0700 Subject: [arin-ppml] ARIN-prop-146 Clarify Justified Need for Transfers In-Reply-To: <0a9a01cc0c22$34149fd0$9c3ddf70$@com> References: <4DBEF120.4080901@arin.net> <88F39B20-5C20-45F0-AD61-5FA1E7F84CE3@delong.com> <4DBF6727.1090303@matthew.at> <097AAC1C-1F68-4820-9274-3290ADEFA195@delong.com> <9501EA7E-FDAD-4DDA-B9E8-08C2811FF642@delong.com> <4DBF82F6.7050608@matthew.at> <20110503145144.N15967@mail.inlandnet.com> <4DC084E7.5000302@matthew.at> <4DC08664.4060905@matthew.at> <4791A59E-8864-483C-9BB0-03A6A5B8D50C@delong.com> <66466F57-4365-4ADB-94EB-E023F01B17CB@delong.com> <30D12BA8-9A6C-4E62-9A67-8B4FEA0EA8C1@matthew.at> <00af01cc0aa7$845a5330$8d0ef990$@net> <8695009A81378E48879980039EEDAD289D0E5BD9@MAIL1.polartel.local> <5542F2FC72CC4995A4205A4C1C844F5E@mike> <0492060B-A00F-4C1E-9722-90F6A00ABD94@arin.net> <7BDE0C6C-E500-413C-9D60-96552490D902@delong.com> <0a9a01cc0c22$34149fd0$9c3ddf70$@co m> Message-ID: <4DC45248.902@matthew.at> On 5/6/2011 12:17 PM, Warren Johnson wrote: > You're not comparing apples to apples. You can hardly compare legalizing > murder to legalizing the sales of address resources. Perhaps a more > realistic comparison would be legalizing marijuana and cocaine to stem the > drug war related violence we see in Mexico. An even better comparison is that legalizing marijuana sales allows the sellers to file accurate sales and income tax returns. Matthew Kaufman From owen at delong.com Fri May 6 15:57:59 2011 From: owen at delong.com (Owen DeLong) Date: Fri, 6 May 2011 12:57:59 -0700 Subject: [arin-ppml] Draft proposal that needs some wordsmithing In-Reply-To: <5A3A69A575A04812BB8985D1CCCFADAD@mike> References: <9638601B94304E4392112CF98CDE757C@mike><4DC31B41.3090001@umn.edu> <940FF59153304663A8094B5EEB172AD3@mike> <468BF725-3BA3-423F-A98E-3CC762344D63@delong.com> <5A3A69A575A04812BB8985D1CCCFADAD@mike> Message-ID: On May 6, 2011, at 11:13 AM, Mike Burns wrote: > Hi Owen, >>> Because prior to exhaust there was no other mechanism to ensure addresses were allocated and used efficiently. > >> If a market was the best mechanism, we could have adopted policy to auction >> IPv4 addresses off to the highest bidders before exhaustion. Exhaustion would >> likely have come much earlier in such a case, but, it was possible, so, your >> assertion that no other mechanism existed is false. No other mechanism was >> chosen, but, it did exist. > > I think arguments about who would have kept the auction money would have ended that option pretty swiftly. > > >>> Prior to exhaust, without such a mechanism, I could have walked up and asked for a /2. > >> What prevents you from doing so post exhaustion in an unmoderated market if you think >> that purchasing all (or as much as you can) of the available address space will have >> a sufficient negative impact on your competitors as to be worth the investment? > > Nothing prevents me from asking. In the prior case, I would have been turned down for lack of need. > In the post-exhaust case, I would have been turned down for lack of money (or supply, obviously). > I doubt that there will be a /2 for sale any time soon, but maybe in the End of Days for IPv4. > (When the value approaches zero.) > Sure, a /2 is a ludicrous example in both cases. (ARIN never had a /2 to give you in the pre-exhaustion world, either). However, at /6, /8, or even /12, this still remains meaningful and gets progressively more realistic as a way to engage in anti-competitive behavior. >> The system that was devised and implemented was a needs analysis which simply made allocations according to demonstrated need. >> The ensured that at least at the start, addresses would not be frivolously wasted. > >> It also ensured that address registrations did not become an artificially valuable >> commodity. Exhaustion will force this artificial valuation on such registrations, but, >> removing the justified need restriction from this forced market will not help >> the situation as it would still have the same effect of allowing waste. Admittedly, >> the degree of frivolity may be more a matter of perspective at that point, but, >> waste through capture for competitive advantage is still waste as far as I am >> concerned. > > Is it your contention that the current system has not allowed waste, or just that a private market will allow for more waste? > It is my contention that the definition of waste is often in the eye of the beholder, but, if you define waste as addresses which are not assigned to machines or assigned to machines without a purpose considered useful by at least some person and related to the address being used to provide or consume a service over the network, then, it is my argument that the amount of waste allowed by a market with justified need would be less than that allowed by an unrestricted market. > >> We know the needs requirement was not a perfect way to ensure efficiencies. >> We know that from the number or allocated and not advertised space, if nothing else. > >> No, we do not. Allocated and not advertised DOES NOT mean underutilized. >> There are many legitimate reasons IP resources may be unadvertised while still >> fully utilized (or more accurately, utilized but not visible in any routing table to which >> you particularly have access). > > I am of the opinion that there is a lot of waste in legacy space, and only slightly less waste in RSA space. > Everyone here can make their own decision on that using their own experience to guide them. > This is all space that has been allocated outside functioning market environments. > I have no reason to believe that a market without justified need requirements would somehow magically reduce waste vs. a market with the requirement that recipients have justified need for their resources. After all, any recipient with justified need for the resources they are receiving is non-waste almost by definition, where this remains largely undefined for a market with no such requirement. An unrestricted market depends on the price of the address to reduce waste. However, unless you consider that tying addresses up to keep them from benefiting your competitors is not waste (I believe it is waste), there is no reason to believe that such an unrestricted market would not create exactly that type of transaction. >> A market will not be perfect either, but unlike the prior needs analysis, we seem to be judging the free market by the exceptions. >> >> Since the misdeeds (which you claim will be "exceptions") in the market have the >> potential to overwhelm the market, where no such risk existed in the needs >> analysis, I think that is a legitimate approach. > > The stewards of APNIC decided otherwise, and your assertions, like mine, about the dangers of allowing free individuals voluntarily engaging in trade, are unsupported. > The APNIC community decided that abandoning needs basis might serve their community better. The other four RIRs have elected to preserve needs basis. My statements about the dangers of allowing unrestricted trade are well documented in other markets where they have occurred. Can you point to examples of completely unregulated markets where such misdeeds have not occurred over any substantial period of time? > >> >>> 2) Why would any organization with need for unique IPv4 addresses >>> choose to not have those addresses recorded in the database which >>> guarantees their value in order to escape stating their need? (i.e. >>> What class of organization with legitimate need would be hurt by >>> having to demonstrate that need before receiving addresses?) >>> >> >> An aggregator buying unroutable bits to aggregate to a routable size?. > >> I see no reason this couldn't be done by an organization with need just as effectively >> as by some random aggregator intending to resell the result. > > What if his need is to buy snippets of space in order to aggregate it into sizes acceptable to the network operator community and then sell them? > How would he describe that need to ARIN? > That isn't a need supported by policy. If he needs an aggregate acceptable to the operator community for his own use, OTOH, I think he could easily justify those multiple purchases to ARIN under current interpretation of 8.3. I don't see where the reseller provides any benefit to the community over the end organization being the one to do the aggregation. >> Somebody who has a different view on the IPv6 transition timeframe and has a longer planning horizon for IPv4? > >> Then they come to the market multiple times. > > Each time involves a cost of waiting, an uncertainty cost of the addresses in the future which some companies may find unacceptable, supply uncertainty,as well as transactional and deaggregation costs. > Is good stewardship to result in increased costs for consumers of ip address space? > Yes... The future of IPv4 is uncertain and will get progressively more uncertain as time progresses. This is the reality of betting your business on continued availability of IPv4. Providing greater or longer durations of certainty to some organizations at the cost of denying it to others is contrary to good stewardship. Good stewardship is keeping the cost playing field relatively level for all players over time. At least to the greatest extent possible. >> A reseller of vanity addresses, like 100.100.100.100? > >> I see no reason to promote or create these. They offer no meaningful benefit to the >> community at large. > > Is it ARIN's role to decide this? Doesn't the history of the Internet suggest allowing volunteer private organizations to make these kinds of decisions? > It is the community's role to decide this. As a member of the community, I have offered my opinion. Others may offer theirs. At the end of the day, ARIN policy should reflect the collective judgment of the community. There is no history of volunteer private organizations making these decisions with respect to number resources on the internet and in places where number resources have been allowed to be managed in such a way, careful regulation has been required in each case to avoid substantial problems that have occurred in its absence. It is a complexity which I do not think we should take on, give its limited value to the community as a whole. >> A wholesaler of addresses who caters to those who need instant availability (needs analysis takes time)? > >> My last needs analysis took less than 24 hours. The average of my last 5 needs analysis is less than 36 hours. >> That's real-time, not resource analyst or my hours. > > Microsoft got turned down recently from APNIC for a temporary allocation for some technical symposium in Australia. So? > Why can't they look to a wholesaler for rapid, and maybe temporary deployment? In the APNIC region, under their policies, presumably they can. In the ARIN region, they cannot because policy prohibits such wholesalers. What policy does, however, allow, is "matchmakers" who could serve the same purpose without possessing the address registrations in the interim. I believe the STLS term for them is "Facilitators". Given the ability to have facilitators, what need is there for wholesalers? > Surely you can understand that transfers will likely increase in number, and ARIN's needs analyses could take longer? I don't think that transfers will increase beyond current allocation/assignment request rates (modulo normal growth) unless the market is becoming excessively liquid which would indicate that we have some level of failure in policy. > But no such wholesaler can exist if you require him to demonstrate need. Nor is he needed or useful in my opinion. > Think of a Quik-E-Mart for IP addresses. Are you certain there would never be a call for that kind of convenience? The visual of purchasing a Big-Gulp full of IP addresses at the local 7-11 is just too much for me to take seriously. > What if there are supply problems on STLS? A wholesaler with inventory on hand is often a valuable resource in times like that, even though he is going to make a buck on the deal. > How is a wholesaler with inventory different from a facilitator as defined in STLS in any meaningful way? The facilitator can still make a buck on the deal. If there's a supply problem, it's because there isn't a supply, not because policy prevented people from providing supply. >> A speculator, who could have a positive role in free markets? > >> ROFL -- The concept of speculator in the same sentence with "positive role" amuses me. > > Suggested reading for when you arise from the floor > http://mises.org/daily/320 > After a long winded explanation of how he can cloud the definition of speculation to mean virtually any form of investing, he finally gets to the point of claiming that there is a benefit to the market if: 1. Prices adjust quickly -- In the case of speculators this almost always means "increase" 2. There is greater liquidity -- Though he makes no mention of how, exactly, speculation actually increases liquidity 3. The market fluctuations are minimized -- Which is interesting to attribute to speculators after attempting to attribute case 1 to them as well. In my observations of various markets, speculators have had a destabilizing influence with a general tendency to increase prices, often far above and beyond rational levels. Yes, the speculators at the end of that process when the bubble bursts usually get hurt badly, then, we the taxpayers get to pay to bail them out, too. >> An organization that does not want to undergo an ARIN analysis for fear it will lead to a review and recovery procedure? > >> An organization which has reason to fear this is an organization which probably shouldn't >> be getting additional resources from the community. > > They would be buying them from the rights holder, not getting them from the community. > The resources belong to the community. The current resource holder is holding them in trust. They are not property. > >> An organization from another region? > There is no policy to support inter-regional transfers currently and your proposed policy would not inherently create them. >> You say this as if it is somehow a benefit. > > I was asked by Chris why anybody would transfer addresses and fail to have them registered, and these were just examples. > I don't think this is a benefit, but I support a global free market for IP addresses, so they can flow to wherever they are needed most, as measured by their price. > In this way I feel I am extending the definition of community wider than the region of abode. > I do not support using price as the sole measure of the need for addresses. There are many cases where I think that, for example, that providing services to is a far better use than insuring that can make sure that their competitors feel the pinch of address exhaustion well before they do. Measured by money, is almost certain to win. >> A buyer of a /24 who thinks an ARIN needs analysis isn't worth the expense? > >> Again, not seeing the benefit to the community in providing this person the opportunity to take >> that /24 out of the hands of some more deserving organization with documented need. > > You miss my point, they may have need, but for a small transaction, having to negotiate ARIN hurdles could be viewed as unworth the effort. Again this is in response to the request for examples of potential buyers who would not take the steps to register. > For a small transaction, the cost of a needs analysis is also small. As someone with rather extensive experience producing needs-basis justifications for submission to ARIN (and some experience with other RIRs), I can say with certainty that the needs-basis justification for a /24 is very simple and does not provide a significant cost to the equation. >> Microsoft? They didn't seem to want or need a needs analysis until ARIN began negotiating with them after the original asset agreement with Nortel had been negotiated. >> > >> This, also, strikes me as an indication that removing needs basis would have a negative impact >> on the overall outcome. > > ARIN ran in and got the transfer reflected in whois through shenanigans with the needs justification, in my opinion. If there were no needs requirement, I think Microsoft would have asked ARIN to make the updates to whois as the normal course of business, but without knowing how accomodating ARIN would be on a needs analysis, they pointedly left ARIN agreements out of the first negotiated asset sale with Nortel. > Your opinion is noted, but, I don't concur with the characterization you make of the situation. I think you state a number of assertions in that paragraph with no factual basis to back them up. > >> I don't pretend to be able to able to identify all the types of transactions for which an ARIN needs analysis seems an unnecessary intrusion into a transaction between two private entities. >> >> What you call unnecessary, I call vital to the overall interests of the community. > > It was vital when there was no other free and voluntary mechanism to ensure efficient use, but I am trying to show that the needs mechanism is now outdated and poses a problem for whois. > Money does not insure efficient use by any definition of efficiency that I find acceptable. Measuring efficiency by money is sort of like measuring electrical consumption of a house by measuring the temperature rise in the upstairs bedroom. Sure, the electrical consumption in the house will definitely contribute, but, you won't get anything near an accurate measurement. >> The point is that many prior transfers have taken place, particularly with legacy space, that have not been reflected in whois. > >> Hopefully as these can be identified, the space can be revoked and reallocated >> to organizations that comply with policy. The original legacy holder has some >> protections. A third party as a result of an unauthorized transfer should not have >> any protections in this regard. > > Microsoft was the third party here. Addresses were transferred to Nortel from their acquisitions, the original legacy holders here. > By your definitions, since ARIN was not involved, these transfers were unauthorized. Yep. > And yet a bankruptcy judge saw no problems with Microsoft buying them from Nortel. I agree that it is unfortunate that the bankruptcy judge did not see fit to consider the community with greater weight. > I haven't stressed this, but the legal facts as I see them are that legacy holdings can be transferred without ARIN notice or needs requirements. As I see it, this remains unclear. Each of the cases so far has carefully not decided this particular point. > By removing needs requirements for transfers, we bring policy in line with developing law, and this is sure to reduce future conflict. > I would rather preserve conflict and try to develop the law in a more useful direction. I guess you can consider this part of my right to petition the government for redress of grievances. > >> One of the problems relates to the requirement for a needs analysis. > >> No, the problem is the belief that community resources can be transferred outside >> of community policy. > > For legacy addresses, these transfers have occurred in reality, it's time for belief to catch up. > As I said, as these blocks which are being used by entities other than their legitimate holders are identified, ARIN should reclaim them and reissue the resources to organizations within the policy process. That is reality. It is time for ARIN to start becoming more aggressive about identifying them in my opinion. > >> If a holder of legacy space acquired through an asset sale approached ARIN to reflect that transfer, ARIN would not update whois without a needs analysis. > >> As it should be. > > You are arrogating needs requirements over whois accuracy by taking that stance. > No, I am taking the stance that the better way to ensure whois accuracy is by identifying blocks being hijacked by organizations to which they were not issued and reclaiming them and providing them to members of the community in compliance with policy. > >> In addition, the requirement for ARIN to do a needs analysis and the potential for review and recovery on either the buyer or seller increases the FUD factor in the market. > >> Only for those attempting to circumvent policies constructed by the consensus of the community. > > If I want to buy and the seller want to sell, and we have reached an agreement on price, then having to undergo an audit before we can process the sale, or being subject to one thereafter, is most certainly an added uncertainty. > So what. You're trying to trade in community resources that are held in the trust of the community for a particular purpose. The community has a right to audit your use of them and ensure that it is in compliance with the policies of the community. The presence of police on the highway adds an element of uncertainty to my ability to drive at any speed I prefer. I don't necessarily see that as a bad thing, even though it was very inconvenient on several occasions in my younger years. >> For a market to function efficiently, Fear, Uncertainty, and Doubt need to be assuaged, and this proposal does that. >> >> I have tremendous fear and uncertainty about the effects of this proposal. I doubt that it will function as >> advertised. Indeed, I believe this proposal increases each of those things from my perspective. > > So you see how FUD works to prevent action. > More often, I see how it is used to provoke incorrect or counterproductive action, such as the PATRIOT act. >> I copied liberally, almost entirely, from the APNIC policy to allow needs-free transfers. The rationale which was most effective in that regions's deliberations may have been the concern that by imposing the needs requirement, transactions would be more likely to occur outside the system, leading to a decay in whois reliability. >> >> That is the argument Geoff used which appears to have had sway in that region. > >> Geoff has repeatedly made that argument in the ARIN and RIPE regions (and I'm not sure >> that he has not made it in LACNIC or AfriNIC as well). So far, it has not been found to be >> convincing outside of APNIC. > >> By structuring my proposal in this way, I am trying to get people to consider whether the original and laudable needs requirement should be maintained when keeping it could lead to whois degradation. > >> This question has been asked and answered as part of the debate around 2008-2, its successor >> 2008-15 (IIRC) and the boards reconstruction of that into 2009-1. You are welcome to ask the >> question again, but, I'm not inclined to believe the answer has changed. > > Things have changed since then in terms of continued failure to transition and the MS/Nortel deal, and APNIC reaching exhaustion and approving their new transfer policy. > Uh, APNICs current transfer policy was in place prior to 2009-1. If you're talking about their inter-regional transfer policy, that's new, but it doesn't really support a removal of needs basis from the ARIN region. If anything, it makes it even more vital. I don't see how the continued failure to transition differs from the expectations that were considered at the time we were debating 2009-1. Finally, I don't really see that the MS/Nortel deal changes anything other than indicating that we may have been insufficiently specific with the restrictions expressed in 2009-1 (NRM 8.3) and might need to tighten the language so as to place better constraints on staff's action more in line with intended policy. As I said, you are more than welcome to ask the question again. > >> My argument is that proper stewardship recognizes the existence of a market which will fulfill the original stewarship role of ensuring efficient use, and we can direct our stewardship best to policies which help to ensure whois veracity. > >> My argument is that the market alone is not a good steward and a regulated market is necessary >> to ensure the vital interests of the community. > > And I counter that the vital interest in address-use-efficiencies are better offloaded to the market, and the vital interest in maintaining whois veracity is retained. > Yes, your argument that it is better entrusted to the market is precisely the point where I think we have the strongest disagreement. Owen -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike at nationwideinc.com Fri May 6 17:02:27 2011 From: mike at nationwideinc.com (Mike Burns) Date: Fri, 6 May 2011 17:02:27 -0400 Subject: [arin-ppml] Draft proposal that needs some wordsmithing References: <9638601B94304E4392112CF98CDE757C@mike><4DC31B41.3090001@umn.edu> <940FF59153304663A8094B5EEB172AD3@mike> <468BF725-3BA3-423F-A98E-3CC762344D63@delong.com> <5A3A69A575A04812BB8985D1CCCFADAD@mike> Message-ID: <2B708E3CAA4F46599B60EE2001111E3A@mike> Hi Owen, It is my contention that the definition of waste is often in the eye of the beholder, If we keep needs, only ARIN's definition matters. They are THE arbiters of need, and thus the corollary, waste. but, if you define waste as addresses which are not assigned to machines or assigned to machines without a purpose considered useful by at least some person and related to the address being used to provide or consume a service over the network, then, it is my argument that the amount of waste allowed by a market with justified need would be less than that allowed by an unrestricted market. If I concede that, will you concede that a market with a continued justified needs policy would lead to a less reliable whois? We know the needs requirement was not a perfect way to ensure efficiencies. We know that from the number or allocated and not advertised space, if nothing else. No, we do not. Allocated and not advertised DOES NOT mean underutilized. There are many legitimate reasons IP resources may be unadvertised while still fully utilized (or more accurately, utilized but not visible in any routing table to which you particularly have access). I am of the opinion that there is a lot of waste in legacy space, and only slightly less waste in RSA space. Everyone here can make their own decision on that using their own experience to guide them. This is all space that has been allocated outside functioning market environments. I have no reason to believe that a market without justified need requirements would somehow magically reduce waste vs. a market with the requirement that recipients have justified need for their resources. After all, any recipient with justified need for the resources they are receiving is non-waste almost by definition, where this remains largely undefined for a market with no such requirement. An unrestricted market depends on the price of the address to reduce waste. However, unless you consider that tying addresses up to keep them from benefiting your competitors is not waste (I believe it is waste), there is no reason to believe that such an unrestricted market would not create exactly that type of transaction. If competitors tried to do that, they would be taking a risk that their investment would be ill-advised, particularly if they drive Ipv6 adoption. And you are presupposing (a big leap to me) that other addresses would not come into the market to replace those purchased by the fictional competitor who is hoarding. They are fungible, after all. You are asking ARIN to make these kinds of business decisions as to what is a valid strategy and what isn't. A market will not be perfect either, but unlike the prior needs analysis, we seem to be judging the free market by the exceptions. Since the misdeeds (which you claim will be "exceptions") in the market have the potential to overwhelm the market, where no such risk existed in the needs analysis, I think that is a legitimate approach. The stewards of APNIC decided otherwise, and your assertions, like mine, about the dangers of allowing free individuals voluntarily engaging in trade, are unsupported. The APNIC community decided that abandoning needs basis might serve their community better. The other four RIRs have elected to preserve needs basis. The APNIC community is also the most active in terms of recent demand, and closest to exhaust. The sponsor of the needs-free transfer policy was a well respected member of the APNIC community, not a latecomer like me. My statements about the dangers of allowing unrestricted trade are well documented in other markets where they have occurred. Can you point to examples of completely unregulated markets where such misdeeds have not occurred over any substantial period of time? I wish I could point to more unregulated markets. I point to the Internet, which has developed largely because it has been free from government rules. It has also been free from unnecessary psuedo-government rules put in place by existing Internet governance systems. After all, these Internet governance systems could have done more to mandate IPv6, but conservative stewardship left the matter to individual choice. I never said no "misdeeds" will occur in a free market. I claim that these are exceptions, and that you are judging markets by their exceptions. I think free markets have moved the world forward immensely since the concept was elucidated by Adam Smith, and I point to the car you drove to work in as one positive result of free markets. But your request for examples leads me to analogies which is a road I am trying to avoid. 2) Why would any organization with need for unique IPv4 addresses choose to not have those addresses recorded in the database which guarantees their value in order to escape stating their need? (i.e. What class of organization with legitimate need would be hurt by having to demonstrate that need before receiving addresses?) An aggregator buying unroutable bits to aggregate to a routable size?. I see no reason this couldn't be done by an organization with need just as effectively as by some random aggregator intending to resell the result. What if his need is to buy snippets of space in order to aggregate it into sizes acceptable to the network operator community and then sell them? How would he describe that need to ARIN? That isn't a need supported by policy. If he needs an aggregate acceptable to the operator community for his own use, OTOH, I think he could easily justify those multiple purchases to ARIN under current interpretation of 8.3. But you would arbitrarily prevent him from providing that service to others through maintaining ARIN sayso over whether his business is justified. Even though that service would benefit the network operator community through aggregation, and the Internet as a whole via recovery of unroutable space. I don't see where the reseller provides any benefit to the community over the end organization being the one to do the aggregation. You don't think that somebody who specializes in that market would possibly be able to provide the service more efficiently than an end user? Somebody who has a different view on the IPv6 transition timeframe and has a longer planning horizon for IPv4? Then they come to the market multiple times. Each time involves a cost of waiting, an uncertainty cost of the addresses in the future which some companies may find unacceptable, supply uncertainty,as well as transactional and deaggregation costs. Is good stewardship to result in increased costs for consumers of ip address space? Yes... The future of IPv4 is uncertain and will get progressively more uncertain as time progresses. This is the reality of betting your business on continued availability of IPv4. Providing greater or longer durations of certainty to some organizations at the cost of denying it to others is contrary to good stewardship. Who is denying anything to anybody? My contention is that you are denying two entities from engaging in a mutually satisfactory voluntary relationship through intervening with needs verification. Good stewardship is keeping the cost playing field relatively level for all players over time. At least to the greatest extent possible. Doesn't a free market treat participants as equal? My proposal seeks to put legacy and RSA holders on a level playing field. A reseller of vanity addresses, like 100.100.100.100? I see no reason to promote or create these. They offer no meaningful benefit to the community at large. Is it ARIN's role to decide this? Doesn't the history of the Internet suggest allowing volunteer private organizations to make these kinds of decisions? It is the community's role to decide this. As a member of the community, I have offered my opinion. Others may offer theirs. At the end of the day, ARIN policy should reflect the collective judgment of the community. There is no history of volunteer private organizations making these decisions with respect to number resources on the internet and in places where number resources have been allowed to be managed in such a way, careful regulation has been required in each case to avoid substantial problems that have occurred in its absence. It is a complexity which I do not think we should take on, give its limited value to the community as a whole. If the community needs to decide this, what more open way for it to do this than allowing them to vote with their dollars? If it is a bad idea, he will go broke. A wholesaler of addresses who caters to those who need instant availability (needs analysis takes time)? My last needs analysis took less than 24 hours. The average of my last 5 needs analysis is less than 36 hours. That's real-time, not resource analyst or my hours. Microsoft got turned down recently from APNIC for a temporary allocation for some technical symposium in Australia. So? Why can't they look to a wholesaler for rapid, and maybe temporary deployment? In the APNIC region, under their policies, presumably they can. In the ARIN region, they cannot because policy prohibits such wholesalers. What policy does, however, allow, is "matchmakers" who could serve the same purpose without possessing the address registrations in the interim. I believe the STLS term for them is "Facilitators". Given the ability to have facilitators, what need is there for wholesalers? Facilitators cannot control supply in the way a wholesaler can. Surely you can understand that transfers will likely increase in number, and ARIN's needs analyses could take longer? I don't think that transfers will increase beyond current allocation/assignment request rates (modulo normal growth) unless the market is becoming excessively liquid which would indicate that we have some level of failure in policy. So there is a limit to allowable market liquidity in your eyes? But no such wholesaler can exist if you require him to demonstrate need. Nor is he needed or useful in my opinion. Unless Microsoft wants to hold that symposium in North America. Think of a Quik-E-Mart for IP addresses. Are you certain there would never be a call for that kind of convenience? The visual of purchasing a Big-Gulp full of IP addresses at the local 7-11 is just too much for me to take seriously. Not 7-11, Apu from the Simpsons will be doling out the address. I guess that doesn't help with the seriousness. What if there are supply problems on STLS? A wholesaler with inventory on hand is often a valuable resource in times like that, even though he is going to make a buck on the deal. How is a wholesaler with inventory different from a facilitator as defined in STLS in any meaningful way? The facilitator can still make a buck on the deal. If there's a supply problem, it's because there isn't a supply, not because policy prevented people from providing supply. This is not reasonable. Surely you could see, especially in the current slim pickings of the STLS, that the market may have a supply problem? If I thought this, and thought I could profit from being a reliable supplier by holding some inventory, your policy would prevent me from entering this business artificially, not through any economic reason. A speculator, who could have a positive role in free markets? ROFL -- The concept of speculator in the same sentence with "positive role" amuses me. Suggested reading for when you arise from the floor http://mises.org/daily/320 After a long winded explanation of how he can cloud the definition of speculation to mean virtually any form of investing, he finally gets to the point of claiming that there is a benefit to the market if: 1. Prices adjust quickly -- In the case of speculators this almost always means "increase" 2. There is greater liquidity -- Though he makes no mention of how, exactly, speculation actually increases liquidity 3. The market fluctuations are minimized -- Which is interesting to attribute to speculators after attempting to attribute case 1 to them as well. In my observations of various markets, speculators have had a destabilizing influence with a general tendency to increase prices, often far above and beyond rational levels. Yes, the speculators at the end of that process when the bubble bursts usually get hurt badly, then, we the taxpayers get to pay to bail them out, too. If you believe all that, then you should be a speculator. I certainly would never support taxpayer bailouts to speculators. An organization that does not want to undergo an ARIN analysis for fear it will lead to a review and recovery procedure? An organization which has reason to fear this is an organization which probably shouldn't be getting additional resources from the community. They would be buying them from the rights holder, not getting them from the community. The resources belong to the community. The current resource holder is holding them in trust. They are not property. Funny they appear on many asset sale documents I have seen along with other tangible and intangible property. And I can have the exclusive right to sell them according to MS/Nortel, even if they weren't allocated to me. Walks and quacks like rights ownership. An organization from another region? There is no policy to support inter-regional transfers currently and your proposed policy would not inherently create them. You are correct, but this is still a reason why somebody would seek to transfer without registering, Chris' original request. You say this as if it is somehow a benefit. I was asked by Chris why anybody would transfer addresses and fail to have them registered, and these were just examples. I don't think this is a benefit, but I support a global free market for IP addresses, so they can flow to wherever they are needed most, as measured by their price. In this way I feel I am extending the definition of community wider than the region of abode. I do not support using price as the sole measure of the need for addresses. There are many cases where I think that, for example, that providing services to is a far better use than insuring that can make sure that their competitors feel the pinch of address exhaustion well before they do. Measured by money, is almost certain to win. In this endeavor, I view ARIN as the large monopolistic entity. A buyer of a /24 who thinks an ARIN needs analysis isn't worth the expense? Again, not seeing the benefit to the community in providing this person the opportunity to take that /24 out of the hands of some more deserving organization with documented need. You miss my point, they may have need, but for a small transaction, having to negotiate ARIN hurdles could be viewed as unworth the effort. Again this is in response to the request for examples of potential buyers who would not take the steps to register. For a small transaction, the cost of a needs analysis is also small. As someone with rather extensive experience producing needs-basis justifications for submission to ARIN (and some experience with other RIRs), I can say with certainty that the needs-basis justification for a /24 is very simple and does not provide a significant cost to the equation. Suppose it is some doctor's office that wants to multihome, do you think they would have the same view of that as a person with your experience? Microsoft? They didn't seem to want or need a needs analysis until ARIN began negotiating with them after the original asset agreement with Nortel had been negotiated. This, also, strikes me as an indication that removing needs basis would have a negative impact on the overall outcome. ARIN ran in and got the transfer reflected in whois through shenanigans with the needs justification, in my opinion. If there were no needs requirement, I think Microsoft would have asked ARIN to make the updates to whois as the normal course of business, but without knowing how accomodating ARIN would be on a needs analysis, they pointedly left ARIN agreements out of the first negotiated asset sale with Nortel. Your opinion is noted, but, I don't concur with the characterization you make of the situation. I think you state a number of assertions in that paragraph with no factual basis to back them up. I don't make a single assertion in that paragraph without factual basis of backup. I invite you to read the original negotiated MS/Nortel asset sale document, and the one that was edited after ARIN became involved. Well, I take that back, I did allege shenanigans, but I did back that up last week with logical conjecture if not actual fact. I don't pretend to be able to able to identify all the types of transactions for which an ARIN needs analysis seems an unnecessary intrusion into a transaction between two private entities. What you call unnecessary, I call vital to the overall interests of the community. It was vital when there was no other free and voluntary mechanism to ensure efficient use, but I am trying to show that the needs mechanism is now outdated and poses a problem for whois. Money does not insure efficient use by any definition of efficiency that I find acceptable. Measuring efficiency by money is sort of like measuring electrical consumption of a house by measuring the temperature rise in the upstairs bedroom. Sure, the electrical consumption in the house will definitely contribute, but, you won't get anything near an accurate measurement. My measurement of efficiency is address utilization. We are near exhaust and there are a billion unrouted addresses. The current system displays obvious inefficiencies, although overall I think it did its job well. The point is that many prior transfers have taken place, particularly with legacy space, that have not been reflected in whois. Hopefully as these can be identified, the space can be revoked and reallocated to organizations that comply with policy. The original legacy holder has some protections. A third party as a result of an unauthorized transfer should not have any protections in this regard. Microsoft was the third party here. Addresses were transferred to Nortel from their acquisitions, the original legacy holders here. By your definitions, since ARIN was not involved, these transfers were unauthorized. Yep. And yet a bankruptcy judge saw no problems with Microsoft buying them from Nortel. I agree that it is unfortunate that the bankruptcy judge did not see fit to consider the community with greater weight. I haven't stressed this, but the legal facts as I see them are that legacy holdings can be transferred without ARIN notice or needs requirements. As I see it, this remains unclear. Each of the cases so far has carefully not decided this particular point. By removing needs requirements for transfers, we bring policy in line with developing law, and this is sure to reduce future conflict. I would rather preserve conflict and try to develop the law in a more useful direction. I guess you can consider this part of my right to petition the government for redress of grievances. Fair enough, but you have to accede the cost to ARIN of that possibility of conflict with the law when it comes to future legacy transactions. One of the problems relates to the requirement for a needs analysis. No, the problem is the belief that community resources can be transferred outside of community policy. For legacy addresses, these transfers have occurred in reality, it's time for belief to catch up. As I said, as these blocks which are being used by entities other than their legitimate holders are identified, ARIN should reclaim them and reissue the resources to organizations within the policy process. That is reality. It is time for ARIN to start becoming more aggressive about identifying them in my opinion. And we're back to FUD over section 12 processes for those seeking to bring addresses to the market. If a holder of legacy space acquired through an asset sale approached ARIN to reflect that transfer, ARIN would not update whois without a needs analysis. As it should be. You are arrogating needs requirements over whois accuracy by taking that stance. No, I am taking the stance that the better way to ensure whois accuracy is by identifying blocks being hijacked by organizations to which they were not issued and reclaiming them and providing them to members of the community in compliance with policy. There is no legal process for reclaiming legacy space. You would be wasting ARIN's time and treasure in the legacy area, and increasing FUD for existing holders seeking to sell. I don't even think there is an ARIN process for recovering legacy space, except through voluntary donation from the holder. In addition, the requirement for ARIN to do a needs analysis and the potential for review and recovery on either the buyer or seller increases the FUD factor in the market. Only for those attempting to circumvent policies constructed by the consensus of the community. If I want to buy and the seller want to sell, and we have reached an agreement on price, then having to undergo an audit before we can process the sale, or being subject to one thereafter, is most certainly an added uncertainty. So what. You're trying to trade in community resources that are held in the trust of the community for a particular purpose. The community has a right to audit your use of them and ensure that it is in compliance with the policies of the community. The presence of police on the highway adds an element of uncertainty to my ability to drive at any speed I prefer. I don't necessarily see that as a bad thing, even though it was very inconvenient on several occasions in my younger years. And the element of uncertainty slows your progress, correct? For a market to function efficiently, Fear, Uncertainty, and Doubt need to be assuaged, and this proposal does that. I have tremendous fear and uncertainty about the effects of this proposal. I doubt that it will function as advertised. Indeed, I believe this proposal increases each of those things from my perspective. So you see how FUD works to prevent action. More often, I see how it is used to provoke incorrect or counterproductive action, such as the PATRIOT act. I copied liberally, almost entirely, from the APNIC policy to allow needs-free transfers. The rationale which was most effective in that regions's deliberations may have been the concern that by imposing the needs requirement, transactions would be more likely to occur outside the system, leading to a decay in whois reliability. That is the argument Geoff used which appears to have had sway in that region. Geoff has repeatedly made that argument in the ARIN and RIPE regions (and I'm not sure that he has not made it in LACNIC or AfriNIC as well). So far, it has not been found to be convincing outside of APNIC. By structuring my proposal in this way, I am trying to get people to consider whether the original and laudable needs requirement should be maintained when keeping it could lead to whois degradation. This question has been asked and answered as part of the debate around 2008-2, its successor 2008-15 (IIRC) and the boards reconstruction of that into 2009-1. You are welcome to ask the question again, but, I'm not inclined to believe the answer has changed. Things have changed since then in terms of continued failure to transition and the MS/Nortel deal, and APNIC reaching exhaustion and approving their new transfer policy. Uh, APNICs current transfer policy was in place prior to 2009-1. This page says February 2010, but even though it may have been in place, it was only activated as the exhaust phased in. http://www.apnic.net/policy/proposals/prop-050 Back in 2009, many people were still thinking/hoping the transition would take off, but now we have years more evidence to the contrary, which may change some minds. If you're talking about their inter-regional transfer policy, that's new, but it doesn't really support a removal of needs basis from the ARIN region. If anything, it makes it even more vital. I don't see how the continued failure to transition differs from the expectations that were considered at the time we were debating 2009-1. Finally, I don't really see that the MS/Nortel deal changes anything other than indicating that we may have been insufficiently specific with the restrictions expressed in 2009-1 (NRM 8.3) and might need to tighten the language so as to place better constraints on staff's action more in line with intended policy. As I said, you are more than welcome to ask the question again. My argument is that proper stewardship recognizes the existence of a market which will fulfill the original stewarship role of ensuring efficient use, and we can direct our stewardship best to policies which help to ensure whois veracity. My argument is that the market alone is not a good steward and a regulated market is necessary to ensure the vital interests of the community. And I counter that the vital interest in address-use-efficiencies are better offloaded to the market, and the vital interest in maintaining whois veracity is retained. Yes, your argument that it is better entrusted to the market is precisely the point where I think we have the strongest disagreement. But what about whois? Don't we absolutely require a believable registry for the integrity of the whole Internet? There is a connection between needs requirements and whois reliability that drove the APNIC decision. I would like to say that I will busy out of town this weekend, but this thread in particular has probably bored the readers to tears and they will be happy at my absence and their relatively empty inboxes. My plan is to take some of the proferred suggestions and resubmit a draft proposal on Monday for futher discussion. Have a nice weekend. REgards, MIke -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcurran at arin.net Fri May 6 17:04:21 2011 From: jcurran at arin.net (John Curran) Date: Fri, 6 May 2011 21:04:21 +0000 Subject: [arin-ppml] transfer conditions In-Reply-To: References: <75E9BD24-F12F-42BF-A989-CF6CC282B28E@arin.net> <7406316661701612155@unknownmsgid> <3F57F52B-F1F1-4450-B493-AA4D544D8D15@arin.net> <8740380157159276993@unknownmsgid> <49E26DCB-DAF7-4A0A-912E-F981494979F5@delong.com> <4DBC2AEB.9040307@matthew.at> <4DBCA58D.4060704@sprunk.org> <2344ADD7-616E-4FA7-9552-19735926A952@delong.com> Message-ID: <391BFA8C-9D09-4BB2-8D49-FD5F9C6FDF93@arin.net> On May 2, 2011, at 4:32 PM, Owen DeLong wrote: > 1. Org. A has a /8 and wants to transfer 32 of it's constituent /24s to Org. B. > However, Org. A doesn't want to put any effort into renumbering, > so, those 32 /24s are each individual non-aggregable /24s. > > This transfer should not be allowed. Owen - I'm going to rework your example a little bit to assist in my understanding of your position: If an Org X has two blocks: a /16 (NETX16) and a /24 (NETX24), & they approach ARIN and indicate that they want to transfer a /24 portion of NETX16 to Org Y, ARIN should disallow it? Does that answer change if NETX24 is in already heavily in use by Org B? What if NETX24 is in use, and it's a part in an embedded system already in the field? What if NETX24 is in use by another business unit than the one which holds the NETX16? Thanks! /John John Curran President and CEO ARIN From owen at delong.com Sat May 7 01:40:04 2011 From: owen at delong.com (Owen DeLong) Date: Fri, 6 May 2011 22:40:04 -0700 Subject: [arin-ppml] transfer conditions In-Reply-To: <391BFA8C-9D09-4BB2-8D49-FD5F9C6FDF93@arin.net> References: <75E9BD24-F12F-42BF-A989-CF6CC282B28E@arin.net> <7406316661701612155@unknownmsgid> <3F57F52B-F1F1-4450-B493-AA4D544D8D15@arin.net> <8740380157159276993@unknownmsgid> <49E26DCB-DAF7-4A0A-912E-F981494979F5@delong.com> <4DBC2AEB.9040307@matthew.at> <4DBCA58D.4060704@sprunk.org> <2344ADD7-616E-4FA7-9552-19735926A952@delong.com> <391BFA8C-9D09-4BB2-8D49-FD5F9C6FDF93@arin.net> Message-ID: <6B951089-C686-4929-AC21-A1BF91BBBCB7@delong.com> On May 6, 2011, at 2:04 PM, John Curran wrote: > On May 2, 2011, at 4:32 PM, Owen DeLong wrote: > >> 1. Org. A has a /8 and wants to transfer 32 of it's constituent /24s to Org. B. >> However, Org. A doesn't want to put any effort into renumbering, >> so, those 32 /24s are each individual non-aggregable /24s. >> >> This transfer should not be allowed. > > Owen - > > I'm going to rework your example a little bit to assist in > my understanding of your position: > > If an Org X has two blocks: a /16 (NETX16) and a /24 (NETX24), & they > approach ARIN and indicate that they want to transfer a /24 portion > of NETX16 to Org Y, ARIN should disallow it? Does that answer change > if NETX24 is in already heavily in use by Org B? What if NETX24 is > in use, and it's a part in an embedded system already in the field? > What if NETX24 is in use by another business unit than the one which > holds the NETX16? > Ideally: Yes... No... No... No. Realistically, probably hard to enforce beyond: No... No... No... No. Owen From owen at delong.com Sat May 7 02:37:47 2011 From: owen at delong.com (Owen DeLong) Date: Fri, 6 May 2011 23:37:47 -0700 Subject: [arin-ppml] Draft proposal that needs some wordsmithing In-Reply-To: <2B708E3CAA4F46599B60EE2001111E3A@mike> References: <9638601B94304E4392112CF98CDE757C@mike><4DC31B41.3090001@umn.edu> <940FF59153304663A8094B5EEB172AD3@mike> <468BF725-3BA3-423F-A98E-3CC762344D63@delong.com> <5A3A69A575A04812BB8985D1CCCFADAD@mike> <2B708E3CAA4F46599B60EE2001111E3A@mike> Message-ID: <36768B46-2E69-434D-A7EB-0FEEC81BF184@delong.com> On May 6, 2011, at 2:02 PM, Mike Burns wrote: > Hi Owen, > > > It is my contention that the definition of waste is often in the eye of the beholder, > > If we keep needs, only ARIN's definition matters. They are THE arbiters of need, and thus the corollary, waste. > In which case, by definition, the current policies are 100% waste free. I don't think that's what you intended to say. ;-) > > > but, if you define waste as addresses which are not assigned to machines or > assigned to machines without a purpose considered useful by at least some > person and related to the address being used to provide or consume a service > over the network, then, it is my argument that the amount of waste allowed by > a market with justified need would be less than that allowed by an unrestricted > market. > If I concede that, will you concede that a market with a continued justified needs policy would lead to a less reliable whois? > No, I think it will lead to a similarly reliable whois to what we have today. Neither less nor more. I believe a permissive market policy _COULD_ lead to a slightly more reliable whois, but, I tend to doubt this. > > >>> We know the needs requirement was not a perfect way to ensure efficiencies. >>> We know that from the number or allocated and not advertised space, if nothing else. >> >>> No, we do not. Allocated and not advertised DOES NOT mean underutilized. >>> There are many legitimate reasons IP resources may be unadvertised while still >>> fully utilized (or more accurately, utilized but not visible in any routing table to which >>> you particularly have access). >> >> I am of the opinion that there is a lot of waste in legacy space, and only slightly less waste in RSA space. >> Everyone here can make their own decision on that using their own experience to guide them. >> This is all space that has been allocated outside functioning market environments. >> > I have no reason to believe that a market without justified need requirements would > somehow magically reduce waste vs. a market with the requirement that recipients > have justified need for their resources. After all, any recipient with justified need for > the resources they are receiving is non-waste almost by definition, where this > remains largely undefined for a market with no such requirement. > > An unrestricted market depends on the price of the address to reduce waste. However, > unless you consider that tying addresses up to keep them from benefiting your > competitors is not waste (I believe it is waste), there is no reason to believe that > such an unrestricted market would not create exactly that type of transaction. > > If competitors tried to do that, they would be taking a risk that their investment would be ill-advised, particularly if they drive Ipv6 adoption. > And you are presupposing (a big leap to me) that other addresses would not come into the market to replace those purchased by the fictional competitor who is hoarding. > They are fungible, after all. You are asking ARIN to make these kinds of business decisions as to what is a valid strategy and what isn't. > Either you don't understand this industry, or, you are making some very interesting assumptions. Imagine for a moment that the 5 largest providers in the US are able to use an unrestricted transfer market to acquire enough addressing for their IPv4 needs for the next 10 years. This has the side effect of essentially eliminating the supply from the market. Now you have the incumbent {telco,cableco,etc.} continuing to provide uninterrupted IPv4 services without LSN to their users while their competitors (all the small and medium sized ISPs) have no access to additional addresses and are forced to subject their customers to LSN and/or adopt IPv6. In this scenario, rather than a significant customer migration to IPv6, what you likely drive is a significant customer migration to the incumbent {telco,cableco,etc.} and the elimination of the competing smaller ISPs in most markets. I do not consider that to be in the community interest. > >>> A market will not be perfect either, but unlike the prior needs analysis, we seem to be judging the free market by the exceptions. >>> >>> Since the misdeeds (which you claim will be "exceptions") in the market have the >>> potential to overwhelm the market, where no such risk existed in the needs >>> analysis, I think that is a legitimate approach. >> >> The stewards of APNIC decided otherwise, and your assertions, like mine, about the dangers of allowing free individuals voluntarily engaging in trade, are unsupported. >> > The APNIC community decided that abandoning needs basis might serve their > community better. The other four RIRs have elected to preserve needs basis. > > The APNIC community is also the most active in terms of recent demand, and closest to exhaust. > The sponsor of the needs-free transfer policy was a well respected member of the APNIC community, not a latecomer like me. Yes... As you know, I am well aware of Geoff's thinking on this and well versed in his position on the subject. You are correct that Geoff is a well respected member of the APNIC community. However, there are a number of things that are unique to the APNIC region and policy process that lead me to believe that looking to them for guidance in this area will not lead to a good outcome for the ARIN community. How many APNIC meetings have you attended? How long have you been subscribed to the APNIC Policy SIG mailing list? I am not a latecomer, either, and I have good familiarity with both APNIC and ARIN. Indeed, I believe I am reasonably well known in at least 4 of the 5 RIR communities. I have been to at least one policy meeting of each of the 5 RIRs in the last year. LACNIC and RIPE are the only regions where I have not yet attended multiple meetings. > > > My statements about the dangers of allowing unrestricted trade are well documented > in other markets where they have occurred. Can you point to examples of completely > unregulated markets where such misdeeds have not occurred over any substantial > period of time? > I wish I could point to more unregulated markets. I point to the Internet, which has developed largely because it has been free from government rules. Well, if you want to use the internet as an example, I would say that the damage done by the deregulation of DNS and it's subsequent abandonment of stewardship in favor of policies preferred by WIPO is a classic example of a market gone wrong. The pollution of the TLD namespace in the name of ICANN earnings is another. > It has also been free from unnecessary psuedo-government rules put in place by existing Internet governance systems. For this to be true, you would have to give up on characterizing the RIR policies as being such rules. You cannot have your cake and eat it too. > After all, these Internet governance systems could have done more to mandate IPv6, but conservative stewardship left the matter to individual choice. I challenge you to cite feasible examples. Please make sure to include the alleged governance body and details of the steps they could have taken to mandate IPv6. > I never said no "misdeeds" will occur in a free market. I claim that these are exceptions, and that you are judging markets by their exceptions. I claim that while they may be exceptions, they may be of such magnitude as to define the market. You have offered nothing to counter that claim. > I think free markets have moved the world forward immensely since the concept was elucidated by Adam Smith, and I point to the car you drove to work in as one positive result of free markets. I point to our utter dependence on foreign oil, the limits of liabilities on oil companies for their environmental disasters, the lack of natural-gas powered automobiles and infrastructure to support them, and the limited investment in renewable energy until very recently as overwhelming counter-examples in that very field. Let us not also forget that it is not the free market, but, regulation and product liability law which brought about most of the innovations in automotive safety whereas the free market was perfectly happy to keep killing people as long as they made enough babies first to have more consumers to buy more cars. > But your request for examples leads me to analogies which is a road I am trying to avoid. > I suppose that's your choice. I believe I have provided examples of market failures. You wish to dismiss them as exceptions, but, this would be such a constrained market that I do not see how you can dismiss the potential for these exceptions to be of such magnitude as to define the market. As such, I do not believe they can be so easily dismissed. > >> >>> >>>> 2) Why would any organization with need for unique IPv4 addresses >>>> choose to not have those addresses recorded in the database which >>>> guarantees their value in order to escape stating their need? (i.e. >>>> What class of organization with legitimate need would be hurt by >>>> having to demonstrate that need before receiving addresses?) >>>> >>> >>> An aggregator buying unroutable bits to aggregate to a routable size?. >> >>> I see no reason this couldn't be done by an organization with need just as effectively >>> as by some random aggregator intending to resell the result. >> >> What if his need is to buy snippets of space in order to aggregate it into sizes acceptable to the network operator community and then sell them? >> How would he describe that need to ARIN? >> > That isn't a need supported by policy. If he needs an aggregate acceptable > to the operator community for his own use, OTOH, I think he could easily justify > those multiple purchases to ARIN under current interpretation of 8.3. > > But you would arbitrarily prevent him from providing that service to others through maintaining ARIN sayso over whether his business is justified. Even though that service would benefit the network operator community through aggregation, and the Internet as a whole via recovery of unroutable space. > I don't believe his ability to aggregate space would, in any way, be superior to the ability of the end recipients of the space that need it. As such, I do not believe my dismissal of the business model is arbitrary. I believe the business model is largely fictitious in nature. > I don't see where the reseller provides any benefit to the community over the > end organization being the one to do the aggregation. > > You don't think that somebody who specializes in that market would possibly be able to provide the service more efficiently than an end user? > No, I do not. For one thing, I'm not convinced it would be at all feasible for either. The general nature of addressing is that aggregation is hard and disaggregation is relatively easy. The universe tends towards entropy. Aggregation requires a substantial force acting against entropy. > >>> Somebody who has a different view on the IPv6 transition timeframe and has a longer planning horizon for IPv4? >> >>> Then they come to the market multiple times. >> >> Each time involves a cost of waiting, an uncertainty cost of the addresses in the future which some companies may find unacceptable, supply uncertainty,as well as transactional and deaggregation costs. >> Is good stewardship to result in increased costs for consumers of ip address space? >> > Yes... The future of IPv4 is uncertain and will get progressively more uncertain as time progresses. > This is the reality of betting your business on continued availability of IPv4. > > Providing greater or longer durations of certainty to some organizations at the cost of denying it to others > is contrary to good stewardship. > > Who is denying anything to anybody? My contention is that you are denying two entities from engaging in a mutually satisfactory voluntary relationship through intervening with needs verification. > If you accept the following postulates (which I do): 1. IPv4 address space is finite. (This is fact, there are roughly 3.8 billion IPv4 unicast addresses) 2. The need for IPv4 addresses vastly exceeds their number (Consider 6.8 billion people and multiply by laptop+desktop+cellphone (20.4 billion). In my understanding of mathematics, 3.8 < 20.4. By the way, that 20.4 figure ignores the need for servers, infrastructure, etc. all of which also need addresses. Now, if you want to claim that only 25% of the worlds citizens will be connected to IPv4, then, you can reduce 20.4 to 5.1 billion. Last I checked, 3.8 < 5.1 too.) 3. The transfer of addresses is a zero sum gain. There is no creation of new addresses accomplished by any transfer mechanism. (also mathematical fact). Then, it stands to reason that for party A to obtain addresses from the transfer market, those same addresses are denied to party B. For party B to obtain addresses, those same addresses are denied to party C. This continues until you reach some party who is unable to obtain addresses. Basically, the movement of addresses through the transfer policy amounts to a form of "musical chairs". If there are enough chairs for everyone, then, when the music stops, everyone sits. However, as I postulated above, there are not enough chairs. > Good stewardship is keeping the cost playing field relatively level for all players over time. > At least to the greatest extent possible. > Doesn't a free market treat participants as equal? My proposal seeks to put legacy and RSA holders on a level playing field. > A free market inherently gives advantages to those with greater capital over those with less capital. With a sufficiently greater capital advantage, one can literally control the market. The IPv4 address market will be sufficiently constrained that this is not an unlikely outcome. >>> A reseller of vanity addresses, like 100.100.100.100? >> >>> I see no reason to promote or create these. They offer no meaningful benefit to the >>> community at large. >> >> Is it ARIN's role to decide this? Doesn't the history of the Internet suggest allowing volunteer private organizations to make these kinds of decisions? >> > It is the community's role to decide this. As a member of the community, I have offered > my opinion. Others may offer theirs. At the end of the day, ARIN policy should reflect > the collective judgment of the community. > > There is no history of volunteer private organizations making these decisions with > respect to number resources on the internet and in places where number resources > have been allowed to be managed in such a way, careful regulation has been required > in each case to avoid substantial problems that have occurred in its absence. It is a > complexity which I do not think we should take on, give its limited value to the community > as a whole. > If the community needs to decide this, what more open way for it to do this than allowing them to vote with their dollars? If it is a bad idea, he will go broke. > The more open way, IMHO, is the public policy process where it is one person, one vote instead of using dollars where it becomes one dollar one vote. I favor people over capital when it comes to decision making. >>> A wholesaler of addresses who caters to those who need instant availability (needs analysis takes time)? >> >>> My last needs analysis took less than 24 hours. The average of my last 5 needs analysis is less than 36 hours. >>> That's real-time, not resource analyst or my hours. >> >> Microsoft got turned down recently from APNIC for a temporary allocation for some technical symposium in Australia. > > So? > >> Why can't they look to a wholesaler for rapid, and maybe temporary deployment? > > In the APNIC region, under their policies, presumably they can. In the ARIN region, they cannot because policy > prohibits such wholesalers. What policy does, however, allow, is "matchmakers" who could serve the same purpose > without possessing the address registrations in the interim. I believe the STLS term for them is "Facilitators". > > Given the ability to have facilitators, what need is there for wholesalers? > > Facilitators cannot control supply in the way a wholesaler can. > I see that as an advantage. >> Surely you can understand that transfers will likely increase in number, and ARIN's needs analyses could take longer? > > I don't think that transfers will increase beyond current allocation/assignment request rates (modulo normal growth) > unless the market is becoming excessively liquid which would indicate that we have some level of failure in policy. > > So there is a limit to allowable market liquidity in your eyes? > Perhaps I used the wrong term, but, unless the market is somehow perverted into a "day-trading" of addresses purely for the purpose of profiteering (which would have an obvious destabilizing effect on the network as a result), I don't see the potential for the transaction rate to become significantly higher than the current application rate. >> But no such wholesaler can exist if you require him to demonstrate need. > > Nor is he needed or useful in my opinion. > > Unless Microsoft wants to hold that symposium in North America. > Micr0$0ft can get their addresses directly from the resource holders without need of a wholesaler in either region. >> Think of a Quik-E-Mart for IP addresses. Are you certain there would never be a call for that kind of convenience? > > The visual of purchasing a Big-Gulp full of IP addresses at the local 7-11 is just too much for me to take seriously. > > Not 7-11, Apu from the Simpsons will be doling out the address. I guess that doesn't help with the seriousness. > No, it really doesn't. >> What if there are supply problems on STLS? A wholesaler with inventory on hand is often a valuable resource in times like that, even though he is going to make a buck on the deal. >> > How is a wholesaler with inventory different from a facilitator as defined in STLS in any meaningful way? > > The facilitator can still make a buck on the deal. If there's a supply problem, it's because there isn't a supply, > not because policy prevented people from providing supply. > > This is not reasonable. Surely you could see, especially in the current slim pickings of the STLS, that the market may have a supply problem? > If I thought this, and thought I could profit from being a reliable supplier by holding some inventory, your policy would prevent me from entering this business artificially, not through any economic reason. The market _WILL_ have a supply problem no matter what. See my above statement about the total supply vs. the obvious demand. If there were no supply problem, then, we would not have bothered developing IPv6 in the first place. The supply problem is obvious and inherent in the situation which is leading to us even considering a market in the first place. What is not reasonable is any belief that it is possible for an IPv4 market to exist without a supply problem for any length of time. Where would you get this inventory that others cannot get it from? Why would someone prefer to sell their addresses to you as a wholesaler than sell them directly to an organization that needs addresses? > > >>> A speculator, who could have a positive role in free markets? >> >>> ROFL -- The concept of speculator in the same sentence with "positive role" amuses me. >> >> Suggested reading for when you arise from the floor >> http://mises.org/daily/320 >> > After a long winded explanation of how he can cloud the definition of speculation to mean virtually > any form of investing, he finally gets to the point of claiming that there is a benefit to the market if: > > 1. Prices adjust quickly > -- In the case of speculators this almost always means "increase" > > 2. There is greater liquidity > -- Though he makes no mention of how, exactly, speculation actually increases liquidity > > 3. The market fluctuations are minimized > -- Which is interesting to attribute to speculators after attempting to attribute case 1 to them as well. > > In my observations of various markets, speculators have had a destabilizing influence with a general > tendency to increase prices, often far above and beyond rational levels. > > Yes, the speculators at the end of that process when the bubble bursts usually get hurt badly, then, we > the taxpayers get to pay to bail them out, too. > > If you believe all that, then you should be a speculator. I certainly would never support taxpayer bailouts to speculators. > I don't support taxpayer bailouts to speculators as a political position. Indeed, I'm quite tired of having my tax dollars used in that way. I'm particularly frustrated at the moment because they managed to: 1. Devalue my property to 33% of what it was once worth. 2. Force the government to create new stricter rules on refinancing which now preclude me from refinancing due to my Loan-to-Value ratio (which was perfectly fine until they devalued my house). Unfortunately, since I purchased responsibly and did not engage in speculation or dive head first into water over my head, I am not entitled to any of the government programs designed to help the people who caused the problem in the first place, so, here I sit paying almost 6% on a mortgage that I could refinance down to a little more than 3% if the speculators hadn't "rapidly adjusted the market". >>> An organization that does not want to undergo an ARIN analysis for fear it will lead to a review and recovery procedure? >> >>> An organization which has reason to fear this is an organization which probably shouldn't >>> be getting additional resources from the community. >> >> They would be buying them from the rights holder, not getting them from the community. >> > The resources belong to the community. The current resource holder is holding them in trust. > They are not property. > > Funny they appear on many asset sale documents I have seen along with other tangible and intangible property. > And I can have the exclusive right to sell them according to MS/Nortel, even if they weren't allocated to me. > Walks and quacks like rights ownership. > As I said, this particular question has not yet received a direct ruling. I would not look to MS/Nortel as precedent setting so much as I think it is an irregularity. > >> >>> An organization from another region? >> > There is no policy to support inter-regional transfers currently and your proposed policy > would not inherently create them. > You are correct, but this is still a reason why somebody would seek to transfer without registering, Chris' original request. > Such a transfer should, as I said, be voided by the respective RIR, the resources reclaimed, and reissued to someone acting within policy. > >>> You say this as if it is somehow a benefit. >> >> I was asked by Chris why anybody would transfer addresses and fail to have them registered, and these were just examples. >> I don't think this is a benefit, but I support a global free market for IP addresses, so they can flow to wherever they are needed most, as measured by their price. >> In this way I feel I am extending the definition of community wider than the region of abode. >> > I do not support using price as the sole measure of the need for addresses. There are many cases where I think > that, for example, that providing services to is a far better use than insuring that > can make sure that their competitors feel the pinch of address exhaustion > well before they do. > > Measured by money, is almost certain to win. > > In this endeavor, I view ARIN as the large monopolistic entity. > No, ARIN may be monopolistic when it comes to address management within their service region, but, my meaning above is the incumbent telcos, cablecos, etc. that mostly operate in either effective or actual monopolies or at best in some cases duopolies. I'm talking about the relative size of the market participants, not ARIN which would be sitting on the side lines of a market recording the events of the day as it were. >>> A buyer of a /24 who thinks an ARIN needs analysis isn't worth the expense? >> >>> Again, not seeing the benefit to the community in providing this person the opportunity to take >>> that /24 out of the hands of some more deserving organization with documented need. >> >> You miss my point, they may have need, but for a small transaction, having to negotiate ARIN hurdles could be viewed as unworth the effort. Again this is in response to the request for examples of potential buyers who would not take the steps to register. >> > For a small transaction, the cost of a needs analysis is also small. As someone with rather > extensive experience producing needs-basis justifications for submission to ARIN (and > some experience with other RIRs), I can say with certainty that the needs-basis justification > for a /24 is very simple and does not provide a significant cost to the equation. > > Suppose it is some doctor's office that wants to multihome, do you think they would have the same view of that as a person with your experience? > None of my customers (some of whom have been small doctor's offices) have had a problem with my fee for preparing their justification. As such, I would say I have evidence that it is not. > >>> Microsoft? They didn't seem to want or need a needs analysis until ARIN began negotiating with them after the original asset agreement with Nortel had been negotiated. >>> >> >>> This, also, strikes me as an indication that removing needs basis would have a negative impact >>> on the overall outcome. >> >> ARIN ran in and got the transfer reflected in whois through shenanigans with the needs justification, in my opinion. If there were no needs requirement, I think Microsoft would have asked ARIN to make the updates to whois as the normal course of business, but without knowing how accomodating ARIN would be on a needs analysis, they pointedly left ARIN agreements out of the first negotiated asset sale with Nortel. >> > Your opinion is noted, but, I don't concur with the characterization you make of the situation. > > I think you state a number of assertions in that paragraph with no factual basis to back them up. > > I don't make a single assertion in that paragraph without factual basis of backup. I invite you to read the original negotiated MS/Nortel asset sale document, and the one that was edited after ARIN became involved. > Well, I take that back, I did allege shenanigans, but I did back that up last week with logical conjecture if not actual fact. I don't agree with your claim of shenanigans. I am inclined to believe John when he states that a full and legitimate needs-basis justification was provided and reviewed by the ARIN staff. I do not believe for one moment that ARIN was in any way more accommodating for Micr0$0ft than they would be for any other transfer recipient W.R.T. needs basis. I also am not convinced that you have any evidence that they "pointedly left ARIN agreements out" vs. it being a simple oversight. > > >> >>> I don't pretend to be able to able to identify all the types of transactions for which an ARIN needs analysis seems an unnecessary intrusion into a transaction between two private entities. >>> >>> What you call unnecessary, I call vital to the overall interests of the community. >> >> It was vital when there was no other free and voluntary mechanism to ensure efficient use, but I am trying to show that the needs mechanism is now outdated and poses a problem for whois. >> > Money does not insure efficient use by any definition of efficiency that I find acceptable. > > Measuring efficiency by money is sort of like measuring electrical consumption of > a house by measuring the temperature rise in the upstairs bedroom. Sure, the electrical > consumption in the house will definitely contribute, but, you won't get anything near > an accurate measurement. > My measurement of efficiency is address utilization. We are near exhaust and there are a billion unrouted addresses. > The current system displays obvious inefficiencies, although overall I think it did its job well. > Measuring it by money virtually assures that a few large ISPs will remove all supply rapidly from the market in order to shut out smaller competitors and position themselves in a place of address affluence for years to come. I will take the current inefficiencies over that situation any day. >>> The point is that many prior transfers have taken place, particularly with legacy space, that have not been reflected in whois. >> >>> Hopefully as these can be identified, the space can be revoked and reallocated >>> to organizations that comply with policy. The original legacy holder has some >>> protections. A third party as a result of an unauthorized transfer should not have >>> any protections in this regard. >> >> Microsoft was the third party here. Addresses were transferred to Nortel from their acquisitions, the original legacy holders here. >> By your definitions, since ARIN was not involved, these transfers were unauthorized. > > Yep. > >> And yet a bankruptcy judge saw no problems with Microsoft buying them from Nortel. > > I agree that it is unfortunate that the bankruptcy judge did not see fit to consider the > community with greater weight. > >> I haven't stressed this, but the legal facts as I see them are that legacy holdings can be transferred without ARIN notice or needs requirements. > > As I see it, this remains unclear. Each of the cases so far has carefully not decided this > particular point. > >> By removing needs requirements for transfers, we bring policy in line with developing law, and this is sure to reduce future conflict. >> > I would rather preserve conflict and try to develop the law in a more useful direction. > I guess you can consider this part of my right to petition the government for redress of grievances. > Fair enough, but you have to accede the cost to ARIN of that possibility of conflict with the law when it comes to future legacy transactions. > I accept that ARIN must accept the judgment of the court no matter how flawed. Just as I accept that the current law effectively includes two seriously flawed supreme court rulings that established: 1. Money is a protected form of free speech. 2. Corporations are people entitled to the protections of the bill of rights. These two rulings combined essentially shifted us from capitalism to corporate socialism. >> >>> One of the problems relates to the requirement for a needs analysis. >> >>> No, the problem is the belief that community resources can be transferred outside >>> of community policy. >> >> For legacy addresses, these transfers have occurred in reality, it's time for belief to catch up. >> > As I said, as these blocks which are being used by entities other than their legitimate holders > are identified, ARIN should reclaim them and reissue the resources to organizations within the > policy process. > > That is reality. It is time for ARIN to start becoming more aggressive about identifying them > in my opinion. > > And we're back to FUD over section 12 processes for those seeking to bring addresses to the market. >> Huh? If you bring the addresses to the (legitimate) market, I'm all for reasonable safe-harbour positions to remove FUD. I want ARIN going after the recipients of invalid transfers, not the ones bringing addresses to the market. >>> If a holder of legacy space acquired through an asset sale approached ARIN to reflect that transfer, ARIN would not update whois without a needs analysis. >> >>> As it should be. >> >> You are arrogating needs requirements over whois accuracy by taking that stance. >> > No, I am taking the stance that the better way to ensure whois accuracy is by identifying > blocks being hijacked by organizations to which they were not issued and reclaiming them > and providing them to members of the community in compliance with policy. > There is no legal process for reclaiming legacy space. You would be wasting ARIN's time and treasure in the legacy area, and increasing FUD for existing holders seeking to sell. > I don't even think there is an ARIN process for recovering legacy space, except through voluntary donation from the holder. > As I said above, I think you misunderstand... Once the addresses are transferred outside of policy, they are no longer legacy addresses. The legacy status is tied to the original legacy holder who received them for a specific purpose from one of ARIN's predecessor registries. I don't want ARIN going after the suppliers... I want ARIN going after the recipients. In fact, I don't really want ARIN so much going after the recipients as removing the records from whois and in-addr.arpa and recycling the addresses to other organizations working through the legitimate process with justified needs. It would be up to the fraudulent transfer recipient to come after ARIN in that case. >> >>> In addition, the requirement for ARIN to do a needs analysis and the potential for review and recovery on either the buyer or seller increases the FUD factor in the market. >> >>> Only for those attempting to circumvent policies constructed by the consensus of the community. >> >> If I want to buy and the seller want to sell, and we have reached an agreement on price, then having to undergo an audit before we can process the sale, or being subject to one thereafter, is most certainly an added uncertainty. >> > So what. You're trying to trade in community resources that are held in the trust of the > community for a particular purpose. The community has a right to audit your use of them > and ensure that it is in compliance with the policies of the community. > > The presence of police on the highway adds an element of uncertainty to my ability > to drive at any speed I prefer. I don't necessarily see that as a bad thing, even though > it was very inconvenient on several occasions in my younger years. > > And the element of uncertainty slows your progress, correct? > Not really, no. >>> For a market to function efficiently, Fear, Uncertainty, and Doubt need to be assuaged, and this proposal does that. >>> >>> I have tremendous fear and uncertainty about the effects of this proposal. I doubt that it will function as >>> advertised. Indeed, I believe this proposal increases each of those things from my perspective. >> >> So you see how FUD works to prevent action. >> > More often, I see how it is used to provoke incorrect or counterproductive action, such as the PATRIOT > act. > > > >>> I copied liberally, almost entirely, from the APNIC policy to allow needs-free transfers. The rationale which was most effective in that regions's deliberations may have been the concern that by imposing the needs requirement, transactions would be more likely to occur outside the system, leading to a decay in whois reliability. >>> >>> That is the argument Geoff used which appears to have had sway in that region. >> >>> Geoff has repeatedly made that argument in the ARIN and RIPE regions (and I'm not sure >>> that he has not made it in LACNIC or AfriNIC as well). So far, it has not been found to be >>> convincing outside of APNIC. >> >>> By structuring my proposal in this way, I am trying to get people to consider whether the original and laudable needs requirement should be maintained when keeping it could lead to whois degradation. >> >>> This question has been asked and answered as part of the debate around 2008-2, its successor >>> 2008-15 (IIRC) and the boards reconstruction of that into 2009-1. You are welcome to ask the >>> question again, but, I'm not inclined to believe the answer has changed. >> >> Things have changed since then in terms of continued failure to transition and the MS/Nortel deal, and APNIC reaching exhaustion and approving their new transfer policy. >> > Uh, APNICs current transfer policy was in place prior to 2009-1. > > This page says February 2010, but even though it may have been in place, it was only activated as the exhaust phased in. > http://www.apnic.net/policy/proposals/prop-050 > Back in 2009, many people were still thinking/hoping the transition would take off, but now we have years more evidence to the contrary, which may change some minds. > I find this concept of "years since 2009" interesting. Please explain to me how you get from an event that occurred not more than 17 months ago to "years" in the same time scale. I think that APNIC amended their transfer policy, but, the base policy was, I believe, put in place prior to 2009-1. However, I suppose it is possible that APNIC didn't actually enact their policy and was talking about it. I know that the policy in a form substantially similar to its current form was definitely being discussed in the region well before we moved from 2008-2 to 2009-1. > If you're talking about their inter-regional > transfer policy, that's new, but it doesn't really support a removal of needs basis from the ARIN region. > If anything, it makes it even more vital. > > I don't see how the continued failure to transition differs from the expectations that were considered at the time we were debating 2009-1. > > Finally, I don't really see that the MS/Nortel deal changes anything other than indicating that we may have been insufficiently specific > with the restrictions expressed in 2009-1 (NRM 8.3) and might need to tighten the language so as to place better constraints on staff's action more > in line with intended policy. > > As I said, you are more than welcome to ask the question again. > >> >>> My argument is that proper stewardship recognizes the existence of a market which will fulfill the original stewarship role of ensuring efficient use, and we can direct our stewardship best to policies which help to ensure whois veracity. >> >>> My argument is that the market alone is not a good steward and a regulated market is necessary >>> to ensure the vital interests of the community. >> >> And I counter that the vital interest in address-use-efficiencies are better offloaded to the market, and the vital interest in maintaining whois veracity is retained. >> > > Yes, your argument that it is better entrusted to the market is precisely the point where I think we have the strongest disagreement. > > But what about whois? Don't we absolutely require a believable registry for the integrity of the whole Internet? There is a connection between needs requirements and whois reliability that drove the APNIC decision. > There is an allegation of a connection which remains unproven. > I would like to say that I will busy out of town this weekend, but this thread in particular has probably bored the readers to tears and they will be happy at my absence and their relatively empty inboxes. My plan is to take some of the proferred suggestions and resubmit a draft proposal on Monday for futher discussion. Have a nice weekend. > LoL... I'll also be mostly not on email this weekend, so, no worries. I'm happy to continue the debate in private if you believe that would be better. Owen -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill at herrin.us Sat May 7 03:22:37 2011 From: bill at herrin.us (William Herrin) Date: Sat, 7 May 2011 03:22:37 -0400 Subject: [arin-ppml] transfer conditions In-Reply-To: <391BFA8C-9D09-4BB2-8D49-FD5F9C6FDF93@arin.net> References: <75E9BD24-F12F-42BF-A989-CF6CC282B28E@arin.net> <7406316661701612155@unknownmsgid> <3F57F52B-F1F1-4450-B493-AA4D544D8D15@arin.net> <8740380157159276993@unknownmsgid> <49E26DCB-DAF7-4A0A-912E-F981494979F5@delong.com> <4DBC2AEB.9040307@matthew.at> <4DBCA58D.4060704@sprunk.org> <2344ADD7-616E-4FA7-9552-19735926A952@delong.com> <391BFA8C-9D09-4BB2-8D49-FD5F9C6FDF93@arin.net> Message-ID: On Fri, May 6, 2011 at 5:04 PM, John Curran wrote: > ? If an Org X has two blocks: a /16 (NETX16) and a /24 (NETX24), & they > ? approach ARIN and indicate that they want to transfer a /24 portion > ? of NETX16 to Org Y, ARIN should disallow it? ?Does that answer change > ? if NETX24 is in already heavily in use by Org B? ?What if NETX24 is > ? in use, and it's a part in an embedded system already in the field? > ? What if NETX24 is in use by another business unit than the one which > ? holds the NETX16? What if NETX24 continues to be justified under NRPM 4.5 Multiple Discrete Networks but Org X finds it can cost-effectively renumber out of part of NETX16? -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 7 09:25:20 2011 From: jcurran at arin.net (John Curran) Date: Sat, 7 May 2011 13:25:20 +0000 Subject: [arin-ppml] transfer conditions In-Reply-To: <6B951089-C686-4929-AC21-A1BF91BBBCB7@delong.com> References: <75E9BD24-F12F-42BF-A989-CF6CC282B28E@arin.net> <7406316661701612155@unknownmsgid> <3F57F52B-F1F1-4450-B493-AA4D544D8D15@arin.net> <8740380157159276993@unknownmsgid> <49E26DCB-DAF7-4A0A-912E-F981494979F5@delong.com> <4DBC2AEB.9040307@matthew.at> <4DBCA58D.4060704@sprunk.org> <2344ADD7-616E-4FA7-9552-19735926A952@delong.com> <391BFA8C-9D09-4BB2-8D49-FD5F9C6FDF93@arin.net> <6B951089-C686-4929-AC21-A1BF91BBBCB7@delong.com> Message-ID: On May 7, 2011, at 1:40 AM, Owen DeLong wrote: >> If an Org X has two blocks: a /16 (NETX16) and a /24 (NETX24), & they >> approach ARIN and indicate that they want to transfer a /24 portion >> of NETX16 to Org Y, ARIN should disallow it? Does that answer change >> if NETX24 is in already heavily in use by Org B? What if NETX24 is >> in use, and it's a part in an embedded system already in the field? >> What if NETX24 is in use by another business unit than the one which >> holds the NETX16? >> > Ideally: > > Yes... No... No... No. > > Realistically, probably hard to enforce beyond: > > No... No... No... No. If the goal is prevent excessive deaggregation, perhaps a simpler constraint could be easier to enforce and still provide much of the benefit? For example, an absolute minimum block size of /24 for transfers wouldn't discourage reutilization of address space, is unlikely to get in the way of any parties that independently make arrangements and then learn of the policies, but certainly would dramatically reduce the potential for directly transfer induced deaggregation. I have no preference for any particular mechanism, but ask that folks consider that many of the parties appearing before ARIN with transfers will already have selected the relevant blocks being transferred, and to the extent that any policy constraints are simple and easy to understand, it is far more likely that transferring parties will be already be aware of them and taken them into consideration in their efforts. Thanks! /John John Curran President and CEO ARIN From mysidia at gmail.com Sat May 7 17:34:31 2011 From: mysidia at gmail.com (Jimmy Hess) Date: Sat, 7 May 2011 16:34:31 -0500 Subject: [arin-ppml] transfer conditions In-Reply-To: References: <75E9BD24-F12F-42BF-A989-CF6CC282B28E@arin.net> <7406316661701612155@unknownmsgid> <3F57F52B-F1F1-4450-B493-AA4D544D8D15@arin.net> <8740380157159276993@unknownmsgid> <49E26DCB-DAF7-4A0A-912E-F981494979F5@delong.com> <4DBC2AEB.9040307@matthew.at> <4DBCA58D.4060704@sprunk.org> <2344ADD7-616E-4FA7-9552-19735926A952@delong.com> <391BFA8C-9D09-4BB2-8D49-FD5F9C6FDF93@arin.net> <6B951089-C686-4929-AC21-A1BF91BBBCB7@delong.com> Message-ID: On Sat, May 7, 2011 at 8:25 AM, John Curran wrote: > On May 7, 2011, at 1:40 AM, Owen DeLong wrote: > If the goal is prevent excessive deaggregation, perhaps a simpler > constraint could be easier to enforce and still provide much of > the benefit? ?For example, an absolute minimum block size of /24 > for transfers wouldn't discourage reutilization of address space, Perhaps it's not necessary. Are holders of IPs going to seek to transfer longer prefixes than /24; knowing full and well, many providers are going to filter/discard any announcements for /25 and longer prefixes? I would suggest transfer makers and recipients give a warning "Transferred IP address blocks may have reduced routability." In addition, the status of a 8.3 transferred block should be indicated in WHOIS as Transferred; and WHOIS should clearly show what the original block was. To indicate very clearly; if you transfer out a /24 out of a block from which only /22s were allocated; your prefix might not be propagated, because your prefix is longer than the minimum allocation for that block. -- -JH From joelja at bogus.com Sat May 7 14:09:17 2011 From: joelja at bogus.com (Joel Jaeggli) Date: Sat, 07 May 2011 11:09:17 -0700 Subject: [arin-ppml] ARIN-2011-6: Returned IPv4 Addresses - Last Call In-Reply-To: References: <4DAC8BE4.9060002@arin.net> <003601cc00a2$e46afae0$ad40f0a0$@iname.com> <5746281551269279304@unknownmsgid> Message-ID: <4DC58ACD.8050005@bogus.com> On 4/22/11 11:34 AM, William Herrin wrote: > I think it's right that we start creating frameworks by which > addresses can move between regions or even pool up and become > available for IETF designation via RFC. Have we considered that? The > IETF doesn't have a way to get addresses to facilitate new > technologies either, and that hurts us all. The IETF directs IANA to assign resources through the vehicle of an RFC. If the assertion is there's no global unicast prefix out of which the IETF can assign new addressing resources, then that's probably as it should be. there's always 240/4 if you can scope the application to something that does not rely on hosts being able to route it. From jcurran at arin.net Sat May 7 20:20:30 2011 From: jcurran at arin.net (John Curran) Date: Sun, 8 May 2011 00:20:30 +0000 Subject: [arin-ppml] transfer conditions In-Reply-To: References: <75E9BD24-F12F-42BF-A989-CF6CC282B28E@arin.net> <7406316661701612155@unknownmsgid> <3F57F52B-F1F1-4450-B493-AA4D544D8D15@arin.net> <8740380157159276993@unknownmsgid> <49E26DCB-DAF7-4A0A-912E-F981494979F5@delong.com> <4DBC2AEB.9040307@matthew.at> <4DBCA58D.4060704@sprunk.org> <2344ADD7-616E-4FA7-9552-19735926A952@delong.com> <391BFA8C-9D09-4BB2-8D49-FD5F9C6FDF93@arin.net> <6B951089-C686-4929-AC21-A1BF91BBBCB7@delong.com> Message-ID: <22A6B158-1CBC-4C35-A842-0BD029B2461C@arin.net> On May 7, 2011, at 5:34 PM, Jimmy Hess wrote: > On Sat, May 7, 2011 at 8:25 AM, John Curran wrote: >> On May 7, 2011, at 1:40 AM, Owen DeLong wrote: >> If the goal is prevent excessive deaggregation, perhaps a simpler >> constraint could be easier to enforce and still provide much of >> the benefit? For example, an absolute minimum block size of /24 >> for transfers wouldn't discourage reutilization of address space, > > Perhaps it's not necessary. Are holders of IPs going to seek to transfer > longer prefixes than /24; knowing full and well, many providers are > going to filter/discard any announcements for /25 and longer prefixes? Many of holders of IP addresses (as well as those who will be attempting to broker same) have no idea about provider routing or filtering, and if they can find parties willing to accept /30's, then they will break down blocks accordingly in the absence of clear guidance to the contrary. My only point is that to the extent that the policies are straightforward, the more easily they are propagated and the higher probably of them being followed in advance. Simplicity is highly desirable because we're going to see lots of address holders who have not ever interacted with the IP registry system have to do so for their first time, and there is a big difference in readability between "Transfers must be of block size N or larger" versus the "Transfers shall only be of a block size which is that which would have been approved for RIR issuance per the minimum block sizes as listed in address allocation policies NRPM 4.2.1, 4.3.2, or 4.9" ARIN will implement whatever policies the community develops, but it should be noted that the transfer policy is likely to be referenced by thousands of parties who up to this point have been unaware of the workings of ISP routing (and potentially unaware of the Internet number registry system for that matter) It would be good to keep this in mind when considering transfer policy proposals. FYI, /John John Curran President and CEO ARIN From bill at herrin.us Sat May 7 20:40:57 2011 From: bill at herrin.us (William Herrin) Date: Sat, 7 May 2011 20:40:57 -0400 Subject: [arin-ppml] transfer conditions In-Reply-To: References: <75E9BD24-F12F-42BF-A989-CF6CC282B28E@arin.net> <7406316661701612155@unknownmsgid> <3F57F52B-F1F1-4450-B493-AA4D544D8D15@arin.net> <8740380157159276993@unknownmsgid> <49E26DCB-DAF7-4A0A-912E-F981494979F5@delong.com> <4DBC2AEB.9040307@matthew.at> <4DBCA58D.4060704@sprunk.org> <2344ADD7-616E-4FA7-9552-19735926A952@delong.com> <391BFA8C-9D09-4BB2-8D49-FD5F9C6FDF93@arin.net> <6B951089-C686-4929-AC21-A1BF91BBBCB7@delong.com> Message-ID: On Sat, May 7, 2011 at 9:25 AM, John Curran wrote: > If the goal is prevent excessive deaggregation, perhaps a simpler > constraint could be easier to enforce and still provide much of > the benefit? Something like... Under NRPM 8, ARIN shall not accept a transfer request: a. for an IPv4 CIDR address registration containing fewer than 256 addresses. b. which would transfer two or more disaggregate pieces of a single, larger aggregate IPv4 address registration c. which would disaggregate a CIDR-aligned IPv4 address registration less than one year after said aggregate was first registered in that exact size. a. Nothing smaller than /24 b. If you break up a block and transfer part of it, you can only transfer *one* part of it. c. Can't get around B by doing multiple rapid transfers. Thoughts? -Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From rbf+arin-ppml at panix.com Sat May 7 21:27:58 2011 From: rbf+arin-ppml at panix.com (Brett Frankenberger) Date: Sat, 7 May 2011 20:27:58 -0500 Subject: [arin-ppml] transfer conditions In-Reply-To: References: <4DBC2AEB.9040307@matthew.at> <4DBCA58D.4060704@sprunk.org> <2344ADD7-616E-4FA7-9552-19735926A952@delong.com> <391BFA8C-9D09-4BB2-8D49-FD5F9C6FDF93@arin.net> <6B951089-C686-4929-AC21-A1BF91BBBCB7@delong.com> Message-ID: <20110508012758.GA26751@panix.com> On Sat, May 07, 2011 at 08:40:57PM -0400, William Herrin wrote: > > Something like... Under NRPM 8, ARIN shall not accept a transfer request: > > a. for an IPv4 CIDR address registration containing fewer than 256 addresses. > b. which would transfer two or more disaggregate pieces of a single, > larger aggregate IPv4 address registration > c. which would disaggregate a CIDR-aligned IPv4 address registration > less than one year after said aggregate was first registered in that > exact size. > > a. Nothing smaller than /24 > b. If you break up a block and transfer part of it, you can only > transfer *one* part of it. > c. Can't get around B by doing multiple rapid transfers. > > Thoughts? Org. A has a /18 that it isn't using. Org. B needs a /19; Org. A transfers half of its /18. 6 months later, Org. C needs a /20. Org. A would like to transfer half of its remaining /19, but can't because of requirement (c) above. In other words, (c) has impacts beyond preventing organizations from trying to get around (b) by doing multiple transfers. Getting to where I think you headed is doable, but the language is going to be a lot more complex. John's point about keeping it simple because of all the new players is valid, but there's a certain amount of complexity that is unavoidable. The goal is probably something like: When an aggregate is split to effect a transfer, it shall be split into the smallest number of smallest aggregates possible to effect the transfer. Once that occurs, for a period of one year, none of the resulting smaller aggregates shall be further split to effect a transfer, except that to effect a transfer of an aggregate smaller than the smallest resulting aggregate still remaining with the holder of the original aggregate, the holder of the original aggregate may further split the smallest aggregate that he still holds (and such split shall be into the smallest number of smaller aggregates possible to effect the transfer). So if Org. A splits a /19 to transfer a /22, Org. A will be left with a /20, a /21, and a /22. For the next year, Org. A can then transfer the /20, the /21, or the /22, or can further split the /22 to transfer a /23 or a /24. If Org. A transferred the /22, it would then be allowed to split the /21 to transfer a /22, /23, or /24. And so on. After one year from the original split, Org. A would be allowed to split the /20, the /21, or the /22, to effect a transfer. Except, no, it needs to be more complicated than what I wrote above. If Org. A splits a /19 to tranfer a /22, and then later transfers a /21, it will be left with a /20 and a /22. At that point, we'd probably want them to be able to split the /20 to transfer a /21, but my language above would prevent that. So maybe replace ... except that to effect a transfer of an aggregate smaller than the smallest resulting aggregate still remaining with the holder of the original aggregate, the holder of the original aggregate may further split the smallest aggregate that he still holds ... with ... except that to effect a transfer of an aggregate of a size not existing in the resulting aggregates still remaining with the holder of the original aggregate, the holder of the original aggregate may further split the smallest remaining aggregate the he still holds that is larger than size of the aggregate to be transferred ... (Anyone wondering why the tax code is complicated should read this thread. Some of the complexity comes from political gamesmanship, but lots of it comes from the fact that defining income is fundamentally difficult. Same goes for this policy. We're going to have to accept a policy with a lot of loopholes or unintended restrictions, or it's goign to be a wordy, complicated policy.) -- Brett From matthew at matthew.at Sun May 8 00:02:27 2011 From: matthew at matthew.at (Matthew Kaufman) Date: Sat, 7 May 2011 21:02:27 -0700 Subject: [arin-ppml] transfer conditions In-Reply-To: References: <75E9BD24-F12F-42BF-A989-CF6CC282B28E@arin.net> <7406316661701612155@unknownmsgid> <3F57F52B-F1F1-4450-B493-AA4D544D8D15@arin.net> <8740380157159276993@unknownmsgid> <49E26DCB-DAF7-4A0A-912E-F981494979F5@delong.com> <4DBC2AEB.9040307@matthew.at> <4DBCA58D.4060704@sprunk.org> <2344ADD7-616E-4FA7-9552-19735926A952@delong.com> <391BFA8C-9D09-4BB2-8D49-FD5F9C6FDF93@arin.net> <6B951089-C686-4929-AC21-A1BF91BBBCB7@delong.com> Message-ID: On May 7, 2011, at 5:40 PM, William Herrin wrote: > On Sat, May 7, 2011 at 9:25 AM, John Curran wrote: >> If the goal is prevent excessive deaggregation, perhaps a simpler >> constraint could be easier to enforce and still provide much of >> the benefit? > > Something like... Under NRPM 8, ARIN shall not accept a transfer request: > > a. for an IPv4 CIDR address registration containing fewer than 256 addresses. > b. which would transfer two or more disaggregate pieces of a single, > larger aggregate IPv4 address registration Do you mean: "...which would transfer two or more disaggregate pieces of a single larger aggregate as a single transfer" (which could be worked around by doing multiple serial transfers) "...which would transfer two or more disaggregate pieces of a single larger aggregate from one party to another" (which fixes the above loophole, but which means that I can't sell you one /24 now and a /23 in 6 months when you can show need for that because of your growth) or something else? Matthew Kaufman ps. I assume that we all understand that *all* address blocks (save 0.0.0.0/0) are pieces of a single larger aggregate, and you don't mean to prohibit a transfer of one /22 and another /22 that are all the seller holds, even these are not adjacent, to the same buyer From matthew at matthew.at Sun May 8 00:04:24 2011 From: matthew at matthew.at (Matthew Kaufman) Date: Sat, 7 May 2011 21:04:24 -0700 Subject: [arin-ppml] transfer conditions In-Reply-To: <22A6B158-1CBC-4C35-A842-0BD029B2461C@arin.net> References: <75E9BD24-F12F-42BF-A989-CF6CC282B28E@arin.net> <7406316661701612155@unknownmsgid> <3F57F52B-F1F1-4450-B493-AA4D544D8D15@arin.net> <8740380157159276993@unknownmsgid> <49E26DCB-DAF7-4A0A-912E-F981494979F5@delong.com> <4DBC2AEB.9040307@matthew.at> <4DBCA58D.4060704@sprunk.org> <2344ADD7-616E-4FA7-9552-19735926A952@delong.com> <391BFA8C-9D09-4BB2-8D49-FD5F9C6FDF93@arin.net> <6B951089-C686-4929-AC21-A1BF91BBBCB7@delong.com> <22A6B158-1CBC-4C35-A842-0BD029B2461C@arin.net> Message-ID: <9CDB0040-AFFD-4A90-94D9-821003EE5B8F@matthew.at> On May 7, 2011, at 5:20 PM, John Curran wrote: > On May 7, 2011, at 5:34 PM, Jimmy Hess wrote: > >> On Sat, May 7, 2011 at 8:25 AM, John Curran wrote: >>> On May 7, 2011, at 1:40 AM, Owen DeLong wrote: >>> If the goal is prevent excessive deaggregation, perhaps a simpler >>> constraint could be easier to enforce and still provide much of >>> the benefit? For example, an absolute minimum block size of /24 >>> for transfers wouldn't discourage reutilization of address space, >> >> Perhaps it's not necessary. Are holders of IPs going to seek to transfer >> longer prefixes than /24; knowing full and well, many providers are >> going to filter/discard any announcements for /25 and longer prefixes? > > Many of holders of IP addresses (as well as those who will be attempting > to broker same) have no idea about provider routing or filtering, and if > they can find parties willing to accept /30's, then they will break down > blocks accordingly in the absence of clear guidance to the contrary. > > My only point is that to the extent that the policies are straightforward, > the more easily they are propagated and the higher probably of them being > followed in advance. Why don't we just start by disallowing all transfers smaller than, say, /19... and then adjusting that downward (in block size... upward in mask length) as the market shows that it can't function with the simultaneous combination of needs-justification-requirements and minimum-block/aggregate-sizes? Matthew Kaufman From mysidia at gmail.com Sun May 8 13:48:49 2011 From: mysidia at gmail.com (Jimmy Hess) Date: Sun, 8 May 2011 12:48:49 -0500 Subject: [arin-ppml] transfer conditions In-Reply-To: <9CDB0040-AFFD-4A90-94D9-821003EE5B8F@matthew.at> References: <75E9BD24-F12F-42BF-A989-CF6CC282B28E@arin.net> <7406316661701612155@unknownmsgid> <3F57F52B-F1F1-4450-B493-AA4D544D8D15@arin.net> <8740380157159276993@unknownmsgid> <49E26DCB-DAF7-4A0A-912E-F981494979F5@delong.com> <4DBC2AEB.9040307@matthew.at> <4DBCA58D.4060704@sprunk.org> <2344ADD7-616E-4FA7-9552-19735926A952@delong.com> <391BFA8C-9D09-4BB2-8D49-FD5F9C6FDF93@arin.net> <6B951089-C686-4929-AC21-A1BF91BBBCB7@delong.com> <22A6B158-1CBC-4C35-A842-0BD029B2461C@arin.net> <9CDB0040-AFFD-4A90-94D9-821003EE5B8F@matthew.at> Message-ID: On Sat, May 7, 2011 at 11:04 PM, Matthew Kaufman wrote: > Why don't we just start by disallowing all transfers smaller than, say, /19... and then adjusting that downward (in block size... upward in mask length) as the market shows that it can't function with the simultaneous combination of needs-justification-requirements and minimum-block/aggregate-sizes? Why don't we start by disallowing all transfers smaller than the minimum allocation size for the block? And use /22 as the minimum allocation size for any legacy block of which /16s were assigned' /20 as the minimum allocation size for any legacy block of size /8 or shorter were assigned? ARIN allocates prefixes longer than /19, so /19 restriction seems a bit much -- -JH From mysidia at gmail.com Sun May 8 13:57:39 2011 From: mysidia at gmail.com (Jimmy Hess) Date: Sun, 8 May 2011 12:57:39 -0500 Subject: [arin-ppml] ARIN-2011-6: Returned IPv4 Addresses - Last Call In-Reply-To: <4DC58ACD.8050005@bogus.com> References: <4DAC8BE4.9060002@arin.net> <003601cc00a2$e46afae0$ad40f0a0$@iname.com> <5746281551269279304@unknownmsgid> <4DC58ACD.8050005@bogus.com> Message-ID: On Sat, May 7, 2011 at 1:09 PM, Joel Jaeggli wrote: > On 4/22/11 11:34 AM, William Herrin wrote: > >> I think it's right that we start creating frameworks by which >> addresses can move between regions or even pool up and become >> available for IETF designation via RFC. Have we considered that? The >> IETF doesn't have a way to get addresses to facilitate new >> technologies either, and that hurts us all. When was the last time the IETF was working on an IPv4 technology that required IPv4 addresses? The IETF has plenty of IP addresses available in 240/4, that the IETF has not (yet at least) indicated any specific purpose for, they are just reserved for the IETF to do something with. I'd much rather see the IETF working on IPv6-based technologies. -- -JH From joelja at bogus.com Sun May 8 14:40:06 2011 From: joelja at bogus.com (Joel Jaeggli) Date: Sun, 08 May 2011 11:40:06 -0700 Subject: [arin-ppml] Hijackings In-Reply-To: <64100.1304017670@tristatelogic.com> References: <64100.1304017670@tristatelogic.com> Message-ID: <4DC6E386.3030405@bogus.com> On 4/28/11 12:07 PM, Ronald F. Guilmette wrote: > In message <9511.1304008691 at marajade.sandelman.ca>, >> Closed, meaning it won't send email outside of it (except, perhaps to >> other RIRs systems). If you aren't a POC, then you have no business >> talking to other POCs, to keep out the spam. This would be a small >> admission that Internet email via MX is dead (and I hate that idea), but >> it would make life easier. > > You comments assume that spam is what causes contact e-mail addresses > to be virtually or actually aliases to /dev/null. > > That may be true in some cases, but my guess is that in the vast majority > of cases POCcontact at some.place.tld isn't going to any live humans simply > because the bean counters and the Golden Slacks types have taken over > the world, and reading POC e-mail has been determined not to represent a > profit center, and that thus, dealing with that e-mail has been pushed down > to the lowest level of the work priority queue. Realistically, if you don't notice a prefix of yours being hijacked (and advertised) for the purpose of sending spam it's unlikely that prefix has much in the way of operational significance to your organization. If the prefix has gone dark and the contacts are stale is that surprising under the circumstances? > Regards, > rfg > _______________________________________________ > 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 gawul00 at gmail.com Fri May 6 14:00:12 2011 From: gawul00 at gmail.com (Andy Koch) Date: Fri, 6 May 2011 13:00:12 -0500 Subject: [arin-ppml] Draft proposal that needs some wordsmithing In-Reply-To: <28AA88B965034F1097AA0B6746409DEC@mike> References: <4DC422A2.6030908@globis.net> <28AA88B965034F1097AA0B6746409DEC@mike> Message-ID: On Friday, May 6, 2011, Mike Burns wrote: > Why the market would work to bring addresses into productive use, is that people are motivated by personal self-interest. > So a person (organization, entity) who had addresses which were dis- or under-used would be motivated by the money he could get by selling the addresses. > The buyer of addresses would be establishing, through his willingness to part with money for them, that he thought he could profit by having them. > If the buyer is putting these addresses to some use which is profitable to him, they will have moved from disuse to use through the operations, in a free market, of people motivated by their own self interest. > These are the basic forces at action, and I think these would be the basic transactions of the ip address transfer market. > > Yes, a speculator or hoarder could purchase addresses and not put them to use, but he would only do that if he thought he could profit by selling them later, or profit in some other way. > A speculator or hoarder (or any other buyer) could also lose money if he is unable to profit from his acquisition for whatever reason. While a market does bring the benefit of an address holder becoming more efficient in their use of addresses due to potential gains for freeing space, I do not see where the removal of needs justification further enhances this market. Even with our current policies in-place, including justification, a market is developing that will meet this enhanced efficiency. > My argument is that retaining needs analysis to approve transfers is no longer required to ensure efficiency, and maintaining it can cause transactions to go off-books, to the detriment of all. True, needs justification is no longer necessary to improve efficiency. However, it does prevent price inflation due to speculation and hoarding. As such, I do not support removing needs justification from policy. Andrew Koch andrew.koch at gmail.com From warren at wholesaleinternet.net Fri May 6 15:10:23 2011 From: warren at wholesaleinternet.net (Warren Johnson) Date: Fri, 6 May 2011 14:10:23 -0500 Subject: [arin-ppml] ARIN-prop-146 Clarify Justified Need for Transfers In-Reply-To: <61AAC8E6-F419-4792-95DB-2D5CE485580D@delong.com> References: <4DBEF120.4080901@arin.net> <88F39B20-5C20-45F0-AD61-5FA1E7F84CE3@delong.com> <4DBF6727.1090303@matthew.at> <097AAC1C-1F68-4820-9274-3290ADEFA195@delong.com> <9501EA7E-FDAD-4DDA-B9E8-08C2811FF642@delong.com> <4DBF82F6.7050608@matthew.at> <20110503145144.N15967@mail.inlandnet.com> <4DC084E7.5000302@matthew.at> <4DC08664.4060905@matthew.at> <4791A59E-8864-483C-9BB0-03A6A5B8D50C@delong.com> <66466F57-4365-4ADB-94EB-E023F01B17CB@delong.com> <30D12BA8-9A6C-4E62-9A67-8B4FEA0EA8C1@matthew.at> <00af01cc0aa7$845a5330$8d0ef990$@net> <8695009A81378E48879980039EEDAD289D0E5BD9@MAIL1.polartel.local> <5542F2FC72CC4995A4205A4C1C844F5E@mike> <0492060B-A00F-4C1E-9722-90F6A00ABD94@arin.net> <61A AC8E6-F419-4792-95DB-2D5CE485580D@delong.com> Message-ID: <0a9601cc0c21$40f390e0$c2dab2a0$@net> Regardless of policy, this can be achieved by purchasing a controlling share in the organization that already holds the resource and altering its operation. > >What if you need a /18, but, know that by purchasing the equivalent >of a /6, you can cause significantly larger additional costs to your >competitors, possibly even pricing some of them out of the market? >You have the cash to do it, should this be allowed? > > (Hint... I think some of your competitors can afford that /6 to keep you >from getting your /18). > >Owen -------------- next part -------------- A non-text attachment was scrubbed... Name: winmail.dat Type: application/ms-tnef Size: 2270 bytes Desc: not available URL: From mike at nationwideinc.com Mon May 9 15:15:06 2011 From: mike at nationwideinc.com (Mike Burns) Date: Mon, 9 May 2011 15:15:06 -0400 Subject: [arin-ppml] Draft Proposal for Needs-Free IPv4 Transfers Message-ID: <323AD9AC0BE24F9BB91D3E712160681A@mike> Hello, Upon feedback to my first draft proposal whose intent is to lift needs requirements for all IPv4 transfers, I have made some changes to my draft proposal. One of the issues was the idea that if I made no changes to section 12, that ARIN could do a resource review of the transferree and if they determined the addresses were not being used, could request them to be returned. I have read section 12 of the NRPM, and could find no language that gives ARIN that right. Basically section 12 is about fraud and about compliance with existing policy, but there is no existing policy that I could find requiring anything like efficient utilization of allocations, except in reference to a new or subsequent allocation. But once an allocation is made, I could find no policy requiring efficient utilization of that block if no further allocation request is made. On the other hand, the current RSA has clear language in section 8 that allows ARIN to review previous allocations and allows ARIN to determine if their use is consistent with the intended purpose as presented on the application at the time of the allocation request: 8. REVIEW OF APPLICANT'S NUMBER RESOURCES ARIN may review, at any time, Applicant's use of previously allocated or assigned number resources or Services received from ARIN to determine if Applicant is complying with this Agreement and the Policies and is using the Services for their intended purposes. Without limiting the foregoing, if Applicant is a holder of a direct allocation or assignment from ARIN, Applicant agrees that it will use the number resources solely for uses consistent with its application and this Agreement, including, for example, its internal infrastructure or to provide Internet access to its customer base. If ARIN determines that the number resources or any other Services are not being used in compliance with this Agreement, the Policies, or the purposes for which they are intended, ARIN may: (i) revoke the number resources; (ii) cease providing the Services to Applicant; and/or (iii) terminate this Agreement. (To my reading, if you got an allocation in 2001 for web hosting purposes, and now you are using the addresses to provide DSL service, ARIN could revoke them for not being used for purposes consistent with the Applicant's application unless you notify them and get approval. But let's leave that aside.) Since my overarching purpose is to bring as much supply into the market as possible, I don't want any old allocations to stay unused on the shelf because the holder is afraid of a recovery action. But if section 12 does not allow ARIN to make a resource finding requesting return of addresses merely for underutilization, and if we remove the language in the RSA allowing ARIN to recover based on compliance with intended use, then an entity could totally fake a justification and get a new allocation today, and turn around tomorrow and list the addreses for sale, and ARIN wouldn't have any teeth with which to revoke the addresses. (Unless of course they could show the justification part of the application was fraudulent.) In order to preclude that, I have added a new source requirement to the source entity for transfers, that they may not have received an ARIN allocation for at least 12 months prior to the transfer. In addition, in my new draft proposal I retained the 8.2 transfer mechanism, which can still be used for ASN and IPv6 transfers via mergers and acquisitions. I also added language forcing no downgrading of current agreement status which covers the transferred addresses, i.e. RSA to RSA, LRSA to LRSA or RSA, no agreement to no agreement or LRSA. In my rationale, I have limited myself to the benefits of whois accuracy which will inure from the greater likelihood that all past and future transfers will be registered. >From the discussion, you know that I believe that stewardship demands that we make policy to ensure whois reliablity in the face of a new paradigm for IPv4 distribution. IPv4 addresses will change hands in a variety of transaction types. If those who engage in these transactions do not choose to have ARIN update whois to reflect them, we run the risk of whois irrelevance and provide the vacuum in to which competitive registries will step, with or without global community authority. If transactors find little cost in having ARIN update whois to reflect the transfer, they are more likely to request that ARIN make the update. If the transaction cost is high, fewer will make that request, leading to a less and less reliable whois, which could degrade to the point where network operators choose a more reliable registry. This kind of chaos in the core of the Internet would be an indictment of ARIN stewardship. We will run out of free pool addresses shortly. At that point we will not be stewards of those addresses anymore. We will, however, retain our stewardship role towards maintaining whois as an authoritative source for routing authority. Prior to exhaust, it was possible to ignore whois, as conflicts over address control were unlikely when "free" addresses were available. In the post-exahaust world, where address control conflict is likely to increase, it is all the more important that whois be a trusted and accurate information source. Now it could be that I have misread section 12, I know I heard from more than one person that ARIN could revoke for underutilization. If you can point me to what I am missing, then maybe I will have to monkey with section 12. My hope is that by simply changing 8.3 and the RSA I can avoid that. I agree with John Curran's posting this week about simplifying transfer requirements, and have retained the /24 minimum for the reasons he mentioned. Regards, Mike Burns 1. Policy Proposal Name: New IPv4 Transfer policy 2. Proposal Originator: a. Name: Mike Burns b. Email: mike at sum.net c. Phone: 1-863-494-7692 x105 d. Organization: Nationwide Computer Systems 3. Proposal Version: 1 4. Date: May 9th, 2011 5. Proposal type: modify 6. Policy term: permanent 7. Policy statement: Replace Section 8.3 with 8.3 ARIN will process and record IPv4 address transfer requests. Conditions on the IPv4 address block: - The minimum transfer size is a /24 - The address block must be in the range of addresses administered by ARIN Conditions on source of the transfer: - The source entity must be the current rights 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 the transfer, or until the exhaustion of ARIN's IPv4 space, whichever occurs first. - The source entity must not have received an allocation from ARIN for the 12 months prior to the transfer. Conditions on recipient of the transfer: - The recipient entity must be a current ARIN account holder. If the addresses being transferred are under RSA, the recipient must sign an RSA with ARIN. If the addresses being transferred are under LRSA, the recipient must sign an LRSA or an RSA with ARIN. If the addresses being transferred are legacy addresses under no form of RSA, recipient may choose to sign an LRSA, but will not be required to do so. - The recipient entity of the transferred resources will be subject to current ARIN policies. In particular, in any subsequent ARIN IPv4 address allocation request, the recipient will be required to account for the efficient utilization of all IPv4 address space held, including all transferred resources. and modify section 12.8 of the current RSA to remove references to "intended purposes." Replace ARIN may review, at any time, Applicant's use of previously allocated or assigned number resources or Services received from ARIN to determine if Applicant is complying with this Agreement and the Policies and is using the Services for their intended purposes. Without limiting the foregoing, if Applicant is a holder of a direct allocation or assignment from ARIN, Applicant agrees that it will use the number resources solely for uses consistent with its application and this Agreement, including, for example, its internal infrastructure or to provide Internet access to its customer base. If ARIN determines that the number resources or any other Services are not being used in compliance with this Agreement, the Policies, or the purposes for which they are intended, ARIN may: (i) revoke the number resources; (ii) cease providing the Services to Applicant; and/or (iii) terminate this Agreement. with ARIN may review, at any time, any Applicant's use of previously allocated or assigned number resources or Services received from ARIN to determine if Applicant is complying with this Agreement and the Policies. Without limiting the foregoing, if Applicant is a holder of a direct allocation or direct assignment from ARIN, Applicant agrees that it will use the number resources solely for uses consistent with this Agreement, including, for example, its internal infrastructure or to provide Internet access to its customer base. If ARIN determines that the number resources or any other Services are not being used in compliance with this Agreement or the Policies, ARIN may: (i) revoke the number resources; (ii) cease providing the Services to Applicant; and/or (iii) terminate this Agreement. 8. Rationale: Current ARIN policies relating to the registration of transfer of address holdings limit the eligibility of registration of transfers to those relating to mergers and acquisitions of entities that are administering an operational network, or to those who agree to sign either an RSA or LRSA with ARIN and subject the buyer to needs analysis and the seller to a potential ARIN review under RSA section 8. It is currently anticipated that the IPv4 unallocated address pool will be exhausted within a couple of years at ARIN, and earlier than that in other regions, and the transition to IPv6-based service delivery is likely to take longer than the remaining period of unallocated address availability. Accordingly, it is likely that demand for IPv4 addresses will continue beyond the time of unallocated address pool exhaustion, leading to a period of movement of IPv4 address blocks between address holders to meet such continuing demand for IPv4 address blocks. The underlying proposition behind this policy proposal is that the registry of IPv4 addresses operated by ARIN is of general utility and value only while it accurately describes the current state of address distribution. If a class of address movement transactions are excluded from being entered in the registry, then the registry will have decreasing value to the broader community, and the integrity of the network itself is thereby compromised. This proposal's central aim is to ensure the continuing utility and value of the ARIN address registry by allowing the registry to record transactions where IPv4 addresses are transfered between ARIN account holders. It proposes that ARIN will recognise and register a transfer of addresses where the parties to the transfer are 'known' to ARIN and that the address block being transferred is part of ARIN's current address set. The proposal does not prescribe how such transfers may occur, nor impose any further constraints on the transfer or on the parties involved other than those described in this proposal. 9. Timetable for implementation: immediate. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rudi.daniel at gmail.com Mon May 9 16:04:37 2011 From: rudi.daniel at gmail.com (Rudolph Daniel) Date: Mon, 9 May 2011 16:04:37 -0400 Subject: [arin-ppml] New IPv4 Transfer policy Message-ID: I may have missed something here, but why is it not possible to dump LSRA and have all transfers..whether LSRA, RSA. or neither...become a mandatory RSA signing on transfer ? with a note to the effect: "Note that ARIN will not reclaim unutilized v4 address space from legacy holders. RD > > Date: Mon, 9 May 2011 15:15:06 -0400 > From: "Mike Burns" > > Hello, > > Upon feedback to my first draft proposal whose intent is to lift needs > requirements for all IPv4 transfers, I have made some changes to my draft > proposal. > > One of the issues was the idea that if I made no changes to section 12, > that ARIN could do a resource review of the transferree and if they > determined the addresses were not being used, could request them to be > returned. > > I have read section 12 of the NRPM, and could find no language that gives > ARIN that right. Basically section 12 is about fraud and about compliance > with existing policy, but there is no existing policy that I could find > requiring anything like efficient utilization of allocations, except in > reference to a new or subsequent allocation. But once an allocation is made, > I could find no policy requiring efficient utilization of that block if no > further allocation request is made. > > On the other hand, the current RSA has clear language in section 8 that > allows ARIN to review previous allocations and allows ARIN to determine if > their use is consistent with the intended purpose as presented on the > application at the time of the allocation request: > > 8. REVIEW OF APPLICANT'S NUMBER RESOURCES > ARIN may review, at any time, Applicant's use of previously allocated or > assigned number resources or Services received from ARIN to determine if > Applicant is complying with this Agreement and the Policies and is using the > Services for their intended purposes. Without limiting the foregoing, if > Applicant is a holder of a direct allocation or assignment from ARIN, > Applicant agrees that it will use the number resources solely for uses > consistent with its application and this Agreement, including, for example, > its internal infrastructure or to provide Internet access to its customer > base. If ARIN determines that the number resources or any other Services are > not being used in compliance with this Agreement, the Policies, or the > purposes for which they are intended, ARIN may: (i) revoke the number > resources; (ii) cease providing the Services to Applicant; and/or (iii) > terminate this Agreement. > > (To my reading, if you got an allocation in 2001 for web hosting purposes, > and now you are using the addresses to provide DSL service, ARIN could > revoke them for not being used for purposes consistent with the Applicant's > application unless you notify them and get approval. But let's leave that > aside.) > > Since my overarching purpose is to bring as much supply into the market as > possible, I don't want any old allocations to stay unused on the shelf > because the holder is afraid of a recovery action. > > But if section 12 does not allow ARIN to make a resource finding requesting > return of addresses merely for underutilization, and if we remove the > language in the RSA allowing ARIN to recover based on compliance with > intended use, then an entity could totally fake a justification and get a > new allocation today, and turn around tomorrow and list the addreses for > sale, and ARIN wouldn't have any teeth with which to revoke the addresses. > (Unless of course they could show the justification part of the application > was fraudulent.) > > In order to preclude that, I have added a new source requirement to the > source entity for transfers, that they may not have received an ARIN > allocation for at least 12 months prior to the transfer. > > In addition, in my new draft proposal I retained the 8.2 transfer > mechanism, which can still be used for ASN and IPv6 transfers via mergers > and acquisitions. > > I also added language forcing no downgrading of current agreement status > which covers the transferred addresses, i.e. RSA to RSA, LRSA to LRSA or > RSA, no agreement to no agreement or LRSA. > > In my rationale, I have limited myself to the benefits of whois accuracy > which will inure from the greater likelihood that all past and future > transfers will be registered. > > >From the discussion, you know that I believe that stewardship demands that > we make policy to ensure whois reliablity in the face of a new paradigm for > IPv4 distribution. IPv4 addresses will change hands in a variety of > transaction types. If those who engage in these transactions do not choose > to have ARIN update whois to reflect them, we run the risk of whois > irrelevance and provide the vacuum in to which competitive registries will > step, with or without global community authority. If transactors find > little cost in having ARIN update whois to reflect the transfer, they are > more likely to request that ARIN make the update. If the transaction cost is > high, fewer will make that request, leading to a less and less reliable > whois, which could degrade to the point where network operators choose a > more reliable registry. This kind of chaos in the core of the Internet would > be an indictment of ARIN stewardship. > > We will run out of free pool addresses shortly. At that point we will not > be stewards of those addresses anymore. We will, however, retain our > stewardship role towards maintaining whois as an authoritative source for > routing authority. Prior to exhaust, it was possible to ignore whois, as > conflicts over address control were unlikely when "free" addresses were > available. In the post-exahaust world, where address control conflict is > likely to increase, it is all the more important that whois be a trusted and > accurate information source. > > Now it could be that I have misread section 12, I know I heard from more > than one person that ARIN could revoke for underutilization. If you can > point me to what I am missing, then maybe I will have to monkey with section > 12. My hope is that by simply changing 8.3 and the RSA I can avoid that. > > I agree with John Curran's posting this week about simplifying transfer > requirements, and have retained the /24 minimum for the reasons he > mentioned. > > Regards, > > Mike Burns > > 1. Policy Proposal Name: New IPv4 Transfer policy > > 2. Proposal Originator: > a. Name: Mike Burns > b. Email: mike at sum.net > c. Phone: 1-863-494-7692 x105 > d. Organization: Nationwide Computer Systems > > 3. Proposal Version: 1 > > 4. Date: May 9th, 2011 > > 5. Proposal type: modify > > 6. Policy term: permanent > > 7. Policy statement: > > Replace Section 8.3 with > > 8.3 ARIN will process and record IPv4 address transfer requests. > > Conditions on the IPv4 address block: > > - The minimum transfer size is a /24 > > - The address block must be in the range of addresses administered > by ARIN > > Conditions on source of the transfer: > > - The source entity must be the current rights 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 the transfer, or until the exhaustion of ARIN's > IPv4 space, whichever occurs first. > > - The source entity must not have received an allocation from ARIN > for the 12 months prior to the transfer. > > > Conditions on recipient of the transfer: > > - The recipient entity must be a current ARIN account holder. > If the addresses being transferred are under RSA, the recipient must > sign an RSA with ARIN. > If the addresses being transferred are under LRSA, the recipient must > sign an LRSA or an RSA with ARIN. > If the addresses being transferred are legacy addresses under no form > of RSA, recipient may choose to sign an LRSA, but will not be required to do > so. > > - The recipient entity of the transferred resources will be subject > to current ARIN policies. In particular, in any subsequent ARIN > IPv4 address allocation request, the recipient will be required > to account for the efficient utilization of all IPv4 address > space held, including all transferred resources. > > > and modify section 12.8 of the current RSA to remove references to > "intended purposes." > > Replace > ARIN may review, at any time, Applicant's use of previously allocated or > assigned number resources or Services received from ARIN to determine if > Applicant is complying with this Agreement and the Policies and is using the > Services for their intended purposes. Without limiting the foregoing, if > Applicant is a holder of a direct allocation or assignment from ARIN, > Applicant agrees that it will use the number resources solely for uses > consistent with its application and this Agreement, including, for example, > its internal infrastructure or to provide Internet access to its customer > base. If ARIN determines that the number resources or any other Services are > not being used in compliance with this Agreement, the Policies, or the > purposes for which they are intended, ARIN may: (i) revoke the number > resources; (ii) cease providing the Services to Applicant; and/or (iii) > terminate this Agreement. > > with > > ARIN may review, at any time, any Applicant's use of previously allocated > or assigned number resources or Services received from ARIN to determine if > Applicant is complying with this Agreement and the Policies. Without > limiting the foregoing, if Applicant is a holder of a direct allocation or > direct assignment from ARIN, Applicant agrees that it will use the number > resources solely for uses consistent with this Agreement, including, for > example, its internal infrastructure or to provide Internet access to its > customer base. If ARIN determines that the number resources or any other > Services are not being used in compliance with this Agreement or the > Policies, ARIN may: (i) revoke the number resources; (ii) cease providing > the Services to Applicant; and/or (iii) terminate this Agreement. > > > > > > 8. Rationale: > > Current ARIN policies relating to the registration of transfer of > address holdings limit the eligibility of registration of transfers to > those relating to mergers and acquisitions of entities that are > administering an operational network, or to those who agree to > sign either an RSA or LRSA with ARIN and subject the buyer > to needs analysis and the seller to a potential ARIN review under RSA > section 8. > > It is currently anticipated that the IPv4 unallocated address pool > will be exhausted within a couple of years at ARIN, and earlier > than that in other regions, and the transition to IPv6-based service > delivery > is likely to take longer than the remaining period of unallocated > address availability. Accordingly, it is likely that demand for IPv4 > addresses will continue beyond the time of unallocated address pool > exhaustion, leading to a period of movement of IPv4 address blocks > between address holders to meet such continuing demand for IPv4 > address blocks. > > The underlying proposition behind this policy proposal is that the > registry of IPv4 addresses operated by ARIN is of general utility and > value only while it accurately describes the current state of address > distribution. If a class of address movement transactions are excluded > from being entered in the registry, then the registry will have > decreasing value to the broader community, and the integrity of the > network itself is thereby compromised. This proposal's central aim is > to ensure the continuing utility and value of the ARIN address > registry by allowing the registry to record transactions where IPv4 > addresses are transfered between ARIN account holders. > > It proposes that ARIN will recognise and register a transfer of > addresses where the parties to the transfer are 'known' to ARIN and > that the address block being transferred is part of ARIN's current address > set. > > The proposal does not prescribe how such transfers may occur, nor > impose any further constraints on the transfer or on the parties > involved other than those described in this proposal. > > 9. Timetable for implementation: immediate. > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > http://lists.arin.net/pipermail/arin-ppml/attachments/20110509/021902b0/attachment.html > > > > ------------------------------ > > _______________________________________________ > ARIN-PPML mailing list > ARIN-PPML at arin.net > http://lists.arin.net/mailman/listinfo/arin-ppml > > End of ARIN-PPML Digest, Vol 71, Issue 99 > ***************************************** > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tedm at ipinc.net Mon May 9 16:34:08 2011 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Mon, 09 May 2011 13:34:08 -0700 Subject: [arin-ppml] Draft Proposal for Needs-Free IPv4 Transfers In-Reply-To: <323AD9AC0BE24F9BB91D3E712160681A@mike> References: <323AD9AC0BE24F9BB91D3E712160681A@mike> Message-ID: <4DC84FC0.6070708@ipinc.net> On 5/9/2011 12:15 PM, Mike Burns wrote: > Hello, > Upon feedback to my first draft proposal whose intent is to lift needs > requirements for all IPv4 transfers, I have made some changes to my > draft proposal. > One of the issues was the idea that if I made no changes to section 12, > that ARIN could do a resource review of the transferree and if they > determined the addresses were not being used, could request them to be > returned. > I have read section 12 of the NRPM, and could find no language that > gives ARIN that right. I think that this gets back into the early days of the RIR. The deal that was cut with the so-called "Legacy" holders, as near as I can piece together from various bits of e-mails and presentations and such made during the time of the formation of the RIR system, was that the Legacy holders would respect the authority of the RIR system (ie: they would not transfer their numbers, they would not attempt to become RIRs themselves, they would go to the RIR's for future allocations) in exchange for the RIR system not demanding that the Legacy holders sign an RSA and thus having to start paying fees on the addresses. Doubtless John Curran would be more explicit if he were to elucidate on this. Unfortunately in the past when pressed he has not been forthcoming. In my opinion, the FACT that none of the Legacy holders, when they needed additional resources, have attempted to just pull numbers out of their ass, but instead have in fact gone to the RIR's for more numbers, means that in effect the concept of "adverse possession" has happened. In short, the RIR's have exerted authority over the IP space, and for the last decade none of the Legacy holders have disputed this, and as a result, the Legacy holders have lost whatever rights that they might have had to dispute RIR control of the ENTIRE IPv4 & IPv6 space. Thus I believe that even though the right of ARIN to pull IPv4 numbers from Legacy holders is not enumerated in the NRPM, that under most legal systems they do have that right today, simply because none of the Legacy holders have attempted to deny them that over the last decade. Basically section 12 is about fraud and about > compliance with existing policy, but there is no existing policy that I > could find requiring anything like efficient utilization of allocations, > except in reference to a new or subsequent allocation. But once an > allocation is made, I could find no policy requiring efficient > utilization of that block if no further allocation request is made. > On the other hand, the current RSA has clear language in section 8 that > allows ARIN to review previous allocations and allows ARIN to determine > if their use is consistent with the intended purpose as presented on the > application at the time of the allocation request: > 8. REVIEW OF APPLICANT?S NUMBER RESOURCES > > ARIN may review, at any time, Applicant?s use of previously allocated or > assigned number resources or Services received from ARIN to determine if > Applicant is complying with this Agreement and the Policies and is using > the Services for their intended purposes. Without limiting the > foregoing, if Applicant is a holder of a direct allocation or assignment > from ARIN, Applicant agrees that it will use the number resources solely > for uses consistent with its application and this Agreement, including, > for example, its internal infrastructure or to provide Internet access > to its customer base. If ARIN determines that the number resources or > any other Services are not being used in compliance with this Agreement, > the Policies, or the purposes for which they are intended, ARIN may: (i) > revoke the number resources; (ii) cease providing the Services to > Applicant; and/or (iii) terminate this Agreement. > > (To my reading, if you got an allocation in 2001 for web hosting > purposes, and now you are using the addresses to provide DSL service, > ARIN could revoke them for not being used for purposes consistent with > the Applicant's application unless you notify them and get approval. But > let's leave that aside.) Arin never applied that fine granularity of utilization requirements to address applicants. > Since my overarching purpose is to bring as much supply into the market > as possible, I don't want any old allocations to stay unused on the > shelf because the holder is afraid of a recovery action. > But if section 12 does not allow ARIN to make a resource finding > requesting return of addresses merely for underutilization, and if we > remove the language in the RSA allowing ARIN to recover based on > compliance with intended use, then an entity could totally fake a > justification and get a new allocation today, and turn around tomorrow > and list the addreses for sale, and ARIN wouldn't have any teeth with > which to revoke the addresses. (Unless of course they could show the > justification part of the application was fraudulent.) > In order to preclude that, I have added a new source requirement to the > source entity for transfers, that they may not have received an ARIN > allocation for at least 12 months prior to the transfer. > In addition, in my new draft proposal I retained the 8.2 transfer > mechanism, which can still be used for ASN and IPv6 transfers via > mergers and acquisitions. > I also added language forcing no downgrading of current agreement status > which covers the transferred addresses, i.e. RSA to RSA, LRSA to LRSA or > RSA, no agreement to no agreement or LRSA. Then frankly, I won't support it. IMHO all transferred resources should end up under RSA not LRSA no matter whether their origination is Legacy or LRSA. > In my rationale, I have limited myself to the benefits of whois accuracy > which will inure from the greater likelihood that all past and future > transfers will be registered. > From the discussion, you know that I believe that stewardship demands > that we make policy to ensure whois reliablity in the face of a new > paradigm for IPv4 distribution. IPv4 addresses will change hands in a > variety of transaction types. If those who engage in these transactions > do not choose to have ARIN update whois to reflect them, we run the risk > of whois irrelevance and provide the vacuum in to which competitive > registries will step, with or without global community authority. If > transactors find little cost in having ARIN update whois to reflect the > transfer, they are more likely to request that ARIN make the update. If > the transaction cost is high, fewer will make that request, leading to a > less and less reliable whois, which could degrade to the point where > network operators choose a more reliable registry. IMHO any organization that is EITHER under RSA or LRSA for ANY PART of it's holdings is required to respect the authority of the RIR in IP assignment matters Read the following from the RSA: Applicant must submit this Agreement and any requested accompanying information to ARIN to apply to receive and use certain services (?Services?) from ARIN, which may include, without limitation, an allocation/assignment of IP address space, assignment of Autonomous System numbers (?ASNs?), inverse addressing on network blocks, maintenance of resource records, and administration of IP address space. Allocation/assignment of IP address space and assignment of ASNs shall hereinafter be defined as ?number resources Note the KEY section: "allocation/assignment of IP address space" What is the IP address space? Well, it is the space assigned by IANA to ARIN, and it so happens that IANA assigned space that includes "legacy" blocks to ARIN. Thus ARIN has control over that Legacy space because it made assignments from blocks that contain the Legacy space, IANA did not say "ARIN you get all of these address blocks EXCEPT for Legacy blocks" The Legacy holders did not dispute this action of IANA's so they lost their rights, case closed. Also, note another section: ARIN shall have the right to freely assign this Agreement or any of its rights or obligations under it upon written notice to Applicant if ARIN is changing its corporate organization to permit a successor organization to provide the Services contemplated by this Agreement. This section does 2 things, first it defines the fact that a successor organization that assigns addresses could exist at all, and second it gives ARIN the right to reassign the RSA you have signed to that org. ARIN could not reassign your signed RSA if it didn't have rights to the IP space. > This kind of chaos in > the core of the Internet would be an indictment of ARIN stewardship. > We will run out of free pool addresses shortly. At that point we will > not be stewards of those addresses anymore. We will, however, retain our > stewardship role towards maintaining whois as an authoritative source > for routing authority. Prior to exhaust, it was possible to ignore > whois, as conflicts over address control were unlikely when "free" > addresses were available. In the post-exahaust world, where address > control conflict is likely to increase, it is all the more important > that whois be a trusted and accurate information source. That is why the POC cleanup was put into the NRPM. > Now it could be that I have misread section 12, I know I heard from more > than one person that ARIN could revoke for underutilization. If you can > point me to what I am missing, then maybe I will have to monkey with > section 12. My hope is that by simply changing 8.3 and the RSA I can > avoid that. > I agree with John Curran's posting this week about simplifying transfer > requirements, and have retained the /24 minimum for the reasons he > mentioned. > Regards, > Mike Burns > 1. Policy Proposal Name: New IPv4 Transfer policy > 2. Proposal Originator: > a. Name: Mike Burns > b. Email: mike at sum.net > c. Phone: 1-863-494-7692 x105 > d. Organization: Nationwide Computer Systems > 3. Proposal Version: 1 > 4. Date: May 9th, 2011 > 5. Proposal type: modify > 6. Policy term: permanent > 7. Policy statement: > Replace Section 8.3 with > 8.3 ARIN will process and record IPv4 address transfer requests. > > Conditions on the IPv4 address block: > > - The minimum transfer size is a /24 > > - The address block must be in the range of addresses administered > by ARIN > Conditions on source of the transfer: > > - The source entity must be the current rights 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 the transfer, or until the exhaustion of ARIN's > IPv4 space, whichever occurs first. > - The source entity must not have received an allocation from ARIN for > the 12 months prior to the transfer. > > > Conditions on recipient of the transfer: > > - The recipient entity must be a current ARIN account holder. > If the addresses being transferred are under RSA, the recipient must > sign an RSA with ARIN. > If the addresses being transferred are under LRSA, the recipient must > sign an LRSA or an RSA with ARIN. > If the addresses being transferred are legacy addresses under no form of > RSA, recipient may choose to sign an LRSA, but will not be required to > do so. > Rubbish. I won't support it and I hope nobody else does either. The end result is even worse than what happened with the Nortel to Microsoft transfer. Ted > - The recipient entity of the transferred resources will be subject > to current ARIN policies. In particular, in any subsequent ARIN > IPv4 address allocation request, the recipient will be required > to account for the efficient utilization of all IPv4 address > space held, including all transferred resources. > and modify section 12.8 of the current RSA to remove references to > "intended purposes." > Replace > > ARIN may review, at any time, Applicant?s use of previously allocated or > assigned number resources or Services received from ARIN to determine if > Applicant is complying with this Agreement and the Policies and is using > the Services for their intended purposes. Without limiting the > foregoing, if Applicant is a holder of a direct allocation or assignment > from ARIN, Applicant agrees that it will use the number resources solely > for uses consistent with its application and this Agreement, including, > for example, its internal infrastructure or to provide Internet access > to its customer base. If ARIN determines that the number resources or > any other Services are not being used in compliance with this Agreement, > the Policies, or the purposes for which they are intended, ARIN may: (i) > revoke the number resources; (ii) cease providing the Services to > Applicant; and/or (iii) terminate this Agreement. > > with > > ARIN may review, at any time, any Applicant?s use of previously > allocated or assigned number resources or Services received from ARIN to > determine if Applicant is complying with this Agreement and the > Policies. Without limiting the foregoing, if Applicant is a holder of a > direct allocation or direct assignment from ARIN, Applicant agrees that > it will use the number resources solely for uses consistent with this > Agreement, including, for example, its internal infrastructure or to > provide Internet access to its customer base. If ARIN determines that > the number resources or any other Services are not being used in > compliance with this Agreement or the Policies, ARIN may: (i) revoke the > number resources; (ii) cease providing the Services to Applicant; and/or > (iii) terminate this Agreement. > > > 8. Rationale: > Current ARIN policies relating to the registration of transfer of > address holdings limit the eligibility of registration of transfers to > those relating to mergers and acquisitions of entities that are > administering an operational network, or to those who agree to > sign either an RSA or LRSA with ARIN and subject the buyer > to needs analysis and the seller to a potential ARIN review under RSA > section 8. > > It is currently anticipated that the IPv4 unallocated address pool > will be exhausted within a couple of years at ARIN, and earlier > than that in other regions, and the transition to IPv6-based service > delivery > is likely to take longer than the remaining period of unallocated > address availability. Accordingly, it is likely that demand for IPv4 > addresses will continue beyond the time of unallocated address pool > exhaustion, leading to a period of movement of IPv4 address blocks > between address holders to meet such continuing demand for IPv4 > address blocks. > > The underlying proposition behind this policy proposal is that the > registry of IPv4 addresses operated by ARIN is of general utility and > value only while it accurately describes the current state of address > distribution. If a class of address movement transactions are excluded > from being entered in the registry, then the registry will have > decreasing value to the broader community, and the integrity of the > network itself is thereby compromised. This proposal's central aim is > to ensure the continuing utility and value of the ARIN address > registry by allowing the registry to record transactions where IPv4 > addresses are transfered between ARIN account holders. > > It proposes that ARIN will recognise and register a transfer of > addresses where the parties to the transfer are 'known' to ARIN and > that the address block being transferred is part of ARIN's current > address set. > > The proposal does not prescribe how such transfers may occur, nor > impose any further constraints on the transfer or on the parties > involved other than those described in this proposal. > 9. 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 tedm at ipinc.net Mon May 9 16:37:18 2011 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Mon, 09 May 2011 13:37:18 -0700 Subject: [arin-ppml] New IPv4 Transfer policy In-Reply-To: References: Message-ID: <4DC8507E.8020506@ipinc.net> On 5/9/2011 1:04 PM, Rudolph Daniel wrote: > > I may have missed something here, but why is it not possible to dump > LSRA and have all transfers..whether LSRA, RSA. or neither...become a > mandatory RSA signing on transfer ? Because of the argument that somehow Legacy holders have rights to their addresses that are greater than the rights that ARIN gives to current address holders. Since the RSA requires yearly fee payments it would seem obvious that transferrees would strive to continue to perpetuate the "free" status of these IP addresses. Ted with a note to the effect: "Note > that ARIN will not reclaim unutilized v4 address space from legacy > holders. > > RD > > > Date: Mon, 9 May 2011 15:15:06 -0400 > From: "Mike Burns" > > > Hello, > > Upon feedback to my first draft proposal whose intent is to lift > needs requirements for all IPv4 transfers, I have made some changes > to my draft proposal. > > One of the issues was the idea that if I made no changes to section > 12, that ARIN could do a resource review of the transferree and if > they determined the addresses were not being used, could request > them to be returned. > > I have read section 12 of the NRPM, and could find no language that > gives ARIN that right. Basically section 12 is about fraud and about > compliance with existing policy, but there is no existing policy > that I could find requiring anything like efficient utilization of > allocations, except in reference to a new or subsequent allocation. > But once an allocation is made, I could find no policy requiring > efficient utilization of that block if no further allocation request > is made. > > On the other hand, the current RSA has clear language in section 8 > that allows ARIN to review previous allocations and allows ARIN to > determine if their use is consistent with the intended purpose as > presented on the application at the time of the allocation request: > > 8. REVIEW OF APPLICANT'S NUMBER RESOURCES > ARIN may review, at any time, Applicant's use of previously > allocated or assigned number resources or Services received from > ARIN to determine if Applicant is complying with this Agreement and > the Policies and is using the Services for their intended purposes. > Without limiting the foregoing, if Applicant is a holder of a direct > allocation or assignment from ARIN, Applicant agrees that it will > use the number resources solely for uses consistent with its > application and this Agreement, including, for example, its internal > infrastructure or to provide Internet access to its customer base. > If ARIN determines that the number resources or any other Services > are not being used in compliance with this Agreement, the Policies, > or the purposes for which they are intended, ARIN may: (i) revoke > the number resources; (ii) cease providing the Services to > Applicant; and/or (iii) terminate this Agreement. > > (To my reading, if you got an allocation in 2001 for web hosting > purposes, and now you are using the addresses to provide DSL > service, ARIN could revoke them for not being used for purposes > consistent with the Applicant's application unless you notify them > and get approval. But let's leave that aside.) > > Since my overarching purpose is to bring as much supply into the > market as possible, I don't want any old allocations to stay unused > on the shelf because the holder is afraid of a recovery action. > > But if section 12 does not allow ARIN to make a resource finding > requesting return of addresses merely for underutilization, and if > we remove the language in the RSA allowing ARIN to recover based on > compliance with intended use, then an entity could totally fake a > justification and get a new allocation today, and turn around > tomorrow and list the addreses for sale, and ARIN wouldn't have any > teeth with which to revoke the addresses. (Unless of course they > could show the justification part of the application was fraudulent.) > > In order to preclude that, I have added a new source requirement to > the source entity for transfers, that they may not have received an > ARIN allocation for at least 12 months prior to the transfer. > > In addition, in my new draft proposal I retained the 8.2 transfer > mechanism, which can still be used for ASN and IPv6 transfers via > mergers and acquisitions. > > I also added language forcing no downgrading of current agreement > status which covers the transferred addresses, i.e. RSA to RSA, LRSA > to LRSA or RSA, no agreement to no agreement or LRSA. > > In my rationale, I have limited myself to the benefits of whois > accuracy which will inure from the greater likelihood that all past > and future transfers will be registered. > > >From the discussion, you know that I believe that stewardship > demands that we make policy to ensure whois reliablity in the face > of a new paradigm for IPv4 distribution. IPv4 addresses will change > hands in a variety of transaction types. If those who engage in > these transactions do not choose to have ARIN update whois to > reflect them, we run the risk of whois irrelevance and provide the > vacuum in to which competitive registries will step, with or without > global community authority. If transactors find little cost in > having ARIN update whois to reflect the transfer, they are more > likely to request that ARIN make the update. If the transaction cost > is high, fewer will make that request, leading to a less and less > reliable whois, which could degrade to the point where network > operators choose a more reliable registry. This kind of chaos in the > core of the Internet would be an indictment of ARIN stewardship. > > We will run out of free pool addresses shortly. At that point we > will not be stewards of those addresses anymore. We will, however, > retain our stewardship role towards maintaining whois as an > authoritative source for routing authority. Prior to exhaust, it was > possible to ignore whois, as conflicts over address control were > unlikely when "free" addresses were available. In the post-exahaust > world, where address control conflict is likely to increase, it is > all the more important that whois be a trusted and accurate > information source. > > Now it could be that I have misread section 12, I know I heard from > more than one person that ARIN could revoke for underutilization. If > you can point me to what I am missing, then maybe I will have to > monkey with section 12. My hope is that by simply changing 8.3 and > the RSA I can avoid that. > > I agree with John Curran's posting this week about simplifying > transfer requirements, and have retained the /24 minimum for the > reasons he mentioned. > > Regards, > > Mike Burns > > 1. Policy Proposal Name: New IPv4 Transfer policy > > 2. Proposal Originator: > a. Name: Mike Burns > b. Email: mike at sum.net > c. Phone: 1-863-494-7692 x105 > d. Organization: Nationwide Computer Systems > > 3. Proposal Version: 1 > > 4. Date: May 9th, 2011 > > 5. Proposal type: modify > > 6. Policy term: permanent > > 7. Policy statement: > > Replace Section 8.3 with > > 8.3 ARIN will process and record IPv4 address transfer requests. > > Conditions on the IPv4 address block: > > - The minimum transfer size is a /24 > > - The address block must be in the range of addresses administered > by ARIN > > Conditions on source of the transfer: > > - The source entity must be the current rights 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 the transfer, or until the exhaustion of ARIN's > IPv4 space, whichever occurs first. > > - The source entity must not have received an allocation from > ARIN for the 12 months prior to the transfer. > > > Conditions on recipient of the transfer: > > - The recipient entity must be a current ARIN account holder. > If the addresses being transferred are under RSA, the > recipient must sign an RSA with ARIN. > If the addresses being transferred are under LRSA, the > recipient must sign an LRSA or an RSA with ARIN. > If the addresses being transferred are legacy addresses under > no form of RSA, recipient may choose to sign an LRSA, but will not > be required to do so. > > - The recipient entity of the transferred resources will be subject > to current ARIN policies. In particular, in any subsequent ARIN > IPv4 address allocation request, the recipient will be required > to account for the efficient utilization of all IPv4 address > space held, including all transferred resources. > > > and modify section 12.8 of the current RSA to remove references to > "intended purposes." > > Replace > ARIN may review, at any time, Applicant's use of previously > allocated or assigned number resources or Services received from > ARIN to determine if Applicant is complying with this Agreement and > the Policies and is using the Services for their intended purposes. > Without limiting the foregoing, if Applicant is a holder of a > direct allocation or assignment from ARIN, Applicant agrees that it > will use the number resources solely for uses consistent with its > application and this Agreement, including, for example, its internal > infrastructure or to provide Internet access to its customer base. > If ARIN determines that the number resources or any other Services > are not being used in compliance with this Agreement, the Policies, > or the purposes for which they are intended, ARIN may: (i) revoke > the number resources; (ii) cease providing the Services to > Applicant; and/or (iii) terminate this Agreement. > > with > > ARIN may review, at any time, any Applicant's use of previously > allocated or assigned number resources or Services received from > ARIN to determine if Applicant is complying with this Agreement and > the Policies. Without limiting the foregoing, if Applicant is a > holder of a direct allocation or direct assignment from ARIN, > Applicant agrees that it will use the number resources solely for > uses consistent with this Agreement, including, for example, its > internal infrastructure or to provide Internet access to its > customer base. If ARIN determines that the number resources or any > other Services are not being used in compliance with this Agreement > or the Policies, ARIN may: (i) revoke the number resources; (ii) > cease providing the Services to Applicant; and/or (iii) terminate > this Agreement. > > > > > > 8. Rationale: > > Current ARIN policies relating to the registration of transfer of > address holdings limit the eligibility of registration of transfers to > those relating to mergers and acquisitions of entities that are > administering an operational network, or to those who agree to > sign either an RSA or LRSA with ARIN and subject the buyer > to needs analysis and the seller to a potential ARIN review under > RSA section 8. > > It is currently anticipated that the IPv4 unallocated address pool > will be exhausted within a couple of years at ARIN, and earlier > than that in other regions, and the transition to IPv6-based > service delivery > is likely to take longer than the remaining period of unallocated > address availability. Accordingly, it is likely that demand for IPv4 > addresses will continue beyond the time of unallocated address pool > exhaustion, leading to a period of movement of IPv4 address blocks > between address holders to meet such continuing demand for IPv4 > address blocks. > > The underlying proposition behind this policy proposal is that the > registry of IPv4 addresses operated by ARIN is of general utility and > value only while it accurately describes the current state of address > distribution. If a class of address movement transactions are excluded > from being entered in the registry, then the registry will have > decreasing value to the broader community, and the integrity of the > network itself is thereby compromised. This proposal's central aim is > to ensure the continuing utility and value of the ARIN address > registry by allowing the registry to record transactions where IPv4 > addresses are transfered between ARIN account holders. > > It proposes that ARIN will recognise and register a transfer of > addresses where the parties to the transfer are 'known' to ARIN and > that the address block being transferred is part of ARIN's current > address set. > > The proposal does not prescribe how such transfers may occur, nor > impose any further constraints on the transfer or on the parties > involved other than those described in this proposal. > > 9. Timetable for implementation: immediate. > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > > > ------------------------------ > > _______________________________________________ > ARIN-PPML mailing list > ARIN-PPML at arin.net > http://lists.arin.net/mailman/listinfo/arin-ppml > > End of ARIN-PPML Digest, Vol 71, Issue 99 > ***************************************** > > > > > _______________________________________________ > 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 matthew at matthew.at Mon May 9 16:27:56 2011 From: matthew at matthew.at (Matthew Kaufman) Date: Mon, 9 May 2011 13:27:56 -0700 Subject: [arin-ppml] New IPv4 Transfer policy In-Reply-To: References: Message-ID: <0F4E49B9-09DB-434F-AD5D-87DA3DCC42D8@matthew.at> Ask ARIN and/or Microsoft? Matthew Kaufman (Sent from my iPhone) On May 9, 2011, at 1:04 PM, Rudolph Daniel wrote: > > I may have missed something here, but why is it not possible to dump LSRA and have all transfers..whether LSRA, RSA. or neither...become a mandatory RSA signing on transfer ? with a note to the effect: "Note that ARIN will not reclaim unutilized v4 address space from legacy holders. > > RD > > Date: Mon, 9 May 2011 15:15:06 -0400 > From: "Mike Burns" > > Hello, > > Upon feedback to my first draft proposal whose intent is to lift needs requirements for all IPv4 transfers, I have made some changes to my draft proposal. > > One of the issues was the idea that if I made no changes to section 12, that ARIN could do a resource review of the transferree and if they determined the addresses were not being used, could request them to be returned. > > I have read section 12 of the NRPM, and could find no language that gives ARIN that right. Basically section 12 is about fraud and about compliance with existing policy, but there is no existing policy that I could find requiring anything like efficient utilization of allocations, except in reference to a new or subsequent allocation. But once an allocation is made, I could find no policy requiring efficient utilization of that block if no further allocation request is made. > > On the other hand, the current RSA has clear language in section 8 that allows ARIN to review previous allocations and allows ARIN to determine if their use is consistent with the intended purpose as presented on the application at the time of the allocation request: > > 8. REVIEW OF APPLICANT'S NUMBER RESOURCES > ARIN may review, at any time, Applicant's use of previously allocated or assigned number resources or Services received from ARIN to determine if Applicant is complying with this Agreement and the Policies and is using the Services for their intended purposes. Without limiting the foregoing, if Applicant is a holder of a direct allocation or assignment from ARIN, Applicant agrees that it will use the number resources solely for uses consistent with its application and this Agreement, including, for example, its internal infrastructure or to provide Internet access to its customer base. If ARIN determines that the number resources or any other Services are not being used in compliance with this Agreement, the Policies, or the purposes for which they are intended, ARIN may: (i) revoke the number resources; (ii) cease providing the Services to Applicant; and/or (iii) terminate this Agreement. > > (To my reading, if you got an allocation in 2001 for web hosting purposes, and now you are using the addresses to provide DSL service, ARIN could revoke them for not being used for purposes consistent with the Applicant's application unless you notify them and get approval. But let's leave that aside.) > > Since my overarching purpose is to bring as much supply into the market as possible, I don't want any old allocations to stay unused on the shelf because the holder is afraid of a recovery action. > > But if section 12 does not allow ARIN to make a resource finding requesting return of addresses merely for underutilization, and if we remove the language in the RSA allowing ARIN to recover based on compliance with intended use, then an entity could totally fake a justification and get a new allocation today, and turn around tomorrow and list the addreses for sale, and ARIN wouldn't have any teeth with which to revoke the addresses. (Unless of course they could show the justification part of the application was fraudulent.) > > In order to preclude that, I have added a new source requirement to the source entity for transfers, that they may not have received an ARIN allocation for at least 12 months prior to the transfer. > > In addition, in my new draft proposal I retained the 8.2 transfer mechanism, which can still be used for ASN and IPv6 transfers via mergers and acquisitions. > > I also added language forcing no downgrading of current agreement status which covers the transferred addresses, i.e. RSA to RSA, LRSA to LRSA or RSA, no agreement to no agreement or LRSA. > > In my rationale, I have limited myself to the benefits of whois accuracy which will inure from the greater likelihood that all past and future transfers will be registered. > > >From the discussion, you know that I believe that stewardship demands that we make policy to ensure whois reliablity in the face of a new paradigm for IPv4 distribution. IPv4 addresses will change hands in a variety of transaction types. If those who engage in these transactions do not choose to have ARIN update whois to reflect them, we run the risk of whois irrelevance and provide the vacuum in to which competitive registries will step, with or without global community authority. If transactors find little cost in having ARIN update whois to reflect the transfer, they are more likely to request that ARIN make the update. If the transaction cost is high, fewer will make that request, leading to a less and less reliable whois, which could degrade to the point where network operators choose a more reliable registry. This kind of chaos in the core of the Internet would be an indictment of ARIN stewardship. > > We will run out of free pool addresses shortly. At that point we will not be stewards of those addresses anymore. We will, however, retain our stewardship role towards maintaining whois as an authoritative source for routing authority. Prior to exhaust, it was possible to ignore whois, as conflicts over address control were unlikely when "free" addresses were available. In the post-exahaust world, where address control conflict is likely to increase, it is all the more important that whois be a trusted and accurate information source. > > Now it could be that I have misread section 12, I know I heard from more than one person that ARIN could revoke for underutilization. If you can point me to what I am missing, then maybe I will have to monkey with section 12. My hope is that by simply changing 8.3 and the RSA I can avoid that. > > I agree with John Curran's posting this week about simplifying transfer requirements, and have retained the /24 minimum for the reasons he mentioned. > > Regards, > > Mike Burns > > 1. Policy Proposal Name: New IPv4 Transfer policy > > 2. Proposal Originator: > a. Name: Mike Burns > b. Email: mike at sum.net > c. Phone: 1-863-494-7692 x105 > d. Organization: Nationwide Computer Systems > > 3. Proposal Version: 1 > > 4. Date: May 9th, 2011 > > 5. Proposal type: modify > > 6. Policy term: permanent > > 7. Policy statement: > > Replace Section 8.3 with > > 8.3 ARIN will process and record IPv4 address transfer requests. > > Conditions on the IPv4 address block: > > - The minimum transfer size is a /24 > > - The address block must be in the range of addresses administered > by ARIN > > Conditions on source of the transfer: > > - The source entity must be the current rights 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 the transfer, or until the exhaustion of ARIN's > IPv4 space, whichever occurs first. > > - The source entity must not have received an allocation from ARIN for the 12 months prior to the transfer. > > > Conditions on recipient of the transfer: > > - The recipient entity must be a current ARIN account holder. > If the addresses being transferred are under RSA, the recipient must sign an RSA with ARIN. > If the addresses being transferred are under LRSA, the recipient must sign an LRSA or an RSA with ARIN. > If the addresses being transferred are legacy addresses under no form of RSA, recipient may choose to sign an LRSA, but will not be required to do so. > > - The recipient entity of the transferred resources will be subject > to current ARIN policies. In particular, in any subsequent ARIN > IPv4 address allocation request, the recipient will be required > to account for the efficient utilization of all IPv4 address > space held, including all transferred resources. > > > and modify section 12.8 of the current RSA to remove references to "intended purposes." > > Replace > ARIN may review, at any time, Applicant's use of previously allocated or assigned number resources or Services received from ARIN to determine if Applicant is complying with this Agreement and the Policies and is using the Services for their intended purposes. Without limiting the foregoing, if Applicant is a holder of a direct allocation or assignment from ARIN, Applicant agrees that it will use the number resources solely for uses consistent with its application and this Agreement, including, for example, its internal infrastructure or to provide Internet access to its customer base. If ARIN determines that the number resources or any other Services are not being used in compliance with this Agreement, the Policies, or the purposes for which they are intended, ARIN may: (i) revoke the number resources; (ii) cease providing the Services to Applicant; and/or (iii) terminate this Agreement. > > with > > ARIN may review, at any time, any Applicant's use of previously allocated or assigned number resources or Services received from ARIN to determine if Applicant is complying with this Agreement and the Policies. Without limiting the foregoing, if Applicant is a holder of a direct allocation or direct assignment from ARIN, Applicant agrees that it will use the number resources solely for uses consistent with this Agreement, including, for example, its internal infrastructure or to provide Internet access to its customer base. If ARIN determines that the number resources or any other Services are not being used in compliance with this Agreement or the Policies, ARIN may: (i) revoke the number resources; (ii) cease providing the Services to Applicant; and/or (iii) terminate this Agreement. > > > > > > 8. Rationale: > > Current ARIN policies relating to the registration of transfer of > address holdings limit the eligibility of registration of transfers to > those relating to mergers and acquisitions of entities that are > administering an operational network, or to those who agree to > sign either an RSA or LRSA with ARIN and subject the buyer > to needs analysis and the seller to a potential ARIN review under RSA section 8. > > It is currently anticipated that the IPv4 unallocated address pool > will be exhausted within a couple of years at ARIN, and earlier > than that in other regions, and the transition to IPv6-based service delivery > is likely to take longer than the remaining period of unallocated > address availability. Accordingly, it is likely that demand for IPv4 > addresses will continue beyond the time of unallocated address pool > exhaustion, leading to a period of movement of IPv4 address blocks > between address holders to meet such continuing demand for IPv4 > address blocks. > > The underlying proposition behind this policy proposal is that the > registry of IPv4 addresses operated by ARIN is of general utility and > value only while it accurately describes the current state of address > distribution. If a class of address movement transactions are excluded > from being entered in the registry, then the registry will have > decreasing value to the broader community, and the integrity of the > network itself is thereby compromised. This proposal's central aim is > to ensure the continuing utility and value of the ARIN address > registry by allowing the registry to record transactions where IPv4 > addresses are transfered between ARIN account holders. > > It proposes that ARIN will recognise and register a transfer of > addresses where the parties to the transfer are 'known' to ARIN and > that the address block being transferred is part of ARIN's current address set. > > The proposal does not prescribe how such transfers may occur, nor > impose any further constraints on the transfer or on the parties > involved other than those described in this proposal. > > 9. Timetable for implementation: immediate. > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > > ------------------------------ > > _______________________________________________ > ARIN-PPML mailing list > ARIN-PPML at arin.net > http://lists.arin.net/mailman/listinfo/arin-ppml > > End of ARIN-PPML Digest, Vol 71, Issue 99 > ***************************************** > > _______________________________________________ > 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 tedm at ipinc.net Mon May 9 18:11:15 2011 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Mon, 09 May 2011 15:11:15 -0700 Subject: [arin-ppml] New IPv4 Transfer policy In-Reply-To: <0F4E49B9-09DB-434F-AD5D-87DA3DCC42D8@matthew.at> References: <0F4E49B9-09DB-434F-AD5D-87DA3DCC42D8@matthew.at> Message-ID: <4DC86683.90204@ipinc.net> Ask ARIN Financially, the fees for the block of numbers that Microsoft got from that transfer are nothing in comparison to what they paid for it, and Microsoft is also known for spending tons of money on useless stuff. So there must have been some difference between the RSA and the LRSA that made Microsoft choose the LRSA and the only thing I can think of is the LRSA is less restrictive in some manner. I suspect we need to have ARIN modify the LRSA. The LRSA was sold to us on the basis that it was the same thing as the RSA without the annual fee. Obviously, the Microsoft lawyers found out that this wasn't true. ARIN has a lot of explaining to do, here. Ted On 5/9/2011 1:27 PM, Matthew Kaufman wrote: > Ask ARIN and/or Microsoft? > > Matthew Kaufman > > (Sent from my iPhone) > > On May 9, 2011, at 1:04 PM, Rudolph Daniel > wrote: > >> >> I may have missed something here, but why is it not possible to dump >> LSRA and have all transfers..whether LSRA, RSA. or neither...become a >> mandatory RSA signing on transfer ? with a note to the effect: "Note >> that ARIN will not reclaim unutilized v4 address space from legacy >> holders. >> >> RD >> >> >> Date: Mon, 9 May 2011 15:15:06 -0400 >> From: "Mike Burns" >> <mike at nationwideinc.com >> > >> >> Hello, >> >> Upon feedback to my first draft proposal whose intent is to lift >> needs requirements for all IPv4 transfers, I have made some >> changes to my draft proposal. >> >> One of the issues was the idea that if I made no changes to >> section 12, that ARIN could do a resource review of the >> transferree and if they determined the addresses were not being >> used, could request them to be returned. >> >> I have read section 12 of the NRPM, and could find no language >> that gives ARIN that right. Basically section 12 is about fraud >> and about compliance with existing policy, but there is no >> existing policy that I could find requiring anything like >> efficient utilization of allocations, except in reference to a new >> or subsequent allocation. But once an allocation is made, I could >> find no policy requiring efficient utilization of that block if no >> further allocation request is made. >> >> On the other hand, the current RSA has clear language in section 8 >> that allows ARIN to review previous allocations and allows ARIN to >> determine if their use is consistent with the intended purpose as >> presented on the application at the time of the allocation request: >> >> 8. REVIEW OF APPLICANT'S NUMBER RESOURCES >> ARIN may review, at any time, Applicant's use of previously >> allocated or assigned number resources or Services received from >> ARIN to determine if Applicant is complying with this Agreement >> and the Policies and is using the Services for their intended >> purposes. Without limiting the foregoing, if Applicant is a holder >> of a direct allocation or assignment from ARIN, Applicant agrees >> that it will use the number resources solely for uses consistent >> with its application and this Agreement, including, for example, >> its internal infrastructure or to provide Internet access to its >> customer base. If ARIN determines that the number resources or any >> other Services are not being used in compliance with this >> Agreement, the Policies, or the purposes for which they are >> intended, ARIN may: (i) revoke the number resources; (ii) cease >> providing the Services to Applicant; and/or (iii) terminate this >> Agreement. >> >> (To my reading, if you got an allocation in 2001 for web hosting >> purposes, and now you are using the addresses to provide DSL >> service, ARIN could revoke them for not being used for purposes >> consistent with the Applicant's application unless you notify them >> and get approval. But let's leave that aside.) >> >> Since my overarching purpose is to bring as much supply into the >> market as possible, I don't want any old allocations to stay >> unused on the shelf because the holder is afraid of a recovery action. >> >> But if section 12 does not allow ARIN to make a resource finding >> requesting return of addresses merely for underutilization, and if >> we remove the language in the RSA allowing ARIN to recover based >> on compliance with intended use, then an entity could totally fake >> a justification and get a new allocation today, and turn around >> tomorrow and list the addreses for sale, and ARIN wouldn't have >> any teeth with which to revoke the addresses. (Unless of course >> they could show the justification part of the application was >> fraudulent.) >> >> In order to preclude that, I have added a new source requirement >> to the source entity for transfers, that they may not have >> received an ARIN allocation for at least 12 months prior to the >> transfer. >> >> In addition, in my new draft proposal I retained the 8.2 transfer >> mechanism, which can still be used for ASN and IPv6 transfers via >> mergers and acquisitions. >> >> I also added language forcing no downgrading of current agreement >> status which covers the transferred addresses, i.e. RSA to RSA, >> LRSA to LRSA or RSA, no agreement to no agreement or LRSA. >> >> In my rationale, I have limited myself to the benefits of whois >> accuracy which will inure from the greater likelihood that all >> past and future transfers will be registered. >> >> >From the discussion, you know that I believe that stewardship >> demands that we make policy to ensure whois reliablity in the face >> of a new paradigm for IPv4 distribution. IPv4 addresses will >> change hands in a variety of transaction types. If those who >> engage in these transactions do not choose to have ARIN update >> whois to reflect them, we run the risk of whois irrelevance and >> provide the vacuum in to which competitive registries will step, >> with or without global community authority. If transactors find >> little cost in having ARIN update whois to reflect the transfer, >> they are more likely to request that ARIN make the update. If the >> transaction cost is high, fewer will make that request, leading to >> a less and less reliable whois, which could degrade to the point >> where network operators choose a more reliable registry. This kind >> of chaos in the core of the Internet would be an indictment of >> ARIN stewardship. >> >> We will run out of free pool addresses shortly. At that point we >> will not be stewards of those addresses anymore. We will, however, >> retain our stewardship role towards maintaining whois as an >> authoritative source for routing authority. Prior to exhaust, it >> was possible to ignore whois, as conflicts over address control >> were unlikely when "free" addresses were available. In the >> post-exahaust world, where address control conflict is likely to >> increase, it is all the more important that whois be a trusted and >> accurate information source. >> >> Now it could be that I have misread section 12, I know I heard >> from more than one person that ARIN could revoke for >> underutilization. If you can point me to what I am missing, then >> maybe I will have to monkey with section 12. My hope is that by >> simply changing 8.3 and the RSA I can avoid that. >> >> I agree with John Curran's posting this week about simplifying >> transfer requirements, and have retained the /24 minimum for the >> reasons he mentioned. >> >> Regards, >> >> Mike Burns >> >> 1. Policy Proposal Name: New IPv4 Transfer policy >> >> 2. Proposal Originator: >> a. Name: Mike Burns >> b. Email: mike at sum.net >> c. Phone: 1-863-494-7692 x105 >> d. Organization: Nationwide Computer Systems >> >> 3. Proposal Version: 1 >> >> 4. Date: May 9th, 2011 >> >> 5. Proposal type: modify >> >> 6. Policy term: permanent >> >> 7. Policy statement: >> >> Replace Section 8.3 with >> >> 8.3 ARIN will process and record IPv4 address transfer requests. >> >> Conditions on the IPv4 address block: >> >> - The minimum transfer size is a /24 >> >> - The address block must be in the range of addresses administered >> by ARIN >> >> Conditions on source of the transfer: >> >> - The source entity must be the current rights 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 the transfer, or until the exhaustion of ARIN's >> IPv4 space, whichever occurs first. >> >> - The source entity must not have received an allocation from ARIN >> for the 12 months prior to the transfer. >> >> >> Conditions on recipient of the transfer: >> >> - The recipient entity must be a current ARIN account holder. >> If the addresses being transferred are under RSA, the recipient >> must sign an RSA with ARIN. >> If the addresses being transferred are under LRSA, the recipient >> must sign an LRSA or an RSA with ARIN. >> If the addresses being transferred are legacy addresses under no >> form of RSA, recipient may choose to sign an LRSA, but will not be >> required to do so. >> >> - The recipient entity of the transferred resources will be subject >> to current ARIN policies. In particular, in any subsequent ARIN >> IPv4 address allocation request, the recipient will be required >> to account for the efficient utilization of all IPv4 address >> space held, including all transferred resources. >> >> >> and modify section 12.8 of the current RSA to remove references to >> "intended purposes." >> >> Replace >> ARIN may review, at any time, Applicant's use of previously >> allocated or assigned number resources or Services received from >> ARIN to determine if Applicant is complying with this Agreement >> and the Policies and is using the Services for their intended >> purposes. Without limiting the foregoing, if Applicant is a holder >> of a direct allocation or assignment from ARIN, Applicant agrees >> that it will use the number resources solely for uses consistent >> with its application and this Agreement, including, for example, >> its internal infrastructure or to provide Internet access to its >> customer base. If ARIN determines that the number resources or any >> other Services are not being used in compliance with this >> Agreement, the Policies, or the purposes for which they are >> intended, ARIN may: (i) revoke the number resources; (ii) cease >> providing the Services to Applicant; and/or (iii) terminate this >> Agreement. >> >> with >> >> ARIN may review, at any time, any Applicant's use of previously >> allocated or assigned number resources or Services received from >> ARIN to determine if Applicant is complying with this Agreement >> and the Policies. Without limiting the foregoing, if Applicant is >> a holder of a direct allocation or direct assignment from ARIN, >> Applicant agrees that it will use the number resources solely for >> uses consistent with this Agreement, including, for example, its >> internal infrastructure or to provide Internet access to its >> customer base. If ARIN determines that the number resources or any >> other Services are not being used in compliance with this >> Agreement or the Policies, ARIN may: (i) revoke the number >> resources; (ii) cease providing the Services to Applicant; and/or >> (iii) terminate this Agreement. >> >> >> >> >> >> 8. Rationale: >> >> Current ARIN policies relating to the registration of transfer of >> address holdings limit the eligibility of registration of transfers to >> those relating to mergers and acquisitions of entities that are >> administering an operational network, or to those who agree to >> sign either an RSA or LRSA with ARIN and subject the buyer >> to needs analysis and the seller to a potential ARIN review under >> RSA section 8. >> >> It is currently anticipated that the IPv4 unallocated address pool >> will be exhausted within a couple of years at ARIN, and earlier >> than that in other regions, and the transition to IPv6-based >> service delivery >> is likely to take longer than the remaining period of unallocated >> address availability. Accordingly, it is likely that demand for IPv4 >> addresses will continue beyond the time of unallocated address pool >> exhaustion, leading to a period of movement of IPv4 address blocks >> between address holders to meet such continuing demand for IPv4 >> address blocks. >> >> The underlying proposition behind this policy proposal is that the >> registry of IPv4 addresses operated by ARIN is of general utility and >> value only while it accurately describes the current state of address >> distribution. If a class of address movement transactions are excluded >> from being entered in the registry, then the registry will have >> decreasing value to the broader community, and the integrity of the >> network itself is thereby compromised. This proposal's central aim is >> to ensure the continuing utility and value of the ARIN address >> registry by allowing the registry to record transactions where IPv4 >> addresses are transfered between ARIN account holders. >> >> It proposes that ARIN will recognise and register a transfer of >> addresses where the parties to the transfer are 'known' to ARIN and >> that the address block being transferred is part of ARIN's current >> address set. >> >> The proposal does not prescribe how such transfers may occur, nor >> impose any further constraints on the transfer or on the parties >> involved other than those described in this proposal. >> >> 9. Timetable for implementation: immediate. >> -------------- next part -------------- >> An HTML attachment was scrubbed... >> URL: >> <http://lists.arin.net/pipermail/arin-ppml/attachments/20110509/021902b0/attachment.html> >> >> ------------------------------ >> >> _______________________________________________ >> ARIN-PPML mailing list >> ARIN-PPML at arin.net >> >> http://lists.arin.net/mailman/listinfo/arin-ppml >> >> End of ARIN-PPML Digest, Vol 71, Issue 99 >> ***************************************** >> >> >> _______________________________________________ >> 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 tedm at ipinc.net Mon May 9 18:49:27 2011 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Mon, 09 May 2011 15:49:27 -0700 Subject: [arin-ppml] transfer conditions In-Reply-To: References: <75E9BD24-F12F-42BF-A989-CF6CC282B28E@arin.net> <8740380157159276993@unknownmsgid> <49E26DCB-DAF7-4A0A-912E-F981494979F5@delong.com> <4DBC2AEB.9040307@matthew.at> <4DBCA58D.4060704@sprunk.org> <2344ADD7-616E-4FA7-9552-19735926A952@delong.com> <391BFA8C-9D09-4BB2-8D49-FD5F9C6FDF93@arin.net> <6B951089-C686-4929-AC21-A1BF91BBBCB7@delong.com> <22A6B158-1CBC-4C35-A842-0BD029B2461C@arin.net> <9CDB0040-AFFD-4A90-94D9-821003EE5B8F@matthew.at> Message-ID: <4DC86F77.2060101@ipinc.net> On 5/8/2011 10:48 AM, Jimmy Hess wrote: > On Sat, May 7, 2011 at 11:04 PM, Matthew Kaufman wrote: > >> Why don't we just start by disallowing all transfers smaller than, say, /19... and then adjusting that downward (in block size... upward in mask length) as the market shows that it can't function with the simultaneous combination of needs-justification-requirements and minimum-block/aggregate-sizes? > > Why don't we start by disallowing all transfers smaller than the > minimum allocation size for the block? > > And use /22 as the minimum allocation size for any legacy block of > which /16s were assigned' > /20 as the minimum allocation size for any legacy block of size /8 or > shorter were assigned? > > ARIN allocates prefixes longer than /19, so /19 restriction seems a bit much > I would be willing to accept a /24 minimum size transfer AS LONG AS it was tied to a mandate for the receiving party to sign an RSA. I wouldn't like it, but obviously ARIN does not like forcing the recieving party to sign an RSA, so this way, we both get equally something that we don't like. 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 Mon May 9 19:45:52 2011 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Mon, 09 May 2011 16:45:52 -0700 Subject: [arin-ppml] Draft proposal that needs some wordsmithing In-Reply-To: <36768B46-2E69-434D-A7EB-0FEEC81BF184@delong.com> References: <9638601B94304E4392112CF98CDE757C@mike><4DC31B41.3090001@umn.edu> <940FF59153304663A8094B5EEB172AD3@mike> <468BF725-3BA3-423F-A98E-3CC762344D63@delong.com> <5A3A69A575A04812BB8985D1CCCFADAD@mike> <2B708E3CAA4F46599B60EE2001111E3A@mike> <36768B46-2E69-434D-A7EB-0FEEC81BF184@delong.com> Message-ID: <4DC87CB0.8060704@ipinc.net> On 5/6/2011 11:37 PM, Owen DeLong wrote: > > On May 6, 2011, at 2:02 PM, Mike Burns wrote: > >> Hi Owen, >> >> It is my contention that the definition of waste is often in the >> eye of the beholder, >> *If we keep needs, only ARIN's definition matters. They are THE >> arbiters of need, and thus the corollary, waste.* > In which case, by definition, the current policies are 100% waste free. > I don't think > that's what you intended to say. ;-) >> >> but, if you define waste as addresses which are not assigned to >> machines or >> assigned to machines without a purpose considered useful by at >> least some >> person and related to the address being used to provide or consume >> a service >> over the network, then, it is my argument that the amount of waste >> allowed by >> a market with justified need would be less than that allowed by an >> unrestricted >> market. >> >> *If I concede that, will you concede that a market with a >> continued justified needs policy would lead to a less reliable whois?* > No, I think it will lead to a similarly reliable whois to what we have > today. Neither > less nor more. I believe a permissive market policy _COULD_ lead to a > slightly > more reliable whois, but, I tend to doubt this. >> >>>> We know the needs requirement was not a perfect way to ensure >>>> efficiencies. >>>> We know that from the number or allocated and not advertised >>>> space, if nothing else. >>> >>>> No, we do not. Allocated and not advertised DOES NOT mean >>>> underutilized. >>>> There are many legitimate reasons IP resources may be >>>> unadvertised while still >>>> fully utilized (or more accurately, utilized but not visible in >>>> any routing table to which >>>> you particularly have access). >>> >>> I am of the opinion that there is a lot of waste in legacy space, >>> and only slightly less waste in RSA space. >>> Everyone here can make their own decision on that using their own >>> experience to guide them. >>> This is all space that has been allocated outside functioning >>> market environments. >>> >> I have no reason to believe that a market without justified need >> requirements would >> somehow magically reduce waste vs. a market with the requirement >> that recipients >> have justified need for their resources. After all, any recipient >> with justified need for >> the resources they are receiving is non-waste almost by >> definition, where this >> remains largely undefined for a market with no such requirement. >> >> An unrestricted market depends on the price of the address to >> reduce waste. However, >> unless you consider that tying addresses up to keep them from >> benefiting your >> competitors is not waste (I believe it is waste), there is no >> reason to believe that >> such an unrestricted market would not create exactly that type of >> transaction. >> *If competitors tried to do that, they would be taking a risk that >> their investment would be ill-advised, particularly if they drive >> Ipv6 adoption.* >> *And you are presupposing (a big leap to me) that other addresses >> would not come into the market to replace those purchased by the >> fictional competitor who is hoarding.* >> *They are fungible, after all. You are asking ARIN to make these >> kinds of business decisions as to what is a valid strategy and >> what isn't.* >> ** > Either you don't understand this industry, or, you are making some very > interesting assumptions. > > Imagine for a moment that the 5 largest providers in the US are able to > use an unrestricted > transfer market to acquire enough addressing for their IPv4 needs for > the next 10 years. > This has the side effect of essentially eliminating the supply from the > market. > > Now you have the incumbent {telco,cableco,etc.} continuing to provide > uninterrupted IPv4 > services without LSN to their users while their competitors (all the > small and medium sized > ISPs) have no access to additional addresses and are forced to subject > their customers > to LSN and/or adopt IPv6. > > In this scenario, rather than a significant customer migration to IPv6, > what you likely drive > is a significant customer migration to the incumbent > {telco,cableco,etc.} and the elimination > of the competing smaller ISPs in most markets. > Not exactly. What your doing is freezing the smaller ISP's at a specific customer level, they cannot take on a new customer unless an old one leaves, and the large ISP's can continue to take on new customers. This won't eliminate them just reduce their market share. And yes I agree that this is a Bad Thing. > I do not consider that to be in the community interest. >> >> >>>> A market will not be perfect either, but unlike the prior needs >>>> analysis, we seem to be judging the free market by the exceptions. >>>> >>>> Since the misdeeds (which you claim will be "exceptions") in the >>>> market have the >>>> potential to overwhelm the market, where no such risk existed in >>>> the needs >>>> analysis, I think that is a legitimate approach. >>> >>> The stewards of APNIC decided otherwise, and your assertions, >>> like mine, about the dangers of allowing free individuals >>> voluntarily engaging in trade, are unsupported. >>> >> The APNIC community decided that abandoning needs basis might >> serve their >> community better. The other four RIRs have elected to preserve >> needs basis. >> *The APNIC community is also the most active in terms of recent >> demand, and closest to exhaust.* >> *The sponsor of the needs-free transfer policy was a well >> respected member of the APNIC community, not a latecomer like me.* > > Yes... As you know, I am well aware of Geoff's thinking on this and well > versed in his > position on the subject. You are correct that Geoff is a well respected > member of the > APNIC community. However, there are a number of things that are unique > to the > APNIC region and policy process that lead me to believe that looking to > them for guidance > in this area will not lead to a good outcome for the ARIN community. > > How many APNIC meetings have you attended? How long have you been subscribed > to the APNIC Policy SIG mailing list? I am not a latecomer, either, and > I have good > familiarity with both APNIC and ARIN. Indeed, I believe I am reasonably > well known > in at least 4 of the 5 RIR communities. I have been to at least one > policy meeting of > each of the 5 RIRs in the last year. LACNIC and RIPE are the only > regions where > I have not yet attended multiple meetings. >> >> >> My statements about the dangers of allowing unrestricted trade are >> well documented >> in other markets where they have occurred. Can you point to >> examples of completely >> unregulated markets where such misdeeds have not occurred over any >> substantial >> period of time? >> >> *I wish I could point to more unregulated markets. I point to the >> Internet, which has developed largely because it has been free >> from government rules.* > Well, if you want to use the internet as an example, I would say that > the damage done > by the deregulation of DNS and it's subsequent abandonment of > stewardship in favor > of policies preferred by WIPO is a classic example of a market gone > wrong. The pollution > of the TLD namespace in the name of ICANN earnings is another. >> >> *It has also been free from unnecessary psuedo-government rules >> put in place by existing Internet governance systems.* > For this to be true, you would have to give up on characterizing the RIR > policies as being such rules. > You cannot have your cake and eat it too. >> >> *After all, these Internet governance systems could have done more >> to mandate IPv6, but conservative stewardship left the matter to >> individual choice.* > I challenge you to cite feasible examples. Please make sure to include > the alleged governance body and details of > the steps they could have taken to mandate IPv6. I will cite at least 1 - the IPv6 RFC 2460 is still in Draft status. This is inexcusible, it should have at least been moved to Proposed Standard status. >> >> *I never said no "misdeeds" will occur in a free market. I claim >> that these are exceptions, and that you are judging markets by >> their exceptions.* > I claim that while they may be exceptions, they may be of such magnitude > as to define the market. You have offered > nothing to counter that claim. >> >> *I think free markets have moved the world forward immensely since >> the concept was elucidated by Adam Smith, and I point to the car >> you drove to work in as one positive result of free markets.* > I point to our utter dependence on foreign oil, the limits of > liabilities on oil companies for their environmental > disasters, the lack of natural-gas powered automobiles and > infrastructure to support them, and the limited > investment in renewable energy until very recently as overwhelming > counter-examples in that very field. > Let us not also forget that it is not the free market, but, regulation > and product liability law which brought about > most of the innovations in automotive safety whereas the free market was > perfectly happy to keep killing > people as long as they made enough babies first to have more consumers > to buy more cars. To make the claim that the Free Market brought about the automobile is insane, and shows a clear misunderstanding of what the automobile is. The Free Market brought about the Model T. The Model T could drive anywhere, on or off road, it could ford streams, be turned into a tractor and plow fields, it was repairable by common tools present in every home and came with a manual to enable you to do so. But almost every automobile since that time has depended heavily on massive government interference, from everything from setting the width of roads, the gentleness of turns, colors and candlepowers of lights, to say nothing of the government infrastructure that had to be developed to support automobile insurance companies, without which it would be simply impossible for the average citizen to afford the risk of owning and driving a car. >> >> *But your request for examples leads me to analogies which is a >> road I am trying to avoid.* >> ** > I suppose that's your choice. I believe I have provided examples of > market failures. You wish to dismiss > them as exceptions, but, this would be such a constrained market that I > do not see how you can > dismiss the potential for these exceptions to be of such magnitude as to > define the market. As such, > I do not believe they can be so easily dismissed. The very claim that there is such a thing as a free market is idiotic, no such market exists on the face of the Earth today, in any country, and in any society. Nobody can cite a single market anywhere that is not free of government intrusion in some manner. Even the Amish must submit to government regulation, they must wear reflectors on their buggies. >> >> >>> >>>> >>>>> 2) Why would any organization with need for unique IPv4 addresses >>>>> choose to not have those addresses recorded in the database which >>>>> guarantees their value in order to escape stating their need? (i.e. >>>>> What class of organization with legitimate need would be hurt by >>>>> having to demonstrate that need before receiving addresses?) >>>>> >>>> >>>> An aggregator buying unroutable bits to aggregate to a routable >>>> size?. >>> >>>> I see no reason this couldn't be done by an organization with >>>> need just as effectively >>>> as by some random aggregator intending to resell the result. >>> >>> What if his need is to buy snippets of space in order to >>> aggregate it into sizes acceptable to the network operator >>> community and then sell them? >>> How would he describe that need to ARIN? >>> >> That isn't a need supported by policy. If he needs an aggregate >> acceptable >> to the operator community for his own use, OTOH, I think he could >> easily justify >> those multiple purchases to ARIN under current interpretation of 8.3. >> *But you would arbitrarily prevent him from providing that service >> to others through maintaining ARIN sayso over whether his business >> is justified. Even though that service would benefit the network >> operator community through aggregation, and the Internet as a >> whole via recovery of unroutable space.* >> > I don't believe his ability to aggregate space would, in any way, be > superior to the > ability of the end recipients of the space that need it. As such, I do > not believe my > dismissal of the business model is arbitrary. I believe the business > model is largely > fictitious in nature. I agree. >> >> I don't see where the reseller provides any benefit to the >> community over the >> end organization being the one to do the aggregation. >> *You don't think that somebody who specializes in that market >> would possibly be able to provide the service more efficiently >> than an end user?* > No, I do not. For one thing, I'm not convinced it would be at all > feasible for either. > The general nature of addressing is that aggregation is hard and > disaggregation > is relatively easy. The universe tends towards entropy. Aggregation requires > a substantial force acting against entropy. I agree. >> >> >>>> Somebody who has a different view on the IPv6 transition >>>> timeframe and has a longer planning horizon for IPv4? >>> >>>> Then they come to the market multiple times. >>> >>> Each time involves a cost of waiting, an uncertainty cost of the >>> addresses in the future which some companies may find >>> unacceptable, supply uncertainty,as well as transactional and >>> deaggregation costs. >>> Is good stewardship to result in increased costs for consumers of >>> ip address space? >>> >> Yes... The future of IPv4 is uncertain and will get progressively >> more uncertain as time progresses. >> This is the reality of betting your business on continued >> availability of IPv4. >> >> Providing greater or longer durations of certainty to some >> organizations at the cost of denying it to others >> is contrary to good stewardship. >> *Who is denying anything to anybody? My contention is that you are >> denying two entities from engaging in a mutually satisfactory >> voluntary relationship through intervening with needs verification.* >> > If you accept the following postulates (which I do): > 1.IPv4 address space is finite. (This is fact, there are roughly 3.8 > billion IPv4 unicast addresses) > 2.The need for IPv4 addresses vastly exceeds their number > (Consider 6.8 billion people and multiply by laptop+desktop+cellphone > (20.4 billion). > In my understanding of mathematics, 3.8 < 20.4. By the way, that 20.4 > figure ignores > the need for servers, infrastructure, etc. all of which also need addresses. > > Now, if you want to claim that only 25% of the worlds citizens will be > connected to > IPv4, then, you can reduce 20.4 to 5.1 billion. Last I checked, 3.8 < > 5.1 too.) > 3.The transfer of addresses is a zero sum gain. There is no creation of > new addresses > accomplished by any transfer mechanism. (also mathematical fact). > > Then, it stands to reason that for party A to obtain addresses from the > transfer market, those > same addresses are denied to party B. For party B to obtain addresses, > those same addresses > are denied to party C. This continues until you reach some party who > is unable to obtain > addresses. Basically, the movement of addresses through the transfer > policy amounts to a > form of "musical chairs". If there are enough chairs for everyone, then, > when the music stops, > everyone sits. However, as I postulated above, there are not enough chairs. Correct, however human history has not been free of these sorts of transfers, the realistic expectation is that they will in fact, happen, and the economically disadvantaged people in society will end up being in the party Z I suppose many content providers who are commercial only care about marketing to party A-Y so that may be why they don't see this as a problem. >> >> Good stewardship is keeping the cost playing field relatively >> level for all players over time. >> At least to the greatest extent possible. >> >> *Doesn't a free market treat participants as equal? My proposal >> seeks to put legacy and RSA holders on a level playing field.* >> * >> * > A free market inherently gives advantages to those with greater capital > over those with less > capital. With a sufficiently greater capital advantage, one can > literally control the market. > The IPv4 address market will be sufficiently constrained that this is > not an unlikely outcome. agreed >> >>>> A reseller of vanity addresses, like 100.100.100.100? >>> >>>> I see no reason to promote or create these. They offer no >>>> meaningful benefit to the >>>> community at large. >>> >>> Is it ARIN's role to decide this? Doesn't the history of the >>> Internet suggest allowing volunteer private organizations to make >>> these kinds of decisions? >>> >> It is the community's role to decide this. As a member of the >> community, I have offered >> my opinion. Others may offer theirs. At the end of the day, ARIN >> policy should reflect >> the collective judgment of the community. >> >> There is no history of volunteer private organizations making >> these decisions with >> respect to number resources on the internet and in places where >> number resources >> have been allowed to be managed in such a way, careful regulation >> has been required >> in each case to avoid substantial problems that have occurred in >> its absence. It is a >> complexity which I do not think we should take on, give its >> limited value to the community >> as a whole. >> >> *If the community needs to decide this, what more open way for it >> to do this than allowing them to vote with their dollars? If it is >> a bad idea, he will go broke.* >> > The more open way, IMHO, is the public policy process where it is one > person, one vote instead of using > dollars where it becomes one dollar one vote. I favor people over > capital when it comes to decision making. >> >>>> A wholesaler of addresses who caters to those who need instant >>>> availability (needs analysis takes time)? >>> >>>> My last needs analysis took less than 24 hours. The average of >>>> my last 5 needs analysis is less than 36 hours. >>>> That's real-time, not resource analyst or my hours. >>> >>> Microsoft got turned down recently from APNIC for a temporary >>> allocation for some technical symposium in Australia. >> >> So? >> >>> Why can't they look to a wholesaler for rapid, and maybe >>> temporary deployment? >> >> In the APNIC region, under their policies, presumably they can. In >> the ARIN region, they cannot because policy >> prohibits such wholesalers. What policy does, however, allow, is >> "matchmakers" who could serve the same purpose >> without possessing the address registrations in the interim. I >> believe the STLS term for them is "Facilitators". >> >> Given the ability to have facilitators, what need is there for >> wholesalers? >> *Facilitators cannot control supply in the way a wholesaler can.* >> > I see that as an advantage. > >>> Surely you can understand that transfers will likely increase in >>> number, and ARIN's needs analyses could take longer? >> >> I don't think that transfers will increase beyond current >> allocation/assignment request rates (modulo normal growth) >> unless the market is becoming excessively liquid which would >> indicate that we have some level of failure in policy. >> *So there is a limit to allowable market liquidity in your eyes?* >> > Perhaps I used the wrong term, but, unless the market is somehow > perverted into a "day-trading" of addresses > purely for the purpose of profiteering (which would have an obvious > destabilizing effect on the network > as a result), I don't see the potential for the transaction rate to > become significantly higher than the current > application rate. The market could easily be perverted into an IPv4 "futures" market where no actual transfer of the IPv4 takes place - just the promises of the trade. >> >>> But no such wholesaler can exist if you require him to >>> demonstrate need. >> >> Nor is he needed or useful in my opinion. >> *Unless Microsoft wants to hold that symposium in North America.* >> > Micr0$0ft can get their addresses directly from the resource holders > without need of > a wholesaler in either region. > >>> Think of a Quik-E-Mart for IP addresses. Are you certain there >>> would never be a call for that kind of convenience? >> >> The visual of purchasing a Big-Gulp full of IP addresses at the >> local 7-11 is just too much for me to take seriously. >> *Not 7-11, Apu from the Simpsons will be doling out the address. I >> guess that doesn't help with the seriousness.* >> > No, it really doesn't. > >>> What if there are supply problems on STLS? A wholesaler with >>> inventory on hand is often a valuable resource in times like >>> that, even though he is going to make a buck on the deal. >>> >> How is a wholesaler with inventory different from a facilitator as >> defined in STLS in any meaningful way? >> >> The facilitator can still make a buck on the deal. If there's a >> supply problem, it's because there isn't a supply, >> not because policy prevented people from providing supply. >> *This is not reasonable. Surely you could see, especially in the >> current slim pickings of the STLS, that the market may have a >> supply problem?* >> *If I thought this, and thought I could profit from being a >> reliable supplier by holding some inventory, your policy would >> prevent me from entering this business artificially, not through >> any economic reason.* > The market _WILL_ have a supply problem no matter what. See my above > statement about the total supply > vs. the obvious demand. If there were no supply problem, then, we would > not have bothered developing > IPv6 in the first place. The supply problem is obvious and inherent in > the situation which is leading to us > even considering a market in the first place. > > What is not reasonable is any belief that it is possible for an IPv4 > market to exist without a supply problem > for any length of time. > > Where would you get this inventory that others cannot get it from? Why > would someone prefer to sell > their addresses to you as a wholesaler than sell them directly to an > organization that needs addresses? A "wholesaler" has to inventory to sell. Wholesalers exist by buying 10,000 of something from A, and selling 1-10 of those things to B-Z over a period of time. This has obvious advantages for a manufacturer who is "A" because they can setup an assembly line, crank out the 10,000 things, then shut the line down and go on to other things after they have made their money. No such paradigm exists with IPv4 because a wholesaler cannot accumulate IPv4 that would violate the utilization requirements. I suspect the transfer market will exist more as a "realtors" market where you have a bunch of guys floating around trying to connect party A to party B and getting a cut on the few times they are successful in doing that. You might ask why people sell homes through realtors. Well the fact is that in hot housing markets THEY DON'T. When my wife and I bought our first home it was in the hottest market in our city and just about every home available was For Sale By Owner. I never understood why this was until years later, but once I did understand it, I resolved to never sell a home in a soft market. The supply of IPv4 will continue to get so constrained to the point that there will be no need of these "brokers" all that will be necessary is to advertise that you have them. The bankruptcy court for Nortel for example was rather dumb - they never advertised that they had those numbers for sale. If they had merely waited another year for ARIN runout, then advertised that block in an open auction, the price they would have gone for would probably be 20-50 million range. But I suspect the reason they did it this way is that they did NOT want US to figure out what was going on and rush a bunch of restrictions - such as making the recipient sign an RSA - into the NRPM. >> >> >>>> A speculator, who could have a positive role in free markets? >>> >>>> ROFL -- The concept of speculator in the same sentence with >>>> "positive role" amuses me. >>> >>> Suggested reading for when you arise from the floor >>> http://mises.org/daily/320 >>> >> After a long winded explanation of how he can cloud the definition >> of speculation to mean virtually >> any form of investing, he finally gets to the point of claiming >> that there is a benefit to the market if: >> >> 1.Prices adjust quickly >> -- In the case of speculators this almost always means "increase" >> >> 2.There is greater liquidity >> -- Though he makes no mention of how, exactly, speculation >> actually increases liquidity >> >> 3.The market fluctuations are minimized >> -- Which is interesting to attribute to speculators after >> attempting to attribute case 1 to them as well. >> >> In my observations of various markets, speculators have had a >> destabilizing influence with a general >> tendency to increase prices, often far above and beyond rational >> levels. >> >> Yes, the speculators at the end of that process when the bubble >> bursts usually get hurt badly, then, we >> the taxpayers get to pay to bail them out, too. >> *If you believe all that, then you should be a speculator. I >> certainly would never support taxpayer bailouts to speculators.* >> > I don't support taxpayer bailouts to speculators as a political > position. Indeed, I'm quite tired of having my > tax dollars used in that way. I'm particularly frustrated at the moment > because they managed to: > 1.Devalue my property to 33% of what it was once worth. > 2.Force the government to create new stricter rules on refinancing which > now preclude > me from refinancing due to my Loan-to-Value ratio (which was perfectly > fine until they > devalued my house). > > Unfortunately, since I purchased responsibly and did not engage in > speculation or dive head first > into water over my head, I am not entitled to any of the government > programs designed to help > the people who caused the problem in the first place, so, here I sit > paying almost 6% on a mortgage > that I could refinance down to a little more than 3% if the speculators > hadn't "rapidly adjusted the market". > You can make an extra payment on the principal only every month and essentially reduce the 6% down by doing this. You have to pay the principal back anyway no matter what your interest rate is, so it is not money lost. >>>> An organization that does not want to undergo an ARIN analysis >>>> for fear it will lead to a review and recovery procedure? >>> >>>> An organization which has reason to fear this is an organization >>>> which probably shouldn't >>>> be getting additional resources from the community. >>> >>> They would be buying them from the rights holder, not getting >>> them from the community. >>> >> The resources belong to the community. The current resource holder >> is holding them in trust. >> They are not property. >> *Funny they appear on many asset sale documents I have seen along >> with other tangible and intangible property.* >> *And I can have the exclusive right to sell them according to >> MS/Nortel, even if they weren't allocated to me.* >> *Walks and quacks like rights ownership.* >> ** > As I said, this particular question has not yet received a direct > ruling. I would not look to MS/Nortel as > precedent setting so much as I think it is an irregularity. > Since MS signed an LRSA and accepting the LRSA means that you give up any rights ownership, the only "precedent" that has been set is the notion that Legacy addresses are property. Meaning once a speculator arranges a sale, further "sales" cannot happen since the recipient doesn't own then. That won't lead to a sustainable speculators market. >> >>> >>>> An organization from another region? >>> >> There is no policy to support inter-regional transfers currently >> and your proposed policy >> would not inherently create them. >> >> *You are correct, but this is still a reason why somebody would >> seek to transfer without registering, Chris' original request.* >> > Such a transfer should, as I said, be voided by the respective RIR, the > resources reclaimed, and > reissued to someone acting within policy. > >>>> You say this as if it is somehow a benefit. >>> >>> I was asked by Chris why anybody would transfer addresses and >>> fail to have them registered, and these were just examples. >>> I don't think this is a benefit, but I support a global free >>> market for IP addresses, so they can flow to wherever they are >>> needed most, as measured by their price. >>> In this way I feel I am extending the definition of community >>> wider than the region of abode. >>> >> I do not support using price as the sole measure of the need for >> addresses. There are many cases where I think >> that, for example, that providing services to > organization> is a far better use than insuring that >> can make sure that their >> competitors feel the pinch of address exhaustion >> well before they do. >> >> Measured by money, is almost >> certain to win. >> *In this endeavor, I view ARIN as the large monopolistic entity.* >> > No, ARIN may be monopolistic when it comes to address management within > their > service region, but, my meaning above is the incumbent telcos, cablecos, > etc. that > mostly operate in either effective or actual monopolies or at best in > some cases > duopolies. > > I'm talking about the relative size of the market participants, not ARIN > which would > be sitting on the side lines of a market recording the events of the day > as it were. >> >>>> A buyer of a /24 who thinks an ARIN needs analysis isn't worth >>>> the expense? >>> >>>> Again, not seeing the benefit to the community in providing this >>>> person the opportunity to take >>>> that /24 out of the hands of some more deserving organization >>>> with documented need. >>> >>> You miss my point, they may have need, but for a small >>> transaction, having to negotiate ARIN hurdles could be viewed as >>> unworth the effort. Again this is in response to the request for >>> examples of potential buyers who would not take the steps to >>> register. >>> >> For a small transaction, the cost of a needs analysis is also >> small. As someone with rather >> extensive experience producing needs-basis justifications for >> submission to ARIN (and >> some experience with other RIRs), I can say with certainty that >> the needs-basis justification >> for a /24 is very simple and does not provide a significant cost >> to the equation. >> *Suppose it is some doctor's office that wants to multihome, do >> you think they would have the same view of that as a person with >> your experience?* > None of my customers (some of whom have been small doctor's offices) > have had a problem > with my fee for preparing their justification. As such, I would say I > have evidence that it is > not. > >> >>>> Microsoft? They didn't seem to want or need a needs analysis >>>> until ARIN began negotiating with them after the original asset >>>> agreement with Nortel had been negotiated. >>>> >>> >>>> This, also, strikes me as an indication that removing needs >>>> basis would have a negative impact >>>> on the overall outcome. >>> >>> ARIN ran in and got the transfer reflected in whois through >>> shenanigans with the needs justification, in my opinion. If there >>> were no needs requirement, I think Microsoft would have asked >>> ARIN to make the updates to whois as the normal course of >>> business, but without knowing how accomodating ARIN would be on a >>> needs analysis, they pointedly left ARIN agreements out of the >>> first negotiated asset sale with Nortel. >>> >> Your opinion is noted, but, I don't concur with the >> characterization you make of the situation. >> >> I think you state a number of assertions in that paragraph with no >> factual basis to back them up. >> *I don't make a single assertion in that paragraph without factual >> basis of backup. I invite you to read the original negotiated >> MS/Nortel asset sale document, and the one that was edited after >> ARIN became involved.* >> *Well, I take that back, I did allege shenanigans, but I did back >> that up last week with logical conjecture if not actual fact.* >> ** > I don't agree with your claim of shenanigans. I am inclined to believe > John when he states that a > full and legitimate needs-basis justification was provided and reviewed > by the ARIN staff. > > I do not believe for one moment that ARIN was in any way more > accommodating for Micr0$0ft than > they would be for any other transfer recipient W.R.T. needs basis. > > I also am not convinced that you have any evidence that they "pointedly > left ARIN agreements out" > vs. it being a simple oversight. > >> >>> >>>> I don't pretend to be able to able to identify all the types of >>>> transactions for which an ARIN needs analysis seems an >>>> unnecessary intrusion into a transaction between two private >>>> entities. >>>> >>>> What you call unnecessary, I call vital to the overall interests >>>> of the community. >>> >>> It was vital when there was no other free and voluntary mechanism >>> to ensure efficient use, but I am trying to show that the needs >>> mechanism is now outdated and poses a problem for whois. >>> >> Money does not insure efficient use by any definition of >> efficiency that I find acceptable. >> >> Measuring efficiency by money is sort of like measuring electrical >> consumption of >> a house by measuring the temperature rise in the upstairs bedroom. >> Sure, the electrical >> consumption in the house will definitely contribute, but, you >> won't get anything near >> an accurate measurement. >> >> *My measurement of efficiency is address utilization. We are near >> exhaust and there are a billion unrouted addresses.* >> *The current system displays obvious inefficiencies, although >> overall I think it did its job well.* >> > Measuring it by money virtually assures that a few large ISPs will > remove all supply rapidly > from the market in order to shut out smaller competitors and position > themselves in a place > of address affluence for years to come. > > I will take the current inefficiencies over that situation any day. > >>>> The point is that many prior transfers have taken place, >>>> particularly with legacy space, that have not been reflected in >>>> whois. >>> >>>> Hopefully as these can be identified, the space can be revoked >>>> and reallocated >>>> to organizations that comply with policy. The original legacy >>>> holder has some >>>> protections. A third party as a result of an unauthorized >>>> transfer should not have >>>> any protections in this regard. >>> >>> Microsoft was the third party here. Addresses were transferred to >>> Nortel from their acquisitions, the original legacy holders here. >>> By your definitions, since ARIN was not involved, these transfers >>> were unauthorized. >> >> Yep. >> >>> And yet a bankruptcy judge saw no problems with Microsoft buying >>> them from Nortel. >> >> I agree that it is unfortunate that the bankruptcy judge did not >> see fit to consider the >> community with greater weight. >> >>> I haven't stressed this, but the legal facts as I see them are >>> that legacy holdings can be transferred without ARIN notice or >>> needs requirements. >> >> As I see it, this remains unclear. Each of the cases so far has >> carefully not decided this >> particular point. >> >>> By removing needs requirements for transfers, we bring policy in >>> line with developing law, and this is sure to reduce future conflict. >>> >> I would rather preserve conflict and try to develop the law in a >> more useful direction. >> I guess you can consider this part of my right to petition the >> government for redress of grievances. >> >> *Fair enough, but you have to accede the cost to ARIN of that >> possibility of conflict with the law when it comes to future >> legacy transactions.* >> > I accept that ARIN must accept the judgment of the court no matter how > flawed. Just > as I accept that the current law effectively includes two seriously > flawed supreme > court rulings that established: > > 1.Money is a protected form of free speech. > 2.Corporations are people entitled to the protections of the bill of rights. > > These two rulings combined essentially shifted us from capitalism to > corporate > socialism. > Read "The Space Merchants" Fredrick Pohl and Cryil Kornbluth you will love it. Ted >>> >>>> One of the problems relates to the requirement for a needs analysis. >>> >>>> No, the problem is the belief that community resources can be >>>> transferred outside >>>> of community policy. >>> >>> For legacy addresses, these transfers have occurred in reality, >>> it's time for belief to catch up. >>> >> As I said, as these blocks which are being used by entities other >> than their legitimate holders >> are identified, ARIN should reclaim them and reissue the resources >> to organizations within the >> policy process. >> >> That is reality. It is time for ARIN to start becoming more >> aggressive about identifying them >> in my opinion. >> *And we're back to FUD over section 12 processes for those seeking >> to bring addresses to the market. >> * >>> > Huh? If you bring the addresses to the (legitimate) market, I'm all for > reasonable safe-harbour positions > to remove FUD. I want ARIN going after the recipients of invalid > transfers, not the ones bringing > addresses to the market. > >>>> If a holder of legacy space acquired through an asset sale >>>> approached ARIN to reflect that transfer, ARIN would not update >>>> whois without a needs analysis. >>> >>>> As it should be. >>> >>> You are arrogating needs requirements over whois accuracy by >>> taking that stance. >>> >> No, I am taking the stance that the better way to ensure whois >> accuracy is by identifying >> blocks being hijacked by organizations to which they were not >> issued and reclaiming them >> and providing them to members of the community in compliance with >> policy. >> >> *There is no legal process for reclaiming legacy space. You would >> be wasting ARIN's time and treasure in the legacy area, and >> increasing FUD for existing holders seeking to sell.* >> *I don't even think there is an ARIN process for recovering legacy >> space, except through voluntary donation from the holder.* >> > As I said above, I think you misunderstand... Once the addresses are > transferred outside of policy, they are > no longer legacy addresses. The legacy status is tied to the original > legacy holder who received them > for a specific purpose from one of ARIN's predecessor registries. > > I don't want ARIN going after the suppliers... I want ARIN going after > the recipients. In fact, I don't really want > ARIN so much going after the recipients as removing the records from > whois and in-addr.arpa and recycling > the addresses to other organizations working through the legitimate > process with justified needs. > It would be up to the fraudulent transfer recipient to come after ARIN > in that case. > >>> >>>> In addition, the requirement for ARIN to do a needs analysis and >>>> the potential for review and recovery on either the buyer or >>>> seller increases the FUD factor in the market. >>> >>>> Only for those attempting to circumvent policies constructed by >>>> the consensus of the community. >>> >>> If I want to buy and the seller want to sell, and we have reached >>> an agreement on price, then having to undergo an audit before we >>> can process the sale, or being subject to one thereafter, is most >>> certainly an added uncertainty. >>> >> So what. You're trying to trade in community resources that are >> held in the trust of the >> community for a particular purpose. The community has a right to >> audit your use of them >> and ensure that it is in compliance with the policies of the >> community. >> >> The presence of police on the highway adds an element of >> uncertainty to my ability >> to drive at any speed I prefer. I don't necessarily see that as a >> bad thing, even though >> it was very inconvenient on several occasions in my younger years. >> *And the element of uncertainty slows your progress, correct?* >> > Not really, no. > >>>> For a market to function efficiently, Fear, Uncertainty, and >>>> Doubt need to be assuaged, and this proposal does that. >>>> >>>> I have tremendous fear and uncertainty about the effects of this >>>> proposal. I doubt that it will function as >>>> advertised. Indeed, I believe this proposal increases each of >>>> those things from my perspective. >>> >>> So you see how FUD works to prevent action. >>> >> More often, I see how it is used to provoke incorrect or >> counterproductive action, such as the PATRIOT >> act. >> >>>> I copied liberally, almost entirely, from the APNIC policy to >>>> allow needs-free transfers. The rationale which was most >>>> effective in that regions's deliberations may have been the >>>> concern that by imposing the needs requirement, transactions >>>> would be more likely to occur outside the system, leading to a >>>> decay in whois reliability. >>>> >>>> That is the argument Geoff used which appears to have had sway >>>> in that region. >>> >>>> Geoff has repeatedly made that argument in the ARIN and RIPE >>>> regions (and I'm not sure >>>> that he has not made it in LACNIC or AfriNIC as well). So far, >>>> it has not been found to be >>>> convincing outside of APNIC. >>> >>>> By structuring my proposal in this way, I am trying to get >>>> people to consider whether the original and laudable needs >>>> requirement should be maintained when keeping it could lead to >>>> whois degradation. >>> >>>> This question has been asked and answered as part of the debate >>>> around 2008-2, its successor >>>> 2008-15 (IIRC) and the boards reconstruction of that into >>>> 2009-1. You are welcome to ask the >>>> question again, but, I'm not inclined to believe the answer has >>>> changed. >>> >>> Things have changed since then in terms of continued failure to >>> transition and the MS/Nortel deal, and APNIC reaching exhaustion >>> and approving their new transfer policy. >>> >> Uh, APNICs current transfer policy was in place prior to 2009-1. >> *This page says February 2010, but even though it may have been in >> place, it was only activated as the exhaust phased in.* >> *http://www.apnic.net/policy/proposals/prop-050* >> *Back in 2009, many people were still thinking/hoping the >> transition would take off, but now we have years more evidence to >> the contrary, which may change some minds.* >> ** > I find this concept of "years since 2009" interesting. Please explain to > me how you get from > an event that occurred not more than 17 months ago to "years" in the > same time scale. > > I think that APNIC amended their transfer policy, but, the base policy > was, I believe, put in place prior to 2009-1. > However, I suppose it is possible that APNIC didn't actually enact their > policy and was talking about it. I know > that the policy in a form substantially similar to its current form was > definitely being discussed in the region > well before we moved from 2008-2 to 2009-1. >> >> If you're talking about their inter-regional >> transfer policy, that's new, but it doesn't really support a >> removal of needs basis from the ARIN region. >> If anything, it makes it even more vital. >> >> I don't see how the continued failure to transition differs from >> the expectations that were considered at the time we were debating >> 2009-1. >> >> Finally, I don't really see that the MS/Nortel deal changes >> anything other than indicating that we may have been >> insufficiently specific >> with the restrictions expressed in 2009-1 (NRM 8.3) and might need >> to tighten the language so as to place better constraints on >> staff's action more >> in line with intended policy. >> >> As I said, you are more than welcome to ask the question again. >> >>> >>>> My argument is that proper stewardship recognizes the existence >>>> of a market which will fulfill the original stewarship role of >>>> ensuring efficient use, and we can direct our stewardship best >>>> to policies which help to ensure whois veracity. >>> >>>> My argument is that the market alone is not a good steward and a >>>> regulated market is necessary >>>> to ensure the vital interests of the community. >>> >>> And I counter that the vital interest in address-use-efficiencies >>> are better offloaded to the market, and the vital interest in >>> maintaining whois veracity is retained. >>> >> >> Yes, your argument that it is better entrusted to the market is >> precisely the point where I think we have the strongest disagreement. >> *But what about whois? Don't we absolutely require a believable >> registry for the integrity of the whole Internet? There is a >> connection between needs requirements and whois reliability that >> drove the APNIC decision.* > There is an allegation of a connection which remains unproven. >> >> *I would like to say that I will busy out of town this weekend, >> but this thread in particular has probably bored the readers to >> tears and they will be happy at my absence and their relatively >> empty inboxes. My plan is to take some of the proferred >> suggestions and resubmit a draft proposal on Monday for futher >> discussion. Have a nice weekend.* >> > LoL... I'll also be mostly not on email this weekend, so, no worries. > I'm happy to continue the debate in private > if you believe that would be better. > > 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 matthew at matthew.at Mon May 9 21:09:44 2011 From: matthew at matthew.at (Matthew Kaufman) Date: Mon, 9 May 2011 18:09:44 -0700 Subject: [arin-ppml] transfer conditions In-Reply-To: <4DC86F77.2060101@ipinc.net> References: <75E9BD24-F12F-42BF-A989-CF6CC282B28E@arin.net> <8740380157159276993@unknownmsgid> <49E26DCB-DAF7-4A0A-912E-F981494979F5@delong.com> <4DBC2AEB.9040307@matthew.at> <4DBCA58D.4060704@sprunk.org> <2344ADD7-616E-4FA7-9552-19735926A952@delong.com> <391BFA8C-9D09-4BB2-8D49-FD5F9C6FDF93@arin.net> <6B951089-C686-4929-AC21-A1BF91BBBCB7@delong.com> <22A6B158-1CBC-4C35-A842-0BD029B2461C@arin.net> <9CDB0040-AFFD-4A90-94D9-821003EE5B8F@matthew.at> <4DC86F77.2060101@ipinc.n et> Message-ID: <1E077822-6D5F-459F-B312-1DD8F7447B40@matthew.at> On May 9, 2011, at 3:49 PM, Ted Mittelstaedt wrote: > On 5/8/2011 10:48 AM, Jimmy Hess wrote: >> On Sat, May 7, 2011 at 11:04 PM, Matthew Kaufman wrote: >> >>> Why don't we just start by disallowing all transfers smaller than, say, /19... and then adjusting that downward (in block size... upward in mask length) as the market shows that it can't function with the simultaneous combination of needs-justification-requirements and minimum-block/aggregate-sizes? >> >> Why don't we start by disallowing all transfers smaller than the >> minimum allocation size for the block? >> >> And use /22 as the minimum allocation size for any legacy block of >> which /16s were assigned' >> /20 as the minimum allocation size for any legacy block of size /8 or >> shorter were assigned? >> >> ARIN allocates prefixes longer than /19, so /19 restriction seems a bit much >> > > I would be willing to accept a /24 minimum size transfer AS LONG AS it > was tied to a mandate for the receiving party to sign an RSA. All of the versions of the LRSA, and all of the modifications of "The RSA" are "an RSA" > > I wouldn't like it, but obviously ARIN does not like forcing the recieving party to sign an RSA, No, they're fine with "an RSA", just not "The RSA and Only The RSA" Matthew Kaufman From matthew at matthew.at Mon May 9 21:14:02 2011 From: matthew at matthew.at (Matthew Kaufman) Date: Mon, 9 May 2011 18:14:02 -0700 Subject: [arin-ppml] Draft Proposal for Needs-Free IPv4 Transfers In-Reply-To: <4DC84FC0.6070708@ipinc.net> References: <323AD9AC0BE24F9BB91D3E712160681A@mike> <4DC84FC0.6070708@ipinc.net> Message-ID: On May 9, 2011, at 1:34 PM, Ted Mittelstaedt wrote: > > In my opinion, the FACT that none of the Legacy holders, when they > needed additional resources, have attempted to just pull numbers out > of their ass, but instead have in fact gone to the RIR's for more > numbers, means that in effect the concept of "adverse possession" > has happened. > > In short, the RIR's have exerted authority over the IP space, and > for the last decade none of the Legacy holders have disputed this, > and as a result, the Legacy holders have lost whatever rights that they > might have had to dispute RIR control of the ENTIRE IPv4 & IPv6 space. That isn't how it works. If I put a fence around a 10 acre corner of your 100-acre plot and you don't object to the fence, then after some years I can claim adverse possession over the 10 acres... not your entire 100-acre plot. > > Thus I believe that even though the right of ARIN to pull IPv4 numbers > from Legacy holders is not enumerated in the NRPM, that under most > legal systems they do have that right today, simply because none of > the Legacy holders have attempted to deny them that over the last decade. None of the legacy holders have attempted to deny them the ability to assign from the unassigned space... but that's difference. And none of this matters if the address space *isn't* property. Matthew Kaufman From owen at delong.com Mon May 9 22:09:49 2011 From: owen at delong.com (Owen DeLong) Date: Mon, 9 May 2011 19:09:49 -0700 Subject: [arin-ppml] ARIN-prop-146 Clarify Justified Need for Transfers In-Reply-To: <0a9601cc0c21$40f390e0$c2dab2a0$@net> References: <4DBEF120.4080901@arin.net> <88F39B20-5C20-45F0-AD61-5FA1E7F84CE3@delong.com> <4DBF6727.1090303@matthew.at> <097AAC1C-1F68-4820-9274-3290ADEFA195@delong.com> <9501EA7E-FDAD-4DDA-B9E8-08C2811FF642@delong.com> <4DBF82F6.7050608@matthew.at> <20110503145144.N15967@mail.inlandnet.com> <4DC084E7.5000302@matthew.at> <4DC08664.4060905@matthew.at> <4791A59E-8864-483C-9BB0-03A6A5B8D50C@delong.com> <66466F57-4365-4ADB-94EB-E023F01B17CB@delong.com> <30D12BA8-9A6C-4E62-9A67-8B4FEA0EA8C1@matthew.at> <00af01cc0aa7$845a5330$8d0ef990$@net> <8695009A81378E48879980039EEDAD289D0E5BD9@MAIL1.polartel.local> <5542F2FC72CC4995A4205A4C1C844F5E@mike> <0492060B-A00F-4C1E-9722-90F6A00ABD94@arin.net> <61A AC8E6-F419-4792-95DB-2D5CE485580D@delong.com> <0a9601cc0c21$40f390e0$c2dab2a0$@net> Message-ID: <011C5185-E0FF-4010-B991-31E709D6AC14@delong.com> Actually, not so much... The resulting organization would still be subject to a section 12 audit and appropriate reclamation of the unused space. Owen On May 6, 2011, at 12:10 PM, Warren Johnson wrote: > Regardless of policy, this can be achieved by purchasing a controlling share > in the organization that already holds the resource and altering its > operation. > >> >> What if you need a /18, but, know that by purchasing the equivalent >> of a /6, you can cause significantly larger additional costs to your >> competitors, possibly even pricing some of them out of the market? >> You have the cash to do it, should this be allowed? >> >> (Hint... I think some of your competitors can afford that /6 to keep you >> from getting your /18). >> >> 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 owen at delong.com Mon May 9 22:20:59 2011 From: owen at delong.com (Owen DeLong) Date: Mon, 9 May 2011 19:20:59 -0700 Subject: [arin-ppml] Draft Proposal for Needs-Free IPv4 Transfers In-Reply-To: <323AD9AC0BE24F9BB91D3E712160681A@mike> References: <323AD9AC0BE24F9BB91D3E712160681A@mike> Message-ID: <77338713-58D2-47AA-9045-C5D19DBB8DA0@delong.com> I cannot support the proposal as written. If he removed the option of the recipient signing any RSA other than the standard RSA, I could support it. I do not support granting LRSA to transfer recipients. The LRSA provides special benefits that are intended to make it attractive for existing legacy holders to join the ARIN community. There is no reason to extend such advantages to new resource recipients. Further, the ability to have ARIN recognize transfers without any RSA at all is utterly unacceptable. Owen On May 9, 2011, at 12:15 PM, Mike Burns wrote: > Hello, > > Upon feedback to my first draft proposal whose intent is to lift needs requirements for all IPv4 transfers, I have made some changes to my draft proposal. > > One of the issues was the idea that if I made no changes to section 12, that ARIN could do a resource review of the transferree and if they determined the addresses were not being used, could request them to be returned. > > I have read section 12 of the NRPM, and could find no language that gives ARIN that right. Basically section 12 is about fraud and about compliance with existing policy, but there is no existing policy that I could find requiring anything like efficient utilization of allocations, except in reference to a new or subsequent allocation. But once an allocation is made, I could find no policy requiring efficient utilization of that block if no further allocation request is made. > > On the other hand, the current RSA has clear language in section 8 that allows ARIN to review previous allocations and allows ARIN to determine if their use is consistent with the intended purpose as presented on the application at the time of the allocation request: > > 8. REVIEW OF APPLICANT?S NUMBER RESOURCES > ARIN may review, at any time, Applicant?s use of previously allocated or assigned number resources or Services received from ARIN to determine if Applicant is complying with this Agreement and the Policies and is using the Services for their intended purposes. Without limiting the foregoing, if Applicant is a holder of a direct allocation or assignment from ARIN, Applicant agrees that it will use the number resources solely for uses consistent with its application and this Agreement, including, for example, its internal infrastructure or to provide Internet access to its customer base. If ARIN determines that the number resources or any other Services are not being used in compliance with this Agreement, the Policies, or the purposes for which they are intended, ARIN may: (i) revoke the number resources; (ii) cease providing the Services to Applicant; and/or (iii) terminate this Agreement. > > (To my reading, if you got an allocation in 2001 for web hosting purposes, and now you are using the addresses to provide DSL service, ARIN could revoke them for not being used for purposes consistent with the Applicant's application unless you notify them and get approval. But let's leave that aside.) > > Since my overarching purpose is to bring as much supply into the market as possible, I don't want any old allocations to stay unused on the shelf because the holder is afraid of a recovery action. > > But if section 12 does not allow ARIN to make a resource finding requesting return of addresses merely for underutilization, and if we remove the language in the RSA allowing ARIN to recover based on compliance with intended use, then an entity could totally fake a justification and get a new allocation today, and turn around tomorrow and list the addreses for sale, and ARIN wouldn't have any teeth with which to revoke the addresses. (Unless of course they could show the justification part of the application was fraudulent.) > > In order to preclude that, I have added a new source requirement to the source entity for transfers, that they may not have received an ARIN allocation for at least 12 months prior to the transfer. > > In addition, in my new draft proposal I retained the 8.2 transfer mechanism, which can still be used for ASN and IPv6 transfers via mergers and acquisitions. > > I also added language forcing no downgrading of current agreement status which covers the transferred addresses, i.e. RSA to RSA, LRSA to LRSA or RSA, no agreement to no agreement or LRSA. > > In my rationale, I have limited myself to the benefits of whois accuracy which will inure from the greater likelihood that all past and future transfers will be registered. > > From the discussion, you know that I believe that stewardship demands that we make policy to ensure whois reliablity in the face of a new paradigm for IPv4 distribution. IPv4 addresses will change hands in a variety of transaction types. If those who engage in these transactions do not choose to have ARIN update whois to reflect them, we run the risk of whois irrelevance and provide the vacuum in to which competitive registries will step, with or without global community authority. If transactors find little cost in having ARIN update whois to reflect the transfer, they are more likely to request that ARIN make the update. If the transaction cost is high, fewer will make that request, leading to a less and less reliable whois, which could degrade to the point where network operators choose a more reliable registry. This kind of chaos in the core of the Internet would be an indictment of ARIN stewardship. > > We will run out of free pool addresses shortly. At that point we will not be stewards of those addresses anymore. We will, however, retain our stewardship role towards maintaining whois as an authoritative source for routing authority. Prior to exhaust, it was possible to ignore whois, as conflicts over address control were unlikely when "free" addresses were available. In the post-exahaust world, where address control conflict is likely to increase, it is all the more important that whois be a trusted and accurate information source. > > Now it could be that I have misread section 12, I know I heard from more than one person that ARIN could revoke for underutilization. If you can point me to what I am missing, then maybe I will have to monkey with section 12. My hope is that by simply changing 8.3 and the RSA I can avoid that. > > I agree with John Curran's posting this week about simplifying transfer requirements, and have retained the /24 minimum for the reasons he mentioned. > > Regards, > > Mike Burns > > > > > > > > > > 1. Policy Proposal Name: New IPv4 Transfer policy > > 2. Proposal Originator: > a. Name: Mike Burns > b. Email: mike at sum.net > c. Phone: 1-863-494-7692 x105 > d. Organization: Nationwide Computer Systems > > 3. Proposal Version: 1 > > 4. Date: May 9th, 2011 > > 5. Proposal type: modify > > 6. Policy term: permanent > > 7. Policy statement: > > Replace Section 8.3 with > > 8.3 ARIN will process and record IPv4 address transfer requests. > > Conditions on the IPv4 address block: > > - The minimum transfer size is a /24 > > - The address block must be in the range of addresses administered > by ARIN > > Conditions on source of the transfer: > > - The source entity must be the current rights 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 the transfer, or until the exhaustion of ARIN's > IPv4 space, whichever occurs first. > > - The source entity must not have received an allocation from ARIN for the 12 months prior to the transfer. > > > Conditions on recipient of the transfer: > > - The recipient entity must be a current ARIN account holder. > If the addresses being transferred are under RSA, the recipient must sign an RSA with ARIN. > If the addresses being transferred are under LRSA, the recipient must sign an LRSA or an RSA with ARIN. > If the addresses being transferred are legacy addresses under no form of RSA, recipient may choose to sign an LRSA, but will not be required to do so. > > - The recipient entity of the transferred resources will be subject > to current ARIN policies. In particular, in any subsequent ARIN > IPv4 address allocation request, the recipient will be required > to account for the efficient utilization of all IPv4 address > space held, including all transferred resources. > > and modify section 12.8 of the current RSA to remove references to "intended purposes." > > Replace > ARIN may review, at any time, Applicant?s use of previously allocated or assigned number resources or Services received from ARIN to determine if Applicant is complying with this Agreement and the Policies and is using the Services for their intended purposes. Without limiting the foregoing, if Applicant is a holder of a direct allocation or assignment from ARIN, Applicant agrees that it will use the number resources solely for uses consistent with its application and this Agreement, including, for example, its internal infrastructure or to provide Internet access to its customer base. If ARIN determines that the number resources or any other Services are not being used in compliance with this Agreement, the Policies, or the purposes for which they are intended, ARIN may: (i) revoke the number resources; (ii) cease providing the Services to Applicant; and/or (iii) terminate this Agreement. > > with > > ARIN may review, at any time, any Applicant?s use of previously allocated or assigned number resources or Services received from ARIN to determine if Applicant is complying with this Agreement and the Policies. Without limiting the foregoing, if Applicant is a holder of a direct allocation or direct assignment from ARIN, Applicant agrees that it will use the number resources solely for uses consistent with this Agreement, including, for example, its internal infrastructure or to provide Internet access to its customer base. If ARIN determines that the number resources or any other Services are not being used in compliance with this Agreement or the Policies, ARIN may: (i) revoke the number resources; (ii) cease providing the Services to Applicant; and/or (iii) terminate this Agreement. > > > > > 8. Rationale: > > Current ARIN policies relating to the registration of transfer of > address holdings limit the eligibility of registration of transfers to > those relating to mergers and acquisitions of entities that are > administering an operational network, or to those who agree to > sign either an RSA or LRSA with ARIN and subject the buyer > to needs analysis and the seller to a potential ARIN review under RSA section 8. > > It is currently anticipated that the IPv4 unallocated address pool > will be exhausted within a couple of years at ARIN, and earlier > than that in other regions, and the transition to IPv6-based service delivery > is likely to take longer than the remaining period of unallocated > address availability. Accordingly, it is likely that demand for IPv4 > addresses will continue beyond the time of unallocated address pool > exhaustion, leading to a period of movement of IPv4 address blocks > between address holders to meet such continuing demand for IPv4 > address blocks. > > The underlying proposition behind this policy proposal is that the > registry of IPv4 addresses operated by ARIN is of general utility and > value only while it accurately describes the current state of address > distribution. If a class of address movement transactions are excluded > from being entered in the registry, then the registry will have > decreasing value to the broader community, and the integrity of the > network itself is thereby compromised. This proposal's central aim is > to ensure the continuing utility and value of the ARIN address > registry by allowing the registry to record transactions where IPv4 > addresses are transfered between ARIN account holders. > > It proposes that ARIN will recognise and register a transfer of > addresses where the parties to the transfer are 'known' to ARIN and > that the address block being transferred is part of ARIN's current address set. > > The proposal does not prescribe how such transfers may occur, nor > impose any further constraints on the transfer or on the parties > involved other than those described in this proposal. > > 9. 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 tedm at ipinc.net Mon May 9 23:52:29 2011 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Mon, 09 May 2011 20:52:29 -0700 Subject: [arin-ppml] Draft Proposal for Needs-Free IPv4 Transfers In-Reply-To: References: <323AD9AC0BE24F9BB91D3E712160681A@mike> <4DC84FC0.6070708@ipinc.net> Message-ID: <4DC8B67D.80208@ipinc.net> On 5/9/2011 6:14 PM, Matthew Kaufman wrote: > > On May 9, 2011, at 1:34 PM, Ted Mittelstaedt wrote: > >> >> In my opinion, the FACT that none of the Legacy holders, when they >> needed additional resources, have attempted to just pull numbers >> out of their ass, but instead have in fact gone to the RIR's for >> more numbers, means that in effect the concept of "adverse >> possession" has happened. >> >> In short, the RIR's have exerted authority over the IP space, and >> for the last decade none of the Legacy holders have disputed this, >> and as a result, the Legacy holders have lost whatever rights that >> they might have had to dispute RIR control of the ENTIRE IPv4& >> IPv6 space. > > That isn't how it works. > > If I put a fence around a 10 acre corner of your 100-acre plot and > you don't object to the fence, then after some years I can claim > adverse possession over the 10 acres... not your entire 100-acre > plot. > except this is a situation where in effect the 10 acre corner is the ONLY access to your 100 acre plot (it's the only section of your land that is next to a road and the county won't issue you a permit for a driveway for anywhere except within that 10 acres) >> >> Thus I believe that even though the right of ARIN to pull IPv4 >> numbers from Legacy holders is not enumerated in the NRPM, that >> under most legal systems they do have that right today, simply >> because none of the Legacy holders have attempted to deny them that >> over the last decade. > > None of the legacy holders have attempted to deny them the ability to > assign from the unassigned space... but that's difference. > > And none of this matters if the address space *isn't* property. > which is why ARIN is so insistent that IP addresses aren't property. I still feel much of this is dependent on what transpired between the Legacy holders during the formation of the RIR system. When ARIN was formed ALL IP assignments in operation were legacy. Yet during the entire time of the RIR's existence none of the Legacy holders attempted to transfer IP addresses? I find that very hard to believe in the absence of some hidden agreement by the Legacy holders to respect the authority of the RIR. Even years ago, Legacy addresses were worth something. If I could have got our /19 transferred from a Legacy holder years ago, we would not have paid fifteen thousand dollars (to date) in fees to ARIN. We would have paid nothing. Ted > Matthew Kaufman > > From tedm at ipinc.net Mon May 9 23:54:56 2011 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Mon, 09 May 2011 20:54:56 -0700 Subject: [arin-ppml] transfer conditions In-Reply-To: <1E077822-6D5F-459F-B312-1DD8F7447B40@matthew.at> References: <75E9BD24-F12F-42BF-A989-CF6CC282B28E@arin.net> <49E26DCB-DAF7-4A0A-912E-F981494979F5@delong.com> <4DBC2AEB.9040307@matthew.at> <4DBCA58D.4060704@sprunk.org> <2344ADD7-616E-4FA7-9552-19735926A952@delong.com> <391BFA8C-9D09-4BB2-8D49-FD5F9C6FDF93@arin.net> <6B951089-C686-4929-AC21-A1BF91BBBCB7@delong.com> <22A6B158-1CBC-4C35-A842-0BD029B2461C@arin.net> <9CDB0040-AFFD-4A90-94D9-821003EE5B8F@matthew.at> <4DC86F77.2060101@ipinc.n et> <1E077822-6D5F-459F-B312-1DD8F7447B40@matthew.at> Message-ID: <4DC8B710.8050801@ipinc.net> On 5/9/2011 6:09 PM, Matthew Kaufman wrote: > > On May 9, 2011, at 3:49 PM, Ted Mittelstaedt wrote: > >> On 5/8/2011 10:48 AM, Jimmy Hess wrote: >>> On Sat, May 7, 2011 at 11:04 PM, Matthew Kaufman wrote: >>> >>>> Why don't we just start by disallowing all transfers smaller than, say, /19... and then adjusting that downward (in block size... upward in mask length) as the market shows that it can't function with the simultaneous combination of needs-justification-requirements and minimum-block/aggregate-sizes? >>> >>> Why don't we start by disallowing all transfers smaller than the >>> minimum allocation size for the block? >>> >>> And use /22 as the minimum allocation size for any legacy block of >>> which /16s were assigned' >>> /20 as the minimum allocation size for any legacy block of size /8 or >>> shorter were assigned? >>> >>> ARIN allocates prefixes longer than /19, so /19 restriction seems a bit much >>> >> >> I would be willing to accept a /24 minimum size transfer AS LONG AS it >> was tied to a mandate for the receiving party to sign an RSA. > > > All of the versions of the LRSA, and all of the modifications of "The RSA" are "an RSA" oops, good catch! Damn I'm going to have to get sneakier in my thinking! Ted >> >> I wouldn't like it, but obviously ARIN does not like forcing the recieving party to sign an RSA, > > No, they're fine with "an RSA", just not "The RSA and Only The RSA" > > Matthew Kaufman > > From mysidia at gmail.com Tue May 10 00:05:18 2011 From: mysidia at gmail.com (Jimmy Hess) Date: Mon, 9 May 2011 23:05:18 -0500 Subject: [arin-ppml] Draft Proposal for Needs-Free IPv4 Transfers In-Reply-To: <77338713-58D2-47AA-9045-C5D19DBB8DA0@delong.com> References: <323AD9AC0BE24F9BB91D3E712160681A@mike> <77338713-58D2-47AA-9045-C5D19DBB8DA0@delong.com> Message-ID: On Mon, May 9, 2011 at 9:20 PM, Owen DeLong wrote: > RSA, I could support it. I do not support granting LRSA to transfer > recipients. The LRSA provides special benefits that are intended to I agree. The LRSA is an agreement between ARIN and a legacy resource holder. A transfer recipient is not a legacy resource holder; a transfer recipient is a new resource holder. Also, there is no reason ARIN should adopt a more lax policy in anticipation that a resource holder will ignore their obligations in attempting to make 'undocumented' transfers not allowed by policy. Legitimizing non-needs-based transfers would encourage them. It is questionable whether black market transfers would even be attempted, otherwise, by any legacy holders with significant number resources assigned to their network. > Owen -- -JH From mysidia at gmail.com Tue May 10 00:36:56 2011 From: mysidia at gmail.com (Jimmy Hess) Date: Mon, 9 May 2011 23:36:56 -0500 Subject: [arin-ppml] transfer conditions In-Reply-To: <1E077822-6D5F-459F-B312-1DD8F7447B40@matthew.at> References: <75E9BD24-F12F-42BF-A989-CF6CC282B28E@arin.net> <8740380157159276993@unknownmsgid> <49E26DCB-DAF7-4A0A-912E-F981494979F5@delong.com> <4DBC2AEB.9040307@matthew.at> <4DBCA58D.4060704@sprunk.org> <2344ADD7-616E-4FA7-9552-19735926A952@delong.com> <391BFA8C-9D09-4BB2-8D49-FD5F9C6FDF93@arin.net> <6B951089-C686-4929-AC21-A1BF91BBBCB7@delong.com> <22A6B158-1CBC-4C35-A842-0BD029B2461C@arin.net> <9CDB0040-AFFD-4A90-94D9-821003EE5B8F@matthew.at> <4DC86F77.2060101@ipinc.net> <1E077822-6D5F-459F-B312-1DD8F7447B40@matthew.at> Message-ID: On Mon, May 9, 2011 at 8:09 PM, Matthew Kaufman wrote: > On May 9, 2011, at 3:49 PM, Ted Mittelstaedt wrote: > All of the versions of the LRSA, and all of the modifications of "The RSA" are "an RSA" >> I wouldn't like it, but obviously ARIN does not like forcing the recieving party to sign an RSA, > No, they're fine with "an RSA", just not "The RSA and Only The RSA" > Matthew Kaufman When I say and see "RSA" in the 8.3 transfer policy; I take that to mean the unmodified, standard RSA signed for new allocations by ARIN. And "LRSA" to be the special modified RSA for legacy holders. Do you suggest ARIN staff have taken a liberty to not implement it in that manner? I expect transfer recipients to be required to sign the RSA equivalent to the standard RSA signed by receivers of new allocations. That is, a RSA that does not provide the transfer recipient any benefits, more rights, provide any fewer restrictions on the transfer recipient, than the new allocation RSA, and does not restrict ARIN or cause ARIN to surrender any rights not surrendered when the allocation recipient enteres into a standard RSA. -- -JH From matthew at matthew.at Tue May 10 00:39:30 2011 From: matthew at matthew.at (Matthew Kaufman) Date: Mon, 9 May 2011 21:39:30 -0700 Subject: [arin-ppml] ARIN-prop-146 Clarify Justified Need for Transfers In-Reply-To: <011C5185-E0FF-4010-B991-31E709D6AC14@delong.com> References: <4DBEF120.4080901@arin.net> <88F39B20-5C20-45F0-AD61-5FA1E7F84CE3@delong.com> <4DBF6727.1090303@matthew.at> <097AAC1C-1F68-4820-9274-3290ADEFA195@delong.com> <9501EA7E-FDAD-4DDA-B9E8-08C2811FF642@delong.com> <4DBF82F6.7050608@matthew.at> <20110503145144.N15967@mail.inlandnet.com> <4DC084E7.5000302@matthew.at> <4DC08664.4060905@matthew.at> <4791A59E-8864-483C-9BB0-03A6A5B8D50C@delong.com> <66466F57-4365-4ADB-94EB-E023F01B17CB@delong.com> <30D12BA8-9A6C-4E62-9A67-8B4FEA0EA8C1@matthew.at> <00af01cc0aa7$845a5330$8d0ef990$@net> <8695009A81378E48879980039EEDAD289D0E5BD9@MAIL1.polartel.local> <5542F2FC72CC4995A4205A4C1C844F5E@mike> <0492060B-A00F-4C1E-9722-90F6A00ABD94@arin.net> <61A AC8E6-F419-4792-95DB-2D5CE485580D@delong.com> <0a9601cc0c21$40f390e0$c2dab2a0$@net> <011C5185-E0FF-4010-B991-31E709D6AC14@delong.com> Message-ID: On May 9, 2011, at 7:09 PM, Owen DeLong wrote: > Actually, not so much... The resulting organization would still be subject > to a section 12 audit and appropriate reclamation of the unused space. > Given that no section 12 audit resulted in a significant return from the HP + DEC/Compaq merger, I will simply assume that you're just wrong about this. Matthew Kaufman From matthew at matthew.at Tue May 10 00:50:23 2011 From: matthew at matthew.at (Matthew Kaufman) Date: Mon, 9 May 2011 21:50:23 -0700 Subject: [arin-ppml] transfer conditions In-Reply-To: References: <75E9BD24-F12F-42BF-A989-CF6CC282B28E@arin.net> <8740380157159276993@unknownmsgid> <49E26DCB-DAF7-4A0A-912E-F981494979F5@delong.com> <4DBC2AEB.9040307@matthew.at> <4DBCA58D.4060704@sprunk.org> <2344ADD7-616E-4FA7-9552-19735926A952@delong.com> <391BFA8C-9D09-4BB2-8D49-FD5F9C6FDF93@arin.net> <6B951089-C686-4929-AC21-A1BF91BBBCB7@delong.com> <22A6B158-1CBC-4C35-A842-0BD029B2461C@arin.net> <9CDB0040-AFFD-4A90-94D9-821003EE5B8F@matthew.at> <4DC86F77.2060101@ipinc.n et> <1E077822-6D5F-459F-B312-1DD8F7447B40@matthew.at> Message-ID: <1B32A1B5-0FFC-4C58-93F3-9C984E42F5AB@matthew.at> On May 9, 2011, at 9:36 PM, Jimmy Hess wrote: > On Mon, May 9, 2011 at 8:09 PM, Matthew Kaufman wrote: >> On May 9, 2011, at 3:49 PM, Ted Mittelstaedt wrote: >> All of the versions of the LRSA, and all of the modifications of "The RSA" are "an RSA" >>> I wouldn't like it, but obviously ARIN does not like forcing the recieving party to sign an RSA, >> No, they're fine with "an RSA", just not "The RSA and Only The RSA" >> Matthew Kaufman > > When I say and see "RSA" in the 8.3 transfer policy; I take that to mean > the unmodified, standard RSA signed for new allocations by ARIN. > And "LRSA" to be the special modified RSA for legacy holders. Well, since "RSA" is not currently defined in the NRPM anywhere, it could mean anything they want, I suppose. Note that even the "normal RSA" gets modified for certain entities, and the LRSA is also often "customized" > > Do you suggest ARIN staff have taken a liberty to not implement it in > that manner? > That is the only way that the public statements made regarding the Nortel/Microsoft transfer make any sense. There's evidence that "a LRSA" was signed and evidence that "policy 8.3 was followed". > I expect transfer recipients to be required to sign the RSA equivalent to > the standard RSA signed by receivers of new allocations. > Well, that isn't what has happened, at least once. I have a policy proposal that clarifies what might happen... please comment on it (I'm guessing you would NOT support it, given your position about which RSA should be required) Matthew Kaufman From mysidia at gmail.com Tue May 10 01:10:30 2011 From: mysidia at gmail.com (Jimmy Hess) Date: Tue, 10 May 2011 00:10:30 -0500 Subject: [arin-ppml] transfer conditions In-Reply-To: <1B32A1B5-0FFC-4C58-93F3-9C984E42F5AB@matthew.at> References: <75E9BD24-F12F-42BF-A989-CF6CC282B28E@arin.net> <8740380157159276993@unknownmsgid> <49E26DCB-DAF7-4A0A-912E-F981494979F5@delong.com> <4DBC2AEB.9040307@matthew.at> <4DBCA58D.4060704@sprunk.org> <2344ADD7-616E-4FA7-9552-19735926A952@delong.com> <391BFA8C-9D09-4BB2-8D49-FD5F9C6FDF93@arin.net> <6B951089-C686-4929-AC21-A1BF91BBBCB7@delong.com> <22A6B158-1CBC-4C35-A842-0BD029B2461C@arin.net> <9CDB0040-AFFD-4A90-94D9-821003EE5B8F@matthew.at> <1E077822-6D5F-459F-B312-1DD8F7447B40@matthew.at> <1B32A1B5-0FFC-4C58-93F3-9C984E42F5AB@matthew.at> Message-ID: On Mon, May 9, 2011 at 11:50 PM, Matthew Kaufman wrote: > On May 9, 2011, at 9:36 PM, Jimmy Hess wrote: >> On Mon, May 9, 2011 at 8:09 PM, Matthew Kaufman wrote: > Note that even the "normal RSA" gets modified for certain entities, and the LRSA is also often "customized" > In what way does the RSA get "modified" for certain entities? Do we have examples? I would suggest at least the requirement that the RSA used match a RSA published in the "Agreements" section of ARIN's website. Some organizations getting private RSAs of their choosing would be inconsistent with ARIN treating all organizations that receive service impartially. 'Special' organizations should not have have rights, waiver of community developed policies, or other privileges granted to them by ARIN, not afforded to others, just because they are X, and "X is special". -- -JH From matthew at matthew.at Tue May 10 01:31:38 2011 From: matthew at matthew.at (Matthew Kaufman) Date: Mon, 9 May 2011 22:31:38 -0700 Subject: [arin-ppml] transfer conditions In-Reply-To: References: <75E9BD24-F12F-42BF-A989-CF6CC282B28E@arin.net> <8740380157159276993@unknownmsgid> <49E26DCB-DAF7-4A0A-912E-F981494979F5@delong.com> <4DBC2AEB.9040307@matthew.at> <4DBCA58D.4060704@sprunk.org> <2344ADD7-616E-4FA7-9552-19735926A952@delong.com> <391BFA8C-9D09-4BB2-8D49-FD5F9C6FDF93@arin.net> <6B951089-C686-4929-AC21-A1BF91BBBCB7@delong.com> <22A6B158-1CBC-4C35-A842-0BD029B2461C@arin.net> <9CDB0040-AFFD-4A90-94D9-821003EE5B8F@matthew.at> <1E077822-6D5F-459F-B312- 1DD8F7447B40@matthew.at> <1B32A1B5-0FFC-4C58-93F3-9C984E42F5AB@matthew.at> Message-ID: <2AC9E61E-B43A-4F9E-A589-7818FFC05C21@matthew.at> On May 9, 2011, at 10:10 PM, Jimmy Hess wrote: > On Mon, May 9, 2011 at 11:50 PM, Matthew Kaufman wrote: >> On May 9, 2011, at 9:36 PM, Jimmy Hess wrote: >>> On Mon, May 9, 2011 at 8:09 PM, Matthew Kaufman wrote: > >> Note that even the "normal RSA" gets modified for certain entities, and the LRSA is also often "customized" >> > In what way does the RSA get "modified" for certain entities? > Do we have examples? > > I would suggest at least the requirement that the RSA used > match a RSA published in the "Agreements" section of ARIN's website. > > Some organizations getting private RSAs of their choosing would be inconsistent > with ARIN treating all organizations that receive service impartially. > > 'Special' organizations should not have have rights, waiver of > community developed > policies, or other privileges granted to them by ARIN, not afforded to others, > just because they are X, and "X is special". From a recent slide deck entitled "IPv4 Report" presented by John Curran: For the unique legal and operational requirements of government entities, ARIN will make appropriate modifications to its RSAs and LRSAs including: - modification or deletion of the indemnification provision, - modification or deletion of the bankruptcy provision, - revision to the choice of law provision, -Amending the dispute resolution section consistent with statute, and -Other issues as needed. So at *the very least* modifications are apparently available if you are a government entity. Matthew Kaufman From owen at delong.com Tue May 10 01:31:37 2011 From: owen at delong.com (Owen DeLong) Date: Mon, 9 May 2011 22:31:37 -0700 Subject: [arin-ppml] ARIN-prop-146 Clarify Justified Need for Transfers In-Reply-To: References: <4DBEF120.4080901@arin.net> <88F39B20-5C20-45F0-AD61-5FA1E7F84CE3@delong.com> <4DBF6727.1090303@matthew.at> <097AAC1C-1F68-4820-9274-3290ADEFA195@delong.com> <9501EA7E-FDAD-4DDA-B9E8-08C2811FF642@delong.com> <4DBF82F6.7050608@matthew.at> <20110503145144.N15967@mail.inlandnet.com> <4DC084E7.5000302@matthew.at> <4DC08664.4060905@matthew.at> <4791A59E-8864-483C-9BB0-03A6A5B8D50C@delong.com> <66466F57-4365-4ADB-94EB-E023F01B17CB@delong.com> <30D12BA8-9A6C-4E62-9A67-8B4FEA0EA8C1@matthew.at> <00af01cc0aa7$845a5330$8d0ef990$@net> <8695009A81378E48879980039EEDAD289D0E5BD9@MAIL1.polartel.local> <5542F2FC72CC4995A4205A4C1C844F5E@mike> <0492060B-A00F-4C1E-9722-90F6A00ABD94@arin.net> <61A AC8E6-F419-4792-95DB-2D5CE485580D@delong.com> <0a9601cc0c21$40f390e0$c2dab2a0$@net> <011C5185-E0FF-4010-B991-31E709D6AC14@delong.com> Message-ID: <661D8335-34EE-4669-A0F5-E7AF7C9B6048@delong.com> On May 9, 2011, at 9:39 PM, Matthew Kaufman wrote: > > On May 9, 2011, at 7:09 PM, Owen DeLong wrote: > >> Actually, not so much... The resulting organization would still be subject >> to a section 12 audit and appropriate reclamation of the unused space. >> > > Given that no section 12 audit resulted in a significant return from the HP + DEC/Compaq merger, I will simply assume that you're just wrong about this. > > Matthew Kaufman That occurred prior to the enactment of section 12. Try again. Owen From owen at delong.com Tue May 10 01:33:08 2011 From: owen at delong.com (Owen DeLong) Date: Mon, 9 May 2011 22:33:08 -0700 Subject: [arin-ppml] transfer conditions In-Reply-To: References: <75E9BD24-F12F-42BF-A989-CF6CC282B28E@arin.net> <8740380157159276993@unknownmsgid> <49E26DCB-DAF7-4A0A-912E-F981494979F5@delong.com> <4DBC2AEB.9040307@matthew.at> <4DBCA58D.4060704@sprunk.org> <2344ADD7-616E-4FA7-9552-19735926A952@delong.com> <391BFA8C-9D09-4BB2-8D49-FD5F9C6FDF93@arin.net> <6B951089-C686-4929-AC21-A1BF91BBBCB7@delong.com> <22A6B158-1CBC-4C35-A842-0BD029B2461C@arin.net> <9CDB0040-AFFD-4A90-94D9-821003EE5B8F@matthew.at> <4DC86F77.2060101@ipinc.! net> <1E077822-6D5F-459F-B312-1DD8F7447B40@matthew.at> Message-ID: <2716F581-B7DC-45BC-AED1-5CD217A28662@delong.com> On May 9, 2011, at 9:36 PM, Jimmy Hess wrote: > On Mon, May 9, 2011 at 8:09 PM, Matthew Kaufman wrote: >> On May 9, 2011, at 3:49 PM, Ted Mittelstaedt wrote: >> All of the versions of the LRSA, and all of the modifications of "The RSA" are "an RSA" >>> I wouldn't like it, but obviously ARIN does not like forcing the recieving party to sign an RSA, >> No, they're fine with "an RSA", just not "The RSA and Only The RSA" >> Matthew Kaufman > > When I say and see "RSA" in the 8.3 transfer policy; I take that to mean > the unmodified, standard RSA signed for new allocations by ARIN. > And "LRSA" to be the special modified RSA for legacy holders. > A lot of us did. Unfortunately, ARIN staff did not. > Do you suggest ARIN staff have taken a liberty to not implement it in > that manner? > That is what John Curran has stated when he explained that M$ signed a modified LRSA for the numbers they acquired from Nortel. > I expect transfer recipients to be required to sign the RSA equivalent to > the standard RSA signed by receivers of new allocations. > Agreed. > That is, a RSA that does not provide the transfer recipient any benefits, > more rights, provide any fewer restrictions on the transfer recipient, than > the new allocation RSA, and does not restrict ARIN or cause ARIN to surrender > any rights not surrendered when the allocation recipient enteres into > a standard RSA. > That is my preference as well. Owen From owen at delong.com Tue May 10 01:38:38 2011 From: owen at delong.com (Owen DeLong) Date: Mon, 9 May 2011 22:38:38 -0700 Subject: [arin-ppml] transfer conditions In-Reply-To: References: <75E9BD24-F12F-42BF-A989-CF6CC282B28E@arin.net> <8740380157159276993@unknownmsgid> <49E26DCB-DAF7-4A0A-912E-F981494979F5@delong.com> <4DBC2AEB.9040307@matthew.at> <4DBCA58D.4060704@sprunk.org> <2344ADD7-616E-4FA7-9552-19735926A952@delong.com> <391BFA8C-9D09-4BB2-8D49-FD5F9C6FDF93@arin.net> <6B951089-C686-4929-AC21-A1BF91BBBCB7@delong.com> <22A6B158-1CBC-4C35-A842-0BD029B2461C@arin.net> <9CDB0040-AFFD-4A90-94D9-821003EE5B8F@matthew.at> <1E077822-6D5F-459F-B312! -1DD8F7447B40@matthew.at> <1B32A1B5-0FFC-4C58-93F3-9C984E42F5AB@matthew.at> Message-ID: On May 9, 2011, at 10:10 PM, Jimmy Hess wrote: > On Mon, May 9, 2011 at 11:50 PM, Matthew Kaufman wrote: >> On May 9, 2011, at 9:36 PM, Jimmy Hess wrote: >>> On Mon, May 9, 2011 at 8:09 PM, Matthew Kaufman wrote: > >> Note that even the "normal RSA" gets modified for certain entities, and the LRSA is also often "customized" >> > In what way does the RSA get "modified" for certain entities? > Do we have examples? > Some examples that have been cited in the past include modification removing indemnity clauses from RSAs issued to certain government bodies or government run institutions which have legal prohibitions that would prevent them from signing such a contract. > I would suggest at least the requirement that the RSA used > match a RSA published in the "Agreements" section of ARIN's website. > Modulo reasonable accommodations to local governing law or specific laws applicable to the institution in question such as shown above, I agree. > Some organizations getting private RSAs of their choosing would be inconsistent > with ARIN treating all organizations that receive service impartially. > I don't believe that is what is happening. > 'Special' organizations should not have have rights, waiver of > community developed > policies, or other privileges granted to them by ARIN, not afforded to others, > just because they are X, and "X is special". > I believe John Curran has stated that all such modifications have not been to these core issues, but, rather revolve around satisfying certain government mandates. Owen From farmer at umn.edu Tue May 10 02:02:46 2011 From: farmer at umn.edu (David Farmer) Date: Tue, 10 May 2011 01:02:46 -0500 Subject: [arin-ppml] New IPv4 Transfer policy In-Reply-To: <4DC86683.90204@ipinc.net> References: <0F4E49B9-09DB-434F-AD5D-87DA3DCC42D8@matthew.at> <4DC86683.90204@ipinc.net> Message-ID: <4DC8D506.3010203@umn.edu> On 5/9/11 17:11 CDT, Ted Mittelstaedt wrote: > Ask ARIN > > Financially, the fees for the block of numbers that Microsoft got > from that transfer are nothing in comparison to what they paid for > it, and Microsoft is also known for spending tons of money on > useless stuff. So there must have been some difference between > the RSA and the LRSA that made Microsoft choose the LRSA and the > only thing I can think of is the LRSA is less restrictive in some > manner. > > I suspect we need to have ARIN modify the LRSA. The LRSA was sold > to us on the basis that it was the same thing as the RSA without > the annual fee. Obviously, the Microsoft lawyers found out that > this wasn't true. ARIN has a lot of explaining to do, here. > > Ted I'm not sure what you feel you were sold. However, the details of the LRSA are not secret, have been published for sometime, and there is more than just a difference in fees for Legacy ISPs. Note: Legacy end users pay the same annual fees as any other end user. So, your view on the difference, or lack there of, in the fees can vary significantly depending on your perspective. There has been a FAQ regarding the LRSA for sometime as well, the current version is at; https://www.arin.net/resources/legacy/ It provides an excellent summary of the LRSA, for those who aren't into recreationally reading contracts. :) I know the LRSA, and the RSA, almost put me to sleep when I had to read it as part of getting my organization to sign them. :) I only survived with the assistance of multiple caffeinated beverages. :) I'll also add that a number of improvements have been made in the LRSA since its initial version, and a number of these improvements have been integrated into the RSA as well, for the benefit of everyone who has received resources from ARIN. -- =============================================== 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 gary.buhrmaster at gmail.com Tue May 10 02:07:28 2011 From: gary.buhrmaster at gmail.com (Gary Buhrmaster) Date: Mon, 9 May 2011 23:07:28 -0700 Subject: [arin-ppml] transfer conditions In-Reply-To: References: <75E9BD24-F12F-42BF-A989-CF6CC282B28E@arin.net> <8740380157159276993@unknownmsgid> <49E26DCB-DAF7-4A0A-912E-F981494979F5@delong.com> <4DBC2AEB.9040307@matthew.at> <4DBCA58D.4060704@sprunk.org> <2344ADD7-616E-4FA7-9552-19735926A952@delong.com> <391BFA8C-9D09-4BB2-8D49-FD5F9C6FDF93@arin.net> <6B951089-C686-4929-AC21-A1BF91BBBCB7@delong.com> <22A6B158-1CBC-4C35-A842-0BD029B2461C@arin.net> <9CDB0040-AFFD-4A90-94D9-821003EE5B8F@matthew.at> <1E077822-6D5F-459F-B312-1DD8F7447B40@matthew.at> <1B32A1B5-0FFC-4C58-93F3-9C984E42F5AB@matthew.at> Message-ID: On Mon, May 9, 2011 at 22:10, Jimmy Hess wrote: .... > In what way does the RSA get "modified" for certain entities? I believe it has been claimed that certain government agencies have, with consultation with their and ARIN staff/consul, made some changes that were required under their interpretations of applicable laws and regulations. I have no doubt that others proposed, and some may have received, modifications. >From my recollection of the RSA (and some conjecture), for example, things like agreeing that a certain state legal interpretation overrides federal law may be a bridge too far for some feds and their purchasing officers. But I have no special knowledge to know whether that conjecture may be true or not. > Do we have examples? I suspect that all examples are NDA (as any contracts probably should be, unless the policies were to be amended to require full disclosure, which probably would result in different challenges). > I would suggest at least the requirement that the RSA used > match a RSA published in the "Agreements" section of ARIN's website. If that is what you want, then it should be explicitly proposed, and if adopted, implemented as such. When you provide ambiguity, lawyers will find an answer to best meet their clients needs (which may not always be what you intended). > Some organizations getting private RSAs of their choosing would be inconsistent > with ARIN treating all organizations that receive service impartially. I believe that all organizations receive service impartially. But that that impartiality includes being able to negotiate. A contract, after all, is an agreement, and the process to agreement often includes some negotiation. I would suggest that we need to provide sufficient flexibility to insure that the communities core objectives are met, and be willing to deal with the realities that things are rarely as ideal as we would like. Of course, that means we have to agree on the core objectives and what we are willing to compromise on, rather than specific point issues. My personal core objectives would include need based allocations/assignments over disagreements over which state gets to have jurisdiction over the contract (for an example). I am also more interested that the receiving organization sign *any* RSA which is no less than the RSA that the numbers are currently available under for a transfer than to have the transfer proceed without any agreements with ARIN (in other words, legacy or LRSA must result in LRSA *or* RSA). Are these perhaps ideal positions? Absolutely not, but they are the compromises *I* would be willing to make in order to move forward to achieve *my* more basic objectives. > 'Special' organizations should not have have rights, waiver of > community developed > policies, or other privileges granted to them by ARIN, not afforded to others, > just because they are X, and ?"X is special". Everyone is special. Just like all the children in Lake Wobegon are above average. Telling someone they are not special (and neither are their children) seems to never be a popular statement (even when it is factually accurate). Gary From rudi.daniel at gmail.com Tue May 10 02:12:55 2011 From: rudi.daniel at gmail.com (Rudolph Daniel) Date: Tue, 10 May 2011 02:12:55 -0400 Subject: [arin-ppml] ARIN-PPML Digest, Vol 71, Issue 104 In-Reply-To: References: Message-ID: My opinion is: Legacy holders can keep what they have until doomsday, and where these holders decide to transfer in any way method shape or form, they are subject to RSA. I feel that it does not seem fair on the part of the rest of the community that legacy holders legitimize (not sure that's the correct word) their holding with the use of a special instrument (LRSA) and at the same time retain the ability to profit from that which is technically not property/....I suspect they were given these resources in the spirit of R&D at the time. rd > > On Mon, May 9, 2011 at 9:20 PM, Owen DeLong wrote: > > RSA, I could support it. I do not support granting LRSA to transfer > > recipients. The LRSA provides special benefits that are intended to > > I agree. The LRSA is an agreement between ARIN and a legacy resource > holder. > A transfer recipient is not a legacy resource holder; a transfer > recipient is a new > resource holder. > > Also, there is no reason ARIN should adopt a more lax policy in > anticipation > that a resource holder will ignore their obligations in attempting to make > 'undocumented' transfers not allowed by policy. > > Legitimizing non-needs-based transfers would encourage them. > It is questionable whether black market transfers would even be > attempted, otherwise, by any legacy holders with significant number > resources assigned to their network. > > > Owen > -- > -JH > > > ------------------------------ > > Message: 4 > Date: Mon, 9 May 2011 23:36:56 -0500 > From: Jimmy Hess > To: Matthew Kaufman > Cc: arin-ppml at arin.net > Subject: Re: [arin-ppml] transfer conditions > Message-ID: > Content-Type: text/plain; charset=ISO-8859-1 > > On Mon, May 9, 2011 at 8:09 PM, Matthew Kaufman > wrote: > > On May 9, 2011, at 3:49 PM, Ted Mittelstaedt wrote: > > All of the versions of the LRSA, and all of the modifications of "The > RSA" are "an RSA" > >> I wouldn't like it, but obviously ARIN does not like forcing the > recieving party to sign an RSA, > > No, they're fine with "an RSA", just not "The RSA and Only The RSA" > > Matthew Kaufman > > When I say and see "RSA" in the 8.3 transfer policy; I take that to mean > the unmodified, standard RSA signed for new allocations by ARIN. > And "LRSA" to be the special modified RSA for legacy holders. > > Do you suggest ARIN staff have taken a liberty to not implement it in > that manner? > > I expect transfer recipients to be required to sign the RSA equivalent to > the standard RSA signed by receivers of new allocations. > > That is, a RSA that does not provide the transfer recipient any benefits, > more rights, provide any fewer restrictions on the transfer recipient, > than > the new allocation RSA, and does not restrict ARIN or cause ARIN to > surrender > any rights not surrendered when the allocation recipient enteres into > a standard RSA. > > -- > -JH > > > ------------------------------ > > Message: 5 > Date: Mon, 9 May 2011 21:39:30 -0700 > From: Matthew Kaufman > To: Owen DeLong > Cc: Warren Johnson , arin-ppml at arin.net > Subject: Re: [arin-ppml] ARIN-prop-146 Clarify Justified Need for > Transfers > Message-ID: > Content-Type: text/plain; charset=us-ascii > > > On May 9, 2011, at 7:09 PM, Owen DeLong wrote: > > > Actually, not so much... The resulting organization would still be > subject > > to a section 12 audit and appropriate reclamation of the unused space. > > > > Given that no section 12 audit resulted in a significant return from the HP > + DEC/Compaq merger, I will simply assume that you're just wrong about this. > > Matthew Kaufman > > > > ------------------------------ > > Message: 6 > Date: Mon, 9 May 2011 21:50:23 -0700 > From: Matthew Kaufman > To: Jimmy Hess > Cc: arin-ppml at arin.net > Subject: Re: [arin-ppml] transfer conditions > Message-ID: <1B32A1B5-0FFC-4C58-93F3-9C984E42F5AB at matthew.at> > Content-Type: text/plain; charset=us-ascii > > > On May 9, 2011, at 9:36 PM, Jimmy Hess wrote: > > > On Mon, May 9, 2011 at 8:09 PM, Matthew Kaufman > wrote: > >> On May 9, 2011, at 3:49 PM, Ted Mittelstaedt wrote: > >> All of the versions of the LRSA, and all of the modifications of "The > RSA" are "an RSA" > >>> I wouldn't like it, but obviously ARIN does not like forcing the > recieving party to sign an RSA, > >> No, they're fine with "an RSA", just not "The RSA and Only The RSA" > >> Matthew Kaufman > > > > When I say and see "RSA" in the 8.3 transfer policy; I take that to mean > > the unmodified, standard RSA signed for new allocations by ARIN. > > And "LRSA" to be the special modified RSA for legacy holders. > > Well, since "RSA" is not currently defined in the NRPM anywhere, it could > mean anything they want, I suppose. > > Note that even the "normal RSA" gets modified for certain entities, and the > LRSA is also often "customized" > > > > > Do you suggest ARIN staff have taken a liberty to not implement it in > > that manner? > > > > That is the only way that the public statements made regarding the > Nortel/Microsoft transfer make any sense. There's evidence that "a LRSA" was > signed and evidence that "policy 8.3 was followed". > > > I expect transfer recipients to be required to sign the RSA equivalent to > > the standard RSA signed by receivers of new allocations. > > > > Well, that isn't what has happened, at least once. I have a policy proposal > that clarifies what might happen... please comment on it (I'm guessing you > would NOT support it, given your position about which RSA should be > required) > > Matthew Kaufman > > ------------------------------ > > Message: 7 > Date: Tue, 10 May 2011 00:10:30 -0500 > From: Jimmy Hess > To: Matthew Kaufman > Cc: arin-ppml at arin.net > Subject: Re: [arin-ppml] transfer conditions > Message-ID: > Content-Type: text/plain; charset=ISO-8859-1 > > On Mon, May 9, 2011 at 11:50 PM, Matthew Kaufman > wrote: > > On May 9, 2011, at 9:36 PM, Jimmy Hess wrote: > >> On Mon, May 9, 2011 at 8:09 PM, Matthew Kaufman > wrote: > > > Note that even the "normal RSA" gets modified for certain entities, and > the LRSA is also often "customized" > > > In what way does the RSA get "modified" for certain entities? > Do we have examples? > > I would suggest at least the requirement that the RSA used > match a RSA published in the "Agreements" section of ARIN's website. > > Some organizations getting private RSAs of their choosing would be > inconsistent > with ARIN treating all organizations that receive service impartially. > > 'Special' organizations should not have have rights, waiver of > community developed > policies, or other privileges granted to them by ARIN, not afforded to > others, > just because they are X, and "X is special". > > -- > -JH > > > ------------------------------ > > _______________________________________________ > ARIN-PPML mailing list > ARIN-PPML at arin.net > http://lists.arin.net/mailman/listinfo/arin-ppml > > End of ARIN-PPML Digest, Vol 71, Issue 104 > ****************************************** > -- Rudi Daniel *danielcharles consulting **1-784 498 8277 * * * -------------- next part -------------- An HTML attachment was scrubbed... URL: From farmer at umn.edu Tue May 10 02:35:11 2011 From: farmer at umn.edu (David Farmer) Date: Tue, 10 May 2011 01:35:11 -0500 Subject: [arin-ppml] transfer conditions In-Reply-To: References: <75E9BD24-F12F-42BF-A989-CF6CC282B28E@arin.net> <49E26DCB-DAF7-4A0A-912E-F981494979F5@delong.com> <4DBC2AEB.9040307@matthew.at> <4DBCA58D.4060704@sprunk.org> <2344ADD7-616E-4FA7-9552-19735926A952@delong.com> <391BFA8C-9D09-4BB2-8D49-FD5F9C6FDF93@arin.net> <6B951089-C686-4929-AC21-A1BF91BBBCB7@delong.com> <22A6B158-1CBC-4C35-A842-0BD029B2461C@arin.net> <9CDB0040-AFFD-4A90-94D9-821003EE5B8F@matthew.at> <1E077822-6D5F-459F-B312-1DD8F7447B40@matthew.at> <1B32A1B5-0FFC-4C58-93F3-9C984E42F5AB@matthew.at> Message-ID: <4DC8DC9F.1020304@umn.edu> On 5/10/11 24:10 CDT, Jimmy Hess wrote: > In what way does the RSA get "modified" for certain entities? > Do we have examples? See https://www.arin.net/resources/legacy/ FAQ #12 as one example for both the RSA and LRSA. > I would suggest at least the requirement that the RSA used > match a RSA published in the "Agreements" section of ARIN's website. > > Some organizations getting private RSAs of their choosing would be inconsistent > with ARIN treating all organizations that receive service impartially. It is common practice when negotiating contracts to remove or edit terms and conditions that are known not to apply or are invalid for some legal reason. By law, not all organization are equal, this is a legal fact beyond the control of ARIN. ARIN must abide by applicable laws and court rulings, in some special cases these conflict with the standard terms and conditions in the RSA or LRSA. > 'Special' organizations should not have have rights, waiver of > community developed > policies, or other privileges granted to them by ARIN, not afforded to others, > just because they are X, and "X is special". In one way ARIN is not treating anyone special, I suspect, if you or your lawyers can provide valid legal reasons why some term or condition doesn't or shouldn't apply to your organization ARIN will probably work with you and provide a contract that resolves that issue for you. I have all confidence that these changes are not made willy-nilly, and that they are made for important and valid legal reasons. -- =============================================== 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 mike at nationwideinc.com Tue May 10 09:58:00 2011 From: mike at nationwideinc.com (Mike Burns) Date: Tue, 10 May 2011 09:58:00 -0400 Subject: [arin-ppml] Draft Proposal for Needs-Free IPv4 Transfers References: <323AD9AC0BE24F9BB91D3E712160681A@mike><77338713-58D2-47AA-9045-C5D19DBB8DA0@delong.com> Message-ID: <8728DDCCEA5E476D8AC8E59368684F12@mike> Hi Guys, Thanks for the feedback. Since this point is germane to my proposal, could I ask for some status on the discussion that Bill Herrin and John Curran were having related to the potential for making some changes to the LRSA? I will have to think about changing my proposal to require an agreement be signed by the receiving entity. On the one hand, as I do support private registries, it would seem strange to me that a registry provides some service to somebody for free, and I would expect every registry to have some contract with its customers. And I don't like the idea of separate classes of addresses, it is my desire to reconcile them under the same set of rules through voluntary acts. And with the proposed change to the RSA included in my proposal and the removal of needs requirements from 8.3, the fear of signing one may be mitigated for a legacy holder. On the other hand, the record shows that there is limited incentive for legacy holders to sign any incarnation of the LRSA, so presumably they would view the more-restrictive RSA as an anathema. There is a relationship, though, between increasing transfer rights for holders under an RSA and increasing the incentive to sign one. And now legacy holders see that a bankruptcy court gave Nortel the unrestricted right to transfer addresses originally allocated as legacy space to entities Nortel acquired in the 1990s. So addresses allocated to Company A passed into the "ownership" of Company B without recourse to any ARIN processes. To these legacy holders, this is a step in the recognition that these addresses ARE transferrable legally, whether or not ARIN is involved, and whether or not whois is updated. Presumably ARIN pitched MS hard to sign an RSA, so as to conform with the 8.3 policy as written, but met with resistance and instead settled for a modified LRSA. To me this is evidence that these transactions involving legacy space are bound to continue, and the acquiesence of ARIN to LRSA tells me the legacy holders are negotiating from a position of legal strength. In addition, legacy holders know they can be active in the APNIC market without having to sign an agreement. I want all transfers recorded in whois, and I don't want to miss recording transactions due to requiring agreements that are onerous. Still, as a legacy holder myself who has not signed the LRSA, I would be inclined to sign the stripped-down LRSA Mr. Herrin suggested, and I would be more likely to sign even an RSA upon adoption of my proposed policy, since I would have new rights to resist a utilization review and would also have the ability to do needs-free transfers. These things would go a long way in overcoming existing disincentives to signing either agreement. A side effect of the adoption of my proposal is that it would settle the issue of address leasing, to my mind. Since an address holder could hold a pool of addresses without fear of a section 12 review, and since he would be free to transfer to another party without a needs requirement, he can structure the transfer as a lease financially and contractually with the lessee, and structure it as two 8.3 transfers with ARIN, one out to the lessee, and then one back to the lessor at the end of the term. This ability to lease has always been associated with an increased value of legacy address space, in my mind. By allowing for RSA holders to hold addresses, transfer to and from their customers, again the disincentive towards signing the RSA are reduced. Let me cogitate and maybe hear about the potential for change to the LRSA that Bill and John were discussing, and I will submit a proposal that is not a draft and the AC can take the temperature of the list. Maybe the net effect of my proposal is to treat every pre-exhaust allocant as near legacy-equivalents and wouldn't that be a good thing ? Regards, Mike ----- Original Message ----- From: "Jimmy Hess" To: "Owen DeLong" Cc: "Mike Burns" ; Sent: Tuesday, May 10, 2011 12:05 AM Subject: Re: [arin-ppml] Draft Proposal for Needs-Free IPv4 Transfers > On Mon, May 9, 2011 at 9:20 PM, Owen DeLong wrote: >> RSA, I could support it. I do not support granting LRSA to transfer >> recipients. The LRSA provides special benefits that are intended to > > I agree. The LRSA is an agreement between ARIN and a legacy resource > holder. > A transfer recipient is not a legacy resource holder; a transfer > recipient is a new > resource holder. > > Also, there is no reason ARIN should adopt a more lax policy in > anticipation > that a resource holder will ignore their obligations in attempting to make > 'undocumented' transfers not allowed by policy. > > Legitimizing non-needs-based transfers would encourage them. > It is questionable whether black market transfers would even be > attempted, otherwise, by any legacy holders with significant number > resources assigned to their network. > >> Owen > -- > -JH From jcurran at arin.net Tue May 10 10:18:26 2011 From: jcurran at arin.net (John Curran) Date: Tue, 10 May 2011 14:18:26 +0000 Subject: [arin-ppml] transfer conditions In-Reply-To: References: <75E9BD24-F12F-42BF-A989-CF6CC282B28E@arin.net> <8740380157159276993@unknownmsgid> <49E26DCB-DAF7-4A0A-912E-F981494979F5@delong.com> <4DBC2AEB.9040307@matthew.at> <4DBCA58D.4060704@sprunk.org> <2344ADD7-616E-4FA7-9552-19735926A952@delong.com> <391BFA8C-9D09-4BB2-8D49-FD5F9C6FDF93@arin.net> <6B951089-C686-4929-AC21-A1BF91BBBCB7@delong.com> <22A6B158-1CBC-4C35-A842-0BD029B2461C@arin.net> <9CDB0040-AFFD-4A90-94D9-821003EE5B8F@matthew.at> <4DC86F77.2060101@ipinc.net> <1E077822-6D5F-459F-B312-1DD8F7447B40@matthew.at> Message-ID: <8FD71350-E23A-4A1F-90F0-F707C73D484C@arin.net> On May 9, 2011, at 9:36 PM, Jimmy Hess wrote: > On Mon, May 9, 2011 at 8:09 PM, Matthew Kaufman wrote: >> On May 9, 2011, at 3:49 PM, Ted Mittelstaedt wrote: >> All of the versions of the LRSA, and all of the modifications of "The RSA" are "an RSA" >>> I wouldn't like it, but obviously ARIN does not like forcing the recieving party to sign an RSA, >> No, they're fine with "an RSA", just not "The RSA and Only The RSA" >> Matthew Kaufman > > When I say and see "RSA" in the 8.3 transfer policy; I take that to mean > the unmodified, standard RSA signed for new allocations by ARIN. > And "LRSA" to be the special modified RSA for legacy holders. > > Do you suggest ARIN staff have taken a liberty to not implement it in > that manner? It is not implemented as you suggested above - it is a standard RSA by default. > I expect transfer recipients to be required to sign the RSA equivalent to > the standard RSA signed by receivers of new allocations. As I noted, a transfer will almost always meet these expectations. However, if there are legacy resources involved and a standard RSA will not work due to conflict of terms with governmental requirements such as a federal, state or provisional authority, court authorities, etc.) ARIN may utilize an LRSA or modified LRSA so that the transfer can proceed. This is unlikely to be a common occurrence, but does happen, just as we sometimes have to modify the LRSA for governmental entities. /John John Curran President and CEO ARIN From jcurran at arin.net Tue May 10 10:21:50 2011 From: jcurran at arin.net (John Curran) Date: Tue, 10 May 2011 14:21:50 +0000 Subject: [arin-ppml] transfer conditions In-Reply-To: References: <75E9BD24-F12F-42BF-A989-CF6CC282B28E@arin.net> <8740380157159276993@unknownmsgid> <49E26DCB-DAF7-4A0A-912E-F981494979F5@delong.com> <4DBC2AEB.9040307@matthew.at> <4DBCA58D.4060704@sprunk.org> <2344ADD7-616E-4FA7-9552-19735926A952@delong.com> <391BFA8C-9D09-4BB2-8D49-FD5F9C6FDF93@arin.net> <6B951089-C686-4929-AC21-A1BF91BBBCB7@delong.com> <22A6B158-1CBC-4C35-A842-0BD029B2461C@arin.net> <9CDB0040-AFFD-4A90-94D9-821003EE5B8F@matthew.at> <1E077822-6D5F-459F-B312-1DD8F7447B40@matthew.at> <1B32A1B5-0FFC-4C58-93F3-9C984E42F5AB@matthew.at> Message-ID: <6DB34964-356D-4276-9DB0-0152BE43A2C8@arin.net> On May 9, 2011, at 10:10 PM, Jimmy Hess wrote: > On Mon, May 9, 2011 at 11:50 PM, Matthew Kaufman wrote: >> On May 9, 2011, at 9:36 PM, Jimmy Hess wrote: >>> On Mon, May 9, 2011 at 8:09 PM, Matthew Kaufman wrote: > >> Note that even the "normal RSA" gets modified for certain entities, and the LRSA is also often "customized" >> > In what way does the RSA get "modified" for certain entities? > Do we have examples? > > I would suggest at least the requirement that the RSA used > match a RSA published in the "Agreements" section of ARIN's website. > > Some organizations getting private RSAs of their choosing would be inconsistent > with ARIN treating all organizations that receive service impartially. > > 'Special' organizations should not have have rights, waiver of > community developed > policies, or other privileges granted to them by ARIN, not afforded to others, > just because they are X, and "X is special". Jimmy - The agreements do not provide any special rights or waivers to policy, but may require that ARIN utilize a particular venue/jurisdiction if we have a dispute, or may require different notification provisions, etc. These commonly occur when doing agreements with governmental authorities, which are often not allowed to enter agreements which specify an external court system. /John John Curran President and CEO ARIN From mike at nationwideinc.com Tue May 10 10:23:35 2011 From: mike at nationwideinc.com (Mike Burns) Date: Tue, 10 May 2011 10:23:35 -0400 Subject: [arin-ppml] An aside in reference to Microsoft Message-ID: <82D5849C6A9A45AEBD2DBFA6E0BB7C88@mike> I see today Microsoft is announcing an acquisition of Skype. I have read recently that Skype will be adversely affected by the advent of Carrier Grade NAT, and will require their own servers when CGN is deployed. http://blog.caida.org/best_available_data/2011/05/03/exhausted-ipv4-address-architectures/ Possibly Microsoft acquired the Nortel addresses because they see a CGN future that will not be disastrous for Skype, as long as IPv4 addresses were available for Skype supernodes. Food for thought when we consider the impact and duration of the IPv4 transfer market. -Mike -------------- next part -------------- An HTML attachment was scrubbed... URL: From tedm at ipinc.net Tue May 10 10:52:45 2011 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Tue, 10 May 2011 07:52:45 -0700 Subject: [arin-ppml] An aside in reference to Microsoft In-Reply-To: <82D5849C6A9A45AEBD2DBFA6E0BB7C88@mike> References: <82D5849C6A9A45AEBD2DBFA6E0BB7C88@mike> Message-ID: <4DC9513D.1060103@ipinc.net> I have studied Microsoft's corporate acquisitions for years. They only do 2 kinds of buying, patent/IP acquisitions, and customer base/ eliminate competition acquisitions. I believe the Skype acquisition is one of the latter. Skype users can probably look forward to increased marketing and tie-in to Microsoft products. Ted On 5/10/2011 7:23 AM, Mike Burns wrote: > I see today Microsoft is announcing an acquisition of Skype. > I have read recently that Skype will be adversely affected by the advent > of Carrier Grade NAT, and will require their own servers when CGN is > deployed. > http://blog.caida.org/best_available_data/2011/05/03/exhausted-ipv4-address-architectures/ > Possibly Microsoft acquired the Nortel addresses because they see a CGN > future that will not be disastrous for Skype, as long as IPv4 addresses > were available for Skype supernodes. > Food for thought when we consider the impact and duration of the IPv4 > transfer market. > -Mike > > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From jcurran at arin.net Tue May 10 10:53:21 2011 From: jcurran at arin.net (John Curran) Date: Tue, 10 May 2011 14:53:21 +0000 Subject: [arin-ppml] Draft Proposal for Needs-Free IPv4 Transfers In-Reply-To: <8728DDCCEA5E476D8AC8E59368684F12@mike> References: <323AD9AC0BE24F9BB91D3E712160681A@mike> <77338713-58D2-47AA-9045-C5D19DBB8DA0@delong.com> <8728DDCCEA5E476D8AC8E59368684F12@mike> Message-ID: <7A8B0D17-0AC3-4C60-B466-39C29708F826@arin.net> On May 10, 2011, at 6:58 AM, Mike Burns wrote: > Since this point is germane to my proposal, could I ask for some status on the discussion that Bill Herrin and John Curran were having related to the potential for making some changes to the LRSA? Currently in progress. We're trying to make more plain english language for the existing terms and conditions, and remove language which is conflicting and/or inoperative. > ... > And now legacy holders see that a bankruptcy court gave Nortel the unrestricted right to transfer addresses originally allocated as legacy space to entities Nortel acquired in the 1990s. > So addresses allocated to Company A passed into the "ownership" of Company B without recourse to any ARIN processes. The above statement is factually incorrect. The transfer occurred in accordance with the community developed policies. If it hadn't been, then the transfer would not have been approved, and the outcome of that situation might have been more indicative (either way). > I want all transfers recorded in whois, and I don't want to miss recording transactions due to requiring agreements that are onerous. > > Still, as a legacy holder myself who has not signed the LRSA, I would be inclined to sign the stripped-down LRSA Mr. Herrin suggested, and I would be more likely to sign even an RSA upon adoption of my proposed policy, since I would have new rights to resist a utilization review and would also have the ability to do needs-free transfers. These things would go a long way in overcoming existing disincentives to signing either agreement. The utilization review is a good example: it is definitely non-operative language due to other phrasing in the LRSA, so there is a great question as to whether it is worth retaining in the LRSA (and to some extent, the same question applies to the RSA as policies for transfers for unneeded are now operative) FYI, /John John Curran President and CEO ARIN From tedm at ipinc.net Tue May 10 11:16:05 2011 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Tue, 10 May 2011 08:16:05 -0700 Subject: [arin-ppml] New IPv4 Transfer policy In-Reply-To: <4DC8D506.3010203@umn.edu> References: <0F4E49B9-09DB-434F-AD5D-87DA3DCC42D8@matthew.at> <4DC86683.90204@ipinc.net> <4DC8D506.3010203@umn.edu> Message-ID: <4DC956B5.3030107@ipinc.net> On 5/9/2011 11:02 PM, David Farmer wrote: > On 5/9/11 17:11 CDT, Ted Mittelstaedt wrote: >> Ask ARIN >> >> Financially, the fees for the block of numbers that Microsoft got >> from that transfer are nothing in comparison to what they paid for >> it, and Microsoft is also known for spending tons of money on >> useless stuff. So there must have been some difference between >> the RSA and the LRSA that made Microsoft choose the LRSA and the >> only thing I can think of is the LRSA is less restrictive in some >> manner. >> >> I suspect we need to have ARIN modify the LRSA. The LRSA was sold >> to us on the basis that it was the same thing as the RSA without >> the annual fee. Obviously, the Microsoft lawyers found out that >> this wasn't true. ARIN has a lot of explaining to do, here. >> >> Ted > > I'm not sure what you feel you were sold. However, the details of the > LRSA are not secret, have been published for sometime, and there is more > than just a difference in fees for Legacy ISPs. Note: Legacy end users > pay the same annual fees as any other end user. Microsoft, a company with 80K employees, could not have possibly provided justification that would have resulted in 50% utilization of 500K additional IP addresses in 1 year. Are you proposing the company grow 4 times it's existing size in 1 year? The only possible justification would be if they were buying them to reallocate to customers in a network the same way that any LIR does. I fail to see what is to be gained by defending what Microsoft did here. Insisting that ARIN have them sign an LRSA instead of the RSA is deplorable. For all ARIN's labor they put into handling this transfer they get paid $100? ARIN costs money to run and it isn't the Net Fairies that pay for it. It's all the ISP's who are reallocating IP addresses that pay for ARIN, that is money that is coming out of the pockets of hard working men and women who build the networks that allow Joe Blow and Sally Schmoe to get online. > So, your view on the > difference, or lack there of, in the fees can vary significantly > depending on your perspective. Here's a thought, how about we charge EVERY address holder the same amount of money that end users pay? > There has been a FAQ regarding the LRSA > for sometime as well, the current version is at; > https://www.arin.net/resources/legacy/ > > It provides an excellent summary of the LRSA, for those who aren't into > recreationally reading contracts. :) I know the LRSA, and the RSA, > almost put me to sleep when I had to read it as part of getting my > organization to sign them. :) I only survived with the assistance of > multiple caffeinated beverages. :) > > I'll also add that a number of improvements have been made in the LRSA > since its initial version, and a number of these improvements have been > integrated into the RSA as well, for the benefit of everyone who has > received resources from ARIN. > The problem here is you cannot discern the real difference between the RSA and the LRSA just by reading them. Just as you cannot discern the real meaning of the NRPM by just reading it. For example the NRPM says that transfer recipients sign "RSA" It is only when you parse the syntax the way that a lawyer would that you can see that this could mean an LRSA or an RSA. I would like to know what the Microsoft lawyers parsed out of the two documents that made the LRSA so much more attractive. I can read both documents and see differences but I don't know how a lawyer would interpret what those differences are and why one would be so much more attractive than the other. Ted From mike at nationwideinc.com Tue May 10 11:16:02 2011 From: mike at nationwideinc.com (Mike Burns) Date: Tue, 10 May 2011 11:16:02 -0400 Subject: [arin-ppml] Draft Proposal for Needs-Free IPv4 Transfers References: <323AD9AC0BE24F9BB91D3E712160681A@mike><77338713-58D2-47AA-9045-C5D19DBB8DA0@delong.com><8728DDCCEA5E476D8AC8E59368684F12@mike> <7A8B0D17-0AC3-4C60-B466-39C29708F826@arin.net> Message-ID: > Since this point is germane to my proposal, could I ask for some status on > the discussion that Bill Herrin and John Curran were having related to the > potential for making some changes to the LRSA? >Currently in progress. We're trying to make more plain english language >for >the existing terms and conditions, and remove language which is conflicting >and/or inoperative. Thanks John, is there any expected timeframe for a revised LRSA? > ... > And now legacy holders see that a bankruptcy court gave Nortel the > unrestricted right to transfer addresses originally allocated as legacy > space to entities Nortel acquired in the 1990s. > So addresses allocated to Company A passed into the "ownership" of Company > B without recourse to any ARIN processes. >The above statement is factually incorrect. The transfer occurred in >accordance with the community developed policies. If it hadn't been, >then the transfer would not have been approved, and the outcome of that >situation might have been more indicative (either way). If the transfer would not have been "approved" by ARIN, wouldn't Microsoft still be using addresses allocated originally to Nortel's "predecessors in interest" ? What we are dancing around is the definition of transfer. If by transfer, you mean ARIN updating whois, then you can say that all transfers happen through policy. If by transfer you mean that somebody else is actually using addresses which they have purchased from the original registrant, and ARIN has not updated whois, well those transfers have occurred, and if the costs of acquiring ARIN's approval are higher than the cost of ignoring ARIN, whois will continue to degrade as these transactions continue. > I want all transfers recorded in whois, and I don't want to miss recording > transactions due to requiring agreements that are onerous. > > Still, as a legacy holder myself who has not signed the LRSA, I would be > inclined to sign the stripped-down LRSA Mr. Herrin suggested, and I would > be more likely to sign even an RSA upon adoption of my >proposed policy, > since I would have new rights to resist a utilization review and would > also have the ability to do needs-free transfers. These things would go a > long way in overcoming existing disincentives to signing >either > agreement. >The utilization review is a good example: it is definitely non-operative >language due to other phrasing in the LRSA, so there is a great question >as to whether it is worth retaining in the LRSA (and to some extent, the >same question applies to the RSA as policies for transfers for unneeded >are now operative) It makes no sense to have non-operative language cluttering up an agreement unless it serves some other purpose. But I don't understand your parenthetical, is there a typo? Regards, Mike From tedm at ipinc.net Tue May 10 11:21:23 2011 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Tue, 10 May 2011 08:21:23 -0700 Subject: [arin-ppml] transfer conditions In-Reply-To: <8FD71350-E23A-4A1F-90F0-F707C73D484C@arin.net> References: <75E9BD24-F12F-42BF-A989-CF6CC282B28E@arin.net> <49E26DCB-DAF7-4A0A-912E-F981494979F5@delong.com> <4DBC2AEB.9040307@matthew.at> <4DBCA58D.4060704@sprunk.org> <2344ADD7-616E-4FA7-9552-19735926A952@delong.com> <391BFA8C-9D09-4BB2-8D49-FD5F9C6FDF93@arin.net> <6B951089-C686-4929-AC21-A1BF91BBBCB7@delong.com> <22A6B158-1CBC-4C35-A842-0BD029B2461C@arin.net> <9CDB0040-AFFD-4A90-94D9-821003EE5B8F@matthew.at> <4DC86F77.2060101@ipinc.net> <1E077822-6D5F-459F-B312-1DD8F7447B40@matthew.at> <8FD71350-E23A-4A1F-90F0-F707C73D484C@arin.net> Message-ID: <4DC957F3.4070702@ipinc.net> On 5/10/2011 7:18 AM, John Curran wrote: > On May 9, 2011, at 9:36 PM, Jimmy Hess wrote: > >> On Mon, May 9, 2011 at 8:09 PM, Matthew Kaufman wrote: >>> On May 9, 2011, at 3:49 PM, Ted Mittelstaedt wrote: >>> All of the versions of the LRSA, and all of the modifications of "The RSA" are "an RSA" >>>> I wouldn't like it, but obviously ARIN does not like forcing the recieving party to sign an RSA, >>> No, they're fine with "an RSA", just not "The RSA and Only The RSA" >>> Matthew Kaufman >> >> When I say and see "RSA" in the 8.3 transfer policy; I take that to mean >> the unmodified, standard RSA signed for new allocations by ARIN. >> And "LRSA" to be the special modified RSA for legacy holders. >> >> Do you suggest ARIN staff have taken a liberty to not implement it in >> that manner? > > It is not implemented as you suggested above - it is a standard RSA by > default. > >> I expect transfer recipients to be required to sign the RSA equivalent to >> the standard RSA signed by receivers of new allocations. > > As I noted, a transfer will almost always meet these expectations. However, > if there are legacy resources involved and a standard RSA will not work due to > conflict of terms with governmental requirements such as a federal, state or > provisional authority, court authorities, etc.) I can see a bankruptcy court requiring ARIN to NOT force a transferrer such as Nortel to sign any kind of document. I cannot see a bankruptcy court requiring ARIN to have a recipient to an address transfer such as Microsoft sign only an LRSA instead of an RSA. Microsoft isn't under bankruptcy court control. Perhaps you could elaborate? Hypothetically, of course? Ted ARIN may utilize an LRSA or > modified LRSA so that the transfer can proceed. This is unlikely to be a common > occurrence, but does happen, just as we sometimes have to modify the LRSA for > governmental entities. > > /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 joelja at bogus.com Tue May 10 11:26:34 2011 From: joelja at bogus.com (Joel Jaeggli) Date: Tue, 10 May 2011 08:26:34 -0700 Subject: [arin-ppml] New IPv4 Transfer policy In-Reply-To: <4DC956B5.3030107@ipinc.net> References: <0F4E49B9-09DB-434F-AD5D-87DA3DCC42D8@matthew.at> <4DC86683.90204@ipinc.net> <4DC8D506.3010203@umn.edu> <4DC956B5.3030107@ipinc.net> Message-ID: <4DC9592A.4070801@bogus.com> On 5/10/11 8:16 AM, Ted Mittelstaedt wrote: > Microsoft, a company with 80K employees, could not have possibly > provided justification that would have resulted in 50% utilization of > 500K additional IP addresses in 1 year. Are you proposing the company > grow 4 times it's existing size in 1 year? The only possible > justification would be if they were buying them to reallocate to > customers in a network the same way that any LIR does. I don't have any particular interest in the outcome but with all due respect you don't have any idea how they intend to utilize them, and address space utilization on the basis of employee count is specious enough to be discarded out of hand. It's obvious that you've never been a customer of microsoft's hosting platform or their SOAS business if the only possible conclusion you can draw is that they're going into the LIR business. joel From jcurran at arin.net Tue May 10 11:40:35 2011 From: jcurran at arin.net (John Curran) Date: Tue, 10 May 2011 15:40:35 +0000 Subject: [arin-ppml] Draft Proposal for Needs-Free IPv4 Transfers In-Reply-To: References: <323AD9AC0BE24F9BB91D3E712160681A@mike> <77338713-58D2-47AA-9045-C5D19DBB8DA0@delong.com> <"BANLkTik8jUuimto500D45ngcoOp CXg4vPg"@mail.gmail.com> <8728DDCCEA5E476D8AC8E59368684F12@mike> <7A8B0D17-0AC3-4C60-B466-39C29708F826@arin.net> Message-ID: <554FF02B-0E97-4C0D-9E7F-17377C1AFFAE@arin.net> On May 10, 2011, at 8:16 AM, Mike Burns wrote: > Thanks John, is there any expected timeframe for a revised LRSA? Anticipated to be 30 to 60 days > If by transfer you mean that somebody else is actually using addresses which they have purchased from the original registrant, and ARIN has not updated whois, well those transfers have occurred, and if the costs of acquiring ARIN's approval are higher than the cost of ignoring ARIN, whois will continue to degrade as these transactions continue. The transfers occur when ARIN approves them and updates the registry. >> The utilization review is a good example: it is definitely non-operative >> language due to other phrasing in the LRSA, so there is a great question >> as to whether it is worth retaining in the LRSA (and to some extent, the >> same question applies to the RSA as policies for transfers for unneeded >> are now operative) > > It makes no sense to have non-operative language cluttering up an agreement unless it serves some other purpose. > But I don't understand your parenthetical, is there a typo? After refreshing the LRSA, we might want to next compare it to the existing RSA to see if there are similar changes that can be made in order to keep the two documents as closely aligned as possible. /John John Curran President and CEO ARIN From mike at nationwideinc.com Tue May 10 11:56:13 2011 From: mike at nationwideinc.com (Mike Burns) Date: Tue, 10 May 2011 11:56:13 -0400 Subject: [arin-ppml] Draft Proposal for Needs-Free IPv4 Transfers References: <323AD9AC0BE24F9BB91D3E712160681A@mike><77338713-58D2-47AA-9045-C5D19DBB8DA0@delong.com><"BANLkTik8jUuimto500D45ngcoOp CXg4vPg"@mail.gmail.com><8728DDCCEA5E476D8AC8E59368684F12@mike><7A8B0D17-0AC3-4C60-B466-39C29708F826@arin.net> <554FF02B-0E97-4C0D-9E7F-17377C1AFFAE@arin.net> Message-ID: Thanks, John, >After refreshing the LRSA, we might want to next compare it to the existing >RSA to see if there are similar changes that can be made in order to keep >the two documents as closely aligned as possible. Part of my draft proposal includes a change to the RSA. What is the process by which changes are made to the RSA or LRSA? Is it allowable for a policy proposal to include proposed changes to either of these documents? I would also like the documents to be closely aligned, and I think maybe there is some room, post-exhaust, to move them together by liberalizing the RSA to grant rights now only granted to LRSA signers. Like the protection from utilization reviews. My proposal would also allow RSA and LRSA signers to transfer without a needs requirement. Taken together, these changes would give RSA and LRSA the rights to hold unused addresses and transfer them without a justification hurdle. To my mind, the difference between them would blur significantly, and I believe more legacy holders would be inclined to sign either agreement if these rights were ensured by policy. And this would serve the purposes of all who look back on legacy distributions with some regret over the lack of associated agreements, and who hope for an inclusive policy which will bring legacy holders into the fold. Finally, do you concur with my reading of NRPM which does not seem to have language in section 12 which clearly allows for a utilization-based resource review? My reading of it is that the reviewers look for policy compliance, but all the policy I read about utilization is in the context of an original or subsequent allocation. On the other hand, the RSA has clear language allowing review for compliance with the intended purpose of the addresses as expressed on the application for resources. I don't know if it is permissible to change the RSA via the normal policy development process, though. Regards, Mike From lar at mwtcorp.net Tue May 10 12:40:59 2011 From: lar at mwtcorp.net (Larry Ash) Date: Tue, 10 May 2011 10:40:59 -0600 Subject: [arin-ppml] transfer conditions In-Reply-To: References: <75E9BD24-F12F-42BF-A989-CF6CC282B28E@arin.net> <8740380157159276993@unknownmsgid> <49E26DCB-DAF7-4A0A-912E-F981494979F5@delong.com> <4DBC2AEB.9040307@matthew.at> <4DBCA58D.4060704@sprunk.org> <2344ADD7-616E-4FA7-9552-19735926A952@delong.com> <391BFA8C-9D09-4BB2-8D49-FD5F9C6FDF93@arin.net> <6B951089-C686-4929-AC21-A1BF91BBBCB7@delong.com> <22A6B158-1CBC-4C35-A842-0BD029B2461C@arin.net> <9CDB0040-AFFD-4A90-94D9-821003EE5B8F@matthew.at> <1E077822-6D5F-459F-B312-1DD8F7447B40@matthew.at> <1B32A1B5-0FFC-4C58-93F3-9C984E42F5AB@matthew.at> Message-ID: Gary, Thank you, I agree. All or nothing usually gets you nothing. If not at first at least at the point of litigation. Gary Buhrmaster wrote: > On Mon, May 9, 2011 at 22:10, Jimmy Hess wrote: > .... >> In what way does the RSA get "modified" for certain entities? > > I believe it has been claimed that certain government agencies > have, with consultation with their and ARIN staff/consul, made > some changes that were required under their interpretations of > applicable laws and regulations. I have no doubt that others > proposed, and some may have received, modifications. > >>From my recollection of the RSA (and some conjecture), for > example, things like agreeing that a certain state legal > interpretation overrides federal law may be a bridge too far > for some feds and their purchasing officers. But I have > no special knowledge to know whether that conjecture may > be true or not. > >> Do we have examples? > > I suspect that all examples are NDA (as any contracts probably > should be, unless the policies were to be amended to require full > disclosure, which probably would result in different challenges). > >> I would suggest at least the requirement that the RSA used >> match a RSA published in the "Agreements" section of ARIN's website. > > If that is what you want, then it should be explicitly proposed, > and if adopted, implemented as such. When you provide ambiguity, > lawyers will find an answer to best meet their clients needs (which > may not always be what you intended). > >> Some organizations getting private RSAs of their choosing would be >>inconsistent >> with ARIN treating all organizations that receive service impartially. > > I believe that all organizations receive service impartially. But > that that impartiality includes being able to negotiate. A contract, > after all, is an agreement, and the process to agreement often > includes some negotiation. > > I would suggest that we need to provide sufficient flexibility > to insure that the communities core objectives are met, and > be willing to deal with the realities that things are rarely > as ideal as we would like. Of course, that means we > have to agree on the core objectives and what we are willing > to compromise on, rather than specific point issues. My > personal core objectives would include need based > allocations/assignments over disagreements over which > state gets to have jurisdiction over the contract (for an > example). I am also more interested that the receiving > organization sign *any* RSA which is no less than the > RSA that the numbers are currently available under > for a transfer than to have the transfer proceed without > any agreements with ARIN (in other words, legacy or > LRSA must result in LRSA *or* RSA). Are these perhaps > ideal positions? Absolutely not, but they are the compromises > *I* would be willing to make in order to move forward to achieve > *my* more basic objectives. > >> 'Special' organizations should not have have rights, waiver of >> community developed >> policies, or other privileges granted to them by ARIN, not afforded to >>others, >> just because they are X, and ?"X is special". > > Everyone is special. Just like all the children in Lake > Wobegon are above average. Telling someone they are > not special (and neither are their children) seems to never > be a popular statement (even when it is factually accurate). > > Gary > _______________________________________________ > 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 jcurran at arin.net Tue May 10 12:51:49 2011 From: jcurran at arin.net (John Curran) Date: Tue, 10 May 2011 16:51:49 +0000 Subject: [arin-ppml] Draft Proposal for Needs-Free IPv4 Transfers In-Reply-To: References: <323AD9AC0BE24F9BB91D3E712160681A@mike> <77338713-58D2-47AA-9045-C5D19DBB8DA0@delong.com> <"BANLkTik8jUuimto500D45ngcoOp CXg4vPg"@mail.gmail.com> <8728DDCCEA5E476D8AC8E59368684F12@mike> <7A8B0D17-0AC3-4C60-B466-39C29708F826@arin.net> <"A818163231EE4B39 B4297986293565F5"@mike> <554FF02B-0E97-4C0D-9E7F-17377C1AFFAE@arin.net> Message-ID: <1AE5056E-A8F9-424A-9AF0-08BB56B425E8@arin.net> On May 10, 2011, at 8:56 AM, Mike Burns wrote: > > Part of my draft proposal includes a change to the RSA. > What is the process by which changes are made to the RSA or LRSA? > Is it allowable for a policy proposal to include proposed changes to either of these documents? Please propose changes to the RSA or LRSA via the ARIN ACSP as these are business practice documents and as such are outside the scope of the ARIN Policy Development Process. > I would also like the documents to be closely aligned, and I think maybe there is some room, post-exhaust, to move them together by liberalizing the RSA to grant rights now only granted to LRSA signers. > Like the protection from utilization reviews. Independent of actual language, it would be good to get community discussion of merits or concerns regarding such changes. > To my mind, the difference between them would blur significantly, and I believe more legacy holders would be inclined to sign either agreement if these rights were ensured by policy. > And this would serve the purposes of all who look back on legacy distributions with some regret over the lack of associated agreements, and who hope for an inclusive policy which will bring legacy holders into the fold. It's quite fine to create policy to cover the specific goals you have in mind. As a purely hypothetical example, you could propose "ARIN shall only reclaim or revoke resources for lack of payment of service fees, fraudulent use or representations to ARIN, or dissolution of the address holder, and specifically ARIN shall not reclaim number resource due to lack of utilization." If discussed, supported by the community, and adopted, ARIN staff and counsel would then revised the registration services agreements accordingly. > Finally, do you concur with my reading of NRPM which does not seem to have language in section 12 which clearly allows for a utilization-based resource review? > My reading of it is that the reviewers look for policy compliance, but all the policy I read about utilization is in the context of an original or subsequent allocation. > On the other hand, the RSA has clear language allowing review for compliance with the intended purpose of the addresses as expressed on the application for resources. > I don't know if it is permissible to change the RSA via the normal policy development process, though. I'm not certain I understand your concern. Both the RSA and LRSA have a utilization review in their respective section 8, and the NRPM 12 provides for reviews at any time, including upon request of new resources. Can you elaborate some? Thanks! /John John Curran President and CEO ARIN From farmer at umn.edu Tue May 10 13:06:08 2011 From: farmer at umn.edu (David Farmer) Date: Tue, 10 May 2011 12:06:08 -0500 Subject: [arin-ppml] New IPv4 Transfer policy In-Reply-To: <4DC956B5.3030107@ipinc.net> References: <0F4E49B9-09DB-434F-AD5D-87DA3DCC42D8@matthew.at> <4DC86683.90204@ipinc.net> <4DC8D506.3010203@umn.edu> <4DC956B5.3030107@ipinc.net> Message-ID: <4DC97080.6070007@umn.edu> On 5/10/11 10:16 CDT, Ted Mittelstaedt wrote: > On 5/9/2011 11:02 PM, David Farmer wrote: >> On 5/9/11 17:11 CDT, Ted Mittelstaedt wrote: >>> Ask ARIN >>> >>> Financially, the fees for the block of numbers that Microsoft got >>> from that transfer are nothing in comparison to what they paid for >>> it, and Microsoft is also known for spending tons of money on >>> useless stuff. So there must have been some difference between >>> the RSA and the LRSA that made Microsoft choose the LRSA and the >>> only thing I can think of is the LRSA is less restrictive in some >>> manner. >>> >>> I suspect we need to have ARIN modify the LRSA. The LRSA was sold >>> to us on the basis that it was the same thing as the RSA without >>> the annual fee. Obviously, the Microsoft lawyers found out that >>> this wasn't true. ARIN has a lot of explaining to do, here. >>> >>> Ted >> >> I'm not sure what you feel you were sold. However, the details of the >> LRSA are not secret, have been published for sometime, and there is more >> than just a difference in fees for Legacy ISPs. Note: Legacy end users >> pay the same annual fees as any other end user. > > Microsoft, a company with 80K employees, could not have possibly > provided justification that would have resulted in 50% utilization of > 500K additional IP addresses in 1 year. Are you proposing the company > grow 4 times it's existing size in 1 year? The only possible > justification would be if they were buying them to reallocate to > customers in a network the same way that any LIR does. > > I fail to see what is to be gained by defending what Microsoft did here. > Insisting that ARIN have them sign an LRSA instead of the RSA is > deplorable. For all ARIN's labor they put into handling this transfer > they get paid $100? I think you misunderstand my comments, I have not, and refuse to speculate, defend, or otherwise comment regarding what Microsoft did or didn't do. I simple do not know enough facts to do anything but participate in rumor mongering, so I have decided to abstain from commenting. However, I'll admit I have been very tempted, so please don't take this comment as condemning you or anyone else who has commented, that is not my intent. I simply want to set the record strait, it wasn't my intent to comment about Microsoft. My comment was directed at what I felt was your accusation that you felt the LRSA was misrepresented and was only about the fees that a legacy resource holder should pay. > ARIN costs money to run and it isn't the Net Fairies that pay for it. > It's all the ISP's who are reallocating IP > addresses that pay for ARIN, that is money that is coming out of the > pockets of hard working men and women who build the networks that > allow Joe Blow and Sally Schmoe to get online. I agree running ARIN and all that represents, which is far more than just running a database, is expensive. I personally have had nothing to do with setting the rate structure. I simple arranged for the legacy resource holding organization that I represent, at least in my day job, to sign a LRSA, after what I felt were necessary improvements had been made. So, the University of Minnesota is at least paying something related to its Legacy holdings now, making its contribution. >> So, your view on the >> difference, or lack there of, in the fees can vary significantly >> depending on your perspective. > > Here's a thought, how about we charge EVERY address holder the same > amount of money that end users pay? I think there are defiantly some inequities between the fees for a large end user organization and a small ISP, especially in the case of IPv4. In the case of the University of Minnesota, we felt that an IPv6 allocation was most appropriate for our planned use of IPv6 and we should be paying an annual fee associated with that allocation. So those inequities may fade as part of the IPv6 transition, in some cases, at least that is my hope. >> There has been a FAQ regarding the LRSA >> for sometime as well, the current version is at; >> https://www.arin.net/resources/legacy/ >> >> It provides an excellent summary of the LRSA, for those who aren't into >> recreationally reading contracts. :) I know the LRSA, and the RSA, >> almost put me to sleep when I had to read it as part of getting my >> organization to sign them. :) I only survived with the assistance of >> multiple caffeinated beverages. :) >> >> I'll also add that a number of improvements have been made in the LRSA >> since its initial version, and a number of these improvements have been >> integrated into the RSA as well, for the benefit of everyone who has >> received resources from ARIN. >> > The problem here is you cannot discern the real difference between the > RSA and the LRSA just by reading them. Just as you cannot discern the > real meaning of the NRPM by just reading it. For example the NRPM > says that transfer recipients sign "RSA" It is only when you parse the > syntax the way that a lawyer would that you can see that this could > mean an LRSA or an RSA. Agreed, the NRPM, RSA, and LRSA are not simple to understand, but I'm not completely sure what can really be done about that. As an AC member I have been trying to make the NRPM more understandable, but that leads to long and wordy policy proposals which a vocal portion of the community doesn't like. They want to deal with small concise portions of policy text at a time. I understand that desire, but it doesn't lead to a smooth, flowing, understandable overall body of policy text. It creates stand-alone ideas that may or may not logically link or flow with the text and other policies surrounding it. As for the RSA and LRSA they are contracts and the realm of lawyers and legalese and probably always will be, this is not a new problem though, Shakespeare said "kill all the Lawyers." I'm not sure that is a socially acceptable solution to the problem. :) > I would like to know what the Microsoft lawyers parsed out of the two > documents that made the LRSA so much more attractive. I can read both > documents and see differences but I don't know how a lawyer would > interpret what those differences are and why one would be so much more > attractive than the other. Unfortunately that is not how our adversarial legal system works. > Ted -- =============================================== 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 BillD at cait.wustl.edu Tue May 10 13:34:01 2011 From: BillD at cait.wustl.edu (Bill Darte) Date: Tue, 10 May 2011 12:34:01 -0500 Subject: [arin-ppml] Draft Proposal 2011-1 - Comments request - Globally Coordinated Transfer Policy Message-ID: Hello, After the San Juan meeting, the Advisory Council tried to resolve differences of opinion among themselves and to ascertain the level of consensus around Draft Policy 2011-1 Globally Coordinated Transfer Policy...and also to determine what objections still remain. The policy text reviewed at the meeting was as follows: Any RIR's resource registrant may transfer IPv4 addresses to the resource registrant of another RIR as long as the two RIRs agree and maintain compatible, needs-based transfer policies that exercise Internet stewardship consistent with the values expressed in RFC2050. *************** It was clear from the meeting that the community wanted the AC to continue to work on this policy. I have asked each AC member to join this conversation along with your input to: 1. Identify support or objection 2. If objections exist, to succinctly identify what they are..and, 3. How objections might be concisely remedied in text Thank you for your continuing support for the Policy Development Process of ARIN and for your contributions to this important discussion. Bill Darte Primary Shepherd DP 2011-1 ARIN Advisory Council -------------- next part -------------- An HTML attachment was scrubbed... URL: From info at arin.net Tue May 10 13:34:21 2011 From: info at arin.net (ARIN) Date: Tue, 10 May 2011 13:34:21 -0400 Subject: [arin-ppml] ARIN-prop-148 LRSA resources must not be transferred to LRSA Message-ID: <4DC9771D.6010809@arin.net> ARIN-prop-148 LRSA resources must not be transferred to LRSA 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-148 LRSA resources must not be transferred to LRSA Proposal Originator: Ted Mittelstaedt Proposal Version: 1 Date: 10 May 2011 Proposal type: Modify Policy term: permanent Policy statement: in section 8 of the NRPM in clause 8.3 the following sentence is added: The recipient of transferred number resources MUST sign the RSA with ARIN if the resources being transferred are already under LRSA. Resources under LRSA may not be transferred to a recieving organization and placed under a new LRSA with that organization. They must be placed under the RSA, not the LRSA. Rationale: John Curran admitted in a recent posting to the PPML that the recent Nortel to Microsoft address transfer resulted in the addresses received by Microsoft being placed under LRSA, not RSA. This indicates that ARIN interpreted section of 8.3 stating: "...Such transferred number resources may only be received under RSA by organizations that are within the ARIN..." to mean ANY version of the RSA, be it LRSA or RSA. Currently the community is engaged in a debate over this since many people who supported the transfer section being added did not support the idea that a recipient could get resources under LRSA. This policy proposal does not attempt to answer that debate. However the fact that ARIN would interpret the manual in this manner opens a loophole in that LRSA resources may be transferred to recipients who would continue to demand that they remain under LRSA, and the Nortel to Microsoft transfer indicates that ARIN could allow such a transfer, since it is not specifically prohibited in the NRPM. This proposal still leaves the loophole that resources could be received from "Legacy" holders and placed under LRSA. Timetable for implementation: immediate From mike at nationwideinc.com Tue May 10 14:01:45 2011 From: mike at nationwideinc.com (Mike Burns) Date: Tue, 10 May 2011 14:01:45 -0400 Subject: [arin-ppml] Draft Proposal for Needs-Free IPv4 Transfers References: <323AD9AC0BE24F9BB91D3E712160681A@mike><77338713-58D2-47AA-9045-C5D19DBB8DA0@delong.com><"BANLkTik8jUuimto500D45ngcoOp CXg4vPg"@mail.gmail.com><8728DDCCEA5E476D8AC8E59368684F12@mike><7A8B0D17-0AC3-4C60-B466-39C29708F826@arin.net> <"A818163231EE4B39B4297986293565F5"@mike> <554FF02B-0E97-4C0D-9E7F-17377C1AFFAE@arin.net> <1AE5056E-A8F9-424A-9AF0-08BB56B425E8@arin.net> Message-ID: <0CFB85F12F10469BAC03B9B467579FC9@mike> Hi John, >Please propose changes to the RSA or LRSA via the ARIN ACSP > as these >are business practice documents and as such are outside the >scope of the ARIN Policy Development Process. Thanks. >> To my mind, the difference between them would blur significantly, and I >> believe more legacy holders would be inclined to sign either agreement if >> these rights were ensured by policy. >> And this would serve the purposes of all who look back on legacy >> distributions with some regret over the lack of associated agreements, >> and who hope for an inclusive policy which will bring legacy holders into >> the >>fold. >It's quite fine to create policy to cover the specific goals you >have in mind. As a purely hypothetical example, you could propose >"ARIN shall only reclaim or revoke resources for lack of payment of >service fees, fraudulent use or representations to ARIN, or dissolution >of the address holder, and specifically ARIN shall not reclaim number >resource due to lack of utilization." >If discussed, supported by the community, and adopted, ARIN staff >and counsel would then revised the registration services agreements >accordingly. OK, maybe it would be easier to modify section 12 than the RSA, but both would probably have to be modified. Any discussion about modifying 12 to remove utilization requirements would probably inform the ARIN staff and counsel about community support for revising agreements. > Finally, do you concur with my reading of NRPM which does not seem to have > language in section 12 which clearly allows for a utilization-based > resource review? > My reading of it is that the reviewers look for policy compliance, but all > the policy I read about utilization is in the context of an original or > subsequent allocation. > On the other hand, the RSA has clear language allowing review for > compliance with the intended purpose of the addresses as expressed on the > application for resources. > I don't know if it is permissible to change the RSA via the normal policy > development process, though. >I'm not certain I understand your concern. Both the RSA and LRSA >have a utilization review in their respective section 8, and the >NRPM 12 provides for reviews at any time, including upon request >of new resources. >Can you elaborate some? If I were allocated a /18 in 2002 order to host websites, and I have sold or lost the customers but retain the corporation, could my resources be reviewed and revoked per NRPM section 12 without recourse to the RSA section 8? My reading of it says no, section 12 does not give ARIN the right to request a return for under-utilization only. I think this is the salient section, 12.4: "Organizations found by ARIN to be materially out of compliance with current ARIN policy shall be requested or required to return resources as needed to bring them into (or reasonably close to) compliance." In my example, what current ARIN policy would I be materially out of compliance with? ARIN policy talks quite a bit about utilization, but always in the context of a new allocation, not the utilization of a prior allocation outside that context. Of course, the RSA section 8 would provide this authority as a result of its "compliance with intended purposes" language. My concern was that I thought section 12 was toothless in this regard, so I left it unmodified in my proposal and instead modified the RSA, which I now know is not possible via this policy proposal mechanism. However, in order to have a viable proposal to eliminate needs requirements for transfers, like APNIC, it is clear that whatever agreement is required of transfer recipients must not have utilization review language in it, or it would vitiate the whole idea of needs-free transfers, and the whole idea of booking every transaction in whois to maintain its integrity. If I make a proposal to change the RSA to remove the language about "intended purposes" via the ARIN ACSP as you indicate, can I make my policy proposal to change NRPM 8.3 linked, or contingent upon, action to change the RSA? Are there any examples of prior policy proposals which required changes to agreements that I can use as guidance? Regards, Mike From owen at delong.com Tue May 10 14:13:46 2011 From: owen at delong.com (Owen DeLong) Date: Tue, 10 May 2011 11:13:46 -0700 Subject: [arin-ppml] Draft Proposal for Needs-Free IPv4 Transfers In-Reply-To: References: <323AD9AC0BE24F9BB91D3E712160681A@mike><77338713-58D2-47AA-9045-C5D19DBB8DA0@delong.com><8728DDCCEA5E476D8AC8E59368684F12@mike> <7A8B0D17-0AC3-4C60-B466-39C29708F826@arin.net> Message-ID: <3106C4E2-5883-4E80-BF72-D073535406FA@delong.com> On May 10, 2011, at 8:16 AM, Mike Burns wrote: > > >> Since this point is germane to my proposal, could I ask for some status on the discussion that Bill Herrin and John Curran were having related to the potential for making some changes to the LRSA? > >> Currently in progress. We're trying to make more plain english language for >> the existing terms and conditions, and remove language which is conflicting >> and/or inoperative. > > Thanks John, is there any expected timeframe for a revised LRSA? > > >> ... >> And now legacy holders see that a bankruptcy court gave Nortel the unrestricted right to transfer addresses originally allocated as legacy space to entities Nortel acquired in the 1990s. >> So addresses allocated to Company A passed into the "ownership" of Company B without recourse to any ARIN processes. > >> The above statement is factually incorrect. The transfer occurred in >> accordance with the community developed policies. If it hadn't been, >> then the transfer would not have been approved, and the outcome of that >> situation might have been more indicative (either way). > > > If the transfer would not have been "approved" by ARIN, wouldn't Microsoft still be using addresses allocated originally to Nortel's "predecessors in interest" ? If they were, then it would have been appropriate for ARIN to determine that the addresses in question had been hijacked from the original (possibly now defunct) recipient and reclaim them for re-issuance to others through proper allocation policy. > What we are dancing around is the definition of transfer. > If by transfer, you mean ARIN updating whois, then you can say that all transfers happen through policy. > If by transfer you mean that somebody else is actually using addresses which they have purchased from the original registrant, and ARIN has not updated whois, well those transfers have occurred, and if the costs of acquiring ARIN's approval are higher than the cost of ignoring ARIN, whois will continue to degrade as these transactions continue. > Transfers outside of policy are indistinguishable to ARIN from hijackings. If the recorded recipient is no longer utilizing the addresses and they have been hijacked, ARIN has a responsibility, IMHO, to reclaim those addresses and issue them to an appropriate party through standard ARIN policy. > >> I want all transfers recorded in whois, and I don't want to miss recording transactions due to requiring agreements that are onerous. >> >> Still, as a legacy holder myself who has not signed the LRSA, I would be inclined to sign the stripped-down LRSA Mr. Herrin suggested, and I would be more likely to sign even an RSA upon adoption of my >proposed policy, since I would have new rights to resist a utilization review and would also have the ability to do needs-free transfers. These things would go a long way in overcoming existing disincentives to signing >either agreement. > >> The utilization review is a good example: it is definitely non-operative >> language due to other phrasing in the LRSA, so there is a great question >> as to whether it is worth retaining in the LRSA (and to some extent, the >> same question applies to the RSA as policies for transfers for unneeded >> are now operative) > > It makes no sense to have non-operative language cluttering up an agreement unless it serves some other purpose. > But I don't understand your parenthetical, is there a typo? > It's not necessarily so inoperative in the RSA, but, with certain policy changes currently under consideration, it could become so. Owen From jcurran at arin.net Tue May 10 14:22:16 2011 From: jcurran at arin.net (John Curran) Date: Tue, 10 May 2011 18:22:16 +0000 Subject: [arin-ppml] Draft Proposal for Needs-Free IPv4 Transfers In-Reply-To: <0CFB85F12F10469BAC03B9B467579FC9@mike> References: <323AD9AC0BE24F9BB91D3E712160681A@mike> <77338713-58D2-47AA-9045-C5D19DBB8DA0@delong.com> <"BANLkTik8jUuimto500D45ngcoOp CXg4vPg"@mail.gmail.com> <8728DDCCEA5E476D8AC8E59368684F12@mike> <7A8B0D17-0AC3-4C60-B466-39C29708F826@arin.net> <554FF02B-0E97-4C0D-9E7F-17377C1AFFAE@arin.net> <1AE5056E-A8F9-424A-9AF0-08BB56B425E8@arin.net> <0CFB85F12F10469BAC03B9B467579FC9@mike> Message-ID: <54564FD7-2846-4F6E-BC40-A0C825E83445@arin.net> On May 10, 2011, at 11:01 AM, Mike Burns wrote: > >> Can you elaborate some? > > If I were allocated a /18 in 2002 order to host websites, and I have sold or lost the customers but retain the corporation, could my resources be reviewed and revoked per NRPM section 12 without recourse to the RSA section 8? Yes, see below. > My reading of it says no, section 12 does not give ARIN the right to request a return for under-utilization only. > I think this is the salient section, 12.4: > "Organizations found by ARIN to be materially out of compliance with current ARIN policy shall be requested or required to return resources as needed to bring them into (or reasonably close to) compliance." > In my example, what current ARIN policy would I be materially out of compliance with? > ARIN policy talks quite a bit about utilization, but always in the context of a new allocation, not the utilization of a prior allocation outside that context. While the criteria are provided in context of a new allocation, the actual IP assignment or allocation remains "valid as long as the criteria continues to be met" (RFC 2050). The RFC 2050 guidance is specifically included per NRPM 4.1.7 (IPv4 General Principles). I'm unaware of ARIN performing reclamation against any organization acting in good faith under such circumstances, but it would technically be a valid course of action. > Of course, the RSA section 8 would provide this authority as a result of its "compliance with intended purposes" language. Correct. > My concern was that I thought section 12 was toothless in this regard, so I left it unmodified in my proposal and instead modified the RSA, which I now know is not possible via this policy proposal mechanism. > However, in order to have a viable proposal to eliminate needs requirements for transfers, like APNIC, it is clear that whatever agreement is required of transfer recipients must not have utilization review language in it, or it would vitiate the whole idea of needs-free transfers, and the whole idea of booking every transaction in whois to maintain its integrity. Best to make explicit via a policy proposal which states the goal. We will amend the agreements accordingly if the draft policy supported by the community and adopted. > If I make a proposal to change the RSA to remove the language about "intended purposes" via the ARIN ACSP as you indicate, can I make my policy proposal to change NRPM 8.3 linked, or contingent upon, action to change the RSA? Are there any examples of prior policy proposals which required changes to agreements that I can use as guidance? Nothing is needed other than a simple statement in the policy rationale that notes that changes to the registration service agreements may be necessary if the policy is adopted. Thanks! /John John Curran President and CEO ARIN From mike at nationwideinc.com Tue May 10 14:24:20 2011 From: mike at nationwideinc.com (Mike Burns) Date: Tue, 10 May 2011 14:24:20 -0400 Subject: [arin-ppml] Draft Proposal for Needs-Free IPv4 Transfers References: <323AD9AC0BE24F9BB91D3E712160681A@mike><77338713-58D2-47AA-9045-C5D19DBB8DA0@delong.com><8728DDCCEA5E476D8AC8E59368684F12@mike> <7A8B0D17-0AC3-4C60-B466-39C29708F826@arin.net> <3106C4E2-5883-4E80-BF72-D073535406FA@delong.com> Message-ID: <0871E647591749DBAC278D8D5FE31D2F@mike> Hi Owen, >Transfers outside of policy are indistinguishable to ARIN from hijackings. >If the >recorded recipient is no longer utilizing the addresses and they have been >hijacked, >ARIN has a responsibility, IMHO, to reclaim those addresses and issue them >to an >appropriate party through standard ARIN policy. >Owen But these transfers do happen, and for ARIN to declare them all hijackings, even though legacy holders have no agreement with ARIN to notify them of transfers, is a recipe for the ignoring and increasing irrelevance of whois. I hate to keep harping on this, but the bankruptcy docs clearly say these addresses were allocated to Nortel's "predecessors in interest" in the early 1990s. Since ARIN became notified that the recorded recipient was no longer utilizing the addresses, why didn't ARIN excercise their responsibility to reclaim those addresses and issue them to an appropriate party through standard ARIN policy? Because there is no standard ARIN policy which would allow them to reclaim legacy space. Regards, Mike From tedm at ipinc.net Tue May 10 14:31:10 2011 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Tue, 10 May 2011 11:31:10 -0700 Subject: [arin-ppml] New IPv4 Transfer policy In-Reply-To: <4DC9592A.4070801@bogus.com> References: <0F4E49B9-09DB-434F-AD5D-87DA3DCC42D8@matthew.at> <4DC86683.90204@ipinc.net> <4DC8D506.3010203@umn.edu> <4DC956B5.3030107@ipinc.net> <4DC9592A.4070801@bogus.com> Message-ID: <4DC9846E.2030205@ipinc.net> On 5/10/2011 8:26 AM, Joel Jaeggli wrote: > On 5/10/11 8:16 AM, Ted Mittelstaedt wrote: > >> Microsoft, a company with 80K employees, could not have possibly >> provided justification that would have resulted in 50% utilization of >> 500K additional IP addresses in 1 year. Are you proposing the company >> grow 4 times it's existing size in 1 year? The only possible >> justification would be if they were buying them to reallocate to >> customers in a network the same way that any LIR does. > > I don't have any particular interest in the outcome but with all due > respect you don't have any idea how they intend to utilize them, and > address space utilization on the basis of employee count is specious > enough to be discarded out of hand. It's obvious that you've never been > a customer of microsoft's hosting platform or their SOAS business if the > only possible conclusion you can draw is that they're going into the LIR > business. > Eh, a betting man, are you? One thing I love about these challenges is that history is going to show that only one of us is right. I'm betting on the mathematics. Your betting on a guesstimate - I think. A couple years from now, one of us will be right. If I'm wrong, I'll have no qualms about standing up to have people say I told you so and throw vegetables. If your wrong, however..... Ted > joel From tedm at ipinc.net Tue May 10 14:49:38 2011 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Tue, 10 May 2011 11:49:38 -0700 Subject: [arin-ppml] New IPv4 Transfer policy In-Reply-To: <4DC97080.6070007@umn.edu> References: <0F4E49B9-09DB-434F-AD5D-87DA3DCC42D8@matthew.at> <4DC86683.90204@ipinc.net> <4DC8D506.3010203@umn.edu> <4DC956B5.3030107@ipinc.net> <4DC97080.6070007@umn.edu> Message-ID: <4DC988C2.5060202@ipinc.net> On 5/10/2011 10:06 AM, David Farmer wrote: > On 5/10/11 10:16 CDT, Ted Mittelstaedt wrote: >> On 5/9/2011 11:02 PM, David Farmer wrote: >>> On 5/9/11 17:11 CDT, Ted Mittelstaedt wrote: >>>> Ask ARIN >>>> >>>> Financially, the fees for the block of numbers that Microsoft got >>>> from that transfer are nothing in comparison to what they paid for >>>> it, and Microsoft is also known for spending tons of money on >>>> useless stuff. So there must have been some difference between >>>> the RSA and the LRSA that made Microsoft choose the LRSA and the >>>> only thing I can think of is the LRSA is less restrictive in some >>>> manner. >>>> >>>> I suspect we need to have ARIN modify the LRSA. The LRSA was sold >>>> to us on the basis that it was the same thing as the RSA without >>>> the annual fee. Obviously, the Microsoft lawyers found out that >>>> this wasn't true. ARIN has a lot of explaining to do, here. >>>> >>>> Ted >>> >>> I'm not sure what you feel you were sold. However, the details of the >>> LRSA are not secret, have been published for sometime, and there is more >>> than just a difference in fees for Legacy ISPs. Note: Legacy end users >>> pay the same annual fees as any other end user. >> >> Microsoft, a company with 80K employees, could not have possibly >> provided justification that would have resulted in 50% utilization of >> 500K additional IP addresses in 1 year. Are you proposing the company >> grow 4 times it's existing size in 1 year? The only possible >> justification would be if they were buying them to reallocate to >> customers in a network the same way that any LIR does. >> >> I fail to see what is to be gained by defending what Microsoft did here. >> Insisting that ARIN have them sign an LRSA instead of the RSA is >> deplorable. For all ARIN's labor they put into handling this transfer >> they get paid $100? > > I think you misunderstand my comments, I have not, and refuse to > speculate, defend, or otherwise comment regarding what Microsoft did or > didn't do. I simple do not know enough facts to do anything but > participate in rumor mongering, so I have decided to abstain from > commenting. However, I'll admit I have been very tempted, so please > don't take this comment as condemning you or anyone else who has > commented, that is not my intent. I simply want to set the record > strait, it wasn't my intent to comment about Microsoft. > > My comment was directed at what I felt was your accusation that you felt > the LRSA was misrepresented and was only about the fees that a legacy > resource holder should pay. > OK, but that still doesn't really answer my question of what about the LSRA is so much better than the RSA for a company like Microsoft, which probably spends more in it's annual budget for office birthday parties than it would on ARIN fees? In other words, if the fee difference isn't the issue, what is it? >> ARIN costs money to run and it isn't the Net Fairies that pay for it. >> It's all the ISP's who are reallocating IP >> addresses that pay for ARIN, that is money that is coming out of the >> pockets of hard working men and women who build the networks that >> allow Joe Blow and Sally Schmoe to get online. > > I agree running ARIN and all that represents, which is far more than > just running a database, is expensive. I personally have had nothing to > do with setting the rate structure. I simple arranged for the legacy > resource holding organization that I represent, at least in my day job, > to sign a LRSA, after what I felt were necessary improvements had been > made. So, the University of Minnesota is at least paying something > related to its Legacy holdings now, making its contribution. > The U of Min isn't really a competitor (and most Universities are in this boat) with a commercial ISP - at least I hope it isn't - so there is at least that. There has been a discussion in the past regarding use of fees as a tool to retard IPv4 address consumption. I look on this as more of a fairness issue. The fee structure is, fundamentally, based on the notion that a commercial money-making LIR should pay more than something like a public university even though they may consume fewer IPv4 addresses. Thus it is very irritating when a commercial entity like Microsoft appears to get off scott free without making any kind of additional compensation to ARIN for enabling it to essentially make a ton more money than it's competitors. Do we really want an Internet with a few large LIRs and all the smaller ones gone out of business? Because that is what the ARIN fee structure encourages. >>> So, your view on the >>> difference, or lack there of, in the fees can vary significantly >>> depending on your perspective. >> >> Here's a thought, how about we charge EVERY address holder the same >> amount of money that end users pay? > > I think there are defiantly some inequities between the fees for a large > end user organization and a small ISP, especially in the case of IPv4. > In the case of the University of Minnesota, we felt that an IPv6 > allocation was most appropriate for our planned use of IPv6 and we > should be paying an annual fee associated with that allocation. So those > inequities may fade as part of the IPv6 transition, in some cases, at > least that is my hope. > There are more inequities between a large LIR and a small LIR. >>> There has been a FAQ regarding the LRSA >>> for sometime as well, the current version is at; >>> https://www.arin.net/resources/legacy/ >>> >>> It provides an excellent summary of the LRSA, for those who aren't into >>> recreationally reading contracts. :) I know the LRSA, and the RSA, >>> almost put me to sleep when I had to read it as part of getting my >>> organization to sign them. :) I only survived with the assistance of >>> multiple caffeinated beverages. :) >>> >>> I'll also add that a number of improvements have been made in the LRSA >>> since its initial version, and a number of these improvements have been >>> integrated into the RSA as well, for the benefit of everyone who has >>> received resources from ARIN. >>> >> The problem here is you cannot discern the real difference between the >> RSA and the LRSA just by reading them. Just as you cannot discern the >> real meaning of the NRPM by just reading it. For example the NRPM >> says that transfer recipients sign "RSA" It is only when you parse the >> syntax the way that a lawyer would that you can see that this could >> mean an LRSA or an RSA. > > Agreed, the NRPM, RSA, and LRSA are not simple to understand, but I'm > not completely sure what can really be done about that. As an AC member > I have been trying to make the NRPM more understandable, but that leads > to long and wordy policy proposals which a vocal portion of the > community doesn't like. Well, I might say they better man up because in business that is how contracts are. Our last AT&T contract was 6 pages of small print. Businesses have learned that short contracts leave huge loopholes because they leave too much to interpretation. One of my former bosses was like that. He was a supporter of the "single page contract" Yet he got screwed over time and again by other businesses. > They want to deal with small concise portions of > policy text at a time. I understand that desire, but it doesn't lead to > a smooth, flowing, understandable overall body of policy text. It > creates stand-alone ideas that may or may not logically link or flow > with the text and other policies surrounding it. > And it creates massive loopholes. Lawyers love people like that. > As for the RSA and LRSA they are contracts and the realm of lawyers and > legalese and probably always will be, this is not a new problem though, > Shakespeare said "kill all the Lawyers." I'm not sure that is a socially > acceptable solution to the problem. :) > >> I would like to know what the Microsoft lawyers parsed out of the two >> documents that made the LRSA so much more attractive. I can read both >> documents and see differences but I don't know how a lawyer would >> interpret what those differences are and why one would be so much more >> attractive than the other. > > Unfortunately that is not how our adversarial legal system works. > our adversarial legal system is far better than anything else, but you simply don't get into that realm unless you know what you are doing. Over the last 25 years of my life, every single story I have ever heard from anyone who has felt "screwed over" by the lawyers or the legal system - and that includes personal as well as business problems - can be boiled down to lack of adequate communication at the very beginning. Every one. Yes, people can do things like enter into business dealings or marriages or home sales with inadequate contracts that do not specify enough, and the majority of them work out. But, your never going to find one of these dealings that has gone sour where the parties feel screwed over by the system, when there was an adequate level of contracting done in the beginning. People may kick themselves for signing the used car lease, they may blame the dealer and decide he's a snake, but they don't go blaming the legal system. Ted >> Ted > > From jcurran at arin.net Tue May 10 14:51:25 2011 From: jcurran at arin.net (John Curran) Date: Tue, 10 May 2011 18:51:25 +0000 Subject: [arin-ppml] Draft Proposal for Needs-Free IPv4 Transfers In-Reply-To: <0871E647591749DBAC278D8D5FE31D2F@mike> References: <323AD9AC0BE24F9BB91D3E712160681A@mike><77338713-58D2-47AA-9045-C5D19DBB8DA0@delong.com><8728DDCCEA5E476D8AC8E59368684F12@mike> <7A8B0D17-0AC3-4C60-B466-39C29708F826@arin.net> <3106C4E2-5883-4E80-BF72-D073535406FA@delong.com> <0871E647591749DBAC278D8D5FE31D2F@mike> Message-ID: <26651534-E310-400A-B073-8D21AA70882B@arin.net> On May 10, 2011, at 11:24 AM, Mike Burns wrote: > Hi Owen, > >> Transfers outside of policy are indistinguishable to ARIN from hijackings. If the >> recorded recipient is no longer utilizing the addresses and they have been hijacked, >> ARIN has a responsibility, IMHO, to reclaim those addresses and issue them to an >> appropriate party through standard ARIN policy. >> Owen > > But these transfers do happen, and for ARIN to declare them all hijackings, even though legacy holders have no agreement with ARIN to notify them of transfers, is a recipe for the ignoring and increasing irrelevance of whois. > > I hate to keep harping on this, but the bankruptcy docs clearly say these addresses were allocated to Nortel's "predecessors in interest" in the early 1990s. > Since ARIN became notified that the recorded recipient was no longer utilizing the addresses, why didn't ARIN excercise their responsibility to reclaim those addresses and issue them to an appropriate party through standard ARIN policy? > > Because there is no standard ARIN policy which would allow them to reclaim legacy space. We do not consider number resources being used by legitimate successor organizations be "hijacked", regardless of whether they are ARIN-issued or legacy assignments. Successor means an entity materially acquiring all of the assets and operations of another. Whether legacy or ARIN-issued, ARIN encourages parties which acquire other organizations to put in a transfer request for the affected resources per NRPM 8.2 (M&A Transfer) FYI, /John John Curran President and CEO ARIN From owen at delong.com Tue May 10 14:58:29 2011 From: owen at delong.com (Owen DeLong) Date: Tue, 10 May 2011 11:58:29 -0700 Subject: [arin-ppml] Draft Proposal for Needs-Free IPv4 Transfers In-Reply-To: <0871E647591749DBAC278D8D5FE31D2F@mike> References: <323AD9AC0BE24F9BB91D3E712160681A@mike><77338713-58D2-47AA-9045-C5D19DBB8DA0@delong.com><8728DDCCEA5E476D8AC8E59368684F12@mike> <7A8B0D17-0AC3-4C60-B466-39C29708F826@arin.net> <3106C4E2-5883-4E80-BF72-D073535406FA@delong.com> <0871E647591749DBAC278D8D5FE31D2F@mike> Message-ID: <82A684B2-DAB9-4334-B99D-C9A55FEB2E74@delong.com> On May 10, 2011, at 11:24 AM, Mike Burns wrote: > Hi Owen, > >> Transfers outside of policy are indistinguishable to ARIN from hijackings. If the >> recorded recipient is no longer utilizing the addresses and they have been hijacked, >> ARIN has a responsibility, IMHO, to reclaim those addresses and issue them to an >> appropriate party through standard ARIN policy. >> Owen > > But these transfers do happen, and for ARIN to declare them all hijackings, even though legacy holders have no agreement with ARIN to notify them of transfers, is a recipe for the ignoring and increasing irrelevance of whois. > > I hate to keep harping on this, but the bankruptcy docs clearly say these addresses were allocated to Nortel's "predecessors in interest" in the early 1990s. > Since ARIN became notified that the recorded recipient was no longer utilizing the addresses, why didn't ARIN excercise their responsibility to reclaim those addresses and issue them to an appropriate party through standard ARIN policy? > First, the entities in question weren't necessarily defunct and I suspect that Nortel would have completed an 8.2 transfer if ARIN had contacted them prior to the bankruptcy. By the time ARIN became aware of the issue, M$ was already involved and the right thing to do was to process the transfer under 8.3 as if the 8.2 transfers had already occurred. Since the 8.2 transfers would be rendered moot by the subsequent 8.3 transfer, skipping that extra procedural step at that point basically made sense. > Because there is no standard ARIN policy which would allow them to reclaim legacy space. > ARIN has and will (hopefully) continue to reclaim legacy resources that are held by defunct organizations. Additionally in the case where the registered organization still exists, ARIN should reclaim resources that organization is no longer using to prevent hijacking and abuse. If ARIN informs me that section 12 is inadequate for these purposes as currently written, I will propose policy to rectify that problem. Owen From stephen at sprunk.org Tue May 10 14:56:38 2011 From: stephen at sprunk.org (Stephen Sprunk) Date: Tue, 10 May 2011 13:56:38 -0500 Subject: [arin-ppml] Draft Proposal for Needs-Free IPv4 Transfers In-Reply-To: <0CFB85F12F10469BAC03B9B467579FC9@mike> References: <323AD9AC0BE24F9BB91D3E712160681A@mike><77338713-58D2-47AA-9045-C5D19DBB8DA0@delong.com><"BANLkTik8jUuimto500D45ngcoOp CXg4vPg"@mail.gmail.com><8728DDCCEA5E476D8AC8E59368684F12@mike><7A8B0D17-0AC3-4C60-B466-39C29708F826@arin.net> <"A818163231EE4B39B4297986293565F5"@mike> <554FF02B-0E97-4C0D-9E7F-17377C1AFFAE@arin.net> <1AE5056E-A8F9-424A-9AF0-08BB56B425E8@arin.net> <0CFB85F12F10469BAC03B9B467579FC9@mike> Message-ID: <4DC98A66.8080702@sprunk.org> On 10-May-11 13:01, Mike Burns wrote: > OK, maybe it would be easier to modify section 12 than the RSA, but > both would probably have to be modified. > Any discussion about modifying 12 to remove utilization requirements > would probably inform the ARIN staff and counsel about community > support for revising agreements. Considering that RSA 8 predates NRPM 12 by a decade or so, I'm not sure about that. However, just modifying policy should be enough to get the effect you're looking for. The very reason I proposed (the text that became) NRPM 12 is that ARIN rejected my ACSP suggestion to enforce RSA 8, based on a lack of activating policy. If NRPM 12 went away, or were weakened in the way you propose, presumably they'd go back to that position. Also, ARIN still hasn't implemented NRPM 12.2(c) as intended, so I fail to see why you think this matter is so urgent. > ... could my resources be reviewed and revoked per NRPM section 12 > without recourse to the RSA section 8? RSA 8 and NRPM 12 work together; neither has teeth without the other. It has been argued (by me and others) that RSA 8 /could/ be used without NRPM 12, and therefore NRPM 12 only serves to /limit/ how RSA 8 can be used, but to date that hasn't been ARIN's interpretation. It's been a while since I've read the LRSA, but AFAIK there is nothing there for NRPM 12 to activate, and that absence is where the special status comes from. > My reading of it says no, section 12 does not give ARIN the right to > request a return for under-utilization only. > I think this is the salient section, 12.4: > "Organizations found by ARIN to be materially out of compliance with > current ARIN policy shall be requested or required to return resources > as needed to bring them into (or reasonably close to) compliance." > In my example, what current ARIN policy would I be materially out of > compliance with? > ARIN policy talks quite a bit about utilization, but always in the > context of a new allocation, not the utilization of a prior allocation > outside that context. Resources are justified based on current and/or projected utilization. If that utilization disappears or fails to materialize, respectively, then the registrant is no longer compliant. > If I were allocated a /18 in 2002 order to host websites, and I have > sold or lost the customers but retain the corporation, ... You were allocated that /18 under a specific policy provision, which requires certain current and projected utilization. If you no longer meet those requirements, then your /18--or a portion of it--can be revoked. If anyone doesn't think this is clear enough from the text, please let me know how it could be improved and I'll submit a proposal to clarify the intent. S -- Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3646 bytes Desc: S/MIME Cryptographic Signature URL: From mike at nationwideinc.com Tue May 10 15:04:48 2011 From: mike at nationwideinc.com (Mike Burns) Date: Tue, 10 May 2011 15:04:48 -0400 Subject: [arin-ppml] Draft Proposal for Needs-Free IPv4 Transfers References: <323AD9AC0BE24F9BB91D3E712160681A@mike><77338713-58D2-47AA-9045-C5D19DBB8DA0@delong.com><8728DDCCEA5E476D8AC8E59368684F12@mike><7A8B0D17-0AC3-4C60-B466-39C29708F826@arin.net><3106C4E2-5883-4E80-BF72-D073535406FA@delong.com><0871E647591749DBAC278D8D5FE31D2F@mike> <26651534-E310-400A-B073-8D21AA70882B@arin.net> Message-ID: Hi John, >We do not consider number resources being used by legitimate >successor organizations be "hijacked", regardless of whether >they are ARIN-issued or legacy assignments. Whew! >Successor means an >entity materially acquiring all of the assets and operations >of another. OK, but my term was not successor, it was "predecessor in interest" http://research.lawyers.com/glossary/predecessor-in-interest.html "a person who previously held the rights or interests currently held by another" is the top definition. Regards, Mike From mike at nationwideinc.com Tue May 10 15:13:25 2011 From: mike at nationwideinc.com (Mike Burns) Date: Tue, 10 May 2011 15:13:25 -0400 Subject: [arin-ppml] Draft Proposal for Needs-Free IPv4 Transfers References: <323AD9AC0BE24F9BB91D3E712160681A@mike><77338713-58D2-47AA-9045-C5D19DBB8DA0@delong.com><8728DDCCEA5E476D8AC8E59368684F12@mike> <7A8B0D17-0AC3-4C60-B466-39C29708F826@arin.net> <3106C4E2-5883-4E80-BF72-D073535406FA@delong.com> <0871E647591749DBAC278D8D5FE31D2F@mike> <82A684B2-DAB9-4334-B99D-C9A55FEB2E74@delong.com> Message-ID: >First, the entities in question weren't necessarily defunct and I suspect >that Nortel would >have completed an 8.2 transfer if ARIN had contacted them prior to the >bankruptcy. By the >time ARIN became aware of the issue, M$ was already involved and the right >thing to do >was to process the transfer under 8.3 as if the 8.2 transfers had already >occurred. Since >the 8.2 transfers would be rendered moot by the subsequent 8.3 transfer, >skipping that >extra procedural step at that point basically made sense. The judge had no truck for any of that, he said Nortel had the exclusive right to transfer those addresses. The entities were so defunct they were in a bankruptcy liquidation. The "skipping extra procedural step" sounds a lot like failing to issue the addresses back to ARIN for the designated transfer to MS, sounds a lot like replacing RSA with "modified LRSA", sounds a lot like an after-the-fact needs analysis coming in smack dab on the number of addresses previously negotiated for purchase. We are contorting ourselves to try to cover a legal transaction with ARIN policies. ARIN trust is the cost for this. > Because there is no standard ARIN policy which would allow them to reclaim > legacy space. > >ARIN has and will (hopefully) continue to reclaim legacy resources that are >held by defunct >organizations. >Additionally in the case where the registered organization still exists, >ARIN should reclaim >resources that organization is no longer using to prevent hijacking and >abuse. >If ARIN informs me that section 12 is inadequate for these purposes as >currently written, I >will propose policy to rectify that problem. >Owen What do you mean if ARIN informs you? You're ARIN. Read section 12 and tell me where the authority to do utilization based reviews are found. The authority is in the RSA only, and an appeal to a best practices IETF document like RFC2050 for authority is weak, IMO. Regards, Mike From mike at nationwideinc.com Tue May 10 15:20:31 2011 From: mike at nationwideinc.com (Mike Burns) Date: Tue, 10 May 2011 15:20:31 -0400 Subject: [arin-ppml] Draft Proposal for Needs-Free IPv4 Transfers Message-ID: <2FB67D2BC44B4E9A842167C387F2CD95@mike> Resources are justified based on current and/or projected utilization. If that utilization disappears or fails to materialize, respectively, then the registrant is no longer compliant. No, allocations are justified based on current and/or projected utilization. Where does it say that if the utilization disappears, the registrant is no longer compliant. What policy is he no longer compliant with? If I were allocated a /18 in 2002 order to host websites, and I have sold or lost the customers but retain the corporation, ... You were allocated that /18 under a specific policy provision, which requires certain current and projected utilization. If you no longer meet those requirements, then your /18--or a portion of it--can be revoked. Can you please give me the number of the policy I would not be in compliance with? Regards, Mike -------------- next part -------------- An HTML attachment was scrubbed... URL: From stephen at sprunk.org Tue May 10 15:23:13 2011 From: stephen at sprunk.org (Stephen Sprunk) Date: Tue, 10 May 2011 14:23:13 -0500 Subject: [arin-ppml] New IPv4 Transfer policy In-Reply-To: <4DC988C2.5060202@ipinc.net> References: <0F4E49B9-09DB-434F-AD5D-87DA3DCC42D8@matthew.at> <4DC86683.90204@ipinc.net> <4DC8D506.3010203@umn.edu> <4DC956B5.3030107@ipinc.net> <4DC97080.6070007@umn.edu> <4DC988C2.5060202@ipinc.net> Message-ID: <4DC990A1.1040602@sprunk.org> On 10-May-11 13:49, Ted Mittelstaedt wrote: > On 5/10/2011 10:06 AM, David Farmer wrote: >> My comment was directed at what I felt was your accusation that you >> felt the LRSA was misrepresented and was only about the fees that a >> legacy resource holder should pay. > > OK, but that still doesn't really answer my question of what about the > LSRA is so much better than the RSA for a company like Microsoft, > which probably spends more in it's annual budget for office birthday > parties than it would on ARIN fees? > > In other words, if the fee difference isn't the issue, what is it? The only other obvious difference is that resources under LRSA cannot be revoked. That's what dangerous about allowing LRSAs for NRPM 8.3 transfers: if the justification is discovered to be bullshit after the fact, there is nothing ARIN can do about it. > The fee structure is, fundamentally, based on the notion that a > commercial money-making LIR should pay more than something like a > public university even though they may consume fewer IPv4 addresses. > > Thus it is very irritating when a commercial entity like Microsoft > appears to get off scott free without making any kind of additional > compensation to ARIN for enabling it to essentially make a ton more > money than it's competitors. I don't see how you get that from the fee structure. Any org, public or private, getting an assignment pays $100 per year, and any org, public or private, getting an allocation pays a lot more. Supposedly, this is because allocations imply a lot more work for ARIN processing sub-allocations and sub-assignments, whereas assignments cannot be sub-allocated or sub-assigned. > Do we really want an Internet with a few large LIRs and all the > smaller ones gone out of business? Because that is what the ARIN fee > structure encourages. That's a matter of the decreasing cost per IP for larger allocations. It has nothing to do with how wildly divergent the allocation and assignment fee schedules are. > People may kick themselves for signing the used car lease, they may > blame the dealer and decide he's a snake, but they don't go blaming > the legal system. Of course they blame the legal system. They're just wrong; they should have blamed themselves for not reading/understanding the contract they signed. This has gotten so bad we now have a federal agency whose express purpose is to regulate credit contracts because consumers are unwilling/unable to do it themselves. S -- Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3646 bytes Desc: S/MIME Cryptographic Signature URL: From owen at delong.com Tue May 10 15:32:45 2011 From: owen at delong.com (Owen DeLong) Date: Tue, 10 May 2011 12:32:45 -0700 Subject: [arin-ppml] New IPv4 Transfer policy In-Reply-To: <4DC988C2.5060202@ipinc.net> References: <0F4E49B9-09DB-434F-AD5D-87DA3DCC42D8@matthew.at> <4DC86683.90204@ipinc.net> <4DC8D506.3010203@umn.edu> <4DC956B5.3030107@ipinc.net> <4DC97080.6070007@umn.edu> <4DC988C2.5060202@ipinc.net> Message-ID: > The fee structure is, fundamentally, based on the notion that a commercial money-making LIR should pay more than something like a public > university even though they may consume fewer IPv4 addresses. > This simply isn't true. The vast majority of IP End-User resource holders are for profit companies and I believe that the fee structure was built with this knowledge. The inherent assumptions in the fee structure, IMHO, are: + ISPs consume more ARIN time and resources dealing with reassignment issues, more frequent requests, and more complex issues requiring greater staff review of their applications. + ISPs get automatic voting membership in ARIN as part of their subscriber membership. + ISPs pay fees based on their peak annual growth rate. They do not pay per-request fees. + End users, by contrast tend to be much more stable, often acquiring an amount of resources once and then staying static (from an ARIN perspective) for several years thereafter. As such, a per-request fee for processing with a low annual maintenance fee makes more sense. Most end users choose not to participate in ARIN as members, but, those that do have the option for an additional fee. > Thus it is very irritating when a commercial entity like Microsoft > appears to get off scott free without making any kind of additional > compensation to ARIN for enabling it to essentially make a ton more > money than it's competitors. > Anyone who knows me will vouch for the fact that I will jump at any opportunity to cry fowl on virtually any Micr0$0ft action which warrants it. I expect to be leaving the Skype user community shortly based on today's announcement, for example. I have a long history of disdain for said convicted felon and their business practices. However, I just don't see the issue here. They are paying the same fee as any other end-user organization such as IBM, Apple, Chevron, etc. If they plan to use these addresses for reassignment as an LIR, then, yes, there might be an issue, but, I haven't yet seen any evidence that this is the case. There are lots of managed hosting companies and other such companies that use addresses to number their customer resources, but, still operate as end-users under ARIN policy because they retain control of the address space and do not reassign it in whois. > Do we really want an Internet with a few large LIRs and all the > smaller ones gone out of business? Because that is what the ARIN > fee structure encourages. > I'm not seeing how this is the case. In fact, the ARIN fee structure has not posed any meaningful impediment to any of the small ISPs I have worked for. When I joined HE, for example, we were in the Small fee category. Today, less than two years later, we are in the Large category. When I explained the fee issue to my management, it was regarded as a "no-brainer" to pay the additional fees to get the address space we needed to grow our business. > > There are more inequities between a large LIR and a small LIR. > I would agree with you if the fees were based on total size. They are not. They are based on consumption rate. Owen From owen at delong.com Tue May 10 15:36:36 2011 From: owen at delong.com (Owen DeLong) Date: Tue, 10 May 2011 12:36:36 -0700 Subject: [arin-ppml] Draft Proposal for Needs-Free IPv4 Transfers In-Reply-To: References: <323AD9AC0BE24F9BB91D3E712160681A@mike><77338713-58D2-47AA-9045-C5D19DBB8DA0@delong.com><8728DDCCEA5E476D8AC8E59368684F12@mike><7A8B0D17-0AC3-4C60-B466-39C29708F826@arin.net><3106C4E2-5883-4E80-BF72-D073535406FA@delong.com><0871E647591749DBAC278D8D5FE31D2F@mike> <26651534-E310-400A-B073-8D21AA70882B@arin.net> Message-ID: <9EB764CF-F388-4036-BF9C-28842F74A79E@delong.com> On May 10, 2011, at 12:04 PM, Mike Burns wrote: > Hi John, > >> We do not consider number resources being used by legitimate >> successor organizations be "hijacked", regardless of whether >> they are ARIN-issued or legacy assignments. > > Whew! > Note, this means legitimate acquisition of the entire functioning entity, which is not the hijackings to which I was referring. The transfer of the addresses as would be accomplished under 8.3 to a third party without the transfer of the original resource holder, OTOH, would, IMHO, not be a legitimate successor in interest and would be, essentially a hijacking unless said transfer was processed through ARIN in compliance with 8.3. > >Successor means an >> entity materially acquiring all of the assets and operations >> of another. > > OK, but my term was not successor, it was "predecessor in interest" > http://research.lawyers.com/glossary/predecessor-in-interest.html > > "a person who previously held the rights or interests currently held by another" is the top definition. > In this case, apparently (according to John), Nortel acquired the predecessor in interest organizations and did actually register those through 8.2 transfers with ARIN. Owen From stephen at sprunk.org Tue May 10 15:46:43 2011 From: stephen at sprunk.org (Stephen Sprunk) Date: Tue, 10 May 2011 14:46:43 -0500 Subject: [arin-ppml] Draft Proposal for Needs-Free IPv4 Transfers In-Reply-To: <0871E647591749DBAC278D8D5FE31D2F@mike> References: <323AD9AC0BE24F9BB91D3E712160681A@mike><77338713-58D2-47AA-9045-C5D19DBB8DA0@delong.com><8728DDCCEA5E476D8AC8E59368684F12@mike> <7A8B0D17-0AC3-4C60-B466-39C29708F826@arin.net> <3106C4E2-5883-4E80-BF72-D073535406FA@delong.com> <0871E647591749DBAC278D8D5FE31D2F@mike> Message-ID: <4DC99623.9080105@sprunk.org> On 10-May-11 13:24, Mike Burns wrote: >> Transfers outside of policy are indistinguishable to ARIN from >> hijackings. If the recorded recipient is no longer utilizing the >> addresses and they have been hijacked, ARIN has a responsibility, >> IMHO, to reclaim those addresses and issue them to an appropriate >> party through standard ARIN policy. > > But these transfers do happen, and for ARIN to declare them all > hijackings, even though legacy holders have no agreement with ARIN to > notify them of transfers, is a recipe for the ignoring and increasing > irrelevance of whois. The main relevance of the RIRs' databases is the fact that ISPs consult WHOIS before deciding whether to accept/advertise customer routes. RIRs also directly control rDNS delegations, which are important to most orgs. Soon, there will be RPKI as well. You are welcome to ignore all that and use whatever numbers you wish within your own network; plenty of folks do. However, as soon as you try to connect to the Internet, you're going to have to play ball with the RIR system. A "transfer" is a matter of updating an RIR database. If the database is not updated, then by definition there has been no transfer. > there is no standard ARIN policy which would allow them to reclaim > legacy space. There's a long-running debate about that. AFAIK, ARIN has no legal obligation to keep any registrations in their database unless a contract, e.g. RSA or LRSA, says so. To date, the community has chosen to do so anyway out of a sense of moral obligation, but that could change at any time. Other folks claim ARIN has no legal right to "take" space from legacy holders, but that ignores the plain fact that numbers are not property and therefore cannot be "taken", just like they cannot be bought or sold. Some courts might not understand this well enough to word their rulings correctly, as happens in many other technical matters, but that doesn't change reality. S -- Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3646 bytes Desc: S/MIME Cryptographic Signature URL: From owen at delong.com Tue May 10 15:46:25 2011 From: owen at delong.com (Owen DeLong) Date: Tue, 10 May 2011 12:46:25 -0700 Subject: [arin-ppml] Draft Proposal for Needs-Free IPv4 Transfers In-Reply-To: References: <323AD9AC0BE24F9BB91D3E712160681A@mike><77338713-58D2-47AA-9045-C5D19DBB8DA0@delong.com><8728DDCCEA5E476D8AC8E59368684F12@mike> <7A8B0D17-0AC3-4C60-B466-39C29708F826@arin.net> <3106C4E2-5883-4E80-BF72-D073535406FA@delong.com> <0871E647591749DBAC278D8D5FE31D2F@mike> <82A684B2-DAB9-4334-B99D-C9A55FEB2E74@delong.com> Message-ID: > >> If ARIN informs me that section 12 is inadequate for these purposes as currently written, I >> will propose policy to rectify that problem. > >> Owen > > What do you mean if ARIN informs you? You're ARIN. Read section 12 and tell me where the authority to do utilization based reviews are found. > The authority is in the RSA only, and an appeal to a best practices IETF document like RFC2050 for authority is weak, IMO. > By ARIN, I meant specifically ARIN staff. NRPM 12 requires organizations to remain in compliance with the criteria specified in sections 4 and 6 of the NRPM even after they have received their resources. At the time of request for additional resources is just one of the times that ARIN can conduct an NRPM 12 review of an organizations utilization. RSA paragraph 8 aids in this, but, NRPM 12 is sufficient on its own, even without RSA 8. NRPM 12 generally is not applied to legacy holders, however, in the case where a legacy holder is defunct and the addresses are reported to ARIN as being in use by a non-registered third party, I would argue that ARIN has a duty to act on the information and conduct an NRPM 12 review and potentially reclaim said resources, legacy or otherwise. That is not what happened in the Nortel/M$ case. ARIN became aware of the situation through a process that fit reasonably well into the NRPM 8.3 transfer policy and so long as the recipient was willing to comply with ARIN policies, the most logical thing to do in the interests of the community was to apply that policy. I agree there appear to be some rough edges in the handling of this particular issue and the process followed may not have been ideal. However, I haven't received full information yet and am waiting until I do to lodge any form of formal protest, policy proposal, or ACSP input to correct any issues. Owen From owen at delong.com Tue May 10 15:54:12 2011 From: owen at delong.com (Owen DeLong) Date: Tue, 10 May 2011 12:54:12 -0700 Subject: [arin-ppml] New IPv4 Transfer policy In-Reply-To: <4DC990A1.1040602@sprunk.org> References: <0F4E49B9-09DB-434F-AD5D-87DA3DCC42D8@matthew.at> <4DC86683.90204@ipinc.net> <4DC8D506.3010203@umn.edu> <4DC956B5.3030107@ipinc.net> <4DC97080.6070007@umn.edu> <4DC988C2.5060202@ipinc.net> <4DC990A1.1040602@sprunk.org> Message-ID: On May 10, 2011, at 12:23 PM, Stephen Sprunk wrote: > On 10-May-11 13:49, Ted Mittelstaedt wrote: >> On 5/10/2011 10:06 AM, David Farmer wrote: >>> My comment was directed at what I felt was your accusation that you >>> felt the LRSA was misrepresented and was only about the fees that a >>> legacy resource holder should pay. >> >> OK, but that still doesn't really answer my question of what about the >> LSRA is so much better than the RSA for a company like Microsoft, >> which probably spends more in it's annual budget for office birthday >> parties than it would on ARIN fees? >> >> In other words, if the fee difference isn't the issue, what is it? > > The only other obvious difference is that resources under LRSA cannot be > revoked. > Cannot be revoked for non-utilization. They can still be revoked for non-payment or virtually any other issue, identical to RSA. The LRSA provides a specific exemption from utilization criteria. > That's what dangerous about allowing LRSAs for NRPM 8.3 transfers: if > the justification is discovered to be bullshit after the fact, there is > nothing ARIN can do about it. > Agreed. >> The fee structure is, fundamentally, based on the notion that a >> commercial money-making LIR should pay more than something like a >> public university even though they may consume fewer IPv4 addresses. >> >> Thus it is very irritating when a commercial entity like Microsoft >> appears to get off scott free without making any kind of additional >> compensation to ARIN for enabling it to essentially make a ton more >> money than it's competitors. > > I don't see how you get that from the fee structure. Any org, public or > private, getting an assignment pays $100 per year, and any org, public > or private, getting an allocation pays a lot more. > > Supposedly, this is because allocations imply a lot more work for ARIN > processing sub-allocations and sub-assignments, whereas assignments > cannot be sub-allocated or sub-assigned. > Allocations also include membership which would cost an assignee $500/year. That narrows the gap between an assignment with membership ($600/year) and an X-Small ISP ($1250/year) to just barely over 2x the ($650/year). I believe ARIN does more than twice the work annually for an X-small ISP on average than for most end users, so, I think this is reasonable. I think the $500/year for membership is more than reasonable when you consider what it includes. As an end-user organization[1], however, I do not elect to join ARIN at that price, but, would do so if it were less than $200/year. However, my primary concerns with ARIN are the policy process which is fully open to me as an end-user. I am less concerned about voting in the ARIN elections. However, I am also currently entitled to do so as the DMR for two subscriber member organizations.[2] [1] End user Org ID's DELONG (RSA) and DELONG-Z (LRSA) [2] Day job -- Org ID HURC and a consulting client that I am not at liberty to name here. >> Do we really want an Internet with a few large LIRs and all the >> smaller ones gone out of business? Because that is what the ARIN fee >> structure encourages. > > That's a matter of the decreasing cost per IP for larger allocations. > It has nothing to do with how wildly divergent the allocation and > assignment fee schedules are. > Since there is no cost per IP, but, rather a cost per IP growth per year, sort of, I think the entire topic is rather specious in nature. Owen From jcurran at arin.net Tue May 10 17:49:25 2011 From: jcurran at arin.net (John Curran) Date: Tue, 10 May 2011 21:49:25 +0000 Subject: [arin-ppml] Draft Proposal for Needs-Free IPv4 Transfers In-Reply-To: References: <323AD9AC0BE24F9BB91D3E712160681A@mike> <77338713-58D2-47AA-9045-C5D19DBB8DA0@delong.com> <"BANLkTik8jUuimto500D45ngcoOp CXg4vPg"@mail.gmail.com> <8728DDCCEA5E476D8AC8E59368684F12@mike> <7A8B0D17-0AC3-4C60-B466-39C29708F826@arin.net> <3106C4E2-5883-4E80-BF72-D073535406FA@delong.com> <0871E647591749DBAC278D8D5FE31D2F@mike> <82A684B2-DAB9-4334-B99D-C9A55FEB2E74@delong.com> Message-ID: On May 10, 2011, at 12:13 PM, Mike Burns wrote: > The "skipping extra procedural step" sounds a lot like failing to issue the addresses back to ARIN for the designated transfer to MS, ... Mike - As noted before, ARIN routinely recognizes M&A mergers after the fact under the policies that were applicable the time of the merger. Prior to May 2010, this means that an organization that acquires substantially all of the the operations of another organization would result in the transfer of the resources per NRPM 8.2. We usually have to perform such updating of registration records when an organization that hasn't been maintaining records comes to ARIN for the first time. FYI, /John John Curran President and CEO ARIN From mike at nationwideinc.com Tue May 10 18:40:02 2011 From: mike at nationwideinc.com (Mike Burns) Date: Tue, 10 May 2011 18:40:02 -0400 Subject: [arin-ppml] Draft Proposal for Needs-Free IPv4 Transfers References: <323AD9AC0BE24F9BB91D3E712160681A@mike><77338713-58D2-47AA-9045-C5D19DBB8DA0@delong.com><"BANLkTik8jUuimto500D45ngcoOp CXg4vPg"@mail.gmail.com><8728DDCCEA5E476D8AC8E59368684F12@mike><7A8B0D17-0AC3-4C60-B466-39C29708F826@arin.net><3106C4E2-5883-4E80-BF72-D073535406FA@delong.com><0871E647591749DBAC278D8D5FE31D2F@mike><82A684B2-DAB9-43 34-B99D-C9A55FEB2E74@delong.com> Message-ID: >> The "skipping extra procedural step" sounds a lot like failing to issue >> the addresses back to ARIN for the designated transfer to MS, ... > As noted before, ARIN routinely recognizes M&A mergers after the fact under the >policies that were applicable the time of the merger. Prior to May 2010, this >means that an organization that acquires substantially all of the the operations >of another organization would result in the transfer of the resources per NRPM 8.2. >We usually have to perform such updating of registration records when an organization >that hasn't been maintaining records comes to ARIN for the first time. Hi John, I wasn't referring to the ex post facto 8.2 transfers, I was referring to 8.3 requirement to release the addresses to ARIN for subsequent transfer to the directed recipient. Which I thought you later said was a procedural issue or similar words. There was nothing in the court documents about the addresses being released to ARIN at any point in time. My underlying point is the evident struggle to cover seemingly otherwise legal transactions with ARIN policies. Just as it is better to reflect 8.2 transfers after-the-fact to comply with policy in order that whois retain accurate information, it would be better if the needs justification was dropped for transfers. Both these things increase the likelihood of valid whois information. In the Microsoft case the needs established by ARIN's needs analysis fortunately fit with the volume of addresses Microsoft had negotiated to purchase. In the future, this may not be the case, and this may cause the recipient to choose to forego registration of the transfer with ARIN. But just to be clear, if a company came to ARIN today with evidence of mergers and acquisitions which occurred prior to May, 2010, and that entity currently had no use for the addresses, would ARIN aprove the prior 8.2 transfers and allow the holder to sell the addresses? (Assuming there is evidence of transfer of network assets which used the addresses when the mergers occurred.) Would ARIN approve the prior 8.2 transfers and then do a resource review under the RSA? What if the addresses were legacy addresses, as they were in the MS/Nortel deal? These are the types of issues we will be facing and I thank you for the excellent information you provide. Regards, Mike From jcurran at arin.net Tue May 10 18:51:07 2011 From: jcurran at arin.net (John Curran) Date: Tue, 10 May 2011 22:51:07 +0000 Subject: [arin-ppml] Draft Proposal for Needs-Free IPv4 Transfers In-Reply-To: References: <323AD9AC0BE24F9BB91D3E712160681A@mike><77338713-58D2-47AA-9045-C5D19DBB8DA0@delong.com><"BANLkTik8jUuimto500D45ngcoOp CXg4vPg"@mail.gmail.com><8728DDCCEA5E476D8AC8E59368684F12@mike><7A8B0D17-0AC3-4C60-B466-39C29708F826@arin.net><3106C4E2-5883-4E80-BF72-D073535406FA@delong.com><0871E647591749DBAC278D8D5FE31D2F@mike><82A684B2-DAB9-43 34-B99D-C9A55FEB2E74@delong.com> Message-ID: <81A149FB-A4F3-4E7C-B40B-3F15D5958BDC@arin.net> On May 10, 2011, at 3:40 PM, Mike Burns wrote: >>> The "skipping extra procedural step" sounds a lot like failing to issue the addresses back to ARIN for the designated transfer to MS, ... > > > > As noted before, ARIN routinely recognizes M&A mergers after the fact under the > >policies that were applicable the time of the merger. Prior to May 2010, this > >means that an organization that acquires substantially all of the the operations > >of another organization would result in the transfer of the resources per NRPM 8.2. > >We usually have to perform such updating of registration records when an organization > >that hasn't been maintaining records comes to ARIN for the first time. > > Hi John, > > I wasn't referring to the ex post facto 8.2 transfers, I was referring to 8.3 requirement to release the addresses to ARIN for subsequent transfer to the directed recipient. My apologies - I thought the "skipping extra procedural step" was a reference that ARIN somehow uniquely processed this transfer with respect to the treatment of resources held by legal predecessors. We did not treat this any differently than done with any other organization coming to ARIN with evidence of past M&A transactions. > ... > But just to be clear, if a company came to ARIN today with evidence of mergers and acquisitions which occurred prior to May, 2010, and that entity currently had no use for the addresses, would ARIN aprove the prior 8.2 transfers and allow the holder to sell the addresses? > (Assuming there is evidence of transfer of network assets which used the addresses when the mergers occurred.) Yes. ARIN would treat the request in accordance the M&A transfer policy in effect at the time of the transaction. /John John Curran President and CEO ARIN From mike at nationwideinc.com Tue May 10 19:16:10 2011 From: mike at nationwideinc.com (Mike Burns) Date: Tue, 10 May 2011 19:16:10 -0400 Subject: [arin-ppml] Draft Proposal for Needs-Free IPv4 Transfers References: <323AD9AC0BE24F9BB91D3E712160681A@mike><77338713-58D2-47AA-9045-C5D19DBB8DA0@delong.com><8728DDCCEA5E476D8AC8E59368684F12@mike> <7A8B0D17-0AC3-4C60-B466-39C29708F826@arin.net> <3106C4E2-5883-4E80-BF72-D073535406FA@delong.com> <0871E647591749DBAC278D8D5FE31D2F@mike> <82A684B2-DAB9-4334-B99D-C9A55FEB2E74@delong.com> <14BB2305F98E4F33967922618689A198@mike> <703F0A62-BFC9-4147-94E1-9C7A33A2E48F@delong.com> Message-ID: <9E2D9BC685AB45E1AB4E32334F404D41@video> Hi Owen, replies in bold. Presumably you got the /18 under NRPM 4.2. Specifically, under 4.2. Efficient utilization is covered under 4.2.2.1.2 which state: Demonstrate efficient use of IP address space allocations by providing appropriate documentation, including assignment histories, showing their efficient use. ISPs must provide reassignment information on the entire previously allocated block(s) via SWIP or RWhois server for /29 or larger blocks. For blocks smaller than /29 and for internal space, ISPs should provide utilization data either via SWIP or RWhois server or by using the table format described in Section 4.2.3.7.5 The section you reference is entirely under the heading for section 4.2: 4.2. Allocations to ISPs (Requirements for Requesting Initial Address Space) It refers explicitly to the requirements for requesting initial space, not for some ongoing utilization requirement. As such, if you can no longer demonstrate efficient use of your IP address space allocations, you would no longer be in compliance with this section. Is there a policy which says that once allocated, addresses must continue to be used? Where is that policy? I believe ARIN would apply the same criteria as are required for justifying a request on an ongoing basis. That has always been my understanding from staff and there has been no indication that has changed. But where is that in the NRPM? Regards, Mike -------------- next part -------------- An HTML attachment was scrubbed... URL: From owen at delong.com Tue May 10 19:29:24 2011 From: owen at delong.com (Owen DeLong) Date: Tue, 10 May 2011 16:29:24 -0700 Subject: [arin-ppml] Draft Proposal for Needs-Free IPv4 Transfers In-Reply-To: References: <323AD9AC0BE24F9BB91D3E712160681A@mike><77338713-58D2-47AA-9045-C5D19DBB8DA0@delong.com><"BANLkTik8jUuimto500D45ngcoOp CXg4vPg"@mail.gmail.com><8728DDCCEA5E476D8AC8E59368684F12@mike><7A8B0D17-0AC3-4C60-B466-39C29708F826@arin.net><3106C4E2-5883-4E80-BF72-D073535406FA@delong.com><0871E647591749DBAC278D8D5FE31D2F@mike><82A684B2-DAB9-43 34-B99D-C9A55FEB2E74@delong.com> Message-ID: <6BFEAC5B-4161-432A-BE2F-9FBC47095F97@delong.com> On May 10, 2011, at 3:40 PM, Mike Burns wrote: >>> The "skipping extra procedural step" sounds a lot like failing to issue the addresses back to ARIN for the designated transfer to MS, ... > > > > As noted before, ARIN routinely recognizes M&A mergers after the fact under the > >policies that were applicable the time of the merger. Prior to May 2010, this > >means that an organization that acquires substantially all of the the operations > >of another organization would result in the transfer of the resources per NRPM 8.2. > >We usually have to perform such updating of registration records when an organization > >that hasn't been maintaining records comes to ARIN for the first time. > > Hi John, > > I wasn't referring to the ex post facto 8.2 transfers, I was referring to 8.3 requirement to release the addresses to ARIN for subsequent transfer to the directed recipient. > > Which I thought you later said was a procedural issue or similar words. > There was nothing in the court documents about the addresses being released to ARIN at any point in time. > > My underlying point is the evident struggle to cover seemingly otherwise legal transactions with ARIN policies. > > Just as it is better to reflect 8.2 transfers after-the-fact to comply with policy in order that whois retain accurate information, it would be better if the needs justification was dropped for transfers. Both these things increase the likelihood of valid whois information. > > In the Microsoft case the needs established by ARIN's needs analysis fortunately fit with the volume of addresses Microsoft had negotiated to purchase. > > In the future, this may not be the case, and this may cause the recipient to choose to forego registration of the transfer with ARIN. > At which point if the transferor is no longer using the addresses for their original purpose, they should be reclaimed by ARIN and reissued to other parties. Owen From owen at delong.com Tue May 10 19:33:06 2011 From: owen at delong.com (Owen DeLong) Date: Tue, 10 May 2011 16:33:06 -0700 Subject: [arin-ppml] Draft Proposal for Needs-Free IPv4 Transfers In-Reply-To: <9E2D9BC685AB45E1AB4E32334F404D41@video> References: <323AD9AC0BE24F9BB91D3E712160681A@mike><77338713-58D2-47AA-9045-C5D19DBB8DA0@delong.com><8728DDCCEA5E476D8AC8E59368684F12@mike> <7A8B0D17-0AC3-4C60-B466-39C29708F826@arin.net> <3106C4E2-5883-4E80-BF72-D073535406FA@delong.com> <0871E647591749DBAC278D8D5FE31D2F@mike> <82A684B2-DAB9-4334-B99D-C9A55FEB2E74@delong.com> <14BB2305F98E4F33967922618689A198@mike> <703F0A62-BFC9-4147-94E1-9C7A33A2E48F@delong.com> <9E2D9BC685AB45E1AB4E32334F404D41@video> Message-ID: On May 10, 2011, at 4:16 PM, Mike Burns wrote: > Hi Owen, replies in bold. > Presumably you got the /18 under NRPM 4.2. > > Specifically, under 4.2. Efficient utilization is covered under 4.2.2.1.2 which state: > > > Demonstrate efficient use of IP address space allocations by providing appropriate documentation, including assignment histories, showing their efficient use. ISPs must provide reassignment information on the entire previously allocated block(s) via SWIP or RWhois server for /29 or larger blocks. For blocks smaller than /29 and for internal space, ISPs should provide utilization data either via SWIP or RWhois server or by using the table format described in Section 4.2.3.7.5 > > > The section you reference is entirely under the heading for section 4.2: > 4.2. Allocations to ISPs (Requirements for Requesting Initial Address Space) > > It refers explicitly to the requirements for requesting initial space, not for some ongoing utilization requirement. > > > > > As such, if you can no longer demonstrate efficient use of your IP address space allocations, > you would no longer be in compliance with this section. > > >> Is there a policy which says that once allocated, addresses must continue to be used? >> Where is that policy? >> > I believe ARIN would apply the same criteria as are required for justifying a request on an ongoing > basis. That has always been my understanding from staff and there has been no indication that > has changed. > But where is that in the NRPM? > > Regards, > Mike > > > It may not be, but, I believe that is ARIN's interpretation. Hopefully John can clarify this one way or the other. If it isn't in the NRPM, I'm betting that adding it will come to consensus relatively easily. Owen -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcurran at arin.net Tue May 10 20:05:20 2011 From: jcurran at arin.net (John Curran) Date: Wed, 11 May 2011 00:05:20 +0000 Subject: [arin-ppml] Draft Proposal for Needs-Free IPv4 Transfers In-Reply-To: <9E2D9BC685AB45E1AB4E32334F404D41@video> References: <323AD9AC0BE24F9BB91D3E712160681A@mike> <77338713-58D2-47AA-9045-C5D19DBB8DA0@delong.com> <"BANLkTik8jUuimto500D45ngcoOp CXg4vPg"@mail.gmail.com> <8728DDCCEA5E476D8AC8E59368684F12@mike> <7A8B0D17-0AC3-4C60-B466-39C29708F826@arin.net> <3106C4E2-5883-4E80-BF72-D073535406FA@delong.com> <0871E647591749DBAC278D8D5FE31D2F@mike> <82A684B2-DAB9-4334-B99D-C9A55FEB2E74@delong.com> <14BB2305F98E4F33967922618689A198@mike> <703F0A62-BFC9-4147-94E1-9C7A33A2E48F@delong.com> <9E2D9BC685AB45E1AB4E32334F404D41@video> Message-ID: <4CF8B063-0CF2-4717-908A-91B916EEADCF@arin.net> On May 10, 2011, at 4:16 PM, Mike Burns wrote: >> Is there a policy which says that once allocated, addresses must continue to be used? > But where is that in the NRPM? Per NRPM 4.1.7 (Section "RFC 2050"): "ARIN takes guidance from allocation and assignment policies and procedures set forth in RFC 2050." RFC 2050 states: "IP addresses are valid as long as the criteria continues to be met." This would indicate that despite the criteria being provided in the context of a new allocation, the actual IP assignment or allocation remains "valid as long as the criteria continues to be met". (I believe I already answered this question earlier on the mailing list, but repeat it here in case it is useful in consideration of the policy proposal) Thanks! /John John Curran President and CEO ARIN From mysidia at gmail.com Tue May 10 21:01:30 2011 From: mysidia at gmail.com (Jimmy Hess) Date: Tue, 10 May 2011 20:01:30 -0500 Subject: [arin-ppml] ARIN-prop-148 LRSA resources must not be transferred to LRSA In-Reply-To: <4DC9771D.6010809@arin.net> References: <4DC9771D.6010809@arin.net> Message-ID: On Tue, May 10, 2011 at 12:34 PM, ARIN wrote: > the following sentence is added: > > The recipient of transferred number resources MUST sign the RSA with > ARIN if the resources being transferred are already under LRSA. > Resources under LRSA may not be transferred to a recieving organization > and placed under a new LRSA with that organization. ?They must be placed > under the RSA, not the LRSA. The current NRPM doesn't even mention the LRSA. So, it's probably not a great idea to refer to a document outside the NRPM. It is conceivable that ARIN staff could develop new RSAs in the future and call them something different, or revise the RSA to make it more like the LRSA. I suggest something more like: The recipient of transferred number resources must sign a standard Registration Services Agreement made public by ARIN, that ensures ARIN retains the right to charge fees and revoke resources as needed, to enforce number resource policies, or reclaim underutilized resources. Every recipient of transferred resources will sign a RSA that provides identical conditions as the RSA signed by ISP and End user recipients of allocations provided under 4.2 and 4.3. -- -JH From owen at delong.com Tue May 10 21:14:53 2011 From: owen at delong.com (Owen DeLong) Date: Tue, 10 May 2011 18:14:53 -0700 Subject: [arin-ppml] ARIN-prop-148 LRSA resources must not be transferred to LRSA In-Reply-To: References: <4DC9771D.6010809@arin.net> Message-ID: On May 10, 2011, at 6:01 PM, Jimmy Hess wrote: > On Tue, May 10, 2011 at 12:34 PM, ARIN wrote: >> the following sentence is added: >> >> The recipient of transferred number resources MUST sign the RSA with >> ARIN if the resources being transferred are already under LRSA. >> Resources under LRSA may not be transferred to a recieving organization >> and placed under a new LRSA with that organization. They must be placed >> under the RSA, not the LRSA. > > The current NRPM doesn't even mention the LRSA. > So, it's probably not a great idea to refer to a document outside the NRPM. > > It is conceivable that ARIN staff could develop new RSAs in the future > and call them > something different, or revise the RSA to make it more like the LRSA. > > I suggest something more like: > > The recipient of transferred number resources must sign a standard > Registration Services > Agreement made public by ARIN, that ensures ARIN retains the right to > charge fees > and revoke resources as needed, to enforce number resource policies, or reclaim > underutilized resources. > > Every recipient of transferred resources will sign a RSA that provides identical > conditions as the RSA signed by ISP and End user recipients of allocations > provided under 4.2 and 4.3. > Since by the time this is enacted, there may not be allocations or assignments under 4.2/4.3, may I suggest we refer, instead, to sections 4 and 6 of the NRPM in their entirety. Owen > > -- > -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 mike at nationwideinc.com Wed May 11 09:31:23 2011 From: mike at nationwideinc.com (Mike Burns) Date: Wed, 11 May 2011 09:31:23 -0400 Subject: [arin-ppml] Draft Proposal for Needs-Free IPv4 Transfers References: <323AD9AC0BE24F9BB91D3E712160681A@mike><77338713-58D2-47AA-9045-C5D19DBB8DA0@delong.com><"BANLkTik8jUuimto500D45ngcoOp CXg4vPg"@mail.gmail.com><8728DDCCEA5E476D8AC8E59368684F12@mike><7A8B0D17-0AC3-4C60-B466-39C29708F826@arin.net><3106C4E2-5883-4E80-BF72-D073535406FA@delong.com><0871E647591749DBAC278D8D5FE31D2F@mike><82A684B2-DAB9-43 34-B99D-C9A55FEB2E74@delong.com><14BB23 05F98E4F33967922618689A198@mike><703F0A62-BFC9-4147-94E1-9C7A33A2E48F@delong.com><9E2D9BC685AB45E1AB4E32334F404D41@video> <4CF8B063-0CF2-4717-908A-91B916EEADCF@arin.net> Message-ID: <4F2105BDB72D46DDB1279FD71EE94A8B@mike> >Per NRPM 4.1.7 (Section "RFC 2050"): >"ARIN takes guidance from allocation and assignment policies and procedures >set forth in RFC 2050." >RFC 2050 states: "IP addresses are valid as long as the criteria continues >to be met." >This would indicate that despite the criteria being provided in the >context of a new allocation, the actual IP assignment or allocation >remains "valid as long as the criteria continues to be met". >(I believe I already answered this question earlier on the mailing list, >but >repeat it here in case it is useful in consideration of the policy >proposal) >Thanks! >/John Hi John, So any violation of RFC2050 is a violation of ARIN policy and could allow a revokation under section12? Does the IETF write ARIN policy? The NRPM is pretty clear that if you don't pay your ARIN bill, addresses can be revoked. It can be that clear about revokation for failing to maintain the original allocation criteria, too. I'm with Owen, in that this looks like an oversight and should be corrected in the NRPM if that's what the community wants. Regards, Mike From tedm at ipinc.net Wed May 11 09:43:12 2011 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Wed, 11 May 2011 06:43:12 -0700 Subject: [arin-ppml] ARIN-prop-148 LRSA resources must not be transferred to LRSA In-Reply-To: References: <4DC9771D.6010809@arin.net> Message-ID: <4DCA9270.9040706@ipinc.net> On 5/10/2011 6:14 PM, Owen DeLong wrote: > > On May 10, 2011, at 6:01 PM, Jimmy Hess wrote: > >> On Tue, May 10, 2011 at 12:34 PM, ARIN wrote: >>> the following sentence is added: >>> >>> The recipient of transferred number resources MUST sign the RSA with >>> ARIN if the resources being transferred are already under LRSA. >>> Resources under LRSA may not be transferred to a recieving organization >>> and placed under a new LRSA with that organization. They must be placed >>> under the RSA, not the LRSA. >> >> The current NRPM doesn't even mention the LRSA. >> So, it's probably not a great idea to refer to a document outside the NRPM. >> >> It is conceivable that ARIN staff could develop new RSAs in the future >> and call them >> something different, or revise the RSA to make it more like the LRSA. >> >> I suggest something more like: >> >> The recipient of transferred number resources must sign a standard >> Registration Services >> Agreement made public by ARIN, that ensures ARIN retains the right to >> charge fees >> and revoke resources as needed, to enforce number resource policies, or reclaim >> underutilized resources. >> >> Every recipient of transferred resources will sign a RSA that provides identical >> conditions as the RSA signed by ISP and End user recipients of allocations >> provided under 4.2 and 4.3. >> > Since by the time this is enacted, there may not be allocations or assignments > under 4.2/4.3, may I suggest we refer, instead, to sections 4 and 6 of the > NRPM in their entirety. > Both excellent points! So by your responses, I take it that both of you are in favor of the general idea that resources under LRSA, when transferred, should be moved into the regular RSA in every practicable instance? In short, the LRSA is intended as a single-use device, for the purposes of getting true Legacy resources not under any RSA at all, under some kind of RSA, and it is not intended for LRSA holders to be able to transfer the LRSA to a recipient? (and so on and so on, and forever as long as IPv4 shall live?) Ted > Owen > >> >> -- >> -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 jcurran at arin.net Wed May 11 09:49:10 2011 From: jcurran at arin.net (John Curran) Date: Wed, 11 May 2011 13:49:10 +0000 Subject: [arin-ppml] Draft Proposal for Needs-Free IPv4 Transfers In-Reply-To: <4F2105BDB72D46DDB1279FD71EE94A8B@mike> References: <323AD9AC0BE24F9BB91D3E712160681A@mike><77338713-58D2-47AA-9045-C5D19DBB8DA0@delong.com><"BANLkTik8jUuimto500D45ngcoOp CXg4vPg"@mail.gmail.com><8728DDCCEA5E476D8AC8E59368684F12@mike><7A8B0D17-0AC3-4C60-B466-39C29708F826@arin.net><3106C4E2-5883-4E80-BF72-D073535406FA@delong.com><0871E647591749DBAC278D8D5FE31D2F@mike><82A684B2-DAB9-43 34-B99D-C9A55FEB2E74@delong.com><14BB23 05F98E4F33967922618689A198@mike><703F0A62-BFC9-4147-94E1-9C7A33A2E48F@delong.com><9E2D9BC685AB45E1AB4E32334F404D41@video> <4CF8B063-0CF2-4717-908A-91B916EEADCF@arin.net> <4F2105BDB72D46DDB1279FD71EE94A8B@mike> Message-ID: On May 11, 2011, at 6:31 AM, Mike Burns wrote: >> RFC 2050 states: "IP addresses are valid as long as the criteria continues to be met." > > I'm with Owen, in that this looks like an oversight and should be corrected in the NRPM if that's what the community wants. Agreed - the community should definitely make their intention known on whether ARIN should consider the utilization of resources after assignment or allocation. We obviously have to consider such when processing a request for additional resources, but should it matter otherwise? Thanks, /John John Curran President and CEO ARIN From mike at nationwideinc.com Wed May 11 09:54:35 2011 From: mike at nationwideinc.com (Mike Burns) Date: Wed, 11 May 2011 09:54:35 -0400 Subject: [arin-ppml] Draft Proposal for Needs-Free IPv4 Transfers References: <323AD9AC0BE24F9BB91D3E712160681A@mike><77338713-58D2-47AA-9045-C5D19DBB8DA0@delong.com><"BANLkTik8jUuimto500D45ngcoO pCXg4vPg"@mail.gmail.com><8728DDCCEA5E476D8AC8E59368684F12@mike><7A8B0D17-0AC3-4C60-B466-39C29708F826@arin.net><3106C4E2-5883-4E80-BF72-D073535406FA@delong.com><0871E647591749DBAC278D8D5FE31D2F@mike><82A684B2-DAB9-4 334-B99D-C9A55FEB2E74@delong.com><14BB2 305F98E4F33967922618689A198@mike><703F0A62-BFC9-4147-94E1-9C7A33A2E48F@delong.com><9E2D9BC685AB45E1AB4E32334F404D41@video><4CF8 B063-0CF2-4717-908A-91B916EEADCF@arin.net><4F2105BDB72D46DDB1279FD71EE94A8B@mike> Message-ID: <876C443127384A6E8FAF0E0E2F50773E@mike> Agreed - the community should definitely make their intention known on whether ARIN should consider the utilization of resources after assignment or allocation. We obviously have to consider such when processing a request for additional resources, but should it matter otherwise? Thanks, /John I support leaving it as is! No review for utilization after allocation! ;-) -Mike From kkargel at polartel.com Wed May 11 12:25:38 2011 From: kkargel at polartel.com (Kevin Kargel) Date: Wed, 11 May 2011 11:25:38 -0500 Subject: [arin-ppml] Draft Proposal for Needs-Free IPv4 Transfers In-Reply-To: <4DC8B67D.80208@ipinc.net> References: <323AD9AC0BE24F9BB91D3E712160681A@mike> <4DC84FC0.6070708@ipinc.net> <4DC8B67D.80208@ipinc.net> Message-ID: <8695009A81378E48879980039EEDAD289D0E5BF2@MAIL1.polartel.local> > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf Of Ted Mittelstaedt > Sent: Monday, May 09, 2011 10:52 PM > To: Matthew Kaufman > Cc: arin-ppml at arin.net > Subject: Re: [arin-ppml] Draft Proposal for Needs-Free IPv4 Transfers > > > > > except this is a situation where in effect the 10 acre corner is the > ONLY access to your 100 acre plot (it's the only section of your land > that is next to a road and the county won't issue you a permit for > a driveway for anywhere except within that 10 acres) > Except that if you are *using* the 10 acres for access to your other 90 acres then adverse possession doesn't apply. Kevin From millnert at gmail.com Wed May 11 12:39:10 2011 From: millnert at gmail.com (Martin Millnert) Date: Wed, 11 May 2011 12:39:10 -0400 Subject: [arin-ppml] ARIN-prop-148 LRSA resources must not be transferred to LRSA In-Reply-To: References: <4DC9771D.6010809@arin.net> Message-ID: Jimmy, On Tue, May 10, 2011 at 9:01 PM, Jimmy Hess wrote: > I suggest ?something more like: > > The recipient of transferred number resources must sign a standard > Registration Services > Agreement made public by ARIN, ?that ensures ARIN retains the right to > charge fees > and revoke resources as needed, to enforce number resource policies, or reclaim > underutilized resources. I'm admittedly not very experienced in ARIN procedures, so if you would please help me out here: How does this motivate sellers of legacy space to involve ARIN in their transactions? My understanding of the term "legacy space" is that it was assigned to users prior to ARIN's (or others) existence, and that you can't assume there is contracts in place where the legacy space holder in effect converts their space to ARIN managed space (which in practical terms means the space isn't "legacy space" per my definition). I'd happily be educated in ARIN terms/procedures on these matters. Thanks, Martin From kkargel at polartel.com Wed May 11 12:46:39 2011 From: kkargel at polartel.com (Kevin Kargel) Date: Wed, 11 May 2011 11:46:39 -0500 Subject: [arin-ppml] transfer conditions In-Reply-To: References: <75E9BD24-F12F-42BF-A989-CF6CC282B28E@arin.net> <8740380157159276993@unknownmsgid> <49E26DCB-DAF7-4A0A-912E-F981494979F5@delong.com> <4DBC2AEB.9040307@matthew.at> <4DBCA58D.4060704@sprunk.org> <2344ADD7-616E-4FA7-9552-19735926A952@delong.com> <391BFA8C-9D09-4BB2-8D49-FD5F9C6FDF93@arin.net> <6B951089-C686-4929-AC21-A1BF91BBBCB7@delong.com> <22A6B158-1CBC-4C35-A842-0BD029B2461C@arin.net> <9CDB0040-AFFD-4A90-94D9-821003EE5B8F@matthew.at> <1E077822-6D5F-459F-B312-1DD8F7447B40@matthew.at> <1B32A1B5-0FFC-4C58-93F3-9C984E42F5AB@matthew.at> Message-ID: <8695009A81378E48879980039EEDAD289D0E5BF4@MAIL1.polartel.local> > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf Of Jimmy Hess > Sent: Tuesday, May 10, 2011 12:11 AM > To: Matthew Kaufman > Cc: arin-ppml at arin.net > Subject: Re: [arin-ppml] transfer conditions > > On Mon, May 9, 2011 at 11:50 PM, Matthew Kaufman > wrote: > > On May 9, 2011, at 9:36 PM, Jimmy Hess wrote: > >> On Mon, May 9, 2011 at 8:09 PM, Matthew Kaufman > wrote: > > > Note that even the "normal RSA" gets modified for certain entities, and > the LRSA is also often "customized" > > > In what way does the RSA get "modified" for certain entities? > Do we have examples? > > I would suggest at least the requirement that the RSA used > match a RSA published in the "Agreements" section of ARIN's website. > > Some organizations getting private RSAs of their choosing would be > inconsistent > with ARIN treating all organizations that receive service impartially. > > 'Special' organizations should not have have rights, waiver of > community developed > policies, or other privileges granted to them by ARIN, not afforded to > others, > just because they are X, and "X is special". > > -- > -JH I would tend to argue the other side of this coin. It is impossible to write a boilerplate contract for anything that will cover all situations and circumstances. Most contracts will have caveats and addenda to fine tune the contract to best serve the interests of the parties involved. NDA's that are more restrictive than standard might be one example. I suspect that if we wrote an RSA with enough clauses to cover all possible circumstances it would require a rather large hard drive to house it and would take a team of logic PHD's to understand it. I completely believe that ARIN staff works for the best interest of the community and with all due diligence. I fully support ARIN staff having the authority to modify an RSA to fit special circumstances. Kevin From kkargel at polartel.com Wed May 11 13:03:02 2011 From: kkargel at polartel.com (Kevin Kargel) Date: Wed, 11 May 2011 12:03:02 -0500 Subject: [arin-ppml] ARIN-PPML Digest, Vol 71, Issue 104 In-Reply-To: References: Message-ID: <8695009A81378E48879980039EEDAD289D0E5BF5@MAIL1.polartel.local> ________________________________________ From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Rudolph Daniel Sent: Tuesday, May 10, 2011 1:13 AM To: arin-ppml at arin.net Subject: Re: [arin-ppml] ARIN-PPML Digest, Vol 71, Issue 104 >My opinion is: Legacy holders can keep what they have until doomsday, and >where ?these holders decide to transfer in any way method shape or form, >they are subject to RSA. I feel that it does not seem fair on the part of >the rest of the community that legacy holders legitimize (not sure that's >the correct word) their holding with the use of a special instrument (LRSA) >and at the same time retain the ability to profit from that which is >technically not property/....I suspect they were given these resources in >the spirit of R&D at the time. > >rd I have to agree with JD on this. I am a huge proponent of 'Legacy' holders being able to continue their use of their IP4 space ad infinitum by virtue of their past contribution to the community, but at the point or moment that they release or transfer any netblocks to another (legacy or non-legacy) party then all deals are off and the subject netblocks *should* become common. I do not hold the 'rights' of 'Legacy' holders to include sale of and/or profit from the netblocks. I have said this in as plain a manner as I can on purpose. Of course I understand that my understandings are my opinion only and may have little bearing on reality. Kevin From owen at delong.com Wed May 11 13:13:00 2011 From: owen at delong.com (Owen DeLong) Date: Wed, 11 May 2011 10:13:00 -0700 Subject: [arin-ppml] ARIN-prop-148 LRSA resources must not be transferred to LRSA In-Reply-To: <4DCA9270.9040706@ipinc.net> References: <4DC9771D.6010809@arin.net> <4DCA9270.9040706@ipinc.net> Message-ID: On May 11, 2011, at 6:43 AM, Ted Mittelstaedt wrote: > On 5/10/2011 6:14 PM, Owen DeLong wrote: >> >> On May 10, 2011, at 6:01 PM, Jimmy Hess wrote: >> >>> On Tue, May 10, 2011 at 12:34 PM, ARIN wrote: >>>> the following sentence is added: >>>> >>>> The recipient of transferred number resources MUST sign the RSA with >>>> ARIN if the resources being transferred are already under LRSA. >>>> Resources under LRSA may not be transferred to a recieving organization >>>> and placed under a new LRSA with that organization. They must be placed >>>> under the RSA, not the LRSA. >>> >>> The current NRPM doesn't even mention the LRSA. >>> So, it's probably not a great idea to refer to a document outside the NRPM. >>> >>> It is conceivable that ARIN staff could develop new RSAs in the future >>> and call them >>> something different, or revise the RSA to make it more like the LRSA. >>> >>> I suggest something more like: >>> >>> The recipient of transferred number resources must sign a standard >>> Registration Services >>> Agreement made public by ARIN, that ensures ARIN retains the right to >>> charge fees >>> and revoke resources as needed, to enforce number resource policies, or reclaim >>> underutilized resources. >>> >>> Every recipient of transferred resources will sign a RSA that provides identical >>> conditions as the RSA signed by ISP and End user recipients of allocations >>> provided under 4.2 and 4.3. >>> >> Since by the time this is enacted, there may not be allocations or assignments >> under 4.2/4.3, may I suggest we refer, instead, to sections 4 and 6 of the >> NRPM in their entirety. >> > > Both excellent points! > > So by your responses, I take it that both of you are in favor of > the general idea that resources under LRSA, when transferred, should > be moved into the regular RSA in every practicable instance? > Absolutely. This was the clear intent of the community in the phrasing of 2009-1, the rationale, and both the community and AC discussions. The fact that it is possible to do otherwise came as a surprise. > In short, the LRSA is intended as a single-use device, for the purposes > of getting true Legacy resources not under any RSA at all, under some > kind of RSA, and it is not intended for LRSA holders to be able to > transfer the LRSA to a recipient? (and so on and so on, and forever as > long as IPv4 shall live?) > Exactly. Owen > From owen at delong.com Wed May 11 13:13:59 2011 From: owen at delong.com (Owen DeLong) Date: Wed, 11 May 2011 10:13:59 -0700 Subject: [arin-ppml] Draft Proposal for Needs-Free IPv4 Transfers In-Reply-To: References: <323AD9AC0BE24F9BB91D3E712160681A@mike><77338713-58D2-47AA-9045-C5D19DBB8DA0@delong.com><"BANLkTik8jUuimto500D45ngcoOp CXg4vPg"@mail.gmail.com><8728DDCCEA5E476D8AC8E59368684F12@mike><7A8B0D17-0AC3-4C60-B466-39C29708F826@arin.net><3106C4E2-5883-4E80-BF72-D073535406FA@delong.com><0871E647591749DBAC278D8D5FE31D2F@mike><82A684B2-DAB9-43 34-B99D-C9A55FEB2E74@delong.com><14BB23 05F98E4F33967922618689A198@mike><703F0A62-BFC9-4147-94E1-9C7A33A2E48F@delong.com><9E2D9BC685AB45E1AB4E32334F404D41@video> <4CF8B063-0CF2-4717-908A-91B916EEADCF@arin.net> <4F2105BDB72D46DDB1279FD71EE94A8B@mike> Message-ID: On May 11, 2011, at 6:49 AM, John Curran wrote: > On May 11, 2011, at 6:31 AM, Mike Burns wrote: >>> RFC 2050 states: "IP addresses are valid as long as the criteria continues to be met." >> >> I'm with Owen, in that this looks like an oversight and should be corrected in the NRPM if that's what the community wants. > > Agreed - the community should definitely make their intention known > on whether ARIN should consider the utilization of resources after > assignment or allocation. We obviously have to consider such when > processing a request for additional resources, but should it matter > otherwise? > I believe that in the discussions and the authorship of section 12, that was the clear intent of the community. Section 12 is a no-op otherwise. Owen From stephen at sprunk.org Wed May 11 13:16:50 2011 From: stephen at sprunk.org (Stephen Sprunk) Date: Wed, 11 May 2011 12:16:50 -0500 Subject: [arin-ppml] ARIN-prop-148 LRSA resources must not be transferred to LRSA In-Reply-To: References: <4DC9771D.6010809@arin.net> Message-ID: <4DCAC482.1080302@sprunk.org> On 11-May-11 11:39, Martin Millnert wrote: > On Tue, May 10, 2011 at 9:01 PM, Jimmy Hess wrote: >> I suggest something more like: >> >> The recipient of transferred number resources must sign a standard >> Registration Services Agreement made public by ARIN, that ensures ARIN retains the right to charge fees and revoke resources as needed, to enforce number resource policies, or reclaim underutilized resources. > I'm admittedly not very experienced in ARIN procedures, so if you would please help me out here: > How does this motivate sellers of legacy space to involve ARIN in their transactions? A transferee is very interested in involving ARIN because they want to make sure the registration database will get updated; if ARIN refuses to record the transfer because it doesn't comply with policy, there is no reason to pay because they have received nothing of value. Therefore, a transferor must involve ARIN because they need to validate that the transfer will be recorded before they can get their money. Remember, numbers are not property and cannot be sold; what is being "sold" is a slot in ARIN's database. If you don't care about ARIN's database, just use whatever numbers you want without paying anyone! > My understanding of the term "legacy space" is that it was assigned to users prior to ARIN's (or others) existence, and that you can't assume there is contracts in place where the legacy space holder in effect converts their space to ARIN managed space (which in practical terms means the space isn't "legacy space" per my definition). All resources issued prior to ARIN's formation are legacy, regardless of whether they are currently covered by an (L)RSA. However, that's a moot point because the policy doesn't really affect to the transferor; it only applies to the transferee, who will be forced to sign some sort of contract for services rendered. Note that, while there is no legacy IPv6, there /are/ legacy ASNs, not just IPv4 space; that's why we use the generic term "resources". (I'm not aware of anyone wanting to "buy" a legacy ASN, but in theory it could happen.) S -- Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3646 bytes Desc: S/MIME Cryptographic Signature URL: From bill at herrin.us Wed May 11 13:29:28 2011 From: bill at herrin.us (William Herrin) Date: Wed, 11 May 2011 13:29:28 -0400 Subject: [arin-ppml] ARIN-prop-148 LRSA resources must not be transferred to LRSA In-Reply-To: References: <4DC9771D.6010809@arin.net> Message-ID: On Tue, May 10, 2011 at 9:01 PM, Jimmy Hess wrote: > On Tue, May 10, 2011 at 12:34 PM, ARIN wrote: >> The recipient of transferred number resources MUST sign the RSA with >> ARIN if the resources being transferred are already under LRSA. >> Resources under LRSA may not be transferred to a recieving organization >> and placed under a new LRSA with that organization. ?They must be placed >> under the RSA, not the LRSA. > > I suggest ?something more like: > > The recipient of transferred number resources must sign a standard > Registration Services > Agreement made public by ARIN, ?that ensures ARIN retains the right to > charge fees > and revoke resources as needed, to enforce number resource policies, or reclaim > underutilized resources. How about: 8.3.1 The recipient of transferred number resources shall, as a condition of registration, consent to and sign the same registration services agreement they would sign as a registrant of new number resources from the free pool. This allows for John Curran's case where the RSA sees minor changes to accommodate government entities and the like. -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 Wed May 11 13:31:35 2011 From: jcurran at arin.net (John Curran) Date: Wed, 11 May 2011 17:31:35 +0000 Subject: [arin-ppml] Draft Proposal for Needs-Free IPv4 Transfers In-Reply-To: References: <323AD9AC0BE24F9BB91D3E712160681A@mike><77338713-58D2-47AA-9045-C5D19DBB8DA0@delong.com><"BANLkTik8jUuimto500D45ngcoOp CXg4vPg"@mail.gmail.com><8728DDCCEA5E476D8AC8E59368684F12@mike><7A8B0D17-0AC3-4C60-B466-39C29708F826@arin.net><3106C4E2-5883-4E80-BF72-D073535406FA@delong.com><0871E647591749DBAC278D8D5FE31D2F@mike><82A684B2-DAB9-43 34-B99D-C9A55FEB2E74@delong.com><14BB23 05F98E4F33967922618689A198@mike><703F0A62-BFC9-4147-94E1-9C7A33A2E48F@delong.com><9E2D9BC685AB45E1AB4E32334F404D41@video> <4CF8B063-0CF2-4717-908A-91B916EEADCF@arin.net> <4F2105BDB72D46DDB1279FD71EE94A8B@mike> Message-ID: On May 11, 2011, at 10:13 AM, Owen DeLong wrote: > On May 11, 2011, at 6:49 AM, John Curran wrote: >> Agreed - the community should definitely make their intention known >> on whether ARIN should consider the utilization of resources after >> assignment or allocation. We obviously have to consider such when >> processing a request for additional resources, but should it matter >> otherwise? >> > I believe that in the discussions and the authorship of section 12, that > was the clear intent of the community. Section 12 is a no-op otherwise. That would be correct (i.e. a decision to cease considering utilization would preempt section 12 for most purposes, aside from fraud-related use) I do not know if this would be good, or bad, but if the community's views have changed at this point, then policy clarity as to how/when/if ARIN should consider utilization would be very helpful. At present, actual practice on resource reviews has focused predominately on requests for new resources and fraud, but today there is certainly the capability to perform reviews of the utilization for any resource. FYI, /John John Curran President and CEO ARIN From kkargel at polartel.com Wed May 11 13:40:02 2011 From: kkargel at polartel.com (Kevin Kargel) Date: Wed, 11 May 2011 12:40:02 -0500 Subject: [arin-ppml] ARIN-prop-148 LRSA resources must not be transferred to LRSA In-Reply-To: References: <4DC9771D.6010809@arin.net> <4DCA9270.9040706@ipinc.net> Message-ID: <8695009A81378E48879980039EEDAD289D0E5BF6@MAIL1.polartel.local> > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf Of Owen DeLong > Sent: Wednesday, May 11, 2011 12:13 PM > To: Ted Mittelstaedt > Cc: arin-ppml at arin.net > Subject: Re: [arin-ppml] ARIN-prop-148 LRSA resources must not be > transferred to LRSA > > > On May 11, 2011, at 6:43 AM, Ted Mittelstaedt wrote: > > > On 5/10/2011 6:14 PM, Owen DeLong wrote: > >> > >> On May 10, 2011, at 6:01 PM, Jimmy Hess wrote: > >> > >>> On Tue, May 10, 2011 at 12:34 PM, ARIN wrote: > >>>> the following sentence is added: > >>>> > >>>> The recipient of transferred number resources MUST sign the RSA with > >>>> ARIN if the resources being transferred are already under LRSA. > >>>> Resources under LRSA may not be transferred to a recieving > organization > >>>> and placed under a new LRSA with that organization. They must be > placed > >>>> under the RSA, not the LRSA. > >>> > >>> The current NRPM doesn't even mention the LRSA. > >>> So, it's probably not a great idea to refer to a document outside the > NRPM. > >>> > >>> It is conceivable that ARIN staff could develop new RSAs in the future > >>> and call them > >>> something different, or revise the RSA to make it more like the LRSA. > >>> > >>> I suggest something more like: > >>> > >>> The recipient of transferred number resources must sign a standard > >>> Registration Services > >>> Agreement made public by ARIN, that ensures ARIN retains the right to > >>> charge fees > >>> and revoke resources as needed, to enforce number resource policies, > or reclaim > >>> underutilized resources. > >>> > >>> Every recipient of transferred resources will sign a RSA that provides > identical > >>> conditions as the RSA signed by ISP and End user recipients of > allocations > >>> provided under 4.2 and 4.3. > >>> > >> Since by the time this is enacted, there may not be allocations or > assignments > >> under 4.2/4.3, may I suggest we refer, instead, to sections 4 and 6 of > the > >> NRPM in their entirety. > >> > > > > Both excellent points! > > > > So by your responses, I take it that both of you are in favor of > > the general idea that resources under LRSA, when transferred, should > > be moved into the regular RSA in every practicable instance? > > > Absolutely. This was the clear intent of the community in the phrasing > of 2009-1, the rationale, and both the community and AC discussions. > The fact that it is possible to do otherwise came as a surprise. I will agree and try to clarify by stating that "Legacy" 'rights' apply to the 'Legacy' organization, not the number resource and are non-transferrable. To my way of thinking when a numbered resource leaves the original 'Legacy' holders dominion it no longer carries any aegis granted to it by the 'Legacy' holders status. At that moment the resource becomes common. > > > In short, the LRSA is intended as a single-use device, for the purposes > > of getting true Legacy resources not under any RSA at all, under some > > kind of RSA, and it is not intended for LRSA holders to be able to > > transfer the LRSA to a recipient? (and so on and so on, and forever as > > long as IPv4 shall live?) > > > Exactly. > > Owen > > > From owen at delong.com Wed May 11 13:52:31 2011 From: owen at delong.com (Owen DeLong) Date: Wed, 11 May 2011 10:52:31 -0700 Subject: [arin-ppml] ARIN-prop-148 LRSA resources must not be transferred to LRSA In-Reply-To: References: <4DC9771D.6010809@arin.net> Message-ID: On May 11, 2011, at 9:39 AM, Martin Millnert wrote: > Jimmy, > > On Tue, May 10, 2011 at 9:01 PM, Jimmy Hess wrote: >> I suggest something more like: >> >> The recipient of transferred number resources must sign a standard >> Registration Services >> Agreement made public by ARIN, that ensures ARIN retains the right to >> charge fees >> and revoke resources as needed, to enforce number resource policies, or reclaim >> underutilized resources. > > I'm admittedly not very experienced in ARIN procedures, so if you > would please help me out here: > How does this motivate sellers of legacy space to involve ARIN in > their transactions? > It doesn't really affect the sellers. This is a requirement incumbent on the recipients of the space, not the providers (sellers). > My understanding of the term "legacy space" is that it was assigned to > users prior to ARIN's (or others) existence, and that you can't assume > there is contracts in place where the legacy space holder in effect > converts their space to ARIN managed space (which in practical terms > means the space isn't "legacy space" per my definition). > Whether the space is legacy or not, it is ARIN managed. Legacy space was issued prior to ARIN's existence, but, even then, it was issued to a particular party for a particular purpose with the expectation that it should be returned when that purpose was no longer valid. The key difference is that utilization density requirements have changed over time and so long as legacy space remains with its original recipient (or their successors in interest), it is subject to the terms under which it was issued, just as space issued under older forms of the RSA remains subject to those terms. Legacy space is not inherently transferable, and even an 8.3 transfer requires that the space first be returned to ARIN and then be reissued as agreed between the original holder and the designated recipient. Since the designated recipient would be receiving a new allocation/assignment from ARIN, it should be subject to the standard RSA. There is no such thing, really, as "legacy space". What there is are legacy resource holders and the space they hold is treated under legacy terms so long as they hold it. Owen From mike at nationwideinc.com Wed May 11 14:03:02 2011 From: mike at nationwideinc.com (Mike Burns) Date: Wed, 11 May 2011 14:03:02 -0400 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate Message-ID: <7F5FC4554E42430FADDC0D376164DFA0@mike> 1. Policy Proposal Name: IPv4 Transfer Policy Change to Keep Whois Accurate 2. Proposal Originator: a. Name: Mike Burns b. Email: mike at sum.net c. Phone: 1-863-494-7692 x105 d. Organization: Nationwide Computer Systems 3. Proposal Version: 1 4. Date: May 11th, 2011 5. Proposal type: modify 6. Policy term: permanent 7. Policy statement: Replace Section 8.3 with 8.3 ARIN will process and record IPv4 address transfer requests. Conditions on the IPv4 address block: - The minimum transfer size is a /24 - The address block must be in the range of addresses administered by ARIN Conditions on source of the transfer: - The source entity must be the current rights 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 the transfer, or until the exhaustion of ARIN's IPv4 space, whichever occurs first. - The source entity must not have received an allocation from ARIN for the 12 months prior to the transfer. Conditions on recipient of the transfer: - The recipient entity must be a current ARIN account holder. - The recipient must sign an RSA with ARIN. - The recipient entity of the transferred resources will be subject to current ARIN policies. In particular, in any subsequent ARIN IPv4 address allocation request, the recipient will be required to account for the efficient utilization of all IPv4 address space held, including all transferred resources. and request the AC to modify section 8 of the current RSA to remove references to "intended purposes." Replace ARIN may review, at any time, Applicant's use of previously allocated or assigned number resources or Services received from ARIN to determine if Applicant is complying with this Agreement and the Policies and is using the Services for their intended purposes. Without limiting the foregoing, if Applicant is a holder of a direct allocation or assignment from ARIN, Applicant agrees that it will use the number resources solely for uses consistent with its application and this Agreement, including, for example, its internal infrastructure or to provide Internet access to its customer base. If ARIN determines that the number resources or any other Services are not being used in compliance with this Agreement, the Policies, or the purposes for which they are intended, ARIN may: (i) revoke the number resources; (ii) cease providing the Services to Applicant; and/or (iii) terminate this Agreement. with ARIN may review, at any time, any Applicant's use of previously allocated or assigned number resources or Services received from ARIN to determine if Applicant is complying with this Agreement and the Policies. Without limiting the foregoing, if Applicant is a holder of a direct allocation or direct assignment from ARIN, Applicant agrees that it will use the number resources solely for uses consistent with this Agreement, including, for example, its internal infrastructure or to provide Internet access to its customer base. If ARIN determines that the number resources or any other Services are not being used in compliance with this Agreement or the Policies, ARIN may: (i) revoke the number resources; (ii) cease providing the Services to Applicant; and/or (iii) terminate this Agreement. and add to the NRPM Section 12: 10. ARIN will not use utilization as a measure of policy compliance for addresses transferred under 8.3. 8. Rationale: Current ARIN policies relating to the registration of transfer of address holdings limit the eligibility of registration of transfers to those relating to mergers and acquisitions of entities that are administering an operational network, or to those who agree to sign either an RSA or LRSA with ARIN and subject the buyer to needs analysis and the seller to a potential ARIN review under RSA section 8. It is currently anticipated that the IPv4 unallocated address pool will be exhausted within a couple of years at ARIN, and earlier than that in other regions, and the transition to IPv6-based service delivery is likely to take longer than the remaining period of unallocated address availability. Accordingly, it is likely that demand for IPv4 addresses will continue beyond the time of unallocated address pool exhaustion, leading to a period of movement of IPv4 address blocks between address holders to meet such continuing demand for IPv4 address blocks. The underlying proposition behind this policy proposal is that the registry of IPv4 addresses operated by ARIN is of general utility and value only while it accurately describes the current state of address distribution. If a class of address movement transactions are excluded from being entered in the registry, then the registry will have decreasing value to the broader community, and the integrity of the network itself is thereby compromised. This proposal's central aim is to ensure the continuing utility and value of the ARIN address registry by allowing the registry to record transactions where IPv4 addresses are transfered between ARIN account holders. It proposes that ARIN will recognise and register a transfer of addresses where the parties to the transfer are 'known' to ARIN and that the address block being transferred is part of ARIN's current address set. The proposal does not prescribe how such transfers may occur, nor impose any further constraints on the transfer or on the parties involved other than those described in this proposal. 9. Timetable for implementation: immediate. -------------- next part -------------- An HTML attachment was scrubbed... URL: From owen at delong.com Wed May 11 14:05:19 2011 From: owen at delong.com (Owen DeLong) Date: Wed, 11 May 2011 11:05:19 -0700 Subject: [arin-ppml] ARIN-prop-148 LRSA resources must not be transferred to LRSA In-Reply-To: <8695009A81378E48879980039EEDAD289D0E5BF6@MAIL1.polartel.local> References: <4DC9771D.6010809@arin.net> <4DCA9270.9040706@ipinc.net> <8695009A81378E48879980039EEDAD289D0E5BF6@MAIL1.polartel.local> Message-ID: <0486F032-43E7-4E4E-B029-AE0C3519C38F@delong.com> >>> >> Absolutely. This was the clear intent of the community in the phrasing >> of 2009-1, the rationale, and both the community and AC discussions. >> The fact that it is possible to do otherwise came as a surprise. > > I will agree and try to clarify by stating that "Legacy" 'rights' apply to the 'Legacy' organization, not the number resource and are non-transferrable. To my way of thinking when a numbered resource leaves the original 'Legacy' holders dominion it no longer carries any aegis granted to it by the 'Legacy' holders status. At that moment the resource becomes common. > Slight refinement... "Legacy" status applies to the intersection of the "Legacy" organization and the resources issued to them by one of ARIN's predecessor registries. Owen From owen at delong.com Wed May 11 14:01:18 2011 From: owen at delong.com (Owen DeLong) Date: Wed, 11 May 2011 11:01:18 -0700 Subject: [arin-ppml] ARIN-prop-148 LRSA resources must not be transferred to LRSA In-Reply-To: <4DCAC482.1080302@sprunk.org> References: <4DC9771D.6010809@arin.net> <4DCAC482.1080302@sprunk.org> Message-ID: On May 11, 2011, at 10:16 AM, Stephen Sprunk wrote: > On 11-May-11 11:39, Martin Millnert wrote: >> On Tue, May 10, 2011 at 9:01 PM, Jimmy Hess wrote: >>> I suggest something more like: >>> >>> The recipient of transferred number resources must sign a standard >>> Registration Services Agreement made public by ARIN, that ensures ARIN retains the right to charge fees and revoke resources as needed, to enforce number resource policies, or reclaim underutilized resources. >> I'm admittedly not very experienced in ARIN procedures, so if you would please help me out here: >> How does this motivate sellers of legacy space to involve ARIN in their transactions? > > A transferee is very interested in involving ARIN because they want to make sure the registration database will get updated; if ARIN refuses to record the transfer because it doesn't comply with policy, there is no reason to pay because they have received nothing of value. Therefore, a transferor must involve ARIN because they need to validate that the transfer will be recorded before they can get their money. > > Remember, numbers are not property and cannot be sold; what is being "sold" is a slot in ARIN's database. If you don't care about ARIN's database, just use whatever numbers you want without paying anyone! > >> My understanding of the term "legacy space" is that it was assigned to users prior to ARIN's (or others) existence, and that you can't assume there is contracts in place where the legacy space holder in effect converts their space to ARIN managed space (which in practical terms means the space isn't "legacy space" per my definition). > > All resources issued prior to ARIN's formation are legacy, regardless of whether they are currently covered by an (L)RSA. However, that's a moot point because the policy doesn't really affect to the transferor; it only applies to the transferee, who will be forced to sign some sort of contract for services rendered. > > Note that, while there is no legacy IPv6, there are legacy ASNs, not just IPv4 space; that's why we use the generic term "resources". (I'm not aware of anyone wanting to "buy" a legacy ASN, but in theory it could happen.) > Not really. Section 8.3 applies only to IPv4 resources. Owen -------------- next part -------------- An HTML attachment was scrubbed... URL: From owen at delong.com Wed May 11 14:02:27 2011 From: owen at delong.com (Owen DeLong) Date: Wed, 11 May 2011 11:02:27 -0700 Subject: [arin-ppml] ARIN-prop-148 LRSA resources must not be transferred to LRSA In-Reply-To: References: <4DC9771D.6010809@arin.net> Message-ID: On May 11, 2011, at 10:29 AM, William Herrin wrote: > On Tue, May 10, 2011 at 9:01 PM, Jimmy Hess wrote: >> On Tue, May 10, 2011 at 12:34 PM, ARIN wrote: >>> The recipient of transferred number resources MUST sign the RSA with >>> ARIN if the resources being transferred are already under LRSA. >>> Resources under LRSA may not be transferred to a recieving organization >>> and placed under a new LRSA with that organization. They must be placed >>> under the RSA, not the LRSA. >> >> I suggest something more like: >> >> The recipient of transferred number resources must sign a standard >> Registration Services >> Agreement made public by ARIN, that ensures ARIN retains the right to >> charge fees >> and revoke resources as needed, to enforce number resource policies, or reclaim >> underutilized resources. > > How about: > > 8.3.1 The recipient of transferred number resources shall, as a > condition of registration, consent to and sign the same registration > services agreement they would sign as a registrant of new number > resources from the free pool. > Works for me. Owen From kkargel at polartel.com Wed May 11 14:11:56 2011 From: kkargel at polartel.com (Kevin Kargel) Date: Wed, 11 May 2011 13:11:56 -0500 Subject: [arin-ppml] ARIN-prop-148 LRSA resources must not be transferred to LRSA In-Reply-To: <0486F032-43E7-4E4E-B029-AE0C3519C38F@delong.com> References: <4DC9771D.6010809@arin.net> <4DCA9270.9040706@ipinc.net> <8695009A81378E48879980039EEDAD289D0E5BF6@MAIL1.polartel.local> <0486F032-43E7-4E4E-B029-AE0C3519C38F@delong.com> Message-ID: <8695009A81378E48879980039EEDAD289D0E5BF8@MAIL1.polartel.local> > -----Original Message----- > From: Owen DeLong [mailto:owen at delong.com] > Sent: Wednesday, May 11, 2011 1:05 PM > To: Kevin Kargel > Cc: arin-ppml at arin.net > Subject: Re: [arin-ppml] ARIN-prop-148 LRSA resources must not be > transferred to LRSA > > >>> > >> Absolutely. This was the clear intent of the community in the phrasing > >> of 2009-1, the rationale, and both the community and AC discussions. > >> The fact that it is possible to do otherwise came as a surprise. > > > > I will agree and try to clarify by stating that "Legacy" 'rights' apply > to the 'Legacy' organization, not the number resource and are non- > transferrable. To my way of thinking when a numbered resource leaves the > original 'Legacy' holders dominion it no longer carries any aegis granted > to it by the 'Legacy' holders status. At that moment the resource becomes > common. > > > Slight refinement... "Legacy" status applies to the intersection of the > "Legacy" organization and the resources issued to them by one of > ARIN's predecessor registries. > > Owen > Agreed. However, the moment the organization severs the tie to the resource then the resource no longer enjoys the aegis provided by the organizations status. I'm getting dizzy. Kevin From owen at delong.com Wed May 11 14:09:18 2011 From: owen at delong.com (Owen DeLong) Date: Wed, 11 May 2011 11:09:18 -0700 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate In-Reply-To: <7F5FC4554E42430FADDC0D376164DFA0@mike> References: <7F5FC4554E42430FADDC0D376164DFA0@mike> Message-ID: <0BB63D56-1605-4E1E-8F0B-B2083FDE4A96@delong.com> I oppose the policy as written. Abandoning our stewardship role for the sake of making it more likely people will register their misappropriation of community resources is like legalizing bank robbery in the hopes that the thieves will pay income tax on their ill gotten gains. Owen On May 11, 2011, at 11:03 AM, Mike Burns wrote: > 1. Policy Proposal Name: IPv4 Transfer Policy Change to Keep Whois Accurate > > 2. Proposal Originator: > a. Name: Mike Burns > b. Email: mike at sum.net > c. Phone: 1-863-494-7692 x105 > d. Organization: Nationwide Computer Systems > > 3. Proposal Version: 1 > > 4. Date: May 11th, 2011 > > 5. Proposal type: modify > > 6. Policy term: permanent > > 7. Policy statement: > > Replace Section 8.3 with > > 8.3 ARIN will process and record IPv4 address transfer requests. > > Conditions on the IPv4 address block: > > - The minimum transfer size is a /24 > > - The address block must be in the range of addresses administered > by ARIN > > Conditions on source of the transfer: > > - The source entity must be the current rights 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 the transfer, or until the exhaustion of ARIN's > IPv4 space, whichever occurs first. > > - The source entity must not have received an allocation from ARIN for the 12 months prior to the transfer. > > > Conditions on recipient of the transfer: > > - The recipient entity must be a current ARIN account holder. > > - The recipient must sign an RSA with ARIN. > > - The recipient entity of the transferred resources will be subject > to current ARIN policies. In particular, in any subsequent ARIN > IPv4 address allocation request, the recipient will be required > to account for the efficient utilization of all IPv4 address > space held, including all transferred resources. > > and request the AC to modify section 8 of the current RSA to remove references to "intended purposes." > > Replace > ARIN may review, at any time, Applicant?s use of previously allocated or assigned number resources or Services received from ARIN to determine if Applicant is complying with this Agreement and the Policies and is using the Services for their intended purposes. Without limiting the foregoing, if Applicant is a holder of a direct allocation or assignment from ARIN, Applicant agrees that it will use the number resources solely for uses consistent with its application and this Agreement, including, for example, its internal infrastructure or to provide Internet access to its customer base. If ARIN determines that the number resources or any other Services are not being used in compliance with this Agreement, the Policies, or the purposes for which they are intended, ARIN may: (i) revoke the number resources; (ii) cease providing the Services to Applicant; and/or (iii) terminate this Agreement. > > with > > ARIN may review, at any time, any Applicant?s use of previously allocated or assigned number resources or Services received from ARIN to determine if Applicant is complying with this Agreement and the Policies. Without limiting the foregoing, if Applicant is a holder of a direct allocation or direct assignment from ARIN, Applicant agrees that it will use the number resources solely for uses consistent with this Agreement, including, for example, its internal infrastructure or to provide Internet access to its customer base. If ARIN determines that the number resources or any other Services are not being used in compliance with this Agreement or the Policies, ARIN may: (i) revoke the number resources; (ii) cease providing the Services to Applicant; and/or (iii) terminate this Agreement. > > and add to the NRPM Section 12: > > 10. ARIN will not use utilization as a measure of policy compliance for addresses transferred under 8.3. > > > 8. Rationale: > > > Current ARIN policies relating to the registration of transfer of > address holdings limit the eligibility of registration of transfers to > those relating to mergers and acquisitions of entities that are > administering an operational network, or to those who agree to > sign either an RSA or LRSA with ARIN and subject the buyer > to needs analysis and the seller to a potential ARIN review under RSA section 8. > > It is currently anticipated that the IPv4 unallocated address pool > will be exhausted within a couple of years at ARIN, and earlier > than that in other regions, and the transition to IPv6-based service delivery > is likely to take longer than the remaining period of unallocated > address availability. Accordingly, it is likely that demand for IPv4 > addresses will continue beyond the time of unallocated address pool > exhaustion, leading to a period of movement of IPv4 address blocks > between address holders to meet such continuing demand for IPv4 > address blocks. > > The underlying proposition behind this policy proposal is that the > registry of IPv4 addresses operated by ARIN is of general utility and > value only while it accurately describes the current state of address > distribution. If a class of address movement transactions are excluded > from being entered in the registry, then the registry will have > decreasing value to the broader community, and the integrity of the > network itself is thereby compromised. This proposal's central aim is > to ensure the continuing utility and value of the ARIN address > registry by allowing the registry to record transactions where IPv4 > addresses are transfered between ARIN account holders. > > It proposes that ARIN will recognise and register a transfer of > addresses where the parties to the transfer are 'known' to ARIN and > that the address block being transferred is part of ARIN's current address set. > > The proposal does not prescribe how such transfers may occur, nor > impose any further constraints on the transfer or on the parties > involved other than those described in this proposal. > > 9. Timetable for implementation: immediate. > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthew at matthew.at Wed May 11 14:43:25 2011 From: matthew at matthew.at (Matthew Kaufman) Date: Wed, 11 May 2011 11:43:25 -0700 Subject: [arin-ppml] ARIN-prop-148 LRSA resources must not be transferred to LRSA In-Reply-To: <4DC9771D.6010809@arin.net> References: <4DC9771D.6010809@arin.net> Message-ID: <4DCAD8CD.7000001@matthew.at> Opposed. Microsoft and ARIN must have had a good reason for having Microsoft sign a LRSA document for their recent transfer, and there is no evidence that ARIN's operations are improved by tying ARIN's hands in this area. Also conflicts with my proposal 142 (Define RSA) and 143 (Clarify Specified Transfer RSA Requirement) Matthew Kaufman From dogwallah at gmail.com Wed May 11 14:53:03 2011 From: dogwallah at gmail.com (McTim) Date: Wed, 11 May 2011 21:53:03 +0300 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate In-Reply-To: <0BB63D56-1605-4E1E-8F0B-B2083FDE4A96@delong.com> References: <7F5FC4554E42430FADDC0D376164DFA0@mike> <0BB63D56-1605-4E1E-8F0B-B2083FDE4A96@delong.com> Message-ID: On Wed, May 11, 2011 at 9:09 PM, Owen DeLong wrote: > I oppose the policy as written. +1 > Abandoning our stewardship role for the sake of making it more likely > people will register their misappropriation of community resources is > like legalizing bank robbery in the hopes that the thieves will pay > income tax on their ill gotten gains. ;-) -- Cheers, McTim "A name indicates what we seek. An address indicates where it is. A route indicates how we get there."? Jon Postel From mike at nationwideinc.com Wed May 11 15:13:52 2011 From: mike at nationwideinc.com (Mike Burns) Date: Wed, 11 May 2011 15:13:52 -0400 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate References: <7F5FC4554E42430FADDC0D376164DFA0@mike> <0BB63D56-1605-4E1E-8F0B-B2083FDE4A96@delong.com> Message-ID: <16AACD9632484C85BF6B855603CF07B4@mike> Hi Owen and McTim, I, along with the APNIC community, could make the claim that you are abandoning the stewardship role in maintaining Whois accuracy, and sacrificing that stewardship role on the altar of an ARIN needs policy developed for the purposes of free pool allocations that does not comply with current legal realities. But charges of abandoning stewardship are inflammatory, and I hope we can keep to actual discussions of the implications of my proposal without casting aspersions. Let's agree that we all seek the highest standards of stewardship, but disagree on how those standards should be applied. I think I could characterize your opposition better by saying that you believe the danger of hoarding and speculation outweigh the risk to whois accuracy. Would that be an accurate statement, if not your exclusive objection to the proposal? Regards, Mike ----- Original Message ----- From: "McTim" To: "Owen DeLong" Cc: "Mike Burns" ; Sent: Wednesday, May 11, 2011 2:53 PM Subject: Re: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate On Wed, May 11, 2011 at 9:09 PM, Owen DeLong wrote: > I oppose the policy as written. +1 > Abandoning our stewardship role for the sake of making it more likely > people will register their misappropriation of community resources is > like legalizing bank robbery in the hopes that the thieves will pay > income tax on their ill gotten gains. ;-) -- Cheers, McTim "A name indicates what we seek. An address indicates where it is. A route indicates how we get there." Jon Postel From john.sweeting at twcable.com Wed May 11 15:42:58 2011 From: john.sweeting at twcable.com (Sweeting, John) Date: Wed, 11 May 2011 15:42:58 -0400 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate Message-ID: I actually have a 10-1 pm that day ----- Reply message ----- From: "Mike Burns" Date: Wed, May 11, 2011 12:15 pm Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate To: "McTim" , "Owen DeLong" Cc: "arin-ppml at arin.net" Hi Owen and McTim, I, along with the APNIC community, could make the claim that you are abandoning the stewardship role in maintaining Whois accuracy, and sacrificing that stewardship role on the altar of an ARIN needs policy developed for the purposes of free pool allocations that does not comply with current legal realities. But charges of abandoning stewardship are inflammatory, and I hope we can keep to actual discussions of the implications of my proposal without casting aspersions. Let's agree that we all seek the highest standards of stewardship, but disagree on how those standards should be applied. I think I could characterize your opposition better by saying that you believe the danger of hoarding and speculation outweigh the risk to whois accuracy. Would that be an accurate statement, if not your exclusive objection to the proposal? Regards, Mike ----- Original Message ----- From: "McTim" To: "Owen DeLong" Cc: "Mike Burns" ; Sent: Wednesday, May 11, 2011 2:53 PM Subject: Re: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate On Wed, May 11, 2011 at 9:09 PM, Owen DeLong wrote: > I oppose the policy as written. +1 > Abandoning our stewardship role for the sake of making it more likely > people will register their misappropriation of community resources is > like legalizing bank robbery in the hopes that the thieves will pay > income tax on their ill gotten gains. ;-) -- Cheers, McTim "A name indicates what we seek. An address indicates where it is. A route indicates how we get there." Jon Postel _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. ________________________________ This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. From owen at delong.com Wed May 11 15:59:29 2011 From: owen at delong.com (Owen DeLong) Date: Wed, 11 May 2011 12:59:29 -0700 Subject: [arin-ppml] ARIN-prop-148 LRSA resources must not be transferred to LRSA In-Reply-To: <8695009A81378E48879980039EEDAD289D0E5BF8@MAIL1.polartel.local> References: <4DC9771D.6010809@arin.net> <4DCA9270.9040706@ipinc.net> <8695009A81378E48879980039EEDAD289D0E5BF6@MAIL1.polartel.local> <0486F032-43E7-4E4E-B029-AE0C3519C38F@delong.com> <8695009A81378E48879980039EEDAD289D0E5BF8@MAIL1.polartel.local> Message-ID: On May 11, 2011, at 11:11 AM, Kevin Kargel wrote: > > > > >> -----Original Message----- >> From: Owen DeLong [mailto:owen at delong.com] >> Sent: Wednesday, May 11, 2011 1:05 PM >> To: Kevin Kargel >> Cc: arin-ppml at arin.net >> Subject: Re: [arin-ppml] ARIN-prop-148 LRSA resources must not be >> transferred to LRSA >> >>>>> >>>> Absolutely. This was the clear intent of the community in the phrasing >>>> of 2009-1, the rationale, and both the community and AC discussions. >>>> The fact that it is possible to do otherwise came as a surprise. >>> >>> I will agree and try to clarify by stating that "Legacy" 'rights' apply >> to the 'Legacy' organization, not the number resource and are non- >> transferrable. To my way of thinking when a numbered resource leaves the >> original 'Legacy' holders dominion it no longer carries any aegis granted >> to it by the 'Legacy' holders status. At that moment the resource becomes >> common. >>> >> Slight refinement... "Legacy" status applies to the intersection of the >> "Legacy" organization and the resources issued to them by one of >> ARIN's predecessor registries. >> >> Owen >> > Agreed. However, the moment the organization severs the tie to the resource then the resource no longer enjoys the aegis provided by the organizations status. > Correct... Hence my statement of intersection. It's an and clause. So long as the resource was issued by a preceding registry _AND_ is in the hands of its original holder for its original purpose, the resources in question remain in legacy status. In some cases, earlier section 8.2 transfers allowed for the transfer of the legacy status to a successor organization with the acquisition of the underlying network infrastructure while retaining legacy status. My understanding of the modifications to 8.2 that occurred with the adoption and implementation of 2009-1 is that even those transfers now involve a standard RSA and valid justification. Owen From owen at delong.com Wed May 11 16:14:34 2011 From: owen at delong.com (Owen DeLong) Date: Wed, 11 May 2011 13:14:34 -0700 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate In-Reply-To: <16AACD9632484C85BF6B855603CF07B4@mike> References: <7F5FC4554E42430FADDC0D376164DFA0@mike> <0BB63D56-1605-4E1E-8F0B-B2083FDE4A96@delong.com> <16AACD9632484C85BF6B855603CF07B4@mike> Message-ID: On May 11, 2011, at 12:13 PM, Mike Burns wrote: > Hi Owen and McTim, > > I, along with the APNIC community, could make the claim that you are abandoning the stewardship role in maintaining Whois accuracy, and sacrificing that stewardship role on the altar of an ARIN needs policy developed for the purposes of free pool allocations that does not comply with current legal realities. > You could, but, you'd be wrong. > But charges of abandoning stewardship are inflammatory, and I hope we can keep to actual discussions of the implications of my proposal without casting aspersions. > Perhaps, but, I believe that is one of the implications of your proposal. > Let's agree that we all seek the highest standards of stewardship, but disagree on how those standards should be applied. > Sorry, I call it as I see it. I think abandoning needs-based resource management is an abandonment of the responsibility of stewardship in managing the resources. > I think I could characterize your opposition better by saying that you believe the danger of hoarding and speculation outweigh the risk to whois accuracy. I think that the risk to whois accuracy is relatively low and is a spectre or boogeyman argument used by those with more libertarian economic views than my own. OTOH, I think that the risks to the community that come with an abandonment of needs-basis and other secondary aspects of address resource management that spring from that is an extreme risk to the community and transitions the fundamental nature of the internet from the greatest tool ever developed for the democratization of communication to yet another tool for media exploitation. > Would that be an accurate statement, if not your exclusive objection to the proposal? > The statement in the last sentence is accurate. It is most certainly not my exclusive objection to the proposal, but, certainly the major one. Owen > Regards, > Mike > > > > ----- Original Message ----- From: "McTim" > To: "Owen DeLong" > Cc: "Mike Burns" ; > Sent: Wednesday, May 11, 2011 2:53 PM > Subject: Re: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate > > > On Wed, May 11, 2011 at 9:09 PM, Owen DeLong wrote: >> I oppose the policy as written. > > +1 > > >> Abandoning our stewardship role for the sake of making it more likely >> people will register their misappropriation of community resources is >> like legalizing bank robbery in the hopes that the thieves will pay >> income tax on their ill gotten gains. > > ;-) > > -- > Cheers, > > McTim > "A name indicates what we seek. An address indicates where it is. A > route indicates how we get there." Jon Postel From tedm at ipinc.net Wed May 11 16:17:02 2011 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Wed, 11 May 2011 13:17:02 -0700 Subject: [arin-ppml] ARIN-prop-148 LRSA resources must not be transferred to LRSA In-Reply-To: References: <4DC9771D.6010809@arin.net> Message-ID: <4DCAEEBE.8020404@ipinc.net> On 5/11/2011 9:39 AM, Martin Millnert wrote: > Jimmy, > > On Tue, May 10, 2011 at 9:01 PM, Jimmy Hess wrote: >> I suggest something more like: >> >> The recipient of transferred number resources must sign a standard >> Registration Services >> Agreement made public by ARIN, that ensures ARIN retains the right to >> charge fees >> and revoke resources as needed, to enforce number resource policies, or reclaim >> underutilized resources. > > I'm admittedly not very experienced in ARIN procedures, so if you > would please help me out here: > How does this motivate sellers of legacy space to involve ARIN in > their transactions? > Martin, Keep in mind this proposal does not apply in that case. "Legacy Space" is specifically space that is NOT under an LRSA. Once it is under an LRSA it is no longer "legacy space" Ted From tvest at eyeconomics.com Wed May 11 16:34:57 2011 From: tvest at eyeconomics.com (Tom Vest) Date: Wed, 11 May 2011 16:34:57 -0400 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate In-Reply-To: <16AACD9632484C85BF6B855603CF07B4@mike> References: <7F5FC4554E42430FADDC0D376164DFA0@mike> <0BB63D56-1605-4E1E-8F0B-B2083FDE4A96@delong.com> <16AACD9632484C85BF6B855603CF07B4@mike> Message-ID: <4294678C-B653-4BB3-9D40-FD935EA00CF3@eyeconomics.com> Hi Mike, While it may or may not be true that your perspective on this question is consonant with that of "the APNIC community," elements within said community have been championing the same broad policy changes that you're advocating here now since the early 1990s. Thus it would seem that the views that you associate yourself with here couldn't possible have anything to do with "current legal realities" -- unless perhaps by "current" you mean something like "twentieth century." Given that historical fact -- and the apparent success of the RIR stewardship mission over the intervening two decades of possible nonconformity with legal reality -- on what basis could you legitimately claim that abandoning time-tested registry practices that have been integral to maintaining whois accuracy to date represents the best, or perhaps the only way to maintain whois accuracy in the future? Alternately, if you actually had in mind some other, more recent legal developments -- which by definition could not have any causal relation to policy arguments that predated them by 10-15 years -- a clarification of exactly what those changes in legal reality are would be much appreciated. Thanks, TV On May 11, 2011, at 3:13 PM, Mike Burns wrote: > Hi Owen and McTim, > > I, along with the APNIC community, could make the claim that you are abandoning the stewardship role in maintaining Whois accuracy, and sacrificing that stewardship role on the altar of an ARIN needs policy developed for the purposes of free pool allocations that does not comply with current legal realities. > > But charges of abandoning stewardship are inflammatory, and I hope we can keep to actual discussions of the implications of my proposal without casting aspersions. > > Let's agree that we all seek the highest standards of stewardship, but disagree on how those standards should be applied. > > I think I could characterize your opposition better by saying that you believe the danger of hoarding and speculation outweigh the risk to whois accuracy. > Would that be an accurate statement, if not your exclusive objection to the proposal? > > Regards, > Mike > > > > ----- Original Message ----- From: "McTim" > To: "Owen DeLong" > Cc: "Mike Burns" ; > Sent: Wednesday, May 11, 2011 2:53 PM > Subject: Re: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate > > > On Wed, May 11, 2011 at 9:09 PM, Owen DeLong wrote: >> I oppose the policy as written. > > +1 > > >> Abandoning our stewardship role for the sake of making it more likely >> people will register their misappropriation of community resources is >> like legalizing bank robbery in the hopes that the thieves will pay >> income tax on their ill gotten gains. > > ;-) > > -- > Cheers, > > McTim > "A name indicates what we seek. An address indicates where it is. A > route indicates how we get there." Jon Postel > _______________________________________________ > 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 Wed May 11 16:51:59 2011 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Wed, 11 May 2011 13:51:59 -0700 Subject: [arin-ppml] ARIN-prop-148 LRSA resources must not be transferred to LRSA In-Reply-To: <4DCAD8CD.7000001@matthew.at> References: <4DC9771D.6010809@arin.net> <4DCAD8CD.7000001@matthew.at> Message-ID: <4DCAF6EF.6060909@ipinc.net> On 5/11/2011 11:43 AM, Matthew Kaufman wrote: > Opposed. > > Microsoft and ARIN must have had a good reason for having Microsoft sign > a LRSA document for their recent transfer, Just to clarify this proposal does not apply to the Nortel->Microsoft purchase. The numbers that were assigned to Nortel were not under LRSA. If they had been, the bankruptcy court would not have been able to declare them property and attempt to sell them to settle debts, anymore than a bankruptcy court could declare your car property of your friend on the day that he files for bankruptcy, just because you parked it in his driveway. > and there is no evidence that > ARIN's operations are improved by tying ARIN's hands in this area. > > Also conflicts with my proposal 142 (Define RSA) and 143 (Clarify > Specified Transfer RSA Requirement) > If you are in favor of my proposal you would definitely not be in favor of either of your proposals, and vis-versa. My approach is to do as much as possible to push whatever Legacy numbers are out there into the main circus tent, that they all come under RSA just as all IPv6 numbers are under a single RSA (with specific modifications for governments, etc.) Your approach is to allow a new circus tent to be constructed, named LRSA and eventually all the Legacy numbers will be there and the non legacy IPv4 numbers will be in the main RSA circus tent. So yes, I cannot see how the two proposals would be more incompatible. It will be interesting to see what approach the community prefers, eh? Ted > Matthew Kaufman > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From mike at nationwideinc.com Wed May 11 17:12:57 2011 From: mike at nationwideinc.com (Mike Burns) Date: Wed, 11 May 2011 17:12:57 -0400 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate References: <7F5FC4554E42430FADDC0D376164DFA0@mike> <0BB63D56-1605-4E1E-8F0B-B2083FDE4A96@delong.com> <16AACD9632484C85BF6B855603CF07B4@mike> <4294678C-B653-4BB3-9D40-FD935EA00CF3@eyeconomics.com> Message-ID: Hi Tom and welcome to this particular discussion, The current legal realities I referenced are the implications of the public information associated with the MS/Nortel deal. In this forum I have argued that the public bankruptcy documents reveal that the addresses transferred from Nortel to MS were not originally allocated to Nortel, but represented some accumulation of addresses allocated to Nortel's "predecessors in interest" who were Nortel acquisitions from the 1990s. I argued that MS and Nortel negotiated a deal to sell all the addresses in that accretion, although the public documents reveal that Microsoft was able to bid on an amount smaller than the entire lot. After the original asset sale agreement between MS and Nortel was negotiated, ARIN became aware of the transaction, and after some negotiations with the parties at interest, and some changes to the MS/Nortel asset agreement, made a press release claiming that the transfer could proceed under existing ARIN policy. ARIN later revealed the policy utilized to be NRPM 8.3, which requires four things which may or may not have actually happened: 1. Addresses are supposed to be issued back to ARIN and then reissued to the recipient, Microsoft, and the bankruptcy docs did not reveal this happened in any way. 2. Address are supposed to be transferred as a single aggregate, but if the addresses were an assortment of netblocks from prior Nortel acquisitions, this could not have happened. 3. Recipients were required to sign an RSA, MS signed a modified LRSA. 4. Finally, the requirement at issue here, a needs analysis had to be completed by ARIN, which magically showed that MS qualified for exactly the amount already bid for and negotiated the sale of. If they had needed fewer addresses, they could have bid for less than the full pool. If they needed more addresses, they should have received an additional ARIN allocation. Paraphrasing Goldilocks, the random allocation of addresses to long-ago Nortel acquisitions was "just right." My reading of the bankruptcy documents leads me to the conclusion that the bankruptcy judge found that Nortel had the exclusive right to transfer the addresses, even though the judge had not been informed of any ex-post-facto NRPM 8.2 transfer from the original registrants to Nortel. To me, this means he was convinced that ARIN had no rights over transferring the addresses, although ARIN has rights over reflecting that transfer in Whois. This is consistent with a declaration by the head of ARIN at the time in the Kremen case where he stated that ARIN has no authority over legacy addresses. My argument is that the apparent success of RIR stewardship (although I claim many of the allocated and unrouted addresses represent failures here) over the last two decades is laudable and represents an obvious requirement in the stewardship of free pool resources, but is unnecessary in a post-exhaust age where the price of addresses will ensure efficient use. I also argue that in the post-exhaust age, conflicts over claims to address rights will likely increase, putting more pressure on Whois to accurately represent reality. Regards, Mike Burns ----- Original Message ----- From: "Tom Vest" To: "Mike Burns" Cc: "McTim" ; "Owen DeLong" ; Sent: Wednesday, May 11, 2011 4:34 PM Subject: Re: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate Hi Mike, While it may or may not be true that your perspective on this question is consonant with that of "the APNIC community," elements within said community have been championing the same broad policy changes that you're advocating here now since the early 1990s. Thus it would seem that the views that you associate yourself with here couldn't possible have anything to do with "current legal realities" -- unless perhaps by "current" you mean something like "twentieth century." Given that historical fact -- and the apparent success of the RIR stewardship mission over the intervening two decades of possible nonconformity with legal reality -- on what basis could you legitimately claim that abandoning time-tested registry practices that have been integral to maintaining whois accuracy to date represents the best, or perhaps the only way to maintain whois accuracy in the future? Alternately, if you actually had in mind some other, more recent legal developments -- which by definition could not have any causal relation to policy arguments that predated them by 10-15 years -- a clarification of exactly what those changes in legal reality are would be much appreciated. Thanks, TV On May 11, 2011, at 3:13 PM, Mike Burns wrote: > Hi Owen and McTim, > > I, along with the APNIC community, could make the claim that you are > abandoning the stewardship role in maintaining Whois accuracy, and > sacrificing that stewardship role on the altar of an ARIN needs policy > developed for the purposes of free pool allocations that does not comply > with current legal realities. > > But charges of abandoning stewardship are inflammatory, and I hope we can > keep to actual discussions of the implications of my proposal without > casting aspersions. > > Let's agree that we all seek the highest standards of stewardship, but > disagree on how those standards should be applied. > > I think I could characterize your opposition better by saying that you > believe the danger of hoarding and speculation outweigh the risk to whois > accuracy. > Would that be an accurate statement, if not your exclusive objection to > the proposal? > > Regards, > Mike > > > > ----- Original Message ----- From: "McTim" > To: "Owen DeLong" > Cc: "Mike Burns" ; > Sent: Wednesday, May 11, 2011 2:53 PM > Subject: Re: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois > Accurate > > > On Wed, May 11, 2011 at 9:09 PM, Owen DeLong wrote: >> I oppose the policy as written. > > +1 > > >> Abandoning our stewardship role for the sake of making it more likely >> people will register their misappropriation of community resources is >> like legalizing bank robbery in the hopes that the thieves will pay >> income tax on their ill gotten gains. > > ;-) > > -- > Cheers, > > McTim > "A name indicates what we seek. An address indicates where it is. A > route indicates how we get there." Jon Postel > _______________________________________________ > 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 mike at nationwideinc.com Wed May 11 17:13:03 2011 From: mike at nationwideinc.com (Mike Burns) Date: Wed, 11 May 2011 17:13:03 -0400 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate References: <7F5FC4554E42430FADDC0D376164DFA0@mike> <0BB63D56-1605-4E1E-8F0B-B2083FDE4A96@delong.com> <16AACD9632484C85BF6B855603CF07B4@mike> Message-ID: <59EC8A7F22F247058ED74A896F0C6978@mike> Hi Owen, >Sorry, I call it as I see it. I think abandoning needs-based resource >management >is an abandonment of the responsibility of stewardship in managing the >resources. The needs requirement is a hold-over from the soon-to-be-past. A needs requirement was mandatory when it came to allocating addresses from the free pool. I hope I don't need to go over why this is so. That requirement of stewardship was there to ensure that addresses were allocated to where they would be used efficiently. Another requirement of proper stewardship, to my mind, is not making rules where they are not needed. To maximize freedom to members of the community, isn't the lightest touch absolutely necessary for order what is demanded of the steward? In a post-exhaust world, human greed will ensure address are used efficiently, so the stewardship need for justification can be eliminated, as it's raison d'etre has ceased to exist. On the other hand, in a post-exhaust world where IPv4 addresses may increase in value, it is easy to see that conflict between address rights claimants is likely to rise. This will naturally put stress on Whois that hasn't existed to that extent in an age of "free" address availability. We have witnessed in the MS/Nortel transaction that ARIN policy is not completely aligned with the law, and the shabby way ARIN scurried to slap an ARIN-approved sticker on the transaction has cost ARIN trust. Surely you see that if Microsoft didn't luckily have an ARIN-assessed need which was in line with the prior agreement negotiated with Nortel, that ARIN would have been faced with a legal transfer which could not be accurately reflected in Whois under current policy. Other transactions like this have occurred and will likely increase in frequency as we move through total exhaust of the free pools. Should reliance on Whois accuracy suffer as a result, the door is open to private registries whom network operators can go to to find more accurate information about routing authority. >> I think I could characterize your opposition better by saying that you >> believe the danger of hoarding and speculation outweigh the risk to whois >> accuracy. >I think that the risk to whois accuracy is relatively low and is a spectre >or boogeyman >argument used by those with more libertarian economic views than my own. >OTOH, I think that the risks to the community that come with an abandonment >of >needs-basis and other secondary aspects of address resource management that >spring from that is an extreme risk to the community and transitions the >fundamental >nature of the internet from the greatest tool ever developed for the >democratization >of communication to yet another tool for media exploitation. > Owen What is the "extreme risk" you mention, if not the impact you feel would come from hoarders and speculators? Is not my proposal in favor of more freedom for the members of the community? What's more, my proposal will provide an incentive to bring legacy addresses under RSA through increasing the rights of RSA holders to hold and transfer addresses. I think the value of bringing address space under an agreement where no agreement existed before should be considered as another positive effect of my proposal. To me, the objections are: Fears of a free market >> Risk to whois + getting more legacy space under RSA. This decision comes down to how much do you fear a free market? Regards, Mike From stephen at sprunk.org Wed May 11 18:02:53 2011 From: stephen at sprunk.org (Stephen Sprunk) Date: Wed, 11 May 2011 17:02:53 -0500 Subject: [arin-ppml] ARIN-prop-148 LRSA resources must not be transferred to LRSA In-Reply-To: <4DCAEEBE.8020404@ipinc.net> References: <4DC9771D.6010809@arin.net> <4DCAEEBE.8020404@ipinc.net> Message-ID: <4DCB078D.8090602@sprunk.org> On 11-May-11 15:17, Ted Mittelstaedt wrote: > "Legacy Space" is specifically space that is NOT under an LRSA. Once > it is under an LRSA it is no longer "legacy space" Incorrect. The entire purpose of the Legacy RSA is to allow registrants to enter a contractual relationship with ARIN /without /losing "legacy" status. That status is only lost for resources put under a /standard/ RSA. S -- Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3646 bytes Desc: S/MIME Cryptographic Signature URL: From dogwallah at gmail.com Wed May 11 18:09:09 2011 From: dogwallah at gmail.com (McTim) Date: Thu, 12 May 2011 01:09:09 +0300 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate In-Reply-To: <59EC8A7F22F247058ED74A896F0C6978@mike> References: <7F5FC4554E42430FADDC0D376164DFA0@mike> <0BB63D56-1605-4E1E-8F0B-B2083FDE4A96@delong.com> <16AACD9632484C85BF6B855603CF07B4@mike> <59EC8A7F22F247058ED74A896F0C6978@mike> Message-ID: Hi, On Thu, May 12, 2011 at 12:13 AM, Mike Burns wrote: > > In a post-exhaust world, human greed will ensure address are used > efficiently, While I agree with the vast majority of Tom's and Owen's comments, I think the above sentence is really the crux of my opposition. Leaving aside the morality of the whole "Greed is Good" discussion, the goal of the RIR system is not "efficiency". The goals, IIRC, are uniqueness, registration and conservation. It just makes no sense to me to abandon a needs basis just because we are getting closer to the bottom of the pool. I think a needs basis may be even more important as the crunch comes. While hoarding/speculation/arbitrage are things I am concerned about, they are not necessarily my primary concern. BTW, would you be in favor of an IPv4 futures market, where companies don't actually buy and sell address blocks, they just buy and sell contracts to buy/sell v4 blocks at some future date? I think Owen is spot on that "the risk to whois accuracy is relatively low and is a spectre" (although I would call it a red-herring). I also think your characterisation of ARIN actions as "shabby" is unwarranted. In short, I think we will just have to agree to disagree on this one. I doubt either one of us will be able to change the others fundamental perspective. -- Cheers, McTim "A name indicates what we seek. An address indicates where it is. A route indicates how we get there."? Jon Postel From owen at delong.com Wed May 11 18:37:22 2011 From: owen at delong.com (Owen DeLong) Date: Wed, 11 May 2011 15:37:22 -0700 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate In-Reply-To: <59EC8A7F22F247058ED74A896F0C6978@mike> References: <7F5FC4554E42430FADDC0D376164DFA0@mike> <0BB63D56-1605-4E1E-8F0B-B2083FDE4A96@delong.com> <16AACD9632484C85BF6B855603CF07B4@mike> <59EC8A7F22F247058ED74A896F0C6978@mike> Message-ID: On May 11, 2011, at 2:13 PM, Mike Burns wrote: > Hi Owen, > >> Sorry, I call it as I see it. I think abandoning needs-based resource management >> is an abandonment of the responsibility of stewardship in managing the resources. > > The needs requirement is a hold-over from the soon-to-be-past. The needs requirement is as valid post run-out as it was prior to runout. There is no reason in my mind that need is any less important in reallocation than it was in allocation. > A needs requirement was mandatory when it came to allocating addresses from the free pool. > I hope I don't need to go over why this is so. It is at least as mandatory for maintaining some level of sanity in a transfer world as well. > That requirement of stewardship was there to ensure that addresses were allocated to where they would be used efficiently. Among other things, yes. More accurately it was to ensure that early address acquisition by parties without need did not unfairly prevent or increase the difficulty/cost/other metric of later address acquisition by parties that didn't have present need. > Another requirement of proper stewardship, to my mind, is not making rules where they are not needed. Agreed. If I fell that needs-basis was unneeded in a post run-out environment, I'd be the first to champion the idea. However, that isn't the case. > To maximize freedom to members of the community, isn't the lightest touch absolutely necessary for order what is demanded of the steward? > Indeed it is. Hence my belief that the relatively light touch of needs-basis must remain there to avoid the heavy handedness of the invisible hand wielded by greedy power-brokers attempting to control a market for their own interests over that of the community. > In a post-exhaust world, human greed will ensure address are used efficiently, so the stewardship need for justification can be eliminated, as it's raison d'etre has ceased to exist. > No, it won't. It will ensure addresses are used to the greatest monetary benefit of the people who have them, whether that is in the community's interest or not. > On the other hand, in a post-exhaust world where IPv4 addresses may increase in value, it is easy to see that conflict between address rights claimants is likely to rise. True. > This will naturally put stress on Whois that hasn't existed to that extent in an age of "free" address availability. This statement is less convincing. > We have witnessed in the MS/Nortel transaction that ARIN policy is not completely aligned with the law, and the shabby way ARIN scurried to slap an ARIN-approved sticker on the transaction has cost ARIN trust. Surely you see that if Microsoft didn't luckily have an ARIN-assessed need which was in line with the prior agreement negotiated with Nortel, that ARIN would have been faced with a legal transfer which could not be accurately reflected in Whois under current policy. Other transactions like this have occurred and will likely increase in frequency as we move through total exhaust of the free pools. > Repeating this invalid assertion doesn't make it any more accurate than it was the first time you uttered it. When you assert other such transactions, are you referring to the 10 for which John Curran provided anonymized data, or, are you asserting that there are others which have occurred outside of ARIN? If so, can you cite examples or provide any documentary proof of such a claim? > Should reliance on Whois accuracy suffer as a result, the door is open to private registries whom network operators can go to to find more accurate information about routing authority. > I am utterly unconvinced that an ad-hoc pile of competing registries none of whom have any obligation to maintain uniqueness vs. what other private registries would somehow provide something the community would find more valuable. Guaranteed Uniqueness is the true value of IP number registrations when you get right down to it. In an ad-hoc private registry system, guaranteed uniqueness is likely one of the first casualties sacrificed on the altar of greed. Additionally, it remains unclear how ISPs would go about determining which of disparate and disagreeing registries was "more" accurate than the others. With the RIR system, we have a set of known rules enacted by the consensus of the community for the benefit of the community. The fact that one court wasn't as aware of those rules as would be ideal and that there are others who seek to circumvent those rules for their own benefit is not a convincing argument for the idea that we should utterly abandon the rules. As I said before, to me, this seems akin to legalizing bank robbery in the hopes that the thieves would pay income tax on their stolen money. > >>> I think I could characterize your opposition better by saying that you believe the danger of hoarding and speculation outweigh the risk to whois accuracy. > >> I think that the risk to whois accuracy is relatively low and is a spectre or boogeyman >> argument used by those with more libertarian economic views than my own. > >> OTOH, I think that the risks to the community that come with an abandonment of >> needs-basis and other secondary aspects of address resource management that >> spring from that is an extreme risk to the community and transitions the fundamental >> nature of the internet from the greatest tool ever developed for the democratization >> of communication to yet another tool for media exploitation. >> Owen > > What is the "extreme risk" you mention, if not the impact you feel would come from hoarders and speculators? Hoarding and speculating are one extreme risk. Extreme disaggregation is another. The movement of the internet at its foundation from its current status as a tool for the democratization of communications to another resource to be exploited by those with the greatest wealth is a third. > Is not my proposal in favor of more freedom for the members of the community? > Anarchy is the greatest form of freedom possible. It does not lend itself well to creating guaranteed uniqueness among competing economic interests. > What's more, my proposal will provide an incentive to bring legacy addresses under RSA through increasing the rights of RSA holders to hold and transfer addresses. At the price of rendering virtually every purpose of the RSA moot. > I think the value of bringing address space under an agreement where no agreement existed before should be considered as another positive effect of my proposal. > Only to the extent that the agreement itself has value to the community. By stripping the community value of the RSA, you are, in effect, making the agreement more palatable to those who prefer not to be part of the community, but, you are also eliminating the benefit to the community at the same time. > To me, the objections are: Fears of a free market >> Risk to whois + getting more legacy space under RSA. > This decision comes down to how much do you fear a free market? > While I don't think that's the entire argument or even a particularly accurate framing of that portion of the argument, I would say that the history of free markets does give one plenty to fear. Especially when you consider that history in situations of truly finite (even for a short time) resources. (Tulips anyone?) Other things that play a factor are the idea that the community has placed rules on address distribution for good reasons that benefit the community. As a member and as a representative of the community, I cannot favor the elimination of those rules just to benefit a handful of vocal opponents. While I may be the most vocal opponent of your proposal and/or your position, there has been significant pushback from other members of the community. Owen From tedm at ipinc.net Wed May 11 18:47:07 2011 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Wed, 11 May 2011 15:47:07 -0700 Subject: [arin-ppml] ARIN-prop-148 LRSA resources must not be transferred to LRSA In-Reply-To: <4DCB078D.8090602@sprunk.org> References: <4DC9771D.6010809@arin.net> <4DCAEEBE.8020404@ipinc.net> <4DCB078D.8090602@sprunk.org> Message-ID: <4DCB11EB.3090709@ipinc.net> On 5/11/2011 3:02 PM, Stephen Sprunk wrote: > On 11-May-11 15:17, Ted Mittelstaedt wrote: >> "Legacy Space" is specifically space that is NOT under an LRSA. Once >> it is under an LRSA it is no longer "legacy space" > > Incorrect. The entire purpose of the Legacy RSA is to allow registrants > to enter a contractual relationship with ARIN /without /losing "legacy" > status. That status is only lost for resources put under a /standard/ RSA. > Stephen, read section 7 of the LRSA, the signatory is required to abide by the NRPM and the signatory also gives up any claim of "property rights in section 9 and the signatory also agrees to return unused numbers. This is a significant departure from the status of "Legacy" numbers that are not under LRSA. Ted From matthew at matthew.at Wed May 11 18:51:11 2011 From: matthew at matthew.at (Matthew Kaufman) Date: Wed, 11 May 2011 15:51:11 -0700 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate In-Reply-To: References: <7F5FC4554E42430FADDC0D376164DFA0@mike> <0BB63D56-1605-4E1E-8F0B-B2083FDE4A96@delong.com> <16AACD9632484C85BF6B855603CF07B4@mike> <4294678C-B653-4BB3-9D40-FD935EA00CF3@eyeconomics.com> Message-ID: <4DCB12DF.7020106@matthew.at> On 5/11/2011 2:12 PM, Mike Burns wrote: > > ARIN later revealed the policy utilized to be NRPM 8.3, which requires > four things which may or may not have actually happened: > > 1. Addresses are supposed to be issued back to ARIN and then reissued > to the recipient, Microsoft, and the bankruptcy docs did not reveal > this happened in any way. 8.3 doesn't say that. It says "released", and ARIN says the release was sufficient for their needs. > 2. Address are supposed to be transferred as a single aggregate, but > if the addresses were an assortment of netblocks from prior Nortel > acquisitions, this could not have happened. ARIN says they read that part of 8.3 as applying to the needs assessment and NOT to the transfer... in other words the "need" is based on a single aggregate but >1 block can be part of a transfer. Doesn't matter, because you can just do multiple serial transfers to get around this if it is read the other way. > 3. Recipients were required to sign an RSA, MS signed a modified LRSA. LRSA is "an RSA". (Not that RSA is even defined in the NRPM... I have a proposal that fixes this) > 4. Finally, the requirement at issue here, a needs analysis had to be > completed by ARIN, which magically showed that MS qualified for > exactly the amount already bid for and negotiated the sale of. Needs assessment is under NDA, so we'll never know. Matthew Kaufman From JOHN at egh.com Wed May 11 18:58:38 2011 From: JOHN at egh.com (John Santos) Date: Wed, 11 May 2011 18:58:38 -0400 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate In-Reply-To: Message-ID: <1110511185755.1397B-100000@Ives.egh.com> On Wed, May 11, 2011 at 9:09 PM, Owen DeLong wrote: > I oppose the policy as written. > +1 -- John Santos Evans Griffiths & Hart, Inc. 781-861-0670 ext 539 From ikiris at gmail.com Wed May 11 19:05:12 2011 From: ikiris at gmail.com (Blake Dunlap) Date: Wed, 11 May 2011 18:05:12 -0500 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate In-Reply-To: <1110511185755.1397B-100000@Ives.egh.com> References: <1110511185755.1397B-100000@Ives.egh.com> Message-ID: While I think Mike has valid points about the effects of monetization of ip addresses as a whole providing companies with an abundance of IP space a sense of value that would greatly increase availability of transfers, I do not prescribe to his lazzie fair fantasy of how the internet, and the world in general would operate under no rules free market. I also oppose as written, but I do see a justification for opening up the transfer market more than it is now. We're going to have to suck it up and deal with both the deaggregation and monetization of IPv4 at some point, might as well get it over with. -Blake -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcurran at arin.net Wed May 11 19:47:22 2011 From: jcurran at arin.net (John Curran) Date: Wed, 11 May 2011 23:47:22 +0000 Subject: [arin-ppml] ARIN-prop-148 LRSA resources must not be transferred to LRSA In-Reply-To: <4DCAF6EF.6060909@ipinc.net> References: <4DC9771D.6010809@arin.net> <4DCAD8CD.7000001@matthew.at> <4DCAF6EF.6060909@ipinc.net> Message-ID: <13CD8E5B-17C1-4002-95EA-C5BF7F434B32@arin.net> On May 11, 2011, at 1:51 PM, Ted Mittelstaedt wrote: > Just to clarify this proposal does not apply to the Nortel->Microsoft > purchase. The numbers that were assigned to Nortel were not under > LRSA. If they had been, the bankruptcy court would not have been able > to declare them property ... For clarity, I need to reiterate some basic facts from the actual public documents regarding that transfer: - The original proposed sale agreement did indeed ask the court to declare the IP addresses themselves to be property: "(ii) the Legacy Number Blocks are property of NNI's bankruptcy estate; - The revised sale agreement as approved by the court does not order such, but instead indicates that the "Seller's Rights in and to the Legacy Number Blocks" are the property in question: "(ii) Seller?s Rights in the Legacy Number Blocks are property of Seller?s bankruptcy estate;" Similarly, the proposed bankruptcy court Order in the matter would have declared the Legacy Number Blocks property. It was revised as well, and as adopted does not declare the Legacy Number Blocks property but instead reads "The Seller has the exclusive right to use the Internet Numbers and the exclusive right to transfer its exclusive right to use the Internet Numbers." To wit, the bankruptcy court did not declare the included legacy numbers in the matter to be property, despite any assertions to the contrary. Legacy address holders do have certain rights regarding their address block holdings, but that does not mean there are not other rights and interests applicable to same address address blocks. ARIN will continue to maintain that the rights that are applicable to all registry entries are subject to the community-developed policies in the region. FYI, /John John Curran President and CEO ARIN From mysidia at gmail.com Wed May 11 19:55:11 2011 From: mysidia at gmail.com (Jimmy Hess) Date: Wed, 11 May 2011 18:55:11 -0500 Subject: [arin-ppml] ARIN-prop-148 LRSA resources must not be transferred to LRSA In-Reply-To: <4DCA9270.9040706@ipinc.net> References: <4DC9771D.6010809@arin.net> <4DCA9270.9040706@ipinc.net> Message-ID: On Wed, May 11, 2011 at 8:43 AM, Ted Mittelstaedt wrote: > On 5/10/2011 6:14 PM, Owen DeLong wrote: > So by your responses, I take it that both of you are in favor of > the general idea that resources under LRSA, when transferred, should > be moved into the regular RSA in every practicable instance? > > In short, the LRSA is intended as a single-use device, for the purposes Yes. I agree with all that. Unless all ARIN resource holders are allowed to upgrade to the LRSA. Transfer recipients should not be allowed to. But there is a reason the "Legacy RSA" is the Legacy RSA and not the standard RSA. The Legacy RSA is a time-limited special offer meant to be part of an effort to reach out and incentivize legacy holders to enter their resources into a formal agreement for registration services prior to December 31 2011. The agreement should not be used, except for that offer, where a legacy holder places all legacy resources under LRSA, but anyone receiving non-legacy resources needs to sign the standard RSA. 8.3 transfer recipients do not need an "incentive", to enter a registration services agreement; they will want services from ARIN, in order to provision Reverse DNS and WHOIS and become the legitimate, publicly recognized holder of the resources. > Ted -- -JH From owen at delong.com Wed May 11 19:59:46 2011 From: owen at delong.com (Owen DeLong) Date: Wed, 11 May 2011 16:59:46 -0700 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate In-Reply-To: <4DCB12DF.7020106@matthew.at> References: <7F5FC4554E42430FADDC0D376164DFA0@mike> <0BB63D56-1605-4E1E-8F0B-B2083FDE4A96@delong.com> <16AACD9632484C85BF6B855603CF07B4@mike> <4294678C-B653-4BB3-9D40-FD935EA00CF3@eyeconomics.com> <4DCB12DF.7020106@matthew.at> Message-ID: <1611B419-92A6-486E-81F9-B3E77379A1BC@delong.com> On May 11, 2011, at 3:51 PM, Matthew Kaufman wrote: > On 5/11/2011 2:12 PM, Mike Burns wrote: >> >> ARIN later revealed the policy utilized to be NRPM 8.3, which requires four things which may or may not have actually happened: >> >> 1. Addresses are supposed to be issued back to ARIN and then reissued to the recipient, Microsoft, and the bankruptcy docs did not reveal this happened in any way. > > 8.3 doesn't say that. It says "released", and ARIN says the release was sufficient for their needs. > It says "released TO ARIN". I'm not sure that I see a meaningful difference between "issued back to", "released to", or "returned to", but, if you believe the words somehow have a significantly different meaning, that's fine. Point is that the addresses do not flow from the transferor to the transferee, they flow from the transferor to ARIN to the transferee. >> 2. Address are supposed to be transferred as a single aggregate, but if the addresses were an assortment of netblocks from prior Nortel acquisitions, this could not have happened. > > ARIN says they read that part of 8.3 as applying to the needs assessment and NOT to the transfer... in other words the "need" is based on a single aggregate but >1 block can be part of a transfer. Doesn't matter, because you can just do multiple serial transfers to get around this if it is read the other way. > Yes, this appears to me to be misinterpretation by ARIN staff of language that was accidentally and unexpectedly vague in its intent. While I believe that the community intent in the policy was clear and that the staff interpretation is arguably nonsensical, the fact remains that it is a valid gramatical construction of the policy as it exists and I support resolving this difference. >> 3. Recipients were required to sign an RSA, MS signed a modified LRSA. > > LRSA is "an RSA". (Not that RSA is even defined in the NRPM... I have a proposal that fixes this) > Indeed, the policy language here is also unfortunately ambiguous and I support resolving this as well. I believe that the intent of the community was for recipients to sign a standard current RSA and not any form of legacy RSA. >> 4. Finally, the requirement at issue here, a needs analysis had to be completed by ARIN, which magically showed that MS qualified for exactly the amount already bid for and negotiated the sale of. > > Needs assessment is under NDA, so we'll never know. > It is not unlikely that Micr0$0ft bid for exactly what they needed, so, I fail to see why this is regarded as so unlikely. Owen From mysidia at gmail.com Wed May 11 20:03:27 2011 From: mysidia at gmail.com (Jimmy Hess) Date: Wed, 11 May 2011 19:03:27 -0500 Subject: [arin-ppml] ARIN-prop-148 LRSA resources must not be transferred to LRSA In-Reply-To: References: <4DC9771D.6010809@arin.net> Message-ID: On Wed, May 11, 2011 at 12:29 PM, William Herrin wrote: > This allows for John Curran's case where the RSA sees minor changes to > accommodate government entities and the like. > -Bill If ARIN staff feels there are minor changes they should make to the RSA, they should make public record of those changes somewhere, and explain when they are used, rather than making Ad-Hoc alterations to the RSA, upon request, at any applicant's whim. It's not very transparent to say "we make minor changes"; your definition of minor might not be the community's definition of minor, and some random ARIN staff member's definition of minor might change as circumstances tempt to change it, for convenience sake. In any case, the registration rules shouldn't be different just because "it's a transfer" instead of a new allocation. -- -JH From jcurran at arin.net Wed May 11 20:05:05 2011 From: jcurran at arin.net (John Curran) Date: Thu, 12 May 2011 00:05:05 +0000 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate In-Reply-To: References: <7F5FC4554E42430FADDC0D376164DFA0@mike> <0BB63D56-1605-4E1E-8F0B-B2083FDE4A96@delong.com> <16AACD9632484C85BF6B855603CF07B4@mike> <4294678C-B653-4BB3-9D40-FD935EA00CF3@eyeconomics.com> Message-ID: On May 11, 2011, at 2:12 PM, Mike Burns wrote: > > My reading of the bankruptcy documents leads me to the conclusion that the bankruptcy judge found that Nortel had the exclusive right to transfer the addresses, Correct. That is stated in the judge's Order, and I have noted that such a finding is consistent with ARIN's assertions and is expected. > To me, this means he was convinced that ARIN had no rights over transferring the addresses, although ARIN has rights over reflecting that transfer in Whois. That's a rather interesting conclusion, as the judge actually made no Order to that effect (or even close). The judge did find that: "I. Purchaser has represented that it has entered into a Legacy Registration Services Agreement with ARIN with respect to the Internet Numbers (the ?LRSA?) J. No further consents or approvals are required for the Seller to enter into the Agreement, to transfer the Seller?s Rights in the Internet Numbers to the Purchaser or to consummate the Transaction other than entry of this Order and as set forth in the Agreement." > My argument is that the apparent success of RIR stewardship (although I claim many of the allocated and unrouted addresses represent failures here) over the last two decades is laudable and represents an obvious requirement in the stewardship of free pool resources, but is unnecessary in a post-exhaust age where the price of addresses will ensure efficient use. That is indeed possible and an excellent question for discussion and determination by the community. > I also argue that in the post-exhaust age, conflicts over claims to address rights will likely increase, putting more pressure on Whois to accurately represent reality. ARIN will maintain the reality of the Whois in accordance to the wishes of this community. Parties asserting that they'll deliver you some invisible numbers for a good price are always likely to find gullible parties, but actual transfers of entries in the registry will only occur in accordance with community-developed policies in the region. FYI, /John John Curran President and CEO ARIN From mysidia at gmail.com Wed May 11 20:23:41 2011 From: mysidia at gmail.com (Jimmy Hess) Date: Wed, 11 May 2011 19:23:41 -0500 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate In-Reply-To: <0BB63D56-1605-4E1E-8F0B-B2083FDE4A96@delong.com> References: <7F5FC4554E42430FADDC0D376164DFA0@mike> <0BB63D56-1605-4E1E-8F0B-B2083FDE4A96@delong.com> Message-ID: On Wed, May 11, 2011 at 1:09 PM, Owen DeLong wrote: > I oppose the policy as written. > Abandoning our stewardship role for the sake of making it more likely > people will register their misappropriation of community resources is > like legalizing bank robbery in the hopes that the thieves will pay > income tax on their ill gotten gains. +1. The proposal's name seems a bit out of place; "Keep Whois Accurate" is an eventual outcome the author hopes the policy will have / thinks the policy is necessary to achieve. Usually policies are named by the actions they will take, instead of theoretical results, it is hoped that the policy will have. A more fitting title would be: "Remove justified need and utilization criteria from resource transfers" The policy does nothing to ensure WHOIS accuracy. Even with this policy adopted, there is a possibility of black market transfers, and address hijacking; perhaps it will be cheaper. Removal of the utilization criterion encourages IP address speculation, which can cause temporary spikes of the price transferrors might ask for, resulting in internet instability due to the hijackings that encourages. " The underlying proposition behind this policy proposal is that the registry of IPv4 addresses operated by ARIN is of general utility and value only while it accurately describes the current state of address distribution. If a class of address movement transactions are excluded from being entered in the registry, then the registry will have decreasing value to the broader community, and the integrity of the network itself is thereby compromised. " The rationale claims there will be "a class of address movement transactions excluded from being entered into the registry" under current policy. We are to believe these movements will happen, and happen with sufficient frequency and quantity to be an issue, although this has not been shown to be the case. We are to believe that throwing out the justified need requirements for transfers is the best way to avoid that, and reflecting all such transfers in WHOIS is the most important consideration. I don't buy that argument. ARIN doesn't need to adopt this policy or remove needs justification from transfers to discourage illicit transfers. Another way ARIN can discourage illicit transfers, is to look for suspicious signs of possible IP address hijacking (legacy or otherwise), and work with the community to identify and flag IP addresses that are possibly hijacked or being used unofficially by an organization other than the registrant of record. > Owen -- -JH From jcurran at arin.net Wed May 11 20:31:08 2011 From: jcurran at arin.net (John Curran) Date: Thu, 12 May 2011 00:31:08 +0000 Subject: [arin-ppml] ARIN-prop-148 LRSA resources must not be transferred to LRSA In-Reply-To: References: <4DC9771D.6010809@arin.net> Message-ID: <6C902952-2438-41D9-88F0-22CF38A8EEA7@arin.net> On May 11, 2011, at 5:03 PM, Jimmy Hess wrote: > It's not very transparent to say "we make minor changes"; Correct. It's a tradeoff in providing reasonable ability to operate the organization versus transparency into the operations. > your definition of minor might not be the community's definition of minor, Also correct (but I believe we have sufficient insight to discern such) > and some random ARIN staff member's definition of minor might change as > circumstances tempt to change it, for convenience sake. Not going to happen; these are quite infrequent events and handled either under my supervision or under ARIN's COO Nate Davis. FYI, /John John Curran President and CEO ARIN From bill at herrin.us Wed May 11 20:46:35 2011 From: bill at herrin.us (William Herrin) Date: Wed, 11 May 2011 20:46:35 -0400 Subject: [arin-ppml] ARIN-prop-148 LRSA resources must not be transferred to LRSA In-Reply-To: References: <4DC9771D.6010809@arin.net> Message-ID: On Wed, May 11, 2011 at 8:03 PM, Jimmy Hess wrote: > On Wed, May 11, 2011 at 12:29 PM, William Herrin wrote: >> This allows for John Curran's case where the RSA sees minor changes to >> accommodate government entities and the like. >> -Bill > > If ARIN staff feels there are minor changes they should make to the > RSA, they should > make public record of those changes somewhere, ?and explain when they > are used, I agree. John -- how about publishing the one-off modified RSAs and LRSAs that have been used and explaining in each case what change was made and why it was deemed appropriate? Making non-substantive adjustments doesn't inherently strike me as unreasonable, but the interests of transparency would be well served by making those adjustments public knowledge. > rather than making ?Ad-Hoc alterations to the RSA, upon request, > at any applicant's whim. There is no evidence such a thing has occurred. John indicated that the changes were typically along the lines of https://www.arin.net/resources/legacy/index.html question #12. 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 11 21:00:07 2011 From: jcurran at arin.net (John Curran) Date: Thu, 12 May 2011 01:00:07 +0000 Subject: [arin-ppml] ARIN-prop-148 LRSA resources must not be transferred to LRSA In-Reply-To: References: <4DC9771D.6010809@arin.net> Message-ID: <31B7D0AD-785E-448D-95CA-F8256D8A38C7@arin.net> On May 11, 2011, at 5:46 PM, William Herrin wrote: > I agree. John -- how about publishing the one-off modified RSAs and > LRSAs that have been used and explaining in each case what change was > made and why it was deemed appropriate? Making non-substantive > adjustments doesn't inherently strike me as unreasonable, but the > interests of transparency would be well served by making those > adjustments public knowledge. My intent is to produce a more friendly and readable version of the LRSA & RSA which incorporates any common changes that we have had to make over time. This would both reduce the occasions that we need to make changes and also would allow folks to move to that version if they so choose. FYI, /John John Curran President and CEO ARIN From mike at nationwideinc.com Wed May 11 21:03:31 2011 From: mike at nationwideinc.com (Mike Burns) Date: Wed, 11 May 2011 21:03:31 -0400 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate References: <7F5FC4554E42430FADDC0D376164DFA0@mike> <0BB63D56-1605-4E1E-8F0B-B2083FDE4A96@delong.com> <16AACD9632484C85BF6B855603CF07B4@mike> <59EC8A7F22F247058ED74A896F0C6978@mike> Message-ID: <907EE389FDC5448ABC46ADD06420B86D@video> Hi Owen, >When you assert other such transactions, are you referring to the 10 for >which John Curran provided anonymized >data, or, are you asserting that there are others which have occurred >outside of ARIN? If so, can you cite examples >or provide any documentary proof of such a claim? I have personally seen many asset sale agreements which included legacy IP addresses which were completed without notifying ARIN, as there is still no requirement for legacy holders to do that. I have seen asset sale agreements which include ARIN accounts and passwords among the listed assets. The addresses change control, but whois still shows the original registrant. When it comes time to route the addresses, if the network operator questions the situation, I have seen them accept the asset sales agreements as acceptable proof of routing authority. And the addresses allocated to entity A are now in control of entity B, with bogus whois data. This is the kind of eventuality which I believe motivated the APNIC community to place the stewardship role of uniqueness above the stewardship role of needs-based transfers. Obviously I am asserting these things without documentary proof. >While I don't think that's the entire argument or even a particularly >accurate framing of that portion of the >argument, I would say that the history of free markets does give one plenty >to fear. Especially when you >consider that history in situations of truly finite (even for a short time) >resources. (Tulips anyone?) Of course we will disagree, but I see the Internet as a crucible of lassez-faire, and its manifest success resulted from those policies based in freedom and private choice. You seem to consider that needs-based allocations were some kind of social agreement preventing malfeasance of the wealthy and protecting the little guy. In reality, it was the least rulemaking possible in an era of free-pool allocations. There really was no other way to distribute scarce resources with no price unless the allocations were limited by need. And nobody really debates that, even an outlier like me. That cause goes away with the free pool, and the imperative against more rules than necessary dictates we lift those needs-based transfer rules. We have to understand the cause of needs requirements. It wasn't some egalitarian ethos, it was an obvious and fair mechanism for placing some limit on address allocations from a free pool of limited size. We didn't impose max limits per allocant, we didn't impose progressive fees that made larger blocks proportionally more expensive, we didn't create rules to favor corporate diversity, we didn't limit distributions per country, we didn't require an income statement of recipients so that we could judge whom to allocate to. We chose the most limited mechanism to ensure that the addresses were not wasted. If we understand that, and we understand that stewards make only the minimum rules necessary for order, it is easier to drop the emotional attachment to needs requirements in the face of free pool exhaust. You will note that despite my free-market inclinations, I have never argued to drop needs requirements for new allocations of IPv4 or for IPv6. I have searched long and hard for a historical analog to this situation. The best I could find was a policy of the US after the Revolutionary War, which allocated property to veterans of that war for free. You had to qualify by being a veteran, the total property available for allocation was limited in size, and the property had value. All the same as our IPv4 situation. In the historical case, there were no limits on resale of the allocated land, there were aggregators, there were speculators, and things progressed normally during the allocation time period, and the time period after the land was fully allocated. Some people intended to live and farm the land, others intended to sell their allocations. And American law allowed a free market in which these men could decide. Rather than judge the benefits of free markets by exceptions like manias and successful market cornering, both rare and shortlived events, why don't we judge free markets like our American ancestors did, even if we're Canadian, eh! Regards, Mike From owen at delong.com Wed May 11 21:04:37 2011 From: owen at delong.com (Owen DeLong) Date: Wed, 11 May 2011 18:04:37 -0700 Subject: [arin-ppml] ARIN-prop-148 LRSA resources must not be transferred to LRSA In-Reply-To: References: <4DC9771D.6010809@arin.net> Message-ID: <88D606D6-C7A3-4E48-9988-4CF29CD052A1@delong.com> On May 11, 2011, at 5:46 PM, William Herrin wrote: > On Wed, May 11, 2011 at 8:03 PM, Jimmy Hess wrote: >> On Wed, May 11, 2011 at 12:29 PM, William Herrin wrote: >>> This allows for John Curran's case where the RSA sees minor changes to >>> accommodate government entities and the like. >>> -Bill >> >> If ARIN staff feels there are minor changes they should make to the >> RSA, they should >> make public record of those changes somewhere, and explain when they >> are used, > > I agree. John -- how about publishing the one-off modified RSAs and > LRSAs that have been used and explaining in each case what change was > made and why it was deemed appropriate? Making non-substantive > adjustments doesn't inherently strike me as unreasonable, but the > interests of transparency would be well served by making those > adjustments public knowledge. > Agreed. This should be possible without identifying the particular recipient of the modification, so, I don't believe it would violate any NDA to do so. Owen From mike at nationwideinc.com Wed May 11 21:20:18 2011 From: mike at nationwideinc.com (Mike Burns) Date: Wed, 11 May 2011 21:20:18 -0400 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate References: <7F5FC4554E42430FADDC0D376164DFA0@mike> <0BB63D56-1605-4E1E-8F0B-B2083FDE4A96@delong.com> <16AACD9632484C85BF6B855603CF07B4@mike> <59EC8A7F22F247058ED74A896F0C6978@mike> Message-ID: Hi McTim, >The goals, IIRC, are uniqueness, registration and conservation. Uniqueness and registration are served by my proposal. Conservation of the free pool is rapidly becoming a thing of the past, and I want to continue needs-based allocations from the free pool. >It just makes no sense to me to abandon a needs basis just because we >are getting closer to the bottom of the pool. I think a needs basis >may be even more important as the crunch comes. I have given reasons why I believe, along with the APNIC community, that maintaining needs requirements for transfers will cause transactions to occur and not be registered. When the crunch comes, ARIN won't be allocating anything. The only ones allocating IPv4 resource then are those whose price is met. The need the seller will be concerned with is the need to get money for addresses. The need the buyer will be concerned with is utilizing them profitably. Neither buyer nor seller will be concerned with ARIN's determination of need. If ARIN won't register the transaction due to this requirement, whois suffers. >BTW, would you be in favor of an IPv4 futures market, where companies >don't actually buy and sell address blocks, they just buy and sell >contracts to buy/sell v4 blocks at some future date? I would be in favor of the freedom to create such a market if voluntary particpants want to engage in it. >I think Owen is spot on that "the risk to whois accuracy is relatively >low and is a spectre" (although I would call it a red-herring). I have personally seen these kinds of transactions, and even Owen concedes they will likely happen with more frequency as we move past free pool exhaust. >I also think your characterisation of ARIN actions as "shabby" is >unwarranted. Do you honestly believe that the ARIN needs analysis of the MS/Nortel deal was fair and accurate? If so, I can see why you would feel shabby is an unwarranted word. >In short, I think we will just have to agree to disagree on this one. >I doubt either one of us will be able to change the others fundamental >perspective. Agreed. Or should I say disagreed? >From the lack of support for my proposal, I would think that I was unable to change most people's perspective. Cheers to you, too McTim! Mike From jcurran at arin.net Wed May 11 21:22:59 2011 From: jcurran at arin.net (John Curran) Date: Thu, 12 May 2011 01:22:59 +0000 Subject: [arin-ppml] ARIN-prop-148 LRSA resources must not be transferred to LRSA In-Reply-To: <88D606D6-C7A3-4E48-9988-4CF29CD052A1@delong.com> References: <4DC9771D.6010809@arin.net> <88D606D6-C7A3-4E48-9988-4CF29CD052A1@delong.com> Message-ID: <8D9911BB-0F78-46F3-892A-B89FD0AD53D3@arin.net> On May 11, 2011, at 6:04 PM, Owen DeLong wrote: > Agreed. This should be possible without identifying the particular > recipient of the modification, so, I don't believe it would violate > any NDA to do so. That is not exactly clear, since parties to the language of an agreement might not want the terms disclosed even without attribution. For example, if a particular state (by statute) has an onerous paper-based notification requirement, and we negotiate an agreement from the department we work with that they will periodically log into ARIN Online and print out & send any materials that need to be mailed to contracting, that particular workaround is not necessarily something that they want to replicate with just any other vendors, and may be discerned even if the particular state name is redacted. I note this is ultimately a matter for the ARIN Board - if you will submit this suggestion to the ARIN ACSP, I will insure that it makes it on to an agenda for their consideration. It has potential impact to our ability to operate the organization successfully under some circumstances, but is a reasonable question for the Board to consider in fullness given the benefit of improved transparency. Thanks! /John John Curran President and CEO ARIN From mike at nationwideinc.com Wed May 11 21:28:54 2011 From: mike at nationwideinc.com (Mike Burns) Date: Wed, 11 May 2011 21:28:54 -0400 Subject: [arin-ppml] ARIN-prop-148 LRSA resources must not betransferred to LRSA References: <4DC9771D.6010809@arin.net> <88D606D6-C7A3-4E48-9988-4CF29CD052A1@delong.com> Message-ID: <083CA8768726468C89482C8D69EF6C71@video> +1 to the idea of publishing redacted RSAs. -Mike ----- Original Message ----- From: "Owen DeLong" To: "William Herrin" Cc: "John Curran" ; Sent: Wednesday, May 11, 2011 9:04 PM Subject: Re: [arin-ppml] ARIN-prop-148 LRSA resources must not betransferred to LRSA > > On May 11, 2011, at 5:46 PM, William Herrin wrote: > >> On Wed, May 11, 2011 at 8:03 PM, Jimmy Hess wrote: >>> On Wed, May 11, 2011 at 12:29 PM, William Herrin wrote: >>>> This allows for John Curran's case where the RSA sees minor changes to >>>> accommodate government entities and the like. >>>> -Bill >>> >>> If ARIN staff feels there are minor changes they should make to the >>> RSA, they should >>> make public record of those changes somewhere, and explain when they >>> are used, >> >> I agree. John -- how about publishing the one-off modified RSAs and >> LRSAs that have been used and explaining in each case what change was >> made and why it was deemed appropriate? Making non-substantive >> adjustments doesn't inherently strike me as unreasonable, but the >> interests of transparency would be well served by making those >> adjustments public knowledge. >> > Agreed. This should be possible without identifying the particular > recipient of the modification, so, I don't believe it would violate > any NDA to do so. > > 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 owen at delong.com Wed May 11 21:37:21 2011 From: owen at delong.com (Owen DeLong) Date: Wed, 11 May 2011 18:37:21 -0700 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate In-Reply-To: <907EE389FDC5448ABC46ADD06420B86D@video> References: <7F5FC4554E42430FADDC0D376164DFA0@mike> <0BB63D56-1605-4E1E-8F0B-B2083FDE4A96@delong.com> <16AACD9632484C85BF6B855603CF07B4@mike> <59EC8A7F22F247058ED74A896F0C6978@mike> <907EE389FDC5448ABC46ADD06420B86D@video> Message-ID: <4B99E603-7892-433A-9FB9-DB9A08D98F39@delong.com> On May 11, 2011, at 6:03 PM, Mike Burns wrote: > Hi Owen, > >> When you assert other such transactions, are you referring to the 10 for which John Curran provided anonymized >> data, or, are you asserting that there are others which have occurred outside of ARIN? If so, can you cite examples >> or provide any documentary proof of such a claim? > > I have personally seen many asset sale agreements which included legacy IP addresses which were completed without notifying ARIN, as there is still no requirement for legacy holders to do that. I have seen asset sale agreements which include ARIN accounts and passwords among the listed assets. The addresses change control, but whois still shows the original registrant. There is no reason that ARIN, upon conducting a section 12 review and finding that the original holder was no longer using the resources and/or was defunct could not reclaim those resources, so, the recipient in that case is taking a rather large risk. I do not believe ARIN will view the asset sale agreement as legitimizing the transfer and the community developed policies support reclamation of resources from defunct legacy holders. ARIN has reclaimed such resources in the past, though I do not know if they have reclaimed them from organizations who believe they were able to "purchase" them as part of some form of asset transfer. > When it comes time to route the addresses, if the network operator questions the situation, I have seen them accept the asset sales agreements as acceptable proof of routing authority. And the addresses allocated to entity A are now in control of entity B, with bogus whois data. This is the kind of eventuality which I believe motivated the APNIC community to place the stewardship role of uniqueness above the stewardship role of needs-based transfers. Obviously I am asserting these things without documentary proof. > Again, can you cite an independently verifiable example? If not, then, I still believe this is a straw man argument. How many such agreements have you seen? (I tend to think that it represents a relatively small fraction of the address space and will likely get resolved through the current contact validation process for the most part.) >> While I don't think that's the entire argument or even a particularly accurate framing of that portion of the >> argument, I would say that the history of free markets does give one plenty to fear. Especially when you >> consider that history in situations of truly finite (even for a short time) resources. (Tulips anyone?) > > Of course we will disagree, but I see the Internet as a crucible of lassez-faire, and its manifest success resulted from those policies based in freedom and private choice. I see the internet as a crucible of community cooperation and the success of individual freedoms that results from the ability to operate a network on the basis that most people will act for the common good. As soon as you put money on the table, the common good goes out the window and you have to have regulations to mitigate the damage that will cause. > You seem to consider that needs-based allocations were some kind of social agreement preventing malfeasance of the wealthy and protecting the little guy. Indeed, i do. > In reality, it was the least rulemaking possible in an era of free-pool allocations. No, we could easily have handed addresses out for the asking without any regulation whatsoever. We, as a community chose not to. We made that choice for good reasons. I believe those reasons remain and may even be enhanced by runout. > There really was no other way to distribute scarce resources with no price unless the allocations were limited by need. Not at all true. They could have been simply handed out to whoever asked first. I agree such an approach would have been ridiculous. The difference between us is that I believe even when you include dollars in the process, such an approach remains ridiculous because it transfers the address regulation from community based stewardship to a system where the only factor determining resource allocation is the accumulation of capital. > And nobody really debates that, even an outlier like me. Interesting... I will actually debate that. I agree the alternatives were absurd. However, to claim that they did not exist would be as logical as my claiming that an unregulated market is not an option. It's an equally detrimental option, but, it's an option. > That cause goes away with the free pool, and the imperative against more rules than necessary dictates we lift those needs-based transfer rules. Indeed, we do disagree. I believe that the cause for needs-basis was the idea that the community preferred not to grant resources to entities that did not need them to the exclusion of entities that do. I see no way in which bringing money into the picture changes that reality or that community ideal. > We have to understand the cause of needs requirements. It wasn't some egalitarian ethos, it was an obvious and fair mechanism for placing some limit on address allocations from a free pool of limited size. And it still is. The source pool for IPv4 address transfers is not unlimited in size, either. > We didn't impose max limits per allocant, we didn't impose progressive fees that made larger blocks proportionally more expensive, we didn't create rules to favor corporate diversity, we didn't limit distributions per country, we didn't require an income statement of recipients so that we could judge whom to allocate to. No, we chose not to allow greedy entities to absorb more space than they needed to the exclusion of others. Your claim is that adding money to the situation somehow removes the need to do so. My argument and belief is that it does not. > We chose the most limited mechanism to ensure that the addresses were not wasted. If we understand that, and we understand that stewards make only the minimum rules necessary for order, it is easier to drop the emotional attachment to needs requirements in the face of free pool exhaust. You will note that despite my free-market inclinations, I have never argued to drop needs requirements for new allocations of IPv4 or for IPv6. My attachment to needs basis is not based in emotion. It is based in logic. You have done nothing to show that money acts as a regulator to prevent those with greater capital from absorbing addresses they do not need to the detriment of the rest of the community. In fact, you have even gone so far as to provide examples of situations where you believe such an occurrence would actually be a good thing. > I have searched long and hard for a historical analog to this situation. The best I could find was a policy of the US after the Revolutionary War, which allocated property to veterans of that war for free. You had to qualify by being a veteran, the total property available for allocation was limited in size, and the property had value. Not an accurate analogue. There was also other land available through a variety of other land grants, purchases, and even in some cases, just being the first to arrive somewhere and stake a claim. Indeed, since there was no "justified need" basis for land allocation at any point prior, the fact that things continued without it on a relatively even keel is kind of irrelevant. > All the same as our IPv4 situation. Except not. (see above). > In the historical case, there were no limits on resale of the allocated land, there were aggregators, there were speculators, and things progressed normally during the allocation time period, and the time period after the land was fully allocated. But there was nothing like needs-basis in the initial allocation and there were many other sources of land as well. This simply isn't the case with IPv4. > Some people intended to live and farm the land, others intended to sell their allocations. And American law allowed a free market in which these men could decide. > > Rather than judge the benefits of free markets by exceptions like manias and successful market cornering, both rare and shortlived events, why don't we judge free markets like our American ancestors did, even if we're Canadian, eh! So you are claiming that there were no regulations on the sale and possession of land back then? What if you were a black veteran? What if you were a woman? What if you were a native American attempting to claim your ancestral homelands? If you can point to a long-term functional completely deregulated market anywhere on the planet as an example, I'm willing to bet that would be the exception rather than the rule. Completely unregulated free markets have never functioned. All markets degrade to the point of requiring the government (or some industry organization) to step in and mitigate the issues they create. This is not the exception, it is the reality we have seen time and again. Preserving needs basis is merely a rational and good form of regulating the IPv4 transfer market to the benefit of the community. Owen From owen at delong.com Wed May 11 21:41:24 2011 From: owen at delong.com (Owen DeLong) Date: Wed, 11 May 2011 18:41:24 -0700 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate In-Reply-To: References: <7F5FC4554E42430FADDC0D376164DFA0@mike> <0BB63D56-1605-4E1E-8F0B-B2083FDE4A96@delong.com> <16AACD9632484C85BF6B855603CF07B4@mike> <59EC8A7F22F247058ED74A896F0C6978@mike> Message-ID: On May 11, 2011, at 6:20 PM, Mike Burns wrote: > Hi McTim, > > >The goals, IIRC, are uniqueness, registration and conservation. > > Uniqueness and registration are served by my proposal. > Conservation of the free pool is rapidly becoming a thing of the past, and I want to continue needs-based allocations from the free pool. > >> It just makes no sense to me to abandon a needs basis just because we >> are getting closer to the bottom of the pool. I think a needs basis >> may be even more important as the crunch comes. > > I have given reasons why I believe, along with the APNIC community, that maintaining needs requirements for transfers will cause transactions to occur and not be registered. When the crunch comes, ARIN won't be allocating anything. The only ones allocating IPv4 resource then are those whose price is met. The need the seller will be concerned with is the need to get money for addresses. The need the buyer will be concerned with is utilizing them profitably. Neither buyer nor seller will be concerned with ARIN's determination of need. If ARIN won't register the transaction due to this requirement, whois suffers. > This operates on the assertion that rDNS and RPKI are also irrelevant to the buyer which are assertions I believe to be false. >> >> I think Owen is spot on that "the risk to whois accuracy is relatively >> low and is a spectre" (although I would call it a red-herring). > > I have personally seen these kinds of transactions, and even Owen concedes they will likely happen with more frequency as we move past free pool exhaust. > Where I believe current frequency is so close to zero as to be insignificant and increased frequency will likely be a barely noticeable blip above zero. >> I also think your characterisation of ARIN actions as "shabby" is unwarranted. > > Do you honestly believe that the ARIN needs analysis of the MS/Nortel deal was fair and accurate? > If so, I can see why you would feel shabby is an unwarranted word. > I have no reason to doubt the word of John Curran and the staff of ARIN, so, yes, I am inclined to believe that the needs analysis of the deal was fair and accurate. Owen From mike at nationwideinc.com Wed May 11 21:59:40 2011 From: mike at nationwideinc.com (Mike Burns) Date: Wed, 11 May 2011 21:59:40 -0400 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate References: <7F5FC4554E42430FADDC0D376164DFA0@mike><0BB63D56-1605-4E1E-8F0B-B2083FDE4A96@delong.com><16AACD9632484C85BF6B855603CF07B4@mike><4294678C-B653-4BB3-9D40-FD935EA00CF3@eyeconomics.com> Message-ID: <3A5E9739CEA64420AB73F106A701DFEB@video> Hi John, >> To me, this means he was convinced that ARIN had no rights over >> transferring the addresses, although ARIN has rights over reflecting that >> transfer in Whois. >That's a rather interesting conclusion, as the judge actually made >no Order to that effect (or even close). Excuse me, but the judge did find that: G. The seller has the exclusive right to use the Internet numbers and the exclusive right to transfer its exclusive right to use the Internet numbers. Such exclusive rights to use and transfer, together with Seller's other legal and equitable rights in and to the Internet numbers, if any, are referred herein collectively as the "Seller's Rights". What part of exclusive right is hard to understand? If the rights were somehow circumscribed by ARIN, why continue in the altered document to use the term "exclusive rights"? >> I also argue that in the post-exhaust age, conflicts over claims to >> address rights will likely increase, putting more pressure on Whois to >> accurately represent >>reality. >ARIN will maintain the reality of the Whois in accordance to the wishes of >this community. Parties asserting that they'll deliver you some invisible >numbers for a good price are always likely to find gullible parties, but >actual transfers of entries in the registry will only occur in accordance >with community-developed policies in the region. The problem is when actual transfers of rights to use occur and ARIN doesn't reflect those in the registry. By transfers, I mean that company A sells their right to use addresses, and Company B buys them and uses them. I know that would not be a definition of transfer that you would use, as you seem to apply only the definition of a whois update to a transfer. That's what I mean by a disconnect with reality, and a penalty to whois accuracy. Regards, Mike From millnert at gmail.com Wed May 11 22:11:20 2011 From: millnert at gmail.com (Martin Millnert) Date: Wed, 11 May 2011 22:11:20 -0400 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate In-Reply-To: <907EE389FDC5448ABC46ADD06420B86D@video> References: <7F5FC4554E42430FADDC0D376164DFA0@mike> <0BB63D56-1605-4E1E-8F0B-B2083FDE4A96@delong.com> <16AACD9632484C85BF6B855603CF07B4@mike> <59EC8A7F22F247058ED74A896F0C6978@mike> <907EE389FDC5448ABC46ADD06420B86D@video> Message-ID: Hi Mike, FWIW, I share your perception of reality in many ways. John's position is perfectly fine; that a transfer inside the registry will only happen following the policies of the community. When a transfers occur outside the RIR's scope and reach, and the involved parties either: a) think involving the RIR is too much work/unnecessary or they are simply unaware of it, or, b) they fail to meet the requirements, or c) they do not think the benefits of involving the RIR outweighs the drawbacks, then, either: 1) policies (eventually) change to adjust more towards reality (if a party can get working internet w/o involving the RIR, by an ISPs free will choice to accept the addresses as legitimate theirs, they have no real reason to involve the RIR ) 2) the RIR's whois loses accuracy, 3) the RIR corrupts its practices of the community policies to avoid 2, lacking 1. This is pretty darn logical and simple IMHO. I accept that it is up to the community to discern what it wants in some kind of democratic fashion and I'm perfectly fine with the outcome of that procedure, but it is very useful for this process to have sufficient data, so to speak. Cheers, Martin On Wed, May 11, 2011 at 9:03 PM, Mike Burns wrote: > Hi Owen, > >> When you assert other such transactions, are you referring to the 10 for >> which John Curran provided anonymized >> data, or, are you asserting that there are others which have occurred >> outside of ARIN? If so, can you cite examples >> or provide any documentary proof of such a claim? > > I have personally seen many asset sale agreements which included legacy IP > addresses which were completed without notifying ARIN, as there is still no > requirement for legacy holders to do that. I have seen asset sale agreements > which include ARIN accounts and passwords among the listed assets. The > addresses change control, but whois still shows the original registrant. > When it comes time to route the addresses, if the network operator questions > the situation, I have seen them accept the asset sales agreements as > acceptable proof of routing authority. And the addresses allocated to entity > A are now in control of entity B, with bogus whois data. This is the kind of > eventuality which I believe motivated the APNIC community to place the > stewardship role of uniqueness above the stewardship role of needs-based > transfers. Obviously I am asserting these things without documentary proof. > >> While I don't think that's the entire argument or even a particularly >> accurate framing of that portion of the >> argument, I would say that the history of free markets does give one >> plenty to fear. Especially when you >> consider that history in situations of truly finite (even for a short >> time) resources. (Tulips anyone?) > > Of course we will disagree, but I see the Internet as a crucible of > lassez-faire, and its manifest success resulted from those policies based in > freedom and private choice. > You seem to consider that needs-based allocations were some kind of social > agreement preventing malfeasance of the wealthy and protecting the little > guy. > In reality, it was the least ?rulemaking possible in an era of free-pool > allocations. > There really was no other way to distribute scarce resources with no price > unless the allocations were limited by need. > And nobody really debates that, even an outlier like me. > That cause goes away with the free pool, and the imperative against more > rules than necessary dictates we lift those needs-based transfer rules. > > We have to understand the cause of needs requirements. It wasn't some > egalitarian ethos, it was an obvious and fair mechanism for placing some > limit on address allocations from a free pool of limited size. We didn't > impose max limits per allocant, we didn't impose progressive fees that made > larger blocks proportionally more expensive, we didn't create rules to favor > corporate diversity, we didn't limit distributions per country, we didn't > require an income statement of recipients so that we could judge whom to > allocate to. We chose the most limited mechanism to ensure that the > addresses were not wasted. If we understand that, and we understand that > stewards make only the minimum rules necessary for order, it is easier to > drop the emotional attachment to needs requirements in the face of free pool > exhaust. You will note that despite my free-market inclinations, I have > never argued to drop needs requirements for new allocations of IPv4 or for > IPv6. > > I have searched long and hard for a historical analog to this situation. The > best I could find was a policy of the US after the Revolutionary War, which > allocated property to veterans of that war for free. You had to qualify by > being a veteran, the total property available for allocation was limited in > size, and the property had value. All the same as our IPv4 situation. ?In > the historical case, there were no limits on resale of the allocated land, > there were aggregators, there were speculators, and things progressed > normally during the allocation time period, and the time period after the > land was fully allocated. Some people intended to live and farm the land, > others intended to sell their allocations. And American law allowed a free > market in which these men could decide. > > Rather than judge the benefits of free markets by exceptions like manias and > successful market cornering, both rare and shortlived events, why don't we > judge free markets like our American ancestors did, even if we're Canadian, > eh! > > Regards, > Mike > > _______________________________________________ > 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 11 22:16:55 2011 From: owen at delong.com (Owen DeLong) Date: Wed, 11 May 2011 19:16:55 -0700 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate In-Reply-To: <3A5E9739CEA64420AB73F106A701DFEB@video> References: <7F5FC4554E42430FADDC0D376164DFA0@mike><0BB63D56-1605-4E1E-8F0B-B2083FDE4A96@delong.com><16AACD9632484C85BF6B855603CF07B4@mike><4294678C-B653-4BB3-9D40-FD935EA00CF3@eyeconomics.com> <3A5E9739CEA64420AB73F106A701DFEB@video> Message-ID: On May 11, 2011, at 6:59 PM, Mike Burns wrote: > Hi John, > >>> To me, this means he was convinced that ARIN had no rights over transferring the addresses, although ARIN has rights over reflecting that transfer in Whois. > >> That's a rather interesting conclusion, as the judge actually made >> no Order to that effect (or even close). > > Excuse me, but the judge did find that: > > G. The seller has the exclusive right to use the Internet numbers and the exclusive right to transfer its exclusive right to use the Internet numbers. Such exclusive rights to use and transfer, together with Seller's other legal and equitable rights in and to the Internet numbers, if any, are referred herein collectively as the "Seller's Rights". > I find the idea that the seller has the exclusive right to use the numbers amusing at best. No law precludes me from using any IPv4 address I wish on any network I want. Only the social convention of the ISPs choosing to route it controls the right to use them on the more global internet. I'm simply unsure of what exclusive right to use the judge was referring to. To me, it appears to be largely a legal fiction from the word go. > What part of exclusive right is hard to understand? If the rights were somehow circumscribed by ARIN, why continue in the altered document to use the term "exclusive rights"? > Nobody other than the seller had the right to transfer their rights (such as they may have been). That's what I understand "exclusive right" to mean. ARIN has no right, per se, to transfer the resources. This does not mean that ARIN does not have the right to de-register the seller from their database, nor does it mean that ARIN does not have the right to refuse to register the buyer in their database. Neither does it mean that ARIN cannot record a different entity in their database with registration of those same numbers. The concept of rights to exclusive use of an IP address is simply and utterly absurd when you do any form of deep analysis. I find it very amusing that on one hand you want to "minimize regulation" by having ARIN remove needs-basis from the criteria by which they will recognize a transfer, yet, on the other hand you seem to like the idea of a legal precedent stating that IP address registrations in the ARIN database somehow convey a set of rights and title to some ephemeral "use" which is nowhere accurately defined. To me, such sudden creation of a variety of new "exclusive" rights (theoretically to the exclusion of the ability of others to exercise those same capabilities) would constitute a new and burdensome regulation, indeed. >>> I also argue that in the post-exhaust age, conflicts over claims to address rights will likely increase, putting more pressure on Whois to accurately represent >>reality. > >> ARIN will maintain the reality of the Whois in accordance to the wishes of >> this community. Parties asserting that they'll deliver you some invisible >> numbers for a good price are always likely to find gullible parties, but >> actual transfers of entries in the registry will only occur in accordance >> with community-developed policies in the region. > > The problem is when actual transfers of rights to use occur and ARIN doesn't reflect those in the registry. Since the "rights to use" are largely fictitious, I'm not sure how they can actually be transferred. > By transfers, I mean that company A sells their right to use addresses, and Company B buys them and uses them. How much will you give me for the number 5? Remember, if you don't pay me, you're not allowed to use 5 any more ever. Huh? We're talking about integers in the range 0-4,026,531,839 (I left out the E/F/G space). I can no more deny you the use of 3,231,648,263 for whatever purpose you wish (and yes, that is an integer registered to me in the ARIN database and advertised into global BGP as part of my network). than you can deny me my right to use it. What I can likely do is convince other ISPs not to route it to you based on the fact that I am listed in the ARIN whois record. If I found you advertising it to the internet and couldn't convince your upstream(s) to remove it, then, I might be able to convince a judge to issue an injunction that stops you from advertising it to the internet causing the moral equivalent of "harmful interference" as that term is defined by the FCC for use in parts 15 and 97 of the FCC regulations. However, I could not prevent you from using the same numbers in any other manner you saw fit, or, even on any network not advertised in a conflicting manner. > I know that would not be a definition of transfer that you would use, as you seem to apply only the definition of a whois update to a transfer. > That's what I mean by a disconnect with reality, and a penalty to whois accuracy. > I think John may not be the one disconnected from reality here. Owen From millnert at gmail.com Wed May 11 22:24:21 2011 From: millnert at gmail.com (Martin Millnert) Date: Wed, 11 May 2011 22:24:21 -0400 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate In-Reply-To: <4B99E603-7892-433A-9FB9-DB9A08D98F39@delong.com> References: <7F5FC4554E42430FADDC0D376164DFA0@mike> <0BB63D56-1605-4E1E-8F0B-B2083FDE4A96@delong.com> <16AACD9632484C85BF6B855603CF07B4@mike> <59EC8A7F22F247058ED74A896F0C6978@mike> <907EE389FDC5448ABC46ADD06420B86D@video> <4B99E603-7892-433A-9FB9-DB9A08D98F39@delong.com> Message-ID: Owen, On Wed, May 11, 2011 at 9:37 PM, Owen DeLong wrote: > Indeed, we do disagree. I believe that the cause for needs-basis was the idea that the community > preferred not to grant resources to entities that did not need them to the exclusion of entities that > do. I see no way in which bringing money into the picture changes that reality or that community > ideal. Two networks, for the sake of argument: - A has 253 hosts and a router, they need a /24 to connect this to the v4 Internet, and they have such an allocation from ARIN for the sake of argument. They don't have a lot of money and would be pretty OK with IPv6, but do like to access the IPv4 internet. - B has also 253 hosts and a router and a really big desire to access the IPv4 internet for some great reason and purpose, much bigger and more valid reason than A in most peoples eyes including their own and they have lots of money. They do not have any IPv4 addresses. ARIN has no free addresses to give out. You cannot use money. What is a good solution to this situation according to you? Now, you can use money: Do you see any different solution now? Regards, Martin From owen at delong.com Wed May 11 22:23:18 2011 From: owen at delong.com (Owen DeLong) Date: Wed, 11 May 2011 19:23:18 -0700 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate In-Reply-To: References: <7F5FC4554E42430FADDC0D376164DFA0@mike> <0BB63D56-1605-4E1E-8F0B-B2083FDE4A96@delong.com> <16AACD9632484C85BF6B855603CF07B4@mike> <59EC8A7F22F247058ED74A896F0C6978@mike> <907EE389FDC5448ABC46ADD06420B86D@video> Message-ID: On May 11, 2011, at 7:11 PM, Martin Millnert wrote: > Hi Mike, > > FWIW, I share your perception of reality in many ways. > > John's position is perfectly fine; that a transfer inside the registry > will only happen following the policies of the community. > > When a transfers occur outside the RIR's scope and reach, and the > involved parties either: > a) think involving the RIR is too much work/unnecessary or they are > simply unaware of it, or, > b) they fail to meet the requirements, or > c) they do not think the benefits of involving the RIR outweighs the drawbacks, > > then, either: > > 1) policies (eventually) change to adjust more towards reality (if a > party can get working internet w/o involving the RIR, by an ISPs free > will choice to accept the addresses as legitimate theirs, they have no > real reason to involve the RIR ) > 2) the RIR's whois loses accuracy, > 3) the RIR corrupts its practices of the community policies to avoid > 2, lacking 1. > You left out: 4) The RIR eventually identifies these outliers and reclaims the numbers to be reissued to members of the community willing to comply with policy. 5) The community directs the RIRs to take some more aggressive action with respect to these outliers. > This is pretty darn logical and simple IMHO. > > I accept that it is up to the community to discern what it wants in > some kind of democratic fashion and I'm perfectly fine with the > outcome of that procedure, but it is very useful for this process to > have sufficient data, so to speak. > Agreed. Owen > Cheers, > Martin > > On Wed, May 11, 2011 at 9:03 PM, Mike Burns wrote: >> Hi Owen, >> >>> When you assert other such transactions, are you referring to the 10 for >>> which John Curran provided anonymized >>> data, or, are you asserting that there are others which have occurred >>> outside of ARIN? If so, can you cite examples >>> or provide any documentary proof of such a claim? >> >> I have personally seen many asset sale agreements which included legacy IP >> addresses which were completed without notifying ARIN, as there is still no >> requirement for legacy holders to do that. I have seen asset sale agreements >> which include ARIN accounts and passwords among the listed assets. The >> addresses change control, but whois still shows the original registrant. >> When it comes time to route the addresses, if the network operator questions >> the situation, I have seen them accept the asset sales agreements as >> acceptable proof of routing authority. And the addresses allocated to entity >> A are now in control of entity B, with bogus whois data. This is the kind of >> eventuality which I believe motivated the APNIC community to place the >> stewardship role of uniqueness above the stewardship role of needs-based >> transfers. Obviously I am asserting these things without documentary proof. >> >>> While I don't think that's the entire argument or even a particularly >>> accurate framing of that portion of the >>> argument, I would say that the history of free markets does give one >>> plenty to fear. Especially when you >>> consider that history in situations of truly finite (even for a short >>> time) resources. (Tulips anyone?) >> >> Of course we will disagree, but I see the Internet as a crucible of >> lassez-faire, and its manifest success resulted from those policies based in >> freedom and private choice. >> You seem to consider that needs-based allocations were some kind of social >> agreement preventing malfeasance of the wealthy and protecting the little >> guy. >> In reality, it was the least rulemaking possible in an era of free-pool >> allocations. >> There really was no other way to distribute scarce resources with no price >> unless the allocations were limited by need. >> And nobody really debates that, even an outlier like me. >> That cause goes away with the free pool, and the imperative against more >> rules than necessary dictates we lift those needs-based transfer rules. >> >> We have to understand the cause of needs requirements. It wasn't some >> egalitarian ethos, it was an obvious and fair mechanism for placing some >> limit on address allocations from a free pool of limited size. We didn't >> impose max limits per allocant, we didn't impose progressive fees that made >> larger blocks proportionally more expensive, we didn't create rules to favor >> corporate diversity, we didn't limit distributions per country, we didn't >> require an income statement of recipients so that we could judge whom to >> allocate to. We chose the most limited mechanism to ensure that the >> addresses were not wasted. If we understand that, and we understand that >> stewards make only the minimum rules necessary for order, it is easier to >> drop the emotional attachment to needs requirements in the face of free pool >> exhaust. You will note that despite my free-market inclinations, I have >> never argued to drop needs requirements for new allocations of IPv4 or for >> IPv6. >> >> I have searched long and hard for a historical analog to this situation. The >> best I could find was a policy of the US after the Revolutionary War, which >> allocated property to veterans of that war for free. You had to qualify by >> being a veteran, the total property available for allocation was limited in >> size, and the property had value. All the same as our IPv4 situation. In >> the historical case, there were no limits on resale of the allocated land, >> there were aggregators, there were speculators, and things progressed >> normally during the allocation time period, and the time period after the >> land was fully allocated. Some people intended to live and farm the land, >> others intended to sell their allocations. And American law allowed a free >> market in which these men could decide. >> >> Rather than judge the benefits of free markets by exceptions like manias and >> successful market cornering, both rare and shortlived events, why don't we >> judge free markets like our American ancestors did, even if we're Canadian, >> eh! >> >> Regards, >> Mike >> >> _______________________________________________ >> 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 11 22:31:08 2011 From: jcurran at arin.net (John Curran) Date: Thu, 12 May 2011 02:31:08 +0000 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate In-Reply-To: <4B99E603-7892-433A-9FB9-DB9A08D98F39@delong.com> References: <7F5FC4554E42430FADDC0D376164DFA0@mike> <0BB63D56-1605-4E1E-8F0B-B2083FDE4A96@delong.com> <16AACD9632484C85BF6B855603CF07B4@mike> <59EC8A7F22F247058ED74A896F0C6978@mike> <907EE389FDC5448ABC46ADD06420B86D@video> <4B99E603-7892-433A-9FB9-DB9A08D98F39@delong.com> Message-ID: On May 11, 2011, at 6:37 PM, Owen DeLong wrote: > There is no reason that ARIN, upon conducting a section 12 review and finding that the original holder was > no longer using the resources and/or was defunct could not reclaim those resources, so, the recipient in that > case is taking a rather large risk. I do not believe ARIN will view the asset sale agreement as legitimizing > the transfer and the community developed policies support reclamation of resources from defunct legacy > holders. ARIN has reclaimed such resources in the past, though I do not know if they have reclaimed them > from organizations who believe they were able to "purchase" them as part of some form of asset transfer. We have not done so to date (as far as I am aware, and I would have very likely have been made aware of any action to do so) We have reclaimed in cases where parties have asserted that they have the right to use specific resources due to merger or acquisition, could not produce any paperwork, and then the original address holder turned out to be defunct or denied that any transfer was intended. These cases almost always involve recipient parties that then quickly disappear rather than further pursue the matter, and similar indications of hijack attempts. While I recognize that ARIN could theoretically reclaim address space from a defunct legacy address holder where the successor organization simply does not wish to update their records per M&A transfers (NRPM 8.2), that course of action appears to me to be more punitive than actually advancing the mission of the organization. The record keeping subsequent to an merger/acquisition often does not get cleaned up for several years subsequent to the actual event, and first we would need to set a realistic community shared expectation regarding how much time is to be allowed for record updating, and the appropriate intermediate steps along the path between "please come in and update your records" and "we have reclaimed the number resources that you thought were assigned to you" By no means is this an encouragement for folks post-merger to skip updating their records at ARIN, but simply pointing out that we would need to have some compelling community guidance before changing the existing practices in this area. We are seeing more 8.2 updates as a result of folks realizing the importance of their number resources, and some as a result of interest in performing transfers, and this is definitely a step in the right direction for improving registry accuracy. Creating a potential risk that ARIN would decide instead to reclaim resources from part M&A activity would more likely to inhibit rather than encourage updates. FYI, /John John Curran President and CEO ARIN From jcurran at arin.net Wed May 11 22:34:41 2011 From: jcurran at arin.net (John Curran) Date: Thu, 12 May 2011 02:34:41 +0000 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate In-Reply-To: <3A5E9739CEA64420AB73F106A701DFEB@video> References: <7F5FC4554E42430FADDC0D376164DFA0@mike> <0BB63D56-1605-4E1E-8F0B-B2083FDE4A96@delong.com> <"BANLkTinTJfYH5sOuqpbiLreMzW3 dH0Ozgg"@mail.gmail.com> <16AACD9632484C85BF6B855603CF07B4@mike> <4294678C-B653-4BB3-9D40-FD935EA00CF3@eyeconomics.com> <"BE8988B2F6 C44DF48FA46C8FD6D0EB27"@mike> <3A5E9739CEA64420AB73F106A701DFEB@video> Message-ID: <3094DA7F-A84F-4934-B8DF-A55D50C0BEC9@arin.net> On May 11, 2011, at 6:59 PM, Mike Burns wrote: > G. The seller has the exclusive right to use the Internet numbers and the exclusive right to transfer its exclusive right to use the Internet numbers. Such exclusive rights to use and transfer, together with Seller's other legal and equitable rights in and to the Internet numbers, if any, are referred herein collectively as the "Seller's Rights". > > What part of exclusive right is hard to understand? If the rights were somehow circumscribed by ARIN, why continue in the altered document to use the term "exclusive rights"? An exclusive right *to use* precludes someone else's *use*, but does not imply that there are not parties with other rights to the same resource. For example, the right to see specific data of the registrant for network operations purposes. As I noted earlier, the rights that are applicable to all registry entries are subject to the community-developed policies in the region. In fact, the judge did explicitly note something very similar in the Order: "For the avoidance of doubt, this Order shall not affect the LRSA and the Purchaser?s rights in the Internet Numbers transferred pursuant to this Order shall be subject to the terms of the LRSA." Thanks for asking, though, I probably should have made this clearer in my original reply. > The problem is when actual transfers of rights to use occur and ARIN doesn't reflect those in the registry. Transfers occur when ARIN approves them in accordance to community policy. > By transfers, I mean that company A sells their right to use addresses, and Company B buys them and uses them. > I know that would not be a definition of transfer that you would use, as you seem to apply only the definition of a whois update to a transfer. > That's what I mean by a disconnect with reality, and a penalty to whois accuracy. Actually, whois is remarkably accurate in such cases. It shows the resource holder as defined by policies of this community. FYI, /John John Curran President and CEO ARIN From mike at nationwideinc.com Wed May 11 22:41:10 2011 From: mike at nationwideinc.com (Mike Burns) Date: Wed, 11 May 2011 22:41:10 -0400 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate References: <7F5FC4554E42430FADDC0D376164DFA0@mike> <0BB63D56-1605-4E1E-8F0B-B2083FDE4A96@delong.com> <16AACD9632484C85BF6B855603CF07B4@mike> <59EC8A7F22F247058ED74A896F0C6978@mike> <907EE389FDC5448ABC46ADD06420B86D@video> <4B99E603-7892-433A-9FB9-DB9A08D98F39@delong.com> Message-ID: <599AC4287E79403D939568C89EB40922@video> Hi Owen > >> I have personally seen many asset sale agreements which included legacy >> IP addresses which were completed without notifying ARIN, as there is >> still no >>requirement for legacy holders to do that. I have seen asset >> sale agreements which include ARIN accounts and passwords among the >> listed assets. The >>addresses change control, but whois still shows the >> original registrant. >There is no reason that ARIN, upon conducting a section 12 review and >finding that the original holder was >no longer using the resources and/or was defunct could not reclaim those >resources, so, the recipient in that >case is taking a rather large risk. Wrong, may I quote NRPM 12.8? This policy does not create any additional authority for ARIN to revoke legacy address space. > I do not believe ARIN will view the asset sale agreement as legitimizing >the transfer and the community developed policies support reclamation of >resources from defunct legacy >holders. I never said they were defunct, they may have simply been acquired. >> When it comes time to route the addresses, if the network operator >> questions the situation, I have seen them accept the asset sales >> agreements as acceptable >>proof of routing authority. And the addresses >> allocated to entity A are now in control of entity B, with bogus whois >> data. This is the kind of eventuality which I >>believe motivated the >> APNIC community to place the stewardship role of uniqueness above the >> stewardship role of needs-based transfers. Obviously I am >>asserting >> these things without documentary proof. > >Again, can you cite an independently verifiable example? If not, then, I >still believe this is a straw man argument. >How many such agreements have you seen? (I tend to think that it represents >a relatively small fraction of >the address space and will likely get resolved through the current contact >validation process for the most >part.) Owen, if it were just Mike Burns saying this, would APNIC have changed their policies? Yes, the agreements I have seen represent a small fraction of the address space. No, I can not cite an independently verifiable example, I hoped by now you would have thought higher of my intelligence. >> While I don't think that's the entire argument or even a particularly >> accurate framing of that portion of the >> argument, I would say that the history of free markets does give one >> plenty to fear. Especially when you >> consider that history in situations of truly finite (even for a short >> time) resources. (Tulips anyone?) > > > You seem to consider that needs-based allocations were some kind of > > social agreement preventing malfeasance of the wealthy and protecting > > the little guy. Indeed, i do. >> In reality, it was the least rulemaking possible in an era of free-pool >> allocations. >No, we could easily have handed addresses out for the asking without any >regulation whatsoever. >We, as a community chose not to. We made that choice for good reasons. I >believe those reasons >remain and may even be enhanced by runout. C'mon Owen! Who could possibly believe what you are saying here? Of course there were good reasons for not handing them out without any regulation whatsoever. I have expressed over and over that nobody has ever supported that notion, to my knowledge. Needs assessment was a noble and valid means of stewarding addresses into productive use. >> There really was no other way to distribute scarce resources with no >> price unless the allocations were limited by need. >Not at all true. They could have been simply handed out to whoever asked >first. I agree such an >approach would have been ridiculous. The difference between us is that I >believe even when you >include dollars in the process, such an approach remains ridiculous because >it transfers the >address regulation from community based stewardship to a system where the >only factor >determining resource allocation is the accumulation of capital. Owen, like it or not, dollars are going to be involved in the process of address transfers. That is not at issue here. Thanks for agreeing that your proposed alternate mechanism for allocation from the free pool is ridiculous, it should be a short step from there towards acknowledging that the needs requirement was the lightest touch of a proper steward allocating from the free pool. >> And nobody really debates that, even an outlier like me. >Interesting... I will actually debate that. I agree the alternatives were >absurd. However, to claim that >they did not exist would be as logical as my claiming that an unregulated >market is not an option. >It's an equally detrimental option, but, it's an option. Would you at least admit that there was no other option if we wished to be proper stewards, both ensuring productive use and making the minimum of rules to allow for that? >> That cause goes away with the free pool, and the imperative against more >> rules than necessary dictates we lift those needs-based transfer rules. >Indeed, we do disagree. I believe that the cause for needs-basis was the >idea that the community >preferred not to grant resources to entities that did not need them to the >exclusion of entities that >do. No, I think we agree. At least I agree with your last statement, if we limit it to the free pool, which was the context. >I see no way in which bringing money into the picture changes that reality >or that community ideal. Owen, you are conflating issues. Money is coming into the picture regardless of needs requirements. >> We have to understand the cause of needs requirements. It wasn't some >> egalitarian ethos, it was an obvious and fair mechanism for placing some >> limit on >>address allocations from a free pool of limited size. >And it still is. The source pool for IPv4 address transfers is not >unlimited in size, either. No, it is not unlimited, but now we have price to ensure productive use, something we did not have when allocating from the free pool, so we chose the least intrusive mechanism to ensure that at the time, which was needs requirements. Now we have no free pool and the mechanisms of supply and demand to ensure productive use. I agree that needs requirements be continued on free pool allocations. > We didn't impose max limits per allocant, we didn't impose progressive > fees that made larger blocks proportionally more expensive, we didn't > create rules to >favor corporate diversity, we didn't limit distributions > per country, we didn't require an income statement of recipients so that > we could judge whom to allocate to. >No, we chose not to allow greedy entities to absorb more space than they >needed >to the exclusion of others. Your claim is that adding money to the >situation somehow >removes the need to do so. My argument and belief is that it does not. Again, Owen, this is not about money. Money is going to be part of all transfers. This is about maintaing a needs requirement. >> We chose the most limited mechanism to ensure that the addresses were not >> wasted. If we understand that, and we understand that stewards make only >> the >>minimum rules necessary for order, it is easier to drop the >> emotional attachment to needs requirements in the face of free pool >> exhaust. You will note that despite >>my free-market inclinations, I have >> never argued to drop needs requirements for new allocations of IPv4 or >> for IPv6. >My attachment to needs basis is not based in emotion. It is based in logic. >You have >done nothing to show that money acts as a regulator to prevent those with >greater >capital from absorbing addresses they do not need to the detriment of the >rest >of the community. In fact, you have even gone so far as to provide examples >of >situations where you believe such an occurrence would actually be a good >thing. Yes, I gave several examples of where transactions which might be profitably engaged in but which would not meet ARIN's needs policies. These are the kinds of transactions which will likely occur outside ARIN's purview and would cost Whois accuracy. >> I have searched long and hard for a historical analog to this situation. >> The best I could find was a policy of the US after the Revolutionary War, >> which allocated >>property to veterans of that war for free. You had to >> qualify by being a veteran, the total property available for allocation >> was limited in size, and the property >>had value. >Not an accurate analogue. There was also other land available through a >variety >of other land grants, purchases, and even in some cases, just being the >first to >arrive somewhere and stake a claim. >Indeed, since there was no "justified need" basis for land allocation at >any point >prior, the fact that things continued without it on a relatively even keel >is kind >of irrelevant. The justification was that you had to be a veteran who fought in the Revolutionary War. There ARE other addresses available, I have heard that you are aware of IPv6. > In the historical case, there were no limits on resale of the allocated > land, there were aggregators, there were speculators, and things > progressed normally during ?>the allocation time period, and the time > period after the land was fully allocated. >But there was nothing like needs-basis in the initial allocation and there >were >many other sources of land as well. This simply isn't the case with IPv4. There was something like needs-basis. You needed to demonstrate that you were a veteran. Land was not handed out to just anybody. (Remember, this land had value.) Sure you could move somewhere else and purchase land, like you can choose to deploy IPv6 or CGN. >> Some people intended to live and farm the land, others intended to sell >> their allocations. And American law allowed a free market in which these >> men could decide. > >> Rather than judge the benefits of free markets by exceptions like manias >> and successful market cornering, both rare and shortlived events, why >> don't we judge >>free markets like our American ancestors did, even if >> we're Canadian, eh! >Completely unregulated free markets have never functioned. All markets >degrade to the point of requiring the government (or some industry >organization) to step in and mitigate the issues they create. This is >not the exception, it is the reality we have seen time and again. >Preserving needs basis is merely a rational and good form of regulating >the IPv4 transfer market to the benefit of the community. What is the great benefit that outweighs the danger to Whois of unbooked transfers and the benefits of incentivizing legacy resources to come under RSA? Who says my proposal would result in completely unregulated markets? Every transferee would sign an RSA and be subject to ARIN policy. And with my policy or without my policy, addresses are bound to flow to the highest bidder. If the policy proposal doesn't fly, it will be to the highest bidder who can show need. Do you think that we should take more steps to protect the little guy in this event? Maybe a price cap? An address czar? Regards, Mike From millnert at gmail.com Wed May 11 22:41:25 2011 From: millnert at gmail.com (Martin Millnert) Date: Wed, 11 May 2011 22:41:25 -0400 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate In-Reply-To: References: <7F5FC4554E42430FADDC0D376164DFA0@mike> <0BB63D56-1605-4E1E-8F0B-B2083FDE4A96@delong.com> <16AACD9632484C85BF6B855603CF07B4@mike> <59EC8A7F22F247058ED74A896F0C6978@mike> <907EE389FDC5448ABC46ADD06420B86D@video> Message-ID: Owen, On Wed, May 11, 2011 at 10:23 PM, Owen DeLong wrote: >>> then, either: >> >> 1) policies (eventually) change to adjust more towards reality (if a >> party can get working internet w/o involving the RIR, by an ISPs free >> will choice to accept the addresses as legitimate theirs, they have no >> real reason to involve the RIR ) >> 2) the RIR's whois loses accuracy, >> 3) the RIR corrupts its practices of the community policies to avoid >> 2, lacking 1. >> > You left out: > > 4) The RIR eventually identifies these outliers and reclaims the numbers > to be reissued to members of the community willing to comply with policy. Well, you'd potentially destroy uniqueness if the other party and its ISPs disagrees and continues to use the addresses. > 5) The community directs the RIRs to take some more aggressive action > with respect to these outliers. It's just bits, numbers, and you said yourself you are free to configure whatever bits you want wherever you want. See above. Cheers, Martin From jcurran at arin.net Wed May 11 22:45:17 2011 From: jcurran at arin.net (John Curran) Date: Thu, 12 May 2011 02:45:17 +0000 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate In-Reply-To: References: <7F5FC4554E42430FADDC0D376164DFA0@mike><0BB63D56-1605-4E1E-8F0B-B2083FDE4A96@delong.com><16AACD9632484C85BF6B855603CF07B4@mike><4294678C-B653-4BB3-9D40-FD935EA00CF3@eyeconomics.com> <3A5E9739CEA64420AB73F106A701DFEB@video> Message-ID: <6C6CDBC0-01AD-4BEA-B816-6B27222C44D6@arin.net> On May 11, 2011, at 7:16 PM, Owen DeLong wrote: > I'm simply unsure of what exclusive right to use the judge was referring to. To me, it > appears to be largely a legal fiction from the word go. If you consider that only a single party can "use" those specific number resources in the ARIN Whois database, it might help in considering the language. (I believe that it would be extremely ambitious to attempt to consider "exclusive use" in the Order to apply to the configuration of any devices in the global Internet... :-) FYI, /John John Curran President and CEO ARIN From mike at nationwideinc.com Wed May 11 22:46:20 2011 From: mike at nationwideinc.com (Mike Burns) Date: Wed, 11 May 2011 22:46:20 -0400 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate References: <7F5FC4554E42430FADDC0D376164DFA0@mike><0BB63D56-1605-4E1E-8F0B-B2083FDE4A96@delong.com><16AACD9632484C85BF6B855603CF07B4@mike><4294678C-B653-4BB3-9D40-FD935EA00CF3@eyeconomics.com> <3A5E9739CEA64420AB73F106A701DFEB@video> Message-ID: <0835C54BD358411A849B29E1244B07E1@video> Owen, The discourse below belongs in 2009. Events have moved beyond your decisions about what is legal fiction and what is legal fact. You can question the intelligence or judgement of the bankruptcy judge, but not his power or authority. Regards, Mike ----- Original Message ----- From: "Owen DeLong" To: "Mike Burns" Cc: "John Curran" ; Sent: Wednesday, May 11, 2011 10:16 PM Subject: Re: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate On May 11, 2011, at 6:59 PM, Mike Burns wrote: > Hi John, > >>> To me, this means he was convinced that ARIN had no rights over >>> transferring the addresses, although ARIN has rights over reflecting >>> that transfer in Whois. > >> That's a rather interesting conclusion, as the judge actually made >> no Order to that effect (or even close). > > Excuse me, but the judge did find that: > > G. The seller has the exclusive right to use the Internet numbers and the > exclusive right to transfer its exclusive right to use the Internet > numbers. Such exclusive rights to use and transfer, together with Seller's > other legal and equitable rights in and to the Internet numbers, if any, > are referred herein collectively as the "Seller's Rights". > I find the idea that the seller has the exclusive right to use the numbers amusing at best. No law precludes me from using any IPv4 address I wish on any network I want. Only the social convention of the ISPs choosing to route it controls the right to use them on the more global internet. I'm simply unsure of what exclusive right to use the judge was referring to. To me, it appears to be largely a legal fiction from the word go. > What part of exclusive right is hard to understand? If the rights were > somehow circumscribed by ARIN, why continue in the altered document to use > the term "exclusive rights"? > Nobody other than the seller had the right to transfer their rights (such as they may have been). That's what I understand "exclusive right" to mean. ARIN has no right, per se, to transfer the resources. This does not mean that ARIN does not have the right to de-register the seller from their database, nor does it mean that ARIN does not have the right to refuse to register the buyer in their database. Neither does it mean that ARIN cannot record a different entity in their database with registration of those same numbers. The concept of rights to exclusive use of an IP address is simply and utterly absurd when you do any form of deep analysis. I find it very amusing that on one hand you want to "minimize regulation" by having ARIN remove needs-basis from the criteria by which they will recognize a transfer, yet, on the other hand you seem to like the idea of a legal precedent stating that IP address registrations in the ARIN database somehow convey a set of rights and title to some ephemeral "use" which is nowhere accurately defined. To me, such sudden creation of a variety of new "exclusive" rights (theoretically to the exclusion of the ability of others to exercise those same capabilities) would constitute a new and burdensome regulation, indeed. >>> I also argue that in the post-exhaust age, conflicts over claims to >>> address rights will likely increase, putting more pressure on Whois to >>> accurately represent >>reality. > >> ARIN will maintain the reality of the Whois in accordance to the wishes >> of >> this community. Parties asserting that they'll deliver you some >> invisible >> numbers for a good price are always likely to find gullible parties, but >> actual transfers of entries in the registry will only occur in accordance >> with community-developed policies in the region. > > The problem is when actual transfers of rights to use occur and ARIN > doesn't reflect those in the registry. Since the "rights to use" are largely fictitious, I'm not sure how they can actually be transferred. > By transfers, I mean that company A sells their right to use addresses, > and Company B buys them and uses them. How much will you give me for the number 5? Remember, if you don't pay me, you're not allowed to use 5 any more ever. Huh? We're talking about integers in the range 0-4,026,531,839 (I left out the E/F/G space). I can no more deny you the use of 3,231,648,263 for whatever purpose you wish (and yes, that is an integer registered to me in the ARIN database and advertised into global BGP as part of my network). than you can deny me my right to use it. What I can likely do is convince other ISPs not to route it to you based on the fact that I am listed in the ARIN whois record. If I found you advertising it to the internet and couldn't convince your upstream(s) to remove it, then, I might be able to convince a judge to issue an injunction that stops you from advertising it to the internet causing the moral equivalent of "harmful interference" as that term is defined by the FCC for use in parts 15 and 97 of the FCC regulations. However, I could not prevent you from using the same numbers in any other manner you saw fit, or, even on any network not advertised in a conflicting manner. > I know that would not be a definition of transfer that you would use, as > you seem to apply only the definition of a whois update to a transfer. > That's what I mean by a disconnect with reality, and a penalty to whois > accuracy. > I think John may not be the one disconnected from reality here. Owen From ikiris at gmail.com Wed May 11 22:53:18 2011 From: ikiris at gmail.com (Blake Dunlap) Date: Wed, 11 May 2011 21:53:18 -0500 Subject: [arin-ppml] Fwd: IPv4 Transfer Policy Change to Keep Whois Accurate In-Reply-To: References: <1110511185755.1397B-100000@Ives.egh.com> <506717DE-3D07-447E-8768-34D86BCB24FE@delong.com> Message-ID: Mistakenly replied to Owen instead of list, at least according to Gmail, I apologize if this is a double post. -Blake ---------- Forwarded message ---------- From: Blake Dunlap Date: Wed, May 11, 2011 at 21:17 Subject: Re: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate To: Owen DeLong On Wed, May 11, 2011 at 19:01, Owen DeLong wrote: > Care to provide some guidance as to what you would consider acceptable? > Personally, I believe > that 2009-1 as it is is a little too open, but, I am interested in opinions > from the community. > The following assumes that holders of legacy space are willing to ceed a minor couple of footnotes in return for proposed changes. Lets go at this just thinking of ARIN space for now, and assume all applicable legacy space would fall to ARIN. - Have ARIN instead of the current listing service, operate effectively a public price viewable bazaar for all listed blocks, and their child blocks, down to /24. - All legacy etc holders may now sign a LRSA (which should be modified as well if this is enacted to allow the following) and provided the following terms are followed, be free of any threat of audit for needs based justification on their existing space, as long as they immediently shift to the bazaar system outlined below. - Any entity wishing to list space for sale on the bazaar, may do so, but understand they are restricting themselves from ever receiving free pool space again, not based on time period, but ever. Effectively you can pick and choose, stay in the free pool system, or switch over to the publicly traded internet where you can buy and sell space as you please subject to the following - Any actual space initially not listed for sale or purchased, must pass current needs based justification audit, although I would suggest slightly modifying it as such, to allow down to minimum /24s for all parties, so long as all attempts are made at aggregation (or at least, something like this). This does a couple of things, that so far the proposals I have seen do not. Primarily of which, they remove the issue that many legacy owners have (myself included), such as the property rights, disputed as they are, or at least the main benefit gained from them, which is the value of the block. The main issue I have with the above plan, is I am not sure of a good system for the actual costs, both of the IP blocks themselves, whether to allow sellers to have full control or any, or what transfer fees ARIN should extract in the process. As for router prefix space, yes its going to happen anyway, might as well get used to it. IPv4 is going to explode very quickly. Personally I'm willing to bet the first real kick in the teeth impetus to go to 6 is not the lack of addresses, its the lack of routability as providers accept less and less 4 prefixes. I'll even put $20 up to this assertion most likely if people ask individually for a wager. Thoughts? -Blake -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcurran at arin.net Wed May 11 22:53:47 2011 From: jcurran at arin.net (John Curran) Date: Thu, 12 May 2011 02:53:47 +0000 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate In-Reply-To: <599AC4287E79403D939568C89EB40922@video> References: <7F5FC4554E42430FADDC0D376164DFA0@mike> <0BB63D56-1605-4E1E-8F0B-B2083FDE4A96@delong.com> <16AACD9632484C85BF6B855603CF07B4@mike> <59EC8A7F22F247058ED74A896F0C6978@mike> <907EE389FDC5448ABC46ADD06420B86D@video> <4B99E603-7892-433A-9FB9-DB9A08D98F39@delong.com> <599AC4287E79403D939568C89EB40922@video> Message-ID: On May 11, 2011, at 7:41 PM, Mike Burns wrote: > > Wrong, may I quote NRPM 12.8? > This policy does not create any additional authority for ARIN to revoke legacy address space. Mike - Alas, that language quite intentionally serves only to make clear that the community was not attempting to create such authority, and to do so without precluding the potential that such authority was already in existence. FYI, /John John Curran President and CEO ARIN From mike at nationwideinc.com Wed May 11 22:55:09 2011 From: mike at nationwideinc.com (Mike Burns) Date: Wed, 11 May 2011 22:55:09 -0400 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate References: <7F5FC4554E42430FADDC0D376164DFA0@mike><0BB63D56-1605-4E1E-8F0B-B2083FDE4A96@delong.com><"BANLkTinTJfYH5sOuqpbiLreMzW3 dH0Ozgg"@mail.gmail.com><16AACD9632484C85BF6B855603CF07B4@mike><4294678C-B653-4BB3-9D40-FD935EA00CF3@eyeconomics.com> <"BE8988B2F6C44DF48FA46C8FD6D0EB27"@mike><3A5E9739CEA64420AB73F106A701DFEB@video > <3094DA7F-A84F-4934-B8DF-A55D50C0BEC9@arin.net> Message-ID: <3278649C0D594E59B6F4EDD830C34C2D@video> Hi John, >> By transfers, I mean that company A sells their right to use addresses, >> and Company B buys them and uses them. >> I know that would not be a definition of transfer that you would use, as >> you seem to apply only the definition of a whois update to a transfer. >> That's what I mean by a disconnect with reality, and a penalty to whois >> accuracy. >Actually, whois is remarkably accurate in such cases. It shows the resource >holder as defined by policies of this community. Just not the resource holder who is actually using the addresses. If that constitutes whois accuracy, then I guess those APNIC stewards are very confused. Thanks for the info on the 8.2 transfers and the increase in their number as the value of addresses begins to be realized. And the correct reclamations for undocumented claims of merger. If they are undocumented, they are hijacked addresses, to my mind. Regards, Mike From fernattj at gmail.com Wed May 11 22:55:47 2011 From: fernattj at gmail.com (Jonathan Fernatt) Date: Wed, 11 May 2011 22:55:47 -0400 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate In-Reply-To: <599AC4287E79403D939568C89EB40922@video> References: <7F5FC4554E42430FADDC0D376164DFA0@mike> <0BB63D56-1605-4E1E-8F0B-B2083FDE4A96@delong.com> <16AACD9632484C85BF6B855603CF07B4@mike> <59EC8A7F22F247058ED74A896F0C6978@mike> <907EE389FDC5448ABC46ADD06420B86D@video> <4B99E603-7892-433A-9FB9-DB9A08D98F39@delong.com> <599AC4287E79403D939568C89EB40922@video> Message-ID: > > > What is the great benefit that outweighs the danger to Whois of unbooked > transfers and the benefits of incentivizing legacy resources to come under > RSA? > Who says my proposal would result in completely unregulated markets? Every > transferee would sign an RSA and be subject to ARIN policy. > And with my policy or without my policy, addresses are bound to flow to the > highest bidder. > If the policy proposal doesn't fly, it will be to the highest bidder who > can show need. > Do you think that we should take more steps to protect the little guy in > this event? > Maybe a price cap? An address czar? > I keep seeing seeing this argument from you Mike. I honestly can't understand why you think the needs requirement is such an obstacle for a company with a legitimate need for addresses that they would have to avoid ARIN altogether. Following that same train of thought, wouldn't it be easier for a company who didn't care about the process or being honest to just falsify their needs justification? I deal with tiny tiny tiny companies who have had no problem whatsoever showing need for resources. ARIN staff and policy have always seemed very accommodating from my perspective. Have you had a different experience? Jon -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthew at matthew.at Wed May 11 22:59:58 2011 From: matthew at matthew.at (Matthew Kaufman) Date: Wed, 11 May 2011 19:59:58 -0700 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate In-Reply-To: References: <7F5FC4554E42430FADDC0D376164DFA0@mike> <0BB63D56-1605-4E1E-8F0B-B2083FDE4A96@delong.com> <16AACD9632484C85BF6B855603CF07B4@mike> <59EC8A7F22F247058ED74A896F0C6978@mike> <907EE389FDC5448ABC46ADD06420B86D@video> <4B99E603-7892-433A-9FB9-DB9A08D98F39@delong.com> <599AC4287E79403D939568C89EB40922@video> Message-ID: <4DCB4D2E.8060301@matthew.at> On 5/11/2011 7:55 PM, Jonathan Fernatt wrote: > > I keep seeing seeing this argument from you Mike. I honestly can't > understand why you think the needs requirement is such an obstacle for > a company with a legitimate need for addresses that they would have to > avoid ARIN altogether. My issue with the needs requirement post-runout is that the 3-month rules are still in effect for new and recent entrants... this means that no matter how hard it is to locate a block that's for sale and successfully bid for one, you're only able to get 3 months worth of space unless you've had space for at least a year. The original argument that it just requires filing some paperwork every 3 months to continue justifying additional space no longer works when it isn't just filing some paperwork to get space from a free pool any more. I have several policy proposals pending that attempt to fix this. Matthew Kaufman From millnert at gmail.com Wed May 11 23:03:18 2011 From: millnert at gmail.com (Martin Millnert) Date: Wed, 11 May 2011 23:03:18 -0400 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate In-Reply-To: <4DCB4D2E.8060301@matthew.at> References: <7F5FC4554E42430FADDC0D376164DFA0@mike> <0BB63D56-1605-4E1E-8F0B-B2083FDE4A96@delong.com> <16AACD9632484C85BF6B855603CF07B4@mike> <59EC8A7F22F247058ED74A896F0C6978@mike> <907EE389FDC5448ABC46ADD06420B86D@video> <4B99E603-7892-433A-9FB9-DB9A08D98F39@delong.com> <599AC4287E79403D939568C89EB40922@video> <4DCB4D2E.8060301@matthew.at> Message-ID: Matthew, On Wed, May 11, 2011 at 10:59 PM, Matthew Kaufman wrote: > On 5/11/2011 7:55 PM, Jonathan Fernatt wrote: >> >> I keep seeing seeing this argument from you Mike. I honestly can't >> understand why you think the needs requirement is such an obstacle for a >> company with a legitimate need for addresses that they would have to avoid >> ARIN altogether. > > My issue with the needs requirement post-runout is that the 3-month rules > are still in effect for new and recent entrants... this means that no matter > how hard it is to locate a block that's for sale and successfully bid for > one, you're only able to get 3 months worth of space unless you've had space > for at least a year. > > The original argument that it just requires filing some paperwork every 3 > months to continue justifying additional space no longer works when it isn't > just filing some paperwork to get space from a free pool any more. > > I have several policy proposals pending that attempt to fix this. > +1 Was about to mention the 3 months rule. It makes any kind of planning quite hard, and fragments the IPv4 space tremendously (not that address policy cares about fragmentation, right?). Regards, Martin From jcurran at arin.net Wed May 11 23:09:29 2011 From: jcurran at arin.net (John Curran) Date: Thu, 12 May 2011 03:09:29 +0000 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate In-Reply-To: <0835C54BD358411A849B29E1244B07E1@video> References: <7F5FC4554E42430FADDC0D376164DFA0@mike> <0BB63D56-1605-4E1E-8F0B-B2083FDE4A96@delong.com> <"BANLkTinTJfYH5sOuqpbiLreMzW3 dH0Ozgg"@mail.gmail.com> <16AACD9632484C85BF6B855603CF07B4@mike> <4294678C-B653-4BB3-9D40-FD935EA00CF3@eyeconomics.com> <"BE8988B2F6 C44DF48FA46C8FD6D0EB27"@mike> <3A5E9739CEA64420AB73F106A701DFEB@video> <0835C54BD358411A849B29E1244B07E1@video> Message-ID: <96EBC125-51B8-4BBD-9ED4-3512245137A9@arin.net> On May 11, 2011, at 7:46 PM, Mike Burns wrote: > The discourse below belongs in 2009. > Events have moved beyond your decisions about what is legal fiction and what is legal fact. > You can question the intelligence or judgement of the bankruptcy judge, but not his power or authority. Mike - Can you be more specific? If you are referring to Owen's remark that anyone can make use of any IP addresses that they wish in the configuration of their own equipment, I am unaware of any framework which would allow enforcement of a federal order which specified that "thou shall not configure equipment with IP address block x.y.z/nn, because exclusive use of it in configuration files of all devices in the global Internet has been given to party ABC" It is an interesting exercise to consider how such a contractual right could ever be provided, given the distributed nature of the Internet. /John John Curran President and CEO ARIN From mike at nationwideinc.com Wed May 11 23:09:51 2011 From: mike at nationwideinc.com (Mike Burns) Date: Wed, 11 May 2011 23:09:51 -0400 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate References: <7F5FC4554E42430FADDC0D376164DFA0@mike><0BB63D56-1605-4E1E-8F0B-B2083FDE4A96@delong.com><16AACD9632484C85BF6B855603CF07B4@mike><59EC8A7F22F247058ED74A896F0C6978@mike><907EE389FDC5448ABC46ADD06420B86D@video><4B99E603-7892-433A-9FB9-DB9A08D98F39@delong.com><599AC4287E79403D939568C89EB40922@video> Message-ID: Hi Jon, Here are some examples of an entity that may want to purchase addresses but not demonstrate need: 1. A company with a 5 year planning horizon 2. A company that wants to provide temporary allocations 3. A company that wants to specialize in very rapid allocations, like same-day service. 4. A company that stocks addresses for sale in to those who would pay more for guaranteed availability 5. A company who is concerned about future supply. 6. A company that wishes to lease address space rather than sell it 7. A company who seeks to buy up small allocations to aggregate them in to larger, more valuable netblocks 8. A seller of vanity ip addresses like 100.100.100.100 9. A speculator willing to risk money to buy addresses as an investment for anticipated gains in address prices. 10. A company whose anticipated need does not begin for 12 months. I'm sure there are many more that I cannot think of. I agree with you that most buyers will have need, and I agree with you that most buyers will see the value of maintaining a valid ARIN whois record pointing to their authority. But the policy in APNIC was changed to remove needs requirements for transfers for the same reasons I am requesting its removal here. My policy proposal also has the benefit of incentivizing legacy resources to come under RSA, and it serves to even the playing field between the disparate rights of legacy versus non-legacy holders. And my underlying point is the obvious one, that the very act of paying for address space is a very good indication of need, or at least perceived need on the part of the buyer. Regards, Mike ----- Original Message ----- From: Jonathan Fernatt To: Mike Burns Cc: arin-ppml at arin.net Sent: Wednesday, May 11, 2011 10:55 PM Subject: Re: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate What is the great benefit that outweighs the danger to Whois of unbooked transfers and the benefits of incentivizing legacy resources to come under RSA? Who says my proposal would result in completely unregulated markets? Every transferee would sign an RSA and be subject to ARIN policy. And with my policy or without my policy, addresses are bound to flow to the highest bidder. If the policy proposal doesn't fly, it will be to the highest bidder who can show need. Do you think that we should take more steps to protect the little guy in this event? Maybe a price cap? An address czar? I keep seeing seeing this argument from you Mike. I honestly can't understand why you think the needs requirement is such an obstacle for a company with a legitimate need for addresses that they would have to avoid ARIN altogether. Following that same train of thought, wouldn't it be easier for a company who didn't care about the process or being honest to just falsify their needs justification? I deal with tiny tiny tiny companies who have had no problem whatsoever showing need for resources. ARIN staff and policy have always seemed very accommodating from my perspective. Have you had a different experience? Jon -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike at nationwideinc.com Wed May 11 23:15:59 2011 From: mike at nationwideinc.com (Mike Burns) Date: Wed, 11 May 2011 23:15:59 -0400 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate References: <7F5FC4554E42430FADDC0D376164DFA0@mike><0BB63D56-1605-4E1E-8F0B-B2083FDE4A96@delong.com><"BANLkTinTJfYH5sOuqpbiLreMzW3 dH0Ozgg"@mail.gmail.com><16AACD9632484C85BF6B855603CF07B4@mike><4294678C-B653-4BB3-9D40-FD935EA00CF3@eyeconomics.com> <"BE8988B2F6C44DF48FA46C8FD6D0EB27"@mike><3A5E9739CEA64420AB73F106A701DFEB@video ><0835C54BD358411A849B29E1244B07E1@video> <96EBC125-51B8-4BBD-9ED4-3512245137A9@arin.net> Message-ID: Hi John, Sorry, it was Owen's concept that these numbers had no exclusive right to use, and thus the sale was a legal fiction. (I'm not sure now as the post was long and not included, sorry if I am still being unspecific.) I'm sure you know that ip addresses show up as listed assets on asset sales. Microsoft payed $7.5 million for some addresses. I'm tired of the academic arguments about their status as just a valueless string of numbers. I suppose I could use 1-800-Flowers on my PBX as an extension number, and that makes those numbers valueless. Maybe the judge should have said exclusive right to advertise them on BGP? Regards, Mike ----- Original Message ----- From: "John Curran" To: "Mike Burns" Cc: "Owen DeLong" ; Sent: Wednesday, May 11, 2011 11:09 PM Subject: Re: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate On May 11, 2011, at 7:46 PM, Mike Burns wrote: > The discourse below belongs in 2009. > Events have moved beyond your decisions about what is legal fiction and > what is legal fact. > You can question the intelligence or judgement of the bankruptcy judge, > but not his power or authority. Mike - Can you be more specific? If you are referring to Owen's remark that anyone can make use of any IP addresses that they wish in the configuration of their own equipment, I am unaware of any framework which would allow enforcement of a federal order which specified that "thou shall not configure equipment with IP address block x.y.z/nn, because exclusive use of it in configuration files of all devices in the global Internet has been given to party ABC" It is an interesting exercise to consider how such a contractual right could ever be provided, given the distributed nature of the Internet. /John John Curran President and CEO ARIN From ikiris at gmail.com Wed May 11 23:17:46 2011 From: ikiris at gmail.com (Blake Dunlap) Date: Wed, 11 May 2011 22:17:46 -0500 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate In-Reply-To: References: <7F5FC4554E42430FADDC0D376164DFA0@mike> <0BB63D56-1605-4E1E-8F0B-B2083FDE4A96@delong.com> <16AACD9632484C85BF6B855603CF07B4@mike> <59EC8A7F22F247058ED74A896F0C6978@mike> <907EE389FDC5448ABC46ADD06420B86D@video> <4B99E603-7892-433A-9FB9-DB9A08D98F39@delong.com> <599AC4287E79403D939568C89EB40922@video> Message-ID: On Wed, May 11, 2011 at 22:09, Mike Burns wrote: > Hi Jon, > > Here are some examples of an entity that may want to purchase addresses but > not demonstrate need: > > 1. A company with a 5 year planning horizon > Don't use IPv4, done. > 2. A company that wants to provide temporary allocations > Why do they need extra space? > 3. A company that wants to specialize in very rapid allocations, like > same-day service. > Not an issue until the block get unreasonably big for such a service. > 4. A company that stocks addresses for sale in to those who would pay more > for guaranteed availability > 5. A company who is concerned about future supply. > Both of the above are something that shouldn't deserve IPs > 6. A company that wishes to lease address space rather than sell it > What? > 7. A company who seeks to buy up small allocations to aggregate them in to > larger, more valuable netblocks > Good (expletive) luck. The birthday paradox on this is pretty stupidly big. > 8. A seller of vanity ip addresses like 100.100.100.100 > Ok, this one i'll buy, but it's still stupid, that's what DNS is for. You don't see the same argument for MAC addresses for the same reason. > 9. A speculator willing to risk money to buy addresses as an investment > for anticipated gains in address prices. > See #5 > 10. A company whose anticipated need does not begin for 12 months. > Wait 9 months, it's not all about you. -Blake -------------- next part -------------- An HTML attachment was scrubbed... URL: From fernattj at gmail.com Wed May 11 23:24:05 2011 From: fernattj at gmail.com (Jonathan Fernatt) Date: Wed, 11 May 2011 23:24:05 -0400 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate In-Reply-To: References: <7F5FC4554E42430FADDC0D376164DFA0@mike> <0BB63D56-1605-4E1E-8F0B-B2083FDE4A96@delong.com> <16AACD9632484C85BF6B855603CF07B4@mike> <59EC8A7F22F247058ED74A896F0C6978@mike> <907EE389FDC5448ABC46ADD06420B86D@video> <4B99E603-7892-433A-9FB9-DB9A08D98F39@delong.com> <599AC4287E79403D939568C89EB40922@video> Message-ID: > > Here are some examples of an entity that may want to purchase addresses but > not demonstrate need: > > 1. A company with a 5 year planning horizon > 2. A company that wants to provide temporary allocations > 3. A company that wants to specialize in very rapid allocations, like > same-day service. > 4. A company that stocks addresses for sale in to those who would pay more > for guaranteed availability > 5. A company who is concerned about future supply. > 6. A company that wishes to lease address space rather than sell it > 7. A company who seeks to buy up small allocations to aggregate them in to > larger, more valuable netblocks > 8. A seller of vanity ip addresses like 100.100.100.100 > 9. A speculator willing to risk money to buy addresses as an investment for > anticipated gains in address prices. > 10. A company whose anticipated need does not begin for 12 months. > > I'm sure there are many more that I cannot think of. I agree with you that > most buyers will have need, and I agree with you that most buyers will see > the value of maintaining a valid ARIN whois record pointing to their > authority. > > But the policy in APNIC was changed to remove needs requirements for > transfers for the same reasons I am requesting its removal here. > My policy proposal also has the benefit of incentivizing legacy resources > to come under RSA, and it serves to even the playing field between the > disparate rights of legacy versus non-legacy holders. > > And my underlying point is the obvious one, that the very act of paying for > address space is a very good indication of need, or at least perceived need > on the part of the buyer. > > Regards, > Mike > I can clearly see the case for 1 and 10. At this point in the game, however, I don't think there is any advantage to the community by enabling any of the cases you listed in 2 - 9. (Just my opinion) I guess I would be much more comfortable seeing the needs requirements changed to accommodate those cases rather than remove the requirements altogether. Jon -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcurran at arin.net Wed May 11 23:37:13 2011 From: jcurran at arin.net (John Curran) Date: Thu, 12 May 2011 03:37:13 +0000 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate In-Reply-To: References: <7F5FC4554E42430FADDC0D376164DFA0@mike> <0BB63D56-1605-4E1E-8F0B-B2083FDE4A96@delong.com> <"BANLkTinTJfYH5sOuqpbiLreMzW3 dH0Ozgg"@mail.gmail.com> <16AACD9632484C85BF6B855603CF07B4@mike> <4294678C-B653-4BB3-9D40-FD935EA00CF3@eyeconomics.com> <3A5E9739CEA64420AB73F106A701DFEB@video> <0835C54BD358411A849B29E1244B07E1@video> <96EBC125-51B8-4BBD-9ED4-3512245137A9@arin.net> Message-ID: <1ADED844-0625-4862-A56B-68192AEAB74F@arin.net> On May 11, 2011, at 8:15 PM, Mike Burns wrote: > Sorry, it was Owen's concept that these numbers had no exclusive right to use, and thus the sale was a legal fiction. I believe that all of the parties reached a common understanding with respect to the intention of the sale, and the judge's order does seem to direct accordingly. As I noted, I believe "use" is clear in context and that would imply with respect to the registry entries in the ARIN Whois database and related services. > I'm sure you know that ip addresses show up as listed assets on asset sales. > Microsoft payed $7.5 million for some addresses. So I heard... :) > I'm tired of the academic arguments about their status as just a valueless string of numbers. > I suppose I could use 1-800-Flowers on my PBX as an extension number, and that makes those numbers valueless. > Maybe the judge should have said exclusive right to advertise them on BGP? That would be a very interesting order, as it would be first be necessary to determine how that right was created as well as the appropriate process for enforcement of it. It's not really necessary for the outcome that the parties were seeking (to my best understanding), and might get into an even wider range of issues than one would wish to be handled incidentally to a bankruptcy proceeding... /John From matthew at matthew.at Wed May 11 23:41:01 2011 From: matthew at matthew.at (Matthew Kaufman) Date: Wed, 11 May 2011 20:41:01 -0700 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate In-Reply-To: References: <7F5FC4554E42430FADDC0D376164DFA0@mike> <0BB63D56-1605-4E1E-8F0B-B2083FDE4A96@delong.com> <16AACD9632484C85BF6B855603CF07B4@mike> <59EC8A7F22F247058ED74A896F0C6978@mike> <907EE389FDC5448ABC46ADD06420B86D@video> <4B99E603-7892-433A-9FB9-DB9A08D98F39@delong.com> <599AC4287E79403D939568C89EB40922@video> Message-ID: <4DCB56CD.9020703@matthew.at> On 5/11/2011 8:17 PM, Blake Dunlap wrote: > > > On Wed, May 11, 2011 at 22:09, Mike Burns > wrote: > > Hi Jon, > Here are some examples of an entity that may want to purchase > addresses but not demonstrate need: > 1. A company with a 5 year planning horizon > > > Don't use IPv4, done. Not a very good risk mitigation strategy. A company may wish to hedge their bets about the speed of the IPv6 transition. > 2. A company that wants to provide temporary allocations > > > Why do they need extra space? This seems obvious. > 3. A company that wants to specialize in very rapid allocations, > like same-day service. > > > Not an issue until the block get unreasonably big for such a service. Huh? How could they possibly justify any acquisition of space, no matter how small, for this purpose? > 4. A company that stocks addresses for sale in to those who would > pay more for guaranteed availability > > 5. A company who is concerned about future supply. > > Both of the above are something that shouldn't deserve IPs Really? A company concerned about future supply doesn't deserve IP addresses? The entire point of needs justification is to justify the need not just for *today* but for 12 months in the future (or 3 months in the future for some unfortunate entities). > 6. A company that wishes to lease address space rather than sell it > > What? This seems obvious to me as well. Leasing is one of the several ways holders of IP address space might make it available to others. > > 7. A company who seeks to buy up small allocations to aggregate > them in to larger, more valuable netblocks > > Good (expletive) luck. The birthday paradox on this is pretty stupidly > big. This I do agree with. > 8. A seller of vanity ip addresses like 100.100.100.100 > > Ok, this one i'll buy, but it's still stupid, that's what DNS is for. > You don't see the same argument for MAC addresses for the same reason. Can't be that stupid... see 8.8.8.8 and 8.8.4.4 > 9. A speculator willing to risk money to buy addresses as an > investment for anticipated gains in address prices. > > See #5 This is one of the ways that market liquidity is generated. If we don't have this then it'll be *harder* to get IP address space when you need it, whether or not you can do a needs justification. This is another reason why the 3-month limits for new/recent entrants are such a big problem post-runout... they eliminate speculative activity BUT the lack of speculative activity means that coming back for more in 3 months is actually harder rather than easier. > 10. A company whose anticipated need does not begin for 12 months. > > Wait 9 months, it's not all about you. Try raising venture capital for a project that will need IPv4 and IPv6 access once product development is complete and disclose that you're not going to try to get space until several months post-runout and see what the potential investors say. Matthew Kaufman -------------- next part -------------- An HTML attachment was scrubbed... URL: From tedm at ipinc.net Thu May 12 00:15:29 2011 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Wed, 11 May 2011 21:15:29 -0700 Subject: [arin-ppml] ARIN-prop-148 LRSA resources must not betransferred to LRSA In-Reply-To: <083CA8768726468C89482C8D69EF6C71@video> References: <4DC9771D.6010809@arin.net> <88D606D6-C7A3-4E48-9988-4CF29CD052A1@delong.com> <083CA8768726468C89482C8D69EF6C71@video> Message-ID: <4DCB5EE1.8070600@ipinc.net> In my opinion I see little value in publishing redacted RSAs The most common reason cited for modifying RSA is court order or government requirement. Many governments have open records laws as do most universities and these documents should be publicly available in enough cases to satisfy the community's curiosity as to what is most commonly modified. ARIN can easily select representative samples of modified RSA's that they know are signed by public organizations under legal requirement to disclose anyway, and ask the organization for permission to publish, most of those requests would be granted automatically, enough so that there would be a good selection for example purposes. Of much more value, and something for John to put on his list of things to place into the "merged RSA" would be language in the RSA that REQUIRES that if the RSA is modified that ARIN has the right to publish the organization name and modification they required, unless the government is under a law that disallows this, or a court orders it under NDA. I understand the concern about a group like a state wanting to reduce paper recording requirements, but frankly that is NOT ARIN's problem, and if the state doesn't like it they need to petition their legislature to quit mandating the practice. In any case, giving ARIN the right to publish does not mean it will do it. I also feel that any NDA that ARIN signs for RSA modification must also have a time limit in it. Whether it be 10, 20, 30 or whatever number of years, it should eventually expire. Ted On 5/11/2011 6:28 PM, Mike Burns wrote: > +1 to the idea of publishing redacted RSAs. > -Mike > > > ----- Original Message ----- From: "Owen DeLong" > To: "William Herrin" > Cc: "John Curran" ; > Sent: Wednesday, May 11, 2011 9:04 PM > Subject: Re: [arin-ppml] ARIN-prop-148 LRSA resources must not > betransferred to LRSA > > >> >> On May 11, 2011, at 5:46 PM, William Herrin wrote: >> >>> On Wed, May 11, 2011 at 8:03 PM, Jimmy Hess wrote: >>>> On Wed, May 11, 2011 at 12:29 PM, William Herrin >>>> wrote: >>>>> This allows for John Curran's case where the RSA sees minor changes to >>>>> accommodate government entities and the like. >>>>> -Bill >>>> >>>> If ARIN staff feels there are minor changes they should make to the >>>> RSA, they should >>>> make public record of those changes somewhere, and explain when they >>>> are used, >>> >>> I agree. John -- how about publishing the one-off modified RSAs and >>> LRSAs that have been used and explaining in each case what change was >>> made and why it was deemed appropriate? Making non-substantive >>> adjustments doesn't inherently strike me as unreasonable, but the >>> interests of transparency would be well served by making those >>> adjustments public knowledge. >>> >> Agreed. This should be possible without identifying the particular >> recipient of the modification, so, I don't believe it would violate >> any NDA to do so. >> >> 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. > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From mysidia at gmail.com Thu May 12 03:25:26 2011 From: mysidia at gmail.com (Jimmy Hess) Date: Thu, 12 May 2011 02:25:26 -0500 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate In-Reply-To: <907EE389FDC5448ABC46ADD06420B86D@video> References: <7F5FC4554E42430FADDC0D376164DFA0@mike> <0BB63D56-1605-4E1E-8F0B-B2083FDE4A96@delong.com> <16AACD9632484C85BF6B855603CF07B4@mike> <59EC8A7F22F247058ED74A896F0C6978@mike> <907EE389FDC5448ABC46ADD06420B86D@video> Message-ID: On Wed, May 11, 2011 at 8:03 PM, Mike Burns wrote: > I have personally seen many asset sale agreements which included legacy IP > addresses which were completed without notifying ARIN, as there is still no > requirement for legacy holders to do that. I have seen asset sale agreements > which include ARIN accounts and passwords among the listed assets. The Any attempt to sell an ARIN account username / ARIN passwords would (hopefully) be a violation of the ARIN Online terms of use, and result in termination of the validity of the account. > addresses change control, but whois still shows the original registrant. > When it comes time to route the addresses, if the network operator questions > the situation, I have seen them accept the asset sales agreements as > acceptable proof of routing authority. And the addresses allocated to entity It is little different than use of a forged LOA, really. The network operator will typically take _anything_ that looks like plausible documentation. If the document is forged or otherwise invalid, the responsibility is now on the customer's head, and the network operator can plead ignorance. The network operator may very well be pulling those routes right back out, however, when the hijacking is found/reported. This is not a problem with addressing policy; it's a weakness of the routing system, and certified resources / RPKI could eventually offer a solution. > A are now in control of entity B, with bogus whois data. This is the kind of > eventuality which I believe motivated the APNIC community to place the > stewardship role of uniqueness above the stewardship role of needs-based > transfers. Obviously I am asserting these things without documentary proof. Bogus WHOIS data doesn't just haunt ARIN. It actually has a possibility to hurt any organization whose resources are listed with bogus data. There may be some spammers who would love the idea of not having valid contacts in WHOIS. But legitimate organizations would usually like some certainty that they have the IP addresses, they are on record as having the IP addresses, they are under proper agreement, and they won't incur a disruption or loss of number resources impacting their business as a result of not doing things right and having mucked up records. -- -JH From tedm at ipinc.net Thu May 12 04:02:02 2011 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Thu, 12 May 2011 01:02:02 -0700 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate In-Reply-To: References: <7F5FC4554E42430FADDC0D376164DFA0@mike> <0BB63D56-1605-4E1E-8F0B-B2083FDE4A96@delong.com> <16AACD9632484C85BF6B855603CF07B4@mike> <59EC8A7F22F247058ED74A896F0C6978@mike> <907EE389FDC5448ABC46ADD06420B86D@video> Message-ID: <4DCB93FA.1020707@ipinc.net> On 5/12/2011 12:25 AM, Jimmy Hess wrote: > On Wed, May 11, 2011 at 8:03 PM, Mike Burns wrote: >> I have personally seen many asset sale agreements which included legacy IP >> addresses which were completed without notifying ARIN, as there is still no >> requirement for legacy holders to do that. I have seen asset sale agreements >> which include ARIN accounts and passwords among the listed assets. The > > Any attempt to sell an ARIN account username / ARIN passwords would (hopefully) > be a violation of the ARIN Online terms of use, and result in > termination of the validity of > the account. > >> addresses change control, but whois still shows the original registrant. >> When it comes time to route the addresses, if the network operator questions >> the situation, I have seen them accept the asset sales agreements as >> acceptable proof of routing authority. And the addresses allocated to entity > > It is little different than use of a forged LOA, really. > The network operator will typically take _anything_ that looks like > plausible documentation. > If the document is forged or otherwise invalid, the responsibility is > now on the customer's head, > and the network operator can plead ignorance. > > The network operator may very well be pulling those routes right back > out, however, > when the hijacking is found/reported. > > This is not a problem with addressing policy; it's a weakness of the > routing system, > and certified resources / RPKI could eventually offer a solution. > > >> A are now in control of entity B, with bogus whois data. This is the kind of >> eventuality which I believe motivated the APNIC community to place the >> stewardship role of uniqueness above the stewardship role of needs-based >> transfers. Obviously I am asserting these things without documentary proof. > > Bogus WHOIS data doesn't just haunt ARIN. > It actually has a possibility to hurt any organization whose resources > are listed > with bogus data. > > There may be some spammers who would love the idea of not having valid contacts > in WHOIS. > > But legitimate organizations would usually like some certainty that > they have the > IP addresses, they are on record as having the IP addresses, they are under > proper agreement, and they won't incur a disruption or loss of number > resources > impacting their business as a result of not doing things right and > having mucked up records. > However most of this really isn't that important. If ISP A goes out of business and has some Legacy numbers and ISP B buys them, and never updates with ARIN it is likely that ISP B is going to have those legacy numbers in use. If ARIN takes the numbers away from ISP B and gives them to ISP C all you have ended up doing is taking some numbers away from some customers of ISP B so that some customers of ISP C can get them. You have not taken numbers that are not in use and gotten them into use. You have in fact done absolutely nothing to increase the amount of time that IPv4 requests can be satisfied, and you have created an enemy of ISP B who is much less likely to want to work with the RIR system and much more likely to want to undermine it. This is very far away from the situation of an org that has legacy numbers they have no use for and want to turn into cash, and that by doing so will yield up some numbers for use that are currently not in use. 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 tvest at eyeconomics.com Thu May 12 04:58:43 2011 From: tvest at eyeconomics.com (Tom Vest) Date: Thu, 12 May 2011 04:58:43 -0400 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate In-Reply-To: References: <7F5FC4554E42430FADDC0D376164DFA0@mike> <0BB63D56-1605-4E1E-8F0B-B2083FDE4A96@delong.com> <16AACD9632484C85BF6B855603CF07B4@mike> <4294678C-B653-4BB3-9D40-FD935EA00CF3@eyeconomics.com> Message-ID: Hi Mike, Thanks for the very detailed response. Given the level of scrutiny that you've obviously devoted to this particular transfer transaction, and your repeated emphasis on what could be interpreted as gaps and inconsistencies in the accumulated public disclosures about this matter, I am tempted to assume that you are either a real stickler for legalistic/rule-based/procedural fairness, or a determined champion of transparency and public disclosure -- or perhaps both (?). And yet your policy proposals seem to exhibit very little of those concerns about procedural fairness and transparency -- but quite a bit of the same sort of fairy tale qualities that you disparage in the official account of the Nortel/Microsoft transfer justification. To paraphrase George Berkeley, if a tree falls in the woods but no one's around to hear it (and/or to witness whether it harms any other trees on the way down), do we still believe that it makes a sound? Or would be better to infer from the silence that trees in the forest have become immune to the laws of gravity, or perhaps that falling trees now spontaneously sublimate into gas as soon as they start tilting, thus making both sound and harm impossible? If we put enough distance between ourselves and the forest so that no sound can ever be heard, does that grant us the license to be indifferent as to which of these is (more) true -- or to take any position that appeals to us, regardless of its (in)consistency with previous observations? The same questions come up in the real world. For example, what does the generally low quality of domain-related whois data that is commonly observed in the competitive market for DNS registrar services say about the notion that the price mechanism alone is sufficient to sustain whois meaningful registry/whois participation? [1]. What can be inferred from a situation in which a 100% voluntary (and until very recently, 100% free) registry dedicated to much pricier assets still only attracts participation at levels that would be fatal to an IP number resource registry? HM Land Registry in the UK, for example, just passed the 70% national participation milestone (though participation in some rural counties remains below 50% ) after only 150+ years of membership promotion efforts) [2]. What, if anything, do you think that we can take away from the experiences of other private registries like these? Why should we assume that the private decision making calculus of future transfer market participants will favor registration/disclosure over nondisclosure at rates that are 2-3x higher than observed participation levels in other private registries? For the record, I agree with you that the next few years are certain to test the current registry/whois system more severely than it has ever been tested in the past. I also believe that that system will continue to represent the best and only means at "our" (individual and/or collective) disposal, both for exercising "macro-prudential" judgment in private/commercial matters, and for serving as informed co-participants in "macro-prudential" coordination and oversight activities -- a.k.a. "industry self-governance." These functions are doubly critical in industries like the ours (which in this sense would include banking/finance) that are highly dependent on the consistency (or at least predictability) of transitive commercial interactions. As long as the "typical" inter-domain packet exchange must traverse 3~4 or more separate business entities in order to be completed, there is no reason to believe that "counterparty scrutiny" (or peer-mediated / "market discipline") alone will be sufficient to keep this industry afloat -- no matter how we reinforce those bilateral levers with (ironclad contracts | secure protocols | interpersonal relationships | faith in the rationality of markets). The banking industry learned that lesson the hard way not so long ago -- or at least I'd like to think that parts of it did, even if there hasn't been any obvious change in the pace or direction of financial activity migration away from the "light" of reciprocal disclosure and limited transparency, and into the "shadows" where nobody knows nothing. Regardless, I think that *we* should take advantage of the opportunity to learn from this episode, even if bankers themselves don't. Considering that Internet industry members still enjoy the kind of operational autonomy and freedom of private action that US banks once had -- until their own self-governance mechanisms stopped working (and the Fed took over, c. 1907), the stakes on the line during the next few years really couldn't be higher... TV, speaking form myself alone On May 11, 2011, at 5:12 PM, Mike Burns wrote: > Hi Tom and welcome to this particular discussion, > > The current legal realities I referenced are the implications of the public information associated with the MS/Nortel deal. > > In this forum I have argued that the public bankruptcy documents reveal that the addresses transferred from Nortel to MS were not originally allocated to Nortel, but represented some accumulation of addresses allocated to Nortel's "predecessors in interest" who were Nortel acquisitions from the 1990s. > > I argued that MS and Nortel negotiated a deal to sell all the addresses in that accretion, although the public documents reveal that Microsoft was able to bid on an amount smaller than the entire lot. > > After the original asset sale agreement between MS and Nortel was negotiated, ARIN became aware of the transaction, and after some negotiations with the parties at interest, and some changes to the MS/Nortel asset agreement, made a press release claiming that the transfer could proceed under existing ARIN policy. > > ARIN later revealed the policy utilized to be NRPM 8.3, which requires four things which may or may not have actually happened: > > 1. Addresses are supposed to be issued back to ARIN and then reissued to the recipient, Microsoft, and the bankruptcy docs did not reveal this happened in any way. > 2. Address are supposed to be transferred as a single aggregate, but if the addresses were an assortment of netblocks from prior Nortel acquisitions, this could not have happened. > 3. Recipients were required to sign an RSA, MS signed a modified LRSA. > 4. Finally, the requirement at issue here, a needs analysis had to be completed by ARIN, which magically showed that MS qualified for exactly the amount already bid for and negotiated the sale of. > > If they had needed fewer addresses, they could have bid for less than the full pool. > If they needed more addresses, they should have received an additional ARIN allocation. > Paraphrasing Goldilocks, the random allocation of addresses to long-ago Nortel acquisitions was "just right." > > My reading of the bankruptcy documents leads me to the conclusion that the bankruptcy judge found that Nortel had the exclusive right to transfer the addresses, even though the judge had not been informed of any ex-post-facto NRPM 8.2 transfer from the original registrants to Nortel. To me, this means he was convinced that ARIN had no rights over transferring the addresses, although ARIN has rights over reflecting that transfer in Whois. This is consistent with a declaration by the head of ARIN at the time in the Kremen case where he stated that ARIN has no authority over legacy addresses. > > My argument is that the apparent success of RIR stewardship (although I claim many of the allocated and unrouted addresses represent failures here) over the last two decades is laudable and represents an obvious requirement in the stewardship of free pool resources, but is unnecessary in a post-exhaust age where the price of addresses will ensure efficient use. > > I also argue that in the post-exhaust age, conflicts over claims to address rights will likely increase, putting more pressure on Whois to accurately represent reality. > > Regards, > Mike Burns > > > > > > > ----- Original Message ----- From: "Tom Vest" > To: "Mike Burns" > Cc: "McTim" ; "Owen DeLong" ; > Sent: Wednesday, May 11, 2011 4:34 PM > Subject: Re: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate > > > Hi Mike, > > While it may or may not be true that your perspective on this question is consonant with that of "the APNIC community," elements within said community have been championing the same broad policy changes that you're advocating here now since the early 1990s. Thus it would seem that the views that you associate yourself with here couldn't possible have anything to do with "current legal realities" -- unless perhaps by "current" you mean something like "twentieth century." > > Given that historical fact -- and the apparent success of the RIR stewardship mission over the intervening two decades of possible nonconformity with legal reality -- on what basis could you legitimately claim that abandoning time-tested registry practices that have been integral to maintaining whois accuracy to date represents the best, or perhaps the only way to maintain whois accuracy in the future? > > Alternately, if you actually had in mind some other, more recent legal developments -- which by definition could not have any causal relation to policy arguments that predated them by 10-15 years -- a clarification of exactly what those changes in legal reality are would be much appreciated. > > Thanks, > > TV > > > On May 11, 2011, at 3:13 PM, Mike Burns wrote: > >> Hi Owen and McTim, >> >> I, along with the APNIC community, could make the claim that you are abandoning the stewardship role in maintaining Whois accuracy, and sacrificing that stewardship role on the altar of an ARIN needs policy developed for the purposes of free pool allocations that does not comply with current legal realities. >> >> But charges of abandoning stewardship are inflammatory, and I hope we can keep to actual discussions of the implications of my proposal without casting aspersions. >> >> Let's agree that we all seek the highest standards of stewardship, but disagree on how those standards should be applied. >> >> I think I could characterize your opposition better by saying that you believe the danger of hoarding and speculation outweigh the risk to whois accuracy. >> Would that be an accurate statement, if not your exclusive objection to the proposal? >> >> Regards, >> Mike >> >> >> >> ----- Original Message ----- From: "McTim" >> To: "Owen DeLong" >> Cc: "Mike Burns" ; >> Sent: Wednesday, May 11, 2011 2:53 PM >> Subject: Re: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate >> >> >> On Wed, May 11, 2011 at 9:09 PM, Owen DeLong wrote: >>> I oppose the policy as written. >> >> +1 >> >> >>> Abandoning our stewardship role for the sake of making it more likely >>> people will register their misappropriation of community resources is >>> like legalizing bank robbery in the hopes that the thieves will pay >>> income tax on their ill gotten gains. >> >> ;-) >> >> -- >> Cheers, >> >> McTim >> "A name indicates what we seek. An address indicates where it is. A >> route indicates how we get there." Jon Postel >> _______________________________________________ >> 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 12 05:09:38 2011 From: owen at delong.com (Owen DeLong) Date: Thu, 12 May 2011 02:09:38 -0700 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate In-Reply-To: References: <7F5FC4554E42430FADDC0D376164DFA0@mike> <0BB63D56-1605-4E1E-8F0B-B2083FDE4A96@delong.com> <16AACD9632484C85BF6B855603CF07B4@mike> <59EC8A7F22F247058ED74A896F0C6978@mike> <907EE389FDC5448ABC46ADD06420B86D@video> <4B99E603-7892-433A-9FB9-DB9A08D98F39@delong.com> Message-ID: <75931BFB-2025-4E6A-9F48-1D0F28815837@delong.com> On May 11, 2011, at 7:31 PM, John Curran wrote: > On May 11, 2011, at 6:37 PM, Owen DeLong wrote: > >> There is no reason that ARIN, upon conducting a section 12 review and finding that the original holder was >> no longer using the resources and/or was defunct could not reclaim those resources, so, the recipient in that >> case is taking a rather large risk. I do not believe ARIN will view the asset sale agreement as legitimizing >> the transfer and the community developed policies support reclamation of resources from defunct legacy >> holders. ARIN has reclaimed such resources in the past, though I do not know if they have reclaimed them >> from organizations who believe they were able to "purchase" them as part of some form of asset transfer. > > We have not done so to date (as far as I am aware, and I would > have very likely have been made aware of any action to do so) > I realize this. I believe the community would like to see that change. > We have reclaimed in cases where parties have asserted that > they have the right to use specific resources due to merger > or acquisition, could not produce any paperwork, and then the > original address holder turned out to be defunct or denied > that any transfer was intended. These cases almost always > involve recipient parties that then quickly disappear rather > than further pursue the matter, and similar indications of > hijack attempts. > The difference between this and what I describe above is subtle at best. > While I recognize that ARIN could theoretically reclaim > address space from a defunct legacy address holder where > the successor organization simply does not wish to update > their records per M&A transfers (NRPM 8.2), that course > of action appears to me to be more punitive than actually > advancing the mission of the organization. The record > keeping subsequent to an merger/acquisition often does > not get cleaned up for several years subsequent to the > actual event, and first we would need to set a realistic > community shared expectation regarding how much time is > to be allowed for record updating, and the appropriate > intermediate steps along the path between "please come > in and update your records" and "we have reclaimed the > number resources that you thought were assigned to you" > I disagree. I have no problem with ARIN extending an offer to complete an 8.2 transfer and sign a current standard RSA substantially similar to that any organization receiving new resources would sign, if ARIN believes they are a legitimate 8.2 successor in interest. I have no problem with ARIN extending an offer to complete an 8.3 transfer and sign a current standard RSA substantially identical to that any organization receiving new resources would sign, if ARIN believes the transfer meets the requirements outlined in section 8.3. However, if an organization refuses to update whois and/or refuses to sign the standard RSA and they are not the original resource holder, then I fail to see how ARIN can consider the space anything other than hijacked and I believe that in the interests of keeping whois consistent and following the policies set by the community for the management of the whois database, the original registration pointing to the defunct organization should be removed and the addresses should be placed back into the free pool for allocation to another organization in compliance with policy. This is not punitive, it is merely intended to avoid allowing those operating outside of policy to retain resources in a manner contrary to the policies set by the community. As I have said before, I do not support punitive approaches to legitimate legacy holders. However, I do not believe that legacy resources are arbitrarily transferable without restriction and I see no reason ARIN should recognize such transfers unless the community specifically expresses a desire to do so through policy. As it currently stands, the community has expressed a fairly clear desire not to allow such arbitrary transfers without needs justification. > By no means is this an encouragement for folks post-merger > to skip updating their records at ARIN, but simply pointing > out that we would need to have some compelling community > guidance before changing the existing practices in this area. You are talking about mergers, whereas I was responding to a message where Mike had described sales of address space completely outside of policy and without involving sale of the underlying infrastructure. > We are seeing more 8.2 updates as a result of folks realizing > the importance of their number resources, and some as a result > of interest in performing transfers, and this is definitely > a step in the right direction for improving registry accuracy. > Creating a potential risk that ARIN would decide instead to > reclaim resources from part M&A activity would more likely > to inhibit rather than encourage updates. > That is not what I was advocating. However, I do think that other than the original legacy holder, nobody should be allowed to retain their registration without signing a current standard RSA as described above. Owen From owen at delong.com Thu May 12 05:14:13 2011 From: owen at delong.com (Owen DeLong) Date: Thu, 12 May 2011 02:14:13 -0700 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate In-Reply-To: References: <7F5FC4554E42430FADDC0D376164DFA0@mike> <0BB63D56-1605-4E1E-8F0B-B2083FDE4A96@delong.com> <16AACD9632484C85BF6B855603CF07B4@mike> <59EC8A7F22F247058ED74A896F0C6978@mike> <907EE389FDC5448ABC46ADD06420B86D@video> Message-ID: <8EBD080A-3150-4269-A73B-BD5724312E6E@delong.com> On May 11, 2011, at 7:41 PM, Martin Millnert wrote: > Owen, > > On Wed, May 11, 2011 at 10:23 PM, Owen DeLong wrote: >>>> then, either: >>> >>> 1) policies (eventually) change to adjust more towards reality (if a >>> party can get working internet w/o involving the RIR, by an ISPs free >>> will choice to accept the addresses as legitimate theirs, they have no >>> real reason to involve the RIR ) >>> 2) the RIR's whois loses accuracy, >>> 3) the RIR corrupts its practices of the community policies to avoid >>> 2, lacking 1. >>> >> You left out: >> >> 4) The RIR eventually identifies these outliers and reclaims the numbers >> to be reissued to members of the community willing to comply with policy. > > Well, you'd potentially destroy uniqueness if the other party and its > ISPs disagrees and continues to use the addresses. > That is a theoretical risk today with hijackings. I fail to see the difference. >> 5) The community directs the RIRs to take some more aggressive action >> with respect to these outliers. > > It's just bits, numbers, and you said yourself you are free to > configure whatever bits you want wherever you want. > Yep. There are things the RIR can do to make that harder for hijackers and others not conforming to community policy if that becomes desirable. Currently, I'm not inclined to believe that it is a desirable alternative. Personally, I think 4 is probably the best option. However, I'm not entirely convinced of any widespread validity of the assertion stated in 1, so, that's probably part of the issue. Owen From owen at delong.com Thu May 12 05:57:18 2011 From: owen at delong.com (Owen DeLong) Date: Thu, 12 May 2011 02:57:18 -0700 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate In-Reply-To: <599AC4287E79403D939568C89EB40922@video> References: <7F5FC4554E42430FADDC0D376164DFA0@mike> <0BB63D56-1605-4E1E-8F0B-B2083FDE4A96@delong.com> <16AACD9632484C85BF6B855603CF07B4@mike> <59EC8A7F22F247058ED74A896F0C6978@mike> <907EE389FDC5448ABC46ADD06420B86D@video> <4B99E603-7892-433A-9FB9-DB9A08D98F39@delong.com> <599AC4287E79403D939568C89EB40922@video> Message-ID: On May 11, 2011, at 7:41 PM, Mike Burns wrote: > > Hi Owen >> >>> I have personally seen many asset sale agreements which included legacy IP addresses which were completed without notifying ARIN, as there is still no >>requirement for legacy holders to do that. I have seen asset sale agreements which include ARIN accounts and passwords among the listed assets. The >>addresses change control, but whois still shows the original registrant. > >> There is no reason that ARIN, upon conducting a section 12 review and finding that the original holder was >> no longer using the resources and/or was defunct could not reclaim those resources, so, the recipient in that >> case is taking a rather large risk. > > Wrong, may I quote NRPM 12.8? > This policy does not create any additional authority for ARIN to revoke legacy address space. > Correct... no _ADDITIONAL_ authority. ARIN has always maintained that they have the ability to reclaim abandoned legacy space. If the original resource holder is no longer using the space and/or is defunct, ARIN has the right to reclaim the space. If the successor organization chooses to complete an 8.2 transfer and sign an ARIN standard RSA and update their whois, that's fine. However, if they do not, then, I see no reason for ARIN to leave bad data in whois to allow them to continue to hijack the space in a manner contrary to the policies set by the community. > >> I do not believe ARIN will view the asset sale agreement as legitimizing >> the transfer and the community developed policies support reclamation of resources from defunct legacy >> holders. > > I never said they were defunct, they may have simply been acquired. > ARIN has a moral, if not legal (the legal status is somewhat unknown) to continue to provide services to the original legacy registrant of certain resources. That obligation is non-transferable. In the case of an acquisition, the acquiring party has the right to keep the resources to the extent they are still justified under current policy by completing a transfer according to section 8.2 and signing the standard RSA. To the best of my knowledge, ARIN has no such obligation to a successor organization that chooses not to operate within policy and complete the transfer under section 8.2 Certainly, ARIN has no obligation whatsoever to a third party that is under the mistaken impression that they were able to acquire the addresses independent of the underlying network and purpose for which the addresses were originally issued. >>> When it comes time to route the addresses, if the network operator questions the situation, I have seen them accept the asset sales agreements as acceptable >>proof of routing authority. And the addresses allocated to entity A are now in control of entity B, with bogus whois data. This is the kind of eventuality which I >>believe motivated the APNIC community to place the stewardship role of uniqueness above the stewardship role of needs-based transfers. Obviously I am >>asserting these things without documentary proof. >> > >> Again, can you cite an independently verifiable example? If not, then, I still believe this is a straw man argument. > >> How many such agreements have you seen? (I tend to think that it represents a relatively small fraction of >> the address space and will likely get resolved through the current contact validation process for the most >> part.) > > Owen, if it were just Mike Burns saying this, would APNIC have changed their policies? APNIC did not "change" their policies any more than ARIN changed their policies. APNIC enacted a transfer policy. ARIN enacted a transfer policy. In the development of those policies, a difference emerged between the policy developed in APNIC and the policy developed in ARIN. In APNIC, the transfer policy does not require justified need. In ARIN, the transfer policy absolutely requires justified need. Both were new policies developed by the two regions, independently, but, at approximately the same time. I believe that the policy in APNIC is largely the result of very strong and vocal lobbying by Geoff Huston and a couple of other individuals that routinely take a rather dominant role in the policy development process there. Even with such strong and vocal support from community leaders in the APNIC region, the debate was long and the outcome was not entirely certain until the matter was finally decided. If you have never been to an APNIC meeting to observe how they determine consensus around a proposal, then, I suspect you have no frame of reference to properly evaluate just how little the fact that APNIC chose to abandon needs-basis actually means in terms of using it as evidence to support such a claim. > Yes, the agreements I have seen represent a small fraction of the address space. > No, I can not cite an independently verifiable example, I hoped by now you would have thought higher of my intelligence. > This has nothing to do with your intelligence or my opinion of it. Without an independently verifiable example, it remains assertion and conjecture rather than proof or fact. You are asserting that these things have happened. I am questioning the validity of that claim. You are asserting that they are happening to such an extent that the integrity of whois is in jeopardy if that continues. I am saying that for the community to properly evaluate such a claim, we would need visibility into the nature and scope of such transactions. >>> While I don't think that's the entire argument or even a particularly accurate framing of that portion of the >>> argument, I would say that the history of free markets does give one plenty to fear. Especially when you >>> consider that history in situations of truly finite (even for a short time) resources. (Tulips anyone?) >> >> > You seem to consider that needs-based allocations were some kind of > social agreement preventing malfeasance of the wealthy and protecting > the little guy. > > Indeed, i do. > >>> In reality, it was the least rulemaking possible in an era of free-pool allocations. > >> No, we could easily have handed addresses out for the asking without any regulation whatsoever. >> We, as a community chose not to. We made that choice for good reasons. I believe those reasons >> remain and may even be enhanced by runout. > > C'mon Owen! Who could possibly believe what you are saying here? Of course there were good reasons for not handing them out without any regulation whatsoever. I have expressed over and over that nobody has ever supported that notion, to my knowledge. Needs assessment was a noble and valid means of stewarding addresses into productive use. > First you question who could believe what I am saying, then you agree with it. I am confused. >>> There really was no other way to distribute scarce resources with no price unless the allocations were limited by need. > >> Not at all true. They could have been simply handed out to whoever asked first. I agree such an >> approach would have been ridiculous. The difference between us is that I believe even when you >> include dollars in the process, such an approach remains ridiculous because it transfers the >> address regulation from community based stewardship to a system where the only factor >> determining resource allocation is the accumulation of capital. > > Owen, like it or not, dollars are going to be involved in the process of address transfers. I never said they would not. Indeed, I am not even opposed to that. However, I am opposed to allowing them to be the sole and only mechanism of regulation. > That is not at issue here. Correct, to a certain extent. (See above). > Thanks for agreeing that your proposed alternate mechanism for allocation from the free pool is ridiculous, it should be a short step from there towards acknowledging that the needs requirement was the lightest touch of a proper steward allocating from the free pool. > I think you are entirely missing my point. I am not sure whether you are doing so deliberately or otherwise. My point is that removing needs-basis from allocation policy makes as little sense with money involved as it would have without money involved. There is nothing to align the money with the community interest or good stewardship. >>> And nobody really debates that, even an outlier like me. > >> Interesting... I will actually debate that. I agree the alternatives were absurd. However, to claim that >> they did not exist would be as logical as my claiming that an unregulated market is not an option. >> It's an equally detrimental option, but, it's an option. > > Would you at least admit that there was no other option if we wished to be proper stewards, both ensuring productive use and making the minimum of rules to allow for that? > There is no other option today if we wish to remain good stewards. The option of abandoning needs basis is equally absurd now as it was then and for the exact same reasons. Yes, we now have to allow money to become an additional factor. It remains to be seen exactly what effects (good and bad) that will have in this environment. However, I greatly prefer the option of adding money as an additional factor vs. replacing all current regulation with money as the sole and only regulation. I think most systems administrators would agree that making a single change and evaluating the results is a more reliable approach to a stable system than making multiple simultaneous changes. >>> That cause goes away with the free pool, and the imperative against more rules than necessary dictates we lift those needs-based transfer rules. > >> Indeed, we do disagree. I believe that the cause for needs-basis was the idea that the community >> preferred not to grant resources to entities that did not need them to the exclusion of entities that >> do. > > No, I think we agree. At least I agree with your last statement, if we limit it to the free pool, which was the context. > I don't see any reason that statement doesn't or shouldn't apply equally to the movement or retention of addresses after the free pool is exhausted, either. > >> I see no way in which bringing money into the picture changes that reality or that community ideal. > > Owen, you are conflating issues. Money is coming into the picture regardless of needs requirements. > No, you are confused. My statement is that merely bringing money in does not change the picture and does not change the reality of that community ideal. I accept and understand that we are bringing money into the picture. Where I am disagreeing with you is the belief that that provides a good reason to abandon the more rational approach at the same time. I believe that money and needs-basis can coexist and result in a better overall outcome for the community than the one achievable through money alone. > >>> We have to understand the cause of needs requirements. It wasn't some egalitarian ethos, it was an obvious and fair mechanism for placing some limit on >>address allocations from a free pool of limited size. > >> And it still is. The source pool for IPv4 address transfers is not unlimited in size, either. > > No, it is not unlimited, but now we have price to ensure productive use, something we did not have when allocating from the free pool, so we chose the least intrusive mechanism to ensure that at the time, which was needs requirements. Now we have no free pool and the mechanisms of supply and demand to ensure productive use. > I agree that needs requirements be continued on free pool allocations. > Price does NOT ensure productive use. No matter how many times you repeat this absurd fallacy, it remains an absurd fallacy. Since price will not ensure productive use, abandoning needs basis (which has proven reasonable effective at doing so) does not make sense. When you build your argument on a flawed premise, your conclusions tend to amplify that flaw. Price ensures that the participants in the market will act in their own financial interest with minimal, if any, consideration for the impact on the other members of the community. Indeed, with price as the only control, anti-competitive manipulations become not only possible, but, very likely. > > >>> We didn't impose max limits per allocant, we didn't impose progressive fees that made larger blocks proportionally more expensive, we didn't create rules to >favor corporate diversity, we didn't limit distributions per country, we didn't require an income statement of recipients so that we could judge whom to allocate to. >> >> No, we chose not to allow greedy entities to absorb more space than they needed >> to the exclusion of others. Your claim is that adding money to the situation somehow >> removes the need to do so. My argument and belief is that it does not. > > Again, Owen, this is not about money. Money is going to be part of all transfers. > This is about maintaing a needs requirement. > Try reading what I actually wrote instead of responding to the internal monologue. I am not saying that money isn't coming into the situation. I'm saying that just because it does, doesn't remove the need to prevent greedy entities from absorbing more space than they need to the exclusion of others. You are saying that bringing money in fundamentally changes the need for regulation. I am saying that it does not. You cannot argue that bringing money in makes all the difference on one side and then claim that the rest of the discussion isn't about money. The question is how money will affect the proper stewardship of addresses. I believe it makes little difference, and, to some extent makes it more difficult to maintain proper stewardship because prior to involving money, people were more likely to do the right thing just because it was the right thing to do. When you add financial incentives which may or may not be aligned with acting in the community interest, that changes things, but, not for the better. Certainly not such that removing prior safeguards makes any sense whatsoever. >>> I have searched long and hard for a historical analog to this situation. The best I could find was a policy of the US after the Revolutionary War, which allocated >>property to veterans of that war for free. You had to qualify by being a veteran, the total property available for allocation was limited in size, and the property >>had value. > >> Not an accurate analogue. There was also other land available through a variety >> of other land grants, purchases, and even in some cases, just being the first to >> arrive somewhere and stake a claim. > >> Indeed, since there was no "justified need" basis for land allocation at any point >> prior, the fact that things continued without it on a relatively even keel is kind >> of irrelevant. > > The justification was that you had to be a veteran who fought in the Revolutionary War. > There ARE other addresses available, I have heard that you are aware of IPv6. > Sigh... Even I am not going to attempt to claim that IPv4 and IPv6 addresses are interchangeable equivalents. > >> In the historical case, there were no limits on resale of the allocated land, there were aggregators, there were speculators, and things progressed normally during ?>the allocation time period, and the time period after the land was fully allocated. > >> But there was nothing like needs-basis in the initial allocation and there were >> many other sources of land as well. This simply isn't the case with IPv4. > > There was something like needs-basis. You needed to demonstrate that you were a veteran. > Land was not handed out to just anybody. (Remember, this land had value.) > Sure you could move somewhere else and purchase land, like you can choose to deploy IPv6 or CGN. > Land was being handed out to just anybody. Maybe not that particular land, but, other land. In fact, there were efforts to recruit immigrants from foreign countries based on the promise of land grants. >>> Some people intended to live and farm the land, others intended to sell their allocations. And American law allowed a free market in which these men could decide. >> >>> Rather than judge the benefits of free markets by exceptions like manias and successful market cornering, both rare and shortlived events, why don't we judge >>free markets like our American ancestors did, even if we're Canadian, eh! > >> Completely unregulated free markets have never functioned. All markets >> degrade to the point of requiring the government (or some industry >> organization) to step in and mitigate the issues they create. This is >> not the exception, it is the reality we have seen time and again. > >> Preserving needs basis is merely a rational and good form of regulating >> the IPv4 transfer market to the benefit of the community. > > What is the great benefit that outweighs the danger to Whois of unbooked transfers and the benefits of incentivizing legacy resources to come under RSA? Since your intent is to gut the RSA to the point of rendering it nearly meaningless, I fail to see much benefit remaining in getting legacy resources under said RSA. Indeed, removing the most meaningful provisions of the RSA from those currently subject to its provisions would, IMHO, do much more harm than any amount of unbooked transfers will likely ever do. > Who says my proposal would result in completely unregulated markets? Every transferee would sign an RSA and be subject to ARIN policy. Except that you want to render ARIN policy and the RSA virtually moot in the process. > And with my policy or without my policy, addresses are bound to flow to the highest bidder. If the highest bidder is limited to only those addresses he can justify, then the addresses he couldn't justify flow to the next highest bidder. If the highest bidder is not so limited, then, the addresses likely flow to a very small number of very well capitalized entities to the extreme detriment of smaller entities. > If the policy proposal doesn't fly, it will be to the highest bidder who can show need. More importantly it will be to the highest bidder that can show need and only to the extent of his need, leaving the remaining addresses for some other bidder. > Do you think that we should take more steps to protect the little guy in this event? I don't know. I'd like to see how things develop with the current policy and re-evaluate once we have some experience. As it stands, I do not believe there is community will to do so. > Maybe a price cap? An address czar? Believe it or not, in general, I am opposed to artificial price caps. I hope that by preserving needs basis and removing the opportunities for speculators and other wholesalers attempting to artificially increase prices, we will be able to avoid any need for them. Since I'm not sure what you mean by an address tsar, I have no idea. Owen From owen at delong.com Thu May 12 06:17:40 2011 From: owen at delong.com (Owen DeLong) Date: Thu, 12 May 2011 03:17:40 -0700 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate In-Reply-To: References: <7F5FC4554E42430FADDC0D376164DFA0@mike><0BB63D56-1605-4E1E-8F0B-B2083FDE4A96@delong.com><"BANLkTinTJfYH5sOuqpbiLreMzW3 dH0Ozgg"@mail.gmail.com><16AACD9632484C85BF6B855603CF07B4@mike><4294678C-B653-4BB3-9D40-FD935EA00CF3@eyeconomics.com> <"BE8988B2F6C44DF48FA46C8FD6D0EB27"@mike><3A5E9739CEA64420AB73F106A701DFEB@video ><0835C54BD358411A849B29E1244B07E1@video> <96EBC125-51B8-4BBD-9ED4-3512245137A9@arin.net> Message-ID: On May 11, 2011, at 8:15 PM, Mike Burns wrote: > Hi John, > > Sorry, it was Owen's concept that these numbers had no exclusive right to use, and thus the sale was a legal fiction. Interesting... John described my concept accurately, but, you came up with some completely different concept and called it mine. > (I'm not sure now as the post was long and not included, sorry if I am still being unspecific.) > I'm sure you know that ip addresses show up as listed assets on asset sales. I was not denying this. > Microsoft payed $7.5 million for some addresses. I was not denying this. > I'm tired of the academic arguments about their status as just a valueless string of numbers. It's not an academic argument. > I suppose I could use 1-800-Flowers on my PBX as an extension number, and that makes those numbers valueless. I didn't say they didn't have value. I said there was no such thing as an exclusive right to use an integer. > Maybe the judge should have said exclusive right to advertise them on BGP? Even that would be beyond his jurisdiction. Owen > > Regards, > Mike > > ----- Original Message ----- From: "John Curran" > To: "Mike Burns" > Cc: "Owen DeLong" ; > Sent: Wednesday, May 11, 2011 11:09 PM > Subject: Re: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate > > > On May 11, 2011, at 7:46 PM, Mike Burns wrote: >> The discourse below belongs in 2009. >> Events have moved beyond your decisions about what is legal fiction and what is legal fact. >> You can question the intelligence or judgement of the bankruptcy judge, but not his power or authority. > > Mike - > > Can you be more specific? > > If you are referring to Owen's remark that anyone can make use of any IP > addresses that they wish in the configuration of their own equipment, I > am unaware of any framework which would allow enforcement of a federal > order which specified that "thou shall not configure equipment with IP > address block x.y.z/nn, because exclusive use of it in configuration > files of all devices in the global Internet has been given to party ABC" > > It is an interesting exercise to consider how such a contractual right > could ever be provided, given the distributed nature of the Internet. > > /John > > John Curran > President and CEO > ARIN > From owen at delong.com Thu May 12 06:15:53 2011 From: owen at delong.com (Owen DeLong) Date: Thu, 12 May 2011 03:15:53 -0700 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate In-Reply-To: References: <7F5FC4554E42430FADDC0D376164DFA0@mike><0BB63D56-1605-4E1E-8F0B-B2083FDE4A96@delong.com><16AACD9632484C85BF6B855603CF07B4@mike><59EC8A7F22F247058ED74A896F0C6978@mike><907EE389FDC5448ABC46ADD06420B86D@video><4B99E603-7892-433A-9FB9-DB9A08D98F39@delong.com><599AC4287E79403D939568C89EB40922@video> Message-ID: <997BBFBA-DE10-40AA-9510-0610808B8B12@delong.com> On May 11, 2011, at 8:09 PM, Mike Burns wrote: > Hi Jon, > > Here are some examples of an entity that may want to purchase addresses but not demonstrate need: > > 1. A company with a 5 year planning horizon That company probably wanted to get more address space from the free pool, too. I fail to see a meaningful difference. > 2. A company that wants to provide temporary allocations I suspect I could produce a justified need that would pass muster for such a business. > 3. A company that wants to specialize in very rapid allocations, like same-day service. We call those "ISPs" and they are able to provide justified need under policy today, so, I'm not sure why you figure this would be different going forward. > 4. A company that stocks addresses for sale in to those who would pay more for guaranteed availability I believe providing for such companies to the detriment of other organizations with more immediate need is contrary to the interests of the community and represents one of the many good reasons for preserving needs-basis in transfer policy. > 5. A company who is concerned about future supply. Vs. everyone else who doesn't care? Get real. > 6. A company that wishes to lease address space rather than sell it This could be answered either with my answer to number 3 (lease with network services) or my answer to number 4 (lease without network services). > 7. A company who seeks to buy up small allocations to aggregate them in to larger, more valuable netblocks The end recipient can do this just as effectively and has justified need. The community receives no benefit from this middleman. > 8. A seller of vanity ip addresses like 100.100.100.100 See answer number 4. > 9. A speculator willing to risk money to buy addresses as an investment for anticipated gains in address prices. See answer number 4. > 10. A company whose anticipated need does not begin for 12 months. See answer number 4. > > I'm sure there are many more that I cannot think of. I agree with you that most buyers will have need, and I agree with you that most buyers will see the value of maintaining a valid ARIN whois record pointing to their authority. > > But the policy in APNIC was changed to remove needs requirements for transfers for the same reasons I am requesting its removal here. > My policy proposal also has the benefit of incentivizing legacy resources to come under RSA, and it serves to even the playing field between the disparate rights of legacy versus non-legacy holders. This is not entirely accurate. The transfer policy in APNIC was created without needs basis. It was not modified to remove it. Rendering the RSA mostly moot in order to incentivize legacy holders to sign it is not a win IMHO. > > And my underlying point is the obvious one, that the very act of paying for address space is a very good indication of need, or at least perceived need on the part of the buyer. Which is an assertion that makes me shake my head in dismay. There are many many reasons to pay for address space outside of need. $LARGE_TELCO may want to make life hard for all the independent Telcos and other smaller competitors in their service region. By purchasing very large amounts of address space and then reselling it at a premium, or, worse, merely keeping it, they can parlay their better capitalization into a serious anti-competitive act. Owen > > Regards, > Mike > > > > > ----- Original Message ----- > From: Jonathan Fernatt > To: Mike Burns > Cc: arin-ppml at arin.net > Sent: Wednesday, May 11, 2011 10:55 PM > Subject: Re: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate > > > What is the great benefit that outweighs the danger to Whois of unbooked transfers and the benefits of incentivizing legacy resources to come under RSA? > Who says my proposal would result in completely unregulated markets? Every transferee would sign an RSA and be subject to ARIN policy. > And with my policy or without my policy, addresses are bound to flow to the highest bidder. > If the policy proposal doesn't fly, it will be to the highest bidder who can show need. > Do you think that we should take more steps to protect the little guy in this event? > Maybe a price cap? An address czar? > > > I keep seeing seeing this argument from you Mike. I honestly can't understand why you think the needs requirement is such an obstacle for a company with a legitimate need for addresses that they would have to avoid ARIN altogether. Following that same train of thought, wouldn't it be easier for a company who didn't care about the process or being honest to just falsify their needs justification? > > I deal with tiny tiny tiny companies who have had no problem whatsoever showing need for resources. ARIN staff and policy have always seemed very accommodating from my perspective. > > Have you had a different experience? > > Jon > _______________________________________________ > 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 mike at nationwideinc.com Thu May 12 09:41:34 2011 From: mike at nationwideinc.com (Mike Burns) Date: Thu, 12 May 2011 09:41:34 -0400 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate References: <7F5FC4554E42430FADDC0D376164DFA0@mike> <0BB63D56-1605-4E1E-8F0B-B2083FDE4A96@delong.com> <16AACD9632484C85BF6B855603CF07B4@mike> <4294678C-B653-4BB3-9D40-FD935EA00CF3@eyeconomics.com> Message-ID: Hi Tom, ditto on the detailed response! Yes I am a stickler for procedural fairness, probably that is why I want so few procedures. No, I would not call myself a champion of transparency and public disclosure, though I value information in the market, so there is a tension there. I don't see that my single policy proposal to lift needs analyses for transfers of already allocated addresses exhibits little concern for procedural fairness or transparency. On the contrary, it seeks to reconcile legacy and non-legacy status as a step towards procedural fairness, and it's underlying rationale is related deal transparency. My lifting the needs requirement, deals which would have been transacted "in the dark" due to that requirement would have more incentive to be registered publicly. So I don't get the inconsistency with previous observations which walked us through the forest. Oh, I'm sorry, in rereading the paragraph I can see that you were probably responding to prior posts about private registries. So you feel that my support of the idea of private registries conflicts with my desire to eliminate needs tests for transfers? I find they are both consistent examples of attempts to remove restrictions on the operation of free markets. As far as the DNS private market goes, I don't see the problem with it. I haven't personally had or seen issues with non-uniqueness of domain names. There are more tools to find domain names, there are cottage industries related to the resale of domain names, there are more tlds, there are lifetime registrations, there are cheaper domains. To me, DNS seems to work, and I have been running production DNS servers since 1996. Are there specific problems with the DNS private market that you feel would be absent from a market with a single "public" registrar? I think that would be an instructive conversation to have on the matter of private registries, which has always been a sideline issue to me. I do think that registry services will see some extra pressure, post-exhaust, and maintaining a registry of uniqueness and accessibility will be vital. Hence you haven't seen me arguing to hide information from whois, rather to have whois reflect the real users of the address space, if only to provide accurate points of contact for abuse notifications. I believe that my proposed changes to the ARIN policy would have the effect of cleaning up some old inaccurate whois data (the provision to hold addresses without fear of revokation) and making new registrations more likely through reducing transaction costs in the form of needs analyses. I also hold that it would increase the supply in the transfer markets, creating a safe harbor for those who wish to sell addresses but who fear a utilization review. I believe this will bring down price, benefitting the community both through cheaper access and through the movement of address from under- or dis-use into productive use. But I don't hold that creating private registries will increase registration rates. I hold that eliminating needs requirements will increase registration rates. Regards, Mike ----- Original Message ----- From: "Tom Vest" To: "Mike Burns" Cc: "McTim" ; "Owen DeLong" ; Sent: Thursday, May 12, 2011 4:58 AM Subject: Re: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate Hi Mike, Thanks for the very detailed response. Given the level of scrutiny that you've obviously devoted to this particular transfer transaction, and your repeated emphasis on what could be interpreted as gaps and inconsistencies in the accumulated public disclosures about this matter, I am tempted to assume that you are either a real stickler for legalistic/rule-based/procedural fairness, or a determined champion of transparency and public disclosure -- or perhaps both (?). And yet your policy proposals seem to exhibit very little of those concerns about procedural fairness and transparency -- but quite a bit of the same sort of fairy tale qualities that you disparage in the official account of the Nortel/Microsoft transfer justification. To paraphrase George Berkeley, if a tree falls in the woods but no one's around to hear it (and/or to witness whether it harms any other trees on the way down), do we still believe that it makes a sound? Or would be better to infer from the silence that trees in the forest have become immune to the laws of gravity, or perhaps that falling trees now spontaneously sublimate into gas as soon as they start tilting, thus making both sound and harm impossible? If we put enough distance between ourselves and the forest so that no sound can ever be heard, does that grant us the license to be indifferent as to which of these is (more) true -- or to take any position that appeals to us, regardless of its (in)consistency with previous observations? The same questions come up in the real world. For example, what does the generally low quality of domain-related whois data that is commonly observed in the competitive market for DNS registrar services say about the notion that the price mechanism alone is sufficient to sustain whois meaningful registry/whois participation? [1]. What can be inferred from a situation in which a 100% voluntary (and until very recently, 100% free) registry dedicated to much pricier assets still only attracts participation at levels that would be fatal to an IP number resource registry? HM Land Registry in the UK, for example, just passed the 70% national participation milestone (though participation in some rural counties remains below 50% ) after only 150+ years of membership promotion efforts) [2]. What, if anything, do you think that we can take away from the experiences of other private registries like these? Why should we assume that the private decision making calculus of future transfer market participants will favor registration/disclosure over nondisclosure at rates that are 2-3x higher than observed participation levels in other private registries? For the record, I agree with you that the next few years are certain to test the current registry/whois system more severely than it has ever been tested in the past. I also believe that that system will continue to represent the best and only means at "our" (individual and/or collective) disposal, both for exercising "macro-prudential" judgment in private/commercial matters, and for serving as informed co-participants in "macro-prudential" coordination and oversight activities -- a.k.a. "industry self-governance." These functions are doubly critical in industries like the ours (which in this sense would include banking/finance) that are highly dependent on the consistency (or at least predictability) of transitive commercial interactions. As long as the "typical" inter-domain packet exchange must traverse 3~4 or more separate business entities in order to be completed, there is no reason to believe that "counterparty scrutiny" (or peer-mediated / "market discipline") alone will be sufficient to keep this industry afloat -- no matter how we reinforce those bilateral levers with (ironclad contracts | secure protocols | interpersonal relationships | faith in the rationality of markets). The banking industry learned that lesson the hard way not so long ago -- or at least I'd like to think that parts of it did, even if there hasn't been any obvious change in the pace or direction of financial activity migration away from the "light" of reciprocal disclosure and limited transparency, and into the "shadows" where nobody knows nothing. Regardless, I think that *we* should take advantage of the opportunity to learn from this episode, even if bankers themselves don't. Considering that Internet industry members still enjoy the kind of operational autonomy and freedom of private action that US banks once had -- until their own self-governance mechanisms stopped working (and the Fed took over, c. 1907), the stakes on the line during the next few years really couldn't be higher... TV, speaking form myself alone On May 11, 2011, at 5:12 PM, Mike Burns wrote: > Hi Tom and welcome to this particular discussion, > > The current legal realities I referenced are the implications of the > public information associated with the MS/Nortel deal. > > In this forum I have argued that the public bankruptcy documents reveal > that the addresses transferred from Nortel to MS were not originally > allocated to Nortel, but represented some accumulation of addresses > allocated to Nortel's "predecessors in interest" who were Nortel > acquisitions from the 1990s. > > I argued that MS and Nortel negotiated a deal to sell all the addresses > in that accretion, although the public documents reveal that Microsoft was > able to bid on an amount smaller than the entire lot. > > After the original asset sale agreement between MS and Nortel was > negotiated, ARIN became aware of the transaction, and after some > negotiations with the parties at interest, and some changes to the > MS/Nortel asset agreement, made a press release claiming that the transfer > could proceed under existing ARIN policy. > > ARIN later revealed the policy utilized to be NRPM 8.3, which requires > four things which may or may not have actually happened: > > 1. Addresses are supposed to be issued back to ARIN and then reissued to > the recipient, Microsoft, and the bankruptcy docs did not reveal this > happened in any way. > 2. Address are supposed to be transferred as a single aggregate, but if > the addresses were an assortment of netblocks from prior Nortel > acquisitions, this could not have happened. > 3. Recipients were required to sign an RSA, MS signed a modified LRSA. > 4. Finally, the requirement at issue here, a needs analysis had to be > completed by ARIN, which magically showed that MS qualified for exactly > the amount already bid for and negotiated the sale of. > > If they had needed fewer addresses, they could have bid for less than the > full pool. > If they needed more addresses, they should have received an additional > ARIN allocation. > Paraphrasing Goldilocks, the random allocation of addresses to long-ago > Nortel acquisitions was "just right." > > My reading of the bankruptcy documents leads me to the conclusion that the > bankruptcy judge found that Nortel had the exclusive right to transfer the > addresses, even though the judge had not been informed of any > ex-post-facto NRPM 8.2 transfer from the original registrants to Nortel. > To me, this means he was convinced that ARIN had no rights over > transferring the addresses, although ARIN has rights over reflecting that > transfer in Whois. This is consistent with a declaration by the head of > ARIN at the time in the Kremen case where he stated that ARIN has no > authority over legacy addresses. > > My argument is that the apparent success of RIR stewardship (although I > claim many of the allocated and unrouted addresses represent failures > here) over the last two decades is laudable and represents an obvious > requirement in the stewardship of free pool resources, but is unnecessary > in a post-exhaust age where the price of addresses will ensure efficient > use. > > I also argue that in the post-exhaust age, conflicts over claims to > address rights will likely increase, putting more pressure on Whois to > accurately represent reality. > > Regards, > Mike Burns > > > > > > > ----- Original Message ----- From: "Tom Vest" > To: "Mike Burns" > Cc: "McTim" ; "Owen DeLong" ; > > Sent: Wednesday, May 11, 2011 4:34 PM > Subject: Re: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois > Accurate > > > Hi Mike, > > While it may or may not be true that your perspective on this question is > consonant with that of "the APNIC community," elements within said > community have been championing the same broad policy changes that you're > advocating here now since the early 1990s. Thus it would seem that the > views that you associate yourself with here couldn't possible have > anything to do with "current legal realities" -- unless perhaps by > "current" you mean something like "twentieth century." > > Given that historical fact -- and the apparent success of the RIR > stewardship mission over the intervening two decades of possible > nonconformity with legal reality -- on what basis could you legitimately > claim that abandoning time-tested registry practices that have been > integral to maintaining whois accuracy to date represents the best, or > perhaps the only way to maintain whois accuracy in the future? > > Alternately, if you actually had in mind some other, more recent legal > developments -- which by definition could not have any causal relation to > policy arguments that predated them by 10-15 years -- a clarification of > exactly what those changes in legal reality are would be much appreciated. > > Thanks, > > TV > > > On May 11, 2011, at 3:13 PM, Mike Burns wrote: > >> Hi Owen and McTim, >> >> I, along with the APNIC community, could make the claim that you are >> abandoning the stewardship role in maintaining Whois accuracy, and >> sacrificing that stewardship role on the altar of an ARIN needs policy >> developed for the purposes of free pool allocations that does not comply >> with current legal realities. >> >> But charges of abandoning stewardship are inflammatory, and I hope we can >> keep to actual discussions of the implications of my proposal without >> casting aspersions. >> >> Let's agree that we all seek the highest standards of stewardship, but >> disagree on how those standards should be applied. >> >> I think I could characterize your opposition better by saying that you >> believe the danger of hoarding and speculation outweigh the risk to whois >> accuracy. >> Would that be an accurate statement, if not your exclusive objection to >> the proposal? >> >> Regards, >> Mike >> >> >> >> ----- Original Message ----- From: "McTim" >> To: "Owen DeLong" >> Cc: "Mike Burns" ; >> Sent: Wednesday, May 11, 2011 2:53 PM >> Subject: Re: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois >> Accurate >> >> >> On Wed, May 11, 2011 at 9:09 PM, Owen DeLong wrote: >>> I oppose the policy as written. >> >> +1 >> >> >>> Abandoning our stewardship role for the sake of making it more likely >>> people will register their misappropriation of community resources is >>> like legalizing bank robbery in the hopes that the thieves will pay >>> income tax on their ill gotten gains. >> >> ;-) >> >> -- >> Cheers, >> >> McTim >> "A name indicates what we seek. An address indicates where it is. A >> route indicates how we get there." Jon Postel >> _______________________________________________ >> 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 mike at nationwideinc.com Thu May 12 10:00:28 2011 From: mike at nationwideinc.com (Mike Burns) Date: Thu, 12 May 2011 10:00:28 -0400 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate References: <7F5FC4554E42430FADDC0D376164DFA0@mike><0BB63D56-1605-4E1E-8F0B-B2083FDE4A96@delong.com><16AACD9632484C85BF6B855603CF07B4@mike><59EC8A7F22F247058ED74A896F0C6978@mike><907EE389FDC5448ABC46ADD06420B86D@video> Message-ID: <0E0411543CDB471A8EA7F68DBC174EB9@mike> Hi Jimmy, > > It is little different than use of a forged LOA, really. > The network operator will typically take _anything_ that looks like > plausible documentation. > If the document is forged or otherwise invalid, the responsibility is > now on the customer's head, > and the network operator can plead ignorance. > This is my experience as well. The network operator requires a CoverYourAss document from the entity seeking routing of their addresses. When the likelihood of conflicting claims potentially rising after the free pool empties, this behavior on the part of network operators might no longer be sufficient. The network operator community probably would like access to a reliable authoritative registry. . > > This is not a problem with addressing policy; it's a weakness of the > routing system, It's only a problem with addressing policy if policy drives registrants away. > and certified resources / RPKI could eventually offer a solution. Agreed. > But legitimate organizations would usually like some certainty that > they have the > IP addresses, they are on record as having the IP addresses, they are > under > proper agreement, and they won't incur a disruption or loss of number > resources > impacting their business as a result of not doing things right and > having mucked up records. > I agree completely that legitimate businesses hate FUD and want reliable registration and control of their addresses. Regards, Mike From matthew at matthew.at Thu May 12 11:23:53 2011 From: matthew at matthew.at (Matthew Kaufman) Date: Thu, 12 May 2011 08:23:53 -0700 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate In-Reply-To: References: <7F5FC4554E42430FADDC0D376164DFA0@mike> <0BB63D56-1605-4E1E-8F0B-B2083FDE4A96@delong.com> <16AACD9632484C85BF6B855603CF07B4@mike> <59EC8A7F22F247058ED74A896F0C6978@mike> <907EE389FDC5448ABC46ADD06420B86D@video> <4B99E603-7892-433A-9FB9-DB9A08D98F39@delong.com> <599AC4287E79403D939568C89EB40922@video> Message-ID: <4DCBFB89.6010804@matthew.at> On 5/12/2011 2:57 AM, Owen DeLong wrote: > On May 11, 2011, at 7:41 PM, Mike Burns wrote: > > >> There ARE other addresses available, I have heard that you are aware of IPv6. >> > Sigh... Even I am not going to attempt to claim that IPv4 and IPv6 addresses are > interchangeable equivalents. > I keep hearing arguments that the price of IPv4 addresses won't go infinitely high because at some price it'll be more cost-effective to switch to IPv6 than to try to keep shuffling the IPv4 deck chairs. If that is true, then IPv4 and IPv6 addresses *are* economically interchangeable, just as coal is an imperfect substitute for natural gas when it comes to generating electric power... at some point the cost of one or the other gets high enough that the cost of switching is lower. >> And with my policy or without my policy, addresses are bound to flow to the highest bidder. > If the highest bidder is limited to only those addresses he can justify, then the addresses he > couldn't justify flow to the next highest bidder. If the highest bidder is not so limited, then, the > addresses likely flow to a very small number of very well capitalized entities to the extreme > detriment of smaller entities. The addresses will likely flow to a very small number of very well capitalized entities in any event... the only question is what type of entity they are. In Mike's world they flow to folks who do things like lease address space and sell blocks at high prices to people who really need them... in your world they flow to the top N ISPs that are experts at showing need, aren't constrained by the 3-month rules, and are growing sufficiently to justify anything. In Mike's world, you can get service from whoever you want but the price of space is high... in your world the price of (what is now provider-assigned) space is high and your choice of transit providers is limited. In theory both of these options are bad enough that people switch to IPv6. Matthew Kaufman From vixie at vix.com Thu May 12 11:30:12 2011 From: vixie at vix.com (Paul Vixie) Date: Thu, 12 May 2011 15:30:12 +0000 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate In-Reply-To: (Mike Burns's message of "Thu, 12 May 2011 09:41:34 -0400") References: <7F5FC4554E42430FADDC0D376164DFA0@mike> <0BB63D56-1605-4E1E-8F0B-B2083FDE4A96@delong.com> <16AACD9632484C85BF6B855603CF07B4@mike> <4294678C-B653-4BB3-9D40-FD935EA00CF3@eyeconomics.com> Message-ID: mike at nationwideinc.com ("Mike Burns") writes: > As far as the DNS private market goes, I don't see the problem with it. see , with raw data at . internet resource holders (whether names or numbers) will *not* show more accountability than is required of them by the rest of us. From mike at nationwideinc.com Thu May 12 11:43:56 2011 From: mike at nationwideinc.com (Mike Burns) Date: Thu, 12 May 2011 11:43:56 -0400 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate References: <7F5FC4554E42430FADDC0D376164DFA0@mike><0BB63D56-1605-4E1E-8F0B-B2083FDE4A96@delong.com><16AACD9632484C85BF6B855603CF07B4@mike><4294678C-B653-4BB3-9D40-FD935EA00CF3@eyeconomics.com> Message-ID: Hi Paul, >From the article: "ICANN requires registrars to enforce the accuracy of their customers' Whois records, and the leading registrars are often quite strict about complying with this rule." So if ICANN already requires this and fails to police it, why do you assume that ICANN would police their own records if private registrars did not exist? Regards, Mike ----- Original Message ----- From: "Paul Vixie" To: Sent: Thursday, May 12, 2011 11:30 AM Subject: Re: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate > mike at nationwideinc.com ("Mike Burns") writes: > >> As far as the DNS private market goes, I don't see the problem with it. > > see > , > with raw data at . > > internet resource holders (whether names or numbers) will *not* show more > accountability than is required of them by the rest of us. > _______________________________________________ > 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 12 12:35:26 2011 From: tvest at eyeconomics.com (Tom Vest) Date: Thu, 12 May 2011 12:35:26 -0400 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate In-Reply-To: References: <7F5FC4554E42430FADDC0D376164DFA0@mike> <0BB63D56-1605-4E1E-8F0B-B2083FDE4A96@delong.com> <16AACD9632484C85BF6B855603CF07B4@mike> <4294678C-B653-4BB3-9D40-FD935EA00CF3@eyeconomics.com> Message-ID: <6332CACB-1F07-4036-AC1E-FE9CF448DE82@eyeconomics.com> On May 12, 2011, at 11:30 AM, Paul Vixie wrote: > mike at nationwideinc.com ("Mike Burns") writes: > >> As far as the DNS private market goes, I don't see the problem with it. > > see , > with raw data at . > > internet resource holders (whether names or numbers) will *not* show more > accountability than is required of them by the rest of us. Ahh thanks Paul for the reminder that I forgot to to add supporting references for the claims I made last night... Corrections inline below... On May 12, 2011, at 4:58 AM, Tom Vest wrote: > Hi Mike, > > Thanks for the very detailed response. > Given the level of scrutiny that you've obviously devoted to this particular transfer transaction, and your repeated emphasis on what could be interpreted as gaps and inconsistencies in the accumulated public disclosures about this matter, I am tempted to assume that you are either a real stickler for legalistic/rule-based/procedural fairness, or a determined champion of transparency and public disclosure -- or perhaps both (?). > > And yet your policy proposals seem to exhibit very little of those concerns about procedural fairness and transparency -- but quite a bit of the same sort of fairy tale qualities that you disparage in the official account of the Nortel/Microsoft transfer justification. To paraphrase George Berkeley, if a tree falls in the woods but no one's around to hear it (and/or to witness whether it harms any other trees on the way down), do we still believe that it makes a sound? Or would be better to infer from the silence that trees in the forest have become immune to the laws of gravity, or perhaps that falling trees now spontaneously sublimate into gas as soon as they start tilting, thus making both sound and harm impossible? If we put enough distance between ourselves and the forest so that no sound can ever be heard, does that grant us the license to be indifferent as to which of these is (more) true -- or to take any position that appeals to us, regardless of its (in)consistency with previous observations? > The same questions come up in the real world. For example, what does the generally low quality of domain-related whois data that is commonly observed in the competitive market for DNS registrar services say about the notion that the price mechanism alone is sufficient to sustain whois meaningful registry/whois participation? [1]. [1] National Opinion Research Center. (2010). Draft Report for the Study of the Accuracy of WHOIS Registrant Contact Information. http://www.icann.org/en/compliance/reports/whois-accuracy-study-17jan10-en.pdf (see esp. p. 14, which I interpret as indicating that appx. 77% of domain registrant records exhibit some combination of deficiencies that would both (a) make them more-or-less useless for many operational communication/coordination requirements, and as a consequence (b) likely cause them to be flagged as nonconforming (if not something worse still) if someone tried to use them in a number resource registry. > What can be inferred from a situation in which a 100% voluntary (and until very recently, 100% free) registry dedicated to much pricier assets still only attracts participation at levels that would be fatal to an IP number resource registry? HM Land Registry in the UK, for example, just passed the 70% national participation milestone (though participation in some rural counties remains below 50% ) after only 150+ years of membership promotion efforts) [2]. What, if anything, do you think that we can take away from the experiences of other private registries like these? Why should we assume that the private decision making calculus of future transfer market participants will favor registration/disclosure over nondisclosure at rates that are 2-3x higher than observed participation levels in other private registries? [2] HM Land Registry: http://www.landreg.gov.uk/ See esp. http://www1.landregistry.gov.uk/upload/documents/regdevmap.pdf for county-level "coverage" (or registry participation levels) c. late 2010. Lots of other interesting/challenging stuff here, esp. for anyone who assumes that a highly professional and 100% free registry would surely attract high levels of participation. TV > For the record, I agree with you that the next few years are certain to test the current registry/whois system more severely than it has ever been tested in the past. I also believe that that system will continue to represent the best and only means at "our" (individual and/or collective) disposal, both for exercising "macro-prudential" judgment in private/commercial matters, and for serving as informed co-participants in "macro-prudential" coordination and oversight activities -- a.k.a. "industry self-governance." These functions are doubly critical in industries like the ours (which in this sense would include banking/finance) that are highly dependent on the consistency (or at least predictability) of transitive commercial interactions. As long as the "typical" inter-domain packet exchange must traverse 3~4 or more separate business entities in order to be completed, there is no reason to believe that "counterparty scrutiny" (or peer-mediated / "market discipline") alone will be sufficient to keep this industry afloat -- no matter how we reinforce those bilateral levers with (ironclad contracts | secure protocols | interpersonal relationships | faith in the rationality of markets). > > The banking industry learned that lesson the hard way not so long ago -- or at least I'd like to think that parts of it did, even if there hasn't been any obvious change in the pace or direction of financial activity migration away from the "light" of reciprocal disclosure and limited transparency, and into the "shadows" where nobody knows nothing. Regardless, I think that *we* should take advantage of the opportunity to learn from this episode, even if bankers themselves don't. Considering that Internet industry members still enjoy the kind of operational autonomy and freedom of private action that US banks once had -- until their own self-governance mechanisms stopped working (and the Fed took over, c. 1907), the stakes on the line during the next few years really couldn't be higher... > > TV, speaking form myself alone From mike at nationwideinc.com Thu May 12 13:00:19 2011 From: mike at nationwideinc.com (Mike Burns) Date: Thu, 12 May 2011 13:00:19 -0400 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate References: <7F5FC4554E42430FADDC0D376164DFA0@mike><0BB63D56-1605-4E1E-8F0B-B2083FDE4A96@delong.com><16AACD9632484C85BF6B855603CF07B4@mike><4294678C-B653-4BB3-9D40-FD935EA00CF3@eyeconomics.com> <6332CACB-1F07-4036-AC1E-FE9CF448DE82@eyeconomics.com> Message-ID: Hi Tom, I still don't see the connection between my proposal to drop needs requirements for transfers and the participation rate of DNS whois or the UK land office. I may be missing something obvious, though. My whole goal is to increase accuracy in Whois, and I am not relying on any financial or price mechanism for that increase. I have not argued that pricing will increase registration, I have argued that pricing will ensure productive use. I have no policies related to private registries, if you are discussing the idea of private registries, then I have some context, but that discussion would not belong with this subject line. (On the subject of subject lines, I will give a nod to the poster who complained about the advocacy buried in the name of the proposed policy. My tounge was in my cheek when I named it that, I'm lucky I didn't call it the Defense of Whois Proposal!) Regards, Mike ----- Original Message ----- From: "Tom Vest" To: Cc: "Paul Vixie" Sent: Thursday, May 12, 2011 12:35 PM Subject: Re: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate > > > On May 12, 2011, at 11:30 AM, Paul Vixie wrote: > >> mike at nationwideinc.com ("Mike Burns") writes: >> >>> As far as the DNS private market goes, I don't see the problem with it. >> >> see >> , >> with raw data at . >> >> internet resource holders (whether names or numbers) will *not* show more >> accountability than is required of them by the rest of us. > > Ahh thanks Paul for the reminder that I forgot to to add supporting > references for the claims I made last night... > > Corrections inline below... > > On May 12, 2011, at 4:58 AM, Tom Vest wrote: > >> Hi Mike, >> >> Thanks for the very detailed response. >> Given the level of scrutiny that you've obviously devoted to this >> particular transfer transaction, and your repeated emphasis on what could >> be interpreted as gaps and inconsistencies in the accumulated public >> disclosures about this matter, I am tempted to assume that you are >> either a real stickler for legalistic/rule-based/procedural fairness, or >> a determined champion of transparency and public disclosure -- or perhaps >> both (?). >> >> And yet your policy proposals seem to exhibit very little of those >> concerns about procedural fairness and transparency -- but quite a bit of >> the same sort of fairy tale qualities that you disparage in the official >> account of the Nortel/Microsoft transfer justification. To paraphrase >> George Berkeley, if a tree falls in the woods but no one's around to hear >> it (and/or to witness whether it harms any other trees on the way down), >> do we still believe that it makes a sound? Or would be better to infer >> from the silence that trees in the forest have become immune to the laws >> of gravity, or perhaps that falling trees now spontaneously sublimate >> into gas as soon as they start tilting, thus making both sound and harm >> impossible? If we put enough distance between ourselves and the forest so >> that no sound can ever be heard, does that grant us the license to be >> indifferent as to which of these is (more) true -- or to take any >> position that appeals to us, regardless of its (in)consistenc > y with previous observations? >> The same questions come up in the real world. For example, what does the >> generally low quality of domain-related whois data that is commonly >> observed in the competitive market for DNS registrar services say about >> the notion that the price mechanism alone is sufficient to sustain whois >> meaningful registry/whois participation? [1]. > > [1] National Opinion Research Center. (2010). Draft Report for the Study > of the Accuracy of WHOIS Registrant Contact Information. > http://www.icann.org/en/compliance/reports/whois-accuracy-study-17jan10-en.pdf > > (see esp. p. 14, which I interpret as indicating that appx. 77% of domain > registrant records exhibit some combination of deficiencies that would > both (a) make them more-or-less useless for many operational > communication/coordination requirements, and as a consequence (b) likely > cause them to be flagged as nonconforming (if not something worse still) > if someone tried to use them in a number resource registry. > >> What can be inferred from a situation in which a 100% voluntary (and >> until very recently, 100% free) registry dedicated to much pricier assets >> still only attracts participation at levels that would be fatal to an IP >> number resource registry? HM Land Registry in the UK, for example, just >> passed the 70% national participation milestone (though participation in >> some rural counties remains below 50% ) after only 150+ years of >> membership promotion efforts) [2]. What, if anything, do you think that >> we can take away from the experiences of other private registries like >> these? Why should we assume that the private decision making calculus of >> future transfer market participants will favor registration/disclosure >> over nondisclosure at rates that are 2-3x higher than observed >> participation levels in other private registries? > > [2] HM Land Registry: http://www.landreg.gov.uk/ > See esp. http://www1.landregistry.gov.uk/upload/documents/regdevmap.pdf > for county-level "coverage" (or registry participation levels) c. late > 2010. > > Lots of other interesting/challenging stuff here, esp. for anyone who > assumes that a highly professional and 100% free registry would surely > attract high levels of participation. > > TV > > >> For the record, I agree with you that the next few years are certain to >> test the current registry/whois system more severely than it has ever >> been tested in the past. I also believe that that system will continue to >> represent the best and only means at "our" (individual and/or collective) >> disposal, both for exercising "macro-prudential" judgment in >> private/commercial matters, and for serving as informed co-participants >> in "macro-prudential" coordination and oversight activities -- a.k.a. >> "industry self-governance." These functions are doubly critical in >> industries like the ours (which in this sense would include >> banking/finance) that are highly dependent on the consistency (or at >> least predictability) of transitive commercial interactions. As long as >> the "typical" inter-domain packet exchange must traverse 3~4 or more >> separate business entities in order to be completed, there is no reason >> to believe that "counterparty scrutiny" (or peer-mediated / "market >> discipline") alone > will be sufficient to keep this industry afloat -- no matter how we > reinforce those bilateral levers with (ironclad contracts | secure > protocols | interpersonal relationships | faith in the rationality of > markets). >> >> The banking industry learned that lesson the hard way not so long ago -- >> or at least I'd like to think that parts of it did, even if there hasn't >> been any obvious change in the pace or direction of financial activity >> migration away from the "light" of reciprocal disclosure and limited >> transparency, and into the "shadows" where nobody knows nothing. >> Regardless, I think that *we* should take advantage of the opportunity to >> learn from this episode, even if bankers themselves don't. Considering >> that Internet industry members still enjoy the kind of operational >> autonomy and freedom of private action that US banks once had -- until >> their own self-governance mechanisms stopped working (and the Fed took >> over, c. 1907), the stakes on the line during the next few years really >> couldn't be higher... >> >> TV, speaking form myself alone > _______________________________________________ > 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 12 12:57:10 2011 From: owen at delong.com (Owen DeLong) Date: Thu, 12 May 2011 09:57:10 -0700 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate In-Reply-To: <0E0411543CDB471A8EA7F68DBC174EB9@mike> References: <7F5FC4554E42430FADDC0D376164DFA0@mike><0BB63D56-1605-4E1E-8F0B-B2083FDE4A96@delong.com><16AACD9632484C85BF6B855603CF07B4@mike><59EC8A7F22F247058ED74A896F0C6978@mike><907EE389FDC5448ABC46ADD06420B86D@video> <0E0411543CDB471A8EA7F68DBC174EB9@mike> Message-ID: On May 12, 2011, at 7:00 AM, Mike Burns wrote: > Hi Jimmy, > >> >> It is little different than use of a forged LOA, really. >> The network operator will typically take _anything_ that looks like >> plausible documentation. >> If the document is forged or otherwise invalid, the responsibility is >> now on the customer's head, >> and the network operator can plead ignorance. >> > > This is my experience as well. > The network operator requires a CoverYourAss document from the entity seeking routing of their addresses. > When the likelihood of conflicting claims potentially rising after the free pool empties, this behavior on the part of network operators might no longer be sufficient. > The network operator community probably would like access to a reliable authoritative registry. > . Or, more accurately, network operators may place increasing value on registry data as authoritative and instruct those without registry entries to get that resolved if they want their space routed. >> >> This is not a problem with addressing policy; it's a weakness of the >> routing system, > > It's only a problem with addressing policy if policy drives registrants away. > I suspect this will be progressively less of a problem, actually. >> and certified resources / RPKI could eventually offer a solution. > > Agreed. > >> But legitimate organizations would usually like some certainty that >> they have the >> IP addresses, they are on record as having the IP addresses, they are under >> proper agreement, and they won't incur a disruption or loss of number >> resources >> impacting their business as a result of not doing things right and >> having mucked up records. >> > > I agree completely that legitimate businesses hate FUD and want reliable registration and control of their addresses. > Which would support continuation of needs basis and preservation of the terms of the RSA. Owen From owen at delong.com Thu May 12 13:02:07 2011 From: owen at delong.com (Owen DeLong) Date: Thu, 12 May 2011 10:02:07 -0700 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate In-Reply-To: <4DCBFB89.6010804@matthew.at> References: <7F5FC4554E42430FADDC0D376164DFA0@mike> <0BB63D56-1605-4E1E-8F0B-B2083FDE4A96@delong.com> <16AACD9632484C85BF6B855603CF07B4@mike> <59EC8A7F22F247058ED74A896F0C6978@mike> <907EE389FDC5448ABC46ADD06420B86D@video> <4B99E603-7892-433A-9FB9-DB9A08D98F39@delong.com> <599AC4287E79403D939568C89EB40922@video> <4DCBFB89.6010804@matthew.at> Message-ID: <463771E5-094B-48CB-BAD7-C6D51088C26E@delong.com> On May 12, 2011, at 8:23 AM, Matthew Kaufman wrote: > On 5/12/2011 2:57 AM, Owen DeLong wrote: >> On May 11, 2011, at 7:41 PM, Mike Burns wrote: >> >> >>> There ARE other addresses available, I have heard that you are aware of IPv6. >>> >> Sigh... Even I am not going to attempt to claim that IPv4 and IPv6 addresses are >> interchangeable equivalents. >> > > I keep hearing arguments that the price of IPv4 addresses won't go infinitely high because at some price it'll be more cost-effective to switch to IPv6 than to try to keep shuffling the IPv4 deck chairs. > You haven't heard that argument from me and I'm not convinced it is accurate. > If that is true, then IPv4 and IPv6 addresses *are* economically interchangeable, just as coal is an imperfect substitute for natural gas when it comes to generating electric power... at some point the cost of one or the other gets high enough that the cost of switching is lower. > Since it may not be true... With coal vs. CNG, you have a single party able to make the switch deterministically for themselves. With IPv4 vs. IPv6, you have a myriad of third-party dependencies in your ability to switch from one to the other and have it actually work out. This significantly changes the underlying assumptions. >>> And with my policy or without my policy, addresses are bound to flow to the highest bidder. >> If the highest bidder is limited to only those addresses he can justify, then the addresses he >> couldn't justify flow to the next highest bidder. If the highest bidder is not so limited, then, the >> addresses likely flow to a very small number of very well capitalized entities to the extreme >> detriment of smaller entities. > > The addresses will likely flow to a very small number of very well capitalized entities in any event... the only question is what type of entity they are. In Mike's world they flow to folks who do things like lease address space and sell blocks at high prices to people who really need them... in your world they flow to the top N ISPs that are experts at showing need, aren't constrained by the 3-month rules, and are growing sufficiently to justify anything. > I think the results are actually the top N ISPs in both cases eventually. The difference is that Mike's resultant value of N tends to be much smaller than mine. > In Mike's world, you can get service from whoever you want but the price of space is high... in your world the price of (what is now provider-assigned) space is high and your choice of transit providers is limited. > I really don't see how you come to these conclusions. My argument is that under Mike's proposed policy, your choice of providers would become more limited. > In theory both of these options are bad enough that people switch to IPv6. > Let's hope. Owen From millnert at gmail.com Thu May 12 13:11:10 2011 From: millnert at gmail.com (Martin Millnert) Date: Thu, 12 May 2011 13:11:10 -0400 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate In-Reply-To: <8EBD080A-3150-4269-A73B-BD5724312E6E@delong.com> References: <7F5FC4554E42430FADDC0D376164DFA0@mike> <0BB63D56-1605-4E1E-8F0B-B2083FDE4A96@delong.com> <16AACD9632484C85BF6B855603CF07B4@mike> <59EC8A7F22F247058ED74A896F0C6978@mike> <907EE389FDC5448ABC46ADD06420B86D@video> <8EBD080A-3150-4269-A73B-BD5724312E6E@delong.com> Message-ID: Owen, On Thu, May 12, 2011 at 5:14 AM, Owen DeLong wrote: >>> You left out: >>> >>> 4) The RIR eventually identifies these outliers and reclaims the numbers >>> to be reissued to members of the community willing to comply with policy. >> >> Well, you'd potentially destroy uniqueness if the other party and its >> ISPs disagrees and continues to use the addresses. >> > That is a theoretical risk today with hijackings. I fail to see the difference. Well, in your case *the RIR* is the one doing the hijacking, if it acts against the will of the ISP it takes numbers away from. Regards, Martin From owen at delong.com Thu May 12 13:20:25 2011 From: owen at delong.com (Owen DeLong) Date: Thu, 12 May 2011 10:20:25 -0700 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate In-Reply-To: References: <7F5FC4554E42430FADDC0D376164DFA0@mike> <0BB63D56-1605-4E1E-8F0B-B2083FDE4A96@delong.com> <16AACD9632484C85BF6B855603CF07B4@mike> <59EC8A7F22F247058ED74A896F0C6978@mike> <907EE389FDC5448ABC46ADD06420B86D@video> <8EBD080A-3150-4269-A73B-BD5724312E6E@delong.com> Message-ID: <3A4A01EC-DE3E-4DC8-80EA-523245381FB4@delong.com> On May 12, 2011, at 10:11 AM, Martin Millnert wrote: > Owen, > > On Thu, May 12, 2011 at 5:14 AM, Owen DeLong wrote: >>>> You left out: >>>> >>>> 4) The RIR eventually identifies these outliers and reclaims the numbers >>>> to be reissued to members of the community willing to comply with policy. >>> >>> Well, you'd potentially destroy uniqueness if the other party and its >>> ISPs disagrees and continues to use the addresses. >>> >> That is a theoretical risk today with hijackings. I fail to see the difference. > > Well, in your case *the RIR* is the one doing the hijacking, if it > acts against the will of the ISP it takes numbers away from. > The RIR is not hijacking, it is reclaiming a community resource from someone using it outside of the policies set by the community, just as squatters would be evicted from land if the owner pursues the issue prior to the expiration of the time limits in the adverse possession laws. Indeed, by the community policy definition, it is provider B that is doing the hijacking. Owen From owen at delong.com Thu May 12 13:18:29 2011 From: owen at delong.com (Owen DeLong) Date: Thu, 12 May 2011 10:18:29 -0700 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate In-Reply-To: References: <7F5FC4554E42430FADDC0D376164DFA0@mike><0BB63D56-1605-4E1E-8F0B-B2083FDE4A96@delong.com><16AACD9632484C85BF6B855603CF07B4@mike><4294678C-B653-4BB3-9D40-FD935EA00CF3@eyeconomics.com> <6332CACB-1F07-4036-AC1E-FE9CF448DE82@eyeconomics.com> Message-ID: <707022CC-A086-4FF6-B42C-8D8DA581367D@delong.com> On May 12, 2011, at 10:00 AM, Mike Burns wrote: > Hi Tom, > > I still don't see the connection between my proposal to drop needs requirements for transfers and the participation rate of DNS whois or the UK land office. > I may be missing something obvious, though. > I believe he is arguing that if you turn address policy into a free-for-all (as in your proposal), like DNS, it will decrease, rather than increase whois accuracy. I hadn't thought of this consequence, but, now that Tom and Paul have brought it up, it does make sense. > My whole goal is to increase accuracy in Whois, and I am not relying on any financial or price mechanism for that increase. > And now there is evidence that your proposal would likely have the opposite effect. > I have not argued that pricing will increase registration, I have argued that pricing will ensure productive use. > Which also remains in dispute and unproven. > I have no policies related to private registries, if you are discussing the idea of private registries, then I have some context, but that discussion would not belong with this subject line. > Those, too, would seem contrary to the goal of whois accuracy. Owen From mike at nationwideinc.com Thu May 12 13:26:17 2011 From: mike at nationwideinc.com (Mike Burns) Date: Thu, 12 May 2011 13:26:17 -0400 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate References: <7F5FC4554E42430FADDC0D376164DFA0@mike><0BB63D56-1605-4E1E-8F0B-B2083FDE4A96@delong.com><16AACD9632484C85BF6B855603CF07B4@mike><4294678C-B653-4BB3-9D40-FD935EA00CF3@eyeconomics.com> <6332CACB-1F07-4036-AC1E-FE9CF448DE82@eyeconomics.com> <707022CC-A086-4FF6-B42C-8D8DA581367D@delong.com> Message-ID: <4CEC4E334DBD4D1CBE15A0E208FD55A0@mike> Hi Owen, > >> I still don't see the connection between my proposal to drop needs >> requirements for transfers and the participation rate of DNS whois or the >> UK land office. >> I may be missing something obvious, though. > >I believe he is arguing that if you turn address policy into a free-for-all >(as in your proposal), like >DNS, it will decrease, rather than increase whois accuracy. I hadn't >thought of this consequence, but, >now that Tom and Paul have brought it up, it does make sense. I am still missing the connection between removing needs requirements for transfers and having that decrease whois accuracy. If you can connect the dots, you will go a long way in convincing me that my proposal is flawed. >> My whole goal is to increase accuracy in Whois, and I am not relying on >> any financial or price mechanism for that increase. > >And now there is evidence that your proposal would likely have the opposite >effect. What evidence? >> I have not argued that pricing will increase registration, I have argued >> that pricing will ensure productive use. > >Which also remains in dispute and unproven. >Owen Hence the word argued. Regards, Mike From george.herbert at gmail.com Thu May 12 14:21:06 2011 From: george.herbert at gmail.com (George Herbert) Date: Thu, 12 May 2011 11:21:06 -0700 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate In-Reply-To: References: <7F5FC4554E42430FADDC0D376164DFA0@mike> <0BB63D56-1605-4E1E-8F0B-B2083FDE4A96@delong.com> <16AACD9632484C85BF6B855603CF07B4@mike> <59EC8A7F22F247058ED74A896F0C6978@mike> <907EE389FDC5448ABC46ADD06420B86D@video> <4B99E603-7892-433A-9FB9-DB9A08D98F39@delong.com> <599AC4287E79403D939568C89EB40922@video> Message-ID: On Thu, May 12, 2011 at 2:57 AM, Owen DeLong wrote: >[...] > > ARIN has a moral, if not legal (the legal status is somewhat unknown) to continue to provide > services to the original legacy registrant of certain resources. That obligation is non-transferable. This statement disturbs me, and I do not support it. There's a worldview about the "ownership question" in which this is a valid view, but we do not have community consensus that that's the best worldview to have, and in particular I think it would be endangering the community stewardship role ARIN and other RIRs are supposed to have to be this exclusive. It's reasonable to suggest that RSA, LRSA, or some variant RSA for *current* transfers is a reasonable minimum expectation. Asserting that it's necessary for pre-existing transfers, particularly those by acquisition, where WHOIS was not properly updated but the business and usage are legit, seems ... improper, at this time. I expect ARIN to accurately reflect reality, and not attempt to retcon. -- -george william herbert george.herbert at gmail.com From matthew at matthew.at Thu May 12 14:48:41 2011 From: matthew at matthew.at (Matthew Kaufman) Date: Thu, 12 May 2011 11:48:41 -0700 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate In-Reply-To: <463771E5-094B-48CB-BAD7-C6D51088C26E@delong.com> References: <7F5FC4554E42430FADDC0D376164DFA0@mike> <0BB63D56-1605-4E1E-8F0B-B2083FDE4A96@delong.com> <16AACD9632484C85BF6B855603CF07B4@mike> <59EC8A7F22F247058ED74A896F0C6978@mike> <907EE389FDC5448ABC46ADD06420B86D@video> <4B99E603-7892-433A-9FB9-DB9A08D98F39@delong.com> <599AC4287E79403D939568C89EB40922@video> <4DCBFB89.6010804@matthew.at> <463771E5-094B-48CB-BAD7-C6D51088C26E@delong.com> Message-ID: <8DDDEFF8-91B6-4C38-83C3-EDDEB44E8BE8@matthew.at> On May 12, 2011, at 10:02 AM, Owen DeLong wrote: > > On May 12, 2011, at 8:23 AM, Matthew Kaufman wrote: > >> On 5/12/2011 2:57 AM, Owen DeLong wrote: >>> On May 11, 2011, at 7:41 PM, Mike Burns wrote: >>> >>> >>>> There ARE other addresses available, I have heard that you are aware of IPv6. >>>> >>> Sigh... Even I am not going to attempt to claim that IPv4 and IPv6 addresses are >>> interchangeable equivalents. >>> >> >> I keep hearing arguments that the price of IPv4 addresses won't go infinitely high because at some price it'll be more cost-effective to switch to IPv6 than to try to keep shuffling the IPv4 deck chairs. >> > > You haven't heard that argument from me and I'm not convinced it is accurate. Ok, so what do *you* think is going to happen if the price of IPv4 addresses converges with infinity? > >> If that is true, then IPv4 and IPv6 addresses *are* economically interchangeable, just as coal is an imperfect substitute for natural gas when it comes to generating electric power... at some point the cost of one or the other gets high enough that the cost of switching is lower. >> > > Since it may not be true... > > With coal vs. CNG, you have a single party able to make the switch deterministically for themselves. > With IPv4 vs. IPv6, you have a myriad of third-party dependencies in your ability to switch from > one to the other and have it actually work out. This significantly changes the underlying assumptions. > >>>> And with my policy or without my policy, addresses are bound to flow to the highest bidder. >>> If the highest bidder is limited to only those addresses he can justify, then the addresses he >>> couldn't justify flow to the next highest bidder. If the highest bidder is not so limited, then, the >>> addresses likely flow to a very small number of very well capitalized entities to the extreme >>> detriment of smaller entities. >> >> The addresses will likely flow to a very small number of very well capitalized entities in any event... the only question is what type of entity they are. In Mike's world they flow to folks who do things like lease address space and sell blocks at high prices to people who really need them... in your world they flow to the top N ISPs that are experts at showing need, aren't constrained by the 3-month rules, and are growing sufficiently to justify anything. >> > > I think the results are actually the top N ISPs in both cases eventually. The difference is that Mike's resultant value > of N tends to be much smaller than mine. I'd argue the reverse, actually. If there is a needs basis then the top N ISPs have an advantage in that they are already experts at manipulating the needs basis. (And it really is manipulation, because any of them could actually get by with much much less than they already have if the "need" took into account things like forcing customers to use NAT) One could argue, for instance, that *with* a needs basis Comcast might end up holding nearly all the space... but without a needs basis it might be an investment banking firm instead, who'd then lease the space out to move providers than just Comcast. > >> In Mike's world, you can get service from whoever you want but the price of space is high... in your world the price of (what is now provider-assigned) space is high and your choice of transit providers is limited. >> > > I really don't see how you come to these conclusions. My argument is that under Mike's proposed policy, > your choice of providers would become more limited. I think you've got it backwards... see above. Matthew Kaufman From fernattj at gmail.com Thu May 12 15:02:56 2011 From: fernattj at gmail.com (Jonathan Fernatt) Date: Thu, 12 May 2011 15:02:56 -0400 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate In-Reply-To: <8DDDEFF8-91B6-4C38-83C3-EDDEB44E8BE8@matthew.at> References: <7F5FC4554E42430FADDC0D376164DFA0@mike> <0BB63D56-1605-4E1E-8F0B-B2083FDE4A96@delong.com> <16AACD9632484C85BF6B855603CF07B4@mike> <59EC8A7F22F247058ED74A896F0C6978@mike> <907EE389FDC5448ABC46ADD06420B86D@video> <4B99E603-7892-433A-9FB9-DB9A08D98F39@delong.com> <599AC4287E79403D939568C89EB40922@video> <4DCBFB89.6010804@matthew.at> <463771E5-094B-48CB-BAD7-C6D51088C26E@delong.com> <8DDDEFF8-91B6-4C38-83C3-EDDEB44E8BE8@matthew.at> Message-ID: > > >> The addresses will likely flow to a very small number of very well > capitalized entities in any event... the only question is what type of > entity they are. In Mike's world they flow to folks who do things like lease > address space and sell blocks at high prices to people who really need > them... in your world they flow to the top N ISPs that are experts at > showing need, aren't constrained by the 3-month rules, and are growing > sufficiently to justify anything. > >> > > > > I think the results are actually the top N ISPs in both cases eventually. > The difference is that Mike's resultant value > > of N tends to be much smaller than mine. > > I'd argue the reverse, actually. If there is a needs basis then the top N > ISPs have an advantage in that they are already experts at manipulating the > needs basis. (And it really is manipulation, because any of them could > actually get by with much much less than they already have if the "need" > took into account things like forcing customers to use NAT) > > One could argue, for instance, that *with* a needs basis Comcast might end > up holding nearly all the space... but without a needs basis it might be an > investment banking firm instead, who'd then lease the space out to move > providers than just Comcast. > > > > >> In Mike's world, you can get service from whoever you want but the price > of space is high... in your world the price of (what is now > provider-assigned) space is high and your choice of transit providers is > limited. > >> > > > > I really don't see how you come to these conclusions. My argument is that > under Mike's proposed policy, > > your choice of providers would become more limited. > > I think you've got it backwards... see above. I don't think ARIN compares the specified recipients need to that of Comcast's for example, though. So how would this example apply at all? Am I misunderstanding the NRPM as written? Jon -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcurran at arin.net Thu May 12 15:04:12 2011 From: jcurran at arin.net (John Curran) Date: Thu, 12 May 2011 19:04:12 +0000 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate In-Reply-To: <8DDDEFF8-91B6-4C38-83C3-EDDEB44E8BE8@matthew.at> References: <7F5FC4554E42430FADDC0D376164DFA0@mike> <0BB63D56-1605-4E1E-8F0B-B2083FDE4A96@delong.com> <16AACD9632484C85BF6B855603CF07B4@mike> <59EC8A7F22F247058ED74A896F0C6978@mike> <907EE389FDC5448ABC46ADD06420B86D@video> <4B99E603-7892-433A-9FB9-DB9A08D98F39@delong.com> <599AC4287E79403D939568C89EB40922@video> <4DCBFB89.6010804@matthew.at> <463771E5-094B-48CB-BAD7-C6D51088C26E@delong.com> <8DDDEFF8-91B6-4C38-83C3-EDDEB44E8BE8@matthew.at> Message-ID: On May 12, 2011, at 11:48 AM, Matthew Kaufman wrote: > I'd argue the reverse, actually. If there is a needs basis then the top N ISPs have an advantage in that they are already experts at manipulating the needs basis. (And it really is manipulation, because any of them could actually get by with much much less than they already have if the "need" took into account things like forcing customers to use NAT) > > One could argue, for instance, that *with* a needs basis Comcast might end up holding nearly all the space... but without a needs basis it might be an investment banking firm instead, who'd then lease the space out to move providers than just Comcast. Matthew - If (for argument) we accept the premise that the "invisible hand" of a well- functioning market will result in more efficient resource utilization, then would it also be the case that ARIN should not issue additional IP address space from the available pool based on need, but instead employ a market function to improve the overall efficiency of resource utilization? /John John Curran President and CEO ARIN From mike at nationwideinc.com Thu May 12 15:11:02 2011 From: mike at nationwideinc.com (Mike Burns) Date: Thu, 12 May 2011 15:11:02 -0400 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate References: <7F5FC4554E42430FADDC0D376164DFA0@mike><0BB63D56-1605-4E1E-8F0B-B2083FDE4A96@delong.com><16AACD9632484C85BF6B855603CF07B4@mike><59EC8A7F22F2470 58ED74A896F0C6978@mike><907EE389FDC5448ABC46ADD06420B86D@video><4B99E603-7892- 433A-9FB9-DB9A08D98F39@delong.com><599AC4287E79403D939568C89EB40922@video><4DC BFB89.6010804@matthew.at><463771E5-094B-48CB-BAD7-C6D51088C26E@delong.com><8DDDEFF8-91B6-4C38-83C3-EDDEB44E8BE8@matthew.at> Message-ID: <8335092AD8D44AAF8A74CD8B81E211AA@mike> Hi John, Does ARIN get to keep the money for auctioned addresses? I actually considered that this might be a good use for some last segment of the final /8! As long as the funds were used by ARIN to beef up its legal staff in the effort to increase ARIN's title services. I think ARIN is going to be tasked with making some dicey decisions in the future related to conflicting claims for control of netblocks. It might be a good idea to increase the size of the legal war chest. I am not seriously proposing this, please no flames. I support needs requirements for free pool allocations, even if they are less efficient than the market. Regards, MIke ----- Original Message ----- From: "John Curran" To: "Matthew Kaufman" Cc: Sent: Thursday, May 12, 2011 3:04 PM Subject: Re: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate > On May 12, 2011, at 11:48 AM, Matthew Kaufman wrote: > >> I'd argue the reverse, actually. If there is a needs basis then the top N >> ISPs have an advantage in that they are already experts at manipulating >> the needs basis. (And it really is manipulation, because any of them >> could actually get by with much much less than they already have if the >> "need" took into account things like forcing customers to use NAT) >> >> One could argue, for instance, that *with* a needs basis Comcast might >> end up holding nearly all the space... but without a needs basis it might >> be an investment banking firm instead, who'd then lease the space out to >> move providers than just Comcast. > > Matthew - > > If (for argument) we accept the premise that the "invisible hand" of a > well- > functioning market will result in more efficient resource utilization, > then > would it also be the case that ARIN should not issue additional IP > address > space from the available pool based on need, but instead employ a market > function to improve the overall efficiency of resource utilization? > > /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 info at arin.net Thu May 12 15:18:53 2011 From: info at arin.net (ARIN) Date: Thu, 12 May 2011 15:18:53 -0400 Subject: [arin-ppml] ARIN-prop-149 Improved Transparency for Directed Transfers Message-ID: <4DCC329D.3020202@arin.net> ARIN-prop-149 Improved Transparency for Directed Transfers 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-149 Improved Transparency for Directed Transfers Proposal Originator: Owen DeLong Proposal Version: 1 Date: 12 May 2011 Proposal type: new Policy term: permanent Policy statement: Add the following to section 8.3 of the NRPM (where 8.3.[a..z] are replaced with appropriate new subsection numbers when incorporated into the NRPM) 8.3.a In order to provide greater transparency in the transfer process and provide the community the best set of tools to make routing decisions as prefix disaggregation increases as a result of the transfer market, ARIN shall maintain and publish a list of all prefixes transfered under section 8.3. The list will identify the original prefix and each subordinate prefix transferred under this policy and the date each prefix was transferred. 8.3.b Upon activation of this policy, ARIN shall include in the list at the earliest possible time all prefixes which have been transferred under section 8.3 to date. Rationale: The community has a right to know which prefixes have been added or are the result of transfer-related disaggregation. This will provide accurate data in a central well-known location. Timetable for implementation: immediate From jcurran at arin.net Thu May 12 15:27:30 2011 From: jcurran at arin.net (John Curran) Date: Thu, 12 May 2011 19:27:30 +0000 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate In-Reply-To: <8335092AD8D44AAF8A74CD8B81E211AA@mike> References: <7F5FC4554E42430FADDC0D376164DFA0@mike> <0BB63D56-1605-4E1E-8F0B-B2083FDE4A96@delong.com> <"BANLkTinTJfYH5sOuqpbiLreMzW3 dH0Ozgg"@mail.gmail.com> <16AACD9632484C85BF6B855603CF07B4@mike> <"59EC8A7F22F2470 58ED74A896F0C6978"@mike> <907EE389FDC5448ABC46ADD06420B86D@video> <"4B99E603-7892- 433A-9FB9-DB9A08D98F39"@delong.com> <599AC4287E79403D939568C89EB40922@video> <"4DC BFB89.6010804"@matthew.at> <463771E5-094B-48CB-BAD7-C6D51088C26E@delong.com> <8DDDEFF8-91B6-4C38-83C3-EDDEB44E8BE8@matthew.at> <8335092AD8D44AAF8A74CD8B81E211AA@mike> Message-ID: <4BF11C3A-955D-4EF4-8455-ACB008AFC513@arin.net> On May 12, 2011, at 12:11 PM, Mike Burns wrote: > Does ARIN get to keep the money for auctioned addresses? > I actually considered that this might be a good use for some last segment of the final /8! > As long as the funds were used by ARIN to beef up its legal staff in the effort to increase ARIN's title services. > I think ARIN is going to be tasked with making some dicey decisions in the future related to conflicting claims for control of netblocks. > It might be a good idea to increase the size of the legal war chest. > I am not seriously proposing this, please no flames. While I believe we have adequate legal reserves, I'm certain ARIN's legal folks appreciate the thought... :-) > I support needs requirements for free pool allocations, even if they are less efficient than the market. Good to know. Can you elaborate why the (presumed) inferior efficiency of needs-based allocations is acceptable in this case, but it is not acceptable as a requirement for the transfer market? Thanks! /John John Curran President and CEO ARIN From cengel at conxeo.com Thu May 12 15:35:27 2011 From: cengel at conxeo.com (Chris Engel) Date: Thu, 12 May 2011 15:35:27 -0400 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate In-Reply-To: <3A4A01EC-DE3E-4DC8-80EA-523245381FB4@delong.com> References: <7F5FC4554E42430FADDC0D376164DFA0@mike> <0BB63D56-1605-4E1E-8F0B-B2083FDE4A96@delong.com> <16AACD9632484C85BF6B855603CF07B4@mike> <59EC8A7F22F247058ED74A896F0C6978@mike> <907EE389FDC5448ABC46ADD06420B86D@video> <8EBD080A-3150-4269-A73B-BD5724312E6E@delong.com> <3A4A01EC-DE3E-4DC8-80EA-523245381FB4@delong.com> Message-ID: > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf Of Owen DeLong > Sent: Thursday, May 12, 2011 1:20 PM > To: Martin Millnert > Cc: arin-ppml at arin.net > Subject: Re: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate > > > On May 12, 2011, at 10:11 AM, Martin Millnert wrote: > > > Owen, > > > > On Thu, May 12, 2011 at 5:14 AM, Owen DeLong > wrote: > >>>> You left out: > >>>> > >>>> 4) The RIR eventually identifies these outliers and reclaims the > numbers > >>>> to be reissued to members of the community willing to comply with > policy. > >>> > >>> Well, you'd potentially destroy uniqueness if the other party and its > >>> ISPs disagrees and continues to use the addresses. > >>> > >> That is a theoretical risk today with hijackings. I fail to see the difference. > > > > Well, in your case *the RIR* is the one doing the hijacking, if it > > acts against the will of the ISP it takes numbers away from. > > > The RIR is not hijacking, it is reclaiming a community resource from someone > using it outside of the policies set by the community, just as squatters would > be > evicted from land if the owner pursues the issue prior to the expiration of > the time limits in the adverse possession laws. > > Indeed, by the community policy definition, it is provider B that is doing the > hijacking. > > Owen > Owen, It seems to me that the above analogy is a little problematic. With land there is a clear legal ownership which is enforced by an outside governing authority. Ownership of the land encompasses within it the legal right to exclude others from using that property. The governing authority has the legal (and practical) power to enforce the ownership rules it recognizes. Your own stance, in previous postings here seems to have been that numbers (i.e. IP addresses) can't be "owned". If that's the case neither ARIN, nor anyone else possesses the legal authority to exclude an entity from their use. (Absent a Court or Government Agency proclaiming the contrary) Unless I misunderstand the situation here (which admittedly I may) ARIN has no real legal authority over the address spaces it registers. It's a self-appointed non-profit, not a government agency.... and has no real legal authority to regulate address usage outside of the individual contracts it has with many organizations. Therefore, if an organization never entered into a contract with ARIN, it really has no legal mechanism for regulating it's use of any particular set of addresses. Do I misunderstand the nature of ARIN as an organization? In practical terms, ARIN's, functional authority seems to derive from the fact that most of the organizations responsible for routing traffic voluntarily accept it as the official keeper of records for what address space belongs to whom. Would that be a correct summation? It seems to me that if ARIN started reclaiming address space from those organizations (or their clients) on any sort of significant scale, it would pretty rapidly risk undermining it's own authority and relevance to them. Whether, ARIN, from a policy standpoint has the technical ability to do so, strikes me as somewhat ancillary as to whether it would actually be a good idea for them to do so. As a hypothetical, if an extremely large organization which had no contractual arrangement with ARIN believed it had legitimate claim to a certain address blocks. I would assume that many of the ISP's who were financially dependent on that organization would be inclined to route said block regardless of what ARIN might have to say about it. I would also presume that it would be in ARIN's self-interest to generally try and recognize the legitimacy of such claim, if at all possible... and try to get that organization into some sort of contractual relationship so that it could exert some sort of legal authority. Are those presumptions reasonable? Christopher Engel (Representing only my own private views) From mike at nationwideinc.com Thu May 12 15:39:42 2011 From: mike at nationwideinc.com (Mike Burns) Date: Thu, 12 May 2011 15:39:42 -0400 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate References: <7F5FC4554E42430FADDC0D376164DFA0@mike><0BB63D56-1605-4E1E-8F0B-B2083FDE4A96@delong.com><"BANLkTinTJfYH5sOuqpbiLreMzW3 dH0Ozgg"@mail.gmail.com><16AACD9632484C85BF6B855603CF07B4@mike> <"59EC8A7F22F247058ED74A896F0C6978"@mike> <907EE389FDC5448ABC46ADD06420B86D@video> <"4B99E603-7892-433A-9FB9-DB9A08D98F39"@delong.com> <599AC4287E79403D939568C89EB40922@video> <"4DCBFB89.6010804"@matthew.at> <463771E5-094B-48CB-BAD7-C6D51088C26E@delong.com><8DDDEFF8-91B6-4C38-83C3-EDDEB44E8BE8@matthew.at><8335092AD8D44AAF8A74CD8B81E211AA@mike> <4BF11C3A-955D-4EF4-8455-ACB008AFC513@arin.net> Message-ID: <8B12F2DF738B408987C1CF1B4A87E705@mike> Hi John, >> I support needs requirements for free pool allocations, even if they are >> less efficient than the market. >Good to know. Can you elaborate why the (presumed) inferior >efficiency of needs-based allocations is acceptable in this >case, but it is not acceptable as a requirement for the transfer >market? I think a needs-based system was required for free-pool allocations because there had to be some constraint in the distribution of scarce resources for free. When scarce resources are allocated without a price constraint, we have the Tragedy of the Commons. Since presumably even a child could understand that some constraint had to be placed on their allocation to prevent somebody from simply taking them all, the question became what type of constraint should be employed that would be consistent with prudential stewardship of finite Internet resources. I think the decision to dole them out to those who could demonstrate a need for them was reasonable and laudable. Once they have all been thus doled out, however, and the era of monetized transfers begin, I rely on the forces of the market to put valuable resources to productive use, generally. (I am not really arguing efficiency in my proposal, though, I am arguing for reduction in transactional burdens which can lead to under-registration of transfers of address rights.) It could be that the needs requirements for the distribution of the final free pool addresses will more efficiently distribute them than the market will at this point in time. Regards, Mike From matthew at matthew.at Thu May 12 15:51:38 2011 From: matthew at matthew.at (Matthew Kaufman) Date: Thu, 12 May 2011 12:51:38 -0700 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate In-Reply-To: References: <7F5FC4554E42430FADDC0D376164DFA0@mike> <0BB63D56-1605-4E1E-8F0B-B2083FDE4A96@delong.com> <16AACD9632484C85BF6B855603CF07B4@mike> <59EC8A7F22F247058ED74A896F0C6978@mike> <907EE389FDC5448ABC46ADD06420B86D@video> <4B99E603-7892-433A-9FB9-DB9A08D98F39@delong.com> <599AC4287E79403D939568C89EB40922@video> <4DCBFB89.6010804@matthew.at> <463771E5-094B-48CB-BAD7-C6D51088C26E@delong.com> <8DDDEFF8-91B6-4C38-83C3-EDDEB44E8BE8@matthew.at> Message-ID: <02540BF3-D17E-4069-BC98-ECC29053A4CA@matthew.at> On May 12, 2011, at 12:04 PM, John Curran wrote: > On May 12, 2011, at 11:48 AM, Matthew Kaufman wrote: > >> I'd argue the reverse, actually. If there is a needs basis then the top N ISPs have an advantage in that they are already experts at manipulating the needs basis. (And it really is manipulation, because any of them could actually get by with much much less than they already have if the "need" took into account things like forcing customers to use NAT) >> >> One could argue, for instance, that *with* a needs basis Comcast might end up holding nearly all the space... but without a needs basis it might be an investment banking firm instead, who'd then lease the space out to move providers than just Comcast. > > Matthew - > > If (for argument) we accept the premise that the "invisible hand" of a well- > functioning market will result in more efficient resource utilization, then > would it also be the case that ARIN should not issue additional IP address > space from the available pool based on need, but instead employ a market > function to improve the overall efficiency of resource utilization? That probably should have started years ago. We might not be at runout today if the price had been set properly... and ARIN would have lots more money for lawyers. Matthew Kaufman From cengel at conxeo.com Thu May 12 16:15:50 2011 From: cengel at conxeo.com (Chris Engel) Date: Thu, 12 May 2011 16:15:50 -0400 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate In-Reply-To: <02540BF3-D17E-4069-BC98-ECC29053A4CA@matthew.at> References: <7F5FC4554E42430FADDC0D376164DFA0@mike> <0BB63D56-1605-4E1E-8F0B-B2083FDE4A96@delong.com> <16AACD9632484C85BF6B855603CF07B4@mike> <59EC8A7F22F247058ED74A896F0C6978@mike> <907EE389FDC5448ABC46ADD06420B86D@video> <4B99E603-7892-433A-9FB9-DB9A08D98F39@delong.com> <599AC4287E79403D939568C89EB40922@video> <4DCBFB89.6010804@matthew.at> <463771E5-094B-48CB-BAD7-C6D51088C26E@delong.com> <8DDDEFF8-91B6-4C38-83C3-EDDEB44E8BE8@matthew.at> <02540BF3-D17E-4069-BC98-ECC29053A4CA@matthew.at> Message-ID: > On May 12, 2011, at 12:04 PM, John Curran wrote: > > > On May 12, 2011, at 11:48 AM, Matthew Kaufman wrote: > > > >> I'd argue the reverse, actually. If there is a needs basis then the top N ISPs > have an advantage in that they are already experts at manipulating the > needs basis. (And it really is manipulation, because any of them could actually > get by with much much less than they already have if the "need" took into > account things like forcing customers to use NAT) > >> > >> One could argue, for instance, that *with* a needs basis Comcast might > end up holding nearly all the space... but without a needs basis it might be an > investment banking firm instead, who'd then lease the space out to move > providers than just Comcast. > > > > Matthew - > > > > If (for argument) we accept the premise that the "invisible hand" of a > well- > > functioning market will result in more efficient resource utilization, then > > would it also be the case that ARIN should not issue additional IP address > > space from the available pool based on need, but instead employ a > market > > function to improve the overall efficiency of resource utilization? > > That probably should have started years ago. We might not be at runout > today if the price had been set properly... and ARIN would have lots more > money for lawyers. > > Matthew Kaufman > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. That's an interesting dynamic. In scarcity market, where an IP Address might have significant financial value, what's to prevent dishonest actors from simply "manufacturing" need in order to gain said resources? Hypothetically, if and IP Address costs $.25 each.....what would stop an actor from creating an "ip enabled virtual pet rock" project where each "virtual pet rock" cost $.05 each and manufacturing a plausible rationale for why each such "virtual pet rock" required a routable public IP...and then grabbing up as much space as they could afford? It strikes me that all a "needs" based regulatory system would accomplish under such conditions would be to force the regulatory agency (ARIN) into some very problematic and somewhat arbitrary decision making on what projects constituted "legitimate need" and which didn't.....and would essentially weight the system in favor of those who were more experienced at "gaming" the system. A scarcity market would definitely seem to create a different dynamic then what would exist were the resource in plentiful supply. Christopher Engel (representing only my own personal views) From tedm at ipinc.net Thu May 12 16:23:52 2011 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Thu, 12 May 2011 13:23:52 -0700 Subject: [arin-ppml] Just a reminder of some quick mathematics for IPv4 that shows the long term impossibility of it Message-ID: <4DCC41D8.1010305@ipinc.net> From the following website: http://www.internetworldstats.com/stats.htm Notice - as of 2009/2010 (last time these figures were updated): WORLD INTERNET USAGE AND POPULATION STATISTICS WORLD TOTAL Population Internet Users Latest Data Penetration (% Population) 6,845,609,960 1,966,514,816 28.7 % From the beginning of public access of the Internet in 1995 we are now about a year away from complete global IPv4 runout. Assuming maybe by then we are at a global penetration of 35% of maybe 7 billion people, that's still only about 2.5 billion people on the Internet. So how exactly do we get the other 4.5 billion people on the Internet using IPv4? The last "legacy" IP block was handed out in 1997. To assume that unused legacy IPv4 will cover the remaining 4.5 billion people assumes that 65% of the usable IPv4 space was handed out before 1997 and the remaining 35% of it was handed out from 1998 until next year. It is a ridiculous assumption completely unsupported by the math. But, don't let something like mathematics bog your day down! It's much more fun to believe that Adam Smith's "Invisible hand" will come sailing in at the last minute and manufacture IPv4 out of thin air! ;-) Ted From jcurran at arin.net Thu May 12 16:42:17 2011 From: jcurran at arin.net (John Curran) Date: Thu, 12 May 2011 20:42:17 +0000 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate In-Reply-To: References: <7F5FC4554E42430FADDC0D376164DFA0@mike> <0BB63D56-1605-4E1E-8F0B-B2083FDE4A96@delong.com> <16AACD9632484C85BF6B855603CF07B4@mike> <59EC8A7F22F247058ED74A896F0C6978@mike> <907EE389FDC5448ABC46ADD06420B86D@video> <8EBD080A-3150-4269-A73B-BD5724312E6E@delong.com> <3A4A01EC-DE3E-4DC8-80EA-523245381FB4@delong.com> Message-ID: On May 12, 2011, at 12:35 PM, Chris Engel wrote: > Unless I misunderstand the situation here (which admittedly I may) ARIN has no real legal authority over the address spaces it registers. It's a self-appointed non-profit, not a government agency.... and has no real legal authority to regulate address usage outside of the individual contracts it has with many organizations. Therefore, if an organization never entered into a contract with ARIN, it really has no legal mechanism for regulating it's use of any particular set of addresses. Do I misunderstand the nature of ARIN as an organization? Chris - ARIN maintains a database of registry entries in accordance with policies developed by the community. ARIN does not need any "regulatory" powers for administration of its registry on behalf of the community. > In practical terms, ARIN's, functional authority seems to derive from the fact that most of the organizations responsible for routing traffic voluntarily accept it as the official keeper of records for what address space belongs to whom. Would that be a correct summation? ARIN's usefulness relies upon that acceptance. > It seems to me that if ARIN started reclaiming address space from those organizations (or their clients) on any sort of significant scale, it would pretty rapidly risk undermining it's own authority and relevance to them. Whether, ARIN, from a policy standpoint has the technical ability to do so, strikes me as somewhat ancillary as to whether it would actually be a good idea for them to do so. That's not necessarily true at all - ARIN has to manage the registry per the policies the community develops, even if that results in actions that are individually unpopular to any given organization. While some policies may be individually unpopular, they are adopted because they are recognized as collectively necessary for efficient Internet operations. > As a hypothetical, if an extremely large organization which had no contractual arrangement with ARIN believed it had legitimate claim to a certain address blocks. I would assume that many of the ISP's who were financially dependent on that organization would be inclined to route said block regardless of what ARIN might have to say about it. I would also presume that it would be in ARIN's self-interest to generally try and recognize the legitimacy of such claim, if at all possible... and try to get that organization into some sort of contractual relationship so that it could exert some sort of legal authority. Are those presumptions reasonable? Correct, but presumably, many of the same ISP's who were financially dependent on that type of organization would also be inclined to make policies which resulted in the minimum number of conflicts possible. FYI, /John John Curran President and CEO ARIN From mike at nationwideinc.com Thu May 12 16:44:49 2011 From: mike at nationwideinc.com (Mike Burns) Date: Thu, 12 May 2011 16:44:49 -0400 Subject: [arin-ppml] Just a reminder of some quick mathematics for IPv4 thatshows the long term impossibility of it References: <4DCC41D8.1010305@ipinc.net> Message-ID: Hi Ted, I don't think anybody made the claim that IPv4 had enough unique addresses to give one to each person on the planet. Nor was there a claim that the Invisible Hand would create any address space. However, there is enough space to give everybody their own unique IPv4 address + TCP port. Even their own thousand unique IPv4 address+TCP ports. 3.8billion times 65,000 is a very large number. Food for thought? Regards, Mike ----- Original Message ----- From: "Ted Mittelstaedt" To: Sent: Thursday, May 12, 2011 4:23 PM Subject: [arin-ppml] Just a reminder of some quick mathematics for IPv4 thatshows the long term impossibility of it > From the following website: > > http://www.internetworldstats.com/stats.htm > > Notice - as of 2009/2010 (last time these figures were updated): > > > WORLD INTERNET USAGE AND POPULATION STATISTICS WORLD TOTAL > > Population Internet Users Latest Data Penetration (% Population) > 6,845,609,960 1,966,514,816 28.7 % > > > From the beginning of public access of the Internet in 1995 we > are now about a year away from complete global IPv4 runout. Assuming > maybe by then we are at a global penetration of 35% of maybe 7 billion > people, that's still only about 2.5 billion people on the Internet. > > So how exactly do we get the other 4.5 billion people on the Internet > using IPv4? > > The last "legacy" IP block was handed out in 1997. To assume that > unused legacy IPv4 will cover the remaining 4.5 billion people assumes > that 65% of the usable IPv4 space was handed out before 1997 and the > remaining 35% of it was handed out from 1998 until next year. It is > a ridiculous assumption completely unsupported by the math. > > But, don't let something like mathematics bog your day down! It's much > more fun to believe that Adam Smith's "Invisible hand" will come sailing > in at the last minute and manufacture IPv4 out of thin air! ;-) > > > Ted > > > > _______________________________________________ > 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 mike at nationwideinc.com Thu May 12 16:56:16 2011 From: mike at nationwideinc.com (Mike Burns) Date: Thu, 12 May 2011 16:56:16 -0400 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate References: <7F5FC4554E42430FADDC0D376164DFA0@mike><0BB63D56-1605-4E1E-8F0B-B2083FDE4A96@delong.com><16AACD9632484C85BF6B855603CF07B4@mike><59EC8A7F22F2470 58ED74A896F0C6978@mike><907EE389FDC5448ABC46ADD06420B86D@video><4B99E603-7892- 433A-9FB9-DB9A08D98F39@delong.com><599AC4287E79403D939568C89EB40922@video><4DC BFB89.6010804@matthew.at><463771E5-094B-48CB-BAD7-C6D51088C26E@delong.com><8DDDEFF8-91B6-4C38-83C3-EDDEB44E8BE8@matthew.at><02540BF3-D17E-4069-BC98-ECC29053A4CA@matthew.at> Message-ID: Hi Chris, > > That's an interesting dynamic. In scarcity market, where an IP Address > might have significant financial value, what's to prevent dishonest actors > from simply "manufacturing" need in order to gain said resources? > > Hypothetically, if and IP Address costs $.25 each.....what would stop an > actor from creating an "ip enabled virtual pet rock" project where each > "virtual pet rock" cost $.05 each and manufacturing a plausible rationale > for why each such "virtual pet rock" required a routable public IP...and > then grabbing up as much space as they could afford? > > It strikes me that all a "needs" based regulatory system would accomplish > under such conditions would be to force the regulatory agency (ARIN) into > some very problematic and somewhat arbitrary decision making on what > projects constituted "legitimate need" and which didn't.....and would > essentially weight the system in favor of those who were more experienced > at "gaming" the system. > > A scarcity market would definitely seem to create a different dynamic then > what would exist were the resource in plentiful supply. > > > Christopher Engel > (representing only my own personal views) > > I would think ARIN would only issue the IPs based on actual sales of the pet rocks. Pet Rocks! You must be old! ;-) But your point is well taken by me, at least. There has been some talk on the list both in support of ARIN's needs analysis procedures, and some talk to the effect that it can be gamed. Incentives towards gaming will only increase along with value of IP address space. Regards, Mike From JOHN at egh.com Thu May 12 16:59:00 2011 From: JOHN at egh.com (John Santos) Date: Thu, 12 May 2011 16:59:00 -0400 Subject: [arin-ppml] ARIN-prop-149 Improved Transparency for Directed Transfers In-Reply-To: <4DCC329D.3020202@arin.net> Message-ID: <1110512163051.1401B-100000@Ives.egh.com> On Thu, 12 May 2011, ARIN wrote: > 8.3.a In order to provide greater transparency in the transfer process > and provide the community the best set of tools to make routing > decisions as prefix disaggregation increases as a result of the transfer > market, ARIN shall maintain and publish a list of all prefixes > transfered under section 8.3. The list will identify the original prefix > and each subordinate prefix transferred under this policy and the date > each prefix was transferred. If the same prefix is transfered multiple times, will the historical record be maintained? E.G. org A transfers to org B on date 1, and then org B transfers to org C on date 2, would both transfers be reflected in the list? If org B disaggregated the prefix and transfered part of it to org C and part to org D, would all 3 transfers be reflected in the list (A -> B, B -> C, B -> D)? Would how org A acquired the prefix in the first place, and whether it was a larger prefix than what it transfered to org B, also be reflected in the list, or is this information already available some place else, such as in whois, and thus redundant? I think it is important to include exactly what information is to be maintained in the policy proposal, or we may find out it is not as useful as hoped. -- John Santos Evans Griffiths & Hart, Inc. 781-861-0670 ext 539 From jcurran at arin.net Thu May 12 17:14:10 2011 From: jcurran at arin.net (John Curran) Date: Thu, 12 May 2011 21:14:10 +0000 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate In-Reply-To: References: <7F5FC4554E42430FADDC0D376164DFA0@mike><0BB63D56-1605-4E1E-8F0B-B2083FDE4A96@delong.com><16AACD9632484C85BF6B855603CF07B4@mike><59EC8A7F22F2470 58ED74A896F0C6978@mike><907EE389FDC5448ABC46ADD06420B86D@video><4B99E603-7892- 433A-9FB9-DB9A08D98F39@delong.com><599AC4287E79403D939568C89EB40922@video><4DC BFB89.6010804@matthew.at><463771E5-094B-48CB-BAD7-C6D51088C26E@delong.com><8DDDEFF8-91B6-4C38-83C3-EDDEB44E8BE8@matthew.at><02540BF3-D17E-4069-BC98-ECC29053A4CA@matthew.at> Message-ID: On May 12, 2011, at 1:56 PM, Mike Burns wrote: > There has been some talk on the list both in support of ARIN's needs analysis procedures, and some talk to the effect that it can be gamed. > Incentives towards gaming will only increase along with value of IP address space. Mike - I'll actually disagree with the presumption that incentives towards gaming will increase with the value of IP address space, if we are considering a transfer market with needs-based qualification. While it is true that there might be incentive to get creative with the total expressed need to obtain more space than otherwise qualified for, the existence of a market (if properly functioning) means that there is some reassurance that additional space will more likely be available when needed in the future, even if at a slightly increased price. This actually reduces the pressure to try and game the system when compared with the present environment and potential that there will be no more resources in the free pool when you come back later. The other potential form of gaming would by a non-operator speculator, who wishes to participate in the market (despite having no actual need at all), and so needs to fabricate imaginary need to be able to obtain IP space from the market for subsequent monetization. While there is no doubt of the incentives involved, there is also significant risk since intangible IP registration entries are readily corrected in such cases of fraudulent representations to the registry. FYI, /John John Curran President and CEO ARIN From mike at nationwideinc.com Thu May 12 17:25:16 2011 From: mike at nationwideinc.com (Mike Burns) Date: Thu, 12 May 2011 17:25:16 -0400 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate References: <7F5FC4554E42430FADDC0D376164DFA0@mike><0BB63D56-1605-4E1E-8F0B-B2083FDE4A96@delong.com><16AACD9632484C85BF6B855603CF07B4@mike><59EC8A7F22F2470 58ED74A896F0C6978@mike><907EE389FDC5448ABC46ADD06420B86D@video><4B99E603-7892- 433A-9FB9-DB9A08D98F39@delong.com><599AC4287E79403D939568C89EB40922@video><4DC BFB89.6010804@matthew.at><463771E5-094B-48CB-BAD7-C6D51088C26E@delong.com><8DDDEFF8-91B6-4C38-83C3-EDDEB44E8BE8@matthew.at><02540BF3-D17E-4069-BC98-ECC29053A4CA@matthew.at> Message-ID: <7834D82CC7C64E64820785568E598738@mike> Ola John, > I'll actually disagree with the presumption that incentives towards > gaming will increase with the value of IP address space, if we are > considering a transfer market with needs-based qualification. While > it is true that there might be incentive to get creative with the > total expressed need to obtain more space than otherwise qualified > for, the existence of a market (if properly functioning) means that > there is some reassurance that additional space will more likely be > available when needed in the future, even if at a slightly increased > price. This actually reduces the pressure to try and game the system > when compared with the present environment and potential that there > will be no more resources in the free pool when you come back later. > The other potential form of gaming would by a non-operator speculator, > who wishes to participate in the market (despite having no actual need > at all), and so needs to fabricate imaginary need to be able to obtain > IP space from the market for subsequent monetization. While there is no > doubt of the incentives involved, there is also significant risk since > intangible IP registration entries are readily corrected in such cases > of fraudulent representations to the registry. If the needs requirement can not be met by the buyer, he will have the incentive to game the needs requirement. If the value of the addresses at question are higher, the incentive will be higher, to my mind. But you are absolutely correct in that having a vibrant and functioning market is the best way to assuage fears of future supply shocks and attendant price increases. And you are correct in that the incentive to game the system for allocations from the free pool is reaching its highest point in the months to come. Pray be diligent! As far as what you term a non-operator speculator, you see the risk of gaming the needs analysis. The same risks lead to not-notifying ARIN and continuing to use the addresses under the purchaser's name, leaving Whois in more disarray. Regards, Mike From jcurran at arin.net Thu May 12 17:44:34 2011 From: jcurran at arin.net (John Curran) Date: Thu, 12 May 2011 21:44:34 +0000 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate In-Reply-To: <7834D82CC7C64E64820785568E598738@mike> References: <7F5FC4554E42430FADDC0D376164DFA0@mike><0BB63D56-1605-4E1E-8F0B-B2083FDE4A96@delong.com><16AACD9632484C85BF6B855603CF07B4@mike><59EC8A7F22F2470 58ED74A896F0C6978@mike><907EE389FDC5448ABC46ADD06420B86D@video><4B99E603-7892- 433A-9FB9-DB9A08D98F39@delong.com><599AC4287E79403D939568C89EB40922@video><4DC BFB89.6010804@matthew.at><463771E5-094B-48CB-BAD7-C6D51088C26E@delong.com><8DDDEFF8-91B6-4C38-83C3-EDDEB44E8BE8@matthew.at><02540BF3-D17E-4069-BC98-ECC29053A4CA@matthew.at> <7834D82CC7C64E64820785568E598738@mike> Message-ID: <7F3FEA3D-7D65-4576-8FD7-EA8A7010C176@arin.net> On May 12, 2011, at 2:25 PM, Mike Burns wrote: > As far as what you term a non-operator speculator, you see the risk of gaming the needs analysis. > The same risks lead to not-notifying ARIN and continuing to use the addresses under the purchaser's name, leaving Whois in more disarray. That is a potential risk that some will take, whereas others may decide to avoid doing speculation in this particular market. One other point regarding transfers from a party with actual need - the risks may increase depending on any policy constraints on the supplier of the IP addressees (e.g. if you qualify based on need, but the party you're getting them from does not have that amount of space in contiguous blocks that match policy constraints, or if you are seeking a small number of addresses which is less than any minimum size requirement, etc.) /John John Curran President and CEO ARIN From owen at delong.com Thu May 12 17:59:41 2011 From: owen at delong.com (Owen DeLong) Date: Thu, 12 May 2011 14:59:41 -0700 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate In-Reply-To: References: <7F5FC4554E42430FADDC0D376164DFA0@mike> <0BB63D56-1605-4E1E-8F0B-B2083FDE4A96@delong.com> <16AACD9632484C85BF6B855603CF07B4@mike> <59EC8A7F22F247058ED74A896F0C6978@mike> <907EE389FDC5448ABC46ADD06420B86D@video> <4B99E603-7892-433A-9FB9-DB9A08D98F39@delong.com> <599AC4287E79403D939568C89EB40922@video> Message-ID: On May 12, 2011, at 11:21 AM, George Herbert wrote: > On Thu, May 12, 2011 at 2:57 AM, Owen DeLong wrote: >> [...] >> >> ARIN has a moral, if not legal (the legal status is somewhat unknown) to continue to provide >> services to the original legacy registrant of certain resources. That obligation is non-transferable. > > This statement disturbs me, and I do not support it. > Interesting... > There's a worldview about the "ownership question" in which this is a > valid view, but we do not have community consensus that that's the > best worldview to have, and in particular I think it would be > endangering the community stewardship role ARIN and other RIRs are > supposed to have to be this exclusive. > I don't believe that's true. I believe the portion of my statement that you take issue with below reflects the current practice at ARIN, but, is not part of what you quoted. > It's reasonable to suggest that RSA, LRSA, or some variant RSA for > *current* transfers is a reasonable minimum expectation. Asserting > that it's necessary for pre-existing transfers, particularly those by > acquisition, where WHOIS was not properly updated but the business and > usage are legit, seems ... improper, at this time. > It is current practice and has been for several years. > I expect ARIN to accurately reflect reality, and not attempt to retcon. > To a certain extent, I agree. However, transfers outside of policy (an acquisition fits nicely in 8.2, actually, in most circumstances) are not really reality, they are, in essence, hijacking of community resources. Should an organization be able to imagine that they are entitled to something and then have ARIN reflect their imagination as reality? I am not so convinced. Owen From mike at nationwideinc.com Thu May 12 18:05:25 2011 From: mike at nationwideinc.com (Mike Burns) Date: Thu, 12 May 2011 18:05:25 -0400 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate References: <7F5FC4554E42430FADDC0D376164DFA0@mike><0BB63D56-1605-4E1E-8F0B-B2083FDE4A96@delong.com><16AACD9632484C85BF6B855603CF07B4@mike><59EC8A7F22F2470 58ED74A896F0C6978@mike><907EE389FDC5448ABC46ADD06420B86D@video><4B99E603-7892- 433A-9FB9-DB9A08D98F39@delong.com><599AC4287E79403D939568C89EB40922@video><4DC BFB89.6010804@matthew.at><463771E5-094B-48CB-BAD7-C6D51088C26E@delong.com><8DDDEFF8-91B6-4C38-83C3-EDDEB44E8BE8@matthew.at><02540BF3-D17E-4069-BC98-ECC29053A4CA@matthew.at><7834D82CC7C64E648207855 68E598738@mike> <7F3FEA3D-7D65-4576-8FD7-EA8A7010C176@arin.net> Message-ID: >> As far as what you term a non-operator speculator, you see the risk of >> gaming the needs analysis. >> The same risks lead to not-notifying ARIN and continuing to use the >> addresses under the purchaser's name, leaving Whois in more disarray. >That is a potential risk that some will take, whereas others may >decide to avoid doing speculation in this particular market. Yup, they can ignore ARIN, game ARIN, or not speculate under current needs-based policy for transfers. >One other point regarding transfers from a party with actual need - >the risks may increase depending on any policy constraints on the >supplier of the IP addressees (e.g. if you qualify based on need, >but the party you're getting them from does not have that amount >of space in contiguous blocks that match policy constraints, or if >you are seeking a small number of addresses which is less than any >minimum size requirement, etc.) >/John John, I'm not really clear on what you mean here. I always assumed there was a buyer and a seller first, then an ARIN needs assessment later. I figured the buyer and seller would reach agreement on what amount is being transferred, and then they would ask ARIN to bless the deal. I know that you have been pleading for some advance consideration of transfer policy as deals are being formulated. So I think it's worth asking for clarification of the last paragraph. Thanks, Mike From millnert at gmail.com Thu May 12 18:07:49 2011 From: millnert at gmail.com (Martin Millnert) Date: Thu, 12 May 2011 18:07:49 -0400 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate In-Reply-To: <7F3FEA3D-7D65-4576-8FD7-EA8A7010C176@arin.net> References: <7F5FC4554E42430FADDC0D376164DFA0@mike> <0BB63D56-1605-4E1E-8F0B-B2083FDE4A96@delong.com> <16AACD9632484C85BF6B855603CF07B4@mike> <907EE389FDC5448ABC46ADD06420B86D@video> <599AC4287E79403D939568C89EB40922@video> <463771E5-094B-48CB-BAD7-C6D51088C26E@delong.com> <8DDDEFF8-91B6-4C38-83C3-EDDEB44E8BE8@matthew.at> <02540BF3-D17E-4069-BC98-ECC29053A4CA@matthew.at> <7834D82CC7C64E64820785568E598738@mike> <7F3FEA3D-7D65-4576-8FD7-EA8A7010C176@arin.net> Message-ID: Hi John, On Thu, May 12, 2011 at 5:44 PM, John Curran wrote: > On May 12, 2011, at 2:25 PM, Mike Burns wrote: >> As far as what you term a non-operator speculator, you see the risk of gaming the needs analysis. >> The same risks lead to not-notifying ARIN and continuing to use the addresses under the purchaser's name, leaving Whois in more disarray. > > That is a potential risk that some will take, whereas others may > decide to avoid doing speculation in this particular market. > > One other point regarding transfers from a party with actual need - > the risks may increase depending on any policy constraints on the > supplier of the IP addressees (e.g. if you qualify based on need, > but the party you're getting them from does not have that amount > of space in contiguous blocks that match policy constraints, or if > you are seeking a small number of addresses which is less than any > minimum size requirement, etc.) How do you value need in terms of $ ? Allowing correct price discovery is essential for any market to function well. Perhaps it is possible to simply binary stamp a buy request approved or rejected, before it can be allowed to bid on objects on the market? Essentially saying 'trader X has been approved for the purchase of /21 worth of IP addresses', or something like this. Comments? Regards, Martin From jcurran at arin.net Thu May 12 18:13:25 2011 From: jcurran at arin.net (John Curran) Date: Thu, 12 May 2011 22:13:25 +0000 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate In-Reply-To: References: <7F5FC4554E42430FADDC0D376164DFA0@mike><0BB63D56-1605-4E1E-8F0B-B2083FDE4A96@delong.com><16AACD9632484C85BF6B855603CF07B4@mike><59EC8A7F22F2470 58ED74A896F0C6978@mike><907EE389FDC5448ABC46ADD06420B86D@video><4B99E603-7892- 433A-9FB9-DB9A08D98F39@delong.com><599AC4287E79403D939568C89EB40922@video><4DC BFB89.6010804@matthew.at><463771E5-094B-48CB-BAD7-C6D51088C26E@delong.com><8DDDEFF8-91B6-4C38-83C3-EDDEB44E8BE8@matthew.at><02540BF3-D17E-4069-BC98-ECC29053A4CA@matthew.at><7834D82CC7C64E648207855 68E598738@mike> <7F3FEA3D-7D65-4576-8FD7-EA8A7010C176@arin.net> Message-ID: <62C67842-6EFA-46E3-9F14-6A5B6AF4AFAF@arin.net> On May 12, 2011, at 3:05 PM, Mike Burns wrote: > >> One other point regarding transfers from a party with actual need - >> the risks may increase depending on any policy constraints on the >> supplier of the IP addressees (e.g. if you qualify based on need, >> but the party you're getting them from does not have that amount >> of space in contiguous blocks that match policy constraints, or if >> you are seeking a small number of addresses which is less than any >> minimum size requirement, etc.) >> /John > > John, I'm not really clear on what you mean here. We've had discussions of various policy constraints that may apply to the seller of the IP address space, e.g. the manner in which they may subdivide existing address blocks for purposes of a transfer. Obviously, such constraints may result in a hurdle that encourages parties to game the system in order to perform a transfer. /John John Curran President and CEO ARIN From jcurran at arin.net Thu May 12 18:16:27 2011 From: jcurran at arin.net (John Curran) Date: Thu, 12 May 2011 22:16:27 +0000 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate In-Reply-To: References: <7F5FC4554E42430FADDC0D376164DFA0@mike> <0BB63D56-1605-4E1E-8F0B-B2083FDE4A96@delong.com> <16AACD9632484C85BF6B855603CF07B4@mike> <907EE389FDC5448ABC46ADD06420B86D@video> <599AC4287E79403D939568C89EB40922@video> <463771E5-094B-48CB-BAD7-C6D51088C26E@delong.com> <8DDDEFF8-91B6-4C38-83C3-EDDEB44E8BE8@matthew.at> <02540BF3-D17E-4069-BC98-ECC29053A4CA@matthew.at> <7834D82CC7C64E64820785568E598738@mike> <7F3FEA3D-7D65-4576-8FD7-EA8A7010C176@arin.net> Message-ID: <9CAAC6FB-ED09-4A37-976B-F2EAFF11BDA8@arin.net> On May 12, 2011, at 3:07 PM, Martin Millnert wrote: > Perhaps it is possible to simply binary stamp a buy request approved > or rejected, before it can be allowed to bid on objects on the market? > Essentially saying 'trader X has been approved for the purchase of /21 > worth of IP addresses', or something like this. ARIN Specified Transfer Listing Service allows those who have qualified need to be listed with that information. Participation in the service is completely voluntary: FYI, /John John Curran President and CEO ARIN From owen at delong.com Thu May 12 18:19:26 2011 From: owen at delong.com (Owen DeLong) Date: Thu, 12 May 2011 15:19:26 -0700 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate In-Reply-To: <8DDDEFF8-91B6-4C38-83C3-EDDEB44E8BE8@matthew.at> References: <7F5FC4554E42430FADDC0D376164DFA0@mike> <0BB63D56-1605-4E1E-8F0B-B2083FDE4A96@delong.com> <16AACD9632484C85BF6B855603CF07B4@mike> <59EC8A7F22F247058ED74A896F0C6978@mike> <907EE389FDC5448ABC46ADD06420B86D@video> <4B99E603-7892-433A-9FB9-DB9A08D98F39@delong.com> <599AC4287E79403D939568C89EB40922@video> <4DCBFB89.6010804@matthew.at> <463771E5-094B-48CB-BAD7-C6D51088C26E@delong.com> <8DDDEFF8-91B6-4C38-83C3-EDDEB44E8BE8@matthew.at> Message-ID: On May 12, 2011, at 11:48 AM, Matthew Kaufman wrote: > > On May 12, 2011, at 10:02 AM, Owen DeLong wrote: > >> >> On May 12, 2011, at 8:23 AM, Matthew Kaufman wrote: >> >>> On 5/12/2011 2:57 AM, Owen DeLong wrote: >>>> On May 11, 2011, at 7:41 PM, Mike Burns wrote: >>>> >>>> >>>>> There ARE other addresses available, I have heard that you are aware of IPv6. >>>>> >>>> Sigh... Even I am not going to attempt to claim that IPv4 and IPv6 addresses are >>>> interchangeable equivalents. >>>> >>> >>> I keep hearing arguments that the price of IPv4 addresses won't go infinitely high because at some price it'll be more cost-effective to switch to IPv6 than to try to keep shuffling the IPv4 deck chairs. >>> >> >> You haven't heard that argument from me and I'm not convinced it is accurate. > > Ok, so what do *you* think is going to happen if the price of IPv4 addresses converges with infinity? > MOAR NAT. Unfortunately. Probably it will increase the pressure towards IPv6 marginally, but, not to such an extent on both sides of the equation as to accomplish much in and of itself. Worse, if enough incumbent Telcos/Cablecos get enough addresses, it might even serve to forestall their considering IPv6 a necessary step in favor of using that fact to bludgeon their smaller competitors into submission. >> >>> If that is true, then IPv4 and IPv6 addresses *are* economically interchangeable, just as coal is an imperfect substitute for natural gas when it comes to generating electric power... at some point the cost of one or the other gets high enough that the cost of switching is lower. >>> >> >> Since it may not be true... >> >> With coal vs. CNG, you have a single party able to make the switch deterministically for themselves. >> With IPv4 vs. IPv6, you have a myriad of third-party dependencies in your ability to switch from >> one to the other and have it actually work out. This significantly changes the underlying assumptions. >> >>>>> And with my policy or without my policy, addresses are bound to flow to the highest bidder. >>>> If the highest bidder is limited to only those addresses he can justify, then the addresses he >>>> couldn't justify flow to the next highest bidder. If the highest bidder is not so limited, then, the >>>> addresses likely flow to a very small number of very well capitalized entities to the extreme >>>> detriment of smaller entities. >>> >>> The addresses will likely flow to a very small number of very well capitalized entities in any event... the only question is what type of entity they are. In Mike's world they flow to folks who do things like lease address space and sell blocks at high prices to people who really need them... in your world they flow to the top N ISPs that are experts at showing need, aren't constrained by the 3-month rules, and are growing sufficiently to justify anything. >>> >> >> I think the results are actually the top N ISPs in both cases eventually. The difference is that Mike's resultant value >> of N tends to be much smaller than mine. > > I'd argue the reverse, actually. If there is a needs basis then the top N ISPs have an advantage in that they are already experts at manipulating the needs basis. (And it really is manipulation, because any of them could actually get by with much much less than they already have if the "need" took into account things like forcing customers to use NAT) Forcing customer to use NAT is not within the scope of ARIN policy and I do not consider the failure or refusal to do so to be a manipulation of need. NAT is a degraded subset of internet access services. There are many providers of much smaller size that are equally expert at dealing with ARIN justified need. I do not believe your argument hold water. As I said, I think with needs-basis, the value of N tends to be larger than it will be without N. > > One could argue, for instance, that *with* a needs basis Comcast might end up holding nearly all the space... but without a needs basis it might be an investment banking firm instead, who'd then lease the space out to move providers than just Comcast. > I think you have a number of assertions there which are not at all proven: 1. I think it is unlikely $CABLECO could demonstrate 12 month need for all the addresses on their first go. Other providers and end-users, will therefore be likely able to obtain some fraction of the address space. 2. I have no reason to believe that $CABLECO would not be ahead of the investment banking firm in line for the addresses as I suspect $CABLECO generally pays more attention to the goings on at ARIN than does $INVESTMENT_BANK. 3. There is nothing to prove that $INVESTMENT_BANK would not prefer to lease all the addresses to $CABLECO vs. dealing with multiple tenants. In fact, there are many things to suggest that such a model would be highly preferable as it would maintain roughly the same revenue while simultaneously reducing costs which generally is viewed favorably by most of the investment bankers I know. Indeed, I think that the likelihood is each of those three assertions is not correct. >> >>> In Mike's world, you can get service from whoever you want but the price of space is high... in your world the price of (what is now provider-assigned) space is high and your choice of transit providers is limited. >>> >> >> I really don't see how you come to these conclusions. My argument is that under Mike's proposed policy, >> your choice of providers would become more limited. > > I think you've got it backwards... see above. > No, I am not the one who has it backwards. See above. Owen From owen at delong.com Thu May 12 18:21:13 2011 From: owen at delong.com (Owen DeLong) Date: Thu, 12 May 2011 15:21:13 -0700 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate In-Reply-To: References: <7F5FC4554E42430FADDC0D376164DFA0@mike> <0BB63D56-1605-4E1E-8F0B-B2083FDE4A96@delong.com> <16AACD9632484C85BF6B855603CF07B4@mike> <59EC8A7F22F247058ED74A896F0C6978@mike> <907EE389FDC5448ABC46ADD06420B86D@video> <4B99E603-7892-433A-9FB9-DB9A08D98F39@delong.com> <599AC4287E79403D939568C89EB40922@video> <4DCBFB89.6010804@matthew.at> <463771E5-094B-48CB-BAD7-C6D51088C26E@delong.com> <8DDDEFF8-91B6-4C38-83C3-EDDEB44E8BE8@matthew.at> Message-ID: On May 12, 2011, at 12:02 PM, Jonathan Fernatt wrote: > >> The addresses will likely flow to a very small number of very well capitalized entities in any event... the only question is what type of entity they are. In Mike's world they flow to folks who do things like lease address space and sell blocks at high prices to people who really need them... in your world they flow to the top N ISPs that are experts at showing need, aren't constrained by the 3-month rules, and are growing sufficiently to justify anything. > >> > > > > I think the results are actually the top N ISPs in both cases eventually. The difference is that Mike's resultant value > > of N tends to be much smaller than mine. > > I'd argue the reverse, actually. If there is a needs basis then the top N ISPs have an advantage in that they are already experts at manipulating the needs basis. (And it really is manipulation, because any of them could actually get by with much much less than they already have if the "need" took into account things like forcing customers to use NAT) > > One could argue, for instance, that *with* a needs basis Comcast might end up holding nearly all the space... but without a needs basis it might be an investment banking firm instead, who'd then lease the space out to move providers than just Comcast. > > > > >> In Mike's world, you can get service from whoever you want but the price of space is high... in your world the price of (what is now provider-assigned) space is high and your choice of transit providers is limited. > >> > > > > I really don't see how you come to these conclusions. My argument is that under Mike's proposed policy, > > your choice of providers would become more limited. > > I think you've got it backwards... see above. > > I don't think ARIN compares the specified recipients need to that of Comcast's for example, though. So how would this example apply at all? Am I misunderstanding the NRPM as written? > > Jon ARIN processes request on a first-come first-serve basis. If the need is justified, they issue the addresses. If the need is not justified, they do not. There is no comparison of need between organizations. Owen -------------- next part -------------- An HTML attachment was scrubbed... URL: From tedm at ipinc.net Thu May 12 18:36:33 2011 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Thu, 12 May 2011 15:36:33 -0700 Subject: [arin-ppml] Just a reminder of some quick mathematics for IPv4 thatshows the long term impossibility of it In-Reply-To: References: <4DCC41D8.1010305@ipinc.net> Message-ID: <4DCC60F1.6080302@ipinc.net> On 5/12/2011 1:44 PM, Mike Burns wrote: > Hi Ted, > > I don't think anybody made the claim that IPv4 had enough unique > addresses to give one to each person on the planet. > Nor was there a claim that the Invisible Hand would create any address > space. > However, there is enough space to give everybody their own unique IPv4 > address + TCP port. > Even their own thousand unique IPv4 address+TCP ports. > 3.8billion times 65,000 is a very large number. > Food for thought? > The stats I posted show penetration of existing IPv4 into the population. It is not a 1-for-1 mapping of the IP address space to people. You can look at headcount, look at total number of IPv4 in use and figure out what the ratio of IPv4 numbers to each person is. As with any math formula, if you change a variable, things happen. For example if you decrease the ratio of IP addresses per person (which is what NAT does) then you can increase the population that is using the same amount of IP addressing. That is what we did 10 years ago and it worked. If you add a new way to use IP addressing that allowed for port numbers on a single IP to be spread around, then you could further decrease the ratio of IP addresses per person. That is what co-called "carrier based" nat or NAT4444, or "stacked nat" (translators behind translators, behind translators) essentially does. Notice though that each iteration of that trick increases complexity and increased complexity decreases reliability. That is why NAT is regarded as played out, we have hit the area of diminishing returns with it. Also notice that NAT tends to push servers from the "leaves" of the Internet to the "trunk" So instead of Joe Blow Company running his webserver off a process on his regular desktop that he runs his company on, now he has to pay someone to do it who is closer to the trunk. Same for e-mail and other services. That isn't what attracted people to the Internet in the first place. So you might say that the popularity of the Internet is putting pressure on promoting solutions that run contrary to the fundamental properties of the Internet that got it popular to begin with. Much like when you build a highway, it is empty, people buy a car and drive on it, it is enjoyable to do so because there is no congestion, so now everyone buys a car, they all get on the highway and now it's congested and unpleasant to drive on, thus you have killed the golden goose that laid the egg that everyone originally wanted. Ted > Regards, > Mike > > > > ----- Original Message ----- From: "Ted Mittelstaedt" > To: > Sent: Thursday, May 12, 2011 4:23 PM > Subject: [arin-ppml] Just a reminder of some quick mathematics for IPv4 > thatshows the long term impossibility of it > > >> From the following website: >> >> http://www.internetworldstats.com/stats.htm >> >> Notice - as of 2009/2010 (last time these figures were updated): >> >> >> WORLD INTERNET USAGE AND POPULATION STATISTICS WORLD TOTAL >> >> Population Internet Users Latest Data Penetration (% Population) >> 6,845,609,960 1,966,514,816 28.7 % >> >> >> From the beginning of public access of the Internet in 1995 we >> are now about a year away from complete global IPv4 runout. Assuming >> maybe by then we are at a global penetration of 35% of maybe 7 billion >> people, that's still only about 2.5 billion people on the Internet. >> >> So how exactly do we get the other 4.5 billion people on the Internet >> using IPv4? >> >> The last "legacy" IP block was handed out in 1997. To assume that >> unused legacy IPv4 will cover the remaining 4.5 billion people assumes >> that 65% of the usable IPv4 space was handed out before 1997 and the >> remaining 35% of it was handed out from 1998 until next year. It is >> a ridiculous assumption completely unsupported by the math. >> >> But, don't let something like mathematics bog your day down! It's much >> more fun to believe that Adam Smith's "Invisible hand" will come sailing >> in at the last minute and manufacture IPv4 out of thin air! ;-) >> >> >> Ted >> >> >> >> _______________________________________________ >> PPML >> You are receiving this message because you are subscribed to >> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/arin-ppml >> Please contact info at arin.net if you experience any issues. > From bill at herrin.us Thu May 12 18:46:17 2011 From: bill at herrin.us (William Herrin) Date: Thu, 12 May 2011 18:46:17 -0400 Subject: [arin-ppml] Just a reminder of some quick mathematics for IPv4 that shows the long term impossibility of it In-Reply-To: <4DCC41D8.1010305@ipinc.net> References: <4DCC41D8.1010305@ipinc.net> Message-ID: On Thu, May 12, 2011 at 4:23 PM, Ted Mittelstaedt wrote: > So how exactly do we get the other 4.5 billion people on the Internet > using IPv4? Survey says: NAT. > But, don't let something like mathematics bog your day down! Or technology either it would seem. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From matthew at matthew.at Thu May 12 19:15:03 2011 From: matthew at matthew.at (Matthew Kaufman) Date: Thu, 12 May 2011 16:15:03 -0700 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate In-Reply-To: References: <7F5FC4554E42430FADDC0D376164DFA0@mike> <0BB63D56-1605-4E1E-8F0B-B2083FDE4A96@delong.com> <16AACD9632484C85BF6B855603CF07B4@mike> <59EC8A7F22F247058ED74A896F0C6978@mike> <907EE389FDC5448ABC46ADD06420B86D@video> <4B99E603-7892-433A-9FB9-DB9A08D98F39@delong.com> <599AC4287E79403D939568C89EB40922@video> <4DCBFB89.6010804@matthew.at> <463771E5-094B-48CB-BAD7-C6D51088C26E@delong.com> <8DDDEFF8-91B6-4C38-83C3-EDDEB44E8BE8@matthew.at> Message-ID: On May 12, 2011, at 3:19 PM, Owen DeLong wrote: >> > > Forcing customer to use NAT is not within the scope of ARIN policy and I do not consider the failure or refusal to do so to be a manipulation of need. > NAT is a degraded subset of internet access services. My point is that someone with lots of addresses that they *could* free up can still claim they need more fairly easily. > > There are many providers of much smaller size that are equally expert at dealing with ARIN justified need. I do not believe your argument > hold water. They don't have enough money to play as the price approaches infinity, however. > As I said, I think with needs-basis, the value of N tends to be larger than it will be without N. And I think you're wrong on that point. > >> >> One could argue, for instance, that *with* a needs basis Comcast might end up holding nearly all the space... but without a needs basis it might be an investment banking firm instead, who'd then lease the space out to move providers than just Comcast. >> > > I think you have a number of assertions there which are not at all proven: > > 1. I think it is unlikely $CABLECO could demonstrate 12 month need for all the > addresses on their first go. Other providers and end-users, will therefore be > likely able to obtain some fraction of the address space. Maybe. But a very small number of players with lots of money and needs justification will be able to dominate the buy side trivially. And very small amounts of gaming turn a /14 of need into a /13 or /12, whereas the same amount applied to a tiny request for a /24 isn't so interesting. > > 2. I have no reason to believe that $CABLECO would not be ahead of the > investment banking firm in line for the addresses as I suspect $CABLECO > generally pays more attention to the goings on at ARIN than does > $INVESTMENT_BANK. One would assume that some of the folks here who have an interest in making money by speculating on IPv4 space are planning on having a source of cash with which to do that. > > 3. There is nothing to prove that $INVESTMENT_BANK would not prefer to > lease all the addresses to $CABLECO vs. dealing with multiple tenants. > In fact, there are many things to suggest that such a model would be > highly preferable as it would maintain roughly the same revenue while > simultaneously reducing costs which generally is viewed favorably > by most of the investment bankers I know. Unknown, but possible. In fact, $CABLECO might be able to afford an exclusive deal. But then this is NO DIFFERENT than $CABLECO going and getting that much space itself.. so who cares? In either case your doomsday scenario of a few big providers holding most of the space happens, and needs justification did nothing to prevent it. Matthew Kaufman From owen at delong.com Thu May 12 19:19:58 2011 From: owen at delong.com (Owen DeLong) Date: Thu, 12 May 2011 16:19:58 -0700 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate In-Reply-To: References: <7F5FC4554E42430FADDC0D376164DFA0@mike> <0BB63D56-1605-4E1E-8F0B-B2083FDE4A96@delong.com> <16AACD9632484C85BF6B855603CF07B4@mike> <59EC8A7F22F247058ED74A896F0C6978@mike> <907EE389FDC5448ABC46ADD06420B86D@video> <8EBD080A-3150-4269-A73B-BD5724312E6E@delong.com> <3A4A01EC-DE3E-4DC8-80EA-523245381FB4@delong.com> Message-ID: <48F50A26-B3ED-47EB-BCC4-289950C93A33@delong.com> On May 12, 2011, at 12:35 PM, Chris Engel wrote: > >> -----Original Message----- >> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On >> Behalf Of Owen DeLong >> Sent: Thursday, May 12, 2011 1:20 PM >> To: Martin Millnert >> Cc: arin-ppml at arin.net >> Subject: Re: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate >> >> >> On May 12, 2011, at 10:11 AM, Martin Millnert wrote: >> >>> Owen, >>> >>> On Thu, May 12, 2011 at 5:14 AM, Owen DeLong >> wrote: >>>>>> You left out: >>>>>> >>>>>> 4) The RIR eventually identifies these outliers and reclaims the >> numbers >>>>>> to be reissued to members of the community willing to comply with >> policy. >>>>> >>>>> Well, you'd potentially destroy uniqueness if the other party and its >>>>> ISPs disagrees and continues to use the addresses. >>>>> >>>> That is a theoretical risk today with hijackings. I fail to see the difference. >>> >>> Well, in your case *the RIR* is the one doing the hijacking, if it >>> acts against the will of the ISP it takes numbers away from. >>> >> The RIR is not hijacking, it is reclaiming a community resource from someone >> using it outside of the policies set by the community, just as squatters would >> be >> evicted from land if the owner pursues the issue prior to the expiration of >> the time limits in the adverse possession laws. >> >> Indeed, by the community policy definition, it is provider B that is doing the >> hijacking. >> >> Owen >> > > > Owen, > > It seems to me that the above analogy is a little problematic. With land there is a clear legal ownership which is enforced by an outside governing authority. Ownership of the land encompasses within it the legal right to exclude others from using that property. The governing authority has the legal (and practical) power to enforce the ownership rules it recognizes. > Agreed. > Your own stance, in previous postings here seems to have been that numbers (i.e. IP addresses) can't be "owned". If that's the case neither ARIN, nor anyone else possesses the legal authority to exclude an entity from their use. (Absent a Court or Government Agency proclaiming the contrary) > Also agreed. > Unless I misunderstand the situation here (which admittedly I may) ARIN has no real legal authority over the address spaces it registers. It's a self-appointed non-profit, not a government agency.... and has no real legal authority to regulate address usage outside of the individual contracts it has with many organizations. Therefore, if an organization never entered into a contract with ARIN, it really has no legal mechanism for regulating it's use of any particular set of addresses. Do I misunderstand the nature of ARIN as an organization? > Correct. ARIN's authority is limited to control of what it does or does not maintain in a database. When I talk about reclamation in this context, I am talking about ARIN removing a registration record from the database and then subsequently issuing a different record with the same numbers to another entity. > In practical terms, ARIN's, functional authority seems to derive from the fact that most of the organizations responsible for routing traffic voluntarily accept it as the official keeper of records for what address space belongs to whom. Would that be a correct summation? Correct. > > It seems to me that if ARIN started reclaiming address space from those organizations (or their clients) on any sort of significant scale, it would pretty rapidly risk undermining it's own authority and relevance to them. Whether, ARIN, from a policy standpoint has the technical ability to do so, strikes me as somewhat ancillary as to whether it would actually be a good idea for them to do so. I do not believe that the scale of these existing hijackings is very large. Further, I believe that if ARIN started taking proper action to prevent or correct these hijackings of addresses, it would reduce the likelihood of their increasing in the near future. > > As a hypothetical, if an extremely large organization which had no contractual arrangement with ARIN believed it had legitimate claim to a certain address blocks. I would assume that many of the ISP's who were financially dependent on that organization would be inclined to route said block regardless of what ARIN might have to say about it. I would also presume that it would be in ARIN's self-interest to generally try and recognize the legitimacy of such claim, if at all possible... and try to get that organization into some sort of contractual relationship so that it could exert some sort of legal authority. Are those presumptions reasonable? What if another large organization also felt they had claim to the block and had a record in ARIN whois to document it? Frankly, I do not believe that the problem here involves large organizations for the most part. I believe that most of the illicit transfers have been much smaller blocks. Further, in the case of a large transfer, I think it is unlikely that the large organization would take the risk of refusing to work with ARIN to come to an agreement on an appropriate RSA. Owen From owen at delong.com Thu May 12 19:31:21 2011 From: owen at delong.com (Owen DeLong) Date: Thu, 12 May 2011 16:31:21 -0700 Subject: [arin-ppml] ARIN-prop-149 Improved Transparency for Directed Transfers In-Reply-To: <1110512163051.1401B-100000@Ives.egh.com> References: <1110512163051.1401B-100000@Ives.egh.com> Message-ID: <7840AFD9-25B0-4574-A036-4247AEF18B48@delong.com> On May 12, 2011, at 1:59 PM, John Santos wrote: > On Thu, 12 May 2011, ARIN wrote: > >> 8.3.a In order to provide greater transparency in the transfer process >> and provide the community the best set of tools to make routing >> decisions as prefix disaggregation increases as a result of the transfer >> market, ARIN shall maintain and publish a list of all prefixes >> transfered under section 8.3. The list will identify the original prefix >> and each subordinate prefix transferred under this policy and the date >> each prefix was transferred. > > If the same prefix is transfered multiple times, will the historical > record be maintained? E.G. org A transfers to org B on date 1, and > then org B transfers to org C on date 2, would both transfers be > reflected in the list? > That would certainly be the intent, though I guess I need to clarify the policy language to reflect that more accurately. Thanks for pointing this out. > If org B disaggregated the prefix and transfered part of it to org C > and part to org D, would all 3 transfers be reflected in the list > (A -> B, B -> C, B -> D)? > Again, my intent is for ALL transfers to be reflected, so, yes, that should show up in the record. Look for language to clarify this intent shortly. > Would how org A acquired the prefix in the first place, and whether it > was a larger prefix than what it transfered to org B, also be reflected > in the list, or is this information already available some place else, > such as in whois, and thus redundant? > Since the list would include the original prefix and each subordinate prefix transfered, yes, that is required under the current wording. For example, if A held 192.0.0.0/16 and transferred 192.0.2.0/24 to B, that should be reflected (at a minimum) as: 192.0.0.0/16 partially transferred 5/12/2011 as 192.0.2.0/24 > I think it is important to include exactly what information is to be > maintained in the policy proposal, or we may find out it is not as > useful as hoped. > Does the above work for you, or, is there more or less information that you would like to see? Owen From owen at delong.com Thu May 12 19:39:25 2011 From: owen at delong.com (Owen DeLong) Date: Thu, 12 May 2011 16:39:25 -0700 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate In-Reply-To: References: <7F5FC4554E42430FADDC0D376164DFA0@mike> <0BB63D56-1605-4E1E-8F0B-B2083FDE4A96@delong.com> <16AACD9632484C85BF6B855603CF07B4@mike> <907EE389FDC5448ABC46ADD06420B86D@video> <599AC4287E79403D939568C89EB40922@video> <463771E5-094B-48CB-BAD7-C6D51088C26E@delong.com> <8DDDEFF8-91B6-4C38-83C3-EDDEB44E8BE8@matthew.at> <02540BF3-D17E-4069-BC98-ECC29053A4CA@matthew.at> <7834D82CC7C64E64820785568E598738@mike> <7F3FEA3D-7D65-4576-8FD7-EA8A7010C176@arin.net> Message-ID: <44E41CE0-9B3B-4AB8-8D3D-0479FCAC987A@delong.com> On May 12, 2011, at 3:07 PM, Martin Millnert wrote: > Hi John, > > On Thu, May 12, 2011 at 5:44 PM, John Curran wrote: >> On May 12, 2011, at 2:25 PM, Mike Burns wrote: >>> As far as what you term a non-operator speculator, you see the risk of gaming the needs analysis. >>> The same risks lead to not-notifying ARIN and continuing to use the addresses under the purchaser's name, leaving Whois in more disarray. >> >> That is a potential risk that some will take, whereas others may >> decide to avoid doing speculation in this particular market. >> >> One other point regarding transfers from a party with actual need - >> the risks may increase depending on any policy constraints on the >> supplier of the IP addressees (e.g. if you qualify based on need, >> but the party you're getting them from does not have that amount >> of space in contiguous blocks that match policy constraints, or if >> you are seeking a small number of addresses which is less than any >> minimum size requirement, etc.) > > > How do you value need in terms of $ ? > Allowing correct price discovery is essential for any market to function well. > > Perhaps it is possible to simply binary stamp a buy request approved > or rejected, before it can be allowed to bid on objects on the market? > Essentially saying 'trader X has been approved for the purchase of /21 > worth of IP addresses', or something like this. > That function is available today as I understand it. You can submit a standard request to ARIN and get your approval. Of course, while ARIN still has space to issue, they will simply issue free-pool space to you upon approval, but, once they are out, you will have the option of taking your approval to the waiting list and/or the transfer market. Owen From owen at delong.com Thu May 12 19:37:38 2011 From: owen at delong.com (Owen DeLong) Date: Thu, 12 May 2011 16:37:38 -0700 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate In-Reply-To: References: <7F5FC4554E42430FADDC0D376164DFA0@mike><0BB63D56-1605-4E1E-8F0B-B2083FDE4A96@delong.com><16AACD9632484C85BF6B855603CF07B4@mike><59EC8A7F22F2470 58ED74A896F0C6978@mike><907EE389FDC5448ABC46ADD06420B86D@video><4B99E603-7892- 433A-9FB9-DB9A08D98F39@delong.com><599AC4287E79403D939568C89EB40922@video><4DC BFB89.6010804@matthew.at><463771E5-094B-48CB-BAD7-C6D51088C26E@delong.com><8DDDEFF8-91B6-4C38-83C3-EDDEB44E8BE8@matthew.at><02540BF3-D17E-4069-BC98-ECC29053A4CA@matthew.at><7834D82CC7C64E648207855 68E598738@mike> <7F3FEA3D-7D65-4576-8FD7-EA8A7010C176@arin.net> Message-ID: On May 12, 2011, at 3:05 PM, Mike Burns wrote: > > > >>> As far as what you term a non-operator speculator, you see the risk of gaming the needs analysis. >>> The same risks lead to not-notifying ARIN and continuing to use the addresses under the purchaser's name, leaving Whois in more disarray. > >> That is a potential risk that some will take, whereas others may >> decide to avoid doing speculation in this particular market. > > Yup, they can ignore ARIN, game ARIN, or not speculate under current needs-based policy for transfers. > >> One other point regarding transfers from a party with actual need - >> the risks may increase depending on any policy constraints on the >> supplier of the IP addressees (e.g. if you qualify based on need, >> but the party you're getting them from does not have that amount >> of space in contiguous blocks that match policy constraints, or if >> you are seeking a small number of addresses which is less than any >> minimum size requirement, etc.) >> /John > > John, I'm not really clear on what you mean here. > I always assumed there was a buyer and a seller first, then an ARIN needs assessment later. Nope... The recipient can approach ARIN and get their need prequalified prior to seeking a supplier. > I figured the buyer and seller would reach agreement on what amount is being transferred, and then they would ask ARIN to bless the deal. That's only one possibility, and, the possibility that carries the greatest risk for both parties. > I know that you have been pleading for some advance consideration of transfer policy as deals are being formulated. > So I think it's worth asking for clarification of the last paragraph. Indeed, if people seek ARIN approval for their need/amount early, then, it is far more likely they will be able to structure a deal which ARIN can easily approve. Owen From owen at delong.com Thu May 12 19:44:01 2011 From: owen at delong.com (Owen DeLong) Date: Thu, 12 May 2011 16:44:01 -0700 Subject: [arin-ppml] Just a reminder of some quick mathematics for IPv4 that shows the long term impossibility of it In-Reply-To: References: <4DCC41D8.1010305@ipinc.net> Message-ID: On May 12, 2011, at 3:46 PM, William Herrin wrote: > On Thu, May 12, 2011 at 4:23 PM, Ted Mittelstaedt wrote: >> So how exactly do we get the other 4.5 billion people on the Internet >> using IPv4? > > Survey says: NAT. > That does not put the other 4.5 billion people on the internet. That might put the other 4.5 billion people onto a carefully controlled subset of the internet. I do not advocate inflicting this damage on what would become the vast majority of internet users. Rather, I think it is vastly better to deploy them with IPv6 and let the rest of the internet catch up. > >> But, don't let something like mathematics bog your day down! > > Or technology either it would seem. > One man's "technology" is another man's nightmare. Owen From owen at delong.com Thu May 12 19:53:51 2011 From: owen at delong.com (Owen DeLong) Date: Thu, 12 May 2011 16:53:51 -0700 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate In-Reply-To: References: <7F5FC4554E42430FADDC0D376164DFA0@mike> <0BB63D56-1605-4E1E-8F0B-B2083FDE4A96@delong.com> <16AACD9632484C85BF6B855603CF07B4@mike> <59EC8A7F22F247058ED74A896F0C6978@mike> <907EE389FDC5448ABC46ADD06420B86D@video> <4B99E603-7892-433A-9FB9-DB9A08D98F39@delong.com> <599AC4287E79403D939568C89EB40922@video> <4DCBFB89.6010804@matthew.at> <463771E5-094B-48CB-BAD7-C6D51088C26E@delong.com> <8DDDEFF8-91B6-4C38-83C3-EDDEB44E8BE8@matthew.at> Message-ID: On May 12, 2011, at 4:15 PM, Matthew Kaufman wrote: > > On May 12, 2011, at 3:19 PM, Owen DeLong wrote: > >>> >> >> Forcing customer to use NAT is not within the scope of ARIN policy and I do not consider the failure or refusal to do so to be a manipulation of need. >> NAT is a degraded subset of internet access services. > > My point is that someone with lots of addresses that they *could* free up can still claim they need more fairly easily. > Your definition of "could" and mine are different. >> >> There are many providers of much smaller size that are equally expert at dealing with ARIN justified need. I do not believe your argument >> hold water. > > They don't have enough money to play as the price approaches infinity, however. > Which is why I think it is important to preserve needs justification. I believe that preserving needs justification will both reduce the speed at which pricing approaches infinity and increase availability to a wider variety of providers. >> As I said, I think with needs-basis, the value of N tends to be larger than it will be without N. > > And I think you're wrong on that point. > Then we can agree to disagree. I have at least provided reasons for my assertion based in both historical fact and observable behavior on the internet and in other markets. >> >>> >>> One could argue, for instance, that *with* a needs basis Comcast might end up holding nearly all the space... but without a needs basis it might be an investment banking firm instead, who'd then lease the space out to move providers than just Comcast. >>> >> >> I think you have a number of assertions there which are not at all proven: >> >> 1. I think it is unlikely $CABLECO could demonstrate 12 month need for all the >> addresses on their first go. Other providers and end-users, will therefore be >> likely able to obtain some fraction of the address space. > > Maybe. But a very small number of players with lots of money and needs justification will be able to dominate the buy side trivially. And very small amounts of gaming turn a /14 of need into a /13 or /12, whereas the same amount applied to a tiny request for a /24 isn't so interesting. > I believe that the initial market will actually be much larger than a few /12s (probably 2-5 /8 equivalents). As such, I believe that for at least the first round of buying, a relatively large number of providers will have purchasing opportunities if we preserve needs-basis. OTOH, if we abandon stewardship as proposed, then, yes, one or more large well funded providers will likely dominate the market early and permanently to the complete exclusion of all others. > >> >> 2. I have no reason to believe that $CABLECO would not be ahead of the >> investment banking firm in line for the addresses as I suspect $CABLECO >> generally pays more attention to the goings on at ARIN than does >> $INVESTMENT_BANK. > > One would assume that some of the folks here who have an interest in making money by speculating on IPv4 space are planning on having a source of cash with which to do that. > Perhaps. Perhaps not. As I stated, this is at best a relatively unfounded assertion. Even if your later statement holds true, that does not necessarily connect them to $INVESTMENT_BANK. >> >> 3. There is nothing to prove that $INVESTMENT_BANK would not prefer to >> lease all the addresses to $CABLECO vs. dealing with multiple tenants. >> In fact, there are many things to suggest that such a model would be >> highly preferable as it would maintain roughly the same revenue while >> simultaneously reducing costs which generally is viewed favorably >> by most of the investment bankers I know. > > Unknown, but possible. In fact, $CABLECO might be able to afford an exclusive deal. But then this is NO DIFFERENT than $CABLECO going and getting that much space itself.. so who cares? In either case your doomsday scenario of a few big providers holding most of the space happens, and needs justification did nothing to prevent it. > I disagree. See point 1 above... again. Owen From springer at inlandnet.com Thu May 12 20:03:11 2011 From: springer at inlandnet.com (John Springer) Date: Thu, 12 May 2011 17:03:11 -0700 (PDT) Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate In-Reply-To: <7F5FC4554E42430FADDC0D376164DFA0@mike> References: <7F5FC4554E42430FADDC0D376164DFA0@mike> Message-ID: <20110512141453.K34430@mail.inlandnet.com> Hi Mike, Thanks for another stimulating post/proposal. Congratulations on generating a massive response which seems to include several new posters! I have reviewed through your post of 12 May 2011 16:56:16. >From here on I have a mix of comments to the original proposal itself and comments on comments to the proposal which I'll do inline below. On Wed, 11 May 2011, Mike Burns wrote: > 1. Policy Proposal Name: IPv4 Transfer Policy Change to Keep Whois > Accurate I note with interest the explanation that the Policy Proposal Name is intended to be taken with tongue firmly in cheek. I'm glad that's cleared up as I was fixin to expostulate, > > and add to the NRPM Section 12: > > 10. ARIN will not use utilization as a measure of policy compliance for addresses transferred under 8.3. because I was confused as to why a policy whose major (only?) proposed effect is to remove utilization devotes most of its wording to WHOIS accuracy. Who wouldn't want that? But I understand now that it is intended only as a witticism. I will therefore attempt to speak only to the non-WHOIS part of the proposal. > > 8. Rationale: > > The underlying proposition behind this policy proposal is that the > registry of IPv4 addresses operated by ARIN is of general utility and > value only while it accurately describes the current state of address > distribution. If a class of address movement transactions are excluded > from being entered in the registry, then the registry will have > decreasing value to the broader community, and the integrity of the > network itself is thereby compromised. This proposal's central aim is > to ensure the continuing utility and value of the ARIN address > registry by allowing the registry to record transactions where IPv4 > addresses are transfered between ARIN account holders. But where is utilization in this underlying proposition? Having observed the preparatory discussions that led to this proposal and subsequent comments to it, I recall massive dialogue on the MS/NN transaction. To integrate that subject with this proposal, I must go to comments to the proposal for guidance. In the authors response of 11 May 2011 17:12:57 to Tom Vest regarding "current legal realities" it is stated: "4. Finally, the requirement at issue here, a needs analysis had to be completed by ARIN, which magically showed that MS qualified for exactly the amount already bid for and negotiated the sale of." And this paragraph "If they had needed fewer addresses, they could have bid for less than the full pool. If they needed more addresses, they should have received an additional ARIN allocation. Paraphrasing Goldilocks, the random allocation of addresses to long-ago Nortel acquisitions was "just right." which I interpret as expressing disbelief. I could be wrong here. So, the implication of an ARIN policy deficiency serious enough to require jettisoning needs analysis. This after several (3?, 5?) rounds of the question asked and answered; John Curran coming right out and stating that a needs assessment was satifactorily conducted and ARIN policy was followed. Which is where I start having a problem. John Curran asks 3 things of us: 1) _I_ oppose this proposal as written, and here's why: 2) It looks to me like we have a fundamental logic flaw here. This proposal will fix a problem that does not exist! From my perspective, a needs assessment was properly conducted in the Microsoft/Nortel bankruptcy affair and ARIN policy was followed. John Curran says so, author says no. Which brings us to the realm of belief and he said, he said. Who do I believe, John or author? Well, John has been exposed to the facts of the matter and cannot talk about it, except obliquely. The rest of us have only our interpretations of public documents. John has a fiduciary responsibility here, so real penalties might apply if he prevaricates. Author can pretty much say what he likes, the worst we could do is get quite cross. John has several decades of credibility in public policy and networking. So might the author, but I can't say. But here's the deal, IT DOESN'T MATTER. We will never know and can't know. And if we do know, it will be because somebody broke the rules. Adopting policy on the sole basis of belief is not acceptable. If an NDA gets violated, relying on facts turned up thereby from what will essentially be fruit of the poisoned tree would be odious. The invisible hand has moved! And lastly, there appears no other even remotely sufficient reason for removing utilization/needs analysis. I reject the idea that because everything changes after V4 runout, it's OK to deep six it as insufficiently rational. Oh, somebody else said it already, but the RIR system specifically allows for different policies in different regions. So may we please dispense with the APNIC did it thing? It's a fallacy anyway: http://en.wikipedia.org/wiki/Argumentum_ad_populum 3) I don't think this can be fixed in text. respectfully John Springer From farmer at umn.edu Thu May 12 20:22:22 2011 From: farmer at umn.edu (David Farmer) Date: Thu, 12 May 2011 19:22:22 -0500 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate In-Reply-To: References: <7F5FC4554E42430FADDC0D376164DFA0@mike><0BB63D56-1605-4E1E-8F0B-B2083FDE4A96@delong.com><16AACD9632484C85BF6B855603CF07B4@mike><59EC8A7F22F247058ED74A896F0C6978@mike><907EE389FDC5448ABC46ADD06420B86D@video><4B99E603-7892-433A-9FB9-DB9A08D98F39@delong.com><599AC4287E79403D939568C89EB40922@video> Message-ID: <4DCC79BE.5070901@umn.edu> On 5/11/11 22:09 CDT, Mike Burns wrote: ... > I'm sure there are many more that I cannot think of. I agree with you > that most buyers will have need, and I agree with you that most buyers > will see the value of maintaining a valid ARIN whois record pointing to > their authority. Unfortunately, most rules are meant to enforce something on those who are not necessarily acting reasonably. Above you save "most buyers will see value" what about those that don't. Or, what about those, that see a value in ensuring that their competitors can't get addresses and that the whole system doesn't shift to IPv6. I don't want to see something like that happen and I'm not entirely sure it can't. > But the policy in APNIC was changed to remove needs requirements for > transfers for the same reasons I am requesting its removal here. There are other policy differences between APNIC and ARIN then just needs or non-needs based transfers that are relevant to the changes due to IPv4 run-out. There is also a fundamental difference in the way APNIC and ARIN plan to operate the pool of addresses they have left, APNIC is reserving their whole /8 and allowing each organization a single /22. The ARIN community has reserved /10 of IPv4 for IPv6 purposes, but is allowing need to driver the run-out of the rest of the pool, limiting to 3 month need for fairness with new entrants and to reduce the competitive disparity created by IPv4 run-out. Additionally ARIN added officer attestations, to ensure organizational accountability for requests, I believe this will strongly suppress the tendency for ARIN to have a run-out curve like APNIC had during the first 4 months of 2011. So there are a number of differences in how ARIN and APNIC are approaching the fundamental changes that are occurring, and it would be a mistake to evaluate only one of these issues out of context with the others. I'm not trying to say APNIC did or is doing something wrong or ARIN did or is doing it right, but there is more to the picture than just needs or non-needs based transfers. If ARIN is going to change to a non-needs based transfer regime lime APNIC we may also need to change many more parts of policy as a consequence. The point here is that ARIN's policies are consistent, if you have need you can have addresses, be that from the free pool or from transfers. Much of the ARIN community didn't like to idea of addresses sitting at ARIN, if there was need for them. APNIC is also consistent, in that once they get down to the last /8, it doesn't matter if you need addresses you only get a /22 once from the last /8 pool, and you can transfer without need. I believe it would be unwise for ARIN community to change only one part of its policies to emulate APNIC. > My policy proposal also has the benefit of incentivizing legacy > resources to come under RSA, and it serves to even the playing field > between the disparate rights of legacy versus non-legacy holders. > > And my underlying point is the obvious one, that the very act of paying > for address space is a very good indication of need, or at least > perceived need on the part of the buyer. I think it is a good indication of perceived value in all cases, it is a indication of need in some cases, but not in all cases. If you want to corner the market on IPv4 there maybe sufficient value to someone to do so, but that is not a valid need. And, this is the case where your analysis breaks down. That said I'm not certain that current criteria for evaluating need will even be valid once there is no longer a free pool. The basic idea that you get a years worth of need based on your past years consumption of addresses assumes the existence of a free pool. Once we get more than a year into a market-like transfer system, what you used last year has more to do with how much money you were willing to spend that what your actual need was. And if the price was high the previous year and if you simply evaluate your need by how much addressing you used last year when the price was high that isn't necessarily a true representation of your actual need. So I am equally skeptical of maintaining the current needs based system as is, as I am of completely abandoning the concept of a needs basis. Right now I'm thinking allowing transfers up to some size limit over some period of time without justifying need more than putting up the cash to do it, on the premise that within some safety limits it might be a good idea to let the market work things out. However, if you want to transfer more than those limits you can, but you must justify your need beyond those limits. Either based on your previous years usage or based on the fact that you have put previously transferred addresses into documented use. Just throwing some numbers out, I'm thinking up to the equilivant of a /12 (or a little more than 1 million IPv4 addresses) of transfers received within 12 months per organization without documenting need. There needs to be a mechanism that prevents gaming by creating multiple organizations by the same real organization, maybe this is another place for officer attestations. For most organizations a /12 is more or less unlimited, but that is probably not enough to corner the market of IPv4 addresses and anyone who really needs more than a /12 can probably justify it without much more hassle then now. If they really need more than a /12 they are probably quite adept at working with ARIN already. I think this would give the invisible hand enough room to do its magic, without allowing someone to corner the IPv4 market and destroy the Internet as we know it. Depending how the actually market progresses, someone could maybe still corner the IPv4 address market, but if they can do that with a /12 then it will really be the time for everyone to move to IPv6. What I mean by "destroy the Internet as we know it", is anyone big enough, or that anyone thinks is big enough, to stall the transition of the Internet to IPv6, getting enough IPv4 addresses to attempt to do so. I'm not sure anyone is big enough, but I'm just not sure no one is. In my view this doesn't abandon needs basis, it significantly changes it based on new the realities we are facing. We are using the market to determine need up to a cretin extent, and beyond that requiring documented need. -- =============================================== 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 JOHN at egh.com Thu May 12 20:40:11 2011 From: JOHN at egh.com (John Santos) Date: Thu, 12 May 2011 20:40:11 -0400 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate In-Reply-To: <7834D82CC7C64E64820785568E598738@mike> Message-ID: <1110512183325.1401A-100000@Ives.egh.com> On Thu, 12 May 2011, Mike Burns wrote: > Ola John, > > > I'll actually disagree with the presumption that incentives towards > > gaming will increase with the value of IP address space, if we are > > considering a transfer market with needs-based qualification. While > > it is true that there might be incentive to get creative with the > > total expressed need to obtain more space than otherwise qualified > > for, the existence of a market (if properly functioning) means that > > there is some reassurance that additional space will more likely be > > available when needed in the future, even if at a slightly increased > > price. This actually reduces the pressure to try and game the system > > when compared with the present environment and potential that there > > will be no more resources in the free pool when you come back later. > > > The other potential form of gaming would by a non-operator speculator, > > who wishes to participate in the market (despite having no actual need > > at all), and so needs to fabricate imaginary need to be able to obtain > > IP space from the market for subsequent monetization. While there is no > > doubt of the incentives involved, there is also significant risk since > > intangible IP registration entries are readily corrected in such cases > > of fraudulent representations to the registry. > > If the needs requirement can not be met by the buyer, he will have the > incentive to game the needs requirement. Why would the buyer be unable to meet the needs requirement? There are two possible reasons: 1) The buyer has need but it is not being recognized by ARIN or 2) The buyer does not have any actual need. In the 1st case, the buyer can protest to PPML and lobby for policy changes that allow his need to be accomodated, or complain that policy is not being followed by ARIN staff. In the 2nd case, too bad. > If the value of the addresses at question are higher, the incentive will be > higher, to my mind. Why did Willie Sutton rob banks? > > But you are absolutely correct in that having a vibrant and functioning > market is the best way to assuage fears of future supply shocks and > attendant price increases. > > And you are correct in that the incentive to game the system for allocations > from the free pool is reaching its highest point in the months to come. > Pray be diligent! > > As far as what you term a non-operator speculator, you see the risk of > gaming the needs analysis. > The same risks lead to not-notifying ARIN and continuing to use the > addresses under the purchaser's name, leaving Whois in more disarray. Someone who is actually using the addresses almost certainly has need. Maybe they have more than they need, but they do have at least some need. It is people who are sitting on UNUSED addresses (for reasons of speculation, or vague fears that they will need the addresses in the future but won't be able to acquire them, or to deprive needful competitors of them), that are the issue. The hope of the marketplace idea (and so far as I can see, the only positive virtue of it) is that people who have need but more addresses than they need, but who have to renumber to consolidate their usage into a smaller block, will be motivated to do so if they can recoup some or all their renumbering costs by selling their surplus addresses on the market. Other possible situations: 1) If they have no need at all (which implies they aren't using any of their addresses) then there is no cost to renumbering. According to the RSA, or implicit in the original application to NetSol or its predecessors (which was predicated on need), they should return unneeded addresses. The general consensus seems to be that this is unenforcible on legacy holders, but I see no reason to grant them a windfall. 2) They have approximately as many addresses as they need (including current use and reasonable projections for the next year or so), then they have no reason to participate in the market. 3) They need more addresses. They should get them from ARIN, while they are still available, or go to the market for them if ARIN can't provide. This whole thread has been suffused with constant conflating of different situations and conditions, in many combinations that don't actually make sense or exist in the real world. > > Regards, > Mike > -- John Santos Evans Griffiths & Hart, Inc. 781-861-0670 ext 539 From JOHN at egh.com Thu May 12 21:12:12 2011 From: JOHN at egh.com (John Santos) Date: Thu, 12 May 2011 21:12:12 -0400 Subject: [arin-ppml] ARIN-prop-149 Improved Transparency for Directed Transfers In-Reply-To: <7840AFD9-25B0-4574-A036-4247AEF18B48@delong.com> Message-ID: <1110512210147.1401B-100000@Ives.egh.com> On Thu, 12 May 2011, Owen DeLong wrote: > > On May 12, 2011, at 1:59 PM, John Santos wrote: > > > Would how org A acquired the prefix in the first place, and whether it > > was a larger prefix than what it transfered to org B, also be reflected > > in the list, or is this information already available some place else, > > such as in whois, and thus redundant? > > > Since the list would include the original prefix and each subordinate > prefix transfered, yes, that is required under the current wording. > > For example, if A held 192.0.0.0/16 and transferred 192.0.2.0/24 > to B, that should be reflected (at a minimum) as: > > 192.0.0.0/16 partially transferred 5/12/2011 as 192.0.2.0/24 > > > I think it is important to include exactly what information is to be > > maintained in the policy proposal, or we may find out it is not as > > useful as hoped. > > > Does the above work for you, or, is there more or less information > that you would like to see? I think that does it for me. Would other people like to see an indication of whether it was originally a legacy (LRSA or not) or ARIN allocation, and what kind of RSA applies to the recipient (RSA, LRSA, or modified version of one of them?) Since the results would presumably be under some sort of RSA, it doesn't really matter to me, but other people might find some utility in tracking this for statistical reasons. I think the utility of this would be to see how busy the transfer market is, and how much fragmentation it is creating, which would then be an indicator of how much attention PPML should be paying to it. Also, when IPv4 finally stagnates and dies, this will be reflected in the churn rate dropping off. This is of interest to people who need to know when it's okay to stop devoting resources to maintaining IPv4 apps and networks and concentrate on IPv6. > > Owen -- John Santos Evans Griffiths & Hart, Inc. 781-861-0670 ext 539 From owen at delong.com Thu May 12 22:44:36 2011 From: owen at delong.com (Owen DeLong) Date: Thu, 12 May 2011 19:44:36 -0700 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate In-Reply-To: <4DCC79BE.5070901@umn.edu> References: <7F5FC4554E42430FADDC0D376164DFA0@mike><0BB63D56-1605-4E1E-8F0B-B2083FDE4A96@delong.com><16AACD9632484C85BF6B855603CF07B4@mike><59EC8A7F22F247058ED74A896F0C6978@mike><907EE389FDC5448ABC46ADD06420B86D@video><4B99E603-7892-433A-9FB9-DB9A08D98F39@delong.com><599AC4287E79403D939568C89EB40922@video> <4DCC79BE.5070901@umn.edu> Message-ID: On May 12, 2011, at 5:22 PM, David Farmer wrote: > On 5/11/11 22:09 CDT, Mike Burns wrote: > ... >> I'm sure there are many more that I cannot think of. I agree with you >> that most buyers will have need, and I agree with you that most buyers >> will see the value of maintaining a valid ARIN whois record pointing to >> their authority. > > Unfortunately, most rules are meant to enforce something on those who are not necessarily acting reasonably. Above you save "most buyers will see value" what about those that don't. Or, what about those, that see a value in ensuring that their competitors can't get addresses and that the whole system doesn't shift to IPv6. I don't want to see something like that happen and I'm not entirely sure it can't. > Not necessarily. I believe that in the case of most ARIN policy, they are, first and foremost intended as a way for the community to communicate their consensus based intent of how number resources should be managed and depend to a large degree (though not entirely) on voluntary compliance. I agree entirely with all but the first sentence, just wanted to clarify that point on the first sentence. >> But the policy in APNIC was changed to remove needs requirements for >> transfers for the same reasons I am requesting its removal here. > > There are other policy differences between APNIC and ARIN then just needs or non-needs based transfers that are relevant to the changes due to IPv4 run-out. There is also a fundamental difference in the way APNIC and ARIN plan to operate the pool of addresses they have left, APNIC is reserving their whole /8 and allowing each organization a single /22. The ARIN community has reserved /10 of IPv4 for IPv6 purposes, but is allowing need to driver the run-out of the rest of the pool, limiting to 3 month need for fairness with new entrants and to reduce the competitive disparity created by IPv4 run-out. Additionally ARIN added officer attestations, to ensure organizational accountability for requests, I believe this will strongly suppress the tendency for ARIN to have a run-out curve like APNIC had during the first 4 months of 2011. > > So there are a number of differences in how ARIN and APNIC are approaching the fundamental changes that are occurring, and it would be a mistake to evaluate only one of these issues out of context with the others. I'm not trying to say APNIC did or is doing something wrong or ARIN did or is doing it right, but there is more to the picture than just needs or non-needs based transfers. If ARIN is going to change to a non-needs based transfer regime lime APNIC we may also need to change many more parts of policy as a consequence. > > The point here is that ARIN's policies are consistent, if you have need you can have addresses, be that from the free pool or from transfers. Much of the ARIN community didn't like to idea of addresses sitting at ARIN, if there was need for them. > > APNIC is also consistent, in that once they get down to the last /8, it doesn't matter if you need addresses you only get a /22 once from the last /8 pool, and you can transfer without need. > > I believe it would be unwise for ARIN community to change only one part of its policies to emulate APNIC. > I believe it is generally unwise for ARIN to emulate APNIC in a number of ways. A phrase my parents used to use with some frequency when I attempted such a justification was "If your friends jumped off a bridge, would you follow them?" While I think that APNIC's choice in this area is ill-advised, I respect their authority and their right to make said choice. However, I will not advocate ARIN emulating their behavior unless I see a good reason to do so. So far, the most compelling reason presented has been "because APNIC thinks it's right". (No, I'm not ignoring the other arguments, merely pointing out that they are even less compelling). Owen From tedm at ipinc.net Fri May 13 00:11:34 2011 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Thu, 12 May 2011 21:11:34 -0700 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate In-Reply-To: <4DCC79BE.5070901@umn.edu> References: <7F5FC4554E42430FADDC0D376164DFA0@mike><0BB63D56-1605-4E1E-8F0B-B2083FDE4A96@delong.com><16AACD9632484C85BF6B855603CF07B4@mike><59EC8A7F22F247058ED74A896F0C6978@mike><907EE389FDC5448ABC46ADD06420B86D@video><4B99E603-7892-433A-9FB9-DB9A08D98F39@delong.com><599AC4287E79403D939568C89EB40922@video> <4DCC79BE.5070901@umn.edu> Message-ID: <4DCCAF76.5080903@ipinc.net> On 5/12/2011 5:22 PM, David Farmer wrote: > On 5/11/11 22:09 CDT, Mike Burns wrote: > ... >> I'm sure there are many more that I cannot think of. I agree with you >> that most buyers will have need, and I agree with you that most buyers >> will see the value of maintaining a valid ARIN whois record pointing to >> their authority. > > Unfortunately, most rules are meant to enforce something on those who > are not necessarily acting reasonably. Above you save "most buyers will > see value" what about those that don't. Or, what about those, that see a > value in ensuring that their competitors can't get addresses and that > the whole system doesn't shift to IPv6. I don't want to see something > like that happen and I'm not entirely sure it can't. > >> But the policy in APNIC was changed to remove needs requirements for >> transfers for the same reasons I am requesting its removal here. > > There are other policy differences between APNIC and ARIN then just > needs or non-needs based transfers that are relevant to the changes due > to IPv4 run-out. There is also a fundamental difference in the way APNIC > and ARIN plan to operate the pool of addresses they have left, APNIC is > reserving their whole /8 and allowing each organization a single /22. > The ARIN community has reserved /10 of IPv4 for IPv6 purposes, but is > allowing need to driver the run-out of the rest of the pool, limiting to > 3 month need for fairness with new entrants and to reduce the > competitive disparity created by IPv4 run-out. Additionally ARIN added > officer attestations, to ensure organizational accountability for > requests, I believe this will strongly suppress the tendency for ARIN to > have a run-out curve like APNIC had during the first 4 months of 2011. > APNIC has higher population and less market penetration. It is in a very high rate of growth scenario. Arin has lower population and higher penetration. This alone puts it in a much lower rate of growth scenario. Ted > So there are a number of differences in how ARIN and APNIC are > approaching the fundamental changes that are occurring, and it would be > a mistake to evaluate only one of these issues out of context with the > others. I'm not trying to say APNIC did or is doing something wrong or > ARIN did or is doing it right, but there is more to the picture than > just needs or non-needs based transfers. If ARIN is going to change to a > non-needs based transfer regime lime APNIC we may also need to change > many more parts of policy as a consequence. > > The point here is that ARIN's policies are consistent, if you have need > you can have addresses, be that from the free pool or from transfers. > Much of the ARIN community didn't like to idea of addresses sitting at > ARIN, if there was need for them. > > APNIC is also consistent, in that once they get down to the last /8, it > doesn't matter if you need addresses you only get a /22 once from the > last /8 pool, and you can transfer without need. > > I believe it would be unwise for ARIN community to change only one part > of its policies to emulate APNIC. > >> My policy proposal also has the benefit of incentivizing legacy >> resources to come under RSA, and it serves to even the playing field >> between the disparate rights of legacy versus non-legacy holders. >> >> And my underlying point is the obvious one, that the very act of paying >> for address space is a very good indication of need, or at least >> perceived need on the part of the buyer. > > I think it is a good indication of perceived value in all cases, it is a > indication of need in some cases, but not in all cases. If you want to > corner the market on IPv4 there maybe sufficient value to someone to do > so, but that is not a valid need. And, this is the case where your > analysis breaks down. > > That said I'm not certain that current criteria for evaluating need will > even be valid once there is no longer a free pool. The basic idea that > you get a years worth of need based on your past years consumption of > addresses assumes the existence of a free pool. Once we get more than a > year into a market-like transfer system, what you used last year has > more to do with how much money you were willing to spend that what your > actual need was. And if the price was high the previous year and if you > simply evaluate your need by how much addressing you used last year when > the price was high that isn't necessarily a true representation of your > actual need. > > So I am equally skeptical of maintaining the current needs based system > as is, as I am of completely abandoning the concept of a needs basis. > Right now I'm thinking allowing transfers up to some size limit over > some period of time without justifying need more than putting up the > cash to do it, on the premise that within some safety limits it might be > a good idea to let the market work things out. However, if you want to > transfer more than those limits you can, but you must justify your need > beyond those limits. Either based on your previous years usage or based > on the fact that you have put previously transferred addresses into > documented use. > > Just throwing some numbers out, I'm thinking up to the equilivant of a > /12 (or a little more than 1 million IPv4 addresses) of transfers > received within 12 months per organization without documenting need. > There needs to be a mechanism that prevents gaming by creating multiple > organizations by the same real organization, maybe this is another place > for officer attestations. > > For most organizations a /12 is more or less unlimited, but that is > probably not enough to corner the market of IPv4 addresses and anyone > who really needs more than a /12 can probably justify it without much > more hassle then now. If they really need more than a /12 they are > probably quite adept at working with ARIN already. I think this would > give the invisible hand enough room to do its magic, without allowing > someone to corner the IPv4 market and destroy the Internet as we know > it. Depending how the actually market progresses, someone could maybe > still corner the IPv4 address market, but if they can do that with a /12 > then it will really be the time for everyone to move to IPv6. > > What I mean by "destroy the Internet as we know it", is anyone big > enough, or that anyone thinks is big enough, to stall the transition of > the Internet to IPv6, getting enough IPv4 addresses to attempt to do so. > I'm not sure anyone is big enough, but I'm just not sure no one is. > > In my view this doesn't abandon needs basis, it significantly changes it > based on new the realities we are facing. We are using the market to > determine need up to a cretin extent, and beyond that requiring > documented need. > From tedm at ipinc.net Fri May 13 00:27:18 2011 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Thu, 12 May 2011 21:27:18 -0700 Subject: [arin-ppml] Just a reminder of some quick mathematics for IPv4 that shows the long term impossibility of it In-Reply-To: References: <4DCC41D8.1010305@ipinc.net> Message-ID: <4DCCB326.7070302@ipinc.net> On 5/12/2011 4:44 PM, Owen DeLong wrote: > > On May 12, 2011, at 3:46 PM, William Herrin wrote: > >> On Thu, May 12, 2011 at 4:23 PM, Ted Mittelstaedt wrote: >>> So how exactly do we get the other 4.5 billion people on the Internet >>> using IPv4? >> >> Survey says: NAT. >> > That does not put the other 4.5 billion people on the internet. I think he was making a joke, Owen. Meaning that the "average person" if they are told a little bit about IPv4 runout they think "NAT can handle it" > That might put > the other 4.5 billion people onto a carefully controlled subset of the internet. > I do not advocate inflicting this damage on what would become the vast > majority of internet users. Rather, I think it is vastly better to deploy them > with IPv6 and let the rest of the internet catch up. > You cannot grow the Internet to be 3 times larger than it is now on RFC1918 numbers. The problem is the average person thinks of an IP address like a telephone number. They see the phone companies throw phone numbers around willy nilly. They don't understand that the two systems are completely different. >> >>> But, don't let something like mathematics bog your day down! >> >> Or technology either it would seem. >> > One man's "technology" is another man's nightmare. > I think he meant that from a technological standpoint the proposition is impossible. Ted > Owen > > From farmer at umn.edu Fri May 13 00:37:58 2011 From: farmer at umn.edu (David Farmer) Date: Thu, 12 May 2011 23:37:58 -0500 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate In-Reply-To: <4DCCAF76.5080903@ipinc.net> References: <7F5FC4554E42430FADDC0D376164DFA0@mike><0BB63D56-1605-4E1E-8F0B-B2083FDE4A96@delong.com><16AACD9632484C85BF6B855603CF07B4@mike><59EC8A7F22F247058ED74A896F0C6978@mike><907EE389FDC5448ABC46ADD06420B86D@video><4B99E603-7892-433A-9FB9-DB9A08D98F39@delong.com><599AC4287E79403D939568C89EB40922@video> <4DCC79BE.5070901@umn.edu> <4DCCAF76.5080903@ipinc.net> Message-ID: <4DCCB5A6.6060604@umn.edu> On 5/12/11 23:11 CDT, Ted Mittelstaedt wrote: > On 5/12/2011 5:22 PM, David Farmer wrote: ... >> competitive disparity created by IPv4 run-out. Additionally ARIN added >> officer attestations, to ensure organizational accountability for >> requests, I believe this will strongly suppress the tendency for ARIN to >> have a run-out curve like APNIC had during the first 4 months of 2011. >> > > APNIC has higher population and less market penetration. It is in a > very high rate of growth scenario. Arin has lower population and higher > penetration. This alone puts it in a much lower rate of growth scenario. > > Ted Yes, that is true. However that does not explain what happened, their own relative rate spiked significantly. See slide 4 of Geoff's APNIC Update presentation from San Juan, and make your own conclusions. https://www.arin.net/participate/meetings/reports/ARIN_XXVII/PDF/Monday/huston_apnic_update.pdf -- =============================================== 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 tedm at ipinc.net Fri May 13 00:44:57 2011 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Thu, 12 May 2011 21:44:57 -0700 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate In-Reply-To: References: <7F5FC4554E42430FADDC0D376164DFA0@mike> <0BB63D56-1605-4E1E-8F0B-B2083FDE4A96@delong.com> <16AACD9632484C85BF6B855603CF07B4@mike> <59EC8A7F22F247058ED74A896F0C6978@mike> <907EE389FDC5448ABC46ADD06420B86D@video> <4B99E603-7892-433A-9FB9-DB9A08D98F39@delong.com> <599AC4287E79403D939568C89EB40922@video> <4DCBFB89.6010804@matthew.at> <463771E5-094B-48CB-BAD7-C6D51088C26E@delong.com> <8DDDEFF8-91B6-4C38-83C3-EDDEB44E8BE8@matthew.at> Message-ID: <4DCCB749.8070202@ipinc.net> On 5/12/2011 4:15 PM, Matthew Kaufman wrote: > > On May 12, 2011, at 3:19 PM, Owen DeLong wrote: > >>> >> >> Forcing customer to use NAT is not within the scope of ARIN policy >> and I do not consider the failure or refusal to do so to be a >> manipulation of need. NAT is a degraded subset of internet access >> services. > > My point is that someone with lots of addresses that they *could* > free up can still claim they need more fairly easily. > >> >> There are many providers of much smaller size that are equally >> expert at dealing with ARIN justified need. I do not believe your >> argument hold water. > > They don't have enough money to play as the price approaches > infinity, however. > >> As I said, I think with needs-basis, the value of N tends to be >> larger than it will be without N. > > And I think you're wrong on that point. > >> >>> >>> One could argue, for instance, that *with* a needs basis Comcast >>> might end up holding nearly all the space... but without a needs >>> basis it might be an investment banking firm instead, who'd then >>> lease the space out to move providers than just Comcast. >>> >> >> I think you have a number of assertions there which are not at all >> proven: >> >> 1. I think it is unlikely $CABLECO could demonstrate 12 month need >> for all the addresses on their first go. Other providers and >> end-users, will therefore be likely able to obtain some fraction of >> the address space. > > Maybe. But a very small number of players with lots of money and > needs justification will be able to dominate the buy side trivially. > And very small amounts of gaming turn a /14 of need into a /13 or > /12, whereas the same amount applied to a tiny request for a /24 > isn't so interesting. > I will make one comment on this here. If there is gaming that will go on I suggest we look at the example of the US economy from the 15 years prior to 2007. As we all know there was a lot of financial gaming. But in the beginning it started with the large orgs, ie: Enron. And the economy didn't melt down. It wasn't until Ma & Pa Kettle got into the home flipping in the mid 2000's and we had thousands and thousands of little small fish ALSO gaming that the system collapsed. I think as long as the gaming is the large orgs the RIR's will be able to handle it but once the small ISP's get into the act we will end up with the dfz routes exploding and the system melting down. Ted > >> >> 2. I have no reason to believe that $CABLECO would not be ahead of >> the investment banking firm in line for the addresses as I suspect >> $CABLECO generally pays more attention to the goings on at ARIN >> than does $INVESTMENT_BANK. > > One would assume that some of the folks here who have an interest in > making money by speculating on IPv4 space are planning on having a > source of cash with which to do that. > >> >> 3. There is nothing to prove that $INVESTMENT_BANK would not prefer >> to lease all the addresses to $CABLECO vs. dealing with multiple >> tenants. In fact, there are many things to suggest that such a >> model would be highly preferable as it would maintain roughly the >> same revenue while simultaneously reducing costs which generally is >> viewed favorably by most of the investment bankers I know. > > Unknown, but possible. In fact, $CABLECO might be able to afford an > exclusive deal. But then this is NO DIFFERENT than $CABLECO going and > getting that much space itself.. so who cares? In either case your > doomsday scenario of a few big providers holding most of the space > happens, and needs justification did nothing to prevent it. > > Matthew Kaufman _______________________________________________ PPML > You are receiving this message because you are subscribed to the ARIN > Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or > manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml Please contact > info at arin.net if you experience any issues. From narten at us.ibm.com Fri May 13 00:53:03 2011 From: narten at us.ibm.com (Thomas Narten) Date: Fri, 13 May 2011 00:53:03 -0400 Subject: [arin-ppml] Weekly posting summary for ppml@arin.net Message-ID: <201105130453.p4D4r3ct003220@rotala.raleigh.ibm.com> Total of 244 messages in the last 7 days. script run at: Fri May 13 00:53:02 EDT 2011 Messages | Bytes | Who --------+------+--------+----------+------------------------ 21.31% | 52 | 28.51% | 689314 | owen at delong.com 18.03% | 44 | 19.55% | 472850 | mike at nationwideinc.com 13.52% | 33 | 8.64% | 208889 | jcurran at arin.net 7.79% | 19 | 8.98% | 217162 | tedm at ipinc.net 6.97% | 17 | 6.17% | 149186 | matthew at matthew.at 4.51% | 11 | 2.94% | 71045 | mysidia at gmail.com 2.05% | 5 | 3.09% | 74753 | stephen at sprunk.org 2.46% | 6 | 1.73% | 41774 | millnert at gmail.com 2.05% | 5 | 1.85% | 44711 | jeffrey.lyon at blacklotus.net 2.05% | 5 | 1.27% | 30622 | kkargel at polartel.com 0.82% | 2 | 2.31% | 55957 | rudi.daniel at gmail.com 1.64% | 4 | 1.07% | 25965 | bill at herrin.us 1.23% | 3 | 1.45% | 34948 | tvest at eyeconomics.com 1.23% | 3 | 1.27% | 30631 | ikiris at gmail.com 1.23% | 3 | 1.24% | 29897 | fernattj at gmail.com 1.23% | 3 | 1.06% | 25559 | farmer at umn.edu 1.23% | 3 | 0.79% | 19221 | info at arin.net 1.23% | 3 | 0.77% | 18503 | dogwallah at gmail.com 1.23% | 3 | 0.68% | 16541 | joelja at bogus.com 1.23% | 3 | 0.62% | 14894 | john at egh.com 0.82% | 2 | 0.65% | 15658 | cengel at conxeo.com 0.82% | 2 | 0.49% | 11780 | v6ops at globis.net 0.41% | 1 | 0.85% | 20674 | scottleibrand at gmail.com 0.41% | 1 | 0.45% | 10987 | warren at wholesaleinternet.com 0.41% | 1 | 0.38% | 9305 | lar at mwtcorp.net 0.41% | 1 | 0.38% | 9248 | warren at wholesaleinternet.net 0.41% | 1 | 0.38% | 9163 | gary.buhrmaster at gmail.com 0.41% | 1 | 0.38% | 9081 | billd at cait.wustl.edu 0.41% | 1 | 0.36% | 8646 | narten at us.ibm.com 0.41% | 1 | 0.34% | 8178 | rbf+arin-ppml at panix.com 0.41% | 1 | 0.33% | 8001 | springer at inlandnet.com 0.41% | 1 | 0.31% | 7394 | john.sweeting at twcable.com 0.41% | 1 | 0.28% | 6736 | gawul00 at gmail.com 0.41% | 1 | 0.26% | 6282 | george.herbert at gmail.com 0.41% | 1 | 0.19% | 4631 | vixie at vix.com --------+------+--------+----------+------------------------ 100.00% | 244 |100.00% | 2418186 | Total From owen at delong.com Fri May 13 05:58:35 2011 From: owen at delong.com (Owen DeLong) Date: Fri, 13 May 2011 02:58:35 -0700 Subject: [arin-ppml] Just a reminder of some quick mathematics for IPv4 that shows the long term impossibility of it In-Reply-To: <4DCCB326.7070302@ipinc.net> References: <4DCC41D8.1010305@ipinc.net> <4DCCB326.7070302@ipinc.net> Message-ID: <6ACB242A-561D-412F-827F-98E50BDC8276@delong.com> On May 12, 2011, at 9:27 PM, Ted Mittelstaedt wrote: > On 5/12/2011 4:44 PM, Owen DeLong wrote: >> >> On May 12, 2011, at 3:46 PM, William Herrin wrote: >> >>> On Thu, May 12, 2011 at 4:23 PM, Ted Mittelstaedt wrote: >>>> So how exactly do we get the other 4.5 billion people on the Internet >>>> using IPv4? >>> >>> Survey says: NAT. >>> >> That does not put the other 4.5 billion people on the internet. > > I think he was making a joke, Owen. Meaning that the "average person" > if they are told a little bit about IPv4 runout they think "NAT can handle it" > I doubt he was joking. Bill is a rather strong proponent of the idea that NAT works just fine. He even seems to believe it is a security feature. >> That might put >> the other 4.5 billion people onto a carefully controlled subset of the internet. >> I do not advocate inflicting this damage on what would become the vast >> majority of internet users. Rather, I think it is vastly better to deploy them >> with IPv6 and let the rest of the internet catch up. >> > > You cannot grow the Internet to be 3 times larger than it is now > on RFC1918 numbers. The problem is the average person thinks of an > IP address like a telephone number. They see the phone companies > throw phone numbers around willy nilly. They don't understand that > the two systems are completely different. > I think we're saying the same thing, though I'm not entirely convinced about your reasoning above. >>> >>>> But, don't let something like mathematics bog your day down! >>> >>> Or technology either it would seem. >>> >> One man's "technology" is another man's nightmare. >> > > I think he meant that from a technological standpoint the proposition > is impossible. > No, he was claiming that the technology (NAT) would make it possible. Bill and I have a long history of debating the lack of merit of NAT. Owen From bill at herrin.us Fri May 13 09:30:09 2011 From: bill at herrin.us (William Herrin) Date: Fri, 13 May 2011 09:30:09 -0400 Subject: [arin-ppml] Just a reminder of some quick mathematics for IPv4 that shows the long term impossibility of it In-Reply-To: References: <4DCC41D8.1010305@ipinc.net> Message-ID: On Thu, May 12, 2011 at 7:44 PM, Owen DeLong wrote: > On May 12, 2011, at 3:46 PM, William Herrin wrote: >> On Thu, May 12, 2011 at 4:23 PM, Ted Mittelstaedt wrote: >>> So how exactly do we get the other 4.5 billion people on the Internet >>> using IPv4? >> >> Survey says: NAT. > > That does not put the other 4.5 billion people on the internet. The half billion or so who've joined the Internet behind NATs this past decade seem to think differently. Who am I to disagree with them? Who are you. -Bill -- 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 Fri May 13 09:49:48 2011 From: info at arin.net (ARIN) Date: Fri, 13 May 2011 09:49:48 -0400 Subject: [arin-ppml] ARIN-prop-150 Reclamation Hold Message-ID: <4DCD36FC.3000501@arin.net> ARIN-prop-150 Reclamation Hold 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-150 Reclamation Hold Proposal Originator: Matthew Kaufman Proposal Version: 1 Date: 13 May 2011 Proposal type: new Policy term: permanent Policy statement: Add a new section to the NRPM: "All resources reclaimed by ARIN shall not be returned to the free pool or otherwise reassigned to any entity than the original registrant for a period of 36 months." Rationale: As the pressures on the system become greater with IPv4 runout, there will be more call for ARIN to reclaim address space. When addresses that are reclaimed are reused too soon, a variety of undesirable outcomes may result. This provides sufficient time for the resources to go unused prior to reassignment and/or to be re-justified by the original registrant, or returned to the proper holder in the case of hijackings. This policy could be restricted to IPv4 space, but it may be useful for AS numbers and has no major impact on IPv6 space (due to the large free pool), so it might as well apply to all. Timetable for implementation: immediate From dogwallah at gmail.com Fri May 13 09:52:34 2011 From: dogwallah at gmail.com (McTim) Date: Fri, 13 May 2011 16:52:34 +0300 Subject: [arin-ppml] ARIN-prop-150 Reclamation Hold In-Reply-To: <4DCD36FC.3000501@arin.net> References: <4DCD36FC.3000501@arin.net> Message-ID: On Fri, May 13, 2011 at 4:49 PM, ARIN wrote: > > ARIN-prop-150 Reclamation Hold > > Proposal Originator: Matthew Kaufman > > Proposal Version: 1 > > Date: 13 May 2011 > > Proposal type: new > > Policy term: permanent > > Policy statement: > > Add a new section to the NRPM: > "All resources reclaimed by ARIN shall not be returned to the free pool > or otherwise reassigned to any entity than the original registrant for a > period of 36 months." I am opposed to this. 36 months is far too long IMO for a "quarantine" -- Cheers, McTim "A name indicates what we seek. An address indicates where it is. A route indicates how we get there."? Jon Postel From mike at nationwideinc.com Fri May 13 10:45:50 2011 From: mike at nationwideinc.com (Mike Burns) Date: Fri, 13 May 2011 10:45:50 -0400 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate References: <7F5FC4554E42430FADDC0D376164DFA0@mike> <20110512141453.K34430@mail.inlandnet.com> Message-ID: Hi John, thanks for the feedback, responses inline. > >> 1. Policy Proposal Name: IPv4 Transfer Policy Change to Keep Whois >> Accurate > > I note with interest the explanation that the Policy Proposal Name is > intended to be taken with tongue firmly in cheek. I'm glad that's cleared > up as I was fixin to expostulate, > I will correct that when I send it to policy at arin.net for official distribution. >> >> 10. ARIN will not use utilization as a measure of policy compliance >> for addresses transferred under 8.3. > > because I was confused as to why a policy whose major (only?) proposed > effect is to remove utilization devotes most of its wording to WHOIS > accuracy. Who wouldn't want that? But I understand now that it is > intended only as a witticism. I will therefore attempt to speak only to > the non-WHOIS part of the proposal. > No, there are two major effects to my proposal, one related to removing needs-requirements from transfers, the other allowing existing RSA holders to sell unused IPv4 addresses without fear of a review/return request if they have had them for more than a year. I copied the proposal largely from the APNIC proposal which passed there, and I believe that the Whois accuracy argument is the most persuasive, the name is a witticism, not the rationale. I fully believe that if Microsoft chose not to sign an LRSA with ARIN, or if ARIN had never become aware of the deal, MS could have legally consummated the deal with Nortel, and that somebody would have routed the addresses for Microsoft. The net effect would have been Whois data for those blocks showing allocations to the original and long defunct entities, instead of pointing accurately to Microsoft. >> >> 8. Rationale: > > > >> >> The underlying proposition behind this policy proposal is that the >> registry of IPv4 addresses operated by ARIN is of general utility and >> value only while it accurately describes the current state of address >> distribution. If a class of address movement transactions are excluded >> from being entered in the registry, then the registry will have >> decreasing value to the broader community, and the integrity of the >> network itself is thereby compromised. This proposal's central aim is >> to ensure the continuing utility and value of the ARIN address >> registry by allowing the registry to record transactions where IPv4 >> addresses are transfered between ARIN account holders. > > But where is utilization in this underlying proposition? As far as I can tell, the word utilization in the paragraph above refers to the utilization of the whois registry, not address space. I have argued that when things are valuable, especially if they are valuable for a short time, they will be sold if not needed. To me, this will naturally increase utilization, I point to the billion or so unrouted but allocated addresses as some evidence that there is more efficiency to be wrung from these allocations. Yes, I understand that some allocated but unrouted addresses are used internally, my perception is that this is a subset of unadvertised but allocated space, much of which is simply wasted. My argument about needs requirement is that it is an artificial contrivance designed to constrain free pool allocations whose purpose has been subsumed by the mechanism of price in the transfer market. And that maintaining that market artificiality will result in some transactions being performed privately, and because the addresses will still work for their intended purpose whether or not ARIN is notified, and because there is no legal venue to challenge the transaction if it involves legacy space, those transactions will not be reflected properly in Whois. > > Having observed the preparatory discussions that led to this proposal and > subsequent comments to it, I recall massive dialogue on the MS/NN > transaction. To integrate that subject with this proposal, I must go to > comments to the proposal for guidance. In the authors response of 11 May > 2011 17:12:57 to Tom Vest regarding "current legal realities" it is > stated: "4. Finally, the requirement at issue here, a needs analysis had > to be completed by ARIN, which magically showed that MS qualified for > exactly the amount already bid for and negotiated the sale of." > > And this paragraph > > "If they had needed fewer addresses, they could have bid for less than the > full pool. If they needed more addresses, they should have received an > additional ARIN allocation. Paraphrasing Goldilocks, the random allocation > of addresses to long-ago Nortel acquisitions was "just right." > > which I interpret as expressing disbelief. I could be wrong here. > No, you are right, I was expressing disbelief. I believe that all the other issues with the transfer as negotiated prior to ARIN's knowledge of the deal were ably finessed so as to fit the deal into the existing policies, via some ex-post-facto 8.2 transfers, stretching "RSA" to include "LRSA", syntactically applying "single aggregate" to need and not to receipt of addresses, and considering the "issue to ARIN" language to be a mere procedurality. To my mind, the most difficult effort in shoehorning the transaction into existing policy was the needs requirement. I believe that requirement contorted ARIN into knots, and at least put ARIN into the potentially corruptible position of deciding the fate of a $7.5 million dollar transaction. I believe that had my proposed policy been in effect, the deal would have been simply booked into Whois, the market would have put addresses right where they were needed (according to ARIN), unused addresses would have come off the shelf, and those addresses would be put under the same RSA that every other RSA holder is under, and questions about ARIN trust and potential corruptability would be absent. > > 2) It looks to me like we have a fundamental logic flaw here. This > proposal will fix a problem that does not exist! From my perspective, a > needs assessment was properly conducted in the Microsoft/Nortel bankruptcy > affair and ARIN policy was followed. John Curran says so, author says no. > Which brings us to the realm of belief and he said, he said. Who do I > believe, John or author? Well, John has been exposed to the facts of the > matter and cannot talk about it, except obliquely. The rest of us have > only our interpretations of public documents. John has a fiduciary > responsibility here, so real penalties might apply if he prevaricates. > Author can pretty much say what he likes, the worst we could do is get > quite cross. John has several decades of credibility in public policy and > networking. So might the author, but I can't say. But here's the deal, IT > DOESN'T MATTER. We will never know and can't know. We may never know, but have you considered an NDA with a time limit? Or WikiLeaks? So may we please > dispense with the APNIC did it thing? It's a fallacy anyway: > http://en.wikipedia.org/wiki/Argumentum_ad_populum > respectfully > > John Springer > I will make a deal. If aspersions of poor stewardship can be done away with, I will do away with the APNIC references. It doesn't advance the argument and doesn't advance our relationship with the APNIC steward community. It is easy to declare one person a poor steward, it is less believable when another steward community is being included in the smear. I have already requested that posters stop equating my proposal to remove needs tests from transfers to phrases like "jettisoning stewardship". We are arguing over proper stewardship, as stewards, and I have tried to refrain from accusing those who oppose my policy of being poor stewards of Whois. Regards, Mike From jeffrey.lyon at blacklotus.net Fri May 13 10:48:54 2011 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Fri, 13 May 2011 10:48:54 -0400 Subject: [arin-ppml] ARIN-prop-150 Reclamation Hold In-Reply-To: References: <4DCD36FC.3000501@arin.net> Message-ID: On Fri, May 13, 2011 at 9:52 AM, McTim wrote: > On Fri, May 13, 2011 at 4:49 PM, ARIN wrote: > >> >> ARIN-prop-150 Reclamation Hold >> >> Proposal Originator: Matthew Kaufman >> >> Proposal Version: 1 >> >> Date: 13 May 2011 >> >> Proposal type: new >> >> Policy term: permanent >> >> Policy statement: >> >> Add a new section to the NRPM: >> "All resources reclaimed by ARIN shall not be returned to the free pool >> or otherwise reassigned to any entity than the original registrant for a >> period of 36 months." > > I am opposed to this. ?36 months is far too long IMO for a "quarantine" > > -- > Cheers, > > McTim > "A name indicates what we seek. An address indicates where it is. A > route indicates how we get there."? Jon Postel > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > Strongly opposed. IPv4 does not require euthanasia. -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications - AS32421 First and Leading in DDoS Protection Solutions From hannigan at gmail.com Fri May 13 10:50:28 2011 From: hannigan at gmail.com (Martin Hannigan) Date: Fri, 13 May 2011 10:50:28 -0400 Subject: [arin-ppml] ARIN-prop-150 Reclamation Hold In-Reply-To: References: <4DCD36FC.3000501@arin.net> Message-ID: On Fri, May 13, 2011 at 9:52 AM, McTim wrote: > On Fri, May 13, 2011 at 4:49 PM, ARIN wrote: > >> >> ARIN-prop-150 Reclamation Hold >> >> Proposal Originator: Matthew Kaufman >> >> Proposal Version: 1 >> >> Date: 13 May 2011 >> >> Proposal type: new >> >> Policy term: permanent >> >> Policy statement: >> >> Add a new section to the NRPM: >> "All resources reclaimed by ARIN shall not be returned to the free pool >> or otherwise reassigned to any entity than the original registrant for a >> period of 36 months." > > I am opposed to this. ?36 months is far too long IMO for a "quarantine" Agreed, we just had a proposal with significant support to return address reclaimed to the free pool with a high expectation of "faster", not slower. I don't see why this would be any different hence I expect a lack of community support. In fact, I think that the author should consider withdrawing this to save us all some time. We need to leave this as an administrative decision influenced by the community vs. a rule. This is an example of not knowing what you might not know. Best, -M< From hannigan at gmail.com Fri May 13 11:13:01 2011 From: hannigan at gmail.com (Martin Hannigan) Date: Fri, 13 May 2011 11:13:01 -0400 Subject: [arin-ppml] Draft Proposal 2011-1 - Comments request - Globally Coordinated Transfer Policy In-Reply-To: References: Message-ID: On Tue, May 10, 2011 at 1:34 PM, Bill Darte wrote: > Hello, > > After the San Juan meeting, the Advisory Council tried to resolve > differences of opinion among themselves and to ascertain the level of > consensus around Draft Policy 2011-1 Globally Coordinated Transfer > Policy...and also to determine what objections still remain. > > The policy text reviewed at the meeting was as follows: > Any RIR's resource registrant may transfer IPv4 addresses to the resource > registrant of another RIR as long as the two RIRs agree and maintain > compatible, needs-based transfer policies that exercise Internet stewardship > consistent with the values expressed in RFC2050. > *************** > > It was clear from the meeting that the community wanted the AC to continue > to work on this policy.? I have asked each AC member to join this > conversation along with your input to: > 1. Identify support or objection Objection. > 2. If objections exist, to succinctly identify what they are..and, The references to RFC 2050 which in the last 6 months has enjoyed almost universal agreement that it's not relevant; it was written in 1996 in a time and place that is far different than today, it was a Best *Current* Practice (emphasis added) "BCP". > 3. How objections might be concisely remedied in text > Remove the reference to RFC 2050 and state something along the lines of transfers being in the ARIN communities interest. I would also argue that transparency will be critical and some additional text around reporting requirements might be relevant. Additional discussion around needs-based requirements would be also be interesting. Finally, how is this proposal being coordinated globally? Best, -M< From Robert.Smales at cw.com Fri May 13 11:11:34 2011 From: Robert.Smales at cw.com (Smales, Robert) Date: Fri, 13 May 2011 16:11:34 +0100 Subject: [arin-ppml] ARIN-prop-150 Reclamation Hold In-Reply-To: Message-ID: <602ACF092EFFB044931BD8746C19AD2F04BAC8A9@gbcwswiem006.ad.plc.cwintra.com> >> ARIN-prop-150 Reclamation Hold >> >> Proposal Originator: Matthew Kaufman >> >> Proposal Version: 1 >> >> Date: 13 May 2011 >> >> Proposal type: new >> >> Policy term: permanent >> >> Policy statement: >> >> Add a new section to the NRPM: >> "All resources reclaimed by ARIN shall not be returned to the free pool >> or otherwise reassigned to any entity than the original registrant for a >> period of 36 months." > > I am opposed to this. ?36 months is far too long IMO for a "quarantine" +1 against. It is hard to imagine that anyone is going to return a block that was in use last week or that someone whose address block has been hijacked and returned to the pool isn't going to notice for two years. The likliest outcome of this policy is that at some point after ARIN has handed out its last /29, someone with a pressing and reasonable need for a v4 allocation will have to be told "sorry, we will have a /22 available in 18 months' time but not before then" Three years is a long time in the telecoms/Internet world, a dormant period of 12 months would be more reasonable. Robert Robert Smales Technical Engineer Cable&Wireless Worldwide www.cw.com This e-mail has been scanned for viruses by the Cable&Wireless Worldwide e-mail security system. For more information on a proactive managed e-mail secure service, visit http://www.cw.com/managed-exchange The information contained in this e-mail is confidential and may also be subject to legal privilege. It is intended only for the recipient(s) named above. If you are not named above as a recipient, you must not read, copy, disclose, forward or otherwise use the information contained in this email. If you have received this e-mail in error, please notify the sender (whose contact details are above) immediately by reply e-mail and delete the message and any attachments without retaining any copies. Cable & Wireless Worldwide plc Registered in England and Wales. Company Number 07029206 Registered office: Liberty House, 76 Hammersmith Road, London W14 8UD, England From cengel at conxeo.com Fri May 13 11:21:57 2011 From: cengel at conxeo.com (Chris Engel) Date: Fri, 13 May 2011 11:21:57 -0400 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate In-Reply-To: <7834D82CC7C64E64820785568E598738@mike> References: <7F5FC4554E42430FADDC0D376164DFA0@mike><0BB63D56-1605-4E1E-8F0B-B2083FDE4A96@delong.com><16AACD9632484C85BF6B855603CF07B4@mike><59EC8A7F22F2470 58ED74A896F0C6978@mike><907EE389FDC5448ABC46ADD06420B86D@video><4B99E603-7892- 433A-9FB9-DB9A08D98F39@delong.com><599AC4287E79403D939568C89EB40922@video><4DC BFB89.6010804@matthew.at><463771E5-094B-48CB-BAD7-C6D51088C26E@delong.com><8DDDEFF8-91B6-4C38-83C3-EDDEB44E8BE8@matthew.at><02540BF3-D17E-4069-BC98-ECC29053A4CA@matthew.at> <7834D82CC7C64E64820785568E598738@mike> Message-ID: > Ola John, > > > I'll actually disagree with the presumption that incentives towards > > gaming will increase with the value of IP address space, if we are > > considering a transfer market with needs-based qualification. While > > it is true that there might be incentive to get creative with the > > total expressed need to obtain more space than otherwise qualified > > for, the existence of a market (if properly functioning) means that > > there is some reassurance that additional space will more likely be > > available when needed in the future, even if at a slightly increased > > price. This actually reduces the pressure to try and game the system > > when compared with the present environment and potential that there > > will be no more resources in the free pool when you come back later. > > > The other potential form of gaming would by a non-operator speculator, > > who wishes to participate in the market (despite having no actual need > > at all), and so needs to fabricate imaginary need to be able to obtain > > IP space from the market for subsequent monetization. While there is no > > doubt of the incentives involved, there is also significant risk since > > intangible IP registration entries are readily corrected in such cases > > of fraudulent representations to the registry. > > If the needs requirement can not be met by the buyer, he will have the > incentive to game the needs requirement. > If the value of the addresses at question are higher, the incentive will be > higher, to my mind. > > But you are absolutely correct in that having a vibrant and functioning > market is the best way to assuage fears of future supply shocks and > attendant price increases. > > And you are correct in that the incentive to game the system for allocations > from the free pool is reaching its highest point in the months to come. > Pray be diligent! > > As far as what you term a non-operator speculator, you see the risk of > gaming the needs analysis. > The same risks lead to not-notifying ARIN and continuing to use the > addresses under the purchaser's name, leaving Whois in more disarray. > > Regards, > Mike > Actually, I would argue that "manufactured" need would be functionally identical to "genuine" need from the point of anyone forced to make approval decisions based upon that, unless the organization attempting to game the system was incredibly un-artful in their attempt. How would someone charged with deciding to approve the "IP-Enabled virtual pet rock program" that was simply instituted to grab and hold IP addresses for a time until they were actually needed for a legitimate project or could be sold (at a profit) to someone who had a legitimate need for those addresses..... from a company that legitimately wanted to enter the "IP-Enabled virtual pet rock" business and were simply bad at business planning? On paper, they'd be identical....the only thing that would be different was the motivation of the organization acquiring the resources....and how could anyone discern that without being a mind-reader? Note that speculators always risk being left holding the bag when the bottom falls out of the market they are playing with. Risk is inherent in what they do...unfortunately it doesn't seem to curtail their activities very much in most scarcity markets. Functionally the only things I see a needs based requirement accomplishing in a transfer market is artificially inflating the cost of transfers, increasing the cost for ARIN to administer transfers and creating a new job position among certain companies of "needs justification designer". I don't think it's going to accomplish what many proponents might hope it would very effectively. In a market where acquiring IP addresses is relatively trivial (i.e. unassigned space from ARIN), I can certainly see why there has to be some artificial barrier built into the system to prevent people from acquiring IP space for trivial reasons....with a scarcity market, the cost of acquisition through transfers itself should act as a barrier to that. Anyway, that's how I see it...for whatever it's worth. Christopher Engel (representing only my own personal views) From matthew at matthew.at Fri May 13 11:34:24 2011 From: matthew at matthew.at (Matthew Kaufman) Date: Fri, 13 May 2011 08:34:24 -0700 Subject: [arin-ppml] ARIN-prop-150 Reclamation Hold In-Reply-To: <602ACF092EFFB044931BD8746C19AD2F04BAC8A9@gbcwswiem006.ad.plc.cwintra.com> References: <602ACF092EFFB044931BD8746C19AD2F04BAC8A9@gbcwswiem006.ad.plc.cwintra.com> Message-ID: <4DCD4F80.5030007@matthew.at> On 5/13/2011 8:11 AM, Smales, Robert wrote: >>> ARIN-prop-150 Reclamation Hold >>> >>> Proposal Originator: Matthew Kaufman >>> >>> Proposal Version: 1 >>> >>> Date: 13 May 2011 >>> >>> Proposal type: new >>> >>> Policy term: permanent >>> >>> Policy statement: >>> >>> Add a new section to the NRPM: >>> "All resources reclaimed by ARIN shall not be returned to the free pool >>> or otherwise reassigned to any entity than the original registrant for a >>> period of 36 months." >> I am opposed to this. 36 months is far too long IMO for a "quarantine" > +1 against. It is hard to imagine that anyone is going to return a block that was in use last week Not intended to apply to returns. > or that someone whose address block has been hijacked and returned to the pool isn't going to notice for two years. This is actually *very* possibly... hijacked blocks are typically hijacks of things that people don't in fact notice for some time... could be a company that uses the block internally but doesn't advertise it on the global Internet right now, could be someone whose contact info got very out of date, could be a block where the contact info got screwed up a long time ago (I have a /24 myself that was listed in one name and got changed, without me asking, to another (the name of its transit ISP, in fact) around the time of the ARIN formation). Getting the block back when you're the rightful registrant is a lot easier if it hasn't been assigned to someone else who is now using it and (post-runout) can't get a substitute... so there needs to be some holddown time. If you think 36 months is too long, propose a change to the time. > The likliest outcome of this policy is that at some point after ARIN has handed out its last /29, someone with a pressing and reasonable need for a v4 allocation will have to be told "sorry, we will have a /22 available in 18 months' time but not before then" "We *might* have a /22 available in 18 months time if there are no challenges to the reclaim we did" would be more accurate. > Three years is a long time in the telecoms/Internet world, a dormant period of 12 months would be more reasonable. I'd be willing to entertain shorter timers than 36 months... 12 is probably a little short, so maybe 18? Matthew Kaufman From matthew at matthew.at Fri May 13 11:35:25 2011 From: matthew at matthew.at (Matthew Kaufman) Date: Fri, 13 May 2011 08:35:25 -0700 Subject: [arin-ppml] ARIN-prop-150 Reclamation Hold In-Reply-To: References: <4DCD36FC.3000501@arin.net> Message-ID: <4DCD4FBD.7090901@matthew.at> On 5/13/2011 7:48 AM, Jeffrey Lyon wrote: > >> I am opposed to this. 36 months is far too long IMO for a "quarantine" Right now the period is "none, or whatever staff thinks is good". What time period would you suggest? (Once we have consensus around the time, I'll submit a revision to the proposal) Matthew Kaufman From bill at herrin.us Fri May 13 11:38:37 2011 From: bill at herrin.us (William Herrin) Date: Fri, 13 May 2011 11:38:37 -0400 Subject: [arin-ppml] ARIN-prop-150 Reclamation Hold In-Reply-To: <4DCD36FC.3000501@arin.net> References: <4DCD36FC.3000501@arin.net> Message-ID: On Fri, May 13, 2011 at 9:49 AM, ARIN wrote: > ARIN-prop-150 Reclamation Hold > Proposal Originator: Matthew Kaufman > > Add a new section to the NRPM: > "All resources reclaimed by ARIN shall not be returned to the free pool > or otherwise reassigned to any entity than the original registrant for a > period of 36 months." LIRs are prevented from implementing this sort of policy since such reserved addresses do not count towards their utilization. What problems are solved by implementing this policy at an RIR level but requiring LIRs to not implement the same? > This provides sufficient time for the resources to go unused > prior to reassignment and/or to be re-justified by the original > registrant, or returned to the proper holder in the case of hijackings. This could be solved with a much weaker requirement: "ARIN shall not reallocate recovered address space while its status is under dispute by a prior registrant." Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From tedm at ipinc.net Fri May 13 11:40:25 2011 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Fri, 13 May 2011 08:40:25 -0700 Subject: [arin-ppml] Just a reminder of some quick mathematics for IPv4 that shows the long term impossibility of it In-Reply-To: References: <4DCC41D8.1010305@ipinc.net> Message-ID: <4DCD50E9.6020302@ipinc.net> On 5/13/2011 6:30 AM, William Herrin wrote: > On Thu, May 12, 2011 at 7:44 PM, Owen DeLong wrote: >> On May 12, 2011, at 3:46 PM, William Herrin wrote: >>> On Thu, May 12, 2011 at 4:23 PM, Ted Mittelstaedt wrote: >>>> So how exactly do we get the other 4.5 billion people on the Internet >>>> using IPv4? >>> >>> Survey says: NAT. >> >> That does not put the other 4.5 billion people on the internet. > > The half billion or so who've joined the Internet behind NATs this > past decade seem to think differently. Who am I to disagree with them? > Who are you. > I think your just seeing if we would take you serious, Bill. You cannot possibly believe the Internet can add all those additional people in the same manner as they have added the first 2 billion. NATs work by using an external public address. When all the external public addresses are gone, you can't setup any more NATs Perhaps if 10 years ago carrier-grade NAT had been mandated and all public addressing had been prohibited from end-users, and only allowed to operate on transit router and networks, while all end-node AS's were just given a small allocation, like a /24, and expected to put all their end users behind centralized NATs, why then it might have slowed address uptake to where it would have been feasible. But that didn't happen because the CPUs and hardware of the time were not powerful enough to do it for the core to do it. And it would have required giving up a fundamental property of the Internet which is that every host have a unique IP address. All that happened with NAT is that we changed the premise slightly to allow for the notion that small pockets of hosts on the Internet could have unique IP addresses from other small pockets of hosts, mixed in with a sea of regular hosts that had unique addresses, but with the stipulation that those small pockets could never be coalesced into significantly large pockets. That slowed IP address uptake and gave us the breathing room for large behemoths like Microsoft and Cisco to fully implement IPv6 in their products, but the other part of that fundamental tradeoff - the stipulation that the small pockets cannot be coalesced - now prevents NAT from getting any larger. For anyone who really believes NAT can get the rest of the 4.5 billion people in the world on the Internet without significantly changing anything for the first 2.5 billion, consider this. The entire Internet would have to be so disrupted to put a carrier NAT solution into place, with so many people having to give up routable numbers, that it would be equivalent to the disruption caused by dropping IPv4 and going to IPv6. The resulting solution, with translators everywhere and significantly increased expenditures for all networks in hardware, increased fragility caused by introducing so much additional hardware into the network, and decreased flexibility as simple packet moving on the Internet turns into a huge bureaucracy, would be a far worse result than a single routable network with full end 2 end connectivity available to any host that wants it, a network where routers are routers and hosts are hosts and network devices go back to being simple devices in the dusty corner, plugged into printers and such. For everything there is a season, and a time for every purpose under heaven. IPv4's time is ending, IPv6's time is beginning. Ted From tedm at ipinc.net Fri May 13 11:45:53 2011 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Fri, 13 May 2011 08:45:53 -0700 Subject: [arin-ppml] ARIN-prop-150 Reclamation Hold In-Reply-To: <4DCD36FC.3000501@arin.net> References: <4DCD36FC.3000501@arin.net> Message-ID: <4DCD5231.3060908@ipinc.net> opposed. I have no objection to a "cooling off" period and think it is a good idea, but we must assume ARIN staff to be competent enough to be able to make a case-by-case determination of how long a cooling off period needs to be for each block that comes back. It's part of their jobs, that is the sort of thing they are paid to do. If you changed it to say the MAXIMUM period addresses could not be reused would be 36 months, and let ARIN staff make a minimum determination, I would not oppose it. Ted On 5/13/2011 6:49 AM, ARIN wrote: > ARIN-prop-150 Reclamation Hold > > 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-150 Reclamation Hold > > Proposal Originator: Matthew Kaufman > > Proposal Version: 1 > > Date: 13 May 2011 > > Proposal type: new > > Policy term: permanent > > Policy statement: > > Add a new section to the NRPM: > "All resources reclaimed by ARIN shall not be returned to the free pool > or otherwise reassigned to any entity than the original registrant for a > period of 36 months." > > Rationale: > As the pressures on the system become greater with IPv4 runout, there > will be more call for ARIN to reclaim address space. When addresses that > are reclaimed are reused too soon, a variety of undesirable outcomes may > result. This provides sufficient time for the resources to go unused > prior to reassignment and/or to be re-justified by the original > registrant, or returned to the proper holder in the case of hijackings. > This policy could be restricted to IPv4 space, but it may be useful for > AS numbers and has no major impact on IPv6 space (due to the large free > pool), so it might as well apply to all. > > 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 joelja at bogus.com Fri May 13 11:48:43 2011 From: joelja at bogus.com (Joel Jaeggli) Date: Fri, 13 May 2011 08:48:43 -0700 Subject: [arin-ppml] Just a reminder of some quick mathematics for IPv4 that shows the long term impossibility of it In-Reply-To: References: <4DCC41D8.1010305@ipinc.net> Message-ID: <4DCD52DB.2080209@bogus.com> On 5/13/11 6:30 AM, William Herrin wrote: > On Thu, May 12, 2011 at 7:44 PM, Owen DeLong wrote: >> On May 12, 2011, at 3:46 PM, William Herrin wrote: >>> On Thu, May 12, 2011 at 4:23 PM, Ted Mittelstaedt wrote: >>>> So how exactly do we get the other 4.5 billion people on the Internet >>>> using IPv4? >>> >>> Survey says: NAT. >> >> That does not put the other 4.5 billion people on the internet. > > The half billion or so who've joined the Internet behind NATs this > past decade seem to think differently. Who am I to disagree with them? > Who are you. There are enough ip's for all the nats to site behind either, it's not rocket science... maintaining large numbers of parallel addressing planes the require state-management for egress has a real cost and those things have nothing like the scaling properties of the stateless v4 internet you grew up with. > -Bill > > > > From matthew at matthew.at Fri May 13 11:48:59 2011 From: matthew at matthew.at (Matthew Kaufman) Date: Fri, 13 May 2011 08:48:59 -0700 Subject: [arin-ppml] ARIN-prop-150 Reclamation Hold In-Reply-To: References: <4DCD36FC.3000501@arin.net> Message-ID: <4DCD52EB.7030806@matthew.at> On 5/13/2011 8:38 AM, William Herrin wrote: > On Fri, May 13, 2011 at 9:49 AM, ARIN wrote: >> ARIN-prop-150 Reclamation Hold >> Proposal Originator: Matthew Kaufman >> >> Add a new section to the NRPM: >> "All resources reclaimed by ARIN shall not be returned to the free pool >> or otherwise reassigned to any entity than the original registrant for a >> period of 36 months." > LIRs are prevented from implementing this sort of policy since such > reserved addresses do not count towards their utilization. What > problems are solved by implementing this policy at an RIR level but > requiring LIRs to not implement the same? LIRs have direct circuit-level (or equivalent) relationships with the address users. RIRs do not. It would be very unusual for someone to have provider-assigned space and no ongoing contact or billing relationship with the provider, whereas legacy space in ARIN's database is exactly like that. > > >> This provides sufficient time for the resources to go unused >> prior to reassignment and/or to be re-justified by the original >> registrant, or returned to the proper holder in the case of hijackings. > This could be solved with a much weaker requirement: "ARIN shall not > reallocate recovered address space while its status is under dispute > by a prior registrant." How can the prior registrant initiate a dispute in time if they weren't aware of a hijacking and subsequent immediate reclaimation? Matthew Kaufman From bill at herrin.us Fri May 13 11:48:47 2011 From: bill at herrin.us (William Herrin) Date: Fri, 13 May 2011 11:48:47 -0400 Subject: [arin-ppml] Just a reminder of some quick mathematics for IPv4 that shows the long term impossibility of it In-Reply-To: <4DCD50E9.6020302@ipinc.net> References: <4DCC41D8.1010305@ipinc.net> <4DCD50E9.6020302@ipinc.net> Message-ID: On Fri, May 13, 2011 at 11:40 AM, Ted Mittelstaedt wrote: > On 5/13/2011 6:30 AM, William Herrin wrote: >> The half billion or so who've joined the Internet behind NATs this >> past decade seem to think differently. Who am I to disagree with them? >> Who are you. > > You > cannot possibly believe the Internet can add all those additional > people in the same manner as they have added the first 2 billion. No more than we could have added the last 15 years of users with classful addressing. And no less. -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 13 11:52:13 2011 From: jcurran at arin.net (John Curran) Date: Fri, 13 May 2011 15:52:13 +0000 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate In-Reply-To: References: <7F5FC4554E42430FADDC0D376164DFA0@mike><0BB63D56-1605-4E1E-8F0B-B2083FDE4A96@delong.com><16AACD9632484C85BF6B855603CF07B4@mike><59EC8A7F22F2470 58ED74A896F0C6978@mike><907EE389FDC5448ABC46ADD06420B86D@video><4B99E603-7892- 433A-9FB9-DB9A08D98F39@delong.com><599AC4287E79403D939568C89EB40922@video><4DC BFB89.6010804@matthew.at><463771E5-094B-48CB-BAD7-C6D51088C26E@delong.com><8DDDEFF8-91B6-4C38-83C3-EDDEB44E8BE8@matthew.at><02540BF3-D17E-4069-BC98-ECC29053A4CA@matthew.at> <7834D82CC7C64E64820785568E598738@mike> Message-ID: On May 13, 2011, at 8:21 AM, Chris Engel wrote: > > Actually, I would argue that "manufactured" need would be functionally identical to "genuine" need from the point of anyone forced to make approval decisions based upon that, unless the organization attempting to game the system was incredibly un-artful in their attempt. How would someone charged with deciding to approve the "IP-Enabled virtual pet rock program" that was simply instituted to grab and hold IP addresses for a time until they were actually needed for a legitimate project or could be sold (at a profit) to someone who had a legitimate need for those addresses..... from a company that legitimately wanted to enter the "IP-Enabled virtual pet rock" business and were simply bad at business planning? On paper, they'd be identical....the only thing that would be different was the motivation of the organization acquiring the resources....and how could anyone discern that without being a mind-reader? Both receive approval for a small initial allocation (unless the one which was serious could show a history of subassignments from their existing IP-enabled "digital paperweight" program...) As soon as either reached 80% utilization, we'd be happy to approve a significantly larger allocation (and so on) Does this clarify how these two organizations would be handled, and how gaming the system works in the small but has diminishing returns? > Note that speculators always risk being left holding the bag when the bottom falls out of the market they are playing with. Risk is inherent in what they do...unfortunately it doesn't seem to curtail their activities very much in most scarcity markets. Agreed, although far fewer participate in situations where the risk is self-created due to operating contrary to the system. It's one thing to point out to investors that you misread the market, it is another to explain that you were doing something that was technically contrary to market rules and that resulted in the loss. > Functionally the only things I see a needs based requirement accomplishing in a transfer market is artificially inflating the cost of transfers, It definitely increases the net transaction cost. > increasing the cost for ARIN to administer transfers To be clear: it results in transfers having overhead similar to the assignment approvals which we are presently doing. > and creating a new job position among certain companies of "needs justification designer". That position or at least job task (IP address management) already exists in ISPs today (or at least those ISPs which are growing and need additional allocations on a routine basis) > I don't think it's going to accomplish what many proponents might hope it would very effectively. For clarity: there is a big difference between "effective" and "very effective"; do you mean that you don't think it will curtail routing growth and prevent speculation at all, or simply that it will provide less than ideal protection from such? > In a market where acquiring IP addresses is relatively trivial (i.e. unassigned space from ARIN), I can certainly see why there has to be some artificial barrier built into the system to prevent people from acquiring IP space for trivial reasons....with a scarcity market, the cost of acquisition through transfers itself should act as a barrier to that. Anyway, that's how I see it...for whatever it's worth. Good comments; hopefully this discussion will help folks in consideration of the large set of policy proposals before us. Thanks! /John John Curran President and CEO ARIN From george at dmu.edu Fri May 13 11:46:45 2011 From: george at dmu.edu (Davey, George) Date: Fri, 13 May 2011 10:46:45 -0500 Subject: [arin-ppml] ARIN-prop-150 Reclamation Hold In-Reply-To: <4DCD36FC.3000501@arin.net> References: <4DCD36FC.3000501@arin.net> Message-ID: I am opposed to the reclamation period only because it is too long. I propose 1 year unless during that year it is disputed then it would be extended in 6 month increments to a maximum of 3 years to account for a dispute process such as court litigation. Additionally, I feel in certain cases there should be constraints for immediate reuse such as a declaration or settlement signed by the verified current IP assignee. ? George Davey, B.S. MCSE Network Administrator 3200 Grand Avenue Des Moines, IA? 50312 DESK 515.271.1544 FAX 515.271.7063 CELL 515.221.2500 George.Davey at dmu.edu www.dmu.edu -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of ARIN Sent: Friday, May 13, 2011 8:50 AM To: arin-ppml at arin.net Subject: [arin-ppml] ARIN-prop-150 Reclamation Hold ARIN-prop-150 Reclamation Hold 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-150 Reclamation Hold Proposal Originator: Matthew Kaufman Proposal Version: 1 Date: 13 May 2011 Proposal type: new Policy term: permanent Policy statement: Add a new section to the NRPM: "All resources reclaimed by ARIN shall not be returned to the free pool or otherwise reassigned to any entity than the original registrant for a period of 36 months." Rationale: As the pressures on the system become greater with IPv4 runout, there will be more call for ARIN to reclaim address space. When addresses that are reclaimed are reused too soon, a variety of undesirable outcomes may result. This provides sufficient time for the resources to go unused prior to reassignment and/or to be re-justified by the original registrant, or returned to the proper holder in the case of hijackings. This policy could be restricted to IPv4 space, but it may be useful for AS numbers and has no major impact on IPv6 space (due to the large free pool), so it might as well apply to all. 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 tvest at eyeconomics.com Fri May 13 12:04:39 2011 From: tvest at eyeconomics.com (Tom Vest) Date: Fri, 13 May 2011 12:04:39 -0400 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate In-Reply-To: References: <7F5FC4554E42430FADDC0D376164DFA0@mike> <0BB63D56-1605-4E1E-8F0B-B2083FDE4A96@delong.com> <16AACD9632484C85BF6B855603CF07B4@mike> <4294678C-B653-4BB3-9D40-FD935EA00CF3@eyeconomics.com> Message-ID: <4A4A6144-C036-4DB8-A350-14E21D18E02A@eyeconomics.com> Hi Mike, Sorry I haven't had time to stay on top of this discussion -- hope you'll excuse my attempt to answer your last two messages addressed to me with this one reply... On May 12, 2011, at 9:41 AM, Mike Burns wrote: > Hi Tom, ditto on the detailed response! > > Yes I am a stickler for procedural fairness, probably that is why I want so few procedures. > No, I would not call myself a champion of transparency and public disclosure, though I value information in the market, so there is a tension there. I would definitely agree that there is tension. In fact, upon further reflection it looks like both of today's response(s) are completely silent on the question of the independent operational value of a public-facing whois interface, as distinguished from the other, uniqueness preservation-related value associated with IP number registries -- the latter of which I tend to think of as residing in the the non-public back-end of the registry. On May 12, 2011, at 1:00 PM, you followed up with this: > My whole goal is to increase accuracy in Whois, and I am not relying on any financial or price mechanism for that increase. > > I have not argued that pricing will increase registration, I have argued that pricing will ensure productive use. After puzzling over these statements for a while, it occurred to me that we may be using the same generic terms to describe things that actually have very little or nothing at all in common with each other, apart from that connection to common terms of reference. In order to clarify whether we are talking about the same thing (or at least partially intersecting things), it would be helpful if you would respond to the following two questions: What definition of "accuracy in Whois" do you have in mind in this context? Can you provide an example of the absolute minimum set of whois parameters and parameter values (e.g., specific whois contact details | degree of verifiability / fidelity of those details ) that would be consistent with your definition of "accuracy in Whois"? And why exactly do are we placing such a high value on "accuracy in Whois" anyway? From your point of view, what are the requirements|purposes|uses of whois that justify the considerable investments in time and effort that are required to maintain Whois data quality at this level? Though it might seem like a simple question, the range of possible answers is vast. Would your own criteria for whois "accuracy" and "purpose" be satisfied, for example, by a number resource registry that maintains 100% accurate contact records sufficient for the purpose of registry fee collection, but nothing more than that -- and only shares those few details with duly authorized LEAa and individuals who have been explicitly granted access by individual registrants themselves? Alternately, would you agree that the provision of open/public access to basic operationally relevant contact information on all registry clients is also an essential and indivisible part of the role of the number resource registry maintainer? Where would you come down between these two extremes? > I don't see that my single policy proposal to lift needs analyses for transfers of already allocated addresses exhibits little concern for procedural fairness or transparency. > On the contrary, it seeks to reconcile legacy and non-legacy status as a step towards procedural fairness, and it's underlying rationale is related deal transparency. > My lifting the needs requirement, deals which would have been transacted "in the dark" due to that requirement would have more incentive to be registered publicly. In my mind, needs-related eligibility criteria and association registry practices are closely connected to (1) the purposes of whois as well as (2) the definition of whois accuracy. They also help to (3) establish bounding conditions for registry and registrant obligations and requirements that IMO are beneficial to all parties. 1. I believe that the public-facing "whois" side of the registry service is absolutely integral to the function of the number registry. I believe this because the whois service (together with various other data resources, and a lot of effort) permits community members to engage in a limited form of "macro-prudential" oversight and coordination, without which it would be much harder to keep the Internet working. Whois is not sufficient by itself to support that "macro-prudential" capability, but the absence of a source of data like whois would be sufficient to make it impossible for anyone to know enough to meaningfully engage in such "big picture" activities. 2. This understanding of the purpose of whois entails a a definition of "data quality" that is near the maximalist (or "RIR-esque") rather than the minimalist (or "DNS registrar-esque) end of the spectrum. Quality is defined by the three dimensions of completeness (which for infrastructure operators would include real names and physical/geographical as well as electronic contact information) + timeliness + accuracy/fidelity. 3. As a matter of operation practice, Initial "needs assessments" play an important role in assuring that each new addition to the registry database meets the highest-applicable data quality standard. Subsequent assessments help to maintain the quality of registry data at relatively high levels over time, at least for one important segment of registry participants, i.e., growing networks. 4. The needs tests are also important because they establish a technical basis for reciprocal exchanges of confidential information and assurances within one narrowly defined domain. Basically, the needs rule makes it possible for the registry to provide as a kind of proxy ratings service for the entire community, but strictly limits the scope of their inquiries to questions about ownership or beneficial access to hardware and other inputs that are required to use IP addresses *as they were designed to be used.* No doubt every IP address seeker would prefer to just get their addresses on a no-questions-asked basis, but that's not a sustainable option -- e.g., as soon as that address seeker gets what they want, they join the community of address users who all have a common interest in preserving the remaining address resources as long as possible, so they themselves could get more in the future if necessary. So while total secrecy might be preferred, the best alternative that actually works is to disclose as little as possible, and only to a proxy agent like the registry that is bound to maintain confidentiality but also capable of credibly "signaling" to the broader community that it has a new member. Without something like a needs test to bracket these interactions, privacy claims of first-time address seekers might make it impossible for registries to provide this proxy assurance service, while the operational and privacy requirements of current address users might be at at perpetual risk if registry decided to unilaterally expand its disclosure or eligibility demands. 5. Finally, by linking access to IP number resources directly to possession of precisely the sort of costly assets and/or commitments that would be most at risk if the s/he operates in a reckless manner, the needs test also helps (on the margin) to cause or confirm that the incentives of the address user are very broadly consistent with the continued functioning of the Internet. In other words, the needs test provides some (weak but nontrivial) assurance that address users all have some "skin in the *Internet* game." That's what makes it possible to describe this otherwise fractious, aggressively competing, often mutually antagonistic bunch as a "community." It's also what makes the needs test rule different from and IMO much more effective than reliance the price mechanism, which can only assure that address buyers have "skin in some kind of game," with no constraint on the choice of game other than the address owner's expectation of profit. Of course they might coincidentally prefer the same game that actual network operators are engaged in, but there are lots of other possibilities -- including many that would be antithetical to the purposes for which IP addresses were created (e.g., the artificial scarcity game, the competitive exclusion game, etc.). [Note: For those who haven't already made the leap, the reasons outlined above also suggest that the needs test should continue to apply for IPv6 requests. While we may assume without consequence that the needs-based eligibility began as nothing more than a super-simple rule for managing scarcity (I actually reject that interpretation, but don't have time to debate about history), I believe that its utility to that end represents just a small part of how it has contributed to the overall security and stability of the Internet over the last two decades. I guess we'll soon find out enough...] > So I don't get the inconsistency with previous observations which walked us through the forest. > > Oh, I'm sorry, in rereading the paragraph I can see that you were probably responding to prior posts about private registries. > So you feel that my support of the idea of private registries conflicts with my desire to eliminate needs tests for transfers? > I find they are both consistent examples of attempts to remove restrictions on the operation of free markets. > As far as the DNS private market goes, I don't see the problem with it. > I haven't personally had or seen issues with non-uniqueness of domain names. > There are more tools to find domain names, there are cottage industries related to the resale of domain names, there are more tlds, there are lifetime registrations, there are cheaper domains. > To me, DNS seems to work, and I have been running production DNS servers since 1996. > Are there specific problems with the DNS private market that you feel would be absent from a market with a single "public" registrar? > I think that would be an instructive conversation to have on the matter of private registries, which has always been a sideline issue to me. Hopefully my remarks above will make clear why I think that a DNS-style registry model would be not only inappropriate for IP numbers, but would quite likely represent a grave threat the continued existence of the Internet as an autonomous, effectively global-scope system under civilian control. The fact that DNS registrars currently enjoy the de facto luxury to compete on features like level of obfuscation of whois data and/or degree of indifference to blatantly deceptive registrant contact information is not an a viable model for IP registries -- in fact, it is an artifact of the existence of an alternative source of critical coordination-enabling information that is both closer and provides a (often vastly) more complete, accurate, and useful view of operational "ground truth," -- a.k.a. the present-day whois services provided by the RIRs. If ever a day comes when the registration data quality standards for both domain and IP registries converge down to the current norm for DNS registries, I predict that none of us on this list would have to worry about the consequences for long (and also that none of us would have much say about registry policy or operations thereafter). > I do think that registry services will see some extra pressure, post-exhaust, and maintaining a registry of uniqueness and accessibility will be vital. Hence you haven't seen me arguing to hide information from whois, rather to have whois reflect the real users of the address space, if only to provide accurate points of contact for abuse notifications. I believe that my proposed changes to the ARIN policy would have the effect of cleaning up some old inaccurate whois data (the provision to hold addresses without fear of revokation) and making new registrations more likely through reducing transaction costs in the form of needs analyses. > > I also hold that it would increase the supply in the transfer markets, creating a safe harbor for those who wish to sell addresses but who fear a utilization review. I believe this will bring down price, benefitting the community both through cheaper access and through the movement of address from under- or dis-use into productive use. > > But I don't hold that creating private registries will increase registration rates. > I hold that eliminating needs requirements will increase registration rates. Increasing the coverage of registry data by radically shrinking both the scope of its usefulness and the share of community members who can use it for any purpose is not a tradeoff that makes sense to me. IMO it should be considered harmful. Regards, TV > Regards, > Mike > > > > > > > ----- Original Message ----- From: "Tom Vest" > To: "Mike Burns" > Cc: "McTim" ; "Owen DeLong" ; > Sent: Thursday, May 12, 2011 4:58 AM > Subject: Re: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate > > > Hi Mike, > > Thanks for the very detailed response. > Given the level of scrutiny that you've obviously devoted to this particular transfer transaction, and your repeated emphasis on what could be interpreted as gaps and inconsistencies in the accumulated public disclosures about this matter, I am tempted to assume that you are either a real stickler for legalistic/rule-based/procedural fairness, or a determined champion of transparency and public disclosure -- or perhaps both (?). > > And yet your policy proposals seem to exhibit very little of those concerns about procedural fairness and transparency -- but quite a bit of the same sort of fairy tale qualities that you disparage in the official account of the Nortel/Microsoft transfer justification. To paraphrase George Berkeley, if a tree falls in the woods but no one's around to hear it (and/or to witness whether it harms any other trees on the way down), do we still believe that it makes a sound? Or would be better to infer from the silence that trees in the forest have become immune to the laws of gravity, or perhaps that falling trees now spontaneously sublimate into gas as soon as they start tilting, thus making both sound and harm impossible? If we put enough distance between ourselves and the forest so that no sound can ever be heard, does that grant us the license to be indifferent as to which of these is (more) true -- or to take any position that appeals to us, regardless of its (in)consistency with previous observations? > The same questions come up in the real world. For example, what does the generally low quality of domain-related whois data that is commonly observed in the competitive market for DNS registrar services say about the notion that the price mechanism alone is sufficient to sustain whois meaningful registry/whois participation? [1]. What can be inferred from a situation in which a 100% voluntary (and until very recently, 100% free) registry dedicated to much pricier assets still only attracts participation at levels that would be fatal to an IP number resource registry? HM Land Registry in the UK, for example, just passed the 70% national participation milestone (though participation in some rural counties remains below 50% ) after only 150+ years of membership promotion efforts) [2]. What, if anything, do you think that we can take away from the experiences of other private registries like these? Why should we assume that the private decision making calculus of future transfer market participants will favor registration/disclosure over nondisclosure at rates that are 2-3x higher than observed participation levels in other private registries? > > For the record, I agree with you that the next few years are certain to test the current registry/whois system more severely than it has ever been tested in the past. I also believe that that system will continue to represent the best and only means at "our" (individual and/or collective) disposal, both for exercising "macro-prudential" judgment in private/commercial matters, and for serving as informed co-participants in "macro-prudential" coordination and oversight activities -- a.k.a. "industry self-governance." These functions are doubly critical in industries like the ours (which in this sense would include banking/finance) that are highly dependent on the consistency (or at least predictability) of transitive commercial interactions. As long as the "typical" inter-domain packet exchange must traverse 3~4 or more separate business entities in order to be completed, there is no reason to believe that "counterparty scrutiny" (or peer-mediated / "market discipline") alone will be sufficient to keep this industry afloat -- no matter how we reinforce those bilateral levers with (ironclad contracts | secure protocols | interpersonal relationships | faith in the rationality of markets). > > The banking industry learned that lesson the hard way not so long ago -- or at least I'd like to think that parts of it did, even if there hasn't been any obvious change in the pace or direction of financial activity migration away from the "light" of reciprocal disclosure and limited transparency, and into the "shadows" where nobody knows nothing. Regardless, I think that *we* should take advantage of the opportunity to learn from this episode, even if bankers themselves don't. Considering that Internet industry members still enjoy the kind of operational autonomy and freedom of private action that US banks once had -- until their own self-governance mechanisms stopped working (and the Fed took over, c. 1907), the stakes on the line during the next few years really couldn't be higher... > > TV, speaking form myself alone > > On May 11, 2011, at 5:12 PM, Mike Burns wrote: > >> Hi Tom and welcome to this particular discussion, >> >> The current legal realities I referenced are the implications of the public information associated with the MS/Nortel deal. >> >> In this forum I have argued that the public bankruptcy documents reveal that the addresses transferred from Nortel to MS were not originally allocated to Nortel, but represented some accumulation of addresses allocated to Nortel's "predecessors in interest" who were Nortel acquisitions from the 1990s. >> >> I argued that MS and Nortel negotiated a deal to sell all the addresses in that accretion, although the public documents reveal that Microsoft was able to bid on an amount smaller than the entire lot. >> >> After the original asset sale agreement between MS and Nortel was negotiated, ARIN became aware of the transaction, and after some negotiations with the parties at interest, and some changes to the MS/Nortel asset agreement, made a press release claiming that the transfer could proceed under existing ARIN policy. >> >> ARIN later revealed the policy utilized to be NRPM 8.3, which requires four things which may or may not have actually happened: >> >> 1. Addresses are supposed to be issued back to ARIN and then reissued to the recipient, Microsoft, and the bankruptcy docs did not reveal this happened in any way. >> 2. Address are supposed to be transferred as a single aggregate, but if the addresses were an assortment of netblocks from prior Nortel acquisitions, this could not have happened. >> 3. Recipients were required to sign an RSA, MS signed a modified LRSA. >> 4. Finally, the requirement at issue here, a needs analysis had to be completed by ARIN, which magically showed that MS qualified for exactly the amount already bid for and negotiated the sale of. >> >> If they had needed fewer addresses, they could have bid for less than the full pool. >> If they needed more addresses, they should have received an additional ARIN allocation. >> Paraphrasing Goldilocks, the random allocation of addresses to long-ago Nortel acquisitions was "just right." >> >> My reading of the bankruptcy documents leads me to the conclusion that the bankruptcy judge found that Nortel had the exclusive right to transfer the addresses, even though the judge had not been informed of any ex-post-facto NRPM 8.2 transfer from the original registrants to Nortel. To me, this means he was convinced that ARIN had no rights over transferring the addresses, although ARIN has rights over reflecting that transfer in Whois. This is consistent with a declaration by the head of ARIN at the time in the Kremen case where he stated that ARIN has no authority over legacy addresses. >> >> My argument is that the apparent success of RIR stewardship (although I claim many of the allocated and unrouted addresses represent failures here) over the last two decades is laudable and represents an obvious requirement in the stewardship of free pool resources, but is unnecessary in a post-exhaust age where the price of addresses will ensure efficient use. >> >> I also argue that in the post-exhaust age, conflicts over claims to address rights will likely increase, putting more pressure on Whois to accurately represent reality. >> >> Regards, >> Mike Burns >> >> >> >> >> >> >> ----- Original Message ----- From: "Tom Vest" >> To: "Mike Burns" >> Cc: "McTim" ; "Owen DeLong" ; >> Sent: Wednesday, May 11, 2011 4:34 PM >> Subject: Re: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate >> >> >> Hi Mike, >> >> While it may or may not be true that your perspective on this question is consonant with that of "the APNIC community," elements within said community have been championing the same broad policy changes that you're advocating here now since the early 1990s. Thus it would seem that the views that you associate yourself with here couldn't possible have anything to do with "current legal realities" -- unless perhaps by "current" you mean something like "twentieth century." >> >> Given that historical fact -- and the apparent success of the RIR stewardship mission over the intervening two decades of possible nonconformity with legal reality -- on what basis could you legitimately claim that abandoning time-tested registry practices that have been integral to maintaining whois accuracy to date represents the best, or perhaps the only way to maintain whois accuracy in the future? >> >> Alternately, if you actually had in mind some other, more recent legal developments -- which by definition could not have any causal relation to policy arguments that predated them by 10-15 years -- a clarification of exactly what those changes in legal reality are would be much appreciated. >> >> Thanks, >> >> TV >> >> >> On May 11, 2011, at 3:13 PM, Mike Burns wrote: >> >>> Hi Owen and McTim, >>> >>> I, along with the APNIC community, could make the claim that you are abandoning the stewardship role in maintaining Whois accuracy, and sacrificing that stewardship role on the altar of an ARIN needs policy developed for the purposes of free pool allocations that does not comply with current legal realities. >>> >>> But charges of abandoning stewardship are inflammatory, and I hope we can keep to actual discussions of the implications of my proposal without casting aspersions. >>> >>> Let's agree that we all seek the highest standards of stewardship, but disagree on how those standards should be applied. >>> >>> I think I could characterize your opposition better by saying that you believe the danger of hoarding and speculation outweigh the risk to whois accuracy. >>> Would that be an accurate statement, if not your exclusive objection to the proposal? >>> >>> Regards, >>> Mike >>> >>> >>> >>> ----- Original Message ----- From: "McTim" >>> To: "Owen DeLong" >>> Cc: "Mike Burns" ; >>> Sent: Wednesday, May 11, 2011 2:53 PM >>> Subject: Re: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate >>> >>> >>> On Wed, May 11, 2011 at 9:09 PM, Owen DeLong wrote: >>>> I oppose the policy as written. >>> >>> +1 >>> >>> >>>> Abandoning our stewardship role for the sake of making it more likely >>>> people will register their misappropriation of community resources is >>>> like legalizing bank robbery in the hopes that the thieves will pay >>>> income tax on their ill gotten gains. >>> >>> ;-) >>> >>> -- >>> Cheers, >>> >>> McTim >>> "A name indicates what we seek. An address indicates where it is. A >>> route indicates how we get there." Jon Postel >>> _______________________________________________ >>> 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 mike at nationwideinc.com Fri May 13 12:07:48 2011 From: mike at nationwideinc.com (Mike Burns) Date: Fri, 13 May 2011 12:07:48 -0400 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate References: <7F5FC4554E42430FADDC0D376164DFA0@mike><0BB63D56-1605-4E1E-8F0B-B2083FDE4A96@delong.com><16AACD9632484C85BF6B855603CF07B4@mike><59EC8A7F22F247058ED74A896F0C6978@mike><907EE389FDC5448ABC46ADD06420B86D@video><4B99E603-7892-433A-9FB9-DB9A08D98F39@delong.com><599AC4287E79403D939568C89EB40922@video> <4DCC79BE.5070901@umn.edu> Message-ID: <28D7CA1C57BE4FFDB6F4AFC2E0D43EA7@mike> > On 5/11/11 22:09 CDT, Mike Burns wrote: > ... >> I'm sure there are many more that I cannot think of. I agree with you >> that most buyers will have need, and I agree with you that most buyers >> will see the value of maintaining a valid ARIN whois record pointing to >> their authority. > > Unfortunately, most rules are meant to enforce something on those who are > not necessarily acting reasonably. Above you save "most buyers will see > value" what about those that don't. Or, what about those, that see a > value in ensuring that their competitors can't get addresses and that the > whole system doesn't shift to IPv6. I don't want to see something like > that happen and I'm not entirely sure it can't. > >> But the policy in APNIC was changed to remove needs requirements for >> transfers for the same reasons I am requesting its removal here. > > There are other policy differences between APNIC and ARIN then just needs > or non-needs based transfers that are relevant to the changes due to IPv4 > run-out. There is also a fundamental difference in the way APNIC and ARIN > plan to operate the pool of addresses they have left, APNIC is reserving > their whole /8 and allowing each organization a single /22. The ARIN > community has reserved /10 of IPv4 for IPv6 purposes, but is allowing need > to driver the run-out of the rest of the pool, limiting to 3 month need > for fairness with new entrants and to reduce the competitive disparity > created by IPv4 run-out. Additionally ARIN added officer attestations, to > ensure organizational accountability for requests, I believe this will > strongly suppress the tendency for ARIN to have a run-out curve like APNIC > had during the first 4 months of 2011. Yes, there are other policy differences and the runout curve would be different, although they both lead to zero in the free pool, whatever the curve shape. > > So there are a number of differences in how ARIN and APNIC are approaching > the fundamental changes that are occurring, and it would be a mistake to > evaluate only one of these issues out of context with the others. I'm not > trying to say APNIC did or is doing something wrong or ARIN did or is > doing it right, but there is more to the picture than just needs or > non-needs based transfers. If ARIN is going to change to a non-needs > based transfer regime lime APNIC we may also need to change many more > parts of policy as a consequence. What other parts of the policy do you think require change should my proposal be accepted? I don't see them, but if they are there we should address them directly. > > The point here is that ARIN's policies are consistent, if you have need > you can have addresses, be that from the free pool or from transfers. Much > of the ARIN community didn't like to idea of addresses sitting at ARIN, if > there was need for them. > But it's inconsistent in that if you have need, you can have addresses for free from the pool. You can't have addresses for free from the transfer market. What is the point of the consistency between transfer and free pool allocation requirements ? > APNIC is also consistent, in that once they get down to the last /8, it > doesn't matter if you need addresses you only get a /22 once from the last > /8 pool, and you can transfer without need. > > I believe it would be unwise for ARIN community to change only one part of > its policies to emulate APNIC. I am not changing policy to emulate APNIC, I use APNIC to shield from the emotionally laden charges about shirking stewardship which don't add to the debate. > >> My policy proposal also has the benefit of incentivizing legacy >> resources to come under RSA, and it serves to even the playing field >> between the disparate rights of legacy versus non-legacy holders. >> >> And my underlying point is the obvious one, that the very act of paying >> for address space is a very good indication of need, or at least >> perceived need on the part of the buyer. > > I think it is a good indication of perceived value in all cases, it is a > indication of need in some cases, but not in all cases. If you want to > corner the market on IPv4 there maybe sufficient value to someone to do > so, but that is not a valid need. And, this is the case where your > analysis breaks down. If you reread what I have said, you will not find that I ever made the claim that every transaction in a non-needs based system will involve a buyer with need as ARIN defines it. I put this objection of yours in the category of fear of the free market. Perhaps it would be valuable to quote some successful examples of market cornering in a free market, and for each I will provide 5 examples of failures? I have expressed that to corner this market would involve serious coin over long periods of time as new suppliers bubble up to the surface as they renumber or whatnot. Since the market cornerer will have no information about the potential limits to these new suppliers, and since there is IPv6, the cornerer will be taking an extraordinary risk of losing. Do we have any evidence of this in the APNIC region, where transfers can happen without need? Wouldn't a market cornerer already be working through entities like tradeipv4.com to start sucking up all the supply? > > That said I'm not certain that current criteria for evaluating need will > even be valid once there is no longer a free pool. The basic idea that > you get a years worth of need based on your past years consumption of > addresses assumes the existence of a free pool. Once we get more than a > year into a market-like transfer system, what you used last year has more > to do with how much money you were willing to spend that what your actual > need was. And if the price was high the previous year and if you simply > evaluate your need by how much addressing you used last year when the > price was high that isn't necessarily a true representation of your actual > need. > Yes, the price will reflect the market's beliefs about things like CGN, IPv6, growth rates, address conservation techniques, and lots of other things we can't envision. And needs criteria based on available free pool addresses will appear increasingly anachronistic. > So I am equally skeptical of maintaining the current needs based system as > is, as I am of completely abandoning the concept of a needs basis. Right > now I'm thinking allowing transfers up to some size limit over some period > of time without justifying need more than putting up the cash to do it, on > the premise that within some safety limits it might be a good idea to let > the market work things out. However, if you want to transfer more than > those limits you can, but you must justify your need beyond those limits. > Either based on your previous years usage or based on the fact that you > have put previously transferred addresses into documented use. > > Just throwing some numbers out, I'm thinking up to the equilivant of a /12 > (or a little more than 1 million IPv4 addresses) of transfers received > within 12 months per organization without documenting need. There needs to > be a mechanism that prevents gaming by creating multiple organizations by > the same real organization, maybe this is another place for officer > attestations. > > For most organizations a /12 is more or less unlimited, but that is > probably not enough to corner the market of IPv4 addresses and anyone who > really needs more than a /12 can probably justify it without much more > hassle then now. If they really need more than a /12 they are probably > quite adept at working with ARIN already. I think this would give the > invisible hand enough room to do its magic, without allowing someone to > corner the IPv4 market and destroy the Internet as we know it. Depending > how the actually market progresses, someone could maybe still corner the > IPv4 address market, but if they can do that with a /12 then it will > really be the time for everyone to move to IPv6. > These sound like reasonable matters for further discussion, let's call them protections against cornering? > What I mean by "destroy the Internet as we know it", is anyone big enough, > or that anyone thinks is big enough, to stall the transition of the > Internet to IPv6, getting enough IPv4 addresses to attempt to do so. I'm > not sure anyone is big enough, but I'm just not sure no one is. > > In my view this doesn't abandon needs basis, it significantly changes it > based on new the realities we are facing. We are using the market to > determine need up to a cretin extent, and beyond that requiring documented > need. > Let me consider what you say, there seems to be a great concern over speculators and market-cornering which I think to be largely unfounded in an area as fraught with risk due to the potential for IPv6 to devalue IPv4 addresses to zero worth, the difficulties in dealing with many thousands of suppliers, the decentralization of control in the hands of network operators, and fears of the ITU, among just some issues. Regards, Mike From jcurran at arin.net Fri May 13 13:03:34 2011 From: jcurran at arin.net (John Curran) Date: Fri, 13 May 2011 17:03:34 +0000 Subject: [arin-ppml] ARIN-prop-150 Reclamation Hold In-Reply-To: <4DCD4FBD.7090901@matthew.at> References: <4DCD36FC.3000501@arin.net> <4DCD4FBD.7090901@matthew.at> Message-ID: <13AA8AAE-A8C7-4C44-9581-D0CC99370AAC@arin.net> On May 13, 2011, at 8:35 AM, Matthew Kaufman wrote: > On 5/13/2011 7:48 AM, Jeffrey Lyon wrote: >> >>> I am opposed to this. 36 months is far too long IMO for a "quarantine" > > Right now the period is "none, or whatever staff thinks is good". What time period would you suggest? (Once we have consensus around the time, I'll submit a revision to the proposal) Not correct - It is presently set at six months (since the last community consultation - ) and there is internal discussion of putting out a consultation to lower it to 3 months. It would be good to get input as to whether different periods are desirable for returned (voluntarily by registrant), revoked (for non-payment) and reclaimed (due to fraud, misappropriation, or business dissolution) Thanks! /John John Curran President and CEO ARIN From mike at nationwideinc.com Fri May 13 13:07:44 2011 From: mike at nationwideinc.com (Mike Burns) Date: Fri, 13 May 2011 13:07:44 -0400 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate References: <7F5FC4554E42430FADDC0D376164DFA0@mike> <0BB63D56-1605-4E1E-8F0B-B2083FDE4A96@delong.com> <16AACD9632484C85BF6B855603CF07B4@mike> <4294678C-B653-4BB3-9D40-FD935EA00CF3@eyeconomics.com> <4A4A6144-C036-4DB8-A350-14E21D18E02A@eyeconomics.com> Message-ID: <85BA8F9D1CA040C7836CD9049CBD5F26@mike> Hi Tom, >What definition of "accuracy in Whois" do you have in mind in this context? >Can you provide an example of the absolute minimum set of whois parameters >and parameter values (e.g., specific whois contact details | >degree of >verifiability / fidelity of those details ) that would be consistent with >your definition of "accuracy in Whois"? Whois has an underlying justification in the requirement for uniqueness of registration for each allocated netblock. I think Whois should list the current owner of the routing rights to the netblock and have valid contact information. If it had those things, I would consider it to be accurate. >And why exactly do are we placing such a high value on "accuracy in Whois" >anyway? From your point of view, what are the requirements|purposes|uses of >whois that justify the considerable investments in time and >effort that >are required to maintain Whois data quality at this level? It provides an element of routing authority that is used by network operators to decide whether their customer had the authority to route these addresses. It can also be used for abuse notification when the only information on the abuser is his ip address. >Though it might seem like a simple question, the range of possible answers >is vast. Would your own criteria for whois "accuracy" and "purpose" be >satisfied, for example, by a number resource registry that maintains >100% >accurate contact records sufficient for the purpose of registry fee >collection, but nothing more than that -- and only shares those few details >with duly authorized LEAa and individuals who have been explicitly >granted >access by individual registrants themselves? No, the registry or registries would also have to ensure uniqueness, not just accurate records for fee collection. >Alternately, would you agree that the provision of open/public access to >basic operationally relevant contact information on all registry clients is >also an essential and indivisible part of the role of the number resource >registry maintainer? Where would you come down between these two extremes? On the side of uniqueness, which is a basic operational requirement of publicy routed IPv4 addresses, and public accessibility for the purposes of the network operators and abuse victims. > I don't see that my single policy proposal to lift needs analyses for > transfers of already allocated addresses exhibits little concern for > procedural fairness or transparency. > On the contrary, it seeks to reconcile legacy and non-legacy status as a > step towards procedural fairness, and it's underlying rationale is related > deal transparency. > My lifting the needs requirement, deals which would have been transacted > "in the dark" due to that requirement would have more incentive to be > registered publicly. >In my mind, needs-related eligibility criteria and association registry >practices are closely connected to (1) the purposes of whois as well as (2) >the definition of whois accuracy. They also help to (3) establish bounding > >conditions for registry and registrant obligations and requirements that >IMO are beneficial to all parties. >1. I believe that the public-facing "whois" side of the registry service is >absolutely integral to the function of the number registry. I believe this >because the whois service (together with various other data resources, and > >a lot of effort) permits community members to engage in a limited form of >"macro-prudential" oversight and coordination, without which it would be >much harder to keep the Internet working. Whois is not sufficient by > >itself to support that "macro-prudential" capability, but the absence of a >source of data like whois would be sufficient to make it impossible for >anyone to know enough to meaningfully engage in such "big picture" > >activities. OK, no problems there. >2. This understanding of the purpose of whois entails a a definition of >"data quality" that is near the maximalist (or "RIR-esque") rather than the >minimalist (or "DNS registrar-esque) end of the spectrum. Quality is > >defined by the three dimensions of completeness (which for infrastructure >operators would include real names and physical/geographical as well as >electronic contact information) + timeliness + accuracy/fidelity. OK, no problems there, although I resist comparing DNS registrar lapses to Whois lapses which I argue are caused by existing policy, instead of failure to apply policy in the DNS case. >3. As a matter of operation practice, Initial "needs assessments" play an >important role in assuring that each new addition to the registry database >meets the highest-applicable data quality standard. Subsequent >assessments >help to maintain the quality of registry data at relatively high levels >over time, at least for one important segment of registry participants, >i.e., growing networks. You get no argument from me on the needs assessments for free pool allocations, but I don't see the connection to registry effects for transfer recipients, which is the issue here. >4. The needs tests are also important because they establish a technical >basis for reciprocal exchanges of confidential information and assurances >within one narrowly defined domain. Basically, the needs rule makes it > >possible for the registry to provide as a kind of proxy ratings service >for the entire community, but strictly limits the scope of their inquiries >to questions about ownership or beneficial access to hardware and other >i>nputs that are required to use IP addresses *as they were designed to be >used.* No doubt every IP address seeker would prefer to just get their >addresses on a no-questions-asked basis, but that's not a sustainable > >option -- e.g., as soon as that address seeker gets what they want, they >join the community of address users who all have a common interest in >preserving the remaining address resources as long as possible, so they > >themselves could get more in the future if necessary. So while total >secrecy might be preferred, the best alternative that actually works is to >disclose as little as possible, and only to a proxy agent like the registry >that >is bound to maintain confidentiality but also capable of credibly >"signaling" to the broader community that it has a new member. Without >something like a needs test to bracket these interactions, privacy claims >of first->time address seekers might make it impossible for registries to >provide this proxy assurance service, while the operational and privacy >requirements of current address users might be at at perpetual risk if >registry >decided to unilaterally expand its disclosure or eligibility >demands. Tom, I have no truck with the method of allocation from the free pool. >5. Finally, by linking access to IP number resources directly to possession >of precisely the sort of costly assets and/or commitments that would be >most at risk if the s/he operates in a reckless manner, the needs test > >also helps (on the margin) to cause or confirm that the incentives of the >address user are very broadly consistent with the continued functioning of >the Internet. My argument is the price of the "costly assets" will provide the incentive to use the addresses in a way that continues the function of the Internet, and not just on the margins. >In other words, the needs test provides some (weak but nontrivial) >assurance that address users all have some "skin in the *Internet* game." >That's what makes it possible to describe this otherwise fractious, > >aggressively competing, often mutually antagonistic bunch as a >"community." It's also what makes the needs test rule different from and >IMO much more effective than reliance the price mechanism, which can only > >assure that address buyers have "skin in some kind of game," with no >constraint on the choice of game other than the address owner's expectation >of profit. Of course they might coincidentally prefer the same game >that >actual network operators are engaged in, but there are lots of other >possibilities -- including many that would be antithetical to the purposes >for which IP addresses were created (e.g., the artificial scarcity game, > >the competitive exclusion game, etc.). Everybody who uses the Internet will have skin in the game. The price of address space will be included in their price for access, included in the price they pay for items on Amazon, included in every transaction that utilizes the Internet. Users will have their say by voting directly with their dollars through each transaction. I am arguing that maintaining needs for transfers will drive transactions off the books, to the detriment of Whois and all who utilize that information. Free markets have history of bringing together competing and mutually antagonistic bunches of people and provide the framework for their productive interaction. The Silk Road lasted for >[Note: For those who haven't already made the leap, the reasons outlined >above also suggest that the needs test should continue to apply for IPv6 >requests. While we may assume without consequence that the >needs-based >eligibility began as nothing more than a super-simple rule for managing >scarcity (I actually reject that interpretation, but don't have time to >debate about history), I believe that its utility to that end >represents >just a small part of how it has contributed to the overall security and >stability of the Internet over the last two decades. I guess we'll soon >find out enough...] I have argued many times that needs test is a proper constraint on the distribution of free pool addresses. > So I don't get the inconsistency with previous observations which walked > us through the forest. > > Oh, I'm sorry, in rereading the paragraph I can see that you were probably > responding to prior posts about private registries. > So you feel that my support of the idea of private registries conflicts > with my desire to eliminate needs tests for transfers? > I find they are both consistent examples of attempts to remove > restrictions on the operation of free markets. > As far as the DNS private market goes, I don't see the problem with it. > I haven't personally had or seen issues with non-uniqueness of domain > names. > There are more tools to find domain names, there are cottage industries > related to the resale of domain names, there are more tlds, there are > lifetime registrations, there are cheaper domains. > To me, DNS seems to work, and I have been running production DNS servers > since 1996. > Are there specific problems with the DNS private market that you feel > would be absent from a market with a single "public" registrar? > I think that would be an instructive conversation to have on the matter of > private registries, which has always been a sideline issue to me. >Hopefully my remarks above will make clear why I think that a DNS-style >registry model would be not only inappropriate for IP numbers, but would >quite likely represent a grave threat the continued existence of the > >Internet as an autonomous, effectively global-scope system under civilian >control. The fact that DNS registrars currently enjoy the de facto luxury >to compete on features like level of obfuscation of whois data and/or > >degree of indifference to blatantly deceptive registrant contact >information is not an a viable model for IP registries -- in fact, it is an >artifact of the existence of an alternative source of critical >coordination-enabling >information that is both closer and provides a >(often vastly) more complete, accurate, and useful view of operational >"ground truth," -- a.k.a. the present-day whois services provided by the >RIRs. >If ever a day comes when the registration data quality standards for both >domain and IP registries converge down to the current norm for DNS >registries, I predict that none of us on this list would have to worry > >about the consequences for long (and also that none of us would have much >say about registry policy or operations thereafter). I have not proposed anything like a DNS-style registry with this proposal, and I think the discussion of my proposal goes off the rails here. Again, I think you are conflating the concept of private registries with this proposal to lift needs requirements for transfers. My argument with the DNS analogy is that DNS registrars are answerable to ICANN to maintain accurate Whois. The impact of needs analysis on the DNS market is not clear, this is an apples-to-oranges comparison that fails to inform. I, personally, have the impression that DNS works, but that is a complete non-sequitur to this discussion. But we agree that decay inWhois accuracy imperils the operation of the Internet? >Increasing the coverage of registry data by radically shrinking both the >scope of its usefulness and the share of community members who can use it >for any purpose is not a tradeoff that makes sense to me. IMO it >should be >considered harmful. >Regards, >TV How does removing needs requirements for transfers radically shrink the scope of the usefulness of registry data? To me that is an unsupported leap. How does removing needs requirements for transfers radically shrink the share of community members who can use registry data? Can you make the logical connection here without diversions into DNS private registries? Or make the clear case where you feel there is something equivalent to needs-requirements in the DNS market that we can investigate to see how it affects registry accuracy? Regards, Mike From owen at delong.com Fri May 13 13:15:01 2011 From: owen at delong.com (Owen DeLong) Date: Fri, 13 May 2011 10:15:01 -0700 Subject: [arin-ppml] Just a reminder of some quick mathematics for IPv4 that shows the long term impossibility of it In-Reply-To: References: <4DCC41D8.1010305@ipinc.net> Message-ID: On May 13, 2011, at 6:30 AM, William Herrin wrote: > On Thu, May 12, 2011 at 7:44 PM, Owen DeLong wrote: >> On May 12, 2011, at 3:46 PM, William Herrin wrote: >>> On Thu, May 12, 2011 at 4:23 PM, Ted Mittelstaedt wrote: >>>> So how exactly do we get the other 4.5 billion people on the Internet >>>> using IPv4? >>> >>> Survey says: NAT. >> >> That does not put the other 4.5 billion people on the internet. > > The half billion or so who've joined the Internet behind NATs this > past decade seem to think differently. Who am I to disagree with them? > Who are you. > Does a rat who has lived its entire life in a cage realize it is in a cage? Just because they haven't actually experienced the internet and have been fooled into believing what they have is access to the internet does not make the claim any more accurate. As I said, they don't have internet access. They have a controlled and limited subset of the features that define internet access. The internet is a peer-to-peer network where each system has a globally unique potentially reachable address and can operate as both client and server. Machines behind a NAT have access to only a subset of those defining features. Owen From owen at delong.com Fri May 13 13:16:30 2011 From: owen at delong.com (Owen DeLong) Date: Fri, 13 May 2011 10:16:30 -0700 Subject: [arin-ppml] ARIN-prop-150 Reclamation Hold In-Reply-To: <4DCD36FC.3000501@arin.net> References: <4DCD36FC.3000501@arin.net> Message-ID: I oppose this proposal as written. ARIN already has reasonable safeguards in place and a reasonable hold-down period for reclaimed resources. This policy would do nothing to improve stewardship of the address space and could leave ARIN holding resources that could be allocated or assigned to organizations with immediate need for no reason other than to satisfy the ridiculous 3-year hold-down in this proposed policy. Owen On May 13, 2011, at 6:49 AM, ARIN wrote: > ARIN-prop-150 Reclamation Hold > > 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-150 Reclamation Hold > > Proposal Originator: Matthew Kaufman > > Proposal Version: 1 > > Date: 13 May 2011 > > Proposal type: new > > Policy term: permanent > > Policy statement: > > Add a new section to the NRPM: > "All resources reclaimed by ARIN shall not be returned to the free pool > or otherwise reassigned to any entity than the original registrant for a > period of 36 months." > > Rationale: > As the pressures on the system become greater with IPv4 runout, there > will be more call for ARIN to reclaim address space. When addresses that > are reclaimed are reused too soon, a variety of undesirable outcomes may > result. This provides sufficient time for the resources to go unused > prior to reassignment and/or to be re-justified by the original > registrant, or returned to the proper holder in the case of hijackings. > This policy could be restricted to IPv4 space, but it may be useful for > AS numbers and has no major impact on IPv6 space (due to the large free > pool), so it might as well apply to all. > > 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 cengel at conxeo.com Fri May 13 13:23:47 2011 From: cengel at conxeo.com (Chris Engel) Date: Fri, 13 May 2011 13:23:47 -0400 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate In-Reply-To: References: <7F5FC4554E42430FADDC0D376164DFA0@mike><0BB63D56-1605-4E1E-8F0B-B2083FDE4A96@delong.com><16AACD9632484C85BF6B855603CF07B4@mike><59EC8A7F22F2470 58ED74A896F0C6978@mike><907EE389FDC5448ABC46ADD06420B86D@video><4B99E603-7892- 433A-9FB9-DB9A08D98F39@delong.com><599AC4287E79403D939568C89EB40922@video><4DC BFB89.6010804@matthew.at><463771E5-094B-48CB-BAD7-C6D51088C26E@delong.com><8DDDEFF8-91B6-4C38-83C3-EDDEB44E8BE8@matthew.at><02540BF3-D17E-4069-BC98-ECC29053A4CA@matthew.at> <7834D82CC7C64E64820785568E598738@mike> Message-ID: John, Thanks for your explanation. The approaching run-out of IPv4 certainly brings alot of complications to the table for ARIN and I don't envy those charged with administrative or decision making duties in the coming months. > > On May 13, 2011, at 8:21 AM, Chris Engel wrote: > > > > Actually, I would argue that "manufactured" need would be functionally > identical to "genuine" need from the point of anyone forced to make > approval decisions based upon that, unless the organization attempting to > game the system was incredibly un-artful in their attempt. How would > someone charged with deciding to approve the "IP-Enabled virtual pet rock > program" that was simply instituted to grab and hold IP addresses for a time > until they were actually needed for a legitimate project or could be sold (at a > profit) to someone who had a legitimate need for those addresses..... from a > company that legitimately wanted to enter the "IP-Enabled virtual pet rock" > business and were simply bad at business planning? On paper, they'd be > identical....the only thing that would be different was the motivation of the > organization acquiring the resources....and how could anyone discern that > without being a mind-reader? > > Both receive approval for a small initial allocation (unless the one > which was serious could show a history of subassignments from their > existing IP-enabled "digital paperweight" program...) > > As soon as either reached 80% utilization, we'd be happy to approve > a significantly larger allocation (and so on) > > Does this clarify how these two organizations would be handled, and > how gaming the system works in the small but has diminishing returns? Sure but how do you determine genuine utilization from manufactured utilization. Does giving away a 3 or 6 month free subscription to a "digital paper-weight" with every happy-meal purchase count as utilization? How about having another company which is a legally separate entity (but just so happened to have the exact same private ownership/board membership) purchase 80% of the virtual pet rocks for their "virtual pet rock garden" count as utilization? Those sort of shenanigans may sound rather absurd now, because there would be a real cost to enacting them in a convincing manner. However IF the real value of an IPv4 address increases beyond the cost of such ploys, suddenly they become worthwhile doing. Would not the cost/difficulty of effectively differentiating between gaming and the real thing also increase for ARIN under such circumstances? > > > Note that speculators always risk being left holding the bag when the > bottom falls out of the market they are playing with. Risk is inherent in what > they do...unfortunately it doesn't seem to curtail their activities very much in > most scarcity markets. > > Agreed, although far fewer participate in situations where the risk > is self-created due to operating contrary to the system. It's one > thing to point out to investors that you misread the market, it is > another to explain that you were doing something that was technically > contrary to market rules and that resulted in the loss. > > > Functionally the only things I see a needs based requirement accomplishing > in a transfer market is artificially inflating the cost of transfers, > > It definitely increases the net transaction cost. > > > increasing the cost for ARIN to administer transfers > > To be clear: it results in transfers having overhead similar to > the assignment approvals which we are presently doing. > As I see it, as the rewards for gaming the rules increase, people will be willing to invest more resources in doing so. Unless you are willing to devote more resources to enforcing said rules, your effectiveness in enforcing them diminishes accordingly. > > and creating a new job position among certain companies of "needs > justification designer". > > That position or at least job task (IP address management) already > exists in ISPs today (or at least those ISPs which are growing and > need additional allocations on a routine basis) > > > I don't think it's going to accomplish what many proponents might hope it > would very effectively. > > For clarity: there is a big difference between "effective" and "very > effective"; do you mean that you don't think it will curtail routing > growth and prevent speculation at all, or simply that it will provide > less than ideal protection from such? > I think you are not going to end up without very much "bang for your buck". Either you are going to end with a rubber stamp system which people with some knowledge of the system and resources to spend in gaming it will increasingly be able to subvert or you are going to end up having to increase your enforcement efforts (and the resources devoted to them) significantly in order to maintain a similar degree of effectiveness as you do today. It strikes me as a pretty unenviable position for ARIN. Perhaps the point David Farmer raised in his post about dropping the needs based justification for transfers below a certain size threshold (or perhaps annual quota for a single organization) and preserving it for ones that exceed it would be a good compromise position? After-all, small transfers would likely be approved on a trial basis anyway....and likely would do limited harm even if done without real justification. Anyway, the above assumes that the scarcity of IPv4 addresses results in a significant increase in the value of such addresses. Perhaps if IPv6 adoption see's more of an uptick.... that situation will be significantly mitigated and the impact of all this won't amount to very much. > > In a market where acquiring IP addresses is relatively trivial (i.e. unassigned > space from ARIN), I can certainly see why there has to be some artificial > barrier built into the system to prevent people from acquiring IP space for > trivial reasons....with a scarcity market, the cost of acquisition through > transfers itself should act as a barrier to that. Anyway, that's how I see it...for > whatever it's worth. > > Good comments; hopefully this discussion will help folks in consideration > of the large set of policy proposals before us. > > Thanks! > /John > > John Curran > President and CEO > ARIN > Thanks again, appreciate the ability to be able to participate in such discussions as just a member of the interested public. The openness and level of communication are refreshing. Christopher Engel (representing only my own views) From owen at delong.com Fri May 13 13:30:01 2011 From: owen at delong.com (Owen DeLong) Date: Fri, 13 May 2011 10:30:01 -0700 Subject: [arin-ppml] Draft Proposal 2011-1 - Comments request - Globally Coordinated Transfer Policy In-Reply-To: References: Message-ID: > >> 2. If objections exist, to succinctly identify what they are..and, > > The references to RFC 2050 which in the last 6 months has enjoyed > almost universal agreement that it's not relevant; it was written in > 1996 in a time and place that is far different than today, it was a > Best *Current* Practice (emphasis added) "BCP". > Just because you keep saying this doesn't make it true. I have only heard a small handful of people argue that RFC 2050 is not relevant. The vast majority of the community seems to still believe that it is. > > Finally, how is this proposal being coordinated globally? > I believe the beauty of this particular proposal is that it does not need to be. It spells out a way in which other RIRs can pass compatible policies which would allow ARIN to approve such transfers. Owen From jeffrey.lyon at blacklotus.net Fri May 13 13:32:21 2011 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Fri, 13 May 2011 13:32:21 -0400 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate In-Reply-To: References: <7F5FC4554E42430FADDC0D376164DFA0@mike> <0BB63D56-1605-4E1E-8F0B-B2083FDE4A96@delong.com> <16AACD9632484C85BF6B855603CF07B4@mike> <907EE389FDC5448ABC46ADD06420B86D@video> <599AC4287E79403D939568C89EB40922@video> <463771E5-094B-48CB-BAD7-C6D51088C26E@delong.com> <8DDDEFF8-91B6-4C38-83C3-EDDEB44E8BE8@matthew.at> <02540BF3-D17E-4069-BC98-ECC29053A4CA@matthew.at> <7834D82CC7C64E64820785568E598738@mike> Message-ID: > > Those sort of shenanigans may sound rather absurd now, because there would be a real cost to enacting them in a convincing manner. However IF the real value of an IPv4 address increases beyond the cost of such ploys, suddenly they become worthwhile doing. Would not the cost/difficulty of effectively differentiating between gaming and the real thing also increase for ARIN under such circumstances? > They're not absurd at all, there are companies doing this right now. There is one small company using 3 x /18, mostly for blackhat SEO and IRC virtual hosts. -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications - AS32421 First and Leading in DDoS Protection Solutions From jcurran at arin.net Fri May 13 13:37:52 2011 From: jcurran at arin.net (John Curran) Date: Fri, 13 May 2011 17:37:52 +0000 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate In-Reply-To: References: <7F5FC4554E42430FADDC0D376164DFA0@mike> <0BB63D56-1605-4E1E-8F0B-B2083FDE4A96@delong.com> <16AACD9632484C85BF6B855603CF07B4@mike> <907EE389FDC5448ABC46ADD06420B86D@video> <599AC4287E79403D939568C89EB40922@video> <463771E5-094B-48CB-BAD7-C6D51088C26E@delong.com> <8DDDEFF8-91B6-4C38-83C3-EDDEB44E8BE8@matthew.at> <02540BF3-D17E-4069-BC98-ECC29053A4CA@matthew.at> <7834D82CC7C64E64820785568E598738@mike> , Message-ID: <6471DF31-73AD-4178-B459-E9F8C0F14E92@arin.net> On May 13, 2011, at 10:32 AM, "Jeffrey Lyon" wrote: > They're not absurd at all, there are companies doing this right now. > There is one small company using 3 x /18, mostly for blackhat SEO and > IRC virtual hosts. Jeffrey - Please report specifics on the number resource fraud reporting page. I cannot guaruantee that we will be able to take action, but we will research and that does lead to reclaimation actions. Thanks! /John John Curran President and CEO ARIN From mike at nationwideinc.com Fri May 13 13:39:07 2011 From: mike at nationwideinc.com (Mike Burns) Date: Fri, 13 May 2011 13:39:07 -0400 Subject: [arin-ppml] Just a reminder of some quick mathematics for IPv4that shows the long term impossibility of it References: <4DCC41D8.1010305@ipinc.net> Message-ID: <714BA22421E941B68BE3268E21738D09@mike> Hi Owen, >> > Does a rat who has lived its entire life in a cage realize it is in a > cage? > I took a population of ad libitum "rats" and put them to this very test. I had about 100 or so DSL users who reprsented normal business and residential use. The used to each get a routable IPv4 address from a DHCP pool. Then I switched them to CGN and waited for complaints, upon which I would have switched back. I waited and waited. There were no complaints. It's been three years no and counting, they are still on CGN, and they are YouTubers, gamers, P2P participants, Skype users. Continuing to call CGN a nightmare looks ludicrous to me. > Just because they haven't actually experienced the internet and have been > fooled into believing what they have is access to the internet does not > make the claim any more accurate. > > As I said, they don't have internet access. They have a controlled > and limited subset of the features that define internet access. > > The internet is a peer-to-peer network where each system has a > globally unique potentially reachable address and can operate > as both client and server. Machines behind a NAT have access > to only a subset of those defining features. > > Owen > Think about the etymology of the word Internet for a moment. It was designed as a network of networks, not a single Layer2 network. End-to-end addressability was not a goal of the founders of the Internet, it was network-to-network reachability. In fact, the era of end-to-end for the Internet was the limited timeframe between popular acceptance and NAT. Most people would fear to put a real IP address on a computer today, I know that I would. I use Logmein from behind NAT to address another computer behind another NAT. Rendezvous servers exist for that purpose, and the market favors them. Holding on to some dream of complete end-to-end reachability leaves out the inevitable firewall application between them in any case. Juniper and Cisco have enabled CGN on their big iron boxes, do you think they are unaware of the nightmarish negative impact of CGN you ascribe? Regards, Mike From owen at delong.com Fri May 13 13:37:12 2011 From: owen at delong.com (Owen DeLong) Date: Fri, 13 May 2011 10:37:12 -0700 Subject: [arin-ppml] ARIN-prop-150 Reclamation Hold In-Reply-To: References: <4DCD36FC.3000501@arin.net> Message-ID: <6B54F569-3486-4420-81AE-68FD67EA1DA7@delong.com> > >> This provides sufficient time for the resources to go unused >> prior to reassignment and/or to be re-justified by the original >> registrant, or returned to the proper holder in the case of hijackings. > > This could be solved with a much weaker requirement: "ARIN shall not > reallocate recovered address space while its status is under dispute > by a prior registrant." > This would require at least some way that ARIN can make a final determination that the dispute is invalid and move on, otherwise a prior registrant could effectively block any reclamation arbitrarily. Owen From tvest at eyeconomics.com Fri May 13 13:43:28 2011 From: tvest at eyeconomics.com (Tom Vest) Date: Fri, 13 May 2011 13:43:28 -0400 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate In-Reply-To: <85BA8F9D1CA040C7836CD9049CBD5F26@mike> References: <7F5FC4554E42430FADDC0D376164DFA0@mike> <0BB63D56-1605-4E1E-8F0B-B2083FDE4A96@delong.com> <16AACD9632484C85BF6B855603CF07B4@mike> <4294678C-B653-4BB3-9D40-FD935EA00CF3@eyeconomics.com> <4A4A6144-C036-4DB8-A350-14E21D18E02A@eyeconomics.com> <85BA8F9D1CA040C7836CD9049CBD5F26@mike> Message-ID: On May 13, 2011, at 1:07 PM, Mike Burns wrote: > Hi Tom, > >> What definition of "accuracy in Whois" do you have in mind in this context? Can you provide an example of the absolute minimum set of whois parameters and parameter values (e.g., specific whois contact details | >degree of verifiability / fidelity of those details ) that would be consistent with your definition of "accuracy in Whois"? > > Whois has an underlying justification in the requirement for uniqueness of registration for each allocated netblock. I think Whois should list the current owner of the routing rights to the netblock and have valid contact information. If it had those things, I would consider it to be accurate. > > >> And why exactly do are we placing such a high value on "accuracy in Whois" anyway? From your point of view, what are the requirements|purposes|uses of whois that justify the considerable investments in time and >effort that are required to maintain Whois data quality at this level? > > It provides an element of routing authority that is used by network operators to decide whether their customer had the authority to route these addresses. It can also be used for abuse notification when the only information on the abuser is his ip address. > >> Though it might seem like a simple question, the range of possible answers is vast. Would your own criteria for whois "accuracy" and "purpose" be satisfied, for example, by a number resource registry that maintains >100% accurate contact records sufficient for the purpose of registry fee collection, but nothing more than that -- and only shares those few details with duly authorized LEAa and individuals who have been explicitly >granted access by individual registrants themselves? > > No, the registry or registries would also have to ensure uniqueness, not just accurate records for fee collection. I'm clipping here because this is a critical point of clarification, and this exchange is already so long and convoluted (mea culpa) that I wouldn't want it to pass unnoticed by anyone who's still reading. When I have more to say, I'll revert to the full version for the sake of continuity... So, I'll ask again using your suggested revision: Would your own criteria for whois "accuracy" and "purpose" be satisfied by a number resource registry that did the following and nothing more: (1) Registry maintains 100% accurate contact records THAT ARE SUFFICIENT TO UNIQUELY ASSOCIATE INDIVIDUAL NUMBER RECORDS with a set of contact information that includes (1a) "a name," plus (1b) any current/working method of payment sufficient to cover recurring registry service fees. (2) Registry maintains such information on file continuously, but shares it ONLY with duly authorized LEAa and individuals who have been explicitly granted access by individual registrants themselves? Yes or no? If no, please feel free to edit yourself so that the description clearly reveals which features of the current RIR-based whois+registration are excluded. Thanks, TV From cengel at conxeo.com Fri May 13 13:51:43 2011 From: cengel at conxeo.com (Chris Engel) Date: Fri, 13 May 2011 13:51:43 -0400 Subject: [arin-ppml] Just a reminder of some quick mathematics for IPv4 that shows the long term impossibility of it Message-ID: > > > On May 13, 2011, at 6:30 AM, William Herrin wrote: > > > On Thu, May 12, 2011 at 7:44 PM, Owen DeLong > wrote: > >> On May 12, 2011, at 3:46 PM, William Herrin wrote: > >>> On Thu, May 12, 2011 at 4:23 PM, Ted Mittelstaedt > wrote: > >>>> So how exactly do we get the other 4.5 billion people on the Internet > >>>> using IPv4? > >>> > >>> Survey says: NAT. > >> > >> That does not put the other 4.5 billion people on the internet. > > > > The half billion or so who've joined the Internet behind NATs this > > past decade seem to think differently. Who am I to disagree with them? > > Who are you. > > > Does a rat who has lived its entire life in a cage realize it is in a cage? > > Just because they haven't actually experienced the internet and have been > fooled into believing what they have is access to the internet does not > make the claim any more accurate. > > As I said, they don't have internet access. They have a controlled > and limited subset of the features that define internet access. > > The internet is a peer-to-peer network where each system has a > globally unique potentially reachable address and can operate > as both client and server. Machines behind a NAT have access > to only a subset of those defining features. > > 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. Perhaps, a more salient point is simply that while resources may be relatively inelastic that doesn't mean there isn't some elasticity available in efficient utilization of resources, even if that elasticity comes with some undesirable side effects. The supply of arable land in supporting population and improvements in agriculture and sanitation come to mind as a historical example. NAT and host headers are examples I can think of for IPv4. I suppose the real question is how much elasticity is left in IPv4 utilization and what are the consequences of efforts to increase it? Note, that I think the "rat" probably isn't significantly bothered by the cage even if it knows it's there....if all it really cares about doing is updating it's Facebook page and checking what movies are playing at the local cinema. It really depends on what the individual "rat" desires to achieve. The cage may limit it's options, but if none of the options the "rat" cares about happen to be limited by the cage...then it's presence is pretty much inconsequential to that individual "rat". Note that this isn't an argument particularly for or against NAT (even though I personally find it useful) nor IPv6 adoption. Just pointing out that not everyone necessarly wants to get the exact same things out of their access to the internet. Christopher Engel (representing only my own personal views) From mike at nationwideinc.com Fri May 13 13:54:23 2011 From: mike at nationwideinc.com (Mike Burns) Date: Fri, 13 May 2011 13:54:23 -0400 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate References: <7F5FC4554E42430FADDC0D376164DFA0@mike> <0BB63D56-1605-4E1E-8F0B-B2083FDE4A96@delong.com> <16AACD9632484C85BF6B855603CF07B4@mike> <4294678C-B653-4BB3-9D40-FD935EA00CF3@eyeconomics.com> <4A4A6144-C036-4DB8-A350-14E21D18E02A@eyeconomics.com> <85BA8F9D1CA040C7836CD9049CBD5F26@mike> Message-ID: <2C7CD21CB4A9430F8E32222F938D888A@mike> Hi Tom, > >> No, the registry or registries would also have to ensure uniqueness, not >> just accurate records for fee collection. >I'm clipping here because this is a critical point of clarification, and >this exchange is already so long and convoluted (mea culpa) that I wouldn't >want it to pass unnoticed by anyone who's still reading. When I have >more >to say, I'll revert to the full version for the sake of continuity... >So, I'll ask again using your suggested revision: >Would your own criteria for whois "accuracy" and "purpose" be satisfied by >a number resource registry that did the following and nothing more: (1) Registry maintains 100% accurate contact records THAT ARE SUFFICIENT TO UNIQUELY ASSOCIATE INDIVIDUAL NUMBER RECORDS with a set of contact information that includes (1a) "a name," plus (1b) any current/working method of payment sufficient to cover recurring registry service fees. No. The numbers need to be unique in the universe of routable IPv4 addresses. Only one registrant may be assigned to an individual netblock. (2) Registry maintains such information on file continuously, but shares it ONLY with duly authorized LEAa and individuals who have been explicitly granted access by individual registrants themselves? No. I think it should be publicly accessible. TV From jeffrey.lyon at blacklotus.net Fri May 13 13:51:45 2011 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Fri, 13 May 2011 13:51:45 -0400 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate In-Reply-To: <6471DF31-73AD-4178-B459-E9F8C0F14E92@arin.net> References: <7F5FC4554E42430FADDC0D376164DFA0@mike> <0BB63D56-1605-4E1E-8F0B-B2083FDE4A96@delong.com> <16AACD9632484C85BF6B855603CF07B4@mike> <907EE389FDC5448ABC46ADD06420B86D@video> <599AC4287E79403D939568C89EB40922@video> <463771E5-094B-48CB-BAD7-C6D51088C26E@delong.com> <8DDDEFF8-91B6-4C38-83C3-EDDEB44E8BE8@matthew.at> <02540BF3-D17E-4069-BC98-ECC29053A4CA@matthew.at> <7834D82CC7C64E64820785568E598738@mike> <6471DF31-73AD-4178-B459-E9F8C0F14E92@arin.net> Message-ID: On Fri, May 13, 2011 at 1:37 PM, John Curran wrote: > On May 13, 2011, at 10:32 AM, "Jeffrey Lyon" wrote: > >> They're not absurd at all, there are companies doing this right now. >> There is one small company using 3 x /18, mostly for blackhat SEO and >> IRC virtual hosts. > > Jeffrey - > > Please report specifics on the number resource fraud reporting page. > > I cannot guaruantee that we will be able to take action, but we will research and that does lead to reclaimation actions. > > Thanks! > /John > > John Curran > President and CEO > ARIN John, You and I have spoken about this before and your fraud investigation was already completed. The one org in question still has the 3 x /18 so presumably they managed to convince ARIN that they're hosting 49k IP enabled pet rocks. -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications - AS32421 First and Leading in DDoS Protection Solutions From owen at delong.com Fri May 13 13:50:52 2011 From: owen at delong.com (Owen DeLong) Date: Fri, 13 May 2011 10:50:52 -0700 Subject: [arin-ppml] ARIN-prop-150 Reclamation Hold In-Reply-To: <4DCD52EB.7030806@matthew.at> References: <4DCD36FC.3000501@arin.net> <4DCD52EB.7030806@matthew.at> Message-ID: <44A0C957-0BB4-4251-B16A-A1373A9F701F@delong.com> On May 13, 2011, at 8:48 AM, Matthew Kaufman wrote: > On 5/13/2011 8:38 AM, William Herrin wrote: >> On Fri, May 13, 2011 at 9:49 AM, ARIN wrote: >>> ARIN-prop-150 Reclamation Hold >>> Proposal Originator: Matthew Kaufman >>> >>> Add a new section to the NRPM: >>> "All resources reclaimed by ARIN shall not be returned to the free pool >>> or otherwise reassigned to any entity than the original registrant for a >>> period of 36 months." >> LIRs are prevented from implementing this sort of policy since such >> reserved addresses do not count towards their utilization. What >> problems are solved by implementing this policy at an RIR level but >> requiring LIRs to not implement the same? > > LIRs have direct circuit-level (or equivalent) relationships with the address users. RIRs do not. > Not necessarily true. As was pointed out in the opposition to my prop. 139 there are several instances of LIRs without circuit-level relationships. > It would be very unusual for someone to have provider-assigned space and no ongoing contact or billing relationship with the provider, whereas legacy space in ARIN's database is exactly like that. > I can point to more than 100,000 users without a billing relationship that have address assignments from at least one provider, so, I don't think that is as unusual as you claim. Some of these users have just over 18 quintillion addresses, while others have 66,537 times that much or even more. >> >> >>> This provides sufficient time for the resources to go unused >>> prior to reassignment and/or to be re-justified by the original >>> registrant, or returned to the proper holder in the case of hijackings. >> This could be solved with a much weaker requirement: "ARIN shall not >> reallocate recovered address space while its status is under dispute >> by a prior registrant." > > How can the prior registrant initiate a dispute in time if they weren't aware of a hijacking and subsequent immediate reclaimation? > Arguably if they were not aware, then, they were not "using" their resources. However, if they have followed policy and kept their POCs up to date, the POCs would have been notified well before the "immediate" reclamation which usually takes at least 6 months. Owen From rudi.daniel at gmail.com Fri May 13 13:56:01 2011 From: rudi.daniel at gmail.com (Rudolph Daniel) Date: Fri, 13 May 2011 13:56:01 -0400 Subject: [arin-ppml] ARIN-prop-150 Reclamation Hold Message-ID: I opposed....this proposal makes very little sense to me. RD > On Fri, May 13, 2011 at 9:52 AM, McTim wrote: > > On Fri, May 13, 2011 at 4:49 PM, ARIN wrote: > > > >> > >> ARIN-prop-150 Reclamation Hold > >> > >> Proposal Originator: Matthew Kaufman > >> > >> Proposal Version: 1 > >> > >> Date: 13 May 2011 > >> > >> Proposal type: new > >> > >> Policy term: permanent > >> > >> Policy statement: > >> > >> Add a new section to the NRPM: > >> "All resources reclaimed by ARIN shall not be returned to the free pool > >> or otherwise reassigned to any entity than the original registrant for a > >> period of 36 months." > > > > Message: 3 > Date: Fri, 13 May 2011 10:50:28 -0400 > From: Martin Hannigan > To: McTim > Cc: arin-ppml at arin.net > Subject: Re: [arin-ppml] ARIN-prop-150 Reclamation Hold > Message-ID: > Content-Type: text/plain; charset=ISO-8859-1 > > On Fri, May 13, 2011 at 9:52 AM, McTim wrote: > > On Fri, May 13, 2011 at 4:49 PM, ARIN wrote: > > > >> > >> ARIN-prop-150 Reclamation Hold > >> > >> Proposal Originator: Matthew Kaufman > >> > >> Proposal Version: 1 > >> > >> Date: 13 May 2011 > >> > >> Proposal type: new > >> > >> Policy term: permanent > >> > >> Policy statement: > >> > >> Add a new section to the NRPM: > >> "All resources reclaimed by ARIN shall not be returned to the free pool > >> or otherwise reassigned to any entity than the original registrant for a > >> period of 36 months." > > > > I am opposed to this. ?36 months is far too long IMO for a "quarantine" > > > Agreed, we just had a proposal with significant support to return > address reclaimed to the free pool with a high expectation of > "faster", not slower. I don't see why this would be any different > hence I expect a lack of community support. In fact, I think that the > author should consider withdrawing this to save us all some time. > > We need to leave this as an administrative decision influenced by the > community vs. a rule. This is an example of not knowing what you might > not know. > > Best, > > -M< > > > ------------------------------ > > _______________________________________________ > ARIN-PPML mailing list > ARIN-PPML at arin.net > http://lists.arin.net/mailman/listinfo/arin-ppml > > End of ARIN-PPML Digest, Vol 71, Issue 143 > ****************************************** > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gary.buhrmaster at gmail.com Fri May 13 13:56:10 2011 From: gary.buhrmaster at gmail.com (Gary Buhrmaster) Date: Fri, 13 May 2011 17:56:10 +0000 Subject: [arin-ppml] ARIN-prop-150 Reclamation Hold In-Reply-To: <4DCD36FC.3000501@arin.net> References: <4DCD36FC.3000501@arin.net> Message-ID: On Fri, May 13, 2011 at 13:49, ARIN wrote: > ARIN-prop-150 Reclamation Hold I oppose the policy as written. I believe that the process for reclamation (or revocation) is sufficiently long (and I would bet onerous) through the ARIN internal processes this substantial increase of hold period after the actual reclaim is not warranted (there is already a hold). I can agree that there will always be a slight risk that a legitimate holder will appear after some extended period, and the space has been reassigned (and after runout, ARIN can not help). For that unlikely event, I might instead propose that after run-out ARIN holds in "reserve" a small amount of space to provide some amount of "relief" in the case of a decision gone bad (which seems unlikely, given my (admittedly limited) understanding of the care and due diligence that ARIN takes to get such decisions right). The only reason I would rethink my position is if ARIN has documented cases where revocation or reclamation has gone "bad" and an extended hold period would have assisted in the resolution. Gary From matthew at matthew.at Fri May 13 14:00:39 2011 From: matthew at matthew.at (Matthew Kaufman) Date: Fri, 13 May 2011 11:00:39 -0700 Subject: [arin-ppml] ARIN-prop-150 Reclamation Hold In-Reply-To: <44A0C957-0BB4-4251-B16A-A1373A9F701F@delong.com> References: <4DCD36FC.3000501@arin.net> <4DCD52EB.7030806@matthew.at> <44A0C957-0BB4-4251-B16A-A1373A9F701F@delong.com> Message-ID: <4DCD71C7.7060602@matthew.at> On 5/13/2011 10:50 AM, Owen DeLong wrote: > On May 13, 2011, at 8:48 AM, Matthew Kaufman wrote: > >> On 5/13/2011 8:38 AM, William Herrin wrote: >>> On Fri, May 13, 2011 at 9:49 AM, ARIN wrote: >>>> ARIN-prop-150 Reclamation Hold >>>> Proposal Originator: Matthew Kaufman >>>> >>>> Add a new section to the NRPM: >>>> "All resources reclaimed by ARIN shall not be returned to the free pool >>>> or otherwise reassigned to any entity than the original registrant for a >>>> period of 36 months." >>> LIRs are prevented from implementing this sort of policy since such >>> reserved addresses do not count towards their utilization. What >>> problems are solved by implementing this policy at an RIR level but >>> requiring LIRs to not implement the same? >> LIRs have direct circuit-level (or equivalent) relationships with the address users. RIRs do not. >> > Not necessarily true. As was pointed out in the opposition to my prop. 139 > there are several instances of LIRs without circuit-level relationships. Yes, but even in those cases the agreements are much more specific. >> It would be very unusual for someone to have provider-assigned space and no ongoing contact or billing relationship with the provider, whereas legacy space in ARIN's database is exactly like that. >> > I can point to more than 100,000 users without a billing relationship that > have address assignments from at least one provider, so, I don't think > that is as unusual as you claim. Some of these users have just over 18 > quintillion addresses, while others have 66,537 times that much or > even more. And do the terms of service they agreed to allow their provider to reclaim the address space from them immediately and give it to someone else? If so, fine. But that's not what legacy holders agreed to when they received their allocations. >>> >>>> This provides sufficient time for the resources to go unused >>>> prior to reassignment and/or to be re-justified by the original >>>> registrant, or returned to the proper holder in the case of hijackings. >>> This could be solved with a much weaker requirement: "ARIN shall not >>> reallocate recovered address space while its status is under dispute >>> by a prior registrant." >> How can the prior registrant initiate a dispute in time if they weren't aware of a hijacking and subsequent immediate reclaimation? >> > Arguably if they were not aware, then, they were not "using" their > resources. They could very well be "using" their resources for exactly the sorts of things that were permitted when they received their space... like using them internally for a network that is not directly connected to the Internet at this time. > However, if they have followed policy and kept their > POCs up to date, the POCs would have been notified well > before the "immediate" reclamation which usually takes at least > 6 months. If their POCs hadn't been changed without them knowing that. Or lost due to a DNS lapse that was exploited by the hijacker. Etc, etc. Matthew Kaufman From jcurran at arin.net Fri May 13 14:00:40 2011 From: jcurran at arin.net (John Curran) Date: Fri, 13 May 2011 18:00:40 +0000 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate In-Reply-To: References: <7F5FC4554E42430FADDC0D376164DFA0@mike> <0BB63D56-1605-4E1E-8F0B-B2083FDE4A96@delong.com> <16AACD9632484C85BF6B855603CF07B4@mike> <907EE389FDC5448ABC46ADD06420B86D@video> <599AC4287E79403D939568C89EB40922@video> <463771E5-094B-48CB-BAD7-C6D51088C26E@delong.com> <8DDDEFF8-91B6-4C38-83C3-EDDEB44E8BE8@matthew.at> <02540BF3-D17E-4069-BC98-ECC29053A4CA@matthew.at> <7834D82CC7C64E64820785568E598738@mike> <6471DF31-73AD-4178-B459-E9F8C0F14E92@arin.net>, Message-ID: <55C50AE0-E80E-443E-A5FE-638371AD4A99@arin.net> On May 13, 2011, at 10:55 AM, "Jeffrey Lyon" wrote: > On Fri, May 13, 2011 at 1:37 PM, John Curran wrote: >> On May 13, 2011, at 10:32 AM, "Jeffrey Lyon" wrote: >> >>> They're not absurd at all, there are companies doing this right now. >>> There is one small company using 3 x /18, mostly for blackhat SEO and >>> IRC virtual hosts. >> >> Jeffrey - >> >> Please report specifics on the number resource fraud reporting page. >> >> I cannot guaruantee that we will be able to take action, but we will research and that does lead to reclaimation actions. >> >> Thanks! >> /John >> >> John Curran >> President and CEO >> ARIN > > John, > > You and I have spoken about this before and your fraud investigation > was already completed. The one org in question still has the 3 x /18 > so presumably they managed to convince ARIN that they're hosting 49k IP enabled pet rocks. As you are aware, we do not judge whether a party is violating any ISP's terms of service, such issues should be reported to the appropriate Internet service provider. Thanks! /John John Curran President and CEO ARIN From hannigan at gmail.com Fri May 13 14:12:47 2011 From: hannigan at gmail.com (Martin Hannigan) Date: Fri, 13 May 2011 14:12:47 -0400 Subject: [arin-ppml] Draft Proposal 2011-1 - Comments request - Globally Coordinated Transfer Policy In-Reply-To: References: Message-ID: On Fri, May 13, 2011 at 1:30 PM, Owen DeLong wrote: >> >>> 2. If objections exist, to succinctly identify what they are..and, >> >> The references to RFC 2050 which in the last 6 months has enjoyed >> almost universal agreement that it's not relevant; it was written in >> 1996 in a time and place that is far different than today, it was a >> Best *Current* Practice (emphasis added) "BCP". >> > > Just because you keep saying this doesn't make it true. I have only > heard a small handful of people argue that RFC 2050 is not relevant. > The vast majority of the community seems to still believe that it is. And just because you keep saying that it's not true doesn't mean that it's not. There's ample evidence supporting my claim including activity at the ICANN ASO AC and NRO NC to deprecate it. That kinda sorta speaks pretty loudly. There has also been plenty of discussion here with most agreeing that it's "outdated". Please, feel free to demonstrate that it's relevant in some way. > >> >> Finally, how is this proposal being coordinated globally? >> > > I believe the beauty of this particular proposal is that it does not > need to be. It spells out a way in which other RIRs can pass > compatible policies which would allow ARIN to approve > such transfers. That means it will be mostly incompatible with the intent of global coordination. I suggest we remove the coordinated part and simply call it inter-RIR transfer process. It doesnt require global adoption nor ICANN approval as far as I can tell. From bill at herrin.us Fri May 13 14:30:08 2011 From: bill at herrin.us (William Herrin) Date: Fri, 13 May 2011 14:30:08 -0400 Subject: [arin-ppml] Just a reminder of some quick mathematics for IPv4 that shows the long term impossibility of it In-Reply-To: <4DCD52DB.2080209@bogus.com> References: <4DCC41D8.1010305@ipinc.net> <4DCD52DB.2080209@bogus.com> Message-ID: On Fri, May 13, 2011 at 11:48 AM, Joel Jaeggli wrote: > On 5/13/11 6:30 AM, William Herrin wrote: >> On Thu, May 12, 2011 at 7:44 PM, Owen DeLong wrote: >>> On May 12, 2011, at 3:46 PM, William Herrin wrote: >>>> On Thu, May 12, 2011 at 4:23 PM, Ted Mittelstaedt wrote: >>>>> So how exactly do we get the other 4.5 billion people on the Internet >>>>> using IPv4? >>>> >>>> Survey says: NAT. >>> >>> That does not put the other 4.5 billion people on the internet. >> >> The half billion or so who've joined the Internet behind NATs this >> past decade seem to think differently. Who am I to disagree with them? >> Who are you. > > There are enough ip's for all the nats to site behind either, it's not > rocket science... maintaining large numbers of parallel addressing > planes the require state-management for egress has a real cost and those > things have nothing like the scaling properties of the stateless v4 > internet you grew up with. Joel, In 1971, Ehrlich predicted a maximum sustainable world population of 1.2 billion people. By 1994 Ehrlich raised the estimate to 2 billion saying, "the present population of 5.5 billion [..] has clearly exceeded the capacity of Earth to sustain it." Two decades later we're closing in on 7 billion actual souls the overwhelming majority of which are not expected to starve to death or otherwise suffer drastic harm due to insufficient planetary carrying capacity. Don't be an Ehrlich, a population alarmist. NAT has scalability issues but with more than a decade's experience, we know what they are. NAT readily and cost-effectively scales the address-to-user ratio by at least two orders of magnitude (100x), more than enough for the 4x increase in Internet usage minimally needed to bring the rest of the world online. Not rocket science indeed. Don't get me wrong: there are lots of good reasons why we -shouldn't- build out the Internet to 7B people using IPv4. Excellent reasons to push for IPv6 as our growth path instead. But the claim that IPv4 use -can't- expand via NAT is purely specious. I'm tired of hearing that outrageous claim from people who should know better. Makes you look like idiots and (annoyingly) distracts from the topics then under discussion. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From dogwallah at gmail.com Fri May 13 14:35:36 2011 From: dogwallah at gmail.com (McTim) Date: Fri, 13 May 2011 21:35:36 +0300 Subject: [arin-ppml] ARIN-prop-150 Reclamation Hold In-Reply-To: <4DCD4FBD.7090901@matthew.at> References: <4DCD36FC.3000501@arin.net> <4DCD4FBD.7090901@matthew.at> Message-ID: On Fri, May 13, 2011 at 6:35 PM, Matthew Kaufman wrote: > On 5/13/2011 7:48 AM, Jeffrey Lyon wrote: >> >>> I am opposed to this. ?36 months is far too long IMO for a "quarantine" > > Right now the period is "none, or whatever staff thinks is good". What time > period would you suggest? I would suggest that it remain a procedural decision, not a policy driven choice. (Once we have consensus around the time, I'll > submit a revision to the proposal) As Martin has said, the community has indicated they wouldn't mind a shorter period just recently. -- Cheers, McTim "A name indicates what we seek. An address indicates where it is. A route indicates how we get there."? Jon Postel From jeffrey.lyon at blacklotus.net Fri May 13 14:38:36 2011 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Fri, 13 May 2011 14:38:36 -0400 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate In-Reply-To: <55C50AE0-E80E-443E-A5FE-638371AD4A99@arin.net> References: <7F5FC4554E42430FADDC0D376164DFA0@mike> <0BB63D56-1605-4E1E-8F0B-B2083FDE4A96@delong.com> <16AACD9632484C85BF6B855603CF07B4@mike> <907EE389FDC5448ABC46ADD06420B86D@video> <599AC4287E79403D939568C89EB40922@video> <463771E5-094B-48CB-BAD7-C6D51088C26E@delong.com> <8DDDEFF8-91B6-4C38-83C3-EDDEB44E8BE8@matthew.at> <02540BF3-D17E-4069-BC98-ECC29053A4CA@matthew.at> <7834D82CC7C64E64820785568E598738@mike> <6471DF31-73AD-4178-B459-E9F8C0F14E92@arin.net> <55C50AE0-E80E-443E-A5FE-638371AD4A99@arin.net> Message-ID: On Fri, May 13, 2011 at 2:00 PM, John Curran wrote: > On May 13, 2011, at 10:55 AM, "Jeffrey Lyon" wrote: > >> On Fri, May 13, 2011 at 1:37 PM, John Curran wrote: >>> On May 13, 2011, at 10:32 AM, "Jeffrey Lyon" wrote: >>> >>>> They're not absurd at all, there are companies doing this right now. >>>> There is one small company using 3 x /18, mostly for blackhat SEO and >>>> IRC virtual hosts. >>> >>> Jeffrey - >>> >>> Please report specifics on the number resource fraud reporting page. >>> >>> I cannot guaruantee that we will be able to take action, but we will research and that does lead to reclaimation actions. >>> >>> Thanks! >>> /John >>> >>> John Curran >>> President and CEO >>> ARIN >> >> John, >> >> You and I have spoken about this before and your fraud investigation >> was already completed. The one org in question still has the 3 x /18 >> so presumably they managed to convince ARIN that they're hosting 49k IP enabled pet rocks. > > As you are aware, we do not judge whether a party is violating any ISP's terms of service, such issues should be reported to the appropriate Internet service provider. > > Thanks! > /John > > John Curran > President and CEO > ARIN John, I don't think they're doing anything that would violate any TOS. They are, however, wasting IP space by allowing a single dedicated server customer to purchase /24 and shorter for reasons including SEO and IRC virtual hosts. If this is ARIN's intent, so be it. Otherwise, understand that they're lying to you in your fraud investigation. If that's not important to you, again, so be it. -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications - AS32421 First and Leading in DDoS Protection Solutions From jeffrey.lyon at blacklotus.net Fri May 13 14:40:06 2011 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Fri, 13 May 2011 14:40:06 -0400 Subject: [arin-ppml] OT: Mailing list bounce Message-ID: Final-Recipient: rfc822;ghoffstetter at madisontelco.net Action: failed Status: 5.1.1 Can someone please remove this address from the list? It's been bouncing for days, if not weeks. -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications - AS32421 First and Leading in DDoS Protection Solutions From owen at delong.com Fri May 13 14:50:22 2011 From: owen at delong.com (Owen DeLong) Date: Fri, 13 May 2011 11:50:22 -0700 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate In-Reply-To: References: <7F5FC4554E42430FADDC0D376164DFA0@mike> <0BB63D56-1605-4E1E-8F0B-B2083FDE4A96@delong.com> <16AACD9632484C85BF6B855603CF07B4@mike> <907EE389FDC5448ABC46ADD06420B86D@video> <599AC4287E79403D939568C89EB40922@video> <463771E5-094B-48CB-BAD7-C6D51088C26E@delong.com> <8DDDEFF8-91B6-4C38-83C3-EDDEB44E8BE8@matthew.at> <02540BF3-D17E-4069-BC98-ECC29053A4CA@matthew.at> <7834D82CC7C64E64820785568E598738@mike> Message-ID: <12895B51-6966-461D-A716-B4294DFCB4B8@delong.com> On May 13, 2011, at 10:32 AM, Jeffrey Lyon wrote: >> >> Those sort of shenanigans may sound rather absurd now, because there would be a real cost to enacting them in a convincing manner. However IF the real value of an IPv4 address increases beyond the cost of such ploys, suddenly they become worthwhile doing. Would not the cost/difficulty of effectively differentiating between gaming and the real thing also increase for ARIN under such circumstances? >> > > They're not absurd at all, there are companies doing this right now. > There is one small company using 3 x /18, mostly for blackhat SEO and > IRC virtual hosts. > If this is demonstrably true, it would be best if you pointed it out in through the ARIN fraud reporting form. Owen From jeffrey.lyon at blacklotus.net Fri May 13 14:52:36 2011 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Fri, 13 May 2011 14:52:36 -0400 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate In-Reply-To: <12895B51-6966-461D-A716-B4294DFCB4B8@delong.com> References: <7F5FC4554E42430FADDC0D376164DFA0@mike> <0BB63D56-1605-4E1E-8F0B-B2083FDE4A96@delong.com> <16AACD9632484C85BF6B855603CF07B4@mike> <907EE389FDC5448ABC46ADD06420B86D@video> <599AC4287E79403D939568C89EB40922@video> <463771E5-094B-48CB-BAD7-C6D51088C26E@delong.com> <8DDDEFF8-91B6-4C38-83C3-EDDEB44E8BE8@matthew.at> <02540BF3-D17E-4069-BC98-ECC29053A4CA@matthew.at> <7834D82CC7C64E64820785568E598738@mike> <12895B51-6966-461D-A716-B4294DFCB4B8@delong.com> Message-ID: On Fri, May 13, 2011 at 2:50 PM, Owen DeLong wrote: > > On May 13, 2011, at 10:32 AM, Jeffrey Lyon wrote: > >>> >>> Those sort of shenanigans may sound rather absurd now, because there would be a real cost to enacting them in a convincing manner. However IF the real value of an IPv4 address increases beyond the cost of such ploys, suddenly they become worthwhile doing. Would not the cost/difficulty of effectively differentiating between gaming and the real thing also increase for ARIN under such circumstances? >>> >> >> They're not absurd at all, there are companies doing this right now. >> There is one small company using 3 x /18, mostly for blackhat SEO and >> IRC virtual hosts. >> > > If this is demonstrably true, it would be best if you pointed it out in through > the ARIN fraud reporting form. > > Owen > > Tried it, didn't work, moved on to more important things. -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications - AS32421 First and Leading in DDoS Protection Solutions From jcurran at arin.net Fri May 13 14:59:11 2011 From: jcurran at arin.net (John Curran) Date: Fri, 13 May 2011 18:59:11 +0000 Subject: [arin-ppml] Draft Proposal 2011-1 - Comments request - Globally Coordinated Transfer Policy In-Reply-To: References: Message-ID: On May 13, 2011, at 11:12 AM, Martin Hannigan wrote: > And just because you keep saying that it's not true doesn't mean that > it's not. There's ample evidence supporting my claim including > activity at the ICANN ASO AC and NRO NC to deprecate it. That kinda > sorta speaks pretty loudly. There has also been plenty of discussion > here with most agreeing that it's "outdated". Please, feel free to > demonstrate that it's relevant in some way. I've heard of discussions to deprecate it, as well as discussions to revise or replace it. I do believe much more important to focus on determine which values in RFC 2050 (some, none, or all) are still valuable to the community, as opposed to having a reference to the RFC 2050 itself. /John John Curran President and CEO ARIN From hannigan at gmail.com Fri May 13 15:00:31 2011 From: hannigan at gmail.com (Martin Hannigan) Date: Fri, 13 May 2011 15:00:31 -0400 Subject: [arin-ppml] Draft Proposal 2011-1 - Comments request - Globally Coordinated Transfer Policy In-Reply-To: References: Message-ID: On Fri, May 13, 2011 at 2:59 PM, John Curran wrote: > On May 13, 2011, at 11:12 AM, Martin Hannigan wrote: > >> And just because you keep saying that it's not true doesn't mean that >> it's not. There's ample evidence supporting my claim including >> activity at the ICANN ASO AC and NRO NC to deprecate it. That kinda >> sorta speaks pretty loudly. There has also been plenty of discussion >> here with most agreeing that it's "outdated". Please, feel free to >> demonstrate that it's relevant in some way. > > I've heard of discussions to deprecate it, as well as discussions to > revise or replace it. ?I do believe much more important to focus on > determine which values in RFC 2050 (some, none, or all) are still > valuable to the community, as opposed to having a reference to the > RFC 2050 itself. > That's where I was going with "in the interest of the ARIN community". Best, -M< From jcurran at arin.net Fri May 13 15:14:15 2011 From: jcurran at arin.net (John Curran) Date: Fri, 13 May 2011 19:14:15 +0000 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate In-Reply-To: References: <7F5FC4554E42430FADDC0D376164DFA0@mike> <0BB63D56-1605-4E1E-8F0B-B2083FDE4A96@delong.com> <"BANLkTinTJfYH5sOuqpbiLreMzW3 dH0Ozgg"@mail.gmail.com> <16AACD9632484C85BF6B855603CF07B4@mike> <"59EC8A7F22F2470 58ED74A896F0C6978"@mike> <907EE389FDC5448ABC46ADD06420B86D@video> <"4B99E603-7892- 433A-9FB9-DB9A08D98F39"@delong.com> <599AC4287E79403D939568C89EB40922@video> <"4DC BFB89.6010804"@matthew.at> <463771E5-094B-48CB-BAD7-C6D51088C26E@delong.com> <8DDDEFF8-91B6-4C38-83C3-EDDEB44E8BE8@matthew.at> <"CA4 0C2F8-CF1F-4C7F-8FDB-87B8D397EB6E"@arin.net> <02540BF3-D17E-4069-BC98-ECC29053A4CA@matthew.at> <"F55FF9C4FDB76643AE0CEC06D0F5CEB30E BC28FEAA"@Skyhawk> <7834D82CC7C64E64820785568E598738@mike> Message-ID: <957142AE-A80F-4202-BE71-459E77ECFA51@arin.net> On May 13, 2011, at 10:23 AM, Chris Engel wrote: > John, > > Thanks for your explanation. The approaching run-out of IPv4 certainly brings alot of complications to the table for ARIN and I don't envy those charged with administrative or decision making duties in the coming months. We'll do the best job possible to implement the policies as defined by the community. This can get rather challenging at times, and does sometimes require ARIN to do some serious educational efforts to folks not aware of the Internet Registry system, but the effort is not insurmountable. > Sure but how do you determine genuine utilization from manufactured utilization. Does giving away a 3 or 6 month free subscription to a "digital paper-weight" with every happy-meal purchase count as utilization? How about having another company which is a legally separate entity (but just so happened to have the exact same private ownership/board membership) purchase 80% of the virtual pet rocks for their "virtual pet rock garden" count as utilization? > > Those sort of shenanigans may sound rather absurd now, because there would be a real cost to enacting them in a convincing manner. However IF the real value of an IPv4 address increases beyond the cost of such ploys, suddenly they become worthwhile doing. Would not the cost/difficulty of effectively differentiating between gaming and the real thing also increase for ARIN under such circumstances? Shenanigans such as the above are attempted now, but are also stopped readily easily when you start asking for various records and perform cross-checks. I am not saying it's foolproof, but the you need to fabricate a fairly complete alternate reality and have the evidence standing by... > As I see it, as the rewards for gaming the rules increase, people will be willing to invest more resources in doing so. Unless you are willing to devote more resources to enforcing said rules, your effectiveness in enforcing them diminishes accordingly. > ... > I think you are not going to end up without very much "bang for your buck". Either you are going to end with a rubber stamp system which people with some knowledge of the system and resources to spend in gaming it will increasingly be able to subvert or you are going to end up having to increase your enforcement efforts (and the resources devoted to them) significantly in order to maintain a similar degree of effectiveness as you do today. Again, we're seeing quite a bit of this now, and the motivations may be stronger (i.e. right now, you can get an entire block "for free" if your request is approved). I do not believe that it is certain that the fraud attempts will necessarily be any greater than we deal with at present. > It strikes me as a pretty unenviable position for ARIN. Perhaps the point David Farmer raised in his post about dropping the needs based justification for transfers below a certain size threshold (or perhaps annual quota for a single organization) and preserving it for ones that exceed it would be a good compromise position? After-all, small transfers would likely be approved on a trial basis anyway....and likely would do limited harm even if done without real justification. The more straightforward the policies and the fewer constraints, the easier to implement. The implementation effort should be considered, but the most important thing is for the community to set policies which match the common goals to keep the Internet operational. If this can be done with simpler policies, that would be good, but the first priority is determining the goals that enjoy overall community support. > Anyway, the above assumes that the scarcity of IPv4 addresses results in a significant increase in the value of such addresses. Perhaps if IPv6 adoption see's more of an uptick.... that situation will be significantly mitigated and the impact of all this won't amount to very much. \ One can hope... :-) > Thanks again, appreciate the ability to be able to participate in such discussions as just a member of the interested public. The openness and level of communication are refreshing. Thanks for participating! /John John Curran President and CEO ARIN From owen at delong.com Fri May 13 15:34:13 2011 From: owen at delong.com (Owen DeLong) Date: Fri, 13 May 2011 12:34:13 -0700 Subject: [arin-ppml] Just a reminder of some quick mathematics for IPv4 that shows the long term impossibility of it In-Reply-To: References: Message-ID: <88BFFFDA-BCB8-454E-810B-1ECBC2859ABD@delong.com> > > Perhaps, a more salient point is simply that while resources may be relatively inelastic that doesn't mean there isn't some elasticity available in efficient utilization of resources, even if that elasticity comes with some undesirable side effects. The supply of arable land in supporting population and improvements in agriculture and sanitation come to mind as a historical example. NAT and host headers are examples I can think of for IPv4. I suppose the real question is how much elasticity is left in IPv4 utilization and what are the consequences of efforts to increase it? > Fortunately for me, since I have signed the LRSA, your efforts can pry my useful globally unique addresses from my cold dead fingers. > Note, that I think the "rat" probably isn't significantly bothered by the cage even if it knows it's there....if all it really cares about doing is updating it's Facebook page and checking what movies are playing at the local cinema. It really depends on what the individual "rat" desires to achieve. The cage may limit it's options, but if none of the options the "rat" cares about happen to be limited by the cage...then it's presence is pretty much inconsequential to that individual "rat". > Well, this rat cares about a great deal more. I host several web sites, operate my own authoritative DNS and mail servers, and make a multitude of remote services available for my use when I am away from home. All of this operates from within my house and I am very glad to be able to use it as such. All without paying a dime to anyone like Citrix (gotomy) or anyone else other than my base internet access charges. > Note that this isn't an argument particularly for or against NAT (even though I personally find it useful) nor IPv6 adoption. Just pointing out that not everyone necessarly wants to get the exact same things out of their access to the internet. > Granted. I wasn't saying that there weren't users that could function behind a NAT, merely that I didn't feel anyone that didn't want to be there should be forced there other than by arrival too late to the party to get an available IPv4 address. Owen From tvest at eyeconomics.com Fri May 13 15:42:20 2011 From: tvest at eyeconomics.com (Tom Vest) Date: Fri, 13 May 2011 15:42:20 -0400 Subject: [arin-ppml] Disambiguation Detour [re: IPv4 Transfer Policy Change to Keep Whois Accurate] In-Reply-To: <2C7CD21CB4A9430F8E32222F938D888A@mike> References: <7F5FC4554E42430FADDC0D376164DFA0@mike> <0BB63D56-1605-4E1E-8F0B-B2083FDE4A96@delong.com> <16AACD9632484C85BF6B855603CF07B4@mike> <4294678C-B653-4BB3-9D40-FD935EA00CF3@eyeconomics.com> <4A4A6144-C036-4DB8-A350-14E21D18E02A@eyeconomics.com> <85BA8F9D1CA040C7836CD9049CBD5F26@mike> <2C7CD21CB4A9430F8E32222F938D888A@mike> Message-ID: <5F20B445-C3A9-4BBD-A704-604C3D71F7BD@eyeconomics.com> On May 13, 2011, at 1:54 PM, Mike Burns wrote: > Hi Tom, > >> >>> No, the registry or registries would also have to ensure uniqueness, not just accurate records for fee collection. > > >> I'm clipping here because this is a critical point of clarification, and this exchange is already so long and convoluted (mea culpa) that I wouldn't want it to pass unnoticed by anyone who's still reading. When I have >more to say, I'll revert to the full version for the sake of continuity... > >> So, I'll ask again using your suggested revision: > >> Would your own criteria for whois "accuracy" and "purpose" be satisfied by a number resource registry that did the following and nothing more: > > (1) Registry maintains 100% accurate contact records THAT ARE SUFFICIENT TO UNIQUELY ASSOCIATE INDIVIDUAL NUMBER RECORDS with a set of contact information that includes (1a) "a name," plus (1b) any current/working method of payment sufficient to cover recurring registry service fees. > > No. The numbers need to be unique in the universe of routable IPv4 addresses. Only one registrant may be assigned to an individual netblock. Does this complete the first half of the formula? (1) Registry maintains a set of unique, non-overlapping number resource records, each one of which is associated with exactly one "registrant" (or equivalently, "registrant record"), which is defined for this purpose as a combination of (1a) a "name," plus (1b) a current/working method of payment sufficient to cover recurring registry service fees. > (2) Registry maintains such information on file continuously, but shares it ONLY with duly authorized LEAa and individuals who have been explicitly granted access by individual registrants themselves? > > No. I think it should be publicly accessible. I don't wish to be pedantic, but would it be possible for you to specify precisely what "it" refers to in the above statement? Also, could you please specify explicitly and directly (i.e., without reference to some another equally ambiguous term) what, if anything, you model registry would *do* to make "it" publicly accessible? Thanks, Tom From owen at delong.com Fri May 13 15:46:26 2011 From: owen at delong.com (Owen DeLong) Date: Fri, 13 May 2011 12:46:26 -0700 Subject: [arin-ppml] ARIN-prop-150 Reclamation Hold In-Reply-To: <4DCD71C7.7060602@matthew.at> References: <4DCD36FC.3000501@arin.net> <4DCD52EB.7030806@matthew.at> <44A0C957-0BB4-4251-B16A-A1373A9F701F@delong.com> <4DCD71C7.7060602@matthew.at> Message-ID: <742E5A96-5C5D-46B4-9AAE-ED69A28C8C2E@delong.com> On May 13, 2011, at 11:00 AM, Matthew Kaufman wrote: > On 5/13/2011 10:50 AM, Owen DeLong wrote: >> On May 13, 2011, at 8:48 AM, Matthew Kaufman wrote: >> >>> On 5/13/2011 8:38 AM, William Herrin wrote: >>>> On Fri, May 13, 2011 at 9:49 AM, ARIN wrote: >>>>> ARIN-prop-150 Reclamation Hold >>>>> Proposal Originator: Matthew Kaufman >>>>> >>>>> Add a new section to the NRPM: >>>>> "All resources reclaimed by ARIN shall not be returned to the free pool >>>>> or otherwise reassigned to any entity than the original registrant for a >>>>> period of 36 months." >>>> LIRs are prevented from implementing this sort of policy since such >>>> reserved addresses do not count towards their utilization. What >>>> problems are solved by implementing this policy at an RIR level but >>>> requiring LIRs to not implement the same? >>> LIRs have direct circuit-level (or equivalent) relationships with the address users. RIRs do not. >>> >> Not necessarily true. As was pointed out in the opposition to my prop. 139 >> there are several instances of LIRs without circuit-level relationships. > > Yes, but even in those cases the agreements are much more specific. > I find your omniscience about the nature of all of the various agreements out there to be most interesting (and unlikely). >>> It would be very unusual for someone to have provider-assigned space and no ongoing contact or billing relationship with the provider, whereas legacy space in ARIN's database is exactly like that. >>> >> I can point to more than 100,000 users without a billing relationship that >> have address assignments from at least one provider, so, I don't think >> that is as unusual as you claim. Some of these users have just over 18 >> quintillion addresses, while others have 66,537 times that much or >> even more. > > And do the terms of service they agreed to allow their provider to reclaim the address space from them immediately and give it to someone else? If so, fine. But that's not what legacy holders agreed to when they received their allocations. > I'm actually not sure. I would have to review our ToS. Legacy holders agreed that their assignments were for a specific purpose and that they should return those addresses when that purpose ended. They also agreed that the addresses were not transferable other than through merger/acquisition of the underlying infrastructure and addresses together (as in acquiring the intended purpose in its entirety). The unfortunate problem is that these were implied agreements among what at the time was a cooperative and friendly community that operated largely on handshakes without the formality of contracts or even real documentation for the most part. It was a very different era in the internet and the current state of affairs had not yet been envisioned or considered, so, we ended up unprepared for it. Frankly, ARIN does not reclaim address space "immediately" even today. The spend time investigating and they attempt to reach the registered PoCs. If those PoCs are responsive, ARIN spends considerable time working with them to see if there is any identifiable way for them to keep the resources within the ARIN policies. Only after that does a reclamation or revocation begin. Even then, reclaimed or revoked addresses enter a minimum 6-month hold-down after they are reclaimed or revoked. >>>> >>>>> This provides sufficient time for the resources to go unused >>>>> prior to reassignment and/or to be re-justified by the original >>>>> registrant, or returned to the proper holder in the case of hijackings. >>>> This could be solved with a much weaker requirement: "ARIN shall not >>>> reallocate recovered address space while its status is under dispute >>>> by a prior registrant." >>> How can the prior registrant initiate a dispute in time if they weren't aware of a hijacking and subsequent immediate reclaimation? >>> >> Arguably if they were not aware, then, they were not "using" their >> resources. > > They could very well be "using" their resources for exactly the sorts of things that were permitted when they received their space... like using them internally for a network that is not directly connected to the Internet at this time. > That is actually still permitted. However, frankly, it's a corner case at best and is dealt with in the next paragraph: >> However, if they have followed policy and kept their >> POCs up to date, the POCs would have been notified well >> before the "immediate" reclamation which usually takes at least >> 6 months. > > If their POCs hadn't been changed without them knowing that. Or lost due to a DNS lapse that was exploited by the hijacker. Etc, etc. > When you change a PoC, the original PoC is notified, so, if their PoC data was valid at the time it was changed, they know. It would take a 3-day or longer DNS lapse for that to be the case. Another safeguard that could be employed, of course, would be to sign the LRSA. Then, at the very least you would notice when you stopped receiving a bill every year. I'm sorry, but, if you have resources and you don't periodically monitor the state of their contact information, then, you are not being a responsible resource holder and I have a very limited amount of sympathy for you. I certainly don't have enough sympathy to keep resources out of circulation for three years waiting for you to miraculously and suddenly start paying attention. Owen -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike at nationwideinc.com Fri May 13 15:59:28 2011 From: mike at nationwideinc.com (Mike Burns) Date: Fri, 13 May 2011 15:59:28 -0400 Subject: [arin-ppml] Disambiguation Detour [re: IPv4 Transfer Policy Change to Keep Whois Accurate] References: <7F5FC4554E42430FADDC0D376164DFA0@mike> <0BB63D56-1605-4E1E-8F0B-B2083FDE4A96@delong.com> <16AACD9632484C85BF6B855603CF07B4@mike> <4294678C-B653-4BB3-9D40-FD935EA00CF3@eyeconomics.com> <4A4A6144-C036-4DB8-A350-14E21D18E02A@eyeconomics.com> <85BA8F9D1CA040C7836CD9049CBD5F26@mike> <2C7CD21CB4A9430F8E32222F938D888A@mike> <5F20B445-C3A9-4BBD-A704-604C3D71F7BD@eyeconomics.com> Message-ID: <5B2DF39B32474A9983356C088C522E5D@mike> Hi Tom, >(1) Registry maintains a set of unique, non-overlapping number resource >records, each one of which is associated with exactly one "registrant" (or >equivalently, "registrant record"), which is defined for this purpose as >a >combination of (1a) a "name," plus (1b) a current/working method of payment >sufficient to cover recurring registry service fees. No, I am not advocating for registry service fees for legacy holders who haven't signed an LRSA, which your definition would imply. Plus I think a contact should be in the record. I do require an RSA of recipients of transferred addresses. >I don't wish to be pedantic, but would it be possible for you to specify >precisely what "it" refers to in the above statement? I think the Whois registry should be publicly accessible under existing access terms. >Also, could you please specify explicitly and directly (i.e., without reference to some another equally ambiguous term) what, if anything, you model registry would *do* to make "it" publicly accessible? I don't have a model registry, but there was a post long back where I provided a link to a letter to ICANN with a proposed set of policies for private registrars, which I guess would be a good place to start, if I were really interested in private registries. Which I'm not, I think that my attempts to change ARIN policy to make it more transparent would provide a disincentive to anybody trying to run a private registry. If ARIN allows buyers and sellers to trade for money without a needs requirement, and doesn't gouge on pricing, what is the incentive to do business with a private registry? Tom, I appreciate the change in the subject line, but my time really is taken up with explaining my proposal which has no connection with private registries, and I don't care about them enough to spend time on this, to my mind, side issue. If you can connect the dots for me and explain why we are talking about registries in the context of my proposal to drop needs requirements for transfers, then I am happy to continue it now. My prior expressed support for private registries related to my desire to free the transfer market from the artificial constraint of needs requirements for transfers. I saw private registries as a means to dropping needs requirements, as I doubt a private registry would apply a needs requirement. Since I have decided to work to change ARIN's policies in this regard, the continued talk of private registries is a continued distraction. Regards, Mike From joelja at bogus.com Fri May 13 16:01:35 2011 From: joelja at bogus.com (Joel Jaeggli) Date: Fri, 13 May 2011 13:01:35 -0700 Subject: [arin-ppml] Just a reminder of some quick mathematics for IPv4 that shows the long term impossibility of it In-Reply-To: References: <4DCC41D8.1010305@ipinc.net> <4DCD52DB.2080209@bogus.com> Message-ID: <4DCD8E1F.50104@bogus.com> On 5/13/11 11:30 AM, William Herrin wrote: > Joel, > > In 1971, Ehrlich predicted a maximum sustainable world population of > 1.2 billion people. By 1994 Ehrlich raised the estimate to 2 billion > saying, "the present population of 5.5 billion [..] has clearly > exceeded the capacity of Earth to sustain it." Two decades later we're > closing in on 7 billion actual souls the overwhelming majority of > which are not expected to starve to death or otherwise suffer drastic > harm due to insufficient planetary carrying capacity. humans are allocated from a finite but quite large pool of oxygen carbon hydrogen nitrogen and trace elements. we're not facing exhaustion pressure of the building blocks. > Don't be an Ehrlich, a population alarmist. NAT has scalability issues > but with more than a decade's experience, we know what they are. NAT > readily and cost-effectively scales the address-to-user ratio by at > least two orders of magnitude (100x), more than enough for the 4x > increase in Internet usage minimally needed to bring the rest of the > world online. the machines will outnumber the humans by a couple of orders of magnitude > Not rocket science indeed. > > Don't get me wrong: there are lots of good reasons why we -shouldn't- > build out the Internet to 7B people using IPv4. Excellent reasons to > push for IPv6 as our growth path instead. But the claim that IPv4 use > -can't- expand via NAT is purely specious. can't and have no interest in paying for it to do so are not the same thing. besides you said can't, not I. > I'm tired of hearing that > outrageous claim from people who should know better. Makes you look > like idiots and (annoyingly) distracts from the topics then under > discussion. > > Regards, > Bill Herrin > > > From owen at delong.com Fri May 13 16:06:52 2011 From: owen at delong.com (Owen DeLong) Date: Fri, 13 May 2011 13:06:52 -0700 Subject: [arin-ppml] Draft Proposal 2011-1 - Comments request - Globally Coordinated Transfer Policy In-Reply-To: References: Message-ID: <3E888370-C93A-431D-B862-14DF01BF27CD@delong.com> On May 13, 2011, at 11:12 AM, Martin Hannigan wrote: > On Fri, May 13, 2011 at 1:30 PM, Owen DeLong wrote: >>> >>>> 2. If objections exist, to succinctly identify what they are..and, >>> >>> The references to RFC 2050 which in the last 6 months has enjoyed >>> almost universal agreement that it's not relevant; it was written in >>> 1996 in a time and place that is far different than today, it was a >>> Best *Current* Practice (emphasis added) "BCP". >>> >> >> Just because you keep saying this doesn't make it true. I have only >> heard a small handful of people argue that RFC 2050 is not relevant. >> The vast majority of the community seems to still believe that it is. > > And just because you keep saying that it's not true doesn't mean that > it's not. There's ample evidence supporting my claim including > activity at the ICANN ASO AC and NRO NC to deprecate it. That kinda > sorta speaks pretty loudly. There has also been plenty of discussion > here with most agreeing that it's "outdated". Please, feel free to > demonstrate that it's relevant in some way. > The fact that there is activity (and not action) is not an indication that there is widespread consensus, merely evidence that it is under consideration. I do not interpret the discussion the way you do. I don't see most people as saying that it is outdated. I see a vocal handful of people saying it is outdated and most people saying nothing or agreeing that it is not. > >> >>> >>> Finally, how is this proposal being coordinated globally? >>> >> >> I believe the beauty of this particular proposal is that it does not >> need to be. It spells out a way in which other RIRs can pass >> compatible policies which would allow ARIN to approve >> such transfers. > > > That means it will be mostly incompatible with the intent of global > coordination. I suggest we remove the coordinated part and simply call > it inter-RIR transfer process. It doesnt require global adoption nor > ICANN approval as far as I can tell. I have no problem with changing the title accordingly, but, I think the title is a no-op anyway. It does not say coordinated anywhere in the policy text. Owen From hannigan at gmail.com Fri May 13 16:23:16 2011 From: hannigan at gmail.com (Martin Hannigan) Date: Fri, 13 May 2011 16:23:16 -0400 Subject: [arin-ppml] Draft Proposal 2011-1 - Comments request - Globally Coordinated Transfer Policy In-Reply-To: <3E888370-C93A-431D-B862-14DF01BF27CD@delong.com> References: <3E888370-C93A-431D-B862-14DF01BF27CD@delong.com> Message-ID: On Fri, May 13, 2011 at 4:06 PM, Owen DeLong wrote: > > On May 13, 2011, at 11:12 AM, Martin Hannigan wrote: > >> On Fri, May 13, 2011 at 1:30 PM, Owen DeLong wrote: >>>> >>>>> 2. If objections exist, to succinctly identify what they are..and, >>>> >>>> The references to RFC 2050 which in the last 6 months has enjoyed >>>> almost universal agreement that it's not relevant; it was written in >>>> 1996 in a time and place that is far different than today, it was a >>>> Best *Current* Practice (emphasis added) "BCP". >>>> >>> >>> Just because you keep saying this doesn't make it true. I have only >>> heard a small handful of people argue that RFC 2050 is not relevant. >>> The vast majority of the community seems to still believe that it is. >> >> And just because you keep saying that it's not true doesn't mean that >> it's not. There's ample evidence supporting my claim including >> activity at the ICANN ASO AC and NRO NC to deprecate it. That kinda >> sorta speaks pretty loudly. There has also been plenty of discussion >> here with most agreeing that it's "outdated". Please, feel free to >> demonstrate that it's relevant in some way. >> > The fact that there is activity (and not action) is not an indication that > there is widespread consensus, merely evidence that it is under > consideration. The only reason that there isn't any action is that it isnt required. "B C P". Best, -M< From tedm at ipinc.net Fri May 13 17:03:06 2011 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Fri, 13 May 2011 14:03:06 -0700 Subject: [arin-ppml] Just a reminder of some quick mathematics for IPv4that shows the long term impossibility of it In-Reply-To: <714BA22421E941B68BE3268E21738D09@mike> References: <4DCC41D8.1010305@ipinc.net> <714BA22421E941B68BE3268E21738D09@mike> Message-ID: <4DCD9C8A.1030701@ipinc.net> On 5/13/2011 10:39 AM, Mike Burns wrote: > > Hi Owen, > >>> >> Does a rat who has lived its entire life in a cage realize it is in a >> cage? >> > > I took a population of ad libitum "rats" and put them to this very test. > I had about 100 or so DSL users who reprsented normal business and > residential use. > The used to each get a routable IPv4 address from a DHCP pool. > Then I switched them to CGN and waited for complaints, upon which I > would have switched back. > I waited and waited. There were no complaints. > It's been three years no and counting, they are still on CGN, and they > are YouTubers, gamers, P2P participants, Skype users. > > Continuing to call CGN a nightmare looks ludicrous to me. > I would say in your case that it IS a nightmare. It's a financial nightmare. Did the CGN box you put in save you money? It seems to me that it did not. It seems to me you spend a lot of money 3 years ago to do this and that expense did nothing to get you more revenue. It seems to me that if you HADN'T spent the money on the CGN box that you would still have those same 100 customers today, you would have the last 3 years * 100 in revenue from them - you just wouldn't have the loss of money you spent on the CGN box. Without a financial analysis to go along with your statement, you really aren't seeing the entire picture. With IPv6 we can do the shift from IPv4 to IPv6 by simply LEAVING ALONE all existing IPv4 customers and doing the work of shifting to IPv6 with the NEW customers. Then the revenue from the existing customers pays for the labor to add customers. Since after all you already have to to the work of adding the NEW customers to your network because you have to add network to your network, your spending money. That is Business 101. With the CGN way you have to go back to your revenue producers - your existing 100 customers - and do the work to shift them over even if all your doing is reworking your existing network. While you are doing that your incurring labor costs that have to be paid, and your going to pay them with revenue from the existing 100 and you won't be able to pay to add new customers. I know of no business that makes money by continually spending money on it's infrastructure and getting nothing back. All profitable businesses I've ever seen expect that for every dollar they spend they get 2 customer dollars back. They also expect to use the infrastructure for many years. They can do that with IPv6 by leaving IPv4 alone and just adding new customers with IPv6. > >> Just because they haven't actually experienced the internet and have been >> fooled into believing what they have is access to the internet does not >> make the claim any more accurate. >> >> As I said, they don't have internet access. They have a controlled >> and limited subset of the features that define internet access. >> >> The internet is a peer-to-peer network where each system has a >> globally unique potentially reachable address and can operate >> as both client and server. Machines behind a NAT have access >> to only a subset of those defining features. >> >> Owen >> > > > Think about the etymology of the word Internet for a moment. It was > designed as a network of networks, not a single Layer2 network. > End-to-end addressability was not a goal of the founders of the > Internet, it was network-to-network reachability. Incorrect. I was around back then and the goal WAS end-to-end reachability. The difference was that hosts then had lots of users connected to them with RS232 terminals. > In fact, the era of end-to-end for the Internet was the limited > timeframe between popular acceptance and NAT. Wrong because most people back then dialed in with a modem using a terminal emulator program. The first connectivity was e-mail gateways between the Internet and BBS networks like FidoNet. The WWW came about later and it still wasn't that interesting until pretty late in the 90's, around 96-97. And NAT came about when most home users were still using dialup to connect to the Internet. > Most people would fear to put a real IP address on a computer today, I > know that I would. > I use Logmein from behind NAT to address another computer behind another > NAT. logmein is not free for business use so your probably violating TOS. And if you paid for it why should everyone else in the world pay that company? Remote Desktop is free for business and personal use and does not require some wacky active x control or java applet to run in a browser. So is VNC. both of these are also faster. > Rendezvous servers exist for that purpose, and the market favors them. > Holding on to some dream of complete end-to-end reachability leaves out > the inevitable firewall application between them in any case. > Juniper and Cisco have enabled CGN on their big iron boxes, do you think > they are unaware of the nightmarish negative impact of CGN you ascribe? > They OFFER CGN on their big iron they don't "enable" it, the admin has to configure it for it to be enabled. And naturally they don't mind if an admin does because they get to sell them more hardware that way. Ted > Regards, > Mike > > _______________________________________________ > 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 Fri May 13 17:31:36 2011 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Fri, 13 May 2011 14:31:36 -0700 Subject: [arin-ppml] Just a reminder of some quick mathematics for IPv4 that shows the long term impossibility of it In-Reply-To: References: <4DCC41D8.1010305@ipinc.net> <4DCD52DB.2080209@bogus.com> Message-ID: <4DCDA338.7020706@ipinc.net> On 5/13/2011 11:30 AM, William Herrin wrote: > On Fri, May 13, 2011 at 11:48 AM, Joel Jaeggli wrote: >> On 5/13/11 6:30 AM, William Herrin wrote: >>> On Thu, May 12, 2011 at 7:44 PM, Owen DeLong wrote: >>>> On May 12, 2011, at 3:46 PM, William Herrin wrote: >>>>> On Thu, May 12, 2011 at 4:23 PM, Ted Mittelstaedt wrote: >>>>>> So how exactly do we get the other 4.5 billion people on the Internet >>>>>> using IPv4? >>>>> >>>>> Survey says: NAT. >>>> >>>> That does not put the other 4.5 billion people on the internet. >>> >>> The half billion or so who've joined the Internet behind NATs this >>> past decade seem to think differently. Who am I to disagree with them? >>> Who are you. >> >> There are enough ip's for all the nats to site behind either, it's not >> rocket science... maintaining large numbers of parallel addressing >> planes the require state-management for egress has a real cost and those >> things have nothing like the scaling properties of the stateless v4 >> internet you grew up with. > > Joel, > > In 1971, Ehrlich predicted a maximum sustainable world population of > 1.2 billion people. By 1994 Ehrlich raised the estimate to 2 billion > saying, "the present population of 5.5 billion [..] has clearly > exceeded the capacity of Earth to sustain it." Two decades later we're > closing in on 7 billion actual souls the overwhelming majority of > which are not expected to starve to death or otherwise suffer drastic > harm due to insufficient planetary carrying capacity. > However we are quickly depleting our energy reserves and once they are gone we WILL see some drastic harm to a lot of things particularly food. I suppose 100 years from now when your hamburger looks like a garden burger and tastes like something almost but entirely unlike real beef, and if you get a piece of steak it's comprised of compressed plankton and food coloring and artificial flavoring, you will be happy enough to have something to eat. You might not even notice since only extremely wealthy will be able to afford the real thing, you probably won't have ever tasted it. But I for one think that's a sad way for most of the people in the world to live. > Don't be an Ehrlich, a population alarmist. NAT has scalability issues > but with more than a decade's experience, we know what they are. NAT > readily and cost-effectively scales the address-to-user ratio by at > least two orders of magnitude (100x), more than enough for the 4x > increase in Internet usage minimally needed to bring the rest of the > world online. > > Not rocket science indeed. > Getting from here to there is the issue. > Don't get me wrong: there are lots of good reasons why we -shouldn't- > build out the Internet to 7B people using IPv4. Excellent reasons to > push for IPv6 as our growth path instead. But the claim that IPv4 use > -can't- expand via NAT is purely specious. You have it backwards, Bill, the claim that it CAN allow the rest of the world to get online is what is specious. To do it requires the existing Internet give up a huge amount of public numbers and your assuming those numbers will be given up when the reality is that they won't be. > I'm tired of hearing that > outrageous claim from people who should know better. Makes you look > like idiots and (annoyingly) distracts from the topics then under > discussion. > All I'll say is that yes, your right in that IN THEORY if everyone used CGN then we would get the rest of the world online with IPv4. But everyone isn't going to want to use CGN and unless they do, it won't work to get the rest of the world online. So in the reality that most people live in, the claim that NAT won't work is absolutely true. In theory if everyone agreed that war was bad and to not do it, all wars would go away. Ted > Regards, > Bill Herrin > > > From bill at herrin.us Fri May 13 18:08:11 2011 From: bill at herrin.us (William Herrin) Date: Fri, 13 May 2011 18:08:11 -0400 Subject: [arin-ppml] Draft Proposal 2011-1 - Comments request - Globally Coordinated Transfer Policy In-Reply-To: References: Message-ID: On Tue, May 10, 2011 at 1:34 PM, Bill Darte wrote: > The policy text reviewed at the meeting was as follows: > Any RIR's resource registrant may transfer IPv4 addresses to the resource > registrant of another RIR as long as the two RIRs agree and maintain > compatible, needs-based transfer policies that exercise Internet stewardship > consistent with the values expressed in RFC2050. > > 1. Identify support or objection Hi Bill, Oppose. > 2. If objections exist, to succinctly identify what they are..and, a. I'm not convinced we should be contemplating inter-region transfers prior to ARIN's free pool exhausting. b. I'm not convinced *any* of the 5 RIRs adhere to RFC2050's "values" except in a very loose way... which makes it a weak and subjective place to hang a policy. > 3. How objections might be concisely remedied in text "ARIN shall permit the transfer of IPv4 addresses between ARIN registrants and registrants of other RIRs provided that: a. Both ARIN and the other RIR agree to the transfer, b. ARIN and the other RIR have functionally reciprocal inter-region transfer policies, and c. Both the offering and receiving registrants qualify for the transfer under ARIN's normal intra-region resource transfer policies save that one of the registrants is not in the ARIN region and will therefore not be under contract to ARIN." Regards, Bill Herrin -- 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 13 18:46:18 2011 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Fri, 13 May 2011 18:46:18 -0400 Subject: [arin-ppml] Draft Proposal 2011-1 - Comments request - Globally Coordinated Transfer Policy In-Reply-To: References: Message-ID: On Fri, May 13, 2011 at 6:08 PM, William Herrin wrote: > On Tue, May 10, 2011 at 1:34 PM, Bill Darte wrote: >> The policy text reviewed at the meeting was as follows: >> Any RIR's resource registrant may transfer IPv4 addresses to the resource >> registrant of another RIR as long as the two RIRs agree and maintain >> compatible, needs-based transfer policies that exercise Internet stewardship >> consistent with the values expressed in RFC2050. >> >> 1. Identify support or objection > > Hi Bill, > > Oppose. > >> 2. If objections exist, to succinctly identify what they are..and, > > a. I'm not convinced we should be contemplating inter-region transfers > prior to ARIN's free pool exhausting. > b. I'm not convinced *any* of the 5 RIRs adhere to RFC2050's "values" > except in a very loose way... which makes it a weak and subjective > place to hang a policy. > > >> 3. How objections might be concisely remedied in text > > "ARIN shall permit the transfer of IPv4 addresses between ARIN > registrants and registrants of other RIRs provided that: > > a. Both ARIN and the other RIR agree to the transfer, > b. ARIN and the other RIR have functionally reciprocal inter-region > transfer policies, and > c. Both the offering and receiving registrants qualify for the > transfer under ARIN's normal intra-region resource transfer policies > save that one of the registrants is not in the ARIN region and will > therefore not be under contract to ARIN." > > 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. > I strongly oppose any measure that would open the doors to ARIN resources flowing outside of ARIN. -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications - AS32421 First and Leading in DDoS Protection Solutions From mike at nationwideinc.com Fri May 13 20:49:37 2011 From: mike at nationwideinc.com (Mike Burns) Date: Fri, 13 May 2011 20:49:37 -0400 Subject: [arin-ppml] Just a reminder of some quick mathematicsfor IPv4that shows the long term impossibility of it References: <4DCC41D8.1010305@ipinc.net> <714BA22421E941B68BE3268E21738D09@mike> <4DCD9C8A.1030701@ipinc.net> Message-ID: Hi Ted and thanks for the financial concern, > I would say in your case that it IS a nightmare. It's a financial > nightmare. > > Did the CGN box you put in save you money? It seems to me that it > did not. It seems to me you spend a lot of money 3 years ago to do > this and that expense did nothing to get you more revenue. It seems > to me that if you HADN'T spent the money on the CGN box that you > would still have those same 100 customers today, you would have the > last 3 years * 100 in revenue from them - you just wouldn't have the > loss of money you spent on the CGN box. I had redundant CGN boxes running Mikrotik. Those are really cheap. Remember this was a test for my personal edification. I had plenty of IP addresses available to me. In fact, upon any complaint I judged to be CGN related, they would have had a real ip back in minutes. I was suprised that the one guy who needed inbound access accepted a static port without question. > > Incorrect. I was around back then and the goal WAS end-to-end > reachability. The difference was that hosts then had lots of > users connected to them with RS232 terminals. Ted, I was around, too. I had an ARPANET account at Brookhaven National Labs in 1978. There were many operating systems running the hosts on the ARPANET, the goal was end-to-end communication among researchers, basically. I don't want to continue this minor digression, though, so I will concede the point. > >> In fact, the era of end-to-end for the Internet was the limited >> timeframe between popular acceptance and NAT. > > Wrong because most people back then dialed in with a modem using > a terminal emulator program. The first connectivity was e-mail > gateways between the Internet and BBS networks like FidoNet. > The WWW came about later and it still wasn't that interesting until > pretty late in the 90's, around 96-97. And NAT came about when > most home users were still using dialup to connect to the Internet. That's what I meant to write. Things got interesting in the mid-90s. NAT came out shortly thereafter. NAT ended the end-to-end connectivity thing. And yet the Internet exploded in size. Dialup was not really end-to-end because there weren't fixed IP addresses, so not many were hosting servers on dialup. (I know there were exceptions, I once got a /24 with a dialup account back in 1995.) > >> Most people would fear to put a real IP address on a computer today, I >> know that I would. >> I use Logmein from behind NAT to address another computer behind another >> NAT. > > logmein is not free for business use so your probably violating TOS. I don't remember saying I used the free one. > And if you paid for it why should everyone else in the world pay > that company? Remote Desktop is free for business and personal use > and does not require some wacky active x control or java applet to > run in a browser. So is VNC. both of these are also faster. > I use both of these products, too. I started with Carbon Copy over modems. Full disclosure: I have done some consulting for Logmein. In the real world I use Logmein for instances behind NAT. It's especially valuable for the rapid setup of remote support because it does not require firewall changes. People are willing to pay for that ability, according to their success in the market. >> Rendezvous servers exist for that purpose, and the market favors them. >> Holding on to some dream of complete end-to-end reachability leaves out >> the inevitable firewall application between them in any case. >> Juniper and Cisco have enabled CGN on their big iron boxes, do you think >> they are unaware of the nightmarish negative impact of CGN you ascribe? >> > > They OFFER CGN on their big iron they don't "enable" it, the admin > has to configure it for it to be enabled. And naturally they don't mind > if an admin does because they get to sell them more hardware that way. > > Ted Well, we won't have to wait too much longer to see who is correct in their appraisal of the perils of CGN. I assume somebody paid the coders at Cisco to write the CGN code. I doubt that would have happened if Cisco's research showed customers would reject it. Regards, Mike From owen at delong.com Fri May 13 21:41:16 2011 From: owen at delong.com (Owen DeLong) Date: Fri, 13 May 2011 18:41:16 -0700 Subject: [arin-ppml] Just a reminder of some quick mathematicsfor IPv4that shows the long term impossibility of it In-Reply-To: References: <4DCC41D8.1010305@ipinc.net> <714BA22421E941B68BE3268E21738D09@mike> <4DCD9C8A.1030701@ipinc.net> Message-ID: >> >>> In fact, the era of end-to-end for the Internet was the limited >>> timeframe between popular acceptance and NAT. >> >> Wrong because most people back then dialed in with a modem using >> a terminal emulator program. The first connectivity was e-mail >> gateways between the Internet and BBS networks like FidoNet. >> The WWW came about later and it still wasn't that interesting until >> pretty late in the 90's, around 96-97. And NAT came about when >> most home users were still using dialup to connect to the Internet. > > That's what I meant to write. Things got interesting in the mid-90s. > NAT came out shortly thereafter. NAT ended the end-to-end connectivity thing. > And yet the Internet exploded in size. > Dialup was not really end-to-end because there weren't fixed IP addresses, so not many were hosting servers on dialup. > (I know there were exceptions, I once got a /24 with a dialup account back in 1995.) > This does not prove NAT is wonderful or that end-to-end is not useful or necessary. It proves that a lot of people faced with the choice between NAT and nothing chose NAT over non-connection. This is akin to facing a choice between food poisoning and cancer. The obvious choice is food poisoning, but, most people would prefer to avoid both. >> >>> Most people would fear to put a real IP address on a computer today, I >>> know that I would. >>> I use Logmein from behind NAT to address another computer behind another >>> NAT. >> >> logmein is not free for business use so your probably violating TOS. > > I don't remember saying I used the free one. > End-to-end addresses mean I don't have to pay someone else just to provide a rendezvous server so I can reach my own stuff. It also means I can connect to my own stuff without subjecting my access to such a man-in-the-middle attack or the additional latency and/or risks associated with doing so. I really don't see any reason I would want to move from globally addressable systems to systems behind such a rendezvous mechanism. Can you point to any single advantage of doing so? >> And if you paid for it why should everyone else in the world pay >> that company? Remote Desktop is free for business and personal use >> and does not require some wacky active x control or java applet to >> run in a browser. So is VNC. both of these are also faster. >> > I use both of these products, too. Not with the target behind a NAT, you don't. > I started with Carbon Copy over modems. LoL... I remember those days. Not all that fondly. > Full disclosure: I have done some consulting for Logmein. Ah, so you have a somewhat vested interest in the success of this arguably unnecessary (if we had end-to-end) business model. > In the real world I use Logmein for instances behind NAT. In the real world, I keep my systems globally accessible. I just don't see any advantage to doing otherwise. > It's especially valuable for the rapid setup of remote support because it does not require firewall changes. > People are willing to pay for that ability, according to their success in the market. > People are willing to accept all kinds of bad engineering and pay for workarounds to resolve the issues they create. For example, look at the number of people that bought Windows 3.1 and then paid third parties for IP software, anti-virus software, firewall software, shells that didn't crash all the time, memory managers, etc. Each of those things is arguably a simple deficiency in the original Windows product and a feature that was included in the basic expectations of virtually every other operating system available at the time. Just as network access services provided without a globally unique address can be worked around through things like back2mymac and other rendezvous services. However, those services would be utterly unnecessary with a proper globally unique address. > >>> Rendezvous servers exist for that purpose, and the market favors them. >>> Holding on to some dream of complete end-to-end reachability leaves out >>> the inevitable firewall application between them in any case. >>> Juniper and Cisco have enabled CGN on their big iron boxes, do you think >>> they are unaware of the nightmarish negative impact of CGN you ascribe? >>> >> >> They OFFER CGN on their big iron they don't "enable" it, the admin >> has to configure it for it to be enabled. And naturally they don't mind >> if an admin does because they get to sell them more hardware that way. >> >> Ted > > Well, we won't have to wait too much longer to see who is correct in their appraisal of the perils of CGN. Indeed. I suspect that carriers in Asia will be forced to implement at least some LSN very soon. Unfortunately, users in Asia are generally used to a much lower level of service quality than even users in the US, so, that may not be an entirely valid datapoint. > I assume somebody paid the coders at Cisco to write the CGN code. As near as I can tell, most of the LSN code in the Cisco gateways is the same as their standard NAT code that's been in their routers for quite some time. Since IOS tends to be the kitchen sink of all kinds of features anyone imagined someone might ever want, I wouldn't take that as too much of an indication as to market demand. After all, IOS still contained support for Banyan until not all that long ago. In fact, I don't know for sure that it has been retired yet. > I doubt that would have happened if Cisco's research showed customers would reject it. > I'm sure, as I said, that Cisco's research showed that some carriers would need it. There is a huge difference between needing to do something and wanting to do it or considering it desirable. The number of IPv4-only devices in the consumer electronics product space that will not be upgraded before IPv4 runout alone means that even consumers placed on primarily IPv6 services are going to need some level of IPv4 connectivity solution for some time. Those consumers will be subjected to LSN because there is literally no other viable option. LSN isn't a feature, it's a workaround for alack of viable options due to the constraints of time combined with a global lack of preparedness and progress. Owen From mysidia at gmail.com Fri May 13 22:02:40 2011 From: mysidia at gmail.com (Jimmy Hess) Date: Fri, 13 May 2011 21:02:40 -0500 Subject: [arin-ppml] ARIN-prop-150 Reclamation Hold In-Reply-To: <4DCD36FC.3000501@arin.net> References: <4DCD36FC.3000501@arin.net> Message-ID: On Fri, May 13, 2011 at 8:49 AM, ARIN wrote: > ARIN-prop-150 Reclamation Hold I am in favor of a brief reclamation hold. I am opposed to this proposal, because the duration is unreasonably long, and by being unreasonably long it thwarts the benefit of reclamation. This is like baking a pie, and deciding to let it sit out to cool for 90 days before eating, so as to avoid the undesirable consequence of burning your mouth. The problem is the wait is excessive, and when it finally lapses, you will find it moldy and its usefulness expired before anyone could eat it. Early re-use of resources can have some undesirable consequences; however, not having sufficient resources can also have some undesirable consequences. > Add a new section to the NRPM: > "All resources reclaimed by ARIN shall not be returned to the free pool > or otherwise reassigned to any entity than the original registrant for a > period of 36 months." I would favor a rule that IP addresses may be held after reclamation, but before becoming eligible for reassignment at the discretion of ARIN staff, no less than 90 days, and no more than 270 days. With the understanding that long hold periods are for IP addresses which are reclaimed after involuntary revokation, lack of use, hijacking, etc. And short hold periods are to be used for voluntarily returned resources. For example "return and renumber" deals. > As the pressures on the system become greater with IPv4 runout, there > will be more call for ARIN to reclaim address space. When addresses that > are reclaimed are reused too soon, a variety of undesirable outcomes may > result. This provides sufficient time for the resources to go unused If they are not used soon enough, a variety of undesirable outcomes may result (unavailability of IP addresses). > prior to reassignment and/or to be re-justified by the original > registrant, or returned to the proper holder in the case of hijackings. The concept of applying a hold here, is counter to the goal of network stability; in case of hijackings, the return to the proper holder should be as soon as possible, if there is one. > This policy could be restricted to IPv4 space, but it may be useful for > AS numbers and has no major impact on IPv6 space (due to the large free > pool), so it might as well apply to all. I would support a 18 month hold on reclaimed AS numbers and an indefinite hold on reclaimed IPv6 space. AS-numbers are not likely to be exhausted; so it makes sense to hold them longer, to avoid any possible confusion. Unless there is a shortage, or ARIN needs more IPv6 resources, the community should consider every properly obtained IPv6 allocation permanent, to keep things simple. Reclamation efforts there (at this time) would just be unnecessary/wasteful labor > Timetable for implementation: immediate -- -JH From matthew at matthew.at Fri May 13 22:09:48 2011 From: matthew at matthew.at (Matthew Kaufman) Date: Fri, 13 May 2011 19:09:48 -0700 Subject: [arin-ppml] ARIN-prop-150 Reclamation Hold In-Reply-To: References: <4DCD36FC.3000501@arin.net> Message-ID: <4DCDE46C.5010509@matthew.at> On 5/13/2011 7:02 PM, Jimmy Hess wrote: > > If they are not used soon enough, a variety of undesirable outcomes may > result (unavailability of IP addresses). > Reclamation isn't going to solve anyone's IP address shortage unless ARIN gets too aggressive about it. > > The concept of applying a hold here, is counter to the goal of network > stability; > in case of hijackings, the return to the proper holder should be as > soon as possible, > if there is one. > Agreed. This proposal doesn't suggest that the proper holder should have any delay in return. Matthew Kaufman From vixie at isc.org Sat May 14 00:11:41 2011 From: vixie at isc.org (Paul Vixie) Date: Sat, 14 May 2011 04:11:41 +0000 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate In-Reply-To: (Mike Burns's message of "Thu, 12 May 2011 11:43:56 -0400") References: <7F5FC4554E42430FADDC0D376164DFA0@mike> <0BB63D56-1605-4E1E-8F0B-B2083FDE4A96@delong.com> <16AACD9632484C85BF6B855603CF07B4@mike> <4294678C-B653-4BB3-9D40-FD935EA00CF3@eyeconomics.com> Message-ID: mike at nationwideinc.com ("Mike Burns") writes: > From the article: > > "ICANN requires registrars to enforce the accuracy of their customers' > Whois records, and the leading registrars are often quite strict about > complying with this rule." > > So if ICANN already requires this and fails to police it, why do you > assume that ICANN would police their own records if private registrars > did not exist? i make no claim nor ever meant to imply that icann should take action with respect to number resource whois. i was answering your statement that the dns private market is working. my assertion is that the dns private market as it is currently does not disincentivise sociopathic behaviour. at scale (and with a lot of money at stake) such behaviour becomes the norm unless opposed by some regime or force. for examples, the tradeoff between accurate whois and making a lot of money, or the tradeoff between conserving routing table slots and making a lot of money, are decisions that the whole community or their representatives would make differently than would most individuals. the short version is, i don't think the private dns market is your best or most shining example of what to hope for from a private numbering resource market. i don't think Garda Sichana's Michael Moran would think so either (referring to the "theregister" URL included below for reference.) re: > mike at nationwideinc.com ("Mike Burns") writes: > >> As far as the DNS private market goes, I don't see the problem with it. > > From: "Paul Vixie" > >> see http://www.theregister.co.uk/2011/03/17/child_abuse_cop_slams_icann/ >> with raw data at . >> >> internet resource holders (whether names or numbers) will *not* show more >> accountability than is required of them by the rest of us. -- Paul Vixie KI6YSY From mike at nationwideinc.com Sat May 14 07:49:22 2011 From: mike at nationwideinc.com (Mike Burns) Date: Sat, 14 May 2011 07:49:22 -0400 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate References: <7F5FC4554E42430FADDC0D376164DFA0@mike><0BB63D56-1605-4E1E-8F0B-B2083FDE4A96@delong.com><16AACD9632484C85BF6B855603CF07B4@mike><4294678C-B653-4BB3-9D40-FD935EA00CF3@eyeconomics.com> Message-ID: <66B385600617480F838FCB79BF50FAAE@video> Paul, I understand you don't like the private DNS structure, but how does that relate to my proposal? My statement that I think the private DNS is working was not related to my proposal, it was just a personal impression from my own personal experience in the DNS market, which includes transactions stretching from 1995 until today, and includes running production DNS servers throughout those years. I have never made a proposal related to private registries, I am not interested in talking about private registries in the context of this thread. Although I supported the idea of a decision on allowing private IP registries for the purposes of creating a freer trade in IP addresses, I decided that the same purpose could be served by modifying ARIN policy to allow needs-free transfers. The talk about DNS registries is a side matter, unless you can relate them to my proposal. I never held the DNS model as a "best or most shining example of what to hope for from a private numbering resource market". I'm not even proposing a private numbering resource market. Regards, Mike ----- Original Message ----- From: "Paul Vixie" To: Sent: Saturday, May 14, 2011 12:11 AM Subject: Re: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate > mike at nationwideinc.com ("Mike Burns") writes: > >> From the article: >> >> "ICANN requires registrars to enforce the accuracy of their customers' >> Whois records, and the leading registrars are often quite strict about >> complying with this rule." >> >> So if ICANN already requires this and fails to police it, why do you >> assume that ICANN would police their own records if private registrars >> did not exist? > > i make no claim nor ever meant to imply that icann should take action with > respect to number resource whois. i was answering your statement that the > dns private market is working. my assertion is that the dns private > market > as it is currently does not disincentivise sociopathic behaviour. at > scale > (and with a lot of money at stake) such behaviour becomes the norm unless > opposed by some regime or force. for examples, the tradeoff between > accurate > whois and making a lot of money, or the tradeoff between conserving > routing > table slots and making a lot of money, are decisions that the whole > community > or their representatives would make differently than would most > individuals. > > the short version is, i don't think the private dns market is your best or > most shining example of what to hope for from a private numbering resource > market. i don't think Garda Sichana's Michael Moran would think so either > (referring to the "theregister" URL included below for reference.) > > re: > >> mike at nationwideinc.com ("Mike Burns") writes: >> >>> As far as the DNS private market goes, I don't see the problem with it. >> >> From: "Paul Vixie" >> >>> see http://www.theregister.co.uk/2011/03/17/child_abuse_cop_slams_icann/ >>> with raw data at . >>> >>> internet resource holders (whether names or numbers) will *not* show >>> more >>> accountability than is required of them by the rest of us. > -- > Paul Vixie > KI6YSY > _______________________________________________ > 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 BillD at cait.wustl.edu Sat May 14 08:30:42 2011 From: BillD at cait.wustl.edu (Bill Darte) Date: Sat, 14 May 2011 07:30:42 -0500 Subject: [arin-ppml] Draft Proposal 2011-1 - Comments request - Globally Coordinated Transfer Policy References: Message-ID: Thanks Bill. This is excellent feedback and gives a very concise starting point for more discussion. Others? Please follow's Bill's lead here. For or Against...as is What could be improved with the original...or Bill's very understandable alternative. Thanks to all, bd- ________________________________ From: wherrin at gmail.com on behalf of William Herrin Sent: Fri 5/13/2011 5:08 PM To: Bill Darte Cc: arin ppml Subject: Re: [arin-ppml] Draft Proposal 2011-1 - Comments request - Globally Coordinated Transfer Policy On Tue, May 10, 2011 at 1:34 PM, Bill Darte wrote: > The policy text reviewed at the meeting was as follows: > Any RIR's resource registrant may transfer IPv4 addresses to the resource > registrant of another RIR as long as the two RIRs agree and maintain > compatible, needs-based transfer policies that exercise Internet stewardship > consistent with the values expressed in RFC2050. > > 1. Identify support or objection Hi Bill, Oppose. > 2. If objections exist, to succinctly identify what they are..and, a. I'm not convinced we should be contemplating inter-region transfers prior to ARIN's free pool exhausting. b. I'm not convinced *any* of the 5 RIRs adhere to RFC2050's "values" except in a very loose way... which makes it a weak and subjective place to hang a policy. > 3. How objections might be concisely remedied in text "ARIN shall permit the transfer of IPv4 addresses between ARIN registrants and registrants of other RIRs provided that: a. Both ARIN and the other RIR agree to the transfer, b. ARIN and the other RIR have functionally reciprocal inter-region transfer policies, and c. Both the offering and receiving registrants qualify for the transfer under ARIN's normal intra-region resource transfer policies save that one of the registrants is not in the ARIN region and will therefore not be under contract to ARIN." Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 -------------- next part -------------- An HTML attachment was scrubbed... URL: From BillD at cait.wustl.edu Sat May 14 08:33:59 2011 From: BillD at cait.wustl.edu (Bill Darte) Date: Sat, 14 May 2011 07:33:59 -0500 Subject: [arin-ppml] Draft Proposal 2011-1 - Comments request - Globally Coordinated Transfer Policy References: Message-ID: Thanks Jeffrey, So, you believe that all legacy space originally captured within the ARIN db to be 'ARIN Resources'? And, if any of that space were to come available while there is need within ARIN it should be used in the ARIN region....even if there is need outside the ARIN region as well? And, if the resources were to come available and there was ONLY need outside the ARIN region, (however unlikely), then the resources should be HELD against future ARIN need, even though there was need outside of ARIN region? bd ________________________________ From: jeffrey.lyon at gmail.com on behalf of Jeffrey Lyon Sent: Fri 5/13/2011 5:46 PM To: William Herrin Cc: Bill Darte; arin ppml Subject: Re: [arin-ppml] Draft Proposal 2011-1 - Comments request - Globally Coordinated Transfer Policy On Fri, May 13, 2011 at 6:08 PM, William Herrin wrote: > On Tue, May 10, 2011 at 1:34 PM, Bill Darte wrote: >> The policy text reviewed at the meeting was as follows: >> Any RIR's resource registrant may transfer IPv4 addresses to the resource >> registrant of another RIR as long as the two RIRs agree and maintain >> compatible, needs-based transfer policies that exercise Internet stewardship >> consistent with the values expressed in RFC2050. >> >> 1. Identify support or objection > > Hi Bill, > > Oppose. > >> 2. If objections exist, to succinctly identify what they are..and, > > a. I'm not convinced we should be contemplating inter-region transfers > prior to ARIN's free pool exhausting. > b. I'm not convinced *any* of the 5 RIRs adhere to RFC2050's "values" > except in a very loose way... which makes it a weak and subjective > place to hang a policy. > > >> 3. How objections might be concisely remedied in text > > "ARIN shall permit the transfer of IPv4 addresses between ARIN > registrants and registrants of other RIRs provided that: > > a. Both ARIN and the other RIR agree to the transfer, > b. ARIN and the other RIR have functionally reciprocal inter-region > transfer policies, and > c. Both the offering and receiving registrants qualify for the > transfer under ARIN's normal intra-region resource transfer policies > save that one of the registrants is not in the ARIN region and will > therefore not be under contract to ARIN." > > 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. > I strongly oppose any measure that would open the doors to ARIN resources flowing outside of ARIN. -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications - AS32421 First and Leading in DDoS Protection Solutions -------------- next part -------------- An HTML attachment was scrubbed... URL: From jeffrey.lyon at blacklotus.net Sat May 14 08:54:04 2011 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Sat, 14 May 2011 08:54:04 -0400 Subject: [arin-ppml] Draft Proposal 2011-1 - Comments request - Globally Coordinated Transfer Policy In-Reply-To: References: Message-ID: On Sat, May 14, 2011 at 8:33 AM, Bill Darte wrote: > Thanks Jeffrey, > > So, you believe that all legacy space originally captured within the ARIN db > to be 'ARIN Resources'?? And, if any of that space were to come available > while there is need within ARIN it should be used in the ARIN region....even > if there is need outside the ARIN region as well? > > And, if the resources were to come available and there was ONLY need outside > the ARIN region, (however unlikely), then the resources should be HELD > against future ARIN need, even though there was need outside of ARIN region? > > bd > ________________________________ > From: jeffrey.lyon at gmail.com on behalf of Jeffrey Lyon > Sent: Fri 5/13/2011 5:46 PM > To: William Herrin > Cc: Bill Darte; arin ppml > Subject: Re: [arin-ppml] Draft Proposal 2011-1 - Comments request - Globally > Coordinated Transfer Policy > > On Fri, May 13, 2011 at 6:08 PM, William Herrin wrote: >> On Tue, May 10, 2011 at 1:34 PM, Bill Darte wrote: >>> The policy text reviewed at the meeting was as follows: >>> Any RIR's resource registrant may transfer IPv4 addresses to the resource >>> registrant of another RIR as long as the two RIRs agree and maintain >>> compatible, needs-based transfer policies that exercise Internet >>> stewardship >>> consistent with the values expressed in RFC2050. >>> >>> 1. Identify support or objection >> >> Hi Bill, >> >> Oppose. >> >>> 2. If objections exist, to succinctly identify what they are..and, >> >> a. I'm not convinced we should be contemplating inter-region transfers >> prior to ARIN's free pool exhausting. >> b. I'm not convinced *any* of the 5 RIRs adhere to RFC2050's "values" >> except in a very loose way... which makes it a weak and subjective >> place to hang a policy. >> >> >>> 3. How objections might be concisely remedied in text >> >> "ARIN shall permit the transfer of IPv4 addresses between ARIN >> registrants and registrants of other RIRs provided that: >> >> a. Both ARIN and the other RIR agree to the transfer, >> b. ARIN and the other RIR have functionally reciprocal inter-region >> transfer policies, and >> c. Both the offering and receiving registrants qualify for the >> transfer under ARIN's normal intra-region resource transfer policies >> save that one of the registrants is not in the ARIN region and will >> therefore not be under contract to ARIN." >> >> 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. >> > > I strongly oppose any measure that would open the doors to ARIN > resources flowing outside of ARIN. > > -- > Jeffrey Lyon, Leadership Team > jeffrey.lyon at blacklotus.net | http://www.blacklotus.net > Black Lotus Communications - AS32421 > First and Leading in DDoS Protection Solutions > Bill, My position is that the elected officials of ARIN are accountable to ARIN region and should only be concerned with securing resources for use within ARIN. As a practical matter, every region is going to have need far beyond supply but I am not comfortable with any policy which would open the door to a decision that somehow another region's need is more important. -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications - AS32421 First and Leading in DDoS Protection Solutions From fw at deneb.enyo.de Sat May 14 10:11:51 2011 From: fw at deneb.enyo.de (Florian Weimer) Date: Sat, 14 May 2011 16:11:51 +0200 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate In-Reply-To: <7F5FC4554E42430FADDC0D376164DFA0@mike> (Mike Burns's message of "Wed, 11 May 2011 14:03:02 -0400") References: <7F5FC4554E42430FADDC0D376164DFA0@mike> Message-ID: <87wrht1ie0.fsf@mid.deneb.enyo.de> * Mike Burns: > Conditions on source of the transfer: > > - The source entity must be the current rights 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 the transfer, or until the exhaustion of ARIN's > IPv4 space, whichever occurs first. > > - The source entity must not have received an allocation from ARIN for the 12 months prior to the transfer. Again, this looks like a backdoor for inter-registry transfers. Please add a requirement the adress space must be under RSA and not within the responsibility of other RIRs. From tedm at ipinc.net Sat May 14 10:56:06 2011 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Sat, 14 May 2011 07:56:06 -0700 Subject: [arin-ppml] Just a reminder of some quick mathematicsfor IPv4that shows the long term impossibility of it In-Reply-To: References: <4DCC41D8.1010305@ipinc.net> <714BA22421E941B68BE3268E21738D09@mike> <4DCD9C8A.1030701@ipinc.net> Message-ID: <4DCE9806.4010206@ipinc.net> On 5/13/2011 5:49 PM, Mike Burns wrote: > Hi Ted and thanks for the financial concern, > >> I would say in your case that it IS a nightmare. It's a financial >> nightmare. >> >> Did the CGN box you put in save you money? It seems to me that it >> did not. It seems to me you spend a lot of money 3 years ago to do >> this and that expense did nothing to get you more revenue. It seems >> to me that if you HADN'T spent the money on the CGN box that you >> would still have those same 100 customers today, you would have the >> last 3 years * 100 in revenue from them - you just wouldn't have the >> loss of money you spent on the CGN box. > > I had redundant CGN boxes running Mikrotik. > Those are really cheap. > Remember this was a test for my personal edification. > I had plenty of IP addresses available to me. > In fact, upon any complaint I judged to be CGN related, they would have > had a real ip back in minutes. > I was suprised that the one guy who needed inbound access accepted a > static port without question. > Maybe all your 100 customers already switched to IPv6 and didn't care about IPv4? ;-) But it is easy to be responsive when you have just 1 guy out of 100 who needed a static port map. I don't see large ISPs who are a lot less customer responsive wanting to increase their support burden. And, incidentally, for that static port map to work, you have to statically assign him an IP number, thus he isn't dynamically assigned anymore. Thus you have to start changing your network around. And what if 1/2 of the 100 were businesses that had their own mailservers and needed port 25 mapped to them? None of this is very scalable. >> >> Incorrect. I was around back then and the goal WAS end-to-end >> reachability. The difference was that hosts then had lots of >> users connected to them with RS232 terminals. > > Ted, I was around, too. I had an ARPANET account at Brookhaven National > Labs in 1978. > There were many operating systems running the hosts on the ARPANET, the > goal was end-to-end communication among researchers, basically. > I don't want to continue this minor digression, though, so I will > concede the point. > >> >>> In fact, the era of end-to-end for the Internet was the limited >>> timeframe between popular acceptance and NAT. >> >> Wrong because most people back then dialed in with a modem using >> a terminal emulator program. The first connectivity was e-mail >> gateways between the Internet and BBS networks like FidoNet. >> The WWW came about later and it still wasn't that interesting until >> pretty late in the 90's, around 96-97. And NAT came about when >> most home users were still using dialup to connect to the Internet. > > That's what I meant to write. Things got interesting in the mid-90s. > NAT came out shortly thereafter. NAT ended the end-to-end connectivity > thing. No, actually it didn't. The reason why is that the NAT's were at the customer site. So if the customer wanted e2e for a specific application, like e-mail, they could add a port map or whatever to their NAT without involving the ISP. That is close enough to real e2e that it is, as the line goes "good enough for government work" > And yet the Internet exploded in size. > Dialup was not really end-to-end because there weren't fixed IP > addresses, so not many were hosting servers on dialup. > (I know there were exceptions, I once got a /24 with a dialup account > back in 1995.) Central Point Software had one of those from PSInet on a 9600bps Telebit Trailblazer around that time I think. > >> >>> Most people would fear to put a real IP address on a computer today, I >>> know that I would. >>> I use Logmein from behind NAT to address another computer behind another >>> NAT. >> >> logmein is not free for business use so your probably violating TOS. > > I don't remember saying I used the free one. > >> And if you paid for it why should everyone else in the world pay >> that company? Remote Desktop is free for business and personal use >> and does not require some wacky active x control or java applet to >> run in a browser. So is VNC. both of these are also faster. >> > I use both of these products, too. > I started with Carbon Copy over modems. > Full disclosure: I have done some consulting for Logmein. > In the real world I use Logmein for instances behind NAT. > It's especially valuable for the rapid setup of remote support because > it does not require firewall changes. > People are willing to pay for that ability, according to their success > in the market. > IT support orgs are forced to pay for it because of NAT. That's not "willing". > >>> Rendezvous servers exist for that purpose, and the market favors them. >>> Holding on to some dream of complete end-to-end reachability leaves out >>> the inevitable firewall application between them in any case. >>> Juniper and Cisco have enabled CGN on their big iron boxes, do you think >>> they are unaware of the nightmarish negative impact of CGN you ascribe? >>> >> >> They OFFER CGN on their big iron they don't "enable" it, the admin >> has to configure it for it to be enabled. And naturally they don't mind >> if an admin does because they get to sell them more hardware that way. >> >> Ted > > Well, we won't have to wait too much longer to see who is correct in > their appraisal of the perils of CGN. > I assume somebody paid the coders at Cisco to write the CGN code. > I doubt that would have happened if Cisco's research showed customers > would reject it. > With Cisco it isn't about whether or not a feature is present, it's about whether or not a feature that is present is free of enough bugs to be usable. They didn't get IPv6 support fixed in integrated routing and bridging until IOS 15.0 that's been almost 15 years since they first claimed "IPv6 support" in IOS. You may think it's a minor issue but any ISP that delivers bridged DSL with Cisco routers was affected. And if Cisco was so good why are you using Mikrotik? > Regards, > Mike > One last thing to consider: Do you think ISP's delivering CGN will never deliver IPv6 dual-stack to their customers? Because once they start delivering IPv6 then the customers have e2e - over the IPv6 network. Thus, any problems with a CGN IPv4 connectivity will be solvable by just doing the e2e over IPv6. That's kind of like saying your broken-down '56 Ford truck is still on the road because you bought a trailer for it and tow it around everywhere... Ted From vixie at isc.org Sat May 14 12:58:30 2011 From: vixie at isc.org (Paul Vixie) Date: Sat, 14 May 2011 16:58:30 +0000 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate In-Reply-To: Your message of "Sat, 14 May 2011 07:49:22 -0400." <66B385600617480F838FCB79BF50FAAE@video> References: <7F5FC4554E42430FADDC0D376164DFA0@mike><0BB63D56-1605-4E1E-8F0B-B2083FDE4A96@delong.com><16AACD9632484C85BF6B855603CF07B4@mike><4294678C-B653-4BB3-9D40-FD935EA00CF3@eyeconomics.com> <66B385600617480F838FCB79BF50FAAE@video> Message-ID: <87735.1305392310@nsa.vix.com> > From: "Mike Burns" > Date: Sat, 14 May 2011 07:49:22 -0400 > > I understand you don't like the private DNS structure, but how does > that relate to my proposal? obliquely. i'm asking that you not try to justify a private numbering resources market using the private dns market as a "success" example. > My statement that I think the private DNS is working was not related > to my proposal, it was just a personal impression from my own personal > experience in the DNS market, which includes transactions stretching > from 1995 until today, and includes running production DNS servers > throughout those years. i'm certain that many personal experiences match yours. however, these positive personal experiences have come at the community's expense. i have heard it called "the chemical polluter business model" where as long as you're not downstream you're probably doing well or at least OK. > I have never made a proposal related to private registries, I am not > interested in talking about private registries in the context of this > thread. ah, ok, then i misunderstood the original reference to which i replied. > Although I supported the idea of a decision on allowing private IP > registries for the purposes of creating a freer trade in IP addresses, > I decided that the same purpose could be served by modifying ARIN > policy to allow needs-free transfers. that's an entirely different kettle of trouble. non-needs-based means that commercial investment techniques such as speculation, hoarding, price manipulation, and everything else that Enron had going during the california energy market deregulation crisis of the previous decade are on the table. i'd much prefer to avoid that kind of crisis for Internet numbering resources. in fact even a steady state non-crisis in which the prices operators pay for resources are in any way controlled by profit-seeking non-operators would be an unfavourable change. > The talk about DNS registries is a side matter, unless you can relate > them to my proposal. I never held the DNS model as a "best or most > shining example of what to hope for from a private numbering resource > market". I'm not even proposing a private numbering resource market. noted. however, we may still be in disagreement, though on a new basis. From mueller at syr.edu Sat May 14 15:56:53 2011 From: mueller at syr.edu (Milton L Mueller) Date: Sat, 14 May 2011 15:56:53 -0400 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate In-Reply-To: References: <7F5FC4554E42430FADDC0D376164DFA0@mike> <0BB63D56-1605-4E1E-8F0B-B2083FDE4A96@delong.com> <16AACD9632484C85BF6B855603CF07B4@mike> <4294678C-B653-4BB3-9D40-FD935EA00CF3@eyeconomics.com> Message-ID: <75822E125BCB994F8446858C4B19F0D717305182F0@SUEX07-MBX-04.ad.syr.edu> Paul, Whatever the problems that exist in DNS, they are problems that are both solvable and can be reasonably expected from scaling up a domain name distribution system thousands of times, from a few hundred thousand domains to a multiple hundreds of millions. Let's not also recall that the massive reduction in price and massive increase in scale and expansion would be considered a net gain by any unbiased observer. The proper benchmark for comparison of DNS and IP address reform is not your romantic, idealized notions of a communitarian utopia, but the actual system of monopoly and unprofessional and unscalable institutions that existed 15 years ago. Let's return then to 1996 and the NSI monopoly, which, as I recall, was something that frustrated a certain Mr. Vixie so much that he was ready to split the root. Are you proposing that we should not have started charging fees for a domain name registration? Are you proposing that we should not have separated registries from registrars, and therefore continue the monopoly of one registry? Are you suggesting that the backlogs and shortages that occurred under the monopoly were better than things are now? Are you suggesting that the process of giving users online and direct control of their accounts was not a huge win for users? Are you proposing that registries should not have relaxed their policies to allow individuals to register the names they want with fewer restrictions? Are you suggesting that the many country code TLDs that liberalized their policies in imitation of the success of gTLDs should not have done so? Are you proposing that we should not have had a formal, governmentally-mediated reform/privatization process and instead left things in the henads of one man and his personal network of friends and colleagues to set policy for the whole DNS? --MM > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf Of Paul Vixie > Sent: Saturday, May 14, 2011 12:12 AM > To: arin-ppml at arin.net > Subject: Re: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois > Accurate > > mike at nationwideinc.com ("Mike Burns") writes: > > > From the article: > > > > "ICANN requires registrars to enforce the accuracy of their customers' > > Whois records, and the leading registrars are often quite strict about > > complying with this rule." > > > > So if ICANN already requires this and fails to police it, why do you > > assume that ICANN would police their own records if private registrars > > did not exist? > > i make no claim nor ever meant to imply that icann should take action > with respect to number resource whois. i was answering your statement > that the dns private market is working. my assertion is that the dns > private market as it is currently does not disincentivise sociopathic > behaviour. at scale (and with a lot of money at stake) such behaviour > becomes the norm unless opposed by some regime or force. for examples, > the tradeoff between accurate whois and making a lot of money, or the > tradeoff between conserving routing table slots and making a lot of > money, are decisions that the whole community or their representatives > would make differently than would most individuals. > > the short version is, i don't think the private dns market is your best > or most shining example of what to hope for from a private numbering > resource market. i don't think Garda Sichana's Michael Moran would > think so either (referring to the "theregister" URL included below for > reference.) > > re: > > > mike at nationwideinc.com ("Mike Burns") writes: > > > >> As far as the DNS private market goes, I don't see the problem with > it. > > > > From: "Paul Vixie" > > > >> see > >> http://www.theregister.co.uk/2011/03/17/child_abuse_cop_slams_icann/ > >> with raw data at . > >> > >> internet resource holders (whether names or numbers) will *not* show > >> more accountability than is required of them by the rest of us. > -- > Paul Vixie > KI6YSY > _______________________________________________ > 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 cgrundemann at gmail.com Sat May 14 19:26:57 2011 From: cgrundemann at gmail.com (Chris Grundemann) Date: Sat, 14 May 2011 17:26:57 -0600 Subject: [arin-ppml] Draft Proposal 2011-1 - Comments request - Globally Coordinated Transfer Policy In-Reply-To: References: Message-ID: On Fri, May 13, 2011 at 09:13, Martin Hannigan wrote: > On Tue, May 10, 2011 at 1:34 PM, Bill Darte wrote: >> The policy text reviewed at the meeting was as follows: >> Any RIR's resource registrant may transfer IPv4 addresses to the resource >> registrant of another RIR as long as the two RIRs agree and maintain >> compatible, needs-based transfer policies that exercise Internet stewardship >> consistent with the values expressed in RFC2050. >> *************** >> 2. If objections exist, to succinctly identify what they are..and, > > The references to RFC 2050 which in the last 6 months has enjoyed > almost universal agreement that it's not relevant; it was written in > 1996 in a time and place that is far different than today, it was a > Best *Current* Practice (emphasis added) "BCP". Comments: 1) There is nothing remotely close to "universal agreement that [RFC 2050] not relevant. 2) The reference is actually to the /values expressed in RFC 2050/ not to the entirety of the text of the RFC. Questions: 1) Why has your mind changed since you and Jason and I wrote this policy text? 2) I take the values expressed in RFC 2050 to be summarized quite nicely as goals in the introduction: Internet address space is distributed according to the following three goals: 1) Conservation: Fair distribution of globally unique Internet address space according to the operational needs of the end-users and Internet Service Providers operating networks using this address space. Prevention of stockpiling in order to maximize the lifetime of the Internet address space. 2) Routability: Distribution of globally unique Internet addresses in a hierarchical manner, permitting the routing scalability of the addresses. This scalability is necessary to ensure proper operation of Internet routing, although it must be stressed that routability is in no way guaranteed with the allocation or assignment of IPv4 addresses. 3) Registration: Provision of a public registry documenting address space allocation and assignment. This is necessary to ensure uniqueness and to provide information for Internet trouble shooting at all levels. Which of those goals/values do you believe to be no longer relevant to Internet number stewardship and why? Cheers, ~Chris > Best, > > -M< > _______________________________________________ > 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 weblog.chrisgrundemann.com www.burningwiththebush.com www.theIPv6experts.net www.coisoc.org From owen at delong.com Sun May 15 00:34:08 2011 From: owen at delong.com (Owen DeLong) Date: Sat, 14 May 2011 21:34:08 -0700 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate In-Reply-To: <75822E125BCB994F8446858C4B19F0D717305182F0@SUEX07-MBX-04.ad.syr.edu> References: <7F5FC4554E42430FADDC0D376164DFA0@mike> <0BB63D56-1605-4E1E-8F0B-B2083FDE4A96@delong.com> <16AACD9632484C85BF6B855603CF07B4@mike> <4294678C-B653-4BB3-9D40-FD935EA00CF3@eyeconomics.com> <75822E125BCB994F8446858C4B19F0D717305182F0@SUEX07-MBX-04.ad.syr.edu> Message-ID: <0C1D40FF-F036-4066-B018-1ED20509B213@delong.com> On May 14, 2011, at 12:56 PM, Milton L Mueller wrote: > Paul, > Whatever the problems that exist in DNS, they are problems that are both solvable and can be reasonably expected from scaling up a domain name distribution system thousands of times, from a few hundred thousand domains to a multiple hundreds of millions. Let's not also recall that the massive reduction in price and massive increase in scale and expansion would be considered a net gain by any unbiased observer. Actually, I'd rather pay $30-50/year for my domain names and have a system that wasn't tied up in WIPO's idea of trademark mapping, didn't have the spammer coefficient and toxic polluter models that are present in todays registry structures, and had a higher level of due diligence. I don't think that is a particularly biased perspective. I'll also note that until they are free, there is not even an equal price to where I started, let alone a massive reduction. Much of the massive expansion is a net gain. Much of it is not. > > The proper benchmark for comparison of DNS and IP address reform is not your romantic, idealized notions of a communitarian utopia, but the actual system of monopoly and unprofessional and unscalable institutions that existed 15 years ago. We can agree to disagree here. Prior to the awarding of the contract to NSI, I got very good service from SRI. > > Let's return then to 1996 and the NSI monopoly, which, as I recall, was something that frustrated a certain Mr. Vixie so much that he was ready to split the root. Let's return, instead, to the SRI days since I believe that to be a vastly superior comparison. > > Are you proposing that we should not have started charging fees for a domain name registration? I'm not sure whether this improved things or not. I do know that abandoning the one-org-one-domain structure and adding trademarks to the mix in place of first-come-first-serve was not an improvement. > Are you proposing that we should not have separated registries from registrars, and therefore continue the monopoly of one registry? Again, I'm uncertain. However, I'm not sure that's a significant factor one way or the other. The problem was the elimination of a global set of policies based on one-org-one-domain and first-come-first-served allocations of domain names that were desired by more than one person. The involvement of WIPO and overloading of the DNS namespace with trademark issues further degraded the situation. > Are you suggesting that the backlogs and shortages that occurred under the monopoly were better than things are now? Care to explain that allegation? The longest I ever waited on a request from NSI was 5-7 days in the very early days before they implemented automation. With SRI, it was more like 1-3 days. I'm not sure what you mean by a shortage. We have more shortages now by any definition I could apply to that term due to the low price and ease of domain squatting. > Are you suggesting that the process of giving users online and direct control of their accounts was not a huge win for users? I think this would have happened even if SRI was still in control. I think that was the inevitable progress of automation more than it relates to any of the changes you mention above. > Are you proposing that registries should not have relaxed their policies to allow individuals to register the names they want with fewer restrictions? Absolutely!! > Are you suggesting that the many country code TLDs that liberalized their policies in imitation of the success of gTLDs should not have done so? The ccTLDs were always subject to whatever policies the applicable nation's government chose to apply to them, so, I really don't see that as part of the discussion. > Are you proposing that we should not have had a formal, governmentally-mediated reform/privatization process and instead left things in the henads of one man and his personal network of friends and colleagues to set policy for the whole DNS? I don't really agree with your characterization of the SRI and NSI operated NICs, but, even if I did, I would say that he and his friends did a better job of administering it in the interest of the global community than this government mediated system has. Owen > > --MM > >> -----Original Message----- >> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On >> Behalf Of Paul Vixie >> Sent: Saturday, May 14, 2011 12:12 AM >> To: arin-ppml at arin.net >> Subject: Re: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois >> Accurate >> >> mike at nationwideinc.com ("Mike Burns") writes: >> >>> From the article: >>> >>> "ICANN requires registrars to enforce the accuracy of their customers' >>> Whois records, and the leading registrars are often quite strict about >>> complying with this rule." >>> >>> So if ICANN already requires this and fails to police it, why do you >>> assume that ICANN would police their own records if private registrars >>> did not exist? >> >> i make no claim nor ever meant to imply that icann should take action >> with respect to number resource whois. i was answering your statement >> that the dns private market is working. my assertion is that the dns >> private market as it is currently does not disincentivise sociopathic >> behaviour. at scale (and with a lot of money at stake) such behaviour >> becomes the norm unless opposed by some regime or force. for examples, >> the tradeoff between accurate whois and making a lot of money, or the >> tradeoff between conserving routing table slots and making a lot of >> money, are decisions that the whole community or their representatives >> would make differently than would most individuals. >> >> the short version is, i don't think the private dns market is your best >> or most shining example of what to hope for from a private numbering >> resource market. i don't think Garda Sichana's Michael Moran would >> think so either (referring to the "theregister" URL included below for >> reference.) >> >> re: >> >>> mike at nationwideinc.com ("Mike Burns") writes: >>> >>>> As far as the DNS private market goes, I don't see the problem with >> it. >>> >>> From: "Paul Vixie" >>> >>>> see >>>> http://www.theregister.co.uk/2011/03/17/child_abuse_cop_slams_icann/ >>>> with raw data at . >>>> >>>> internet resource holders (whether names or numbers) will *not* show >>>> more accountability than is required of them by the rest of us. >> -- >> Paul Vixie >> KI6YSY >> _______________________________________________ >> PPML >> You are receiving this message because you are subscribed to the ARIN >> Public Policy Mailing List (ARIN-PPML at arin.net). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/arin-ppml >> Please contact info at arin.net if you experience any issues. > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From hannigan at gmail.com Sun May 15 10:55:19 2011 From: hannigan at gmail.com (Martin Hannigan) Date: Sun, 15 May 2011 10:55:19 -0400 Subject: [arin-ppml] Draft Proposal 2011-1 - Comments request - Globally Coordinated Transfer Policy In-Reply-To: References: Message-ID: On Sat, May 14, 2011 at 7:26 PM, Chris Grundemann wrote: > On Fri, May 13, 2011 at 09:13, Martin Hannigan wrote: > >> On Tue, May 10, 2011 at 1:34 PM, Bill Darte wrote: > >>> The policy text reviewed at the meeting was as follows: >>> Any RIR's resource registrant may transfer IPv4 addresses to the resource >>> registrant of another RIR as long as the two RIRs agree and maintain >>> compatible, needs-based transfer policies that exercise Internet stewardship >>> consistent with the values expressed in RFC2050. >>> *************** > > >>> 2. If objections exist, to succinctly identify what they are..and, >> >> The references to RFC 2050 which in the last 6 months has enjoyed >> almost universal agreement that it's not relevant; it was written in >> 1996 in a time and place that is far different than today, it was a >> Best *Current* Practice (emphasis added) "BCP". > > > Comments: > 1) There is nothing remotely close to "universal agreement that [RFC > 2050] not relevant. Feel free to demonstrate otherwise. So far, I count two denying that and what appears to be significant opposition to the proposal at large. I don't see any value in engaging in any discussion arguing for or against any language around 2050, rather it would be more effective to find more appropriate language reconciling the issue to move the concept forward. Feel free to make a suggestion. Best, -M< From tvest at eyeconomics.com Sun May 15 11:34:24 2011 From: tvest at eyeconomics.com (Tom Vest) Date: Sun, 15 May 2011 11:34:24 -0400 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate In-Reply-To: <4CEC4E334DBD4D1CBE15A0E208FD55A0@mike> References: <7F5FC4554E42430FADDC0D376164DFA0@mike><0BB63D56-1605-4E1E-8F0B-B2083FDE4A96@delong.com><16AACD9632484C85BF6B855603CF07B4@mike><4294678C-B653-4BB3-9D40-FD935EA00CF3@eyeconomics.com> <6332CACB-1F07-4036-AC1E-FE9CF448DE82@eyeconomics.com> <707022CC-A086-4FF6-B42C-8D8DA581367D@delong.com> <4CEC4E334DBD4D1CBE15A0E208FD55A0@mike> Message-ID: On May 12, 2011, at 1:26 PM, Mike Burns wrote: > Hi Owen, >> >>> I still don't see the connection between my proposal to drop needs requirements for transfers and the participation rate of DNS whois or the UK land office. >>> I may be missing something obvious, though. >> > >> I believe he is arguing that if you turn address policy into a free-for-all (as in your proposal), like >> DNS, it will decrease, rather than increase whois accuracy. I hadn't thought of this consequence, but, >> now that Tom and Paul have brought it up, it does make sense. > > > I am still missing the connection between removing needs requirements for transfers and having that decrease whois accuracy. > If you can connect the dots, you will go a long way in convincing me that my proposal is flawed. Hi Mike, Again, apologies for the delayed response. I tried to clarify the connection in my message of May 13, 2011 12:04:39 PM EDT (specifically, @ bullet points 3 and esp. 4). But that was a long message that also covered several other reasons why the so-called "needs" (which IMO should be "capability") requirement is important which are completely independent of its relevance to whois accuracy, and perhaps I wasn't clear enough on the specific one that interests you. Basically, the need/capability test facilitates the ongoing maintenance/preservation of whois accuracy because it assures that each subsequent allocation/assignment (and in the future, each transfer transaction) will trigger the same kind of "moment of controlled disclosure" that occurs when a new entity joins an RIR and/or requests an initial allocation. As a group, network operators -- and esp. growing ones -- undergo the sort of internal changes (e.g., reorgs, relocations, new sites, new non-M&A commercial partnerships, et al.) that can trigger changes in their external contact details fairly frequently. For all sorts of reasons that are mostly banal (oversights, procrastination, impatience with "bureaucracy," miscommunication, someone else's job, thought they were already informed, etc.), the RIRs don't always "get the memo" at the time when such changes occur -- or even afterward, during subsequent "casual" interactions. Absent other countervailing factors, such changes would cause the overall quality of registration data to degrade progressively over time, with the more dynamic/faster growing networks typically leading the way down. What prevents (or at least substantially mitigates) this progressive decay is the policy-mandated needs/capability test requirement. That requirement assures that each subsequent interaction between registrants and the RIR that could materially alter the distribution of IP number resources *will not* be "casual" in the above sense, but rather will (typically) involve some presentation of documents which illustrate the existence and size of the new addressing requirements. The review of such materials -- which frequently include invoices for new network-related assets or similar documents that show buyer address and other contact info -- provides a formal opportunity for RIR and registrant representatives to make sure that they're on the same page with respect to all current contact information. So, to put this explicitly in the context of your proposal: The exhaustion of the unallocated IPv4 pool is not going to reduce the frequency with which address registrants undergo the sort of internal changes that can make some or all of their current whois contact details outdated -- if anything it might make those changes happen more frequently. Thus, in order for whois data quality to be preserved going forward at (at least) current accuracy levels, the current practice of making each subsequent address-related transaction subject to a mandatory needs/capability capability review must continue. In order for your proposal to have *any chance at all* of causing a net improvement in whois data quality, the number of future Pv4 transfer seekers that are x: (NOT current RSA signatories + NOT willing/able to undergo a need/capability test + ARE certain to self-maintain the quality of their own whois information at historically unprecedented high levels in perpetuity) ...would have to exceed the sum of other kinds of future address seekers, including those who are: y: (NOT current RSA signatories + ARE willing/able to undergo a need/capability test + NOT certain to self-maintain the quality of their own whois information at historically unprecedented high levels in perpetuity) z: (ARE current RSA signatories + (n/a) + NOT certain to self-maintain the quality of their own whois information at historically unprecedented high levels in perpetuity) Logically, the universe of potential future address seekers is complete characterized by (x + y + z) as described above, plus two other groups that, hypothetically, wouldn't be affected either way by your proposal: Incorrigibles: (NOT signatories + NOT willing + NOT self-maintaining) Saints: (ARE signatories + (n/a)+ ARE self-maintaining) [Note: I say "hypothetically" above because I actually believe that the adoption of this policy would undermine an existing community "norm" of whois participation that currently contributes to "irrationally" high data quality across current registrants -- and as a result your policy would cause average levels of whois "self-maintenance" to decline across all groups. But that possibility is not factored into this analysis] Assuming that "saints" and "incorrigibles" would be equally represented across both current ARIN members/RSA signatories and future address seekers (and excluding any possible "normative" affects), your proposal would only be net positive at the point where ((non-Saint, non-Incorrigible x)) exceeds (non-Saint, non-Incorrigible (y+z)). Given the size of the current ARIN membership, the only way this pans out in your favor if 90%+ of current members and 90%+ of future address seekers actually fall into the "Saint" or "Incorrigible" category. But of course, this assumption would also mean that your policy (and all policies, more-or-less) are almost complete irrelevant. Happily, I believe that those demographic assumption are grossly inconsistent with both RIR administrative experience and with the documented record of RIR community-policy interactions over the last 20 years. Hence, I am opposed. TV >>> My whole goal is to increase accuracy in Whois, and I am not relying on any financial or price mechanism for that increase. >> > >> And now there is evidence that your proposal would likely have the opposite effect. > > What evidence? > >>> I have not argued that pricing will increase registration, I have argued that pricing will ensure productive use. >> > >> Which also remains in dispute and unproven. >> Owen > > Hence the word argued. > > > Regards, > Mike From cgrundemann at gmail.com Sun May 15 11:52:10 2011 From: cgrundemann at gmail.com (Chris Grundemann) Date: Sun, 15 May 2011 09:52:10 -0600 Subject: [arin-ppml] Draft Proposal 2011-1 - Comments request - Globally Coordinated Transfer Policy In-Reply-To: References: Message-ID: On Sun, May 15, 2011 at 08:55, Martin Hannigan wrote: > to find more appropriate language reconciling the issue to move the > concept forward. Feel free to make a suggestion. Inter-Regional Transfer Policy Any ARIN resource registrant may transfer IPv4 addresses to the resource registrant of another RIR as long as the two RIRs agree and maintain compatible, needs-based transfer policies that exercise Internet stewardship and the values of Conservation, Routability and Registration as described in RFC2050. > Best, > > -M< > -- @ChrisGrundemann weblog.chrisgrundemann.com www.burningwiththebush.com www.theIPv6experts.net www.coisoc.org From hannigan at gmail.com Sun May 15 11:57:49 2011 From: hannigan at gmail.com (Martin Hannigan) Date: Sun, 15 May 2011 11:57:49 -0400 Subject: [arin-ppml] Draft Proposal 2011-1 - Comments request - Globally Coordinated Transfer Policy In-Reply-To: References: Message-ID: Unfortunately, I'll have to join the growing list of folks not in favor of advancing this proposal further. Best, -M< On 5/15/11, Chris Grundemann wrote: > On Sun, May 15, 2011 at 08:55, Martin Hannigan wrote: > >> to find more appropriate language reconciling the issue to move the >> concept forward. Feel free to make a suggestion. > > Inter-Regional Transfer Policy > > Any ARIN resource registrant may transfer IPv4 addresses to the > resource registrant of another RIR as long as the two RIRs agree and > maintain compatible, needs-based transfer policies that exercise > Internet stewardship and the values of Conservation, Routability and > Registration as described in RFC2050. > >> Best, >> >> -M< >> > > > > -- > @ChrisGrundemann > weblog.chrisgrundemann.com > www.burningwiththebush.com > www.theIPv6experts.net > www.coisoc.org > From cgrundemann at gmail.com Sun May 15 12:26:57 2011 From: cgrundemann at gmail.com (Chris Grundemann) Date: Sun, 15 May 2011 10:26:57 -0600 Subject: [arin-ppml] Draft Proposal 2011-1 - Comments request - Globally Coordinated Transfer Policy In-Reply-To: References: Message-ID: On Sat, May 14, 2011 at 06:54, Jeffrey Lyon wrote: > My position is that the elected officials of ARIN are accountable to > ARIN region and should only be concerned with securing resources for > use within ARIN. As an elected member of the ARIN Advisory Council, I feel compelled to state that while I see myself as accountable directly to the ARIN region (as you state); I completely disagree that means "securing resources for use within ARIN" exclusively and in all cases, particularly when it could/would cause harm to the Internet ecosystem at large. I believe that Internet stability is of utmost importance to everyone I am accountable to and that it is a higher goal than securing IPv4 addresses for them individually (the greater-good vs. individual-need is how I see it). Please feel free not to vote for me the next time around if you disagree. > As a practical matter, every region is going to have need far beyond > supply but I am not comfortable with any policy which would open the > door to a decision that somehow another region's need is more > important. Agreed. We should not put any region's need above that of another. Cheers, ~Chris > -- > Jeffrey Lyon, Leadership Team > jeffrey.lyon at blacklotus.net | http://www.blacklotus.net > Black Lotus Communications - AS32421 > First and Leading in DDoS Protection Solutions > _______________________________________________ > 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 weblog.chrisgrundemann.com www.burningwiththebush.com www.theIPv6experts.net www.coisoc.org From mike at nationwideinc.com Sun May 15 14:13:42 2011 From: mike at nationwideinc.com (Mike Burns) Date: Sun, 15 May 2011 14:13:42 -0400 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate References: <7F5FC4554E42430FADDC0D376164DFA0@mike><0BB63D56-1605-4E1E-8F0B-B2083FDE4A96@delong.com><16AACD9632484C85BF6B855603CF07B4@mike><4294678C-B653-4BB3-9D40-FD935EA00CF3@eyeconomics.com> <6332CACB-1F07-4036-AC1E-FE9CF448DE82@eyeconomics.com> <707022CC-A086-4FF6-B42C-8D8DA581367D@delong.com> <4CEC4E334DBD4D1CBE15A0E208FD55A0@mike> Message-ID: Hi Tom, I don't think we will have to rely on "moments of controlled disclosure" you describe, involving NDA-covered private network information to the local registrar, simply to have accurate contact information. Why? Because proper registration is going to be the effective proof of ownership. As the value of control of IP assets becomes more widely known, and higher, in the face of free pool exhaust, those who control these rights will be motivated by their desire to publicy record their rights in a registry. When addresses are free, conflict over their control is limited, and proof of ownership much less important. When conflict rises, along with value, and there is no tangible "certificate of control", getting the authoritative registry recognition is more important. I believe John Curran referenced an increase in the processing of old 8.2 Transfers, cleaning up old mergers, which I take to be an indication of the motivation I am describing here. Therefore, x: (NOT current RSA signatories + NOT willing/able to undergo a need/capability test + ARE certain to self-maintain the quality of their own whois information at historically unprecedented high levels in perpetuity) is the population I intended to reach with this proposal. They will have every incentive to keep their information registred correctly, if only to increase its resale value. You call them Saints. I call them normal humans who want some evidence of their valuable control rights. All your groups, x,y,and z will likely keep their registration more updated than they have historically as the value of their holdings becomes clearer to all. If I have a new business plan that I am pitching to investors, and if my projected growth plan includes a need for increasing IPv4 addresses over the next 24 months, what do I say to the investor who asks how I will get those addresses and what they will cost? If I could purchase 24 months supply on the transfer market now, but would have to keep ARIN in the dark, and know that I could get the addresses routed by submitting the purchase document to my network provider, why wouldn't I do that, and isn't it clear that Whois accuracy will suffer? Is this situation so unworldly that it can't be envisioned? The sole limitation to getting this transaction registered is the ARIN needs test for transfers. I think it's really quite a stretch to think the needs requirement increases registration accuracy, as you imply. Remember, if ARIN is doing a needs analysis for somebody, it's because they have already been contacted in reference to the desire to have ARIN book a transfer, right? So if they have already done that, why does the needs requirement enchance contact information accuracy? I don't see the logic there. Regards, Mike ----- Original Message ----- From: "Tom Vest" To: "Mike Burns" Cc: "Owen DeLong" ; ; "Paul Vixie" Sent: Sunday, May 15, 2011 11:34 AM Subject: Re: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate On May 12, 2011, at 1:26 PM, Mike Burns wrote: > Hi Owen, >> >>> I still don't see the connection between my proposal to drop needs >>> requirements for transfers and the participation rate of DNS whois or >>> the UK land office. >>> I may be missing something obvious, though. >> > >> I believe he is arguing that if you turn address policy into a >> free-for-all (as in your proposal), like >> DNS, it will decrease, rather than increase whois accuracy. I hadn't >> thought of this consequence, but, >> now that Tom and Paul have brought it up, it does make sense. > > > I am still missing the connection between removing needs requirements for > transfers and having that decrease whois accuracy. > If you can connect the dots, you will go a long way in convincing me that > my proposal is flawed. Hi Mike, Again, apologies for the delayed response. I tried to clarify the connection in my message of May 13, 2011 12:04:39 PM EDT (specifically, @ bullet points 3 and esp. 4). But that was a long message that also covered several other reasons why the so-called "needs" (which IMO should be "capability") requirement is important which are completely independent of its relevance to whois accuracy, and perhaps I wasn't clear enough on the specific one that interests you. Basically, the need/capability test facilitates the ongoing maintenance/preservation of whois accuracy because it assures that each subsequent allocation/assignment (and in the future, each transfer transaction) will trigger the same kind of "moment of controlled disclosure" that occurs when a new entity joins an RIR and/or requests an initial allocation. As a group, network operators -- and esp. growing ones -- undergo the sort of internal changes (e.g., reorgs, relocations, new sites, new non-M&A commercial partnerships, et al.) that can trigger changes in their external contact details fairly frequently. For all sorts of reasons that are mostly banal (oversights, procrastination, impatience with "bureaucracy," miscommunication, someone else's job, thought they were already informed, etc.), the RIRs don't always "get the memo" at the time when such changes occur -- or even afterward, during subsequent "casual" interactions. Absent other countervailing factors, such changes would cause the overall quality of registration data to degrade progressively over time, with the more dynamic/faster growing networks typically leading the way down. What prevents (or at least substantially mitigates) this progressive decay is the policy-mandated needs/capability test requirement. That requirement assures that each subsequent interaction between registrants and the RIR that could materially alter the distribution of IP number resources *will not* be "casual" in the above sense, but rather will (typically) involve some presentation of documents which illustrate the existence and size of the new addressing requirements. The review of such materials -- which frequently include invoices for new network-related assets or similar documents that show buyer address and other contact info -- provides a formal opportunity for RIR and registrant representatives to make sure that they're on the same page with respect to all current contact information. So, to put this explicitly in the context of your proposal: The exhaustion of the unallocated IPv4 pool is not going to reduce the frequency with which address registrants undergo the sort of internal changes that can make some or all of their current whois contact details outdated -- if anything it might make those changes happen more frequently. Thus, in order for whois data quality to be preserved going forward at (at least) current accuracy levels, the current practice of making each subsequent address-related transaction subject to a mandatory needs/capability capability review must continue. In order for your proposal to have *any chance at all* of causing a net improvement in whois data quality, the number of future Pv4 transfer seekers that are x: (NOT current RSA signatories + NOT willing/able to undergo a need/capability test + ARE certain to self-maintain the quality of their own whois information at historically unprecedented high levels in perpetuity) ...would have to exceed the sum of other kinds of future address seekers, including those who are: y: (NOT current RSA signatories + ARE willing/able to undergo a need/capability test + NOT certain to self-maintain the quality of their own whois information at historically unprecedented high levels in perpetuity) z: (ARE current RSA signatories + (n/a) + NOT certain to self-maintain the quality of their own whois information at historically unprecedented high levels in perpetuity) Logically, the universe of potential future address seekers is complete characterized by (x + y + z) as described above, plus two other groups that, hypothetically, wouldn't be affected either way by your proposal: Incorrigibles: (NOT signatories + NOT willing + NOT self-maintaining) Saints: (ARE signatories + (n/a)+ ARE self-maintaining) [Note: I say "hypothetically" above because I actually believe that the adoption of this policy would undermine an existing community "norm" of whois participation that currently contributes to "irrationally" high data quality across current registrants -- and as a result your policy would cause average levels of whois "self-maintenance" to decline across all groups. But that possibility is not factored into this analysis] Assuming that "saints" and "incorrigibles" would be equally represented across both current ARIN members/RSA signatories and future address seekers (and excluding any possible "normative" affects), your proposal would only be net positive at the point where ((non-Saint, non-Incorrigible x)) exceeds (non-Saint, non-Incorrigible (y+z)). Given the size of the current ARIN membership, the only way this pans out in your favor if 90%+ of current members and 90%+ of future address seekers actually fall into the "Saint" or "Incorrigible" category. But of course, this assumption would also mean that your policy (and all policies, more-or-less) are almost complete irrelevant. Happily, I believe that those demographic assumption are grossly inconsistent with both RIR administrative experience and with the documented record of RIR community-policy interactions over the last 20 years. Hence, I am opposed. TV >>> My whole goal is to increase accuracy in Whois, and I am not relying on >>> any financial or price mechanism for that increase. >> > >> And now there is evidence that your proposal would likely have the >> opposite effect. > > What evidence? > >>> I have not argued that pricing will increase registration, I have argued >>> that pricing will ensure productive use. >> > >> Which also remains in dispute and unproven. >> Owen > > Hence the word argued. > > > Regards, > Mike From cgrundemann at gmail.com Sun May 15 15:12:29 2011 From: cgrundemann at gmail.com (Chris Grundemann) Date: Sun, 15 May 2011 13:12:29 -0600 Subject: [arin-ppml] New Version of ARIN-prop-126: Compliance Requirement In-Reply-To: References: Message-ID: On Wed, Apr 20, 2011 at 18:41, Scott Leibrand wrote: > All, > How would you feel about striking the following sentence in 12.6?: "If > progress of resource returns or?record corrections is not visible within > sixty (60) days after correspondence with ARIN began, ARIN will cease > providing reverse DNS?services for the resources in question." > The preceding sentence says that "ARIN may cease providing reverse DNS > services" at any time after 30 days, and the requirement that ARIN > *will*?cease providing reverse DNS after 60 days seems like it would limit > ARIN's ability to do the right thing if an organization is cooperating... > Thoughts? I think that the last sentence already provides this flexibility to ARIN staff: "ARIN shall negotiate a longer term with the organization if ARIN believes the organization is working in good faith to substantially restore compliance and has a valid need for additional time to renumber out of the affected blocks." Do you disagree? At this point, I think there is enough support for this idea that we should move the current text forward to draft status and discuss it in Philly (and on the list before then of course). Those who have not spoken up regarding this proposal are highly encouraged to do so. Thanks, ~Chris (Primary Shepherd, ARIN-prop-126) > -Scott > > On Wed, Feb 16, 2011 at 11:34 AM, Chris Grundemann > wrote: >> >> Hail PPML! >> >> I am the primary AC shepherd for ARIN-prop-126: Compliance Requirement >> and I would like to hear your comments and feedback on this new >> version of the proposal (included below). If the community is happy >> with this text; I will take the necessary steps as shepherd to advance >> it to the next stage of the process, which would be getting the AC to >> promote it to a draft policy (https://www.arin.net/policy/pdp.html). >> >> One thing to note: This proposal updates existing policy and as such >> not all of the text is new or a change. Please review the current >> policy language when evaluating this proposal: >> https://www.arin.net/policy/nrpm.html#twelve. >> >> Thanks in advance for your input! >> >> Cheers, >> ~Chris >> >> #### >> >> ARIN-prop-126: Compliance Requirement >> >> Proposal Originator: Marla Azinger >> >> Proposal Version: 2 >> >> Date: 16 February 2011 >> >> Proposal type: new >> >> Policy term: permanent >> >> Policy statement: >> >> Resource Review >> Update the following NRPM Sections: >> >> 12.4 - Update to: Organizations found by ARIN to be out of compliance >> with current ARIN policy shall be required to update reassignment >> information or return resources as needed to bring them into (or >> reasonably close to) compliance. >> >> 1. The degree to which an organization may remain out of compliance >> shall be based on the reasonable judgment of the ARIN staff and shall >> balance all facts known, including the organization's utilization >> rate, available address pool, and other factors as appropriate so as >> to avoid forcing returns which will result in near-term additional >> requests or unnecessary route de-aggregation. >> 2. To the extent possible, entire blocks should be returned. Partial >> address blocks shall be returned in such a way that the portion >> retained will comprise a single aggregate block. >> >> (leave 12.5 as is) >> >> 12.6 - Update to: Except in cases of fraud, an organization shall be >> given a minimum of thirty (30) days to respond. If an organization >> does not respond within those thirty (30) days, ARIN may cease >> providing reverse DNS services to that organization. If progress of >> resource returns or record corrections is not visible within sixty >> (60) days after correspondence with ARIN began, ARIN will cease >> providing reverse DNS services for the resources in question. At any >> time after ninety (90) days have passed, ARIN may initiate resource >> revocation as allowed in paragraph 12.5. ARIN shall negotiate a longer >> term with the organization if ARIN believes the organization is >> working in good faith to substantially restore compliance and has a >> valid need for additional time to renumber out of the affected blocks. >> >> Rationale: >> >> Version 2 addresses several staff and legal concerns with the original >> text of this policy by clarifying the language and making it more >> concrete. >> >> To date the community has not documented or firmly established use of >> an effective enforcement mechanism. This policy will support current >> policy and compel those who are allocated ARIN resources to maintain >> the proper WHOIS records in accordance with ARIN NRPM. While it is >> recognized this is not an absolute solution to ensure compliance, it >> is the best method under current ARIN policies. >> >> 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. > > -- @ChrisGrundemann weblog.chrisgrundemann.com www.burningwiththebush.com www.theIPv6experts.net www.coisoc.org From cgrundemann at gmail.com Sun May 15 15:41:42 2011 From: cgrundemann at gmail.com (Chris Grundemann) Date: Sun, 15 May 2011 13:41:42 -0600 Subject: [arin-ppml] ARIN-2011-6: Returned IPv4 Addresses - Last Call In-Reply-To: <4DAC8BE4.9060002@arin.net> References: <4DAC8BE4.9060002@arin.net> Message-ID: Hello PPML, As one of the shepherds for 2011-6, I wanted to let you all know that at this point, I plan to make a motion to recommend 2011-6 to the Board for adoption. The AC moved this to last call based on fairly strong community consensus and looking back over the last call thread, I do not see any sign of that changing. Among the replies I see 3 clearly in favor and 2 clearly opposed. The folks opposed appear to oppose the fact that this policy does not block ARIN from ever returning IPv4 addresses to the IANA while the statements of support cited having this not be permanent as a cause for their support. Therefor I believe we have the correct balance and that this important policy should now be moved forward. If you feel strongly about this decision one way or the other, please feel free to voice your opinion before our meeting on Thursday, May 19th. Although the official last call period has ended, I (and very likely all of the AC) will take any comments received into consideration. Cheers, ~Chris On Mon, Apr 18, 2011 at 13:07, ARIN wrote: > The ARIN Advisory Council (AC) met on 13 April 2011 and decided to > send a revised version of the following draft policy to last call: > > ?ARIN-2011-6: Returned IPv4 Addresses > > Feedback is encouraged during the last call period. All comments should > be provided to the Public Policy Mailing List. Last call for 2011-6 will > expire on 2 May 2011. 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-2011-6 > Returned IPv4 Addresses > > Date: 18 April 2011 > > Policy statement: > > 4.1.9 Returned IPv4 Addresses > > Until a global policy which clearly defines a mechanism for the > re-allocation of IPv4 addresses returned to the IANA is adopted by all > five regions and implemented at the IANA which clearly defines a > mechanism for the re-allocation of IPv4 addresses returned to the IANA; > all IPv4 addresses returned to, recovered, or revoked by ARIN will be > made available for allocation or assignment in the ARIN region as > quickly as practicable. > > Rationale: > > Adopting this proposal will result in the clarification of the status of > returned IPv4 addresses. IPv4 address resources should not sit idle due > to lack of policy clarity. > > Timetable for implementation: Immediately > > > _______________________________________________ > 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 weblog.chrisgrundemann.com www.burningwiththebush.com www.theIPv6experts.net www.coisoc.org From fernattj at gmail.com Sun May 15 16:04:13 2011 From: fernattj at gmail.com (Jonathan Fernatt) Date: Sun, 15 May 2011 16:04:13 -0400 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate In-Reply-To: References: <7F5FC4554E42430FADDC0D376164DFA0@mike> <0BB63D56-1605-4E1E-8F0B-B2083FDE4A96@delong.com> <16AACD9632484C85BF6B855603CF07B4@mike> <4294678C-B653-4BB3-9D40-FD935EA00CF3@eyeconomics.com> <6332CACB-1F07-4036-AC1E-FE9CF448DE82@eyeconomics.com> <707022CC-A086-4FF6-B42C-8D8DA581367D@delong.com> <4CEC4E334DBD4D1CBE15A0E208FD55A0@mike> Message-ID: Hi Mike, Wouldn't it be more sensible for the company in question to contract with their upstream ISP for the addressing? Unless your start up is an ISP, wouldn't that be sufficient to start with? Is PI space typically necessary day one? Jon -------------- next part -------------- An HTML attachment was scrubbed... URL: From tvest at eyeconomics.com Sun May 15 16:46:01 2011 From: tvest at eyeconomics.com (Tom Vest) Date: Sun, 15 May 2011 16:46:01 -0400 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate In-Reply-To: References: <7F5FC4554E42430FADDC0D376164DFA0@mike><0BB63D56-1605-4E1E-8F0B-B2083FDE4A96@delong.com><16AACD9632484C85BF6B855603CF07B4@mike><4294678C-B653-4BB3-9D40-FD935EA00CF3@eyeconomics.com> <6332CACB-1F07-4036-AC1E-FE9CF448DE82@eyeconomics.com> <707022CC-A086-4FF6-B42C-8D8DA581367D@delong.com> <4CEC4E334DBD4D1CBE15A0E208FD55A0@mike> Message-ID: On May 15, 2011, at 2:13 PM, Mike Burns wrote: > Hi Tom, > > I don't think we will have to rely on "moments of controlled disclosure" you describe, involving NDA-covered private network information to the local registrar, simply to have accurate contact information. > Why? > Because proper registration is going to be the effective proof of ownership. > As the value of control of IP assets becomes more widely known, and higher, in the face of free pool exhaust, those who control these rights will be motivated by their desire to publicy record their rights in a registry. That outcome may be "guaranteed" by some theory about the connection between property and incentives, but it is not well supported by any facts that anyone might plausibly regard as relevant to this case. One counterexample is provided by the case of HM Land Registry that I already mentioned. There's hasn't been any "free land" in the UK since the Enclosures, and I doubt anyone would dispute that UK land has appreciated in value -- or that squatters are a risk -- and yet those facts alone haven't been sufficient to motivate a substantial share of UK landowners to participate in a (before 2009) 100% free registry with no barriers to entry. > When addresses are free, conflict over their control is limited, and proof of ownership much less important. Really? Would anyone on nsp-sec care to chime in to respond to the claim that conflicts over the "control of IP addresses" haven't been much of problem over the last two decades? For the purposes of both this particular claim, and *your own proposal*, the alleged primary concern is "whois accuracy," and the alleged (secondary) contributor to that end is ownership by those who are unable or unwilling to undergo a nee/capability test. Let's stick to your own proposal, because debating philosophy will not be productive. > When conflict rises, along with value, and there is no tangible "certificate of control", getting the authoritative registry recognition is more important. > I believe John Curran referenced an increase in the processing of old 8.2 Transfers, cleaning up old mergers, which I take to be an indication of the motivation I am describing here. > > Therefore, x: (NOT current RSA signatories + NOT willing/able to undergo a need/capability test + ARE certain to self-maintain the quality of their own whois information at historically unprecedented high levels in perpetuity) is the population I intended to reach with this proposal. Even if I believed that you're right on this point, my original analysis stands. Your goal is create a positive incentive for some unknown minority segment of unregistered future transfer seekers to abide by registration policies, at the cost of changing a key element of those policies that contributes to the preservation of whois data accuracy across every other segment of existing and future address users. But you and I both know that the the sort of property purists that you have used to illustrate the merits of this policy are also very likely to be privacy purists too. So while they may be only too eager to register, their whois entries are likely to consist of nothing more than "Address Owner Inc." plus "thisprefixcouldbeyours$$$@anonymous.com). As first-time registrants who have never had, and would never expect to have any "nontrivial" interaction with the RIR, any information that they'd be likely to share would carefully tuned to maximize their own private advantage with no other considerations whatsoever. > They will have every incentive to keep their information registred correctly, if only to increase its resale value. Okay, on that narrow point we agree: aspiring speculators and address flippers are more likely to register, albeit in the manner described above. But the stronger that incentive is, the more likely it is that the addresses in question are kept out of "real production" anyway (the fastest flipper gets the worm!), or alternately that the content of their 100% accurate registrations have no actual value for operational coordination purposes. Outside of address flippers, many prospective address buyers may wish to register with ARIN, but many may not. Of all the reasons that they might prefer registration over non-registration, or vice versa, the burden of a needs/capability test will almost certainly rank pretty low on that list for most. And for the overwhelming majority for whom this is more than a marginal concern, removing the need/capability test is not going to tip the scales in favor of meaningful registration. > You call them Saints. I call them normal humans who want some evidence of their valuable control rights. I guess someone should call the Prime Minister and warn him about the millions of abnormal humans that have been roaming the Brisitsh countryside for the last few centuries. Seriously, most of the normal humans that I encounter aren't driven by a monomaniacal fixation on establishing and reaffirming evidence of their valuable control rights every moment of every day. Sometimes they forget things, sometimes they get overwhelmed with more immediate demands. I find that many normal humans can rationalize failures to prioritize the reaffirmation of their precious control rights almost indefinitely if they can get away with it -- especially if the act of reaffirming those rights entails waiting in line, filling out forms, being questioned about sensitive personal matters by strangers whose interests and incentives are suspect, or generally spending even the smallest time or effort doing anything outside of what they would classify as "work" or "fun." It's just human nature -- at least among the normal humans that I know. > All your groups, x,y,and z will likely keep their registration more updated than they have historically as the value of their holdings becomes clearer to all. Could you please cite something other than theory that supports this expectation? > If I have a new business plan that I am pitching to investors, and if my projected growth plan includes a need for increasing IPv4 addresses over the next 24 months, what do I say to the investor who asks how I will get those addresses and what they will cost? First thing I'd do is redirect them with an offer to put them into some fine ocreanfront property in Kansas -- because if they're going to fund your IPv4-dependent growth plan, they'll probably bankroll anything. > If I could purchase 24 months supply on the transfer market now, but would have to keep ARIN in the dark, and know that I could get the addresses routed by submitting the purchase document to my network provider, why wouldn't I do that, and isn't it clear that Whois accuracy will suffer? > Is this situation so unworldly that it can't be envisioned? > The sole limitation to getting this transaction registered is the ARIN needs test for transfers. > > I think it's really quite a stretch to think the needs requirement increases registration accuracy, as you imply. You are at liberty to doubt. I'm not. > Remember, if ARIN is doing a needs analysis for somebody, it's because they have already been contacted in reference to the desire to have ARIN book a transfer, right? So if they have already done that, why does the needs requirement enchance contact information accuracy? > I don't see the logic there. Please refer to my previous message for a fuller accounting of the various beneficial effects of the need/capability requirement; those other benefits would still apply even for aspiring new address flippers who have been completely open and forthcoming with respect to their whois-related information. Regards, Tom > Regards, > Mike > > > > ----- Original Message ----- From: "Tom Vest" > To: "Mike Burns" > Cc: "Owen DeLong" ; ; "Paul Vixie" > Sent: Sunday, May 15, 2011 11:34 AM > Subject: Re: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate > > > > On May 12, 2011, at 1:26 PM, Mike Burns wrote: > >> Hi Owen, >>> >>>> I still don't see the connection between my proposal to drop needs requirements for transfers and the participation rate of DNS whois or the UK land office. >>>> I may be missing something obvious, though. >>> >> >>> I believe he is arguing that if you turn address policy into a free-for-all (as in your proposal), like >>> DNS, it will decrease, rather than increase whois accuracy. I hadn't thought of this consequence, but, >>> now that Tom and Paul have brought it up, it does make sense. >> >> >> I am still missing the connection between removing needs requirements for transfers and having that decrease whois accuracy. >> If you can connect the dots, you will go a long way in convincing me that my proposal is flawed. > > Hi Mike, > > Again, apologies for the delayed response. I tried to clarify the connection in my message of May 13, 2011 12:04:39 PM EDT (specifically, @ bullet points 3 and esp. 4). But that was a long message that also covered several other reasons why the so-called "needs" (which IMO should be "capability") requirement is important which are completely independent of its relevance to whois accuracy, and perhaps I wasn't clear enough on the specific one that interests you. > > Basically, the need/capability test facilitates the ongoing maintenance/preservation of whois accuracy because it assures that each subsequent allocation/assignment (and in the future, each transfer transaction) will trigger the same kind of "moment of controlled disclosure" that occurs when a new entity joins an RIR and/or requests an initial allocation. As a group, network operators -- and esp. growing ones -- undergo the sort of internal changes (e.g., reorgs, relocations, new sites, new non-M&A commercial partnerships, et al.) that can trigger changes in their external contact details fairly frequently. For all sorts of reasons that are mostly banal (oversights, procrastination, impatience with "bureaucracy," miscommunication, someone else's job, thought they were already informed, etc.), the RIRs don't always "get the memo" at the time when such changes occur -- or even afterward, during subsequent "casual" interactions. Absent other countervailing factors, such changes would cause the overall quality of registration data to degrade progressively over time, with the more dynamic/faster growing networks typically leading the way down. > > What prevents (or at least substantially mitigates) this progressive decay is the policy-mandated needs/capability test requirement. That requirement assures that each subsequent interaction between registrants and the RIR that could materially alter the distribution of IP number resources *will not* be "casual" in the above sense, but rather will (typically) involve some presentation of documents which illustrate the existence and size of the new addressing requirements. The review of such materials -- which frequently include invoices for new network-related assets or similar documents that show buyer address and other contact info -- provides a formal opportunity for RIR and registrant representatives to make sure that they're on the same page with respect to all current contact information. > > So, to put this explicitly in the context of your proposal: > > The exhaustion of the unallocated IPv4 pool is not going to reduce the frequency with which address registrants undergo the sort of internal changes that can make some or all of their current whois contact details outdated -- if anything it might make those changes happen more frequently. Thus, in order for whois data quality to be preserved going forward at (at least) current accuracy levels, the current practice of making each subsequent address-related transaction subject to a mandatory needs/capability capability review must continue. > > In order for your proposal to have *any chance at all* of causing a net improvement in whois data quality, the number of future Pv4 transfer seekers that are > > x: (NOT current RSA signatories + NOT willing/able to undergo a need/capability test + ARE certain to self-maintain the quality of their own whois information at historically unprecedented high levels in perpetuity) > > ...would have to exceed the sum of other kinds of future address seekers, including those who are: > > y: (NOT current RSA signatories + ARE willing/able to undergo a need/capability test + NOT certain to self-maintain the quality of their own whois information at historically unprecedented high levels in perpetuity) > > z: (ARE current RSA signatories + (n/a) + NOT certain to self-maintain the quality of their own whois information at historically unprecedented high levels in perpetuity) > > Logically, the universe of potential future address seekers is complete characterized by (x + y + z) as described above, plus two other groups that, hypothetically, wouldn't be affected either way by your proposal: > > Incorrigibles: (NOT signatories + NOT willing + NOT self-maintaining) > > Saints: (ARE signatories + (n/a)+ ARE self-maintaining) > > [Note: I say "hypothetically" above because I actually believe that the adoption of this policy would undermine an existing community "norm" of whois participation that currently contributes to "irrationally" high data quality across current registrants -- and as a result your policy would cause average levels of whois "self-maintenance" to decline across all groups. But that possibility is not factored into this analysis] > > Assuming that "saints" and "incorrigibles" would be equally represented across both current ARIN members/RSA signatories and future address seekers (and excluding any possible "normative" affects), your proposal would only be net positive at the point where ((non-Saint, non-Incorrigible x)) exceeds (non-Saint, non-Incorrigible (y+z)). Given the size of the current ARIN membership, the only way this pans out in your favor if 90%+ of current members and 90%+ of future address seekers actually fall into the "Saint" or "Incorrigible" category. > > But of course, this assumption would also mean that your policy (and all policies, more-or-less) are almost complete irrelevant. > > Happily, I believe that those demographic assumption are grossly inconsistent with both RIR administrative experience and with the documented record of RIR community-policy interactions over the last 20 years. > > Hence, I am opposed. > > TV > > >>>> My whole goal is to increase accuracy in Whois, and I am not relying on any financial or price mechanism for that increase. >>> >> >>> And now there is evidence that your proposal would likely have the opposite effect. >> >> What evidence? >> >>>> I have not argued that pricing will increase registration, I have argued that pricing will ensure productive use. >>> >> >>> Which also remains in dispute and unproven. >>> Owen >> >> Hence the word argued. >> >> >> Regards, >> Mike > From mike at nationwideinc.com Sun May 15 18:39:35 2011 From: mike at nationwideinc.com (Mike Burns) Date: Sun, 15 May 2011 18:39:35 -0400 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate References: <7F5FC4554E42430FADDC0D376164DFA0@mike><0BB63D56-1605-4E1E-8F0B-B2083FDE4A96@delong.com><16AACD9632484C85BF6B855603CF07B4@mike><4294678C-B653-4BB3-9D40-FD935EA00CF3@eyeconomics.com> <6332CACB-1F07-4036-AC1E-FE9CF448DE82@eyeconomics.com> <707022CC-A086-4FF6-B42C-8D8DA581367D@delong.com> <4CEC4E334DBD4D1CBE15A0E208FD55A0@mike> Message-ID: Hi Tom, responses inline. >That outcome may be "guaranteed" by some theory about the connection >between property and incentives, but it is not well supported by any facts >that anyone >might plausibly regard as relevant to this case. One >counterexample is provided by the case of HM Land Registry that I already >mentioned. There's hasn't been >any "free land" in the UK since the >Enclosures, and I doubt anyone would dispute that UK land has appreciated >in value -- or that squatters are a risk -- and yet >those facts alone >haven't been sufficient to motivate a substantial share of UK landowners to >participate in a (before 2009) 100% free registry with no barriers to > >entry. My evidence is John Curran saying there has been an uptick in 8.2 transfer requests that reflect old transfers. Pretty direct evidence, isn't it? Maybe since this is ARIN, an example familiar to Americans may be a more effective analogy than the HM Land Registry? >> When addresses are free, conflict over their control is limited, and >> proof of ownership much less important. >Really? Would anyone on nsp-sec care to chime in to respond to the claim >that conflicts over the "control of IP addresses" haven't been much of >problem over the >last two decades? My point was that whatever conflict there has been will increase post-exhaust. And please don't change my language. I said limited, not "haven't been much of a problem over the last two decades." Conflict has been limited, compared to pre-exhaust, by the low replacement cost, and the lack of resale value. >For the purposes of both this particular claim, and *your own proposal*, >the alleged primary concern is "whois accuracy," and the alleged >(secondary) contributor >to that end is ownership by those who are unable >or unwilling to undergo a nee/capability test. Let's stick to your own >proposal, because debating philosophy will >not be productive. Tom, you have led the discussion astray twice now, with a deviation to private DNS registries, and now an argument over how likely people will be to register their addresses post-exhaust. Neither of these issues is related to my proposal to lift needs on 8.3 transfers, let us please stick to that. I have given clear and multiple examples of transactions which have incentives for buyers and sellers to engage, but which would fail the needs analysis. You have provided no information that I can find which connects the needs requirement to better accuracy. Do you have any evidence of that to counter the claims I make about natural transactions between buyers and sellers which does not meet the needs requirement, but which buyers and sellers would voluntarily want to engage in, and the likelihood they will do the deal "off the books"? >> When conflict rises, along with value, and there is no tangible >> "certificate of control", getting the authoritative registry recognition >> is more important. >> I believe John Curran referenced an increase in the processing of old 8.2 >> Transfers, cleaning up old mergers, which I take to be an indication of >> the motivation I am describing here. > >> Therefore, x: (NOT current RSA signatories + NOT willing/able to undergo >> a need/capability test + ARE certain to self-maintain the quality of >> their own whois >>nformation at historically unprecedented high levels >> in perpetuity) is the population I intended to reach with this proposal. >Even if I believed that you're right on this point, my original analysis >stands. You're analysis is flawed from get-go because it involved the incentive for others to register, who could pass the needs requirement. There is no argument that those people will participate and Whois accuracy will be maintained at least at current levels. My proposal is specifically designed to extend the range of transactions for which ARIN will be contacted to update WHois registration. >Your goal is create a positive incentive for some unknown minority segment >of unregistered future transfer seekers to abide by registration policies, >at the cost of changing a key element of those policies that contributes to >the preservation of whois data accuracy across every other segment of >existing and future address users. How does dropping the needs requirement for transfer of IPv4 address space change the "preservation of whois data accuracy across every other segment of existing and future addess holders"? You assert this without any support that I can discern. How does dropping 8.3 needs requirements change whois data accuracy for existing RSA holders who don't wish to sell? Existing RSA holders who do wish to sell? IPv6 holders? There are three segments of existing address users, how is their Whois accuracy degraded by my proposal? >But you and I both know that the the sort of property purists that you have >used to illustrate the merits of this policy are also very likely to be >privacy purists too. >>So while they may be only too eager to register, >their whois entries are likely to consist of nothing more than "Address >Owner Inc." plus >thisprefixcouldbeyours$$$@anonymous.com). As first-time >registrants who have never had, and would never expect to have any >"nontrivial" interaction with the >RR, any information that they'd be >likely to share would carefully tuned to maximize their own private >advantage with no other considerations whatsoever. Tom, are you calling the guy pitching the 24 month plan to investors a "property purist"? Is that supposed to be a perjorative? Now they are "only too eager to register", where in your last post, they would have had to have been Saints? And if they register with false information, it hinders the resale value of the addresses, and the debases the very reason why they would be so eager. Their private advantage is aligned with whois accuracy, as they want acknowledgement of their valuable control rights, and Whois is the trust authority whose registration provides evidence of their ownership. This is the same reason hijacking addresses would be more difficult, because the owners would be more diligent in maintaining control over valuable assets than they currently have been, as has been noticed by another poster here. >> They will have every incentive to keep their information registred >> correctly, if only to increase its resale value. >Okay, on that narrow point we agree: aspiring speculators and address >flippers are more likely to register, albeit in the manner described above. >But the stronger that incentive is, the more likely it is that the >addresses in question are kept out of "real production" anyway (the fastest >flipper gets the worm!), or >alternately that the content of their 100% >accurate registrations have no actual value for operational coordination >purposes. So you acknowledge that certain buyers will want to register, but would be precluded by the needs requirement. Thank you. >Outside of address flippers, many prospective address buyers may wish to >register with ARIN, but many may not. Of all the reasons that they might >prefer >registration over non-registration, or vice versa, the burden of a >needs/capability test will almost certainly rank pretty low on that list >for most. And for the >overwhelming majority for whom this is more than a >marginal concern, removing the need/capability test is not going to tip the >scales in favor of meaningful >registration. I wouldn't consider the 24-month business pitchers I gave as an example to be "address flippers" and I note your frequent use of what you consider to be perjorative descriptions which I think is an effort to appeal to emotion more than logic in youir argument. I don't think registration is going to be a "marginal concern" when addresses have substantial resale value. On the contrary, and again I refer to John mentioning the uptick in 8.2 transfers which occured some time in the past as evidence for the increased value associated with correct registration. Care to directly address the example of the sage investor seeing a flaw in the business plan being pitched to him which requires more addresses than the current ARIN needs requirement allows? With my proposal, there is no such flaw, the plan gets approved, and people get put to work. Without my proposal, the FUD factor about a basic requirment's future availability overrides, the deal is canceled, the jobs do not get created. Or, the sage investor is told that a purchase can be made, but can not be registered in Whois. There is uncertainty here, too, for an investor, and for whois accuracy. >> You call them Saints. I call them normal humans who want some evidence of >> their valuable control rights. >I guess someone should call the Prime Minister and warn him about the >millions of abnormal humans that have been roaming the Brisitsh countryside >for the last >few centuries. Tom, you are astray again. My proposal does not depend on increasing whois accuracy for existing allocations, and is not related that, as much as you keep returning us to the UK Land Office. My proposal seeks to identify transactions which would naturally occur which would not meet the current needs requrement and would thus have a disincentive towards registration. >Seriously, most of the normal humans that I encounter aren't driven by a >monomaniacal fixation on establishing and reaffirming evidence of their >valuable control >rights every moment of every day. Sometimes they forget >things, sometimes they get overwhelmed with more immediate demands. I find >that many normal humans >can rationalize failures to prioritize the >reaffirmation of their precious control rights almost indefinitely if they >can get away with it -- especially if the act of >reaffirming those rights >entails waiting in line, filling out forms, being questioned about >sensitive personal matters by strangers whose interests and incentives are > >suspect, or generally spending even the smallest time or effort doing >anything outside of what they would classify as "work" or "fun." It's just >human nature -- at >least among the normal humans that I know. Tom, really, did I mention a monomanical fixation which grasps owners every moment of the day? Remember how we got here, it was you adducing that the needs requirement *helps* to maintain whois accuracy during the contact with the RIR doing the needs analysis. I merely pointed out that all else being equal vis a vis registrations, that the increase in perceived value of the holdings would create an incentive towards proper registration, and what's more, that any RIR doing a needs analysis has already been contacted by the tranferee, thus is already in the moment of contact. >> All your groups, x,y,and z will likely keep their registration more >> updated than they have historically as the value of their holdings >> becomes clearer to all. >Could you please cite something other than theory that supports this >expectation? I cite common sense. Where there is no other evidence for control, and where control is valuable, the registry which provides the evidence for the ownership of control will become more accurate as the incentive for the address holder is plain. Call it philosophy, I think every reader of these sentences understands the incentive I mention and the likely effects of that incentive on their action to maintain accurate data. But again, Tom, this is a sideline issue to dropping needs requirements for transfers, and only a counter argument to your claim that maintaining an extra transaction cost will somehow drive registration. >> If I have a new business plan that I am pitching to investors, and if my >> projected growth plan includes a need for increasing IPv4 addresses over >> the next 24 >>months, what do I say to the investor who asks how I will >> get those addresses and what they will cost? >First thing I'd do is redirect them with an offer to put them into some >fine ocreanfront property in Kansas -- because if they're going to fund >your IPv4-dependent >growth plan, they'll probably bankroll anything. It's your right to believe in IPv6 transition in two years, or in two weeks. I would tell any investor that if they think anybody is going to be turning off IPv4 in favor of IPv6 only in 24 months, they are being naive, but those are the kinds of risks investors take. > Remember, if ARIN is doing a needs analysis for somebody, it's because > they have already been contacted in reference to the desire to have ARIN > book a transfer, right? So if they have already done that, why does the > needs requirement enchance contact information accuracy? > I don't see the logic there. >Please refer to my previous message for a fuller accounting of the various >beneficial effects of the need/capability requirement; those other benefits >would still apply >even for aspiring new address flippers who have been >completely open and forthcoming with respect to their whois-related >information. I have reread it, is is full, but you only make two points. 1. There is a moment of contact at the point of needs analysis which provides opportunity to get valid whois information. and 2. The needs requirement makes the contact less "casual" and therefore more accurate. I have refuted those two points by indicating that the whole purpose of contact with the RIR is to update the contact information, in a needs-free transfer. Readers are advised to review Tom's post in full below to see if I have described it correctly. Regards, Mike > Regards, > Mike > > > > ----- Original Message ----- From: "Tom Vest" > To: "Mike Burns" > Cc: "Owen DeLong" ; ; "Paul Vixie" > > Sent: Sunday, May 15, 2011 11:34 AM > Subject: Re: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois > Accurate > > > > On May 12, 2011, at 1:26 PM, Mike Burns wrote: > >> Hi Owen, >>> >>>> I still don't see the connection between my proposal to drop needs >>>> requirements for transfers and the participation rate of DNS whois or >>>> the UK land office. >>>> I may be missing something obvious, though. >>> >> >>> I believe he is arguing that if you turn address policy into a >>> free-for-all (as in your proposal), like >>> DNS, it will decrease, rather than increase whois accuracy. I hadn't >>> thought of this consequence, but, >>> now that Tom and Paul have brought it up, it does make sense. >> >> >> I am still missing the connection between removing needs requirements for >> transfers and having that decrease whois accuracy. >> If you can connect the dots, you will go a long way in convincing me that >> my proposal is flawed. > > Hi Mike, > > Again, apologies for the delayed response. I tried to clarify the > connection in my message of May 13, 2011 12:04:39 PM EDT (specifically, @ > bullet points 3 and esp. 4). But that was a long message that also covered > several other reasons why the so-called "needs" (which IMO should be > "capability") requirement is important which are completely independent of > its relevance to whois accuracy, and perhaps I wasn't clear enough on the > specific one that interests you. > > Basically, the need/capability test facilitates the ongoing > maintenance/preservation of whois accuracy because it assures that each > subsequent allocation/assignment (and in the future, each transfer > transaction) will trigger the same kind of "moment of controlled > disclosure" that occurs when a new entity joins an RIR and/or requests an > initial allocation. As a group, network operators -- and esp. growing > ones -- undergo the sort of internal changes (e.g., reorgs, relocations, > new sites, new non-M&A commercial partnerships, et al.) that can trigger > changes in their external contact details fairly frequently. For all sorts > of reasons that are mostly banal (oversights, procrastination, impatience > with "bureaucracy," miscommunication, someone else's job, thought they > were already informed, etc.), the RIRs don't always "get the memo" at the > time when such changes occur -- or even afterward, during subsequent > "casual" interactions. Absent other countervailing factors, such changes > would cause the overall quality of registration data to degrade > progressively over time, with the more dynamic/faster growing networks > typically leading the way down. > > What prevents (or at least substantially mitigates) this progressive decay > is the policy-mandated needs/capability test requirement. That requirement > assures that each subsequent interaction between registrants and the RIR > that could materially alter the distribution of IP number resources *will > not* be "casual" in the above sense, but rather will (typically) involve > some presentation of documents which illustrate the existence and size of > the new addressing requirements. The review of such materials -- which > frequently include invoices for new network-related assets or similar > documents that show buyer address and other contact info -- provides a > formal opportunity for RIR and registrant representatives to make sure > that they're on the same page with respect to all current contact > information. > > So, to put this explicitly in the context of your proposal: > > The exhaustion of the unallocated IPv4 pool is not going to reduce the > frequency with which address registrants undergo the sort of internal > changes that can make some or all of their current whois contact details > outdated -- if anything it might make those changes happen more > frequently. Thus, in order for whois data quality to be preserved going > forward at (at least) current accuracy levels, the current practice of > making each subsequent address-related transaction subject to a mandatory > needs/capability capability review must continue. > > In order for your proposal to have *any chance at all* of causing a net > improvement in whois data quality, the number of future Pv4 transfer > seekers that are > > x: (NOT current RSA signatories + NOT willing/able to undergo a > need/capability test + ARE certain to self-maintain the quality of their > own whois information at historically unprecedented high levels in > perpetuity) > > ...would have to exceed the sum of other kinds of future address seekers, > including those who are: > > y: (NOT current RSA signatories + ARE willing/able to undergo a > need/capability test + NOT certain to self-maintain the quality of their > own whois information at historically unprecedented high levels in > perpetuity) > > z: (ARE current RSA signatories + (n/a) + NOT certain to self-maintain the > quality of their own whois information at historically unprecedented high > levels in perpetuity) > > Logically, the universe of potential future address seekers is complete > characterized by (x + y + z) as described above, plus two other groups > that, hypothetically, wouldn't be affected either way by your proposal: > > Incorrigibles: (NOT signatories + NOT willing + NOT self-maintaining) > > Saints: (ARE signatories + (n/a)+ ARE self-maintaining) > > [Note: I say "hypothetically" above because I actually believe that the > adoption of this policy would undermine an existing community "norm" of > whois participation that currently contributes to "irrationally" high data > quality across current registrants -- and as a result your policy would > cause average levels of whois "self-maintenance" to decline across all > groups. But that possibility is not factored into this analysis] > > Assuming that "saints" and "incorrigibles" would be equally represented > across both current ARIN members/RSA signatories and future address > seekers (and excluding any possible "normative" affects), your proposal > would only be net positive at the point where ((non-Saint, > non-Incorrigible x)) exceeds (non-Saint, non-Incorrigible (y+z)). Given > the size of the current ARIN membership, the only way this pans out in > your favor if 90%+ of current members and 90%+ of future address seekers > actually fall into the "Saint" or "Incorrigible" category. > > But of course, this assumption would also mean that your policy (and all > policies, more-or-less) are almost complete irrelevant. > > Happily, I believe that those demographic assumption are grossly > inconsistent with both RIR administrative experience and with the > documented record of RIR community-policy interactions over the last 20 > years. > > Hence, I am opposed. > > TV > > >>>> My whole goal is to increase accuracy in Whois, and I am not relying on >>>> any financial or price mechanism for that increase. >>> >> >>> And now there is evidence that your proposal would likely have the >>> opposite effect. >> >> What evidence? >> >>>> I have not argued that pricing will increase registration, I have >>>> argued that pricing will ensure productive use. >>> >> >>> Which also remains in dispute and unproven. >>> Owen >> >> Hence the word argued. >> >> >> Regards, >> Mike > From rudi.daniel at gmail.com Sun May 15 21:47:18 2011 From: rudi.daniel at gmail.com (Rudolph Daniel) Date: Sun, 15 May 2011 21:47:18 -0400 Subject: [arin-ppml] Draft Proposal 2011-1 Message-ID: I am not in favor of "Any RIR's resource registrant may transfer IPv4 addresses to the resource registrant of another RIR" as it is my belief that such a proposal would hype up the transfer market and has the possibility to split the RIRs into those who fit ARIN's needs based transfer policies and those who do not.... rd > >> On Tue, May 10, 2011 at 1:34 PM, Bill Darte > wrote: > > > >>> The policy text reviewed at the meeting was as follows: > >>> Any RIR's resource registrant may transfer IPv4 addresses to the > resource > >>> registrant of another RIR as long as the two RIRs agree and maintain > >>> compatible, needs-based transfer policies that exercise Internet > stewardship > >>> consistent with the values expressed in RFC2050. > >>> *************** > > > > > >>> 2. If objections exist, to succinctly identify what they are..and, > >> > >> The references to RFC 2050 which in the last 6 months has enjoyed > >> almost universal agreement that it's not relevant; it was written in > >> 1996 in a time and place that is far different than today, it was a > >> Best *Current* Practice (emphasis added) "BCP". > > > > > > Comments: > > 1) There is nothing remotely close to "universal agreement that [RFC > > 2050] not relevant. > > Feel free to demonstrate otherwise. So far, I count two denying that > and what appears to be significant opposition to the proposal at > large. I don't see any value in engaging in any discussion arguing for > or against any language around 2050, rather it would be more effective > to find more appropriate language reconciling the issue to move the > concept forward. Feel free to make a suggestion. > > Best, > > -M< > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cengel at conxeo.com Mon May 16 11:28:57 2011 From: cengel at conxeo.com (Chris Engel) Date: Mon, 16 May 2011 11:28:57 -0400 Subject: [arin-ppml] Just a reminder of some quick mathematicsfor IPv4that shows the long term impossibility of it In-Reply-To: References: <4DCC41D8.1010305@ipinc.net> <714BA22421E941B68BE3268E21738D09@mike> <4DCD9C8A.1030701@ipinc.net> Message-ID: > >> > >>> In fact, the era of end-to-end for the Internet was the limited > >>> timeframe between popular acceptance and NAT. > >> > >> Wrong because most people back then dialed in with a modem using > >> a terminal emulator program. The first connectivity was e-mail > >> gateways between the Internet and BBS networks like FidoNet. > >> The WWW came about later and it still wasn't that interesting until > >> pretty late in the 90's, around 96-97. And NAT came about when > >> most home users were still using dialup to connect to the Internet. > > > > That's what I meant to write. Things got interesting in the mid-90s. > > NAT came out shortly thereafter. NAT ended the end-to-end connectivity > thing. > > And yet the Internet exploded in size. > > Dialup was not really end-to-end because there weren't fixed IP addresses, > so not many were hosting servers on dialup. > > (I know there were exceptions, I once got a /24 with a dialup account back > in 1995.) > > > > This does not prove NAT is wonderful or that end-to-end is not useful > or necessary. > > It proves that a lot of people faced with the choice between NAT and nothing > chose NAT over non-connection. This is akin to facing a choice between > food poisoning and cancer. The obvious choice is food poisoning, but, > most people would prefer to avoid both. > > >> > >>> Most people would fear to put a real IP address on a computer today, I > >>> know that I would. > >>> I use Logmein from behind NAT to address another computer behind > another > >>> NAT. > >> > >> logmein is not free for business use so your probably violating TOS. > > > > I don't remember saying I used the free one. > > > > End-to-end addresses mean I don't have to pay someone else just to > provide a rendezvous server so I can reach my own stuff. It also means > I can connect to my own stuff without subjecting my access to such a > man-in-the-middle attack or the additional latency and/or risks associated > with doing so. > > I really don't see any reason I would want to move from globally addressable > systems to systems behind such a rendezvous mechanism. Can you point > to any single advantage of doing so? > > >> And if you paid for it why should everyone else in the world pay > >> that company? Remote Desktop is free for business and personal use > >> and does not require some wacky active x control or java applet to > >> run in a browser. So is VNC. both of these are also faster. > >> > > I use both of these products, too. > > Not with the target behind a NAT, you don't. > > > I started with Carbon Copy over modems. > > LoL... I remember those days. Not all that fondly. > > > Full disclosure: I have done some consulting for Logmein. > > Ah, so you have a somewhat vested interest in the success of this > arguably unnecessary (if we had end-to-end) business model. > > > In the real world I use Logmein for instances behind NAT. > > In the real world, I keep my systems globally accessible. I just > don't see any advantage to doing otherwise. > > > It's especially valuable for the rapid setup of remote support because it > does not require firewall changes. > > People are willing to pay for that ability, according to their success in the > market. > > > > People are willing to accept all kinds of bad engineering and pay for > workarounds to > resolve the issues they create. For example, look at the number of people > that > bought Windows 3.1 and then paid third parties for IP software, anti-virus > software, > firewall software, shells that didn't crash all the time, memory managers, etc. > > Each of those things is arguably a simple deficiency in the original Windows > product > and a feature that was included in the basic expectations of virtually every > other > operating system available at the time. > > Just as network access services provided without a globally unique address > can > be worked around through things like back2mymac and other rendezvous > services. > However, those services would be utterly unnecessary with a proper globally > unique address. > > > > >>> Rendezvous servers exist for that purpose, and the market favors them. > >>> Holding on to some dream of complete end-to-end reachability leaves > out > >>> the inevitable firewall application between them in any case. > >>> Juniper and Cisco have enabled CGN on their big iron boxes, do you > think > >>> they are unaware of the nightmarish negative impact of CGN you > ascribe? > >>> > >> > >> They OFFER CGN on their big iron they don't "enable" it, the admin > >> has to configure it for it to be enabled. And naturally they don't mind > >> if an admin does because they get to sell them more hardware that way. > >> > >> Ted > > > > Well, we won't have to wait too much longer to see who is correct in their > appraisal of the perils of CGN. > > Indeed. I suspect that carriers in Asia will be forced to implement at least > some LSN very soon. > Unfortunately, users in Asia are generally used to a much lower level of > service quality than > even users in the US, so, that may not be an entirely valid datapoint. > > > I assume somebody paid the coders at Cisco to write the CGN code. > > As near as I can tell, most of the LSN code in the Cisco gateways is the same > as their standard > NAT code that's been in their routers for quite some time. Since IOS tends to > be the kitchen > sink of all kinds of features anyone imagined someone might ever want, I > wouldn't take > that as too much of an indication as to market demand. After all, IOS still > contained support > for Banyan until not all that long ago. In fact, I don't know for sure that it has > been retired yet. > > > I doubt that would have happened if Cisco's research showed customers > would reject it. > > > > I'm sure, as I said, that Cisco's research showed that some carriers would > need it. There is > a huge difference between needing to do something and wanting to do it or > considering it > desirable. The number of IPv4-only devices in the consumer electronics > product space > that will not be upgraded before IPv4 runout alone means that even > consumers placed > on primarily IPv6 services are going to need some level of IPv4 connectivity > solution > for some time. Those consumers will be subjected to LSN because there is > literally no > other viable option. > > LSN isn't a feature, it's a workaround for alack of viable options due to the > constraints > of time combined with a global lack of preparedness and progress. > > Owen > Even though I enjoy healthy debate as much as anyone, I'm not sure what the point or relevance of this thread is? Some participants here view universal end-to-end connectivity as an important goal and as such NAT being significantly harmful to the internet. Others of us believe that goal is not particularly desirable and possibly even harmful to the interests of a portion of the community....and thus NAT has significant utility that outweighs any potential harm. Much like politics or religion, I don't believe either side will be effective in changing the others beliefs no matter how much verbiage is expended in the effort. That seems evident by the number of times this particular discussion has taken place on this list. Is it possible to simply agree to disagree on the utility/harm of NAT and set aside that portion of the discussion? Can we simply agree that at this particular point in time IPv4 address space continues to have some value/use to a significant portion of the internet community? If we can generally agree on that proposition, then it seems clear that ARIN still has some responsibility for setting policies in regards assignment of that space. The question of whether the rest of the worlds population of human's, llama's or house flies will be able to access the internet through IPv4 strikes me as entirely tangential to that point. FWIW, my particular hope is that IPv6 see's a steady increase in adoption so that people who do value publically addressable space can get it, IF they want it....and that NAT & IPv4 (and maybe even NAT66) continue to be available to those of us who prefer it as an option. The world is a diverse place, I don't see why the internet should not reflect that diversity in being able to cater to a varied and sometimes conflicting set of interests. Yes, that adds to the complexity of the system from an engineering standpoint....but so does manufacturing more then one size of shoe. Christopher Engel (representing only my own views) From cgrundemann at gmail.com Mon May 16 11:55:16 2011 From: cgrundemann at gmail.com (Chris Grundemann) Date: Mon, 16 May 2011 09:55:16 -0600 Subject: [arin-ppml] Just a reminder of some quick mathematicsfor IPv4that shows the long term impossibility of it In-Reply-To: References: <4DCC41D8.1010305@ipinc.net> <714BA22421E941B68BE3268E21738D09@mike> <4DCD9C8A.1030701@ipinc.net> Message-ID: On Mon, May 16, 2011 at 09:28, Chris Engel wrote: > Can we simply agree that at this particular point in time IPv4 address space continues to have some value/use to a significant portion of the internet community? > > If we can generally agree on that proposition, then it seems clear that ARIN still has some responsibility for setting policies in regards assignment of that space. The question of whether the rest of the worlds population of human's, llama's or house flies will be able to access the internet through IPv4 strikes me as entirely tangential to that point. It may be tangential to whether or not we have a responsibility to set policy, but it is crucial to our understanding of what policy to set. > FWIW, my particular hope is that IPv6 see's a steady increase in adoption so that people who do value publically addressable space can get it, IF they want it....and that NAT & IPv4 (and maybe even NAT66) continue to be available to those of us who prefer it as an option. The world is a diverse place, I don't see why the internet should not reflect that diversity in being able to cater to a varied and sometimes conflicting set of interests. Yes, that adds to the complexity of the system from an engineering standpoint....but so does manufacturing more then one size of shoe. We share the same hope, and I too see the world as diverse and choice as a good thing. The problem is that perpetuating IPv4 removes my choice. If someone is able to force us to continue using IPv4 through the policy that they set and the technology they adopt, then they have relegated us to using NAT - whether it makes sense in a particular situation or not. I believe this is the point that most have tried to make in this thread; not that you have to give up NAT but rather that you should not be allowed to force NAT on me. Cheers, ~Chris (speaking for myself, and likely not posting in this thread again) > Christopher Engel > (representing only my own views) > > _______________________________________________ > 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 weblog.chrisgrundemann.com www.burningwiththebush.com www.theIPv6experts.net www.coisoc.org From tedm at ipinc.net Mon May 16 12:11:28 2011 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Mon, 16 May 2011 09:11:28 -0700 Subject: [arin-ppml] Just a reminder of some quick mathematicsfor IPv4that shows the long term impossibility of it In-Reply-To: References: <4DCC41D8.1010305@ipinc.net> <714BA22421E941B68BE3268E21738D09@mike> <4DCD9C8A.1030701@ipinc.net> Message-ID: <4DD14CB0.3090607@ipinc.net> On 5/16/2011 8:28 AM, Chris Engel wrote: > >>>> >>>>> In fact, the era of end-to-end for the Internet was the >>>>> limited timeframe between popular acceptance and NAT. >>>> >>>> Wrong because most people back then dialed in with a modem >>>> using a terminal emulator program. The first connectivity was >>>> e-mail gateways between the Internet and BBS networks like >>>> FidoNet. The WWW came about later and it still wasn't that >>>> interesting until pretty late in the 90's, around 96-97. And >>>> NAT came about when most home users were still using dialup to >>>> connect to the Internet. >>> >>> That's what I meant to write. Things got interesting in the >>> mid-90s. NAT came out shortly thereafter. NAT ended the >>> end-to-end connectivity >> thing. >>> And yet the Internet exploded in size. Dialup was not really >>> end-to-end because there weren't fixed IP addresses, >> so not many were hosting servers on dialup. >>> (I know there were exceptions, I once got a /24 with a dialup >>> account back >> in 1995.) >>> >> >> This does not prove NAT is wonderful or that end-to-end is not >> useful or necessary. >> >> It proves that a lot of people faced with the choice between NAT >> and nothing chose NAT over non-connection. This is akin to facing a >> choice between food poisoning and cancer. The obvious choice is >> food poisoning, but, most people would prefer to avoid both. >> >>>> >>>>> Most people would fear to put a real IP address on a computer >>>>> today, I know that I would. I use Logmein from behind NAT to >>>>> address another computer behind >> another >>>>> NAT. >>>> >>>> logmein is not free for business use so your probably violating >>>> TOS. >>> >>> I don't remember saying I used the free one. >>> >> >> End-to-end addresses mean I don't have to pay someone else just to >> provide a rendezvous server so I can reach my own stuff. It also >> means I can connect to my own stuff without subjecting my access to >> such a man-in-the-middle attack or the additional latency and/or >> risks associated with doing so. >> >> I really don't see any reason I would want to move from globally >> addressable systems to systems behind such a rendezvous mechanism. >> Can you point to any single advantage of doing so? >> >>>> And if you paid for it why should everyone else in the world >>>> pay that company? Remote Desktop is free for business and >>>> personal use and does not require some wacky active x control >>>> or java applet to run in a browser. So is VNC. both of these >>>> are also faster. >>>> >>> I use both of these products, too. >> >> Not with the target behind a NAT, you don't. >> >>> I started with Carbon Copy over modems. >> >> LoL... I remember those days. Not all that fondly. >> >>> Full disclosure: I have done some consulting for Logmein. >> >> Ah, so you have a somewhat vested interest in the success of this >> arguably unnecessary (if we had end-to-end) business model. >> >>> In the real world I use Logmein for instances behind NAT. >> >> In the real world, I keep my systems globally accessible. I just >> don't see any advantage to doing otherwise. >> >>> It's especially valuable for the rapid setup of remote support >>> because it >> does not require firewall changes. >>> People are willing to pay for that ability, according to their >>> success in the >> market. >>> >> >> People are willing to accept all kinds of bad engineering and pay >> for workarounds to resolve the issues they create. For example, >> look at the number of people that bought Windows 3.1 and then paid >> third parties for IP software, anti-virus software, firewall >> software, shells that didn't crash all the time, memory managers, >> etc. >> >> Each of those things is arguably a simple deficiency in the >> original Windows product and a feature that was included in the >> basic expectations of virtually every other operating system >> available at the time. >> >> Just as network access services provided without a globally unique >> address can be worked around through things like back2mymac and >> other rendezvous services. However, those services would be utterly >> unnecessary with a proper globally unique address. >> >>> >>>>> Rendezvous servers exist for that purpose, and the market >>>>> favors them. Holding on to some dream of complete end-to-end >>>>> reachability leaves >> out >>>>> the inevitable firewall application between them in any >>>>> case. Juniper and Cisco have enabled CGN on their big iron >>>>> boxes, do you >> think >>>>> they are unaware of the nightmarish negative impact of CGN >>>>> you >> ascribe? >>>>> >>>> >>>> They OFFER CGN on their big iron they don't "enable" it, the >>>> admin has to configure it for it to be enabled. And naturally >>>> they don't mind if an admin does because they get to sell them >>>> more hardware that way. >>>> >>>> Ted >>> >>> Well, we won't have to wait too much longer to see who is correct >>> in their >> appraisal of the perils of CGN. >> >> Indeed. I suspect that carriers in Asia will be forced to implement >> at least some LSN very soon. Unfortunately, users in Asia are >> generally used to a much lower level of service quality than even >> users in the US, so, that may not be an entirely valid datapoint. >> >>> I assume somebody paid the coders at Cisco to write the CGN >>> code. >> >> As near as I can tell, most of the LSN code in the Cisco gateways >> is the same as their standard NAT code that's been in their routers >> for quite some time. Since IOS tends to be the kitchen sink of all >> kinds of features anyone imagined someone might ever want, I >> wouldn't take that as too much of an indication as to market >> demand. After all, IOS still contained support for Banyan until not >> all that long ago. In fact, I don't know for sure that it has been >> retired yet. >> >>> I doubt that would have happened if Cisco's research showed >>> customers >> would reject it. >>> >> >> I'm sure, as I said, that Cisco's research showed that some >> carriers would need it. There is a huge difference between needing >> to do something and wanting to do it or considering it desirable. >> The number of IPv4-only devices in the consumer electronics product >> space that will not be upgraded before IPv4 runout alone means that >> even consumers placed on primarily IPv6 services are going to need >> some level of IPv4 connectivity solution for some time. Those >> consumers will be subjected to LSN because there is literally no >> other viable option. >> >> LSN isn't a feature, it's a workaround for alack of viable options >> due to the constraints of time combined with a global lack of >> preparedness and progress. >> >> Owen >> > > Even though I enjoy healthy debate as much as anyone, I'm not sure > what the point or relevance of this thread is? The point is that IPv4 isn't going to work to get the rest of the world online. Sorry it's degenerating into a NAT debate but the NAT proponents seem to think that NAT will allow IPv4 to be used forever on the Internet. > Some participants > here view universal end-to-end connectivity as an important goal and > as such NAT being significantly harmful to the internet. Others of us > believe that goal is not particularly desirable and possibly even > harmful to the interests of a portion of the community....and thus > NAT has significant utility that outweighs any potential harm. > > Much like politics or religion, I don't believe either side will be > effective in changing the others beliefs no matter how much verbiage > is expended in the effort. That seems evident by the number of times > this particular discussion has taken place on this list. Is it > possible to simply agree to disagree on the utility/harm of NAT and > set aside that portion of the discussion? > > Can we simply agree that at this particular point in time IPv4 > address space continues to have some value/use to a significant > portion of the internet community? > So it's the "I've got mine Jack to bad there ain't any left for you" approach? > If we can generally agree on that proposition, then it seems clear > that ARIN still has some responsibility for setting policies in > regards assignment of that space. The question of whether the rest of > the worlds population of human's, llama's or house flies will be able > to access the internet through IPv4 strikes me as entirely tangential > to that point. > Since ARIN has essentially completed assignment of that space, there is really not much left to set as policy in the IPv4 realm other than continued interference in transfers of IPv4 from one to the other party. > FWIW, my particular hope is that IPv6 see's a steady increase in > adoption so that people who do value publically addressable space can > get it, IF they want it....and that NAT& IPv4 (and maybe even NAT66) > continue to be available to those of us who prefer it as an option. But those NATs will NOT continue to be available to those of us who prefer them because they require IPv4 to go on the "outside" of the NAT. > The world is a diverse place, I don't see why the internet should not > reflect that diversity in being able to cater to a varied and > sometimes conflicting set of interests. Yes, that adds to the > complexity of the system from an engineering standpoint....but so > does manufacturing more then one size of shoe. > Sounds good so let's go ahead and run IPX on the Internet too... since I like that old Netware protocol better than IP. So I should be arguing for ISPs to all enable it on their routers based on backwards compatibility, using that logic. The fact of the matter is that what other people choose to do DOES affect you, the Internet is not some wild west network where there is no law and governance and you Chris can do as you damn well please. Every time someone else brings up another AS it uses a piece of ram in MY router. Every time I subnet the advertisements of my own AS and prepend some and not others to balance my load it uses a piece of ram in YOUR router. Like it or not, we are tied to each other. How well do you think the US highway system would work if every state was allowed to set their own highway widths? Or set their own standards on what color vehicle brake lights would be? Would you like to get a ticket in my state for having an amber directional signal on the back of your car instead of red? This is why the Internet cannot reflect the world's diversity in it's protocols. You can be as diverse as you want with website content and suchlike but the value of the Internet is that everyone is talking with the same protocols. We currently have a problem with one of them right now and we have a plan in place to change it that was set up a decade ago that all the major networks have signed on to doing - and what is going on is a few malcontents out there who were asleep at the switch and are too lazy to educate themselves about how IPv6 works now want to derail that plan by pretending CGN will allow us to ashcan IPv6 and keep IPv4 going in perpetuity. It is one thing to regard CGN as transitional and admit you have a grotty infrastructure that needs it that you can't replace just right now, but you are going to soon. It is quite another to claim that it is reasonable that CGN will allow IPv4 to be a permanent future protocol on the Internet, but that is what your doing. Ted > > Christopher Engel (representing only my own views) > > _______________________________________________ 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 cengel at conxeo.com Mon May 16 13:09:58 2011 From: cengel at conxeo.com (Chris Engel) Date: Mon, 16 May 2011 13:09:58 -0400 Subject: [arin-ppml] Just a reminder of some quick mathematicsfor IPv4that shows the long term impossibility of it In-Reply-To: <4DD14CB0.3090607@ipinc.net> References: <4DCC41D8.1010305@ipinc.net> <714BA22421E941B68BE3268E21738D09@mike> <4DCD9C8A.1030701@ipinc.net> <4DD14CB0.3090607@ipinc.net> Message-ID: Ted, > > Even though I enjoy healthy debate as much as anyone, I'm not sure > > what the point or relevance of this thread is? > > The point is that IPv4 isn't going to work to get the rest of the > world online. Sorry it's degenerating into a NAT debate but the > NAT proponents seem to think that NAT will allow IPv4 to be > used forever on the Internet. > Even if true, why does that matter? If 30 years from now if IPv6, for whatever reason, should prove insufficient to the planets internet needs does that mean that 30 years of policy regarding it will have been wasted? No one posses a crystal ball to see with perfect clarity what the future holds. Generally policy should reflect immediate needs with the understanding that it may need to be modified in future if those needs change. > > Some participants > > here view universal end-to-end connectivity as an important goal and > > as such NAT being significantly harmful to the internet. Others of us > > believe that goal is not particularly desirable and possibly even > > harmful to the interests of a portion of the community....and thus > > NAT has significant utility that outweighs any potential harm. > > > > Much like politics or religion, I don't believe either side will be > > effective in changing the others beliefs no matter how much verbiage > > is expended in the effort. That seems evident by the number of times > > this particular discussion has taken place on this list. Is it > > possible to simply agree to disagree on the utility/harm of NAT and > > set aside that portion of the discussion? > > > > Can we simply agree that at this particular point in time IPv4 > > address space continues to have some value/use to a significant > > portion of the internet community? > > > > So it's the "I've got mine Jack to bad there ain't any left for you" > approach? > What are you talking about here? No one can manufacture more IPv4 then currently exists to assign to those who don't have it yet. They can however present you with a choice as to whether you want IPv6 space or whether you want some "limited subset" of IPv4 functionality behind something like CGN. If there is some genuine value to either then the dynamics of a free market will ensure that such choices are available. In the long run, companies don't succeed by offering their clients inferior products.....and if they do, their competitors have only themselves to blame for not making a compelling enough case to consumers about the advantages of their own products. Would you prefer rule by fiat? > > If we can generally agree on that proposition, then it seems clear > > that ARIN still has some responsibility for setting policies in > > regards assignment of that space. The question of whether the rest of > > the worlds population of human's, llama's or house flies will be able > > to access the internet through IPv4 strikes me as entirely tangential > > to that point. > > > > Since ARIN has essentially completed assignment of that space, there > is really not much left to set as policy in the IPv4 realm other > than continued interference in transfers of IPv4 from one to the > other party. > > > FWIW, my particular hope is that IPv6 see's a steady increase in > > adoption so that people who do value publically addressable space can > > get it, IF they want it....and that NAT& IPv4 (and maybe even NAT66) > > continue to be available to those of us who prefer it as an option. > > But those NATs will NOT continue to be available to those of us > who prefer them because they require IPv4 to go on the "outside" of > the NAT. Please explain, this isn't clear? > > > The world is a diverse place, I don't see why the internet should not > > reflect that diversity in being able to cater to a varied and > > sometimes conflicting set of interests. Yes, that adds to the > > complexity of the system from an engineering standpoint....but so > > does manufacturing more then one size of shoe. > > > > Sounds good so let's go ahead and run IPX on the Internet too... since I > like that old Netware protocol better than IP. So I should be arguing > for ISPs to all enable it on their routers based on backwards > compatibility, using that logic. > No one is stopping you...nor should they have the right to do so. No one has the right to tell anyone else what packets to run on their own network segments. If what you are doing proves problematic, you may find your segment isolated and not much traffic routed through it... but if you can manage to make it work well enough for the people using it, why should anyone be able to dictate to you the details of exactly how you achieve that? > The fact of the matter is that what other people choose to do DOES > affect you, the Internet is not some wild west network where there is > no law and governance and you Chris can do as you damn well please. > > Every time someone else brings up another AS it uses a piece of ram in > MY router. Every time I subnet the advertisements of my own AS and > prepend some and not others to balance my load it uses a piece of ram > in YOUR router. Like it or not, we are tied to each other. > Um....as far as I am aware....we are responsible for how our individual routers work....we can certainly choose NOT to carry a particular route in it if we want.....and we can certainly choose to drop/block/filter particular packets going across our boundaries if we choose. There are consequences for us making poor choices of course....but that doesn't mean we don't have any choice. > How well do you think the US highway system would work if every state > was allowed to set their own highway widths? Or set their own standards > on what color vehicle brake lights would be? Would you like to get a > ticket in my state for having an amber directional signal on the back > of your car instead of red? Actually, the US highway system works alot like that. Different states have different speed limits set, different regulations for what you can do while driving (in my state you can get ticketed for talking on the cell phone while driving or having tinted glass, in others you can't) and of course once you get off of PUBLIC roads and onto PRIVATE ones, there is an entirely different set of rules governing their use. Note that the US Highway system is PUBLICALY funded, which is a big differentiator. > > This is why the Internet cannot reflect the world's diversity in it's > protocols. You can be as diverse as you want with website content and > suchlike but the value of the Internet is that everyone is talking > with the same protocols. We currently have a problem with one of them > right now and we have a plan in place to change it that was set up > a decade ago that all the major networks have signed on to doing - and > what is going on is a few malcontents out there who were asleep at the > switch and are too lazy to educate themselves about how IPv6 works > now want to derail that plan by pretending CGN will allow us to ashcan > IPv6 and keep IPv4 going in perpetuity. > > It is one thing to regard CGN as transitional and admit you have a > grotty infrastructure that needs it that you can't replace just right > now, but you are going to soon. It is quite another to claim that it > is reasonable that CGN will allow IPv4 to be a permanent future protocol > on the Internet, but that is what your doing. > > Ted I certainly have no ability to stop anyone from deploying IPv6 that wants to.... wouldn't try if I could. If people are CHOOSING something else over IPv6...then the only people who are to blame for that are the designers, proponents and vendors of IPv6 solutions for not offering a compelling enough reason/argument for people to CHOOSE IPv6. Don't blame others for your inability to convince people of your vision for the future. Christopher Engel (representing only my own views) From bill at herrin.us Mon May 16 13:28:09 2011 From: bill at herrin.us (William Herrin) Date: Mon, 16 May 2011 13:28:09 -0400 Subject: [arin-ppml] Just a reminder of some quick mathematicsfor IPv4that shows the long term impossibility of it In-Reply-To: References: <4DCC41D8.1010305@ipinc.net> <714BA22421E941B68BE3268E21738D09@mike> <4DCD9C8A.1030701@ipinc.net> Message-ID: On Mon, May 16, 2011 at 11:55 AM, Chris Grundemann wrote: > The problem is that perpetuating IPv4 removes my > choice. If someone is able to force us to continue using IPv4 through > the policy that they set and the technology they adopt, then they have > relegated us to using NAT - whether it makes sense in a particular > situation or not. I believe this is the point that most have tried to > make in this thread; not that you have to give up NAT but rather that > you should not be allowed to force NAT on me. Chris, Yeah, yeah, we get it. You should be allowed to force IPv6 on me (direct, first-order effect) because my continued use of IPv4 coupled with the general shortage of IPv4 addresses would eventually force you to use NAT. (indirect third-order effect). The argument fails. You've not demonstrated that the harm and expense from the uses of NAT which would plausibly end with the ubiquity of IPv6 outweighs the harm and expense of a forced migration to IPv6. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From tedm at ipinc.net Mon May 16 17:49:43 2011 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Mon, 16 May 2011 14:49:43 -0700 Subject: [arin-ppml] Just a reminder of some quick mathematicsfor IPv4that shows the long term impossibility of it In-Reply-To: References: <4DCC41D8.1010305@ipinc.net> <714BA22421E941B68BE3268E21738D09@mike> <4DCD9C8A.1030701@ipinc.net> <4DD14CB0.3090607@ipinc.net> Message-ID: <4DD19BF7.1030203@ipinc.net> On 5/16/2011 10:09 AM, Chris Engel wrote: > Ted, > >>> Even though I enjoy healthy debate as much as anyone, I'm not >>> sure what the point or relevance of this thread is? >> >> The point is that IPv4 isn't going to work to get the rest of the >> world online. Sorry it's degenerating into a NAT debate but the >> NAT proponents seem to think that NAT will allow IPv4 to be used >> forever on the Internet. >> > > Even if true, why does that matter? If it WAS true or even remotely plausible then it WOULD matter. But it isn't, which is why it doesn't matter, thus making your question rhetorical. > If 30 years from now if IPv6, > for whatever reason, should prove insufficient to the planets > internet needs does that mean that 30 years of policy regarding it > will have been wasted? The planet's addressing needs and the planet's internet needs are different. We aren't talking internet needs, we are talking addressing needs. And to say that IPv6 will wear out in 30 years is foolish and shows a lack of understanding about communication standards. We still to this day produce telephone gear that works on the POTS standard. Communication standards that reach a critical mass of popularity usually don't go away easily. We still use RCA jacks and plugs in audio. We still until very recently produced personal computers with both parallel ports and serial ports on them. The very fact that we are having this discussion about IPv4 when the planet has not even reached 50% penetration of Internet connectivity is proof enough of how difficult it is to change a bad standard when a lot of people use it. (rs232 is a terrible serial port standard, BTW, as it is not balanced) When and if the planet ever reaches 100% market penetration of Internet there will still be enormous amounts of IPv6 unused. As an addressing standard IPv6 is pretty much "it" as they say. > No one posses a crystal ball to see with > perfect clarity what the future holds. Generally policy should > reflect immediate needs with the understanding that it may need to be > modified in future if those needs change. > >>> Some participants here view universal end-to-end connectivity as >>> an important goal and as such NAT being significantly harmful to >>> the internet. Others of us believe that goal is not particularly >>> desirable and possibly even harmful to the interests of a portion >>> of the community....and thus NAT has significant utility that >>> outweighs any potential harm. >>> >>> Much like politics or religion, I don't believe either side will >>> be effective in changing the others beliefs no matter how much >>> verbiage is expended in the effort. That seems evident by the >>> number of times this particular discussion has taken place on >>> this list. Is it possible to simply agree to disagree on the >>> utility/harm of NAT and set aside that portion of the >>> discussion? >>> >>> Can we simply agree that at this particular point in time IPv4 >>> address space continues to have some value/use to a significant >>> portion of the internet community? >>> >> >> So it's the "I've got mine Jack to bad there ain't any left for >> you" approach? >> > > What are you talking about here? No one can manufacture more IPv4 > then currently exists to assign to those who don't have it yet. They > can however present you with a choice as to whether you want IPv6 > space or whether you want some "limited subset" of IPv4 functionality > behind something like CGN. No, they can't - because to run the CGN you must have 'real' IPv4 and when that is gone, what are you going to assign to the CGN's? > If there is some genuine value to either > then the dynamics of a free market will ensure that such choices are > available. In the long run, companies don't succeed by offering their > clients inferior products.....and if they do, their competitors have > only themselves to blame for not making a compelling enough case to > consumers about the advantages of their own products. Would you > prefer rule by fiat? > rule by fiat? Are you arguing that this is always bad or something? >>> If we can generally agree on that proposition, then it seems >>> clear that ARIN still has some responsibility for setting >>> policies in regards assignment of that space. The question of >>> whether the rest of the worlds population of human's, llama's or >>> house flies will be able to access the internet through IPv4 >>> strikes me as entirely tangential to that point. >>> >> >> Since ARIN has essentially completed assignment of that space, >> there is really not much left to set as policy in the IPv4 realm >> other than continued interference in transfers of IPv4 from one to >> the other party. >> >>> FWIW, my particular hope is that IPv6 see's a steady increase in >>> adoption so that people who do value publically addressable space >>> can get it, IF they want it....and that NAT& IPv4 (and maybe >>> even NAT66) continue to be available to those of us who prefer it >>> as an option. >> >> But those NATs will NOT continue to be available to those of us who >> prefer them because they require IPv4 to go on the "outside" of the >> NAT. > > Please explain, this isn't clear? > When the last of the RIR's assigns out the last IPv4 that will be the end of it. If a new ISP that has no numbering comes along where are they going to get their IPv4 to get online? Unless you think that CGN automatically includes NAT64 also? >> >>> The world is a diverse place, I don't see why the internet should >>> not reflect that diversity in being able to cater to a varied >>> and sometimes conflicting set of interests. Yes, that adds to >>> the complexity of the system from an engineering >>> standpoint....but so does manufacturing more then one size of >>> shoe. >>> >> >> Sounds good so let's go ahead and run IPX on the Internet too... >> since I like that old Netware protocol better than IP. So I should >> be arguing for ISPs to all enable it on their routers based on >> backwards compatibility, using that logic. >> > > No one is stopping you...nor should they have the right to do so. No > one has the right to tell anyone else what packets to run on their > own network segments. If what you are doing proves problematic, you > may find your segment isolated and not much traffic routed through > it... but if you can manage to make it work well enough for the > people using it, why should anyone be able to dictate to you the > details of exactly how you achieve that? > I didn't say run IPX on my own segment, I said run it on the Internet. Your getting pretty desperate to keep this NAT thing justified when you stoop to remarks like that. >> The fact of the matter is that what other people choose to do DOES >> affect you, the Internet is not some wild west network where there >> is no law and governance and you Chris can do as you damn well >> please. >> >> Every time someone else brings up another AS it uses a piece of ram >> in MY router. Every time I subnet the advertisements of my own AS >> and prepend some and not others to balance my load it uses a piece >> of ram in YOUR router. Like it or not, we are tied to each other. >> > > Um....as far as I am aware....we are responsible for how our > individual routers work....we can certainly choose NOT to carry a > particular route in it if we want.....and we can certainly choose to > drop/block/filter particular packets going across our boundaries if > we choose. There are consequences for us making poor choices of > course....but that doesn't mean we don't have any choice. > It isn't reasonable to assume that an admin of an ISP that takes a full feed would have the time to be able to research every single entry in the table and decide if he was going to block it or not. >> How well do you think the US highway system would work if every >> state was allowed to set their own highway widths? Or set their >> own standards on what color vehicle brake lights would be? Would >> you like to get a ticket in my state for having an amber >> directional signal on the back of your car instead of red? > > Actually, the US highway system works alot like that. Different > states have different speed limits set, different regulations for > what you can do while driving (in my state you can get ticketed for > talking on the cell phone while driving or having tinted glass, in > others you can't) and of course once you get off of PUBLIC roads and > onto PRIVATE ones, there is an entirely different set of rules > governing their use. Note that the US Highway system is PUBLICALY > funded, which is a big differentiator. > In the US, only the old US highways are allowed to be noncompliant, any additions to the US highway system must meet design standards recommended by American Association of State Highway Officials (AASHO) And of course, the Interstate highway system has a much higher set of AASHO standards to meet. >> >> This is why the Internet cannot reflect the world's diversity in >> it's protocols. You can be as diverse as you want with website >> content and suchlike but the value of the Internet is that everyone >> is talking with the same protocols. We currently have a problem >> with one of them right now and we have a plan in place to change it >> that was set up a decade ago that all the major networks have >> signed on to doing - and what is going on is a few malcontents out >> there who were asleep at the switch and are too lazy to educate >> themselves about how IPv6 works now want to derail that plan by >> pretending CGN will allow us to ashcan IPv6 and keep IPv4 going in >> perpetuity. >> >> It is one thing to regard CGN as transitional and admit you have a >> grotty infrastructure that needs it that you can't replace just >> right now, but you are going to soon. It is quite another to claim >> that it is reasonable that CGN will allow IPv4 to be a permanent >> future protocol on the Internet, but that is what your doing. >> >> Ted > > I certainly have no ability to stop anyone from deploying IPv6 that > wants to.... wouldn't try if I could. If people are CHOOSING > something else over IPv6...then the only people who are to blame for > that are the designers, proponents and vendors of IPv6 solutions for > not offering a compelling enough reason/argument for people to CHOOSE > IPv6. Don't blame others for your inability to convince people of > your vision for the future. > IPv6 isn't my vision, I didn't design it. And people often choose things that are self-destructive, why do you think the US has an epidemic of obesity? This isn't a case of people understanding both IPv6 and IPv4 and choosing IPv4. It's a case of people understanding IPv4 because that is all they know, and not choosing IPv6 because they don't understand it. Given a chose between something they know and understand and something they don't, people as a group will choose the first thing even when it is self-destructive. There are at current estimate over 6 thousand people walking around today who are alive because of vehicle air bags. Yet, the general public back in the 70's thought air bags were stupid when they first heard of them. Fortunately the federal government ignored the idiots in '84 and mandated them. I suspect that those 6,000+ people are probably in the pro-airbag camp nowadays. Ted > > Christopher Engel (representing only my own views) > From owen at delong.com Mon May 16 18:55:49 2011 From: owen at delong.com (Owen DeLong) Date: Mon, 16 May 2011 15:55:49 -0700 Subject: [arin-ppml] Just a reminder of some quick mathematicsfor IPv4that shows the long term impossibility of it In-Reply-To: References: <4DCC41D8.1010305@ipinc.net> <714BA22421E941B68BE3268E21738D09@mike> <4DCD9C8A.1030701@ipinc.net> Message-ID: <700C596A-658D-4550-9FA8-5D3409FAF294@delong.com> > > Even though I enjoy healthy debate as much as anyone, I'm not sure what the point or relevance of this thread is? Some participants here view universal end-to-end connectivity as an important goal and as such NAT being significantly harmful to the internet. Others of us believe that goal is not particularly desirable and possibly even harmful to the interests of a portion of the community....and thus NAT has significant utility that outweighs any potential harm. > The latter view presupposes an incorrect perception of both end to end and the capabilities of NAT. If you have good firewalls, there is no harm in leaving the packet header unmangled. The harm from NAT is huge and the utility of NAT is demonstrably small unless you are trying to conserve addresses. The value of conserving addresses in IPv6 is demonstrably small, therefore, I find it very unlikely that the utility of NAT could possibly outweigh the harm it is known to cause. > Much like politics or religion, I don't believe either side will be effective in changing the others beliefs no matter how much verbiage is expended in the effort. That seems evident by the number of times this particular discussion has taken place on this list. Is it possible to simply agree to disagree on the utility/harm of NAT and set aside that portion of the discussion? > Not really. NAT is a toxic-polluter issue and those in favor of it are rarely its victims. That would be sort of like asking the residents of Bhopal to agree to disagree with Union Carbide about the utility/harm of irresponsible chemical processing. > Can we simply agree that at this particular point in time IPv4 address space continues to have some value/use to a significant portion of the internet community? I don't think that is in dispute. > > If we can generally agree on that proposition, then it seems clear that ARIN still has some responsibility for setting policies in regards assignment of that space. The question of whether the rest of the worlds population of human's, llama's or house flies will be able to access the internet through IPv4 strikes me as entirely tangential to that point. It is tangential to that point, but, it becomes quite meaningful to the discussion of what those policies should be. Since this thread has covered both the fact that ARIN should continue to set policies (which some seem to take as opinion rather than fact) as well as several aspects of what those policies should be, I don't think you can discard content of the thread just because it is not relevant to one of the topics in the thread. > > FWIW, my particular hope is that IPv6 see's a steady increase in adoption so that people who do value publically addressable space can get it, IF they want it....and that NAT & IPv4 (and maybe even NAT66) continue to be available to those of us who prefer it as an option. The world is a diverse place, I don't see why the internet should not reflect that diversity in being able to cater to a varied and sometimes conflicting set of interests. Yes, that adds to the complexity of the system from an engineering standpoint....but so does manufacturing more then one size of shoe. > Because ISVs won't reflect that diversity and they will limit application features to the lowest common denominator. I don't want to see the internet hobbled by NAT any longer than it already has been. Owen From owen at delong.com Mon May 16 19:07:14 2011 From: owen at delong.com (Owen DeLong) Date: Mon, 16 May 2011 16:07:14 -0700 Subject: [arin-ppml] Just a reminder of some quick mathematicsfor IPv4that shows the long term impossibility of it In-Reply-To: References: <4DCC41D8.1010305@ipinc.net> <714BA22421E941B68BE3268E21738D09@mike> <4DCD9C8A.1030701@ipinc.net> Message-ID: <8C7FAAA3-63E7-4FF5-BD96-CD66978F80F5@delong.com> On May 16, 2011, at 10:28 AM, William Herrin wrote: > On Mon, May 16, 2011 at 11:55 AM, Chris Grundemann > wrote: >> The problem is that perpetuating IPv4 removes my >> choice. If someone is able to force us to continue using IPv4 through >> the policy that they set and the technology they adopt, then they have >> relegated us to using NAT - whether it makes sense in a particular >> situation or not. I believe this is the point that most have tried to >> make in this thread; not that you have to give up NAT but rather that >> you should not be allowed to force NAT on me. > > Chris, > > Yeah, yeah, we get it. You should be allowed to force IPv6 on me > (direct, first-order effect) because my continued use of IPv4 coupled > with the general shortage of IPv4 addresses would eventually force you > to use NAT. (indirect third-order effect). > > The argument fails. You've not demonstrated that the harm and expense > from the uses of NAT which would plausibly end with the ubiquity of > IPv6 outweighs the harm and expense of a forced migration to IPv6. > > Regards, > Bill Herrin > > I don't think he's arguing you should be forced to use IPv6. He's just arguing that you shouldn't be allowed to continue to use IPv4. That kind of renders the rest of your conclusions moot. Owen From matthew at matthew.at Mon May 16 19:37:10 2011 From: matthew at matthew.at (Matthew Kaufman) Date: Mon, 16 May 2011 16:37:10 -0700 Subject: [arin-ppml] ARIN-prop-150 Reclamation Hold In-Reply-To: References: <4DCD36FC.3000501@arin.net> Message-ID: On May 13, 2011, at 7:50 AM, Martin Hannigan wrote: > > Agreed, we just had a proposal with significant support to return > address reclaimed to the free pool with a high expectation of > "faster", not slower. I don't see why this would be any different > hence I expect a lack of community support. In fact, I think that the > author should consider withdrawing this to save us all some time. > I am withdrawing ARIN-prop-150. > We need to leave this as an administrative decision influenced by the > community vs. a rule. This is an example of not knowing what you might > not know. Agree that this should be handled via ASCP rather than as a policy change to the NRPM. I believe the discussion on the list has been enlightening in that some want a much shorter hold period, some want a much longer hold period, and almost nobody wants the hold period we currently have. Matthew Kaufman -------------- next part -------------- An HTML attachment was scrubbed... URL: From ipng at 69706e6720323030352d30312d31340a.nosense.org Mon May 16 18:41:55 2011 From: ipng at 69706e6720323030352d30312d31340a.nosense.org (Mark Smith) Date: Tue, 17 May 2011 08:11:55 +0930 Subject: [arin-ppml] Just a reminder of some quick mathematicsfor IPv4that shows the long term impossibility of it In-Reply-To: References: <4DCC41D8.1010305@ipinc.net> <714BA22421E941B68BE3268E21738D09@mike> <4DCD9C8A.1030701@ipinc.net> Message-ID: <20110517081155.22315ac7@opy.nosense.org> On Mon, 16 May 2011 11:28:57 -0400 Chris Engel wrote: > > > >> > > >>> In fact, the era of end-to-end for the Internet was the limited > > >>> timeframe between popular acceptance and NAT. > > >> > > >> Wrong because most people back then dialed in with a modem using > > >> a terminal emulator program. The first connectivity was e-mail > > >> gateways between the Internet and BBS networks like FidoNet. > > >> The WWW came about later and it still wasn't that interesting until > > >> pretty late in the 90's, around 96-97. And NAT came about when > > >> most home users were still using dialup to connect to the Internet. > > > > > > That's what I meant to write. Things got interesting in the mid-90s. > > > NAT came out shortly thereafter. NAT ended the end-to-end connectivity > > thing. > > > And yet the Internet exploded in size. > > > Dialup was not really end-to-end because there weren't fixed IP addresses, > > so not many were hosting servers on dialup. > > > (I know there were exceptions, I once got a /24 with a dialup account back > > in 1995.) > > > > > > > This does not prove NAT is wonderful or that end-to-end is not useful > > or necessary. > > > > It proves that a lot of people faced with the choice between NAT and nothing > > chose NAT over non-connection. This is akin to facing a choice between > > food poisoning and cancer. The obvious choice is food poisoning, but, > > most people would prefer to avoid both. > > > > >> > > >>> Most people would fear to put a real IP address on a computer today, I > > >>> know that I would. > > >>> I use Logmein from behind NAT to address another computer behind > > another > > >>> NAT. > > >> > > >> logmein is not free for business use so your probably violating TOS. > > > > > > I don't remember saying I used the free one. > > > > > > > End-to-end addresses mean I don't have to pay someone else just to > > provide a rendezvous server so I can reach my own stuff. It also means > > I can connect to my own stuff without subjecting my access to such a > > man-in-the-middle attack or the additional latency and/or risks associated > > with doing so. > > > > I really don't see any reason I would want to move from globally addressable > > systems to systems behind such a rendezvous mechanism. Can you point > > to any single advantage of doing so? > > > > >> And if you paid for it why should everyone else in the world pay > > >> that company? Remote Desktop is free for business and personal use > > >> and does not require some wacky active x control or java applet to > > >> run in a browser. So is VNC. both of these are also faster. > > >> > > > I use both of these products, too. > > > > Not with the target behind a NAT, you don't. > > > > > I started with Carbon Copy over modems. > > > > LoL... I remember those days. Not all that fondly. > > > > > Full disclosure: I have done some consulting for Logmein. > > > > Ah, so you have a somewhat vested interest in the success of this > > arguably unnecessary (if we had end-to-end) business model. > > > > > In the real world I use Logmein for instances behind NAT. > > > > In the real world, I keep my systems globally accessible. I just > > don't see any advantage to doing otherwise. > > > > > It's especially valuable for the rapid setup of remote support because it > > does not require firewall changes. > > > People are willing to pay for that ability, according to their success in the > > market. > > > > > > > People are willing to accept all kinds of bad engineering and pay for > > workarounds to > > resolve the issues they create. For example, look at the number of people > > that > > bought Windows 3.1 and then paid third parties for IP software, anti-virus > > software, > > firewall software, shells that didn't crash all the time, memory managers, etc. > > > > Each of those things is arguably a simple deficiency in the original Windows > > product > > and a feature that was included in the basic expectations of virtually every > > other > > operating system available at the time. > > > > Just as network access services provided without a globally unique address > > can > > be worked around through things like back2mymac and other rendezvous > > services. > > However, those services would be utterly unnecessary with a proper globally > > unique address. > > > > > > > >>> Rendezvous servers exist for that purpose, and the market favors them. > > >>> Holding on to some dream of complete end-to-end reachability leaves > > out > > >>> the inevitable firewall application between them in any case. > > >>> Juniper and Cisco have enabled CGN on their big iron boxes, do you > > think > > >>> they are unaware of the nightmarish negative impact of CGN you > > ascribe? > > >>> > > >> > > >> They OFFER CGN on their big iron they don't "enable" it, the admin > > >> has to configure it for it to be enabled. And naturally they don't mind > > >> if an admin does because they get to sell them more hardware that way. > > >> > > >> Ted > > > > > > Well, we won't have to wait too much longer to see who is correct in their > > appraisal of the perils of CGN. > > > > Indeed. I suspect that carriers in Asia will be forced to implement at least > > some LSN very soon. > > Unfortunately, users in Asia are generally used to a much lower level of > > service quality than > > even users in the US, so, that may not be an entirely valid datapoint. > > > > > I assume somebody paid the coders at Cisco to write the CGN code. > > > > As near as I can tell, most of the LSN code in the Cisco gateways is the same > > as their standard > > NAT code that's been in their routers for quite some time. Since IOS tends to > > be the kitchen > > sink of all kinds of features anyone imagined someone might ever want, I > > wouldn't take > > that as too much of an indication as to market demand. After all, IOS still > > contained support > > for Banyan until not all that long ago. In fact, I don't know for sure that it has > > been retired yet. > > > > > I doubt that would have happened if Cisco's research showed customers > > would reject it. > > > > > > > I'm sure, as I said, that Cisco's research showed that some carriers would > > need it. There is > > a huge difference between needing to do something and wanting to do it or > > considering it > > desirable. The number of IPv4-only devices in the consumer electronics > > product space > > that will not be upgraded before IPv4 runout alone means that even > > consumers placed > > on primarily IPv6 services are going to need some level of IPv4 connectivity > > solution > > for some time. Those consumers will be subjected to LSN because there is > > literally no > > other viable option. > > > > LSN isn't a feature, it's a workaround for alack of viable options due to the > > constraints > > of time combined with a global lack of preparedness and progress. > > > > Owen > > > > Even though I enjoy healthy debate as much as anyone, I'm not sure what the point or relevance of this thread is? Some participants here view universal end-to-end connectivity as an important goal and as such NAT being significantly harmful to the internet. Others of us believe that goal is not particularly desirable and possibly even harmful to the interests of a portion of the community....and thus NAT has significant utility that outweighs any potential harm. > > Much like politics or religion, I don't believe either side will be effective in changing the others beliefs no matter how much verbiage is expended in the effort. That seems evident by the number of times this particular discussion has taken place on this list. Is it possible to simply agree to disagree on the utility/harm of NAT and set aside that portion of the discussion? > NAT isn't up to a matter of opinion. It is a matter of what the Internet's design architecture is, and whether NAT can fit within that architecture. NAT breaks end-to-end reachability and transparency between the edges of the Internet, which is why it doesn't fit the Internet's design architecture. The Internet is intended to be a dumb packet switching network, not one that has to have an understanding of the applications that are running over it. That's the fundamental difference between the Internet and a traditional application specific network such as the PSTN - if you want to run something other than voice over the PSTN (e.g. fax), you have to make it look like a phone call. If you want to run an application over the Internet (the no-NAT Internet), you don't have to care what it looks like, because the Internet doesn't care what the application is. The moment you add NAT is the moment "the Internet" needs to care about the applications because it now has to translate any addresses carried in them. You then also introduce a performance bottle neck, another point of application failure and a traffic interception point at the "public server" that is acting as a relay between the true end-points. (Imagine a birthday party where nobody can talk directly to each other, instead, all conversations have to go through the person having the birthday ...) For those in the pro-NAT camp, have a read of the following. Then if you're still advocating NAT, you'll be more aware as to what you're trading off. RFC1627 - Network 10 Considered Harmful (Some Practices Shouldn't be Codified) http://tools.ietf.org/html/rfc1627 RFC1958 - Architectural Principles of the Internet http://tools.ietf.org/html/rfc1958 RFC2775 - Internet Transparency http://tools.ietf.org/html/rfc2775 RFC2993 - Architectural Implications of NAT http://tools.ietf.org/html/rfc2993 > Can we simply agree that at this particular point in time IPv4 address space continues to have some value/use to a significant portion of the internet community? > > If we can generally agree on that proposition, then it seems clear that ARIN still has some responsibility for setting policies in regards assignment of that space. The question of whether the rest of the worlds population of human's, llama's or house flies will be able to access the internet through IPv4 strikes me as entirely tangential to that point. > > FWIW, my particular hope is that IPv6 see's a steady increase in adoption so that people who do value publically addressable space can get it, IF they want it....and that NAT & IPv4 (and maybe even NAT66) continue to be available to those of us who prefer it as an option. The world is a diverse place, I don't see why the internet should not reflect that diversity in being able to cater to a varied and sometimes conflicting set of interests. Yes, that adds to the complexity of the system from an engineering standpoint....but so does manufacturing more then one size of shoe. > > > Christopher Engel > (representing only my own views) > > _______________________________________________ > 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 george.herbert at gmail.com Mon May 16 19:59:55 2011 From: george.herbert at gmail.com (George Herbert) Date: Mon, 16 May 2011 16:59:55 -0700 Subject: [arin-ppml] ARIN-prop-150 Reclamation Hold In-Reply-To: References: <4DCD36FC.3000501@arin.net> Message-ID: On Mon, May 16, 2011 at 4:37 PM, Matthew Kaufman wrote: > > On May 13, 2011, at 7:50 AM, Martin Hannigan wrote: > > Agreed, we just had a proposal with significant support to return > address reclaimed to the free pool with a high expectation of > "faster", not slower. I don't see why this would be any different > hence I expect a lack of community support. In fact, I think that the > author should consider withdrawing this to save us all some time. > > > I am withdrawing ARIN-prop-150. > > We need to leave this as an administrative decision influenced by the > community vs. a rule. This is an example of not knowing what you might > not ?know. > > Agree that this should be handled via ASCP rather than as a policy change to > the NRPM. > I believe the discussion on the list has been enlightening in that some want > a much shorter hold period, some want a much longer hold period, and almost > nobody wants the hold period we currently have. > Matthew Kaufman Perhaps a clarifying document that splits the all theh discussed categories out separately would be a timely response to the conversation. However, I have No Time This Week, so I leave this to someone else to write if it's seen to be valuable enough to pursue. -- -george william herbert george.herbert at gmail.com From farmer at umn.edu Mon May 16 23:46:11 2011 From: farmer at umn.edu (David Farmer) Date: Mon, 16 May 2011 22:46:11 -0500 Subject: [arin-ppml] New Version of ARIN-prop-126: Compliance Requirement In-Reply-To: References: Message-ID: <4DD1EF83.3070303@umn.edu> On 5/15/11 14:12 CDT, Chris Grundemann wrote: > On Wed, Apr 20, 2011 at 18:41, Scott Leibrand wrote: >> All, >> How would you feel about striking the following sentence in 12.6?: "If >> progress of resource returns or record corrections is not visible within >> sixty (60) days after correspondence with ARIN began, ARIN will cease >> providing reverse DNS services for the resources in question." >> The preceding sentence says that "ARIN may cease providing reverse DNS >> services" at any time after 30 days, and the requirement that ARIN >> *will* cease providing reverse DNS after 60 days seems like it would limit >> ARIN's ability to do the right thing if an organization is cooperating... >> Thoughts? > > I think that the last sentence already provides this flexibility to > ARIN staff: "ARIN shall negotiate a longer term with the organization > if ARIN believes the organization is working in good faith to > substantially restore compliance and has a valid need for additional > time to renumber out of the affected blocks." Do you disagree? > > At this point, I think there is enough support for this idea that we > should move the current text forward to draft status and discuss it in > Philly (and on the list before then of course). Those who have not > spoken up regarding this proposal are highly encouraged to do so. > > Thanks, > ~Chris > (Primary Shepherd, ARIN-prop-126) Chris, In reviewing the responses to the current text I don't think this text is ready yet. I think there is general support for the intent of this policy. But there seems to be support for the change Scott is suggesting, I think it is a good suggestion too. Additionally, I'm still not fully comfortable with the details of how breaking RDNS will be implemented by staff. I'm not sure this is a policy issue itself, but I would like to see some implementation recommendations included, like that when RDNS service has been withdrawn that is directly visible in Whois to everyone and there should be an alert for any ARIN online accounts that have POCs associated with the resource, similar to how the invalid POC thing is working now. If we are going to do this it needs to jump out a bite you, right now I'm worried that it will be to subtle. >> On Wed, Feb 16, 2011 at 11:34 AM, Chris Grundemann >> wrote: >>> >>> Hail PPML! >>> >>> I am the primary AC shepherd for ARIN-prop-126: Compliance Requirement >>> and I would like to hear your comments and feedback on this new >>> version of the proposal (included below). If the community is happy >>> with this text; I will take the necessary steps as shepherd to advance >>> it to the next stage of the process, which would be getting the AC to >>> promote it to a draft policy (https://www.arin.net/policy/pdp.html). >>> >>> One thing to note: This proposal updates existing policy and as such >>> not all of the text is new or a change. Please review the current >>> policy language when evaluating this proposal: >>> https://www.arin.net/policy/nrpm.html#twelve. >>> >>> Thanks in advance for your input! >>> >>> Cheers, >>> ~Chris >>> >>> #### >>> >>> ARIN-prop-126: Compliance Requirement >>> >>> Proposal Originator: Marla Azinger >>> >>> Proposal Version: 2 >>> >>> Date: 16 February 2011 >>> >>> Proposal type: new >>> >>> Policy term: permanent >>> >>> Policy statement: >>> >>> Resource Review >>> Update the following NRPM Sections: >>> >>> 12.4 - Update to: Organizations found by ARIN to be out of compliance >>> with current ARIN policy shall be required to update reassignment >>> information or return resources as needed to bring them into (or >>> reasonably close to) compliance. >>> >>> 1. The degree to which an organization may remain out of compliance >>> shall be based on the reasonable judgment of the ARIN staff and shall >>> balance all facts known, including the organization's utilization >>> rate, available address pool, and other factors as appropriate so as >>> to avoid forcing returns which will result in near-term additional >>> requests or unnecessary route de-aggregation. >>> 2. To the extent possible, entire blocks should be returned. Partial >>> address blocks shall be returned in such a way that the portion >>> retained will comprise a single aggregate block. >>> >>> (leave 12.5 as is) >>> >>> 12.6 - Update to: Except in cases of fraud, an organization shall be >>> given a minimum of thirty (30) days to respond. If an organization >>> does not respond within those thirty (30) days, ARIN may cease >>> providing reverse DNS services to that organization. If progress of >>> resource returns or record corrections is not visible within sixty >>> (60) days after correspondence with ARIN began, ARIN will cease >>> providing reverse DNS services for the resources in question. At any >>> time after ninety (90) days have passed, ARIN may initiate resource >>> revocation as allowed in paragraph 12.5. ARIN shall negotiate a longer >>> term with the organization if ARIN believes the organization is >>> working in good faith to substantially restore compliance and has a >>> valid need for additional time to renumber out of the affected blocks. >>> >>> Rationale: >>> >>> Version 2 addresses several staff and legal concerns with the original >>> text of this policy by clarifying the language and making it more >>> concrete. >>> >>> To date the community has not documented or firmly established use of >>> an effective enforcement mechanism. This policy will support current >>> policy and compel those who are allocated ARIN resources to maintain >>> the proper WHOIS records in accordance with ARIN NRPM. While it is >>> recognized this is not an absolute solution to ensure compliance, it >>> is the best method under current ARIN policies. >>> >>> Timetable for implementation: Immediate -- =============================================== 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 hannigan at gmail.com Tue May 17 09:58:13 2011 From: hannigan at gmail.com (Martin Hannigan) Date: Tue, 17 May 2011 09:58:13 -0400 Subject: [arin-ppml] New Version of ARIN-prop-126: Compliance Requirement In-Reply-To: <4DD1EF83.3070303@umn.edu> References: <4DD1EF83.3070303@umn.edu> Message-ID: On Mon, May 16, 2011 at 11:46 PM, David Farmer wrote: > On 5/15/11 14:12 CDT, Chris Grundemann wrote: >> >> On Wed, Apr 20, 2011 at 18:41, Scott Leibrand >> ?wrote: >>> >>> All, >>> How would you feel about striking the following sentence in 12.6?: "If >>> progress of resource returns or record corrections is not visible within >>> sixty (60) days after correspondence with ARIN began, ARIN will cease >>> providing reverse DNS services for the resources in question." >>> The preceding sentence says that "ARIN may cease providing reverse DNS >>> services" at any time after 30 days, and the requirement that ARIN >>> *will* cease providing reverse DNS after 60 days seems like it would >>> limit >>> ARIN's ability to do the right thing if an organization is cooperating... >>> Thoughts? >> >> I think that the last sentence already provides this flexibility to >> ARIN staff: "ARIN shall negotiate a longer term with the organization >> if ARIN believes the organization is working in good faith to >> substantially restore compliance and has a valid need for additional >> time to renumber out of the affected blocks." Do you disagree? >> >> At this point, I think there is enough support for this idea that we >> should move the current text forward to draft status and discuss it in >> Philly (and on the list before then of course). Those who have not >> spoken up regarding this proposal are highly encouraged to do so. >> >> Thanks, >> ~Chris >> (Primary Shepherd, ARIN-prop-126) > > Chris, > > In reviewing the responses to the current text I don't think this text is > ready yet. ?I think there is general support for the intent of this policy. > But there seems to be support for the change Scott is suggesting, I think it > is a good suggestion too. How did the shepherds determine that there is a real problem that this solves and that it requires a codified solution? Can you demonstrate "general support" and why general support is not anything more than disinterest? I'm curious about that since I can't see the support you describe, especially support that would insist that we continue to haggle over this. There are occasions where proposals should die and not continue to be subject to repeated edits to try and "find" an audience. Best, -M< From cgrundemann at gmail.com Tue May 17 11:01:27 2011 From: cgrundemann at gmail.com (Chris Grundemann) Date: Tue, 17 May 2011 09:01:27 -0600 Subject: [arin-ppml] New Version of ARIN-prop-126: Compliance Requirement In-Reply-To: <4DD1EF83.3070303@umn.edu> References: <4DD1EF83.3070303@umn.edu> Message-ID: On Mon, May 16, 2011 at 21:46, David Farmer wrote: > Chris, > > In reviewing the responses to the current text I don't think this text is > ready yet. ?I think there is general support for the intent of this policy. > But there seems to be support for the change Scott is suggesting, I think it > is a good suggestion too. Thanks David, I agree that further discussion is warranted, hence my stated intentions (moving the proposal forward as a draft for further discussion). Folks that are opposed to the intent of this policy should speak up if they think the discussion is complete and abandonment is more appropriate (I believe one person has thus far). For everyone's reference; the substantive changes are specific to section 12.6 of the NRPM and include: 1) Lowering the minimum time given to organizations that are out of compliance from six months to 90 days. 2) Adding the ability for ARIN to remove rDNS before revoking space with a minimum of 30 days given to orgs to respond. 3) The current proposal text requires staff to remove rDNS after an org is unresponsive for 60 days. (removing this requirement has been discussed with no objections) * The proposal retains the final sentence of that section which allows staff to provide more time where appropriate. While I do not want to rush text changes, it would be very informative to know which of the three changes are supported and/or opposed. > Additionally, I'm still not fully comfortable with the details of how > breaking RDNS will be implemented by staff. ?I'm not sure this is a policy > issue itself, but I would like to see some implementation recommendations > included, like that when RDNS service has been withdrawn that is directly > visible in Whois to everyone and there should be an alert for any ARIN > online accounts that have POCs associated with the resource, similar to how > the invalid POC thing is working now. ?If we are going to do this it needs > to jump out a bite you, right now I'm worried that it will be to subtle. Again, I agree. This is not a policy matter but should be discussed. Cheers, ~Chris > -- > =============================================== > 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 > =============================================== > -- @ChrisGrundemann weblog.chrisgrundemann.com www.burningwiththebush.com www.theIPv6experts.net www.coisoc.org From info at arin.net Tue May 17 11:05:21 2011 From: info at arin.net (ARIN) Date: Tue, 17 May 2011 11:05:21 -0400 Subject: [arin-ppml] ARIN-prop-140 Business Failure Clarification - version 2 In-Reply-To: <4DBEF0DF.8060800@arin.net> References: <4DBEF0DF.8060800@arin.net> Message-ID: <4DD28EB1.10503@arin.net> The proposal originator revised the proposal. Regards, Communications and Member Services American Registry for Internet Numbers (ARIN) ## * ## ARIN-prop-140 Business Failure Clarification Proposal Originator: Matthew Kaufman Proposal Version: 2 Date: 17 May 2011 Proposal type: new Policy term: permanent Policy statement: Modify Section 8.1. Strike "This, if a company goes out of business" and replace with "If an organization ceases to exist". Replace "must notify ARIN if a business fails" with "should notify ARIN that the organization has ceased to exist". the resultant text: "Number resources are issued, based on justified need, to organizations, not to individuals representing those organizations. If an organization ceases to exist, regardless of the reason, the point of contact (POC) listed for the number resource does not have the authority to sell, transfer, assign, or give the number resource to any other person or organization. If a transfer is not promptly requested and justified, the POC should notify ARIN that the organization has ceased to exist so the assigned number resources can be returned to the available pool of number resources." Rationale: Potential confusion exists over the requirement to return address space from a bankrupt entity. This is a needed clarification to the policy manual. This text removes any mention of special treatment of bankrupt entities that was mentioned in version 1 and which may not comply with law. "must notify" is replaced with "should notify" in order to reflect that the POC may not have the authority or permission to make the notification. Timetable for implementation: immediate ARIN wrote: > ARIN-prop-140 Business Failure Clarification > > 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-140 Business Failure Clarification > > Proposal Originator: Matthew Kaufman > > Proposal Version: 1 > > Date: 2 May 2011 > > Proposal type: new > > Policy term: permanent > > Policy statement: > > Add to end of Section 8.1: "Note that an entity which is reorganizing > under any section of the US bankruptcy code (or foreign equivalent) is > not 'out of business' for the purpose of interpreting this section" > > Rationale: > > Potential confusion exists over the requirement to return address space > from a bankrupt entity. This is a needed clarification to the policy > manual. > > Timetable for implementation: immediate > > > > > > > From info at arin.net Tue May 17 11:06:13 2011 From: info at arin.net (ARIN) Date: Tue, 17 May 2011 11:06:13 -0400 Subject: [arin-ppml] ARIN-prop-141 Combined M&A and Specified Transfers - version 2 In-Reply-To: <4DBEF0EB.5070905@arin.net> References: <4DBEF0EB.5070905@arin.net> Message-ID: <4DD28EE5.8010303@arin.net> The proposal originator revised the proposal. Regards, Communications and Member Services American Registry for Internet Numbers (ARIN) ## * ## ARIN-prop-141 Combined M&A and Specified Transfers Proposal Originator: Matthew Kaufman Proposal Version: 2 Date: 17 May 2011 Proposal type: new Policy term: permanent Policy statement: To section 8.2 change "... ARIN will work with the resource holder(s) to return, aggregate, or reclaim resources as appropriate via the processes outlined in current ARIN policy (for example, sections 4.6, 4.7, or 12 of the NRPM)." to "...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: Given that both M&A transfers and specified transfers are possible, it should be possible to execute a combined transfer in which unneeded resources are transferred via 8.3 (rather than returning unneeded resources to the free pool) and the rest are transferred via 8.2. Doing this in the wrong order (i.e., attempting to execute the 8.2 transfer first) should not penalize the transferring entity... especially as ARIN's opinion as to what is "no longer justified under ARIN policy" is best known by ARIN and may not be completely knowable by the transferring entity. Note that as there is no ARIN policy permitting IPv6 specified transfers, this policy would only affect IPv4 resources at this time. New text removes references to other NRPM sections by number, shortens text by inlining the transfer option. Timetable for implementation: immediate ARIN wrote: > ARIN-prop-141 Combined M&A and Specified Transfers > > 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-141 Combined M&A and Specified Transfers > > Proposal Originator: Matthew Kaufman > > Proposal Version: 1 > > Date: 2 May 2011 > > Proposal type: new > > Policy term: permanent > > Policy statement: > > To section 8.2 change "... ARIN will work with the resource holder(s) to > return, aggregate, or reclaim resources as appropriate via the processes > outlined in current ARIN policy (for example, sections 4.6, 4.7, or 12 > of the NRPM)." to > > "... ARIN will work with the resource holder(s) to return, aggregate, or > reclaim resources as appropriate via the processes outlined in current > ARIN policy (for example, sections 4.6, 4.7, or 12 of the NRPM), or to > transfer resources to a qualified specified recipient via the processes > outlined in current ARIN policy (section 8.3 of the NRPM)". > > Rationale: > > Given that both M&A transfers and specified transfers are possible, it > should be possible to execute a combined transfer in which unneeded > resources are transferred via 8.3 (rather than returning unneeded > resources to the free pool) and the rest are transferred via 8.2. Doing > this in the wrong order (i.e., attempting to execute the 8.2 transfer > first) should not penalize the transferring entity... especially as > ARIN's opinion as to what is "no longer justified under ARIN policy" is > best known by ARIN and may not be completely knowable by the > transferring entity. > > Note that as there is no ARIN policy permitting IPv6 specified > transfers, this policy would only affect IPv4 resources at this time. > > Timetable for implementation: immediate > > > > > > > > From info at arin.net Tue May 17 11:06:51 2011 From: info at arin.net (ARIN) Date: Tue, 17 May 2011 11:06:51 -0400 Subject: [arin-ppml] ARIN-prop-142 Define RSA - version 2 In-Reply-To: <4DBEF0F6.2050502@arin.net> References: <4DBEF0F6.2050502@arin.net> Message-ID: <4DD28F0B.3060206@arin.net> The proposal originator revised the proposal. Regards, Communications and Member Services American Registry for Internet Numbers (ARIN) ## * ## ARIN-prop-142 Define RSA Proposal Originator: Matthew Kaufman Proposal Version: 2 Date: 17 May 2011 Proposal type: new Policy term: permanent Policy statement: Add to "Definitions" the definition of "Registration Services Agreement (RSA)" - A Registration Services Agreement (RSA) is an agreement entered into between ARIN and a Local Internet Registry or End-user. The specific form of agreement is not defined in this document and may differ in its specifics from one agreement to another. The "Standard RSA" and the various forms of "Legacy Registration Services Agreement (LRSA)" are examples of such an agreement. Rationale: The term "Registration Services Agreement" is used in 4.2.1.2 and 8.1 without definition. The term RSA is used in 4.6.5 and 8.3 without definition. ARIN staff has interpreted Registration Services Agreement in 8.3 (and possibly other places) to mean "any registration services agreement" rather than "a specific, standard, and unmodified Registration Services Agreement". Readers of the NRPM have come to other conclusions. Updated version text replaces "this Internet Registry" with "ARIN". No other changes. Timetable for implementation: immediate ARIN wrote: > ARIN-prop-142 Define RSA > > 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-142 Define RSA > > Proposal Originator: Matthew Kaufman > > Proposal Version: 1 > > Date: 2 May 2011 > > Proposal type: new > > Policy term: permanent > > Policy statement: > > Add to "Definitions" the definition of "Registration Services Agreement > (RSA)" - > > A Registration Services Agreement (RSA) is an agreement entered into > between this Internet Registry and a Local Internet Registry or > End-user. The specific form of agreement is not defined in this document > and may differ in its specifics from one agreement to another. The > "Standard RSA" and the various forms of "Legacy Registration Services > Agreement (LRSA)" are examples of such an agreement. > > Rationale: > > The term "Registration Services Agreement" is used in 4.2.1.2 and 8.1 > without definition. The term RSA is used in 4.6.5 and 8.3 without > definition. > > ARIN staff has interpreted Registration Services Agreement in 8.3 (and > possibly other places) to mean "any registration services agreement" > rather than "a specific, standard, and unmodified Registration Services > Agreement". Readers of the NRPM have come to other conclusions. > > Timetable for implementation: immediate > > > > > > > > > From cengel at conxeo.com Tue May 17 11:10:59 2011 From: cengel at conxeo.com (Chris Engel) Date: Tue, 17 May 2011 11:10:59 -0400 Subject: [arin-ppml] Just a reminder of some quick mathematicsfor IPv4that shows the long term impossibility of it In-Reply-To: <700C596A-658D-4550-9FA8-5D3409FAF294@delong.com> References: <4DCC41D8.1010305@ipinc.net> <714BA22421E941B68BE3268E21738D09@mike> <4DCD9C8A.1030701@ipinc.net> <700C596A-658D-4550-9FA8-5D3409FAF294@delong.com> Message-ID: > > > > Even though I enjoy healthy debate as much as anyone, I'm not sure what > the point or relevance of this thread is? Some participants here view > universal end-to-end connectivity as an important goal and as such NAT > being significantly harmful to the internet. Others of us believe that goal is > not particularly desirable and possibly even harmful to the interests of a > portion of the community....and thus NAT has significant utility that > outweighs any potential harm. > > > > The latter view presupposes an incorrect perception of both end to end and > the capabilities of NAT. > > If you have good firewalls, there is no harm in leaving the packet header > unmangled. > > The harm from NAT is huge and the utility of NAT is demonstrably small > unless you are trying to conserve addresses. > The value of conserving addresses in IPv6 is demonstrably small, therefore, I > find it very unlikely that the utility of NAT > could possibly outweigh the harm it is known to cause. > In YOUR opinion. When a burning bush proclaims you infallible master of all technology, maybe that'll carry a little more weight. Until that happens, I'll simply maintain what common sense and my own experience tells me... that you are WRONG. Thanks. > > Much like politics or religion, I don't believe either side will be effective in > changing the others beliefs no matter how much verbiage is expended in the > effort. That seems evident by the number of times this particular discussion > has taken place on this list. Is it possible to simply agree to disagree on the > utility/harm of NAT and set aside that portion of the discussion? > > > > Not really. NAT is a toxic-polluter issue and those in favor of it are rarely its > victims. That would be sort of like > asking the residents of Bhopal to agree to disagree with Union Carbide about > the utility/harm of irresponsible > chemical processing. > I would argue that the sort of peer-to-peer applications that you guys are pushing tend to be far more "toxic polluters" of the net then NAT. However, one man's garbage is another man's treasure and I'm open minded enough not to try to argue that every single peer-to-peer operator be shut down, even if I think 90% of them are pushing dreck. The only difference is that no packets which NAT would cause a problem with happen to leave my network. While most of the peer-to-peer application developers seem to spend considerable effort in circumventing other Network Operators purposefully crafted filtering policies.... things like running over ports used by other well known protocols and even encapsulating thier traffic in other protocols in an attempt to sneak by filtering rules. > > Can we simply agree that at this particular point in time IPv4 address space > continues to have some value/use to a significant portion of the internet > community? > > I don't think that is in dispute. > > > > > If we can generally agree on that proposition, then it seems clear that ARIN > still has some responsibility for setting policies in regards assignment of that > space. The question of whether the rest of the worlds population of > human's, llama's or house flies will be able to access the internet through > IPv4 strikes me as entirely tangential to that point. > > It is tangential to that point, but, it becomes quite meaningful to the > discussion of what those policies should be. > Since this thread has covered both the fact that ARIN should continue to set > policies (which some seem to take > as opinion rather than fact) as well as several aspects of what those policies > should be, I don't think you can > discard content of the thread just because it is not relevant to one of the > topics in the thread. > Ok I'll bite. What specificaly are addressing policy implications of the assertion (IF we accept it to be true) that the entire worlds population can't/shouldn't be put on the internet with IPv4? Other then there needs to be addressing policies set for IPv6 and such space should be reasonably availble to those who need it? Neither of which seem to be in contention here? > > > > FWIW, my particular hope is that IPv6 see's a steady increase in adoption so > that people who do value publically addressable space can get it, IF they > want it....and that NAT & IPv4 (and maybe even NAT66) continue to be > available to those of us who prefer it as an option. The world is a diverse > place, I don't see why the internet should not reflect that diversity in being > able to cater to a varied and sometimes conflicting set of interests. Yes, that > adds to the complexity of the system from an engineering standpoint....but > so does manufacturing more then one size of shoe. > > > > Because ISVs won't reflect that diversity and they will limit application > features to the lowest common > denominator. I don't want to see the internet hobbled by NAT any longer > than it already has been. > If you have a problem with the type of services that are being provided by service providers, you have two options... 1) Start up your own service and offer the kind of services that you think should be offered. If you are not off-target, you'll get plenty of customers. 2) Find a vendor willing to provide the type of services you want to see and give them your business. Then promote them. If enough people agree with your preference of services, they'll be successfull and those sort of services will become more commonly available. Don't try to promote your own preferences by limiting those of others. From info at arin.net Tue May 17 11:14:29 2011 From: info at arin.net (ARIN) Date: Tue, 17 May 2011 11:14:29 -0400 Subject: [arin-ppml] ARIN-prop-143 Clarify Specified Transfer RSA Requirement - version 2 In-Reply-To: <4DBEF101.5060407@arin.net> References: <4DBEF101.5060407@arin.net> Message-ID: <4DD290D5.5030108@arin.net> The proposal originator revised the proposal. Regards, Communications and Member Services American Registry for Internet Numbers (ARIN) ## * ## ARIN-prop-143 Clarify Specified Transfer RSA Requirement Proposal Originator: Matthew Kaufman Proposal Version: 2 Date: 17 May 2011 Proposal type: new Policy term: permanent Policy statement: Replace section 8.3 "Such transferred number resources may only be received under RSA" with "Such transferred number resources may only be received under a registration services agreement" Rationale: Updated version removes language regarding Legacy->LRSA, LRSA->LRSA, RSA->RSA transfers as this will be moved to ASCP. Updated version removes language regarding deviation reporting, will be moved to ASCP. Only remaining change is to clarify that the transferred resources must be received under some registration services agreement, but not necessarily "The RSA". Timetable for implementation: immediate ARIN wrote: > ARIN-prop-143 Clarify Specified Transfer RSA Requirement > > ARIN received the following policy proposal and is posting it to the > Public Policy Mailing List (PPML) in accordance with the Policy > Development Process. > > The ARIN Advisory Council (AC) will review the proposal at their next > regularly scheduled meeting (if the period before the next regularly > scheduled meeting is less than 10 days, then the period may be extended > to the subsequent regularly scheduled meeting). The AC will decide how > to utilize the proposal and announce the decision to the PPML. > > The AC invites everyone to comment on the proposal on the PPML, > particularly their support or non-support and the reasoning > behind their opinion. Such participation contributes to a thorough > vetting and provides important guidance to the AC in their deliberations. > > Draft Policies and Proposals under discussion can be found at: > https://www.arin.net/policy/proposals/index.html > > The ARIN Policy Development Process can be found at: > https://www.arin.net/policy/pdp.html > > Mailing list subscription information can be found > at: https://www.arin.net/mailing_lists/ > > Regards, > > Communications and Member Services > American Registry for Internet Numbers (ARIN) > > > ## * ## > > > ARIN-prop-143 Clarify Specified Transfer RSA Requirement > > Proposal Originator: Matthew Kaufman > > Proposal Version: 1 > > Date: 2 May 2011 > > Proposal type: new > > Policy term: permanent > > Policy statement: > > Replace section 8.3 "Such transferred number resources may only be > received under RSA" with "Such transferred number resources may only be > received under a registration services agreement" > > Add to section 8.3 "It is the intent of this policy that the > registration services agreement under which the transferred resources > are received SHOULD be at least as restrictive as the registration > services agreement that covers these resources prior to the transfer. > Legacy resources that are not currently covered by a registration > services agreement should be received under a Legacy Registration > Services Agreement (or at the recipient's option, the standard > Registration Services Agreement). Legacy resources that are currently > covered by a Legacy Registration Services Agreement should be received > under a Legacy Registration Services Agreement which is at least as > restrictive as the previous LRSA (or at the recipient's option, the > standard Registration Services Agreement). Resources that are currently > covered under the standard Registration Services Agreement should be > received under the standard Registration Services Agreement. ARIN staff > shall report periodically on any required deviation from this paragraph, > including modifications that have been required to either the standard > forms of the LRSA or RSA." > > Rationale: > > Clarifies the NRPM to reflect policy as currently implemented and to > properly reflect that legacy resources may be received, at the option of > the recipient, under either the standard RSA or the legacy RSA. > > Also clarifies the NRPM to reflect that registration services agreements > may be modified from standard if necessary for the purposes of effecting > Section 8.3 transfers. > > Requires transparency for deviations from the recommended policy and/or > customized registration services agreements. > > Timetable for implementation: immediate > > From info at arin.net Tue May 17 11:15:03 2011 From: info at arin.net (ARIN) Date: Tue, 17 May 2011 11:15:03 -0400 Subject: [arin-ppml] ARIN-prop-146 Clarify Justified Need for Transfers - version 2 In-Reply-To: <4DBEF120.4080901@arin.net> References: <4DBEF120.4080901@arin.net> Message-ID: <4DD290F7.6070506@arin.net> The proposal originator revised the proposal. Regards, Communications and Member Services American Registry for Internet Numbers (ARIN) ## * ## ARIN-prop-146 Clarify Justified Need for Transfers Proposal Originator: Matthew Kaufman Proposal Version: 2 Date: 17 May 2011 Proposal type: new Policy term: permanent Policy statement: Add to Section 8.3 "...they can justify under current ARIN policies showing how the addresses will be utilized within 12 months." Remove from 4.2.4.4: "This reduction does not apply to resources received via section 8.3. An organization receiving a transfer under section 8.3 may continue to request up to a 12-month supply of IP addresses." Rationale: An organization which is not able to obtain its initial IPv4 address assignment from ARIN post-runout would otherwise be limited to purchasing only a 3-month supply (because the language in 4.2.4.4 regarding 8.3 transfers is not triggered). An organization which has only recently received its first allocation under the "last /8" criteria is also otherwise limited to purchasing only a 3-month supply (because the language in 4.2.4.4 is again not applicable). There is also ambiguity if 4.2.2.1.3 is applied in that a transfer to a new organization might only need to show need for a /20 (because that is what is specifically called out) even though they are receiving a much larger block. Previous version of this proposal modified Section 8 to point at 4.2.4, rather than the shorter and clearer modification to 8.3 now proposed. There is also ambiguity with regard to transfers under 8.2 where the receiving organization is a new organization... not at all clear how "justified need" has been or should be determined, however this proposal no longer addresses this. Timetable for implementation: immediate ARIN wrote: > ARIN-prop-146 Clarify Justified Need for Transfers > > 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-146 Clarify Justified Need for Transfers > > Proposal Originator: Matthew Kaufman > > Proposal Version: 1 > > Date: 2 May 2011 > > Proposal type: new > > Policy term: permanent > > Policy statement: > > Add a subsection to Section 8 (Transfers) of the NRPM: > > "Justified Need" for resources associated with a transfer shall be > determined using the "4.2.4 ISP Additional Requests" criteria applied as > though the recipient has been a subscriber member of ARIN for at least > one year (whether or not that is the case). > > Rationale: > > An organization which is not able to obtain its initial IPv4 address > assignment from ARIN post-runout would otherwise be limited to > purchasing only a 3-month supply (because the language in 4.2.4.4 > regarding 8.3 transfers is not triggered). > > An organization which has only recently received its first allocation > under the "last /8" criteria is also otherwise limited to purchasing > only a 3-month supply (because the language in 4.2.4.4 is again not > applicable). > > There is also ambiguity if 4.2.2.1.3 is applied in that a transfer to > a new organization might only need to show need for a /20 (because that > is what is specifically called out) even though they are receiving a > much larger block. > > There is also ambiguity with regard to transfers under 8.2 where the > receiving organization is a new organization... not at all clear how > "justified need" has been or should be determined. > > Timetable for implementation: immediate > > From info at arin.net Tue May 17 11:15:46 2011 From: info at arin.net (ARIN) Date: Tue, 17 May 2011 11:15:46 -0400 Subject: [arin-ppml] ARIN-prop-147 Set Transfer Need to 24 months and Clarify Exception - version 2 In-Reply-To: <4DBEF12A.2020002@arin.net> References: <4DBEF12A.2020002@arin.net> Message-ID: <4DD29122.1030306@arin.net> The proposal originator revised the proposal. Regards, Communications and Member Services American Registry for Internet Numbers (ARIN) ## * ## ARIN-prop-147 Set Transfer Need to 24 months Proposal Originator: Matthew Kaufman Proposal Version: 2 Date: 17 May 2011 Proposal type: new Policy term: permanent Policy statement: If ARIN-prop-146 passes, also modify "will be utilized within 12 months" to "will be utilized within 24 months" Rationale: Due to the complexity of the financial transaction that may be involved and the associated budgeting on the part of the receiving organization, 24 months is a more reasonable amount of forecast need to allow to be fulfilled via the transfer process. Potential benefit to address aggregation by allowing fewer larger transfers sooner. Change from previous version: uses the new language proposed in ARIN-prop-146 rather than modifying 4.2.4.4. Also no longer modifies 4.2.4.4 to apply to section 8.2 transfers. Timetable for implementation: immediate ARIN wrote: > ARIN-prop-147 Set Transfer Need to 24 months and Clarify Exception > > 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-147 Set Transfer Need to 24 months and Clarify Exception > > Proposal Originator: Matthew Kaufman > > Proposal Version: 1 > > Date: 2 May 2011 > > Proposal type: new > > Policy term: permanent > > Policy statement: > > Change section 4.2.4.4 content as follows: > > Replace: > "This reduction does not apply to resources received via section 8.3. An > organization receiving a transfer under section 8.3 may continue to > request up to a 12-month supply of IP addresses." > > With: > "This reduction does not apply to resources received via transfer. An > organization receiving a transfer under section 8 may request up to a > 24-month supply of IP addresses." > > Rationale: > > The exception should apply to transfers under 8.2 as well as 8.3 (and > any future transfer policies). > > Due to the complexity of the financial transaction that may be > involved and the associated budgeting on the part of the receiving > organization, 24 months is a more reasonable amount of forecast need to > allow to be fulfilled via the transfer process. > > Potential benefit to address aggregation by allowing fewer larger > transfers sooner. > > Timetable for implementation: immediate > > > From info at arin.net Tue May 17 11:16:55 2011 From: info at arin.net (ARIN) Date: Tue, 17 May 2011 11:16:55 -0400 Subject: [arin-ppml] ARIN-prop-150 Reclamation Hold In-Reply-To: <4DCD36FC.3000501@arin.net> References: <4DCD36FC.3000501@arin.net> Message-ID: <4DD29167.8070607@arin.net> The proposal originator sent the following regarding this proposal: "I'd like to withdraw ARIN-prop-150. I will consider submitting to ASCP. Debate on the list clearly shows that there's some who think that we should significantly shorten the hold and others who think it should be lengthened, and almost nobody who thinks it should stay at the present length." The ARIN Advisory Council will take this into consideration when they decide what to do with this proposal. Regards, Communications and Member Services American Registry for Internet Numbers (ARIN) ## * ## ARIN wrote: > ARIN-prop-150 Reclamation Hold > > 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-150 Reclamation Hold > > Proposal Originator: Matthew Kaufman > > Proposal Version: 1 > > Date: 13 May 2011 > > Proposal type: new > > Policy term: permanent > > Policy statement: > > Add a new section to the NRPM: > "All resources reclaimed by ARIN shall not be returned to the free pool > or otherwise reassigned to any entity than the original registrant for a > period of 36 months." > > Rationale: > As the pressures on the system become greater with IPv4 runout, there > will be more call for ARIN to reclaim address space. When addresses that > are reclaimed are reused too soon, a variety of undesirable outcomes may > result. This provides sufficient time for the resources to go unused > prior to reassignment and/or to be re-justified by the original > registrant, or returned to the proper holder in the case of hijackings. > This policy could be restricted to IPv4 space, but it may be useful for > AS numbers and has no major impact on IPv6 space (due to the large free > pool), so it might as well apply to all. > > Timetable for implementation: immediate > > > > > > > > > > > From info at arin.net Tue May 17 11:16:33 2011 From: info at arin.net (ARIN) Date: Tue, 17 May 2011 11:16:33 -0400 Subject: [arin-ppml] ARIN-prop-145 STLS Listing Immunity In-Reply-To: <4DBEF116.1000400@arin.net> References: <4DBEF116.1000400@arin.net> Message-ID: <4DD29151.9070908@arin.net> The proposal originator sent the following regarding this proposal: "I would like to withdrawn ARIN-prop-145 from consideration entirely." The ARIN Advisory Council will take this into consideration when they decide what to do with this proposal. Regards, Communications and Member Services American Registry for Internet Numbers (ARIN) ## * ## ARIN wrote: > ARIN-prop-145 STLS Listing Immunity > > 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-145 STLS Listing Immunity > > Proposal Originator: Matthew Kaufman > > Proposal Version: 1 > > Date: 2 May 2011 > > Proposal type: new > > Policy term: permanent > > Policy statement: > > Add a subsection to Section 12 (Resource Review) of the NRPM: > > ARIN may not revoke any resources issued by ARIN that are presently > listed as "available" on the ARIN Specified Transfer Listing Service > unless there is sufficient reason to believe that the holder does not in > fact intend to transfer these resources. > > Rationale: > > An entity may list space as available and might begin the process of > moving out of that space in order to facilitate the transfer. A review > after such work was in progress might reveal that the addresses are not > sufficiently utilized. > > Additionally, because posting a listing on the STLS signals directly to > ARIN that an entity believes it can use addresses more efficiently, ARIN > might simply use STLS listings in order to trigger audit under 12.2(c). > This would not be fair. (And would be a disincentive to using the ARIN > STLS at all in order to list available space) > > This policy would also serve to increase the value of the ARIN STLS over > other possible transfer listing services, increasing the transparency of > the transfer market, particularly to ARIN, who wishes to ensure that > transfers take place within NRPM 8.3. > > Timetable for implementation: immediate > > > > From cengel at conxeo.com Tue May 17 12:27:27 2011 From: cengel at conxeo.com (Chris Engel) Date: Tue, 17 May 2011 12:27:27 -0400 Subject: [arin-ppml] Just a reminder of some quick mathematicsfor IPv4that shows the long term impossibility of it In-Reply-To: <20110517081155.22315ac7@opy.nosense.org> References: <4DCC41D8.1010305@ipinc.net> <714BA22421E941B68BE3268E21738D09@mike> <4DCD9C8A.1030701@ipinc.net> <20110517081155.22315ac7@opy.nosense.org> Message-ID: Mark, > NAT isn't up to a matter of opinion. It is a matter of what the > Internet's design architecture is, and whether NAT can fit within that > architecture. NAT breaks end-to-end reachability and transparency > between the edges of the Internet, which is why it doesn't fit the > Internet's design architecture. > The same can be said of firewalls and spam filters and proxy servers. Guess what, VERY few people actually want "end-to-end reachability and transparency". The survey is out, privacy wins overwhelmingly. I don't WANT the inside of my network reachable and transparent to external users. Neither do the vast majority of endpoint network operators or individual users. We want to expose what we CHOOSE to advertise to the outside world....and keep everything else private....and we are willing to accept extra cost and complexity involved in running certain types of applications in order to do that. On the Enterprise side of things, of which I am very familiar, most don't tend to WANT decentralized application models (i.e. peer-to-peer). They want to mandate that applications have to go through a central known point in order to be able to function properly. That facilitates better monitoring and application of policy on said applications, as well as easier support, in many cases. > The Internet is intended to be a dumb packet switching network, not one > that has to have an understanding of the applications that are running > over it. That's the fundamental difference between the Internet and a > traditional application specific network such as the PSTN - if you want > to run something other than voice over the PSTN (e.g. fax), you have to > make it look like a phone call. If you want to run an application over > the Internet (the no-NAT Internet), you don't have to care what it > looks like, because the Internet doesn't care what the application is. > The moment you add NAT is the moment "the Internet" needs to care about > the applications because it now has to translate any addresses carried > in them. You then also introduce a performance bottle neck, another > point of application failure and a traffic interception point at the > "public server" that is acting as a relay between the true end-points. > (Imagine a birthday party where nobody can talk directly to each other, > instead, all conversations have to go through the person having the > birthday ...) > > For those in the pro-NAT camp, have a read of the following. Then if > you're still advocating NAT, you'll be more aware as to what > you're trading off. > > RFC1627 - Network 10 Considered Harmful (Some Practices Shouldn't be > Codified) > http://tools.ietf.org/html/rfc1627 > > RFC1958 - Architectural Principles of the Internet > http://tools.ietf.org/html/rfc1958 > > RFC2775 - Internet Transparency > http://tools.ietf.org/html/rfc2775 > > RFC2993 - Architectural Implications of NAT > http://tools.ietf.org/html/rfc2993 > > I know EXACTLY what NAT does. It does EXACTLY what I INTEND it to do. That's true for most network admins I'm familiar with as well as with most private individuals. I work and am friends with alot of other folks in various positions in IT. Not a single one of the people I know DOESN'T run RFC-1918 space on their home networks....and address availability has very little to do with that. The internet isn't one completely homogenous entity....it's thousands upon thousands of individual networks.... each of them has their own rules that they play by. If you don't like the rules that an individual network plays by....guess what...don't go there...chances are you aren't welcome. Christopher Engel (representing only my own views) From ikiris at gmail.com Tue May 17 12:45:18 2011 From: ikiris at gmail.com (Blake Dunlap) Date: Tue, 17 May 2011 11:45:18 -0500 Subject: [arin-ppml] Just a reminder of some quick mathematicsfor IPv4that shows the long term impossibility of it In-Reply-To: References: <4DCC41D8.1010305@ipinc.net> <714BA22421E941B68BE3268E21738D09@mike> <4DCD9C8A.1030701@ipinc.net> <20110517081155.22315ac7@opy.nosense.org> Message-ID: On Tue, May 17, 2011 at 11:27, Chris Engel wrote: > Mark, > > > NAT isn't up to a matter of opinion. It is a matter of what the > > Internet's design architecture is, and whether NAT can fit within that > > architecture. NAT breaks end-to-end reachability and transparency > > between the edges of the Internet, which is why it doesn't fit the > > Internet's design architecture. > > > > The same can be said of firewalls and spam filters and proxy servers. Guess > what, VERY few people actually want "end-to-end reachability and > transparency". The survey is out, privacy wins overwhelmingly. I don't WANT > the inside of my network reachable and transparent to external users. > Neither do the vast majority of endpoint network operators or individual > users. We want to expose what we CHOOSE to advertise to the outside > world....and keep everything else private....and we are willing to accept > extra cost and complexity involved in running certain types of applications > in order to do that. > > On the Enterprise side of things, of which I am very familiar, most don't > tend to WANT decentralized application models (i.e. peer-to-peer). They want > to mandate that applications have to go through a central known point in > order to be able to function properly. That facilitates better monitoring > and application of policy on said applications, as well as easier support, > in many cases. > > (snip) > > I know EXACTLY what NAT does. It does EXACTLY what I INTEND it to do. > That's true for most network admins I'm familiar with as well as with most > private individuals. I work and am friends with alot of other folks in > various positions in IT. Not a single one of the people I know DOESN'T run > RFC-1918 space on their home networks....and address availability has very > little to do with that. The internet isn't one completely homogenous > entity....it's thousands upon thousands of individual networks.... each of > them has their own rules that they play by. If you don't like the rules that > an individual network plays by....guess what...don't go there...chances are > you aren't welcome. > > Christopher Engel > (representing only my own views) > None of what you just said you want, has anything to do with NAT. This is what leads people to believe you don't know what NAT does, even while you yell that you do. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Wesley.E.George at sprint.com Tue May 17 12:46:53 2011 From: Wesley.E.George at sprint.com (George, Wes E [NTK]) Date: Tue, 17 May 2011 16:46:53 +0000 Subject: [arin-ppml] Draft Proposal 2011-1 - Comments request - Globally Coordinated Transfer Policy In-Reply-To: References: Message-ID: <54E900DC635DAB4DB7A6D799B3C4CD8E10D6364D@PDAWM12B.ad.sprint.com> -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Jeffrey Lyon Sent: Saturday, May 14, 2011 8:54 AM To: Bill Darte Cc: arin ppml Subject: Re: [arin-ppml] Draft Proposal 2011-1 - Comments request - Globally Coordinated Transfer Policy > I strongly oppose any measure that would open the doors to ARIN > resources flowing outside of ARIN. > > Bill, My position is that the elected officials of ARIN are accountable to ARIN region and should only be concerned with securing resources for use within ARIN. As a practical matter, every region is going to have need far beyond supply but I am not comfortable with any policy which would open the door to a decision that somehow another region's need is more important. -- Jeffrey Lyon, Leadership Team [WEG] This is exactly the sort of comment that when taken out of context (or possibly even *in* context) gives folks ammunition to point to the fact that the ARIN community is being insular and that a more "neutral" body (say... the ITU) would be better equipped to equitably manage this global resource. I agree that we don't want to give preferential treatment to any other region, but you can't have it both ways. Either all regions are on equal footing or by definition, you're saying that ARIN's needs are more important than any others. The reality is that the whole notion of keeping ARIN resources for ARIN members is a sham, because there are going to be plenty of folks who are technically members of another region (based on where their corporate offices are located) but will use the fact that they have some presence in the US to justify space in ARIN since APNIC is effectively out. To the matter of the policy - I'm in support of it as written. Wes George -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 6753 bytes Desc: not available URL: From jradel at vantage.com Tue May 17 13:13:54 2011 From: jradel at vantage.com (Jon Radel) Date: Tue, 17 May 2011 13:13:54 -0400 Subject: [arin-ppml] Just a reminder of some quick mathematicsfor IPv4that shows the long term impossibility of it In-Reply-To: References: <4DCC41D8.1010305@ipinc.net> <714BA22421E941B68BE3268E21738D09@mike> <4DCD9C8A.1030701@ipinc.net> <20110517081155.22315ac7@opy.nosense.org> Message-ID: <4DD2ACD2.8070203@vantage.com> On 5/17/11 12:45 PM, Blake Dunlap wrote: > On Tue, May 17, 2011 at 11:27, Chris Engel > wrote: > > (snip) > > > I know EXACTLY what NAT does. It does EXACTLY what I INTEND it to do. > (snip some more) > > None of what you just said you want, has anything to do with NAT. This > is what leads people to believe you don't know what NAT does, even > while you yell that you do. And even leaving that aside, I suspect most people here are at least resigned to NAT at the edge of the end-user network, where it can indeed be made to do just what the owner of the network desires, or believes he desires. What I, and I suspect many others, find much more troubling is the thought of an arbitrary number of service providers, at an arbitrary number of points on the network, performing NAT. That most assuredly will not result in exactly what the customer wants, assuming they want anything the least bit more interesting than surfing the web and picking up their e-mail. (My view on this is colored by the fact that I dislike trying to explain to customers why their SIP softphone they're trying to use on a 4th tier ISP in Egypt, which has at least 2 layers of NAT between him and the "Internet proper," just isn't going to work like it does at home.) --Jon Radel -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3648 bytes Desc: S/MIME Cryptographic Signature URL: From hannigan at gmail.com Tue May 17 13:43:11 2011 From: hannigan at gmail.com (Martin Hannigan) Date: Tue, 17 May 2011 13:43:11 -0400 Subject: [arin-ppml] Followup: ARIN-prop-139 No reassignment without network service Message-ID: I'm "shepherding" this proposal and wanted to ask if there were additional comments. It seems fair to characterize this proposal as having little support. This would include the author in a followup message to the AC regarding PP 139. Best, Martin Hannigan ARIN Advisory Council/Member On Wed, Apr 13, 2011 at 8:36 AM, Scott Helms wrote: > On 4/13/2011 1:33 AM, Owen DeLong wrote: >> >> There is not a single ARIN policy for which you are completely unable to >> engineer a sufficient workaround so as to violate its intent while still >> preserving some appearance of being close to the letter of the policy. > > True, but working around this proposal is trivial AND it fails to provide > any measurable benefit in the use case I've seen defined. ?All requiring a > network connection and BGP announcements will do is provide a method to see > who has given space and connectivity to a given "snowshoe" spammer. ?The > problem is that reallocating or reassignment _already_ provides a linkage > via the WHOIS database. > >> This is a consensus-based policy process where adherence to the policy is >> largely voluntary and where the community functions primarily on the >> expectation that most entities will act in good faith. > > So we're going to create a rule aimed at spammers and operators who sell > services to them, who are by definition not going to act in good faith, that > only operators who do work in good faith will abide by and bear the cost of? > >> Refusing to make policy more accurately and clearly describe operational >> practice will >> benefit the community. Refusing to do so merely because you cannot >> strictly and >> reliably enforce the policy in a handful of corner cases, doesn't make >> much sense. >> > > Again, this proposal does _NOT_ represent current practices. ?ARIN has known > about LIRs providing space without network connectivity for a very long time > (we've been doing it since 2003) though its not common, nor a problem, in > the region that ARIN is responsible for. ?Out of respect for my customers' > privacy I won't share their exact networks, but anyone who is curious can > look at our space and see the reallocations and reassignments. ?As I > mentioned earlier in this thread, ARIN even asked in one of the annual > surveys about the practice of reallocation without network connectivity so > framing the practice as something that hasn't been allowed is inaccurate. > > http://whois.arin.net/rest/org/ISPAL-4/nets > > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > From hannigan at gmail.com Tue May 17 14:07:53 2011 From: hannigan at gmail.com (Martin Hannigan) Date: Tue, 17 May 2011 14:07:53 -0400 Subject: [arin-ppml] ARIN-prop-147 Set Transfer Need to 24 months and Clarify Exception - version 2 In-Reply-To: <4DD29122.1030306@arin.net> References: <4DBEF12A.2020002@arin.net> <4DD29122.1030306@arin.net> Message-ID: This proposal would be better served with a 36 month window instead of 24 IMHO. 24 months is a significant improvement. Extending the window to 36 would be an even bigger improvement in terms of the ability for not only small but the largest networks to plan as well. Best, -M< On Tue, May 17, 2011 at 11:15 AM, ARIN wrote: > The proposal originator revised the proposal. > > Regards, > > Communications and Member Services > American Registry for Internet Numbers (ARIN) > > > ## * ## > > > ARIN-prop-147 Set Transfer Need to 24 months > Proposal Originator: Matthew Kaufman > Proposal Version: 2 > Date: 17 May 2011 > Proposal type: new > Policy term: permanent > Policy statement: > > If ARIN-prop-146 passes, also modify "will be utilized within 12 months" > to "will be utilized within 24 months" > > Rationale: > > Due to the complexity of the financial transaction that may be > involved and the associated budgeting on the part of the receiving > organization, 24 months is a more reasonable amount of forecast need to > allow to be fulfilled via the transfer process. > > Potential benefit to address aggregation by allowing fewer larger > transfers sooner. > > Change from previous version: uses the new language proposed in > ARIN-prop-146 rather than modifying 4.2.4.4. Also no longer modifies > 4.2.4.4 to apply to section 8.2 transfers. > > Timetable for implementation: immediate > > > ARIN wrote: >> >> ARIN-prop-147 Set Transfer Need to 24 months and Clarify Exception >> >> 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-147 Set Transfer Need to 24 months and Clarify Exception >> >> Proposal Originator: Matthew Kaufman >> >> Proposal Version: 1 >> >> Date: 2 May 2011 >> >> Proposal type: new >> >> Policy term: permanent >> >> Policy statement: >> >> Change section 4.2.4.4 content as follows: >> >> Replace: >> "This reduction does not apply to resources received via section 8.3. An >> organization receiving a transfer under section 8.3 may continue to >> request up to a 12-month supply of IP addresses." >> >> With: >> "This reduction does not apply to resources received via transfer. An >> organization receiving a transfer under section 8 may request up to a >> 24-month supply of IP addresses." >> >> Rationale: >> >> The exception should apply to transfers under 8.2 as well as 8.3 (and >> any future transfer policies). >> >> Due to the complexity of the financial transaction that may be >> involved and the associated budgeting on the part of the receiving >> organization, 24 months is a more reasonable amount of forecast need to >> allow to be fulfilled via the transfer process. >> >> Potential benefit to address aggregation by allowing fewer larger >> transfers sooner. >> >> 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 cengel at conxeo.com Tue May 17 14:33:59 2011 From: cengel at conxeo.com (Chris Engel) Date: Tue, 17 May 2011 14:33:59 -0400 Subject: [arin-ppml] Just a reminder of some quick mathematicsfor IPv4that shows the long term impossibility of it In-Reply-To: References: <4DCC41D8.1010305@ipinc.net> <714BA22421E941B68BE3268E21738D09@mike> <4DCD9C8A.1030701@ipinc.net> <20110517081155.22315ac7@opy.nosense.org> Message-ID: > > > Mark, > > > > NAT isn't up to a matter of opinion. It is a matter of what the > > Internet's design architecture is, and whether NAT can fit within > that > > architecture. NAT breaks end-to-end reachability and transparency > > between the edges of the Internet, which is why it doesn't fit the > > Internet's design architecture. > > > > > The same can be said of firewalls and spam filters and proxy servers. > Guess what, VERY few people actually want "end-to-end reachability and > transparency". The survey is out, privacy wins overwhelmingly. I don't WANT > the inside of my network reachable and transparent to external users. > Neither do the vast majority of endpoint network operators or individual > users. We want to expose what we CHOOSE to advertise to the outside > world....and keep everything else private....and we are willing to accept extra > cost and complexity involved in running certain types of applications in order > to do that. > > On the Enterprise side of things, of which I am very familiar, most > don't tend to WANT decentralized application models (i.e. peer-to-peer). > They want to mandate that applications have to go through a central known > point in order to be able to function properly. That facilitates better > monitoring and application of policy on said applications, as well as easier > support, in many cases. > > > (snip) > > > I know EXACTLY what NAT does. It does EXACTLY what I INTEND it to > do. That's true for most network admins I'm familiar with as well as with > most private individuals. I work and am friends with alot of other folks in > various positions in IT. Not a single one of the people I know DOESN'T run > RFC-1918 space on their home networks....and address availability has very > little to do with that. The internet isn't one completely homogenous > entity....it's thousands upon thousands of individual networks.... each of > them has their own rules that they play by. If you don't like the rules that an > individual network plays by....guess what...don't go there...chances are you > aren't welcome. > > > Christopher Engel > (representing only my own views) > > > > None of what you just said you want, has anything to do with NAT. This is > what leads people to believe you don't know what NAT does, even while you > yell that you do. Let's see NAT allows me to abstract the internal architecture of my network from it's externally advertised presence.... - With many:1 NAT, I can have any number of devices appear to come from a single IP address. None of those devices are addressable externally, unless they've created an entry in the NAT devices state table to an external address. Thus none of those devices are reachable from external sources even if filtering rules would otherwise allow such traffic. - With 1:1 NAT, I can advertise a particular IP on the external interface of the NAT device regardless what device(s) are actually providing that service, where they are located in the topology of my network or my internal addressing scheme. I can change any of that around internally at any time without needing to do anything with that address on my internal infrastructure and such change will be entirely invisible to the external advertisement of that service. - With 1:1 NAT with PAT, I can even have entirely separate devices provide different services on the same external IP without an external source needing to know any of the details about that (i.e. server A provides SMTP, Server B provides HTTP..... to the outside world they both sit on the same IP). - With NAT I can change ISP's at will without needing to renumber anything internally. Conversely I can change internal addressing schemes without needing to worry about messing around with external advertisement of services. Have I missed anything significant about NAT's function? The fact that NAT also makes it much more difficult for certain peer-to-peer apps to function doesn't happen to mean squat to me, since I have no desire to use those apps in the first place....and the fact that I may need to take some extra steps to allow them to function is nothing but a bonus to me. As far as CGN, that's a discussion that belongs between the service provider and their customers. If the vendor want to provide it and the customer wants to buy it and is happy with the service it provides them....it REALLY is no-one else's business to tell them they shouldn't. If that makes an application vendors life more difficult....well no-one is holding a gun to their head telling them they have to support their applications functioning through NAT. You can tell your customers that you don't support NAT if you want....just like a website author can refuse to support certain browsers. If your customers are choosing NAT over your application....well that's your problem....welcome to the free market. FWIW, I'm still waiting for some-one to explain exactly how any of this has jack-all to do with number resource policy? Christopher Engel (representing only my own views) From lar at mwtcorp.net Tue May 17 14:41:46 2011 From: lar at mwtcorp.net (Larry Ash) Date: Tue, 17 May 2011 12:41:46 -0600 Subject: [arin-ppml] Just a reminder of some quick mathematicsfor IPv4that shows the long term impossibility of it In-Reply-To: References: <4DCC41D8.1010305@ipinc.net> <714BA22421E941B68BE3268E21738D09@mike> <4DCD9C8A.1030701@ipinc.net> <20110517081155.22315ac7@opy.nosense.org> Message-ID: Hi Chris, I resisted for so long but I have to reply-- Chris Engel wrote: > Mark, > >> NAT isn't up to a matter of opinion. It is a matter of what the >> Internet's design architecture is, and whether NAT can fit within that >> architecture. NAT breaks end-to-end reachability and transparency >> between the edges of the Internet, which is why it doesn't fit the >> Internet's design architecture. >> > > The same can be said of firewalls and spam filters and proxy servers. >Guess what, VERY few people actually want "end-to-end reachability and >transparency". The survey is out, privacy wins overwhelmingly. I don't WANT >the inside of my network reachable and transparent to external users. >Neither do the vast majority of endpoint network operators or individual >users. We want to expose what we CHOOSE to advertise to the outside >world....and keep everything else private....and we are willing to accept >extra cost and complexity involved in running certain types of applications >in order to do that. > > On the Enterprise side of things, of which I am very familiar, most don't >tend to WANT decentralized application models (i.e. peer-to-peer). They >want to mandate that applications have to go through a central known point >in order to be able to function properly. That facilitates better >monitoring and application of policy on said applications, as well as >easier support, in many cases. > They sure bitch like mad when they have a voice call with one-way audio or some other service that they want to "just work" that doesn't until someone manually configures a work-around into their equipment. > >> The Internet is intended to be a dumb packet switching network, not one >> that has to have an understanding of the applications that are running >> over it. That's the fundamental difference between the Internet and a >> traditional application specific network such as the PSTN - if you want >> to run something other than voice over the PSTN (e.g. fax), you have to >> make it look like a phone call. If you want to run an application over >> the Internet (the no-NAT Internet), you don't have to care what it >> looks like, because the Internet doesn't care what the application is. >> The moment you add NAT is the moment "the Internet" needs to care about >> the applications because it now has to translate any addresses carried >> in them. You then also introduce a performance bottle neck, another >> point of application failure and a traffic interception point at the >> "public server" that is acting as a relay between the true end-points. >> (Imagine a birthday party where nobody can talk directly to each other, >> instead, all conversations have to go through the person having the >> birthday ...) >> >> For those in the pro-NAT camp, have a read of the following. Then if >> you're still advocating NAT, you'll be more aware as to what >> you're trading off. >> >> RFC1627 - Network 10 Considered Harmful (Some Practices Shouldn't be >> Codified) >> http://tools.ietf.org/html/rfc1627 >> >> RFC1958 - Architectural Principles of the Internet >> http://tools.ietf.org/html/rfc1958 >> >> RFC2775 - Internet Transparency >> http://tools.ietf.org/html/rfc2775 >> >> RFC2993 - Architectural Implications of NAT >> http://tools.ietf.org/html/rfc2993 >> >> > > I know EXACTLY what NAT does. It does EXACTLY what I INTEND it to do. > That's true for most network admins I'm familiar with as well as with most >private individuals. I work and am friends with alot of other folks in >various positions in IT. Not a single one of the people I know DOESN'T run >RFC-1918 space on their home networks....and address availability has very >little to do with that. The internet isn't one completely homogenous >entity....it's thousands upon thousands of individual networks.... each of >them has their own rules that they play by. If you don't like the rules >that an individual network plays by....guess what...don't go >there...chances are you aren't welcome. > Unfortunately NAT is a category not an implementation. Most vendors implementation differ in subtle ways. That's the rub. You can make it work the way you want but does that allow my equipment to know what you've done to compensate? When a user calls and complains all too often my techs have to find out if NAT is in place, what device is in use, and which version of software in order to suggest configurations that will allow our systems to know to proxy that call without forcing a proxy of everything including interoffice calls. Sometimes proxy everything is the only answer but I sell bandwidth too so I guess that is ok if it's my customer? Can I make NAT work. Sure, if I get to pick the hardware and certain configuration details I can make it work every time (for my equipment). But as you point out it isn't a homogeneous Internet. I just get tired of paying the support cost for someone else to buy a $40 box and press the NAT button and now it's my problem instead if his. But he sure is secure!! Should networks use NAT, probably for many (IPV4), but it requires a good deal more skill to debug issues than many small customers have access to. Should every ISP install CGN. That has potential to cause major problems much like an ISP installing one firewall and one set of policies for all customers. For my mind its more a case of: Do you want a date with the prom queen or just a picture of the prom queen. Sometimes a picture is all that there is but if there is any way I'll take the date. Seems to me that many pro-NAT voices are more interested in how they do something than what they are trying to accomplish. Weird. > Christopher Engel > (representing only my own views) > > > _______________________________________________ > 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 lar at mwtcorp.net Tue May 17 14:53:52 2011 From: lar at mwtcorp.net (Larry Ash) Date: Tue, 17 May 2011 12:53:52 -0600 Subject: [arin-ppml] ARIN-prop-147 Set Transfer Need to 24 months and Clarify Exception - version 2 In-Reply-To: References: <4DBEF12A.2020002@arin.net> <4DD29122.1030306@arin.net> Message-ID: I oppose either 24 or 36 month requirement. I think what we have is by far better. I oppose micro-managing staff by fine tuning policy to remove reasonable wiggle room. The staff does an overall good job lets not mandate that they quit doing that. Larry Ash POE CBS-129 Martin Hannigan wrote: > This proposal would be better served with a 36 month window instead of > 24 IMHO. 24 months is a significant improvement. Extending the window > to 36 would be an even bigger improvement in terms of the ability for > not only small but the largest networks to plan as well. > > Best, > > -M< > > > > On Tue, May 17, 2011 at 11:15 AM, ARIN wrote: >> The proposal originator revised the proposal. >> >> Regards, >> >> Communications and Member Services >> American Registry for Internet Numbers (ARIN) >> >> >> ## * ## >> >> >> ARIN-prop-147 Set Transfer Need to 24 months >> Proposal Originator: Matthew Kaufman >> Proposal Version: 2 >> Date: 17 May 2011 >> Proposal type: new >> Policy term: permanent >> Policy statement: >> >> If ARIN-prop-146 passes, also modify "will be utilized within 12 months" >> to "will be utilized within 24 months" >> >> Rationale: >> >> Due to the complexity of the financial transaction that may be >> involved and the associated budgeting on the part of the receiving >> organization, 24 months is a more reasonable amount of forecast need to >> allow to be fulfilled via the transfer process. >> >> Potential benefit to address aggregation by allowing fewer larger >> transfers sooner. >> >> Change from previous version: uses the new language proposed in >> ARIN-prop-146 rather than modifying 4.2.4.4. Also no longer modifies >> 4.2.4.4 to apply to section 8.2 transfers. >> >> Timetable for implementation: immediate >> >> >> ARIN wrote: >>> >>> ARIN-prop-147 Set Transfer Need to 24 months and Clarify Exception >>> >>> 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-147 Set Transfer Need to 24 months and Clarify Exception >>> >>> Proposal Originator: Matthew Kaufman >>> >>> Proposal Version: 1 >>> >>> Date: 2 May 2011 >>> >>> Proposal type: new >>> >>> Policy term: permanent >>> >>> Policy statement: >>> >>> Change section 4.2.4.4 content as follows: >>> >>> Replace: >>> "This reduction does not apply to resources received via section 8.3. An >>> organization receiving a transfer under section 8.3 may continue to >>> request up to a 12-month supply of IP addresses." >>> >>> With: >>> "This reduction does not apply to resources received via transfer. An >>> organization receiving a transfer under section 8 may request up to a >>> 24-month supply of IP addresses." >>> >>> Rationale: >>> >>> The exception should apply to transfers under 8.2 as well as 8.3 (and >>> any future transfer policies). >>> >>> Due to the complexity of the financial transaction that may be >>> involved and the associated budgeting on the part of the receiving >>> organization, 24 months is a more reasonable amount of forecast need to >>> allow to be fulfilled via the transfer process. >>> >>> Potential benefit to address aggregation by allowing fewer larger >>> transfers sooner. >>> >>> 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. Larry Ash Network Administrator Mountain West Telephone 123 W 1st St. Casper, WY 82601 Office 307 233-8387 From jeffrey.lyon at blacklotus.net Tue May 17 16:33:22 2011 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Tue, 17 May 2011 16:33:22 -0400 Subject: [arin-ppml] ARIN-prop-147 Set Transfer Need to 24 months and Clarify Exception - version 2 In-Reply-To: References: <4DBEF12A.2020002@arin.net> <4DD29122.1030306@arin.net> Message-ID: I support 24 months and 36 months even more so. Jeff On Tue, May 17, 2011 at 2:53 PM, Larry Ash wrote: > I oppose either 24 or 36 month requirement. > I think what we have is by far better. > I oppose micro-managing staff by fine tuning policy to remove reasonable > wiggle room. > The staff does an overall good job lets not mandate that they quit doing > that. > > Larry Ash > POE CBS-129 > > > > ?Martin Hannigan wrote: >> >> This proposal would be better served with a 36 month window instead of >> 24 IMHO. 24 months is a significant improvement. Extending the window >> to 36 would be an even bigger improvement in terms of the ability for >> not only small but the largest networks to plan as well. >> >> Best, >> >> -M< >> >> >> >> On Tue, May 17, 2011 at 11:15 AM, ARIN wrote: >>> >>> The proposal originator revised the proposal. >>> >>> Regards, >>> >>> Communications and Member Services >>> American Registry for Internet Numbers (ARIN) >>> >>> >>> ## * ## >>> >>> >>> ARIN-prop-147 Set Transfer Need to 24 months >>> Proposal Originator: Matthew Kaufman >>> Proposal Version: 2 >>> Date: 17 May 2011 >>> Proposal type: new >>> Policy term: permanent >>> Policy statement: >>> >>> If ARIN-prop-146 passes, also modify "will be utilized within 12 months" >>> to "will be utilized within 24 months" >>> >>> Rationale: >>> >>> Due to the complexity of the financial transaction that may be >>> involved and the associated budgeting on the part of the receiving >>> organization, 24 months is a more reasonable amount of forecast need to >>> allow to be fulfilled via the transfer process. >>> >>> Potential benefit to address aggregation by allowing fewer larger >>> transfers sooner. >>> >>> Change from previous version: uses the new language proposed in >>> ARIN-prop-146 rather than modifying 4.2.4.4. Also no longer modifies >>> 4.2.4.4 to apply to section 8.2 transfers. >>> >>> Timetable for implementation: immediate >>> >>> >>> ARIN wrote: >>>> >>>> ARIN-prop-147 Set Transfer Need to 24 months and Clarify Exception >>>> >>>> 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-147 Set Transfer Need to 24 months and Clarify Exception >>>> >>>> Proposal Originator: Matthew Kaufman >>>> >>>> Proposal Version: 1 >>>> >>>> Date: 2 May 2011 >>>> >>>> Proposal type: new >>>> >>>> Policy term: permanent >>>> >>>> Policy statement: >>>> >>>> Change section 4.2.4.4 content as follows: >>>> >>>> Replace: >>>> "This reduction does not apply to resources received via section 8.3. An >>>> organization receiving a transfer under section 8.3 may continue to >>>> request up to a 12-month supply of IP addresses." >>>> >>>> With: >>>> "This reduction does not apply to resources received via transfer. An >>>> organization receiving a transfer under section 8 may request up to a >>>> 24-month supply of IP addresses." >>>> >>>> Rationale: >>>> >>>> The exception should apply to transfers under 8.2 as well as 8.3 (and >>>> any future transfer policies). >>>> >>>> Due to the complexity of the financial transaction that may be >>>> involved and the associated budgeting on the part of the receiving >>>> organization, 24 months is a more reasonable amount of forecast need to >>>> allow to be fulfilled via the transfer process. >>>> >>>> Potential benefit to address aggregation by allowing fewer larger >>>> transfers sooner. >>>> >>>> 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. > > 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. > -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications - AS32421 First and Leading in DDoS Protection Solutions From ipng at 69706e6720323030352d30312d31340a.nosense.org Tue May 17 17:36:27 2011 From: ipng at 69706e6720323030352d30312d31340a.nosense.org (Mark Smith) Date: Wed, 18 May 2011 07:06:27 +0930 Subject: [arin-ppml] Just a reminder of some quick mathematicsfor IPv4that shows the long term impossibility of it In-Reply-To: References: <4DCC41D8.1010305@ipinc.net> <714BA22421E941B68BE3268E21738D09@mike> <4DCD9C8A.1030701@ipinc.net> <20110517081155.22315ac7@opy.nosense.org> Message-ID: <20110518070627.07cb3227@opy.nosense.org> On Tue, 17 May 2011 12:27:27 -0400 Chris Engel wrote: > Mark, > > > NAT isn't up to a matter of opinion. It is a matter of what the > > Internet's design architecture is, and whether NAT can fit within that > > architecture. NAT breaks end-to-end reachability and transparency > > between the edges of the Internet, which is why it doesn't fit the > > Internet's design architecture. > > > > The same can be said of firewalls and spam filters and proxy servers. Guess what, VERY few people actually want "end-to-end reachability and transparency". The survey is out, privacy wins overwhelmingly. I don't WANT the inside of my network reachable and transparent to external users. Neither do the vast majority of endpoint network operators or individual users. We want to expose what we CHOOSE to advertise to the outside world....and keep everything else private....and we are willing to accept extra cost and complexity involved in running certain types of applications in order to do that. > > On the Enterprise side of things, of which I am very familiar, most don't tend to WANT decentralized application models (i.e. peer-to-peer). They want to mandate that applications have to go through a central known point in order to be able to function properly. That facilitates better monitoring and application of policy on said applications, as well as easier support, in many cases. > > > > The Internet is intended to be a dumb packet switching network, not one > > that has to have an understanding of the applications that are running > > over it. That's the fundamental difference between the Internet and a > > traditional application specific network such as the PSTN - if you want > > to run something other than voice over the PSTN (e.g. fax), you have to > > make it look like a phone call. If you want to run an application over > > the Internet (the no-NAT Internet), you don't have to care what it > > looks like, because the Internet doesn't care what the application is. > > The moment you add NAT is the moment "the Internet" needs to care about > > the applications because it now has to translate any addresses carried > > in them. You then also introduce a performance bottle neck, another > > point of application failure and a traffic interception point at the > > "public server" that is acting as a relay between the true end-points. > > (Imagine a birthday party where nobody can talk directly to each other, > > instead, all conversations have to go through the person having the > > birthday ...) > > > > For those in the pro-NAT camp, have a read of the following. Then if > > you're still advocating NAT, you'll be more aware as to what > > you're trading off. > > > > RFC1627 - Network 10 Considered Harmful (Some Practices Shouldn't be > > Codified) > > http://tools.ietf.org/html/rfc1627 > > > > RFC1958 - Architectural Principles of the Internet > > http://tools.ietf.org/html/rfc1958 > > > > RFC2775 - Internet Transparency > > http://tools.ietf.org/html/rfc2775 > > > > RFC2993 - Architectural Implications of NAT > > http://tools.ietf.org/html/rfc2993 > > > > > > I know EXACTLY what NAT does. It does EXACTLY what I INTEND it to do. That's true for most network admins I'm familiar with as well as with most private individuals. I work and am friends with alot of other folks in various positions in IT. Not a single one of the people I know DOESN'T run RFC-1918 space on their home networks....and address availability has very little to do with that. The internet isn't one completely homogenous entity....it's thousands upon thousands of individual networks.... each of them has their own rules that they play by. If you don't like the rules that an individual network plays by....guess what...don't go there...chances are you aren't welcome. > So you're saying you're going to choose to remain ignorant about NAT's limitations, and the greater Internet architecture? > Christopher Engel > (representing only my own views) > From scottleibrand at gmail.com Tue May 17 18:02:07 2011 From: scottleibrand at gmail.com (Scott Leibrand) Date: Tue, 17 May 2011 15:02:07 -0700 Subject: [arin-ppml] New Version of ARIN-prop-126: Compliance Requirement In-Reply-To: References: <4DD1EF83.3070303@umn.edu> Message-ID: On Tue, May 17, 2011 at 8:01 AM, Chris Grundemann wrote: > On Mon, May 16, 2011 at 21:46, David Farmer wrote: > >> Chris, >> >> In reviewing the responses to the current text I don't think this text is >> ready yet. ?I think there is general support for the intent of this policy. >> But there seems to be support for the change Scott is suggesting, I think it >> is a good suggestion too. > > Thanks David, I agree that further discussion is warranted, hence my > stated intentions (moving the proposal forward as a draft for further > discussion). Folks that are opposed to the intent of this policy > should speak up if they think the discussion is complete and > abandonment is more appropriate (I believe one person has thus far). > > For everyone's reference; the substantive changes are specific to > section 12.6 of the NRPM and include: > 1) Lowering the minimum time given to organizations that are out of > compliance from six months to 90 days. > 2) Adding the ability for ARIN to remove rDNS before revoking space > with a minimum of 30 days given to orgs to respond. > 3) The current proposal text requires staff to remove rDNS after an > org is unresponsive for 60 days. (removing this requirement has been > discussed with no objections) > * The proposal retains the final sentence of that section which allows > staff to provide more time where appropriate. > > While I do not want to rush text changes, it would be very informative > to know which of the three changes are supported and/or opposed. FWIW, I'm agnostic on #1, in support of #2, and would like to remove requirement #3. I think there's another aspect to this proposal that's worth highlighting: it adds the phrase "update reassignment information or" to 12.4, which would then read: "Organizations found by ARIN to be out of compliance with current ARIN policy shall be required to update reassignment information or return resources as needed to bring them into (or reasonably close to) compliance." At the San Juan meeting, we had some lunch topic tables, and one of the topics was this proposal. Several interested folks attended and discussed the proposal. The main concern I recall being expressed was from some law enforcement folks, who were worried that as we move to an IPv6-only world, where organizations don't have to come back for new space every year or two, there will be less and less incentive to keep whois reassignment information up to date. This proposal is an attempt to make sure that there is at least some ability for ARIN to enforce existing whois policy once we reach IPv6 steady state. So, if anyone has any thoughts on how whois should work, and how we should balance the interests of the community in accurate reassignment information in whois against the interests of organizations in doing less work, now would be a good time to speak up. :-) -Scott From ikiris at gmail.com Tue May 17 19:18:02 2011 From: ikiris at gmail.com (Blake Dunlap) Date: Tue, 17 May 2011 18:18:02 -0500 Subject: [arin-ppml] Just a reminder of some quick mathematicsfor IPv4that shows the long term impossibility of it In-Reply-To: References: <4DCC41D8.1010305@ipinc.net> <714BA22421E941B68BE3268E21738D09@mike> <4DCD9C8A.1030701@ipinc.net> <20110517081155.22315ac7@opy.nosense.org> Message-ID: > - With many:1 NAT, I can have any number of devices appear to come from > a single IP address. None of those devices are addressable externally, > unless they've created an entry in the NAT devices state table to an > external address. Thus none of those devices are reachable from external > sources even if filtering rules would otherwise allow such traffic Yes, double the work is security. Screen doors and such on a Vault. > - With 1:1 NAT, I can advertise a particular IP on the external interface > of the NAT device regardless what device(s) are actually providing that > service, where they are located in the topology of my network or my internal > addressing scheme. I can change any of that around internally at any time > without needing to do anything with that address on my internal > infrastructure and such change will be entirely invisible to the external > advertisement of that service. > I like 1-1 NAT, it is the one case that makes sense, provided it is complete, but you are speciously excluding the requirement of external advertisement needing change either way, you still have to update all external services to use the new external addressing. Also, the goal with this is multiple addressing in IPv6, not external NAT with a single address pool. Different, not gone. > - With 1:1 NAT with PAT, I can even have entirely separate devices > provide different services on the same external IP without an external > source needing to know any of the details about that (i.e. server A provides > SMTP, Server B provides HTTP..... to the outside world they both sit on the > same IP). > This does *not* require full NAT. There are a great many services that do this, look into load balancing for a start. > > - With NAT I can change ISP's at will without needing to renumber > anything internally. Conversely I can change internal addressing schemes > without needing to worry about messing around with external advertisement of > services. > You double posted this one point, to try to make it look like NAT has more usefulness. See above point on 1-1 NAT > > Have I missed anything significant about NAT's function > > The fact that NAT also makes it much more difficult for certain > peer-to-peer apps to function doesn't happen to mean squat to me, since I > have no desire to use those apps in the first place....and the fact that I > may need to take some extra steps to allow them to function is nothing but a > bonus to me. > It's not all about you. This is standards development, not your network development. All needs must be considered. It is much less work for you to do things properly, than to force the rest of the world to do a lot of work so you can be lazy. > > As far as CGN, that's a discussion that belongs between the service > provider and their customers. If the vendor want to provide it and the > customer wants to buy it and is happy with the service it provides > them....it REALLY is no-one else's business to tell them they shouldn't. If > that makes an application vendors life more difficult....well no-one is > holding a gun to their head telling them they have to support their > applications functioning through NAT. You can tell your customers that you > don't support NAT if you want....just like a website author can refuse to > support certain browsers. If your customers are choosing NAT over your > application....well that's your problem....welcome to the free market. > Actually, that is what protocol designers and stewards do. They design standard protocols for intercommunication. It's part of the job description. > > FWIW, I'm still waiting for some-one to explain exactly how any of this has > jack-all to do with number resource policy? > > How doesn't a protocol designed for number resource (and only number resource) over-subscription not have anything to do with number resource policy? > Christopher Engel > (representing only my own views) > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mysidia at gmail.com Tue May 17 19:41:26 2011 From: mysidia at gmail.com (Jimmy Hess) Date: Tue, 17 May 2011 18:41:26 -0500 Subject: [arin-ppml] ARIN-prop-145 STLS Listing Immunity In-Reply-To: <4DBEF116.1000400@arin.net> References: <4DBEF116.1000400@arin.net> Message-ID: On Mon, May 2, 2011 at 12:59 PM, ARIN wrote: > > ARIN may not revoke any resources issued by ARIN that are presently > listed as "available" on the ARIN Specified Transfer Listing Service > unless there is sufficient reason to believe that the holder does not in > fact intend to transfer these resources. I am opposed to ARIN giving resource holders an unlimited pass on policy and efficient utilization, just because they have resources listed in the STLS or anywhere else. This could encourage an organization to apply for resources they don't need, and list those resources in the STLS, to protect those resources from revokation, even if there are other reasons for a review of the allocation. They could list on the STLS, and demand unreasonably high consideration to effect transfer, so no one wants to deal with them; then they can abuse STLS to maintain permanent immunity... I suggest instead a 12 month 'grace period'/waiver for resource holders who can show that they _were_ utilizing IP resources efficiently, on the date they apply for the grace period, but have decided to go through the trouble of renumbering or ceasing use of some address space in order to release it or transfer it; extendable to 24 months. Providing they fill out some form, submit it to ARIN, and pay a fee similar to the STLS fee. e.g. "Statement of intent to renumber and transfer/return resources" They will need to identify which resources they intend to transfer. The resources must still be efficiently used as of the date of the application. I suggest that if they file that form, and have not performed some action that requires ARIN to review their resources , and ARIN has not already started a review or inquiry into their resources in suspicion of fraud or error, they receive a grace period against future resource reviews, with regards to their change in utilization _after_ the date they completed the form, On the condition they maintain their account in good standing with ARIN for the duration of the waiver and do not apply for or receive additional number resources of the same type. ARIN will treat their utilization of that block (for any review purposes), as the same as the utilization on the date the form was filed. If the allocation was properly utilized on the date the form was submitted, then the resources will not be subject to revokation until the waiver period lapses. If they choose not to file the form, then their resources might be reviewed as normal, and STLS listing might contribute to ARIN's reasoning. Other types of resources, and other allocations not intended to be returned still subject to resource review. If the filed the intent, but have not transferred the resources within the waiver period, have not received an extension, then ARIN may consider a resource review based on failure to transfer, or ARIN may ask them to explain why they have withdrawn from their intent to release resources. -- -JH From mksmith at adhost.com Tue May 17 20:11:08 2011 From: mksmith at adhost.com (Michael K. Smith - Adhost) Date: Wed, 18 May 2011 00:11:08 +0000 Subject: [arin-ppml] Just a reminder of some quick mathematicsfor IPv4that shows the long term impossibility of it In-Reply-To: Message-ID: On 5/17/11 11:33 AM, "Chris Engel" wrote: > >FWIW, I'm still waiting for some-one to explain exactly how any of this >has jack-all to do with number resource policy? > >Christopher Engel >(representing only my own views) This is the one thing we agree on. RFC 1918 was implemented to address a resource starvation problem. We don't have that with IPv6, so we don't need a similar RFC for IPv6. If anyone says differently, they haven't read the RFC. If you want to NAT your NAT's NATs, go right ahead. I said the same thing to the Netware guys about IPX/SPX routing 15 years ago. You can only fight the "where are they now file" for some finite period of time. You get to pick what finite is for your environment. Mike From ikiris at gmail.com Tue May 17 22:03:55 2011 From: ikiris at gmail.com (Blake Dunlap) Date: Tue, 17 May 2011 21:03:55 -0500 Subject: [arin-ppml] ARIN-prop-145 STLS Listing Immunity In-Reply-To: References: <4DBEF116.1000400@arin.net> Message-ID: Also opposed as written. Would not be opposed if this had other strings attached, like outlined in one of my previous comments, but this is not enough. -Blake -------------- next part -------------- An HTML attachment was scrubbed... URL: From jeffrey.lyon at blacklotus.net Wed May 18 03:13:34 2011 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Wed, 18 May 2011 03:13:34 -0400 Subject: [arin-ppml] Draft Proposal 2011-1 - Comments request - Globally Coordinated Transfer Policy In-Reply-To: <54E900DC635DAB4DB7A6D799B3C4CD8E10D6364D@PDAWM12B.ad.sprint.com> References: <54E900DC635DAB4DB7A6D799B3C4CD8E10D6364D@PDAWM12B.ad.sprint.com> Message-ID: On Tue, May 17, 2011 at 12:46 PM, George, Wes E [NTK] wrote: > > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Jeffrey Lyon > Sent: Saturday, May 14, 2011 8:54 AM > To: Bill Darte > Cc: arin ppml > Subject: Re: [arin-ppml] Draft Proposal 2011-1 - Comments request - Globally Coordinated Transfer Policy > >> I strongly oppose any measure that would open the doors to ARIN >> resources flowing outside of ARIN. >> >> > > Bill, > > My position is that the elected officials of ARIN are accountable to ARIN region and should only be concerned with securing > resources for use within ARIN. > > As a practical matter, every region is going to have need far beyond supply but I am not comfortable with any policy which would > open the door to a decision that somehow another region's need is more important. > > -- > Jeffrey Lyon, Leadership Team > > [WEG] This is exactly the sort of comment that when taken out of context (or possibly even *in* context) gives folks ammunition to > point to the fact that the ARIN community is being insular and that a more "neutral" body (say... the ITU) would be better equipped > to equitably manage this global resource. > I agree that we don't want to give preferential treatment to any other region, but you can't have it both ways. Either all regions > are on equal footing or by definition, you're saying that ARIN's needs are more important than any others. The reality is that the > whole notion of keeping ARIN resources for ARIN members is a sham, because there are going to be plenty of folks who are technically > members of another region (based on where their corporate offices are located) but will use the fact that they have some presence in > the US to justify space in ARIN since APNIC is effectively out. > > To the matter of the policy - I'm in support of it as written. > > Wes George > For matter of record, I do regard ARIN's need as more important than any region. IANA already gave sufficient space to the other RIR's, let them worry about themselves and we will worry about us. We should not be developing policy with the aim of extending support to other regions. -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications - AS32421 First and Leading in DDoS Protection Solutions From ipng at 69706e6720323030352d30312d31340a.nosense.org Wed May 18 04:35:49 2011 From: ipng at 69706e6720323030352d30312d31340a.nosense.org (Mark Smith) Date: Wed, 18 May 2011 18:05:49 +0930 Subject: [arin-ppml] Just a reminder of some quick mathematicsfor IPv4that shows the long term impossibility of it In-Reply-To: References: <4DCC41D8.1010305@ipinc.net> <714BA22421E941B68BE3268E21738D09@mike> <4DCD9C8A.1030701@ipinc.net> <20110517081155.22315ac7@opy.nosense.org> Message-ID: <20110518180549.20588961@opy.nosense.org> On Tue, 17 May 2011 18:18:02 -0500 Blake Dunlap wrote: > > > > It's not all about you. This is standards development, not your network > development. All needs must be considered. It is much less work for you to > do things properly, than to force the rest of the world to do a lot of work > so you can be lazy. > +1 From cengel at conxeo.com Wed May 18 09:43:04 2011 From: cengel at conxeo.com (Chris Engel) Date: Wed, 18 May 2011 09:43:04 -0400 Subject: [arin-ppml] Just a reminder of some quick mathematicsfor IPv4that shows the long term impossibility of it In-Reply-To: <20110518180549.20588961@opy.nosense.org> References: <4DCC41D8.1010305@ipinc.net> <714BA22421E941B68BE3268E21738D09@mike> <4DCD9C8A.1030701@ipinc.net> <20110517081155.22315ac7@opy.nosense.org> , <20110518180549.20588961@opy.nosense.org> Message-ID: On Tue, 17 May 2011 18:18:02 -0500 Blake Dunlap wrote: > > > > It's not all about you. This is standards development, not your network > development. All needs must be considered. It is much less work for you to > do things properly, than to force the rest of the world to do a lot of work > so you can be lazy. > Until there is an official anouncement apointing you "king of the internet" you don't get to dictate what anyone else impliments on thier own networks. Write standards till your blue in the face. It's not going to stop people from implimenting what makes sense to them. It won't stop vendors from designing and selling solutions that they percieve thier customers want and it won't stop people from voting with thier feet and thier wallets. Right now the populace of the net has overwhelmingly voted for NAT over IPv6. The comparitive adoption rates of both make that evident. Maybe that'll change in future, maybe not. One thing I'm fairly certain about, as much as some might wish to wax poetic about the "end to end" design of the internet.... the actual users of the internet are overwhelmingly picking other priorties over that, deal with it. Either way, you don't get more then one vote among the billions...no matter how many standards you participate in developing. Christopher Engel From john.sweeting at twcable.com Wed May 18 10:32:47 2011 From: john.sweeting at twcable.com (Sweeting, John) Date: Wed, 18 May 2011 10:32:47 -0400 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate In-Reply-To: <7F5FC4554E42430FADDC0D376164DFA0@mike> Message-ID: Hello PPML, I wanted to take a second to provide some clarity on this particular email thread to ensure that everyone's expectations are the same. ARIN Staff touched base with the Proposal Originator (Mike Burns) and it was confirmed by Mike that his intent on sending this to PPML was not to formally submit it but to get feedback from the community prior to formally submitting. With that in mind, this proposal has not been assigned a Policy Proposal number as yet and AC shepherds have not been assigned. Thanks, John AC Chair On 5/11/11 2:03 PM, "Mike Burns" wrote: 1. Policy Proposal Name: IPv4 Transfer Policy Change to Keep Whois Accurate 2. Proposal Originator: a. Name: Mike Burns b. Email: mike at sum.net c. Phone: 1-863-494-7692 x105 d. Organization: Nationwide Computer Systems 3. Proposal Version: 1 4. Date: May 11th, 2011 5. Proposal type: modify 6. Policy term: permanent 7. Policy statement: Replace Section 8.3 with 8.3 ARIN will process and record IPv4 address transfer requests. Conditions on the IPv4 address block: - The minimum transfer size is a /24 - The address block must be in the range of addresses administered by ARIN Conditions on source of the transfer: - The source entity must be the current rights 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 the transfer, or until the exhaustion of ARIN's IPv4 space, whichever occurs first. - The source entity must not have received an allocation from ARIN for the 12 months prior to the transfer. Conditions on recipient of the transfer: - The recipient entity must be a current ARIN account holder. - The recipient must sign an RSA with ARIN. - The recipient entity of the transferred resources will be subject to current ARIN policies. In particular, in any subsequent ARIN IPv4 address allocation request, the recipient will be required to account for the efficient utilization of all IPv4 address space held, including all transferred resources. and request the AC to modify section 8 of the current RSA to remove references to "intended purposes." Replace ARIN may review, at any time, Applicant's use of previously allocated or assigned number resources or Services received from ARIN to determine if Applicant is complying with this Agreement and the Policies and is using the Services for their intended purposes. Without limiting the foregoing, if Applicant is a holder of a direct allocation or assignment from ARIN, Applicant agrees that it will use the number resources solely for uses consistent with its application and this Agreement, including, for example, its internal infrastructure or to provide Internet access to its customer base. If ARIN determines that the number resources or any other Services are not being used in compliance with this Agreement, the Policies, or the purposes for which they are intended, ARIN may: (i) revoke the number resources; (ii) cease providing the Services to Applicant; and/or (iii) terminate this Agreement. with ARIN may review, at any time, any Applicant's use of previously allocated or assigned number resources or Services received from ARIN to determine if Applicant is complying with this Agreement and the Policies. Without limiting the foregoing, if Applicant is a holder of a direct allocation or direct assignment from ARIN, Applicant agrees that it will use the number resources solely for uses consistent with this Agreement, including, for example, its internal infrastructure or to provide Internet access to its customer base. If ARIN determines that the number resources or any other Services are not being used in compliance with this Agreement or the Policies, ARIN may: (i) revoke the number resources; (ii) cease providing the Services to Applicant; and/or (iii) terminate this Agreement. and add to the NRPM Section 12: 10. ARIN will not use utilization as a measure of policy compliance for addresses transferred under 8.3. 8. Rationale: Current ARIN policies relating to the registration of transfer of address holdings limit the eligibility of registration of transfers to those relating to mergers and acquisitions of entities that are administering an operational network, or to those who agree to sign either an RSA or LRSA with ARIN and subject the buyer to needs analysis and the seller to a potential ARIN review under RSA section 8. It is currently anticipated that the IPv4 unallocated address pool will be exhausted within a couple of years at ARIN, and earlier than that in other regions, and the transition to IPv6-based service delivery is likely to take longer than the remaining period of unallocated address availability. Accordingly, it is likely that demand for IPv4 addresses will continue beyond the time of unallocated address pool exhaustion, leading to a period of movement of IPv4 address blocks between address holders to meet such continuing demand for IPv4 address blocks. The underlying proposition behind this policy proposal is that the registry of IPv4 addresses operated by ARIN is of general utility and value only while it accurately describes the current state of address distribution. If a class of address movement transactions are excluded from being entered in the registry, then the registry will have decreasing value to the broader community, and the integrity of the network itself is thereby compromised. This proposal's central aim is to ensure the continuing utility and value of the ARIN address registry by allowing the registry to record transactions where IPv4 addresses are transfered between ARIN account holders. It proposes that ARIN will recognise and register a transfer of addresses where the parties to the transfer are 'known' to ARIN and that the address block being transferred is part of ARIN's current address set. The proposal does not prescribe how such transfers may occur, nor impose any further constraints on the transfer or on the parties involved other than those described in this proposal. 9. Timetable for implementation: immediate. ________________________________ This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. From mike at nationwideinc.com Wed May 18 11:23:57 2011 From: mike at nationwideinc.com (Mike Burns) Date: Wed, 18 May 2011 11:23:57 -0400 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate References: Message-ID: <4DCFDB5C64DD4F738B65AB82D36B629D@mike> I wanted to take a second to provide some clarity on this particular email thread to ensure that everyone's expectations are the same. ARIN Staff touched base with the Proposal Originator (Mike Burns) and it was confirmed by Mike that his intent on sending this to PPML was not to formally submit it but to get feedback from the community prior to formally submitting. With that in mind, this proposal has not been assigned a Policy Proposal number as yet and AC shepherds have not been assigned. Hi John, I will send it to policy at arin.net today. The objections I have noted seem to fall in three categories: 1. That's not the way we have historically dealt with addresses. 2. It could lead to disaggregation 3. Hoarders and speculators will appear and will unfairly manipulate price. As far as 1, my argument is that the historical method was appropriate for free pool allocations, as it provided the necessary constraint for doling out valuable resources without a price. The economic concept of the Tragedy of the Commons holds that without any constraint, that the resources would be overconsumed. In our world, this would mean that people would grab more addresses than they could use, unless we constrained them by demonstrated need. In a post-exhaust world, price would impose that constraint. Our job as stewards is to make policy to ensure accurate Whois, and to end policies which provide disincentives for under-utilized addresses to enter the market, driving up price. Needs requirements designed to constrain the delivery of free pool addresses are no longer required for stewardship, and maintaining them for transfers threatens Whois accuracy, whose stewardship we maintain. As far as 2, this danger seems to be manageable, and there haven't been too many objections related to this lately. I have argued that the stewards of the APNIC region, led by Geoff Huston, considered this problem when deciding whether to have needs requirements on transfers, and decided the benefits to Whois accuracy outweighed the potential disaggregation problems. This cost is borne most by network operators, who presumably can make decisions on minimum block size which will allow them to run profitably. Those decisions will likely shape the transfer market, so nobody expects there to be much value in a /32 netblock, because network operators find this size unprofitable to route today. This ability of network operators provides a constraint on disaggregation in the transfer market. And as far as 3, I have argued that speculators provide a value to free markets, that most attempts to corner markets fail, that supply uncertainty and IPv6 deployment provide a poor environment for speculators. But inasmuch as this forum is populated by technical types who are making decisions here based on their understanding of, and philosophy of, economics, I have decided to take David Farmer's advice and add an anti-speculator, anti-hoarder protection in the form of a limit of a /12 equivalent for needs-free transfers per 12 month period. If more transfers than that are desired, the recipient will have to demonstrate need. As a whole, then, my policy seeks to recognize that there are transfer transactions which provide incentives for buyers and sellers of addresses but which transactions may not meed the needs requirements which ARIN mandates for transfers. Additionally, I pointed out that network operators, in my experience, will route addresses whose Whois record does not reflect that the network operator's customer is the registrant. The network operator, in my experience, will normally check to make sure that nobody else is advertising the addresses, and will solicit from the customer some documentary evidence that the customer has the right to the route the addresses, and then the network operator will route the addresses. The net effect of these types of transactions is a lack of trust in the Whois table as an accurate source to check for authoritative routing rights. My proposal seeks to reduce the harm to Whois accuracy by extending the range of allowable transactions, providing additional incentive to have transfers reflected accurately by ARIN's updating of Whois to reflect the transfer. As we move into a trading world, which will happen whether or not my proposal passes, conflicts over address control are likely to increase, and the value of trust in Whois as the routing authority will also increase. Rather than sit back and watch Whois decay, I urge ARIN stewards to consider making these changes to foster accuracy in Whois. Regards, Mike PS I will change the name to Removing the needs requirement for IPv4 transfers smaller than a /12 and send it in today. ----- Original Message ----- From: "Sweeting, John" To: "Mike Burns" ; Sent: Wednesday, May 18, 2011 10:32 AM Subject: Re: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate Hello PPML, I wanted to take a second to provide some clarity on this particular email thread to ensure that everyone's expectations are the same. ARIN Staff touched base with the Proposal Originator (Mike Burns) and it was confirmed by Mike that his intent on sending this to PPML was not to formally submit it but to get feedback from the community prior to formally submitting. With that in mind, this proposal has not been assigned a Policy Proposal number as yet and AC shepherds have not been assigned. Thanks, John AC Chair On 5/11/11 2:03 PM, "Mike Burns" wrote: 1. Policy Proposal Name: IPv4 Transfer Policy Change to Keep Whois Accurate 2. Proposal Originator: a. Name: Mike Burns b. Email: mike at sum.net c. Phone: 1-863-494-7692 x105 d. Organization: Nationwide Computer Systems 3. Proposal Version: 1 4. Date: May 11th, 2011 5. Proposal type: modify 6. Policy term: permanent 7. Policy statement: Replace Section 8.3 with 8.3 ARIN will process and record IPv4 address transfer requests. Conditions on the IPv4 address block: - The minimum transfer size is a /24 - The address block must be in the range of addresses administered by ARIN Conditions on source of the transfer: - The source entity must be the current rights 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 the transfer, or until the exhaustion of ARIN's IPv4 space, whichever occurs first. - The source entity must not have received an allocation from ARIN for the 12 months prior to the transfer. Conditions on recipient of the transfer: - The recipient entity must be a current ARIN account holder. - The recipient must sign an RSA with ARIN. - The recipient entity of the transferred resources will be subject to current ARIN policies. In particular, in any subsequent ARIN IPv4 address allocation request, the recipient will be required to account for the efficient utilization of all IPv4 address space held, including all transferred resources. and request the AC to modify section 8 of the current RSA to remove references to "intended purposes." Replace ARIN may review, at any time, Applicant's use of previously allocated or assigned number resources or Services received from ARIN to determine if Applicant is complying with this Agreement and the Policies and is using the Services for their intended purposes. Without limiting the foregoing, if Applicant is a holder of a direct allocation or assignment from ARIN, Applicant agrees that it will use the number resources solely for uses consistent with its application and this Agreement, including, for example, its internal infrastructure or to provide Internet access to its customer base. If ARIN determines that the number resources or any other Services are not being used in compliance with this Agreement, the Policies, or the purposes for which they are intended, ARIN may: (i) revoke the number resources; (ii) cease providing the Services to Applicant; and/or (iii) terminate this Agreement. with ARIN may review, at any time, any Applicant's use of previously allocated or assigned number resources or Services received from ARIN to determine if Applicant is complying with this Agreement and the Policies. Without limiting the foregoing, if Applicant is a holder of a direct allocation or direct assignment from ARIN, Applicant agrees that it will use the number resources solely for uses consistent with this Agreement, including, for example, its internal infrastructure or to provide Internet access to its customer base. If ARIN determines that the number resources or any other Services are not being used in compliance with this Agreement or the Policies, ARIN may: (i) revoke the number resources; (ii) cease providing the Services to Applicant; and/or (iii) terminate this Agreement. and add to the NRPM Section 12: 10. ARIN will not use utilization as a measure of policy compliance for addresses transferred under 8.3. 8. Rationale: Current ARIN policies relating to the registration of transfer of address holdings limit the eligibility of registration of transfers to those relating to mergers and acquisitions of entities that are administering an operational network, or to those who agree to sign either an RSA or LRSA with ARIN and subject the buyer to needs analysis and the seller to a potential ARIN review under RSA section 8. It is currently anticipated that the IPv4 unallocated address pool will be exhausted within a couple of years at ARIN, and earlier than that in other regions, and the transition to IPv6-based service delivery is likely to take longer than the remaining period of unallocated address availability. Accordingly, it is likely that demand for IPv4 addresses will continue beyond the time of unallocated address pool exhaustion, leading to a period of movement of IPv4 address blocks between address holders to meet such continuing demand for IPv4 address blocks. The underlying proposition behind this policy proposal is that the registry of IPv4 addresses operated by ARIN is of general utility and value only while it accurately describes the current state of address distribution. If a class of address movement transactions are excluded from being entered in the registry, then the registry will have decreasing value to the broader community, and the integrity of the network itself is thereby compromised. This proposal's central aim is to ensure the continuing utility and value of the ARIN address registry by allowing the registry to record transactions where IPv4 addresses are transfered between ARIN account holders. It proposes that ARIN will recognise and register a transfer of addresses where the parties to the transfer are 'known' to ARIN and that the address block being transferred is part of ARIN's current address set. The proposal does not prescribe how such transfers may occur, nor impose any further constraints on the transfer or on the parties involved other than those described in this proposal. 9. Timetable for implementation: immediate. ________________________________ This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. From john.sweeting at twcable.com Wed May 18 11:56:37 2011 From: john.sweeting at twcable.com (Sweeting, John) Date: Wed, 18 May 2011 11:56:37 -0400 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate In-Reply-To: <4DCFDB5C64DD4F738B65AB82D36B629D@mike> Message-ID: Perfect Mike, thanks for the update. On 5/18/11 11:23 AM, "Mike Burns" wrote: I wanted to take a second to provide some clarity on this particular email thread to ensure that everyone's expectations are the same. ARIN Staff touched base with the Proposal Originator (Mike Burns) and it was confirmed by Mike that his intent on sending this to PPML was not to formally submit it but to get feedback from the community prior to formally submitting. With that in mind, this proposal has not been assigned a Policy Proposal number as yet and AC shepherds have not been assigned. Hi John, I will send it to policy at arin.net today. The objections I have noted seem to fall in three categories: 1. That's not the way we have historically dealt with addresses. 2. It could lead to disaggregation 3. Hoarders and speculators will appear and will unfairly manipulate price. As far as 1, my argument is that the historical method was appropriate for free pool allocations, as it provided the necessary constraint for doling out valuable resources without a price. The economic concept of the Tragedy of the Commons holds that without any constraint, that the resources would be overconsumed. In our world, this would mean that people would grab more addresses than they could use, unless we constrained them by demonstrated need. In a post-exhaust world, price would impose that constraint. Our job as stewards is to make policy to ensure accurate Whois, and to end policies which provide disincentives for under-utilized addresses to enter the market, driving up price. Needs requirements designed to constrain the delivery of free pool addresses are no longer required for stewardship, and maintaining them for transfers threatens Whois accuracy, whose stewardship we maintain. As far as 2, this danger seems to be manageable, and there haven't been too many objections related to this lately. I have argued that the stewards of the APNIC region, led by Geoff Huston, considered this problem when deciding whether to have needs requirements on transfers, and decided the benefits to Whois accuracy outweighed the potential disaggregation problems. This cost is borne most by network operators, who presumably can make decisions on minimum block size which will allow them to run profitably. Those decisions will likely shape the transfer market, so nobody expects there to be much value in a /32 netblock, because network operators find this size unprofitable to route today. This ability of network operators provides a constraint on disaggregation in the transfer market. And as far as 3, I have argued that speculators provide a value to free markets, that most attempts to corner markets fail, that supply uncertainty and IPv6 deployment provide a poor environment for speculators. But inasmuch as this forum is populated by technical types who are making decisions here based on their understanding of, and philosophy of, economics, I have decided to take David Farmer's advice and add an anti-speculator, anti-hoarder protection in the form of a limit of a /12 equivalent for needs-free transfers per 12 month period. If more transfers than that are desired, the recipient will have to demonstrate need. As a whole, then, my policy seeks to recognize that there are transfer transactions which provide incentives for buyers and sellers of addresses but which transactions may not meed the needs requirements which ARIN mandates for transfers. Additionally, I pointed out that network operators, in my experience, will route addresses whose Whois record does not reflect that the network operator's customer is the registrant. The network operator, in my experience, will normally check to make sure that nobody else is advertising the addresses, and will solicit from the customer some documentary evidence that the customer has the right to the route the addresses, and then the network operator will route the addresses. The net effect of these types of transactions is a lack of trust in the Whois table as an accurate source to check for authoritative routing rights. My proposal seeks to reduce the harm to Whois accuracy by extending the range of allowable transactions, providing additional incentive to have transfers reflected accurately by ARIN's updating of Whois to reflect the transfer. As we move into a trading world, which will happen whether or not my proposal passes, conflicts over address control are likely to increase, and the value of trust in Whois as the routing authority will also increase. Rather than sit back and watch Whois decay, I urge ARIN stewards to consider making these changes to foster accuracy in Whois. Regards, Mike PS I will change the name to Removing the needs requirement for IPv4 transfers smaller than a /12 and send it in today. ----- Original Message ----- From: "Sweeting, John" To: "Mike Burns" ; Sent: Wednesday, May 18, 2011 10:32 AM Subject: Re: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate Hello PPML, I wanted to take a second to provide some clarity on this particular email thread to ensure that everyone's expectations are the same. ARIN Staff touched base with the Proposal Originator (Mike Burns) and it was confirmed by Mike that his intent on sending this to PPML was not to formally submit it but to get feedback from the community prior to formally submitting. With that in mind, this proposal has not been assigned a Policy Proposal number as yet and AC shepherds have not been assigned. Thanks, John AC Chair On 5/11/11 2:03 PM, "Mike Burns" wrote: 1. Policy Proposal Name: IPv4 Transfer Policy Change to Keep Whois Accurate 2. Proposal Originator: a. Name: Mike Burns b. Email: mike at sum.net c. Phone: 1-863-494-7692 x105 d. Organization: Nationwide Computer Systems 3. Proposal Version: 1 4. Date: May 11th, 2011 5. Proposal type: modify 6. Policy term: permanent 7. Policy statement: Replace Section 8.3 with 8.3 ARIN will process and record IPv4 address transfer requests. Conditions on the IPv4 address block: - The minimum transfer size is a /24 - The address block must be in the range of addresses administered by ARIN Conditions on source of the transfer: - The source entity must be the current rights 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 the transfer, or until the exhaustion of ARIN's IPv4 space, whichever occurs first. - The source entity must not have received an allocation from ARIN for the 12 months prior to the transfer. Conditions on recipient of the transfer: - The recipient entity must be a current ARIN account holder. - The recipient must sign an RSA with ARIN. - The recipient entity of the transferred resources will be subject to current ARIN policies. In particular, in any subsequent ARIN IPv4 address allocation request, the recipient will be required to account for the efficient utilization of all IPv4 address space held, including all transferred resources. and request the AC to modify section 8 of the current RSA to remove references to "intended purposes." Replace ARIN may review, at any time, Applicant's use of previously allocated or assigned number resources or Services received from ARIN to determine if Applicant is complying with this Agreement and the Policies and is using the Services for their intended purposes. Without limiting the foregoing, if Applicant is a holder of a direct allocation or assignment from ARIN, Applicant agrees that it will use the number resources solely for uses consistent with its application and this Agreement, including, for example, its internal infrastructure or to provide Internet access to its customer base. If ARIN determines that the number resources or any other Services are not being used in compliance with this Agreement, the Policies, or the purposes for which they are intended, ARIN may: (i) revoke the number resources; (ii) cease providing the Services to Applicant; and/or (iii) terminate this Agreement. with ARIN may review, at any time, any Applicant's use of previously allocated or assigned number resources or Services received from ARIN to determine if Applicant is complying with this Agreement and the Policies. Without limiting the foregoing, if Applicant is a holder of a direct allocation or direct assignment from ARIN, Applicant agrees that it will use the number resources solely for uses consistent with this Agreement, including, for example, its internal infrastructure or to provide Internet access to its customer base. If ARIN determines that the number resources or any other Services are not being used in compliance with this Agreement or the Policies, ARIN may: (i) revoke the number resources; (ii) cease providing the Services to Applicant; and/or (iii) terminate this Agreement. and add to the NRPM Section 12: 10. ARIN will not use utilization as a measure of policy compliance for addresses transferred under 8.3. 8. Rationale: Current ARIN policies relating to the registration of transfer of address holdings limit the eligibility of registration of transfers to those relating to mergers and acquisitions of entities that are administering an operational network, or to those who agree to sign either an RSA or LRSA with ARIN and subject the buyer to needs analysis and the seller to a potential ARIN review under RSA section 8. It is currently anticipated that the IPv4 unallocated address pool will be exhausted within a couple of years at ARIN, and earlier than that in other regions, and the transition to IPv6-based service delivery is likely to take longer than the remaining period of unallocated address availability. Accordingly, it is likely that demand for IPv4 addresses will continue beyond the time of unallocated address pool exhaustion, leading to a period of movement of IPv4 address blocks between address holders to meet such continuing demand for IPv4 address blocks. The underlying proposition behind this policy proposal is that the registry of IPv4 addresses operated by ARIN is of general utility and value only while it accurately describes the current state of address distribution. If a class of address movement transactions are excluded from being entered in the registry, then the registry will have decreasing value to the broader community, and the integrity of the network itself is thereby compromised. This proposal's central aim is to ensure the continuing utility and value of the ARIN address registry by allowing the registry to record transactions where IPv4 addresses are transfered between ARIN account holders. It proposes that ARIN will recognise and register a transfer of addresses where the parties to the transfer are 'known' to ARIN and that the address block being transferred is part of ARIN's current address set. The proposal does not prescribe how such transfers may occur, nor impose any further constraints on the transfer or on the parties involved other than those described in this proposal. 9. Timetable for implementation: immediate. ________________________________ This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. ________________________________ This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. From info at arin.net Wed May 18 12:48:51 2011 From: info at arin.net (ARIN) Date: Wed, 18 May 2011 12:48:51 -0400 Subject: [arin-ppml] ARIN-prop-151 IPv4 Transfer Policy Change to Keep Whois Accurate Message-ID: <4DD3F873.3080709@arin.net> ARIN-prop-151 IPv4 Transfer Policy Change to Keep Whois Accurate 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-151 IPv4 Transfer Policy Change to Keep Whois Accurate Proposal Originator: Mike Burns Proposal Version: 1 Date: 18 May 2011 Proposal type: modify Policy term: permanent Policy statement: Replace Section 8.3 with 8.3 ARIN will process and record IPv4 address transfer requests. Conditions on the IPv4 address block: - The minimum transfer size is a /24 - The address block must be in the range of addresses administered by ARIN Conditions on source of the transfer: - The source entity must be the current rights 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 the transfer, or until the exhaustion of ARIN's IPv4 space, whichever occurs first. - The source entity must not have received an allocation from ARIN for the 12 months prior to the transfer. Conditions on recipient of the transfer: - The recipient entity must be a current ARIN account holder. - The recipient must sign an RSA with ARIN. - The recipient entity of the transferred resources will be subject to current ARIN policies. In particular, in any subsequent ARIN IPv4 address allocation request, the recipient will be required to account for the efficient utilization of all IPv4 address space held, including all transferred resources. - If the recipient has already received the equivalent of a /12 of addresses in the prior 12 months, the recipient must demonstrate the need for additional resources in the exact amount which they can justify under current ARIN policies. and request the AC to modify section 8 of the current RSA to remove references to "intended purposes." Replace ARIN may review, at any time, Applicant?s use of previously allocated or assigned number resources or Services received from ARIN to determine if Applicant is complying with this Agreement and the Policies and is using the Services for their intended purposes. Without limiting the foregoing, if Applicant is a holder of a direct allocation or assignment from ARIN, Applicant agrees that it will use the number resources solely for uses consistent with its application and this Agreement, including, for example, its internal infrastructure or to provide Internet access to its customer base. If ARIN determines that the number resources or any other Services are not being used in compliance with this Agreement, the Policies, or the purposes for which they are intended, ARIN may: (i) revoke the number resources; (ii) cease providing the Services to Applicant; and/or (iii) terminate this Agreement. with ARIN may review, at any time, any Applicant?s use of previously allocated or assigned number resources or Services received from ARIN to determine if Applicant is complying with this Agreement and the Policies. Without limiting the foregoing, if Applicant is a holder of a direct allocation or direct assignment from ARIN, Applicant agrees that it will use the number resources solely for uses consistent with this Agreement, including, for example, its internal infrastructure or to provide Internet access to its customer base. If ARIN determines that the number resources or any other Services are not being used in compliance with this Agreement or the Policies, ARIN may: (i) revoke the number resources; (ii) cease providing the Services to Applicant; and/or (iii) terminate this Agreement. and add to the NRPM Section 12: 10. ARIN will not use utilization as a measure of policy compliance for addresses transferred under 8.3. Rationale: Current ARIN policies relating to the registration of transfer of address holdings limit the eligibility of registration of transfers to those relating to mergers and acquisitions of entities that are administering an operational network, or to those who agree to sign either an RSA or LRSA with ARIN and subject the buyer to needs analysis and the seller to a potential ARIN review under RSA section 8. It is currently anticipated that the IPv4 unallocated address pool will be exhausted within a couple of years at ARIN, and earlier than that in other regions, and the transition to IPv6-based service delivery is likely to take longer than the remaining period of unallocated address availability. Accordingly, it is likely that demand for IPv4 addresses will continue beyond the time of unallocated address pool exhaustion, leading to a period of movement of IPv4 address blocks between address holders to meet such continuing demand for IPv4 address blocks. The underlying proposition behind this policy proposal is that the registry of IPv4 addresses operated by ARIN is of general utility and value only while it accurately describes the current state of address distribution. If a class of address movement transactions are excluded from being entered in the registry, then the registry will have decreasing value to the broader community, and the integrity of the network itself is thereby compromised. This proposal's central aim is to ensure the continuing utility and value of the ARIN address registry by allowing the registry to record transactions where IPv4 addresses are transfered between ARIN account holders. It proposes that ARIN will recognise and register a transfer of addresses where the parties to the transfer are 'known' to ARIN and that the address block being transferred is part of ARIN's current address set. The proposal does not prescribe how such transfers may occur, nor impose any further constraints on the transfer or on the parties involved other than those described in this proposal. Timetable for implementation: immediate. From mike at nationwideinc.com Wed May 18 13:03:19 2011 From: mike at nationwideinc.com (Mike Burns) Date: Wed, 18 May 2011 13:03:19 -0400 Subject: [arin-ppml] ARIN-prop-151 IPv4 Transfer Policy Change to Keep WhoisAccurate References: <4DD3F873.3080709@arin.net> Message-ID: Sorry, I meant to change the name to Limiting Needs Requirements for IPv4 Transfers. Can the name be changed and reposted prior to any thread starting? Regards, Mike ----- Original Message ----- From: "ARIN" To: Sent: Wednesday, May 18, 2011 12:48 PM Subject: [arin-ppml] ARIN-prop-151 IPv4 Transfer Policy Change to Keep WhoisAccurate ARIN-prop-151 IPv4 Transfer Policy Change to Keep Whois Accurate 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-151 IPv4 Transfer Policy Change to Keep Whois Accurate Proposal Originator: Mike Burns Proposal Version: 1 Date: 18 May 2011 Proposal type: modify Policy term: permanent Policy statement: Replace Section 8.3 with 8.3 ARIN will process and record IPv4 address transfer requests. Conditions on the IPv4 address block: - The minimum transfer size is a /24 - The address block must be in the range of addresses administered by ARIN Conditions on source of the transfer: - The source entity must be the current rights 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 the transfer, or until the exhaustion of ARIN's IPv4 space, whichever occurs first. - The source entity must not have received an allocation from ARIN for the 12 months prior to the transfer. Conditions on recipient of the transfer: - The recipient entity must be a current ARIN account holder. - The recipient must sign an RSA with ARIN. - The recipient entity of the transferred resources will be subject to current ARIN policies. In particular, in any subsequent ARIN IPv4 address allocation request, the recipient will be required to account for the efficient utilization of all IPv4 address space held, including all transferred resources. - If the recipient has already received the equivalent of a /12 of addresses in the prior 12 months, the recipient must demonstrate the need for additional resources in the exact amount which they can justify under current ARIN policies. and request the AC to modify section 8 of the current RSA to remove references to "intended purposes." Replace ARIN may review, at any time, Applicant?s use of previously allocated or assigned number resources or Services received from ARIN to determine if Applicant is complying with this Agreement and the Policies and is using the Services for their intended purposes. Without limiting the foregoing, if Applicant is a holder of a direct allocation or assignment from ARIN, Applicant agrees that it will use the number resources solely for uses consistent with its application and this Agreement, including, for example, its internal infrastructure or to provide Internet access to its customer base. If ARIN determines that the number resources or any other Services are not being used in compliance with this Agreement, the Policies, or the purposes for which they are intended, ARIN may: (i) revoke the number resources; (ii) cease providing the Services to Applicant; and/or (iii) terminate this Agreement. with ARIN may review, at any time, any Applicant?s use of previously allocated or assigned number resources or Services received from ARIN to determine if Applicant is complying with this Agreement and the Policies. Without limiting the foregoing, if Applicant is a holder of a direct allocation or direct assignment from ARIN, Applicant agrees that it will use the number resources solely for uses consistent with this Agreement, including, for example, its internal infrastructure or to provide Internet access to its customer base. If ARIN determines that the number resources or any other Services are not being used in compliance with this Agreement or the Policies, ARIN may: (i) revoke the number resources; (ii) cease providing the Services to Applicant; and/or (iii) terminate this Agreement. and add to the NRPM Section 12: 10. ARIN will not use utilization as a measure of policy compliance for addresses transferred under 8.3. Rationale: Current ARIN policies relating to the registration of transfer of address holdings limit the eligibility of registration of transfers to those relating to mergers and acquisitions of entities that are administering an operational network, or to those who agree to sign either an RSA or LRSA with ARIN and subject the buyer to needs analysis and the seller to a potential ARIN review under RSA section 8. It is currently anticipated that the IPv4 unallocated address pool will be exhausted within a couple of years at ARIN, and earlier than that in other regions, and the transition to IPv6-based service delivery is likely to take longer than the remaining period of unallocated address availability. Accordingly, it is likely that demand for IPv4 addresses will continue beyond the time of unallocated address pool exhaustion, leading to a period of movement of IPv4 address blocks between address holders to meet such continuing demand for IPv4 address blocks. The underlying proposition behind this policy proposal is that the registry of IPv4 addresses operated by ARIN is of general utility and value only while it accurately describes the current state of address distribution. If a class of address movement transactions are excluded from being entered in the registry, then the registry will have decreasing value to the broader community, and the integrity of the network itself is thereby compromised. This proposal's central aim is to ensure the continuing utility and value of the ARIN address registry by allowing the registry to record transactions where IPv4 addresses are transfered between ARIN account holders. It proposes that ARIN will recognise and register a transfer of addresses where the parties to the transfer are 'known' to ARIN and that the address block being transferred is part of ARIN's current address set. The proposal does not prescribe how such transfers may occur, nor impose any further constraints on the transfer or on the parties involved other than those described in this proposal. 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 18 13:05:55 2011 From: info at arin.net (ARIN) Date: Wed, 18 May 2011 13:05:55 -0400 Subject: [arin-ppml] ARIN-prop-151 Limiting Needs Requirements for IPv4 Transfers Message-ID: <4DD3FC73.3050502@arin.net> ARIN-prop-151 Limiting Needs Requirements for IPv4 Transfers Corrected proposal name. 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-151 Limiting Needs Requirements for IPv4 Transfers Proposal Originator: Mike Burns Proposal Version: 1 Date: 18 May 2011 Proposal type: modify Policy term: permanent Policy statement: Replace Section 8.3 with 8.3 ARIN will process and record IPv4 address transfer requests. Conditions on the IPv4 address block: - The minimum transfer size is a /24 - The address block must be in the range of addresses administered by ARIN Conditions on source of the transfer: - The source entity must be the current rights 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 the transfer, or until the exhaustion of ARIN's IPv4 space, whichever occurs first. - The source entity must not have received an allocation from ARIN for the 12 months prior to the transfer. Conditions on recipient of the transfer: - The recipient entity must be a current ARIN account holder. - The recipient must sign an RSA with ARIN. - The recipient entity of the transferred resources will be subject to current ARIN policies. In particular, in any subsequent ARIN IPv4 address allocation request, the recipient will be required to account for the efficient utilization of all IPv4 address space held, including all transferred resources. - If the recipient has already received the equivalent of a /12 of addresses in the prior 12 months, the recipient must demonstrate the need for additional resources in the exact amount which they can justify under current ARIN policies. and request the AC to modify section 8 of the current RSA to remove references to "intended purposes." Replace ARIN may review, at any time, Applicant?s use of previously allocated or assigned number resources or Services received from ARIN to determine if Applicant is complying with this Agreement and the Policies and is using the Services for their intended purposes. Without limiting the foregoing, if Applicant is a holder of a direct allocation or assignment from ARIN, Applicant agrees that it will use the number resources solely for uses consistent with its application and this Agreement, including, for example, its internal infrastructure or to provide Internet access to its customer base. If ARIN determines that the number resources or any other Services are not being used in compliance with this Agreement, the Policies, or the purposes for which they are intended, ARIN may: (i) revoke the number resources; (ii) cease providing the Services to Applicant; and/or (iii) terminate this Agreement. with ARIN may review, at any time, any Applicant?s use of previously allocated or assigned number resources or Services received from ARIN to determine if Applicant is complying with this Agreement and the Policies. Without limiting the foregoing, if Applicant is a holder of a direct allocation or direct assignment from ARIN, Applicant agrees that it will use the number resources solely for uses consistent with this Agreement, including, for example, its internal infrastructure or to provide Internet access to its customer base. If ARIN determines that the number resources or any other Services are not being used in compliance with this Agreement or the Policies, ARIN may: (i) revoke the number resources; (ii) cease providing the Services to Applicant; and/or (iii) terminate this Agreement. and add to the NRPM Section 12: 10. ARIN will not use utilization as a measure of policy compliance for addresses transferred under 8.3. Rationale: Current ARIN policies relating to the registration of transfer of address holdings limit the eligibility of registration of transfers to those relating to mergers and acquisitions of entities that are administering an operational network, or to those who agree to sign either an RSA or LRSA with ARIN and subject the buyer to needs analysis and the seller to a potential ARIN review under RSA section 8. It is currently anticipated that the IPv4 unallocated address pool will be exhausted within a couple of years at ARIN, and earlier than that in other regions, and the transition to IPv6-based service delivery is likely to take longer than the remaining period of unallocated address availability. Accordingly, it is likely that demand for IPv4 addresses will continue beyond the time of unallocated address pool exhaustion, leading to a period of movement of IPv4 address blocks between address holders to meet such continuing demand for IPv4 address blocks. The underlying proposition behind this policy proposal is that the registry of IPv4 addresses operated by ARIN is of general utility and value only while it accurately describes the current state of address distribution. If a class of address movement transactions are excluded from being entered in the registry, then the registry will have decreasing value to the broader community, and the integrity of the network itself is thereby compromised. This proposal's central aim is to ensure the continuing utility and value of the ARIN address registry by allowing the registry to record transactions where IPv4 addresses are transfered between ARIN account holders. It proposes that ARIN will recognise and register a transfer of addresses where the parties to the transfer are 'known' to ARIN and that the address block being transferred is part of ARIN's current address set. The proposal does not prescribe how such transfers may occur, nor impose any further constraints on the transfer or on the parties involved other than those described in this proposal. Timetable for implementation: immediate. From lar at mwtcorp.net Wed May 18 13:12:33 2011 From: lar at mwtcorp.net (Larry Ash) Date: Wed, 18 May 2011 11:12:33 -0600 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate In-Reply-To: <4DCFDB5C64DD4F738B65AB82D36B629D@mike> References: <4DCFDB5C64DD4F738B65AB82D36B629D@mike> Message-ID: > > The objections I have noted seem to fall in three categories: > > 1. That's not the way we have historically dealt with addresses. > 2. It could lead to disaggregation > 3. Hoarders and speculators will appear and will unfairly manipulate >price. > > As far as 1, my argument is that the historical method was appropriate for >free pool allocations, as it provided the necessary constraint for doling >out valuable resources without a price. The economic concept of the Tragedy >of the Commons holds that without any constraint, that the resources would >be overconsumed. In our world, this would mean that people would grab more >addresses than they could use, unless we constrained them by demonstrated >need. In a post-exhaust world, price would impose that constraint. Our job >as stewards is to make policy to ensure accurate Whois, and to end policies >which provide disincentives for under-utilized addresses to enter the >market, driving up price. Needs requirements designed to constrain the >delivery of free pool addresses are no longer required for stewardship, and >maintaining them for transfers threatens Whois accuracy, whose stewardship >we maintain. This is a "toothpaste tube" moment. If we let you squeeze the toothpaste out of the tube we can't put it back. Most of your arguments seem more philosophical than anything. I don't care a whit about how we used to do it BUT the long standing goal of good stewardship still apply. Free pool run-out has nothing to do with that. > > As far as 2, this danger seems to be manageable, and there haven't been >too many objections related to this lately. I have argued that the stewards >of the APNIC region, led by Geoff Huston, considered this problem when >deciding whether to have needs requirements on transfers, and decided the >benefits to Whois accuracy outweighed the potential disaggregation >problems. This cost is borne most by network operators, who presumably can >make decisions on minimum block size which will allow them to run >profitably. Those decisions will likely shape the transfer market, so >nobody expects there to be much value in a /32 netblock, because network >operators find this size unprofitable to route today. This ability of >network operators provides a constraint on disaggregation in the transfer >market. I think not!! Disaggregation is a table top issue that only becomes a big issue when we go over the edge. It has been raised and argued on this list almost as much as the benefit/disadvantage of NAT and whether a supply demand curve really works for ip addresses. Whois accuracy is a straw man argument. The Whois database will remain fairly accurate in both scenarios because most of us want it to. Those that have something to hide do and will avoid or obfuscate the entries. Hiding number utilization probably won't be high on the list of why they do it either. I have no idea why APNIC made the decisions they did. To be honest I don't care but so far my experience of tracing problems coming from there have not been productive. The problem networks don't seem to be listed in whois? Go figure. > > And as far as 3, I have argued that speculators provide a value to free >markets, that most attempts to corner markets fail, that supply uncertainty >and IPv6 deployment provide a poor environment for speculators. But >inasmuch as this forum is populated by technical types who are making >decisions here based on their understanding of, and philosophy of, >economics, I have decided to take David Farmer's advice and add an >anti-speculator, anti-hoarder protection in the form of a limit of a /12 >equivalent for needs-free transfers per 12 month period. If more transfers >than that are desired, the recipient will have to demonstrate need. > It seems to me that the whole issue comes down to the proposition that by having a monetary value for ip addresses (either the addresses or license to use) you philosophically believe that the supply will be increased. Classical supply/demand theory argues that price is an efficient allocator because as price for widgets goes up, some suppliers of bonkos will divert resources used to manufacture bonkos to building widgets and the supply will go up relieving the price pressure and establishing equilibrium at the most efficient mix of bonkos vs widgets. When supply is fixed the whole issue becomes much more cloudy and the market behaves in a much more complex and less predictable manner. I encourage each person to think carefully and ask themselves what addresses could he/she part with if the price was high enough and what would that price be. Even if I had a bunch of extra space it would have been cut up into small pieces and I'd have to renumber some customers to liberate it. I have renumbered 4 times. Three in PA on once into PI. It would not be worth it at 10 times what MS paid for the Nortel addresses per IP. Other than liquidating a failing business or shedding an orphan /23 or /24 I don't see price shaking loose many addresses. During liquidation addresses will come available and when a large block is involved there will be publicity but I see that as the exception rather than the rule. What I do see is as the price goes up a group of individuals will try and find and reclaim abandoned or lost blocks that have fallen between the cracks. The more unscrupulous will move in and try to reclaim blocks that are not announced even if they are in use. ARIN could find themselves spending more time trying to figure our who has the rights to a block that they did assigning numbers in the past. Personally I'd rather task ARIN to try and reclaim them rather than every hustler that thinks he can make a million reclaiming unused IP addresses. > As a whole, then, my policy seeks to recognize that there are transfer >transactions which provide incentives for buyers and sellers of addresses >but which transactions may not meed the needs requirements which ARIN >mandates for transfers. Additionally, I pointed out that network operators, >in my experience, will route addresses whose Whois record does not reflect >that the network operator's customer is the registrant. The network >operator, in my experience, will normally check to make sure that nobody >else is advertising the addresses, and will solicit from the customer some >documentary evidence that the customer has the right to the route the >addresses, and then the network operator will route the addresses. > > The net effect of these types of transactions is a lack of trust in the >Whois table as an accurate source to check for authoritative routing >rights. My proposal seeks to reduce the harm to Whois accuracy by extending >the range of allowable transactions, providing additional incentive to have >transfers reflected accurately by ARIN's updating of Whois to reflect the >transfer. > > As we move into a trading world, which will happen whether or not my >proposal passes, conflicts over address control are likely to increase, and >the value of trust in Whois as the routing authority will also increase. >Rather than sit back and watch Whois decay, I urge ARIN stewards to >consider making these changes to foster accuracy in Whois. > > Regards, > Mike > > PS I will change the name to Removing the needs requirement for IPv4 >transfers smaller than a /12 and send it in today. > So I don't have to tell why I want 65535 /20's just as long as I don't go after a /12? Before we squeeze all of the toothpaste out of the tube, it seems we could lower the bar and see if anything bad happens. Changing the horizon for transfers to 12 month instead of 3 months is a step that way. Maybe the 80% rule could be lowered to 70% when evaluating past utilization? > > > > > > ----- Original Message ----- From: "Sweeting, John" > > To: "Mike Burns" ; > Sent: Wednesday, May 18, 2011 10:32 AM > Subject: Re: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois >Accurate > > > Hello PPML, > > I wanted to take a second to provide some clarity on this particular email >thread to ensure that everyone's expectations are the same. ARIN Staff >touched base with the Proposal Originator (Mike Burns) and it was confirmed >by Mike that his intent on sending this to PPML was not to formally submit >it but to get feedback from the community prior to formally submitting. >With that in mind, this proposal has not been assigned a Policy Proposal >number as yet and AC shepherds have not been assigned. > > Thanks, > John > AC Chair > > > On 5/11/11 2:03 PM, "Mike Burns" wrote: > > 1. Policy Proposal Name: IPv4 Transfer Policy Change to Keep Whois >Accurate > > 2. Proposal Originator: > a. Name: Mike Burns > b. Email: mike at sum.net > c. Phone: 1-863-494-7692 x105 > d. Organization: Nationwide Computer Systems > > 3. Proposal Version: 1 > > 4. Date: May 11th, 2011 > > 5. Proposal type: modify > > 6. Policy term: permanent > > 7. Policy statement: > > Replace Section 8.3 with > > 8.3 ARIN will process and record IPv4 address transfer requests. > > Conditions on the IPv4 address block: > > - The minimum transfer size is a /24 > > - The address block must be in the range of addresses administered > by ARIN > > Conditions on source of the transfer: > > - The source entity must be the current rights 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 the transfer, or until the exhaustion of ARIN's > IPv4 space, whichever occurs first. > > - The source entity must not have received an allocation from ARIN >for the 12 months prior to the transfer. > > > Conditions on recipient of the transfer: > > - The recipient entity must be a current ARIN account holder. > > - The recipient must sign an RSA with ARIN. > > - The recipient entity of the transferred resources will be subject > to current ARIN policies. In particular, in any subsequent ARIN > IPv4 address allocation request, the recipient will be required > to account for the efficient utilization of all IPv4 address > space held, including all transferred resources. > > and request the AC to modify section 8 of the current RSA to remove >references to "intended purposes." > > Replace > ARIN may review, at any time, Applicant's use of previously allocated or >assigned number resources or Services received from ARIN to determine if >Applicant is complying with this Agreement and the Policies and is using >the Services for their intended purposes. Without limiting the foregoing, >if Applicant is a holder of a direct allocation or assignment from ARIN, >Applicant agrees that it will use the number resources solely for uses >consistent with its application and this Agreement, including, for example, >its internal infrastructure or to provide Internet access to its customer >base. If ARIN determines that the number resources or any other Services >are not being used in compliance with this Agreement, the Policies, or the >purposes for which they are intended, ARIN may: (i) revoke the number >resources; (ii) cease providing the Services to Applicant; and/or (iii) >terminate this Agreement. > > with > > ARIN may review, at any time, any Applicant's use of previously allocated >or assigned number resources or Services received from ARIN to determine if >Applicant is complying with this Agreement and the Policies. Without >limiting the foregoing, if Applicant is a holder of a direct allocation or >direct assignment from ARIN, Applicant agrees that it will use the number >resources solely for uses consistent with this Agreement, including, for >example, its internal infrastructure or to provide Internet access to its >customer base. If ARIN determines that the number resources or any other >Services are not being used in compliance with this Agreement or the >Policies, ARIN may: (i) revoke the number resources; (ii) cease providing >the Services to Applicant; and/or (iii) terminate this Agreement. > > and add to the NRPM Section 12: > > 10. ARIN will not use utilization as a measure of policy compliance for >addresses transferred under 8.3. > > > 8. Rationale: > > > Current ARIN policies relating to the registration of transfer of > address holdings limit the eligibility of registration of transfers to > those relating to mergers and acquisitions of entities that are > administering an operational network, or to those who agree to > sign either an RSA or LRSA with ARIN and subject the buyer > to needs analysis and the seller to a potential ARIN review under RSA >section 8. > > It is currently anticipated that the IPv4 unallocated address pool > will be exhausted within a couple of years at ARIN, and earlier > than that in other regions, and the transition to IPv6-based service >delivery > is likely to take longer than the remaining period of unallocated > address availability. Accordingly, it is likely that demand for IPv4 > addresses will continue beyond the time of unallocated address pool > exhaustion, leading to a period of movement of IPv4 address blocks > between address holders to meet such continuing demand for IPv4 > address blocks. > > The underlying proposition behind this policy proposal is that the > registry of IPv4 addresses operated by ARIN is of general utility and > value only while it accurately describes the current state of address > distribution. If a class of address movement transactions are excluded > from being entered in the registry, then the registry will have > decreasing value to the broader community, and the integrity of the > network itself is thereby compromised. This proposal's central aim is > to ensure the continuing utility and value of the ARIN address > registry by allowing the registry to record transactions where IPv4 > addresses are transfered between ARIN account holders. > > It proposes that ARIN will recognise and register a transfer of > addresses where the parties to the transfer are 'known' to ARIN and > that the address block being transferred is part of ARIN's current address >set. > > The proposal does not prescribe how such transfers may occur, nor > impose any further constraints on the transfer or on the parties > involved other than those described in this proposal. > > 9. Timetable for implementation: immediate. > > > > ________________________________ > This E-mail and any of its attachments may contain Time Warner Cable >proprietary information, which is privileged, confidential, or subject to >copyright belonging to Time Warner Cable. This E-mail is intended solely >for the use of the individual or entity to which it is addressed. If you >are not the intended recipient of this E-mail, you are hereby notified that >any dissemination, distribution, copying, or action taken in relation to >the contents of and attachments to this E-mail is strictly prohibited and >may be unlawful. If you have received this E-mail in error, please notify >the sender immediately and permanently delete the original and any copy of >this E-mail and any printout. > _______________________________________________ > 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 mike at nationwideinc.com Wed May 18 13:31:23 2011 From: mike at nationwideinc.com (Mike Burns) Date: Wed, 18 May 2011 13:31:23 -0400 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep WhoisAccurate References: <4DCFDB5C64DD4F738B65AB82D36B629D@mike> Message-ID: <3E48F186D6C346E98CB507F7D673D31F@mike> Hi Larry, A quick point: 1. No, you can't do that many addresses (65555 /20's), as I wrote the proposal it's a /12 equivalent max transfer without needs. I was unclear in my introductory post about the /12, sorry for that. Regards, Mike ----- Original Message ----- From: "Larry Ash" To: "Mike Burns" ; "Sweeting, John" ; Sent: Wednesday, May 18, 2011 1:12 PM Subject: Re: [arin-ppml] IPv4 Transfer Policy Change to Keep WhoisAccurate > >> >> The objections I have noted seem to fall in three categories: >> >> 1. That's not the way we have historically dealt with addresses. >> 2. It could lead to disaggregation >> 3. Hoarders and speculators will appear and will unfairly manipulate >> price. >> >> As far as 1, my argument is that the historical method was appropriate >> for free pool allocations, as it provided the necessary constraint for >> doling out valuable resources without a price. The economic concept of >> the Tragedy of the Commons holds that without any constraint, that the >> resources would be overconsumed. In our world, this would mean that >> people would grab more addresses than they could use, unless we >> constrained them by demonstrated need. In a post-exhaust world, price >> would impose that constraint. Our job as stewards is to make policy to >> ensure accurate Whois, and to end policies which provide disincentives >> for under-utilized addresses to enter the market, driving up price. Needs >> requirements designed to constrain the delivery of free pool addresses >> are no longer required for stewardship, and maintaining them for >> transfers threatens Whois accuracy, whose stewardship we maintain. > > This is a "toothpaste tube" moment. If we let you squeeze the toothpaste > out > of the tube we can't put it back. Most of your arguments seem more > philosophical > than anything. I don't care a whit about how we used to do it BUT the long > standing > goal of good stewardship still apply. Free pool run-out has nothing to do > with that. >> >> As far as 2, this danger seems to be manageable, and there haven't been >> too many objections related to this lately. I have argued that the >> stewards of the APNIC region, led by Geoff Huston, considered this >> problem when deciding whether to have needs requirements on transfers, >> and decided the benefits to Whois accuracy outweighed the potential >> disaggregation problems. This cost is borne most by network operators, >> who presumably can make decisions on minimum block size which will allow >> them to run profitably. Those decisions will likely shape the transfer >> market, so nobody expects there to be much value in a /32 netblock, >> because network operators find this size unprofitable to route today. >> This ability of network operators provides a constraint on disaggregation >> in the transfer market. > > I think not!! Disaggregation is a table top issue that only becomes a big > issue > when we go over the edge. It has been raised and argued on this list > almost > as much as the benefit/disadvantage of NAT and whether a supply demand > curve really > works for ip addresses. > > Whois accuracy is a straw man argument. The Whois database will remain > fairly accurate > in both scenarios because most of us want it to. Those that have something > to hide do > and will avoid or obfuscate the entries. > Hiding number utilization probably won't be high on the list of why they > do it either. > I have no idea why APNIC made the decisions they did. To be honest I don't > care > but so far my experience of tracing problems coming from there have not > been > productive. The problem networks don't seem to be listed in whois? Go > figure. >> >> And as far as 3, I have argued that speculators provide a value to free >> markets, that most attempts to corner markets fail, that supply >> uncertainty and IPv6 deployment provide a poor environment for >> speculators. But inasmuch as this forum is populated by technical types >> who are making decisions here based on their understanding of, and >> philosophy of, economics, I have decided to take David Farmer's advice >> and add an anti-speculator, anti-hoarder protection in the form of a >> limit of a /12 equivalent for needs-free transfers per 12 month period. >> If more transfers than that are desired, the recipient will have to >> demonstrate need. >> > > It seems to me that the whole issue comes down to the proposition that by > having > a monetary value for ip addresses (either the addresses or license > to use) you philosophically believe that the supply will be increased. > > Classical supply/demand theory argues that price is an efficient allocator > because > as price for widgets goes up, some suppliers of bonkos will divert > resources used > to manufacture bonkos to building widgets and the supply will go up > relieving the > price pressure and establishing equilibrium at the most efficient mix of > bonkos vs widgets. > > When supply is fixed the whole issue becomes much more cloudy and the > market behaves > in a much more complex and less predictable manner. > > I encourage each person to think carefully and ask themselves what > addresses could > he/she part with if the price was high enough and what would that price > be. > > Even if I had a bunch of extra space it would have been cut up into small > pieces and I'd > have to renumber some customers to liberate it. I have renumbered 4 times. > Three in > PA on once into PI. It would not be worth it at 10 times what MS paid for > the Nortel > addresses per IP. Other than liquidating a failing business or shedding an > orphan /23 > or /24 I don't see price shaking loose many addresses. During liquidation > addresses > will come available and when a large block is involved there will be > publicity but > I see that as the exception rather than the rule. > > What I do see is as the price goes up a group of individuals will try and > find and reclaim > abandoned or lost blocks that have fallen between the cracks. The more > unscrupulous will > move in and try to reclaim blocks that are not announced even if they are > in use. ARIN > could find themselves spending more time trying to figure our who has the > rights to a block > that they did assigning numbers in the past. Personally I'd rather task > ARIN to try and > reclaim them rather than every hustler that thinks he can make a million > reclaiming unused IP addresses. > > > > > >> As a whole, then, my policy seeks to recognize that there are transfer >> transactions which provide incentives for buyers and sellers of addresses >> but which transactions may not meed the needs requirements which ARIN >> mandates for transfers. Additionally, I pointed out that network >> operators, in my experience, will route addresses whose Whois record does >> not reflect that the network operator's customer is the registrant. The >> network operator, in my experience, will normally check to make sure that >> nobody else is advertising the addresses, and will solicit from the >> customer some documentary evidence that the customer has the right to the >> route the addresses, and then the network operator will route the >> addresses. >> >> The net effect of these types of transactions is a lack of trust in the >> Whois table as an accurate source to check for authoritative routing >> rights. My proposal seeks to reduce the harm to Whois accuracy by >> extending the range of allowable transactions, providing additional >> incentive to have transfers reflected accurately by ARIN's updating of >> Whois to reflect the transfer. >> >> As we move into a trading world, which will happen whether or not my >> proposal passes, conflicts over address control are likely to increase, >> and the value of trust in Whois as the routing authority will also >> increase. Rather than sit back and watch Whois decay, I urge ARIN >> stewards to consider making these changes to foster accuracy in Whois. >> >> Regards, >> Mike >> >> PS I will change the name to Removing the needs requirement for IPv4 >> transfers smaller than a /12 and send it in today. >> > > So I don't have to tell why I want 65535 /20's just as long as I don't go > after a /12? > > Before we squeeze all of the toothpaste out of the tube, it seems we could > lower the bar > and see if anything bad happens. > Changing the horizon for transfers to 12 month instead of 3 months is a > step that way. > Maybe the 80% rule could be lowered to 70% when evaluating past > utilization? > > > > > >> >> >> >> >> >> ----- Original Message ----- From: "Sweeting, John" >> >> To: "Mike Burns" ; >> Sent: Wednesday, May 18, 2011 10:32 AM >> Subject: Re: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois >> Accurate >> >> >> Hello PPML, >> >> I wanted to take a second to provide some clarity on this particular >> email thread to ensure that everyone's expectations are the same. ARIN >> Staff touched base with the Proposal Originator (Mike Burns) and it was >> confirmed by Mike that his intent on sending this to PPML was not to >> formally submit it but to get feedback from the community prior to >> formally submitting. With that in mind, this proposal has not been >> assigned a Policy Proposal number as yet and AC shepherds have not been >> assigned. >> >> Thanks, >> John >> AC Chair >> >> >> On 5/11/11 2:03 PM, "Mike Burns" wrote: >> >> 1. Policy Proposal Name: IPv4 Transfer Policy Change to Keep Whois >> Accurate >> >> 2. Proposal Originator: >> a. Name: Mike Burns >> b. Email: mike at sum.net >> c. Phone: 1-863-494-7692 x105 >> d. Organization: Nationwide Computer Systems >> >> 3. Proposal Version: 1 >> >> 4. Date: May 11th, 2011 >> >> 5. Proposal type: modify >> >> 6. Policy term: permanent >> >> 7. Policy statement: >> >> Replace Section 8.3 with >> >> 8.3 ARIN will process and record IPv4 address transfer requests. >> >> Conditions on the IPv4 address block: >> >> - The minimum transfer size is a /24 >> >> - The address block must be in the range of addresses administered >> by ARIN >> >> Conditions on source of the transfer: >> >> - The source entity must be the current rights 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 the transfer, or until the exhaustion of ARIN's >> IPv4 space, whichever occurs first. >> >> - The source entity must not have received an allocation from ARIN >> for the 12 months prior to the transfer. >> >> >> Conditions on recipient of the transfer: >> >> - The recipient entity must be a current ARIN account holder. >> >> - The recipient must sign an RSA with ARIN. >> >> - The recipient entity of the transferred resources will be subject >> to current ARIN policies. In particular, in any subsequent ARIN >> IPv4 address allocation request, the recipient will be required >> to account for the efficient utilization of all IPv4 address >> space held, including all transferred resources. >> >> and request the AC to modify section 8 of the current RSA to remove >> references to "intended purposes." >> >> Replace >> ARIN may review, at any time, Applicant's use of previously allocated or >> assigned number resources or Services received from ARIN to determine if >> Applicant is complying with this Agreement and the Policies and is using >> the Services for their intended purposes. Without limiting the >> foregoing, if Applicant is a holder of a direct allocation or assignment >> from ARIN, Applicant agrees that it will use the number resources solely >> for uses consistent with its application and this Agreement, including, >> for example, its internal infrastructure or to provide Internet access to >> its customer base. If ARIN determines that the number resources or any >> other Services are not being used in compliance with this Agreement, the >> Policies, or the purposes for which they are intended, ARIN may: (i) >> revoke the number resources; (ii) cease providing the Services to >> Applicant; and/or (iii) terminate this Agreement. >> >> with >> >> ARIN may review, at any time, any Applicant's use of previously allocated >> or assigned number resources or Services received from ARIN to determine >> if Applicant is complying with this Agreement and the Policies. Without >> limiting the foregoing, if Applicant is a holder of a direct allocation >> or direct assignment from ARIN, Applicant agrees that it will use the >> number resources solely for uses consistent with this Agreement, >> including, for example, its internal infrastructure or to provide >> Internet access to its customer base. If ARIN determines that the number >> resources or any other Services are not being used in compliance with >> this Agreement or the Policies, ARIN may: (i) revoke the number >> resources; (ii) cease providing the Services to Applicant; and/or (iii) >> terminate this Agreement. >> >> and add to the NRPM Section 12: >> >> 10. ARIN will not use utilization as a measure of policy compliance >> for addresses transferred under 8.3. >> >> >> 8. Rationale: >> >> >> Current ARIN policies relating to the registration of transfer of >> address holdings limit the eligibility of registration of transfers to >> those relating to mergers and acquisitions of entities that are >> administering an operational network, or to those who agree to >> sign either an RSA or LRSA with ARIN and subject the buyer >> to needs analysis and the seller to a potential ARIN review under RSA >> section 8. >> >> It is currently anticipated that the IPv4 unallocated address pool >> will be exhausted within a couple of years at ARIN, and earlier >> than that in other regions, and the transition to IPv6-based service >> delivery >> is likely to take longer than the remaining period of unallocated >> address availability. Accordingly, it is likely that demand for IPv4 >> addresses will continue beyond the time of unallocated address pool >> exhaustion, leading to a period of movement of IPv4 address blocks >> between address holders to meet such continuing demand for IPv4 >> address blocks. >> >> The underlying proposition behind this policy proposal is that the >> registry of IPv4 addresses operated by ARIN is of general utility and >> value only while it accurately describes the current state of address >> distribution. If a class of address movement transactions are excluded >> from being entered in the registry, then the registry will have >> decreasing value to the broader community, and the integrity of the >> network itself is thereby compromised. This proposal's central aim is >> to ensure the continuing utility and value of the ARIN address >> registry by allowing the registry to record transactions where IPv4 >> addresses are transfered between ARIN account holders. >> >> It proposes that ARIN will recognise and register a transfer of >> addresses where the parties to the transfer are 'known' to ARIN and >> that the address block being transferred is part of ARIN's current >> address set. >> >> The proposal does not prescribe how such transfers may occur, nor >> impose any further constraints on the transfer or on the parties >> involved other than those described in this proposal. >> >> 9. Timetable for implementation: immediate. >> >> >> >> ________________________________ >> This E-mail and any of its attachments may contain Time Warner Cable >> proprietary information, which is privileged, confidential, or subject to >> copyright belonging to Time Warner Cable. This E-mail is intended solely >> for the use of the individual or entity to which it is addressed. If you >> are not the intended recipient of this E-mail, you are hereby notified >> that any dissemination, distribution, copying, or action taken in >> relation to the contents of and attachments to this E-mail is strictly >> prohibited and may be unlawful. If you have received this E-mail in >> error, please notify the sender immediately and permanently delete the >> original and any copy of this E-mail and any printout. >> _______________________________________________ >> 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 JOHN at egh.com Wed May 18 14:43:59 2011 From: JOHN at egh.com (John Santos) Date: Wed, 18 May 2011 14:43:59 -0400 Subject: [arin-ppml] ARIN-prop-151 IPv4 Transfer Policy Change to Keep Whois Accurate In-Reply-To: <4DD3F873.3080709@arin.net> Message-ID: <1110518143301.1397C-100000@Ives.egh.com> On Wed, 18 May 2011, ARIN wrote: > - The source entity will be ineligible to receive any further IPv4 > address allocations or assignments from ARIN for a period of 12 > months after the transfer, or until the exhaustion of ARIN's > IPv4 space, whichever occurs first. I don't understand the intent of the "or until the exhaustion of ARIN's IPv4 space" clause. Once ARIN is out of space, the eligibility of the source organization to receive more IPv4 is moot. However, if ARIN were to acquire more space subsequently (e.g. through reclaimation or return), this clause would make the source instantly eligible to receive that space. On the other hand, if ARIN still had a couple of /24s, it would not technically be exhausted, so the 12 month hold period would continue to apply to the source organization, even if someone subsequently returned a /8. Unless there is some rational reason for resetting the clock on ARIN exhaustion, I think everything after "12 months after the transfer" should be stricken. -- John Santos Evans Griffiths & Hart, Inc. 781-861-0670 ext 539 From matthew at matthew.at Wed May 18 14:47:59 2011 From: matthew at matthew.at (Matthew Kaufman) Date: Wed, 18 May 2011 11:47:59 -0700 Subject: [arin-ppml] ARIN-prop-151 IPv4 Transfer Policy Change to Keep Whois Accurate In-Reply-To: <1110518143301.1397C-100000@Ives.egh.com> References: <1110518143301.1397C-100000@Ives.egh.com> Message-ID: <7AD85DB1-4673-4037-97A6-1CEA78ED2334@matthew.at> On May 18, 2011, at 11:43 AM, John Santos wrote: > On Wed, 18 May 2011, ARIN wrote: > >> - The source entity will be ineligible to receive any further IPv4 >> address allocations or assignments from ARIN for a period of 12 >> months after the transfer, or until the exhaustion of ARIN's >> IPv4 space, whichever occurs first. > > I don't understand the intent of the "or until the exhaustion of ARIN's > IPv4 space" clause. Once ARIN is out of space, the eligibility of the > source organization to receive more IPv4 is moot. Well, no, it isnt moot. That's the whole issue we're debating. Right now in order to effect a transfer, the recipient must demonstrate need to ARIN, which ARIN evaluates using either a 3-month or 12-month need horizon, depending on the recipient's status. I think the intent here is that once ARIN Is out, we change how we do things. We might want to actually define exhaustion as "ARIN does not have enough space to fulfill " however. Matthew Kaufman From JOHN at egh.com Wed May 18 15:01:08 2011 From: JOHN at egh.com (John Santos) Date: Wed, 18 May 2011 15:01:08 -0400 Subject: [arin-ppml] ARIN-prop-151 Limiting Needs Requirements for IPv4 Transfers In-Reply-To: <7AD85DB1-4673-4037-97A6-1CEA78ED2334@matthew.at> Message-ID: <1110518145103.1397A-100000@Ives.egh.com> On Wed, 18 May 2011, Matthew Kaufman wrote: > > On May 18, 2011, at 11:43 AM, John Santos wrote: > > > On Wed, 18 May 2011, ARIN wrote: > > > >> - The source entity will be ineligible to receive any further IPv4 > >> address allocations or assignments from ARIN for a period of 12 > >> months after the transfer, or until the exhaustion of ARIN's > >> IPv4 space, whichever occurs first. > > > > I don't understand the intent of the "or until the exhaustion of ARIN's > > IPv4 space" clause. Once ARIN is out of space, the eligibility of the > > source organization to receive more IPv4 is moot. > > Well, no, it isnt moot. That's the whole issue we're debating. How can an org receive "further IPv4 address allocations *FROM* *ARIN*" if ARIN is exhausted? This clause says nothing about receiving addresses by buying them on the market. It is explicitly about getting addresses from ARIN. > > Right now in order to effect a transfer, the recipient must demonstrate need to ARIN, which ARIN evaluates using either a 3-month or 12-month need horizon, depending on the recipient's status. > > I think the intent here is that once ARIN Is out, we change how we do things. We might want to actually define exhaustion as "ARIN does not have enough space to fulfill " however. The point is, this will be a temporary condition. It might phase shift several times as exhaustion occurs. (Eventually, in much more than 12 months, IPv4 will no longer matter, and ARIN will probably accumulate lots of abandoned IPv4, but that's not what I'm concerned about.) > > Matthew Kaufman > > > -- John Santos Evans Griffiths & Hart, Inc. 781-861-0670 ext 539 From mike at nationwideinc.com Wed May 18 15:23:10 2011 From: mike at nationwideinc.com (Mike Burns) Date: Wed, 18 May 2011 15:23:10 -0400 Subject: [arin-ppml] ARIN-prop-151 IPv4 Transfer Policy Change to KeepWhois Accurate References: <1110518143301.1397C-100000@Ives.egh.com> Message-ID: <2172B2E7D04B436CB3E08FFADAECFDA5@mike> Hi John, I'm okay with striking everything after "12 months after the transfer". Regards, Mike ----- Original Message ----- From: "John Santos" To: "ARIN" Cc: Sent: Wednesday, May 18, 2011 2:43 PM Subject: Re: [arin-ppml] ARIN-prop-151 IPv4 Transfer Policy Change to KeepWhois Accurate > On Wed, 18 May 2011, ARIN wrote: > >> - The source entity will be ineligible to receive any further IPv4 >> address allocations or assignments from ARIN for a period of 12 >> months after the transfer, or until the exhaustion of ARIN's >> IPv4 space, whichever occurs first. > > I don't understand the intent of the "or until the exhaustion of ARIN's > IPv4 space" clause. Once ARIN is out of space, the eligibility of the > source organization to receive more IPv4 is moot. However, if ARIN > were to acquire more space subsequently (e.g. through reclaimation or > return), this clause would make the source instantly eligible to > receive that space. On the other hand, if ARIN still had a couple of > /24s, it would not technically be exhausted, so the 12 month hold > period would continue to apply to the source organization, even if > someone subsequently returned a /8. > > Unless there is some rational reason for resetting the clock on ARIN > exhaustion, I think everything after "12 months after the transfer" should > be stricken. > > -- > John Santos > Evans Griffiths & Hart, Inc. > 781-861-0670 ext 539 > > _______________________________________________ > 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 ipng at 69706e6720323030352d30312d31340a.nosense.org Wed May 18 18:06:59 2011 From: ipng at 69706e6720323030352d30312d31340a.nosense.org (Mark Smith) Date: Thu, 19 May 2011 07:36:59 +0930 Subject: [arin-ppml] Just a reminder of some quick mathematicsfor IPv4that shows the long term impossibility of it In-Reply-To: References: <4DCC41D8.1010305@ipinc.net> <714BA22421E941B68BE3268E21738D09@mike> <4DCD9C8A.1030701@ipinc.net> <20110517081155.22315ac7@opy.nosense.org> <20110518180549.20588961@opy.nosense.org> Message-ID: <20110519073659.3653d498@opy.nosense.org> Hi Chris, On Wed, 18 May 2011 09:43:04 -0400 Chris Engel wrote: > On Tue, 17 May 2011 18:18:02 -0500 > Blake Dunlap wrote: > > > > > > > > It's not all about you. This is standards development, not your network > > development. All needs must be considered. It is much less work for you to > > do things properly, than to force the rest of the world to do a lot of work > > so you can be lazy. > > > > Until there is an official anouncement apointing you "king of the internet" Well, Microsoft managed to buy the Catholic church a number of years ago, so it might still be possible that I'll be appointed King of the Internet. I might go and have a king's hat fitted at lunchtime today. > you don't get to dictate what anyone else impliments on thier own > networks. Write standards till your blue in the face. It's not going > to stop people from implimenting what makes sense to them. It won't > stop vendors from designing and selling solutions that they percieve > thier customers want and it won't stop people from voting with thier > feet and thier wallets. > Have a look up what the word "protocol" means, and think about why it has been used as the noun to describe the methods and message formats used by computers to communicate. A clue is that without a standard one, your computers won't. > Right now the populace of the net has overwhelmingly voted for NAT over IPv6. The comparitive adoption rates of both make that evident. Maybe that'll change in future, maybe not. One thing I'm fairly certain about, as much as some might wish to wax poetic about the "end to end" design of the internet.... the actual users of the internet are overwhelmingly picking other priorties over that, deal with it. Either way, you don't get more then one vote among the billions...no matter how many standards you participate in developing. > It looks like I've got an answer to my earlier question. Regards, Mark. From owen at delong.com Wed May 18 20:11:02 2011 From: owen at delong.com (Owen DeLong) Date: Wed, 18 May 2011 17:11:02 -0700 Subject: [arin-ppml] Just a reminder of some quick mathematicsfor IPv4that shows the long term impossibility of it In-Reply-To: References: <4DCC41D8.1010305@ipinc.net> <714BA22421E941B68BE3268E21738D09@mike> <4DCD9C8A.1030701@ipinc.net> <700C596A-658D-4550-9FA8-5D3409FAF294@delong.com> Message-ID: <93442FA7-6C3C-435A-9EB5-C438163316E3@delong.com> On May 17, 2011, at 8:10 AM, Chris Engel wrote: >>> >>> Even though I enjoy healthy debate as much as anyone, I'm not sure what >> the point or relevance of this thread is? Some participants here view >> universal end-to-end connectivity as an important goal and as such NAT >> being significantly harmful to the internet. Others of us believe that goal is >> not particularly desirable and possibly even harmful to the interests of a >> portion of the community....and thus NAT has significant utility that >> outweighs any potential harm. >>> >> >> The latter view presupposes an incorrect perception of both end to end and >> the capabilities of NAT. >> >> If you have good firewalls, there is no harm in leaving the packet header >> unmangled. >> >> The harm from NAT is huge and the utility of NAT is demonstrably small >> unless you are trying to conserve addresses. >> The value of conserving addresses in IPv6 is demonstrably small, therefore, I >> find it very unlikely that the utility of NAT >> could possibly outweigh the harm it is known to cause. >> > > In YOUR opinion. When a burning bush proclaims you infallible master of all technology, maybe that'll carry a little more weight. Until that happens, I'll simply maintain what common sense and my own experience tells me... that you are WRONG. Thanks. > Which part are you claiming is wrong? You feel there is great value in conserving addresses in IPv6? What utility does NAT offer other than conserving addresses that cannot be better accomplished by other technologies if you don't lack addresses? Security: Provably false. NAT does not improve security, stateful inspection provides security. Obfuscation of host addresses: If you believe this is a benefit, privacy addresses can provide it. Arguably this is more harm than benefit in most cases. Mutihoming: Easily accomplished with PI and BGP and much cleaner and more effective. (do-able with a very low-end router, too). Do you have some other utility for NAT not listed above? If not, then, I think perhaps this is more than just my opinion. > >>> Much like politics or religion, I don't believe either side will be effective in >> changing the others beliefs no matter how much verbiage is expended in the >> effort. That seems evident by the number of times this particular discussion >> has taken place on this list. Is it possible to simply agree to disagree on the >> utility/harm of NAT and set aside that portion of the discussion? >>> >> >> Not really. NAT is a toxic-polluter issue and those in favor of it are rarely its >> victims. That would be sort of like >> asking the residents of Bhopal to agree to disagree with Union Carbide about >> the utility/harm of irresponsible >> chemical processing. >> > > I would argue that the sort of peer-to-peer applications that you guys are pushing tend to be far more "toxic polluters" of the net then NAT. However, one man's garbage is another man's treasure and I'm open minded enough not to try to argue that every single peer-to-peer operator be shut down, even if I think 90% of them are pushing dreck. The only difference is that no packets which NAT would cause a problem with happen to leave my network. While most of the peer-to-peer application developers seem to spend considerable effort in circumventing other Network Operators purposefully crafted filtering policies.... things like running over ports used by other well known protocols and even encapsulating thier traffic in other protocols in an attempt to sneak by filtering rules. > Actually, NAT does create problems that stretch far beyond your network: + Increased application costs Developers have to spend time and resources developing workarounds for your damage to the network. Code complexity increases the probability (and occurrence) of bugs. + Decreased innovation Developers have to develop to the lowest common denominator meaning that innovations that could occur in the absence of NAT are stymied by its presence. + Increased abuse The obfuscation provided by NAT makes it harder to identify particular abusers and resolve such issues. + Increased troubleshooting costs Debugging things across a NAT is just harder than without it. Especially if you don't control the NAT or have access to the state tables. etc. None of the above are opinion. They're all demonstrable facts. It's not about open mindedness or one person's opinion of dreck vs. treasure. The toxic polluter model doesn't refer to the quality of stuff, it refers to the fact that you take an action on your network which has negative consequences and costs borne by others elsewhere on the internet, just as dumping toxic waste into the river has consequences and costs borne by those downstream, and not by the person dumping the waste into the river. > >>> Can we simply agree that at this particular point in time IPv4 address space >> continues to have some value/use to a significant portion of the internet >> community? >> >> I don't think that is in dispute. >> >>> >>> If we can generally agree on that proposition, then it seems clear that ARIN >> still has some responsibility for setting policies in regards assignment of that >> space. The question of whether the rest of the worlds population of >> human's, llama's or house flies will be able to access the internet through >> IPv4 strikes me as entirely tangential to that point. >> >> It is tangential to that point, but, it becomes quite meaningful to the >> discussion of what those policies should be. >> Since this thread has covered both the fact that ARIN should continue to set >> policies (which some seem to take >> as opinion rather than fact) as well as several aspects of what those policies >> should be, I don't think you can >> discard content of the thread just because it is not relevant to one of the >> topics in the thread. >> > > Ok I'll bite. What specificaly are addressing policy implications of the assertion (IF we accept it to be true) that the entire worlds population can't/shouldn't be put on the internet with IPv4? > 1. That we should not develop more aggressive policies trying to force more people to NAT. 2. That there may be implications to how we consider policies aimed at allowing what NAT is required in the least harmful way possible. I'm sure there may be other implications, but, it would depend on the context of a specific policy proposal. > Other then there needs to be addressing policies set for IPv6 and such space should be reasonably availble to those who need it? Neither of which seem to be in contention here? > We have seen people claiming that providers should be forced to free up space for NAT pools by NATing more of their customers. I don't see that as an overall win for the community, but, it's one example of a policy implication around NAT. >>> >>> FWIW, my particular hope is that IPv6 see's a steady increase in adoption so >> that people who do value publically addressable space can get it, IF they >> want it....and that NAT & IPv4 (and maybe even NAT66) continue to be >> available to those of us who prefer it as an option. The world is a diverse >> place, I don't see why the internet should not reflect that diversity in being >> able to cater to a varied and sometimes conflicting set of interests. Yes, that >> adds to the complexity of the system from an engineering standpoint....but >> so does manufacturing more then one size of shoe. >>> >> >> Because ISVs won't reflect that diversity and they will limit application >> features to the lowest common >> denominator. I don't want to see the internet hobbled by NAT any longer >> than it already has been. >> > > If you have a problem with the type of services that are being provided by service providers, you have two options... > > 1) Start up your own service and offer the kind of services that you think should be offered. If you are not off-target, you'll get plenty of customers. > > 2) Find a vendor willing to provide the type of services you want to see and give them your business. Then promote them. If enough people agree with your preference of services, they'll be successfull and those sort of services will become more commonly available. > > Don't try to promote your own preferences by limiting those of others. I'm not trying to limit your choices. If you want to damage your network, you're free to do so. However, that doesn't mean I can't call what you do broken since it does actually break the internet in ways that actually reach beyond the border of your network. Owen From george.herbert at gmail.com Wed May 18 21:33:02 2011 From: george.herbert at gmail.com (George Herbert) Date: Wed, 18 May 2011 18:33:02 -0700 Subject: [arin-ppml] Just a reminder of some quick mathematicsfor IPv4that shows the long term impossibility of it In-Reply-To: <93442FA7-6C3C-435A-9EB5-C438163316E3@delong.com> References: <4DCC41D8.1010305@ipinc.net> <714BA22421E941B68BE3268E21738D09@mike> <4DCD9C8A.1030701@ipinc.net> <700C596A-658D-4550-9FA8-5D3409FAF294@delong.com> <93442FA7-6C3C-435A-9EB5-C438163316E3@delong.com> Message-ID: On Wed, May 18, 2011 at 5:11 PM, Owen DeLong wrote: >[...] > > What utility does NAT offer other than conserving addresses that cannot be > better accomplished by other technologies if you don't lack addresses? > > ? ? ? ?Security: Provably false. NAT does not improve security, stateful > ? ? ? ? ? ? ? ?inspection provides security. I've had this argument with Owen in person (and many others in person), but asymmetrical routability and NAT provide some benefits to security. The statement "does not improve security" is provably false. Stateful inspection is MUCH BETTER - yes. But even stateful inspection isn't perfect if there are application layer vulnerabilities that the stateful inspector is not aware of. I remember the time before buffer overflow... At the very least, NAT and its ilk provide information limitations on potential attackers. This is not absolute, but neither is any other aspect of security. Security (and many other IT problems, generalizing) are statistical games of time-variable exposure potential and probability of exploit on known and unknown exposures. Anything which limits the attack space is of utility. How is this relevant to ARIN and policy? Policy should not be dictating technical solutions. I'm all for IPv6. I'm also all for NAT. Policy that attempts to exclude viable solutions at the technical level is unwise. -- -george william herbert george.herbert at gmail.com From owen at delong.com Wed May 18 23:45:55 2011 From: owen at delong.com (Owen DeLong) Date: Wed, 18 May 2011 20:45:55 -0700 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate In-Reply-To: <4DCFDB5C64DD4F738B65AB82D36B629D@mike> References: <4DCFDB5C64DD4F738B65AB82D36B629D@mike> Message-ID: <15F92ECD-2BE5-48F2-B65A-9A9D39B98F54@delong.com> On May 18, 2011, at 8:23 AM, Mike Burns wrote: > I wanted to take a second to provide some clarity on this particular email thread to ensure that everyone's expectations are the same. ARIN Staff touched base with the Proposal Originator (Mike Burns) and it was confirmed by Mike that his intent on sending this to PPML was not to formally submit it but to get feedback from the community prior to formally submitting. With that in mind, this proposal has not been assigned a Policy Proposal number as yet and AC shepherds have not been assigned. > > > > > Hi John, > > I will send it to policy at arin.net today. > > The objections I have noted seem to fall in three categories: > > 1. That's not the way we have historically dealt with addresses. That is not my impression of any of the objections raised, so, I think perhaps you misunderstand what some of the people were trying to get across to you. > 2. It could lead to disaggregation > 3. Hoarders and speculators will appear and will unfairly manipulate price. > These are both accurate and virtually guaranteed outcomes of the proposal as it was discussed. You also left off: 4. It might actually reduce whois accuracy rather than increase it. 5. Markets without additional controls inevitably lead to manipulation and dysfunction which requires later regulation to correct. These later corrections are rarely (if ever) effective at making the original victims of the manipulations and dysfunction whole. > As far as 2, this danger seems to be manageable, and there haven't been too many objections related to this lately. I have argued that the stewards of the APNIC region, led by Geoff Huston, considered this problem when deciding whether to have needs requirements on transfers, and decided the benefits to Whois accuracy outweighed the potential disaggregation problems. This cost is borne most by network operators, who presumably can make decisions on minimum block size which will allow them to run profitably. Those decisions will likely shape the transfer market, so nobody expects there to be much value in a /32 netblock, because network operators find this size unprofitable to route today. This ability of network operators provides a constraint on disaggregation in the transfer market. > People haven't been repeating what they already said. That does not mean that it is not still a factor, merely that we didn't think we needed to repeat ourselves on a topic already covered. In what way do you believe this danger would be manageable and/or managed under the proposed policy? Your belief that the ability of network operators will place a constraint on disaggregation in the transfer market presumes a number of facts not in evidence. Namely that: + There is some direct correlation between what people will buy and what they can get routed. + There is some correlation between what engineers can profitably route and what sales people will actually sell. + The feedback mechanism on these factors is fast enough that the market can keep pace with the effect the market is having on them. + There actually is a feedback mechanism by which the market and disaggregation will regulate each other to some livable equilibrium. In order to believe that this is not an issue, I think you would have to demonstrate that each of those assertions has at least a reasonable chance of being correct. > And as far as 3, I have argued that speculators provide a value to free markets, that most attempts to corner markets fail, that supply uncertainty and IPv6 deployment provide a poor environment for speculators. But inasmuch as this forum is populated by technical types who are making decisions here based on their understanding of, and philosophy of, economics, I have decided to take David Farmer's advice and add an anti-speculator, anti-hoarder protection in the form of a limit of a /12 equivalent for needs-free transfers per 12 month period. If more transfers than that are desired, the recipient will have to demonstrate need. Actually many attempts to corner markets in the case of a truly finite market with players that have effectively unlimited resources _AND_ motivations other than direct profit from the value of the market commodity succeed. While attempts to corner relatively large, and especially dynamically elastic markets (such as finished goods) by relatively small (value of player as compared to overall value of market) players are, in fact, doomed, that is not an accurate description of the likely IPv4 address market. > > As a whole, then, my policy seeks to recognize that there are transfer transactions which provide incentives for buyers and sellers of addresses but which transactions may not meed the needs requirements which ARIN mandates for transfers. There are thefts of automobiles which meet the needs of car thieves and the resellers who purchase the stolen cars from them. That does not make the legalization of car theft attractive. The question is whether removing the needs basis benefits the ARIN community as a whole, not just the individual participants in any particular transaction. ARIN does not need to make policy to the benefit of individual participants in a transaction. Our role as stewards is to make policy to the benefit of the community as a whole. Individual participants in a transaction are quite capable of looking out for their own immediate interests without involving ARIN policy. > Additionally, I pointed out that network operators, in my experience, will route addresses whose Whois record does not reflect that the network operator's customer is the registrant. The network operator, in my experience, will normally check to make sure that nobody else is advertising the addresses, and will solicit from the customer some documentary evidence that the customer has the right to the route the addresses, and then the network operator will route the addresses. > This is not my general experience. Most reputable operators will refuse to route addresses unless they have some reason to believe that the customer asking them to route them has some legitimate registration of those resources. Sure, there are ISPs that specialize in routing hijacked space to the benefit of snowshoe spammers and the like, but, they are relatively rare and tend to get de-peered over time. I agree that ARIN should get more aggressive about removing registrations for addresses which are no longer being held by the original resource holder or its legitimate successor through some form of section 8 transfer. ARIN should then reissue those available resources to organizations with documented need in a timely manner. > The net effect of these types of transactions is a lack of trust in the Whois table as an accurate source to check for authoritative routing rights. My proposal seeks to reduce the harm to Whois accuracy by extending the range of allowable transactions, providing additional incentive to have transfers reflected accurately by ARIN's updating of Whois to reflect the transfer. > There is no evidence whatsoever that this newfound range provides any incentive whatsoever for those transactions to be registered. Yes, it might actually remove some small amount of disincentive, but, I believe it would be better for ARIN to provide incentive for accurate whois through a more active audit and reclamation process as that would also better serve the community by reducing the probability of hijacked space being invisibly routed as well as making some abandoned resources available to the ARIN community for reuse. > As we move into a trading world, which will happen whether or not my proposal passes, conflicts over address control are likely to increase, and the value of trust in Whois as the routing authority will also increase. Rather than sit back and watch Whois decay, I urge ARIN stewards to consider making these changes to foster accuracy in Whois. > There is no proof these changes will foster accuracy in Whois. Owen From owen at delong.com Thu May 19 01:12:54 2011 From: owen at delong.com (Owen DeLong) Date: Wed, 18 May 2011 22:12:54 -0700 Subject: [arin-ppml] Just a reminder of some quick mathematicsfor IPv4that shows the long term impossibility of it In-Reply-To: References: <4DCC41D8.1010305@ipinc.net> <714BA22421E941B68BE3268E21738D09@mike> <4DCD9C8A.1030701@ipinc.net> <700C596A-658D-4550-9FA8-5D3409FAF294@delong.com> <93442FA7-6C3C-435A-9EB5-C438163316E3@delong.com> Message-ID: On May 18, 2011, at 6:33 PM, George Herbert wrote: > On Wed, May 18, 2011 at 5:11 PM, Owen DeLong wrote: >> [...] >> >> What utility does NAT offer other than conserving addresses that cannot be >> better accomplished by other technologies if you don't lack addresses? >> >> Security: Provably false. NAT does not improve security, stateful >> inspection provides security. > > I've had this argument with Owen in person (and many others in > person), but asymmetrical routability and NAT provide some benefits to > security. The statement "does not improve security" is provably > false. > Provably it is a NET security negative. > Stateful inspection is MUCH BETTER - yes. But even stateful > inspection isn't perfect if there are application layer > vulnerabilities that the stateful inspector is not aware of. I > remember the time before buffer overflow... > And NAT doesn't protect you from those, either. It just provides a false sense of security. > At the very least, NAT and its ilk provide information limitations on > potential attackers. This is not absolute, but neither is any other > aspect of security. > I believe this fits someone's earlier "screen doors improve the security of vault doors" comment. > Security (and many other IT problems, generalizing) are statistical > games of time-variable exposure potential and probability of exploit > on known and unknown exposures. Anything which limits the attack > space is of utility. > Which NAT does not. > How is this relevant to ARIN and policy? Policy should not be > dictating technical solutions. I'm all for IPv6. I'm also all for > NAT. Policy that attempts to exclude viable solutions at the > technical level is unwise. > The point was that policy should not exclude non-NAT solutions wherever possible. Owen From tedm at ipinc.net Thu May 19 04:49:53 2011 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Thu, 19 May 2011 01:49:53 -0700 Subject: [arin-ppml] Just a reminder of some quick mathematicsfor IPv4that shows the long term impossibility of it In-Reply-To: References: <4DCC41D8.1010305@ipinc.net> <714BA22421E941B68BE3268E21738D09@mike> <4DCD9C8A.1030701@ipinc.net> <700C596A-658D-4550-9FA8-5D3409FAF294@delong.com> <93442FA7-6C3C-435A-9EB5-C438163316E3@delong.com> Message-ID: <4DD4D9B1.60706@ipinc.net> On 5/18/2011 6:33 PM, George Herbert wrote: > On Wed, May 18, 2011 at 5:11 PM, Owen DeLong wrote: >> [...] >> >> What utility does NAT offer other than conserving addresses that cannot be >> better accomplished by other technologies if you don't lack addresses? >> >> Security: Provably false. NAT does not improve security, stateful >> inspection provides security. > > I've had this argument with Owen in person (and many others in > person), but asymmetrical routability and NAT provide some benefits to > security. The statement "does not improve security" is provably > false. > > Stateful inspection is MUCH BETTER - yes. But even stateful > inspection isn't perfect if there are application layer > vulnerabilities that the stateful inspector is not aware of. I > remember the time before buffer overflow... > > At the very least, NAT and its ilk provide information limitations on > potential attackers. This is not absolute, but neither is any other > aspect of security. > > Security (and many other IT problems, generalizing) are statistical > games of time-variable exposure potential and probability of exploit > on known and unknown exposures. Anything which limits the attack > space is of utility. > > How is this relevant to ARIN and policy? Policy should not be > dictating technical solutions. I'm all for IPv6. I'm also all for > NAT. Policy that attempts to exclude viable solutions at the > technical level is unwise. > My original point in starting this thread was NOT to attempt to dictate policy that excluded technical solutions. I was merely attempting to illustrate the sheer futility of spending so much time on attempting to help keep IPv4 going in the long term. I run NAT and RFC1918 numbers on my home network. I also run IPv6 natively on my home network. My home router - which is a FreeBSD system - routes IPv6 and does NAT on IPv4 just fine. I even run an IPv6 firewall on it. And it is connected via DSL to the ISP I run, which offers both IPv4 and IPv6. And my systems behind my router - which are autoassigned and dual-stacked, including Windows XP systems - work perfectly on my network to access both IPv4 and IPv6 networks. Speed of access of content providing sites that are either IPv6 or IPv4 or dual-stacked on the Internet is the same. Telnet and SSH access to either IPv4 or IPv6 numbers of hosts at the ISP and on the Internet works fine too. If every location that I accessed on the Internet was dual-stacked and I replaced my remaining Windows XP systems, I could drop IPv4 and not even miss it. Nowhere am I running any form of IPv6 NAT, I'm not running any kind of IPv6->IPv4 NAT or IPv4->IPv6 NAT. My setup was not difficult to put together and the only thing needed to duplicate it to a typical end user is a IPv4/IPv6 CPE. With my experience it is crystal clear to me that there is only ONE reason that anyone would advocate continued usage of IPv4 on the Internet, and that is that they want to allow content providers to continue to provide content ONLY via IPv4. However, I fail to see why the masses of end users out there who are not on the Internet now, but will be in the future, and who are never going to ever get a public IPv4 address in their lifetime assigned to anything that they own, should have to saddle themselves with weird IPv6->IPv4 NAT bridge devices or CGN with private numbers handed to them, just to allow a group of content providers to remain on the IPv4 network. The real question is "why should we build a future Internet that is dependent in any way on IPv4" We should not. And in a future Internet where all content providers are dual-stacked, a client system will have no problems they would need IPv4 to solve. Ted > > From mike at nationwideinc.com Thu May 19 10:59:58 2011 From: mike at nationwideinc.com (Mike Burns) Date: Thu, 19 May 2011 10:59:58 -0400 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate References: <4DCFDB5C64DD4F738B65AB82D36B629D@mike> <15F92ECD-2BE5-48F2-B65A-9A9D39B98F54@delong.com> Message-ID: <0829B106605C4FE8B189DB2E56C69615@mike> Hi Owen, >You also left off: >4. It might actually reduce whois accuracy rather than increase it. Why does anybody think that removing the needs requirement for transfers would degrade whois accuracy? The only support for that contention was the idea that because the needs requirement involved some extra informational flow, the contact information would be more accurate. I argue that registration will become more and more important, and John Curran indicated there was an uptick in 8.2 Transfers for old M&A activity, which I held to be an indication that holders of addresses find registration valuable, and likely more so as the addresses increase in monetary value. People will naturally want their ownership rights established in whatever venue is appropriate, and for ip address holdings, that venue is Whois. I don't think the argument that my proposal will reduce Whois accuracy holds water, is there anybody who wants to continue to make that charge? >5. Markets without additional controls inevitably lead to manipulation and >dysfunction >which requires later regulation to correct. These later corrections are >rarely (if ever) >effective at making the original victims of the manipulations and >dysfunction whole. First, this is your opinion only, second, I already alluded to speculators and hoarders, and your number 5 is merely a restatement. >> As far as 2, this danger seems to be manageable, and there haven't been >> too many objections related to this lately. I have argued that the >> stewards of the APNIC region, led by Geoff Huston, considered this >> problem when deciding whether to have needs requirements on transfers, >> and decided the benefits to >>Whois accuracy outweighed the potential >> disaggregation problems. This cost is borne most by network operators, >> who presumably can make decisions on minimum block size which will allow >> them to run profitably. Those decisions will likely shape the transfer >> market, so nobody expects there to be much >>value in a /32 netblock, >> because network operators find this size unprofitable to route today. >> This ability of network operators provides a constraint on disaggregation >> in the transfer market. > >People haven't been repeating what they already said. That does not mean >that it is not still a factor, merely that we didn't >think we needed to repeat ourselves on a topic already covered. >In what way do you believe this danger would be manageable and/or managed >under the proposed policy? Primarily, I associate my decision with Geoff Huston's decision at APNIC. Geoff is one of the world's top experts on BGP, I think it fair to say, and yet he viewed the danger to Whois accuracy in maintaining needs as outweighing the danger of disaggregation. Secondarily, I believe that private network operators are the ultimate decisionmakers here. If they won't route a netblock, the value of the netblock is reduced significantly. >Your belief that the ability of network operators will place a constraint >on disaggregation in the transfer market >presumes a number of facts not in evidence. Namely that: >+ There is some direct correlation between what people will buy and what >they can get routed. What kind of evidence would satisfy you? The absence of recorded /32 transactions? Just use common sense, and put yourself in the position of a buyer. >+ There is some correlation between what engineers can profitably route and >what sales people >will actually sell. There is a correlation, because if the sales people continue to sell unprofitably, the company will go out of business. >+ The feedback mechanism on these factors is fast enough that the market >can keep pace with >the effect the market is having on them. To keep the market moving at its quickest pace, lower transactional costs like the artificial needs analysis. Surely having that requirement will slow transactional pace as well as drive transactions off the books. >+ There actually is a feedback mechanism by which the market and >disaggregation will regulate >each other to some livable equilibrium. The feedback mechanism is price. The network operators will effectively set the floor for size. The price will reflect the netblock's routability. >In order to believe that this is not an issue, I think you would have to >demonstrate that each of those >assertions has at least a reasonable chance of being correct. >> And as far as 3, I have argued that speculators provide a value to free >> markets, that most attempts to corner markets fail, that supply >> uncertainty and IPv6 deployment provide a poor environment for >> speculators. But inasmuch as this forum is populated by technical types >> who are making decisions here based >>on their understanding of, and >> philosophy of, economics, I have decided to take David Farmer's advice >> and add an anti-speculator, anti-hoarder protection in the form of a >> limit of a /12 equivalent for needs-free transfers per 12 month period. >> If more transfers than that are desired, the recipient will have to >> >>demonstrate need. >Actually many attempts to corner markets in the case of a truly finite >market with players that have effectively unlimited >resources _AND_ motivations other than direct profit from the value of the >market commodity succeed. Could I get some examples from the many you allude to? >While attempts to corner relatively large, and especially dynamically >elastic markets (such as finished goods) by relatively small (value >of player as compared to overall value of market) players are, in fact, >doomed, that is not an accurate description >of the likely IPv4 address market. I have already pointed out the obvious risk that CGN has for anybody who tries to corner the market. There is also the very obvious risk that IPv6 will finally take off. And when there is an alternative, the very action of the cornerers drives the market to that alternative, posing additional risks to these speculators. As to the smallness of the market, we are in fact talking about a trillion dollar network running on a pool of 3.8 billion address units worth at least $40 billion right now. An international commodities market consisting of fungible, valuable, and transportable assets is in the offing. The supply source of unknown depth and availabilty, although we know the total upper bound of the market. And of course, no evidence of this activity that you can point to in the nascent APNIC marketplace as evidenced by tradeipv4.com. > >> As a whole, then, my policy seeks to recognize that there are transfer >> transactions which provide incentives for buyers and sellers of addresses >> but which transactions may not meed the needs requirements which ARIN >> mandates for transfers. >There are thefts of automobiles which meet the needs of car thieves and the >resellers who purchase the stolen >cars from them. That does not make the legalization of car theft >attractive. Geez, maybe you should have used kidnappers of children and the child-sex rings who purchase them! You obviously have an emotional view that transfers of addresses are akin to theft from the rightful owner, ARIN. In that I think you act more as king than steward. At least in terms of legacy space, the holders of address rights *predate* ARIN, and yet in your mind, if they transfer them without telling ARIN, they are thieves and hijackers. >>The question is whether removing the needs basis benefits the ARIN >>community as a whole, not just the individual participants in any >>particular >>transaction. ARIN does not need to make policy to the benefit of >>individual participants in a transaction. >>Our role as stewards is to make policy to the benefit of the community as >>a whole. Individual participants in a >>transaction are quite capable of looking out for their own immediate >>interests without involving ARIN policy. My rationale is the stewardship of Whois, which benefits the entire Internet community. >> Additionally, I pointed out that network operators, in my experience, >> will route addresses whose Whois record does not reflect that the network >> operator's customer is the registrant. The network operator, in my >> experience, will normally check to make sure that nobody else is >> advertising the addresses, and >>will solicit from the customer some >> documentary evidence that the customer has the right to the route the >> addresses, and then the network operator will route the addresses. > >This is not my general experience. Most reputable operators will refuse to >route addresses unless they have >some reason to believe that the customer asking them to route them has some >legitimate registration of those >resources. The legitimate reason is the documentary evidence of transfer in the form of a merger, acquisition, asset sale, or Letter of Agency. >Sure, there are ISPs that specialize in routing hijacked space to the >benefit of snowshoe spammers >and the like, but, they are relatively rare and tend to get de-peered over >time. And how is a company with a three-year planning window like a snowshoe spammer or hijacker? These companies cannot pass the ARIN needs requirements, and would be incentivized to purchase enough addresses on the transfer market. The seller is incentivized by the money the buyer will pay. The network operator is incentivized by the money the buyer will pay him, and is satisfied by documentary evidence of the transfer that the buyer has the right to route. The net result is Whois inaccuracy (and the fact that the buyer will have no RSA with ARIN). >I agree that ARIN should get more aggressive about removing registrations >for addresses which are no longer >being held by the original resource holder or its legitimate successor >through some form of section 8 transfer. >ARIN should then reissue those available resources to organizations with >documented need in a timely manner. This is your stick to my carrot. And wielding that stick can get very expensive for ARIN through legal costs. And as far as legacy addresses go, ARIN can spend through the nose on lawyers, but my reading of MS/Nortel and the Plzack declaration in the Kremen case leads me to believe that would be money ARIN would waste. >> The net effect of these types of transactions is a lack of trust in the >> Whois table as an accurate source to check for authoritative routing >> rights. My proposal seeks to reduce the harm to Whois accuracy by >> extending the range of allowable transactions, providing additional >> incentive to have transfers reflected >>accurately by ARIN's updating of >> Whois to reflect the transfer. > >There is no evidence whatsoever that this newfound range provides any >incentive whatsoever for those >transactions to be registered. Owen, you said a couple of paragraphs ago that network operators would check registration when asked by a customer to route addresses. I agree that is the first place they would go, and that is one of the incentives for address transferees to seek registration. The other is the fact that this is really the only public venue for the registration of ownership rights, and I believe registration increases the resale value of the addresses. I point again to MS/Nortel and the luckiness that MS had a need exactly equal to a previously negotiated sale with Nortel. Had that need not matched precisely with the addresses allocated to Nortel's acquisitions 20 years ago, what would have happened? I think we all know what would have happened, and that is that Microsoft would soon be routing those addresses, and Whois would still list Nortel, or even some Nortel acquistion, as the registrant. This was the spur for my proposal. Had the needs requirement not been in place, the transaction could have flowed through 8.3, and the natural incentives towards registration would have caused Whois to accurately reflect Microsoft as the new registrant. In addition to this public transaction, I offered some other potential transactions which would also fail the needs test, among which is a buyer with a 2 year planning horizon. I will continue to use this example, as recent proposals to extend the needs window attest to the belief among some that having a 2 year planning window does not put you in the same league as spammers, speculators, and hijackers. >Yes, it might actually remove some small amount of disincentive, but, I >believe >it would be better for ARIN to provide incentive for accurate whois through >a more active audit and >reclamation process as that would also better serve the community by >reducing the probability of hijacked >space being invisibly routed as well as making some abandoned resources >available to the ARIN community >for reuse. Again with the stick. How successfully as this stick been weilded in the past? >> As we move into a trading world, which will happen whether or not my >> proposal passes, conflicts over address control are likely to increase, >> and the value of trust in Whois as the routing authority will also >> increase. Rather than sit back and watch Whois decay, I urge ARIN >> stewards to consider making these >>changes to foster accuracy in Whois. > >There is no proof these changes will foster accuracy in Whois. >Owen There is proof that transfers have occurred that have not been reflected in Whois. John mentioned the current 8.2 requests to reflect old mergers and acquisitions. So we know that transfers have occurred among the non-reprobate which are not reflected in Whois. I have pointed out that there is a major change afoot, the development of an ip address transfer market. So looking in the past for proof, or really looking anywhere for proof of results of a change which has not occurred yet, is specious. Regards, Mike From cengel at conxeo.com Thu May 19 12:11:04 2011 From: cengel at conxeo.com (Chris Engel) Date: Thu, 19 May 2011 12:11:04 -0400 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate In-Reply-To: <0829B106605C4FE8B189DB2E56C69615@mike> References: <4DCFDB5C64DD4F738B65AB82D36B629D@mike> <15F92ECD-2BE5-48F2-B65A-9A9D39B98F54@delong.com> <0829B106605C4FE8B189DB2E56C69615@mike> Message-ID: > Hi Owen, > > >You also left off: > > >4. It might actually reduce whois accuracy rather than increase it. > > Why does anybody think that removing the needs requirement for transfers > would degrade whois accuracy? > The only support for that contention was the idea that because the needs > requirement involved some extra informational flow, the contact > information > would be more accurate. > I argue that registration will become more and more important, and John > Curran indicated there was an uptick in 8.2 Transfers for old M&A activity, > which I held to be an indication that holders of addresses find registration > valuable, and likely more so as the addresses increase in monetary value. > People will naturally want their ownership rights established in whatever > venue is appropriate, and for ip address holdings, that venue is Whois. > I don't think the argument that my proposal will reduce Whois accuracy holds > water, is there anybody who wants to continue to make that charge? > > > >5. Markets without additional controls inevitably lead to manipulation and > >dysfunction > >which requires later regulation to correct. These later corrections are > >rarely (if ever) > >effective at making the original victims of the manipulations and > >dysfunction whole. > > First, this is your opinion only, second, I already alluded to speculators > and hoarders, and your number 5 is merely a restatement. > > > >> As far as 2, this danger seems to be manageable, and there haven't been > >> too many objections related to this lately. I have argued that the > >> stewards of the APNIC region, led by Geoff Huston, considered this > >> problem when deciding whether to have needs requirements on > transfers, > >> and decided the benefits to >>Whois accuracy outweighed the potential > >> disaggregation problems. This cost is borne most by network operators, > >> who presumably can make decisions on minimum block size which will > allow > >> them to run profitably. Those decisions will likely shape the transfer > >> market, so nobody expects there to be much >>value in a /32 netblock, > >> because network operators find this size unprofitable to route today. > >> This ability of network operators provides a constraint on disaggregation > >> in the transfer market. > > > > >People haven't been repeating what they already said. That does not mean > >that it is not still a factor, merely that we didn't > >think we needed to repeat ourselves on a topic already covered. > > >In what way do you believe this danger would be manageable and/or > managed > >under the proposed policy? > > Primarily, I associate my decision with Geoff Huston's decision at APNIC. > Geoff is one of the world's top experts on BGP, I think it fair to say, and > yet he viewed the danger to Whois accuracy in maintaining needs as > outweighing the danger of disaggregation. > Secondarily, I believe that private network operators are the ultimate > decisionmakers here. If they won't route a netblock, the value of the > netblock is reduced significantly. > > > >Your belief that the ability of network operators will place a constraint > >on disaggregation in the transfer market > >presumes a number of facts not in evidence. Namely that: > >+ There is some direct correlation between what people will buy and what > >they can get routed. > > What kind of evidence would satisfy you? The absence of recorded /32 > transactions? > Just use common sense, and put yourself in the position of a buyer. > > >+ There is some correlation between what engineers can profitably route > and > >what sales people > >will actually sell. > > There is a correlation, because if the sales people continue to sell > unprofitably, the company will go out of business. > > >+ The feedback mechanism on these factors is fast enough that the market > >can keep pace with > >the effect the market is having on them. > > To keep the market moving at its quickest pace, lower transactional costs > like the artificial needs analysis. > Surely having that requirement will slow transactional pace as well as drive > transactions off the books. > > >+ There actually is a feedback mechanism by which the market and > >disaggregation will regulate > >each other to some livable equilibrium. > > The feedback mechanism is price. The network operators will effectively set > the floor for size. > The price will reflect the netblock's routability. > > >In order to believe that this is not an issue, I think you would have to > >demonstrate that each of those > >assertions has at least a reasonable chance of being correct. > > >> And as far as 3, I have argued that speculators provide a value to free > >> markets, that most attempts to corner markets fail, that supply > >> uncertainty and IPv6 deployment provide a poor environment for > >> speculators. But inasmuch as this forum is populated by technical types > >> who are making decisions here based >>on their understanding of, and > >> philosophy of, economics, I have decided to take David Farmer's advice > >> and add an anti-speculator, anti-hoarder protection in the form of a > >> limit of a /12 equivalent for needs-free transfers per 12 month period. > >> If more transfers than that are desired, the recipient will have to > >> >>demonstrate need. > > >Actually many attempts to corner markets in the case of a truly finite > >market with players that have effectively unlimited > >resources _AND_ motivations other than direct profit from the value of the > >market commodity succeed. > > Could I get some examples from the many you allude to? > > >While attempts to corner relatively large, and especially dynamically > >elastic markets (such as finished goods) by relatively small (value > >of player as compared to overall value of market) players are, in fact, > >doomed, that is not an accurate description > >of the likely IPv4 address market. > > I have already pointed out the obvious risk that CGN has for anybody who > tries to corner the market. > There is also the very obvious risk that IPv6 will finally take off. > And when there is an alternative, the very action of the cornerers drives > the market to that alternative, posing additional risks to these > speculators. > As to the smallness of the market, we are in fact talking about a trillion > dollar network running on a pool of 3.8 billion address units worth at least > $40 billion right now. > An international commodities market consisting of fungible, valuable, and > transportable assets is in the offing. > The supply source of unknown depth and availabilty, although we know the > total upper bound of the market. > And of course, no evidence of this activity that you can point to in the > nascent APNIC marketplace as evidenced by tradeipv4.com. > > > > >> As a whole, then, my policy seeks to recognize that there are transfer > >> transactions which provide incentives for buyers and sellers of addresses > >> but which transactions may not meed the needs requirements which > ARIN > >> mandates for transfers. > > >There are thefts of automobiles which meet the needs of car thieves and > the > >resellers who purchase the stolen > >cars from them. That does not make the legalization of car theft > >attractive. > > Geez, maybe you should have used kidnappers of children and the child-sex > rings who purchase them! > You obviously have an emotional view that transfers of addresses are akin to > theft from the rightful owner, ARIN. > In that I think you act more as king than steward. > At least in terms of legacy space, the holders of address rights *predate* > ARIN, and yet in your mind, if they transfer them without telling ARIN, they > are thieves and hijackers. > > > >>The question is whether removing the needs basis benefits the ARIN > >>community as a whole, not just the individual participants in any > >>particular > >>transaction. ARIN does not need to make policy to the benefit of > >>individual participants in a transaction. > >>Our role as stewards is to make policy to the benefit of the community as > >>a whole. Individual participants in a > >>transaction are quite capable of looking out for their own immediate > >>interests without involving ARIN policy. > > My rationale is the stewardship of Whois, which benefits the entire Internet > community. > > >> Additionally, I pointed out that network operators, in my experience, > >> will route addresses whose Whois record does not reflect that the > network > >> operator's customer is the registrant. The network operator, in my > >> experience, will normally check to make sure that nobody else is > >> advertising the addresses, and >>will solicit from the customer some > >> documentary evidence that the customer has the right to the route the > >> addresses, and then the network operator will route the addresses. > > > > >This is not my general experience. Most reputable operators will refuse to > >route addresses unless they have > >some reason to believe that the customer asking them to route them has > some > >legitimate registration of those > >resources. > > The legitimate reason is the documentary evidence of transfer in the form of > a merger, acquisition, asset sale, or Letter of Agency. > > >Sure, there are ISPs that specialize in routing hijacked space to the > >benefit of snowshoe spammers > >and the like, but, they are relatively rare and tend to get de-peered over > >time. > > And how is a company with a three-year planning window like a snowshoe > spammer or hijacker? > These companies cannot pass the ARIN needs requirements, and would be > incentivized to purchase enough addresses on the transfer market. > The seller is incentivized by the money the buyer will pay. > The network operator is incentivized by the money the buyer will pay him, > and is satisfied by documentary evidence of the transfer that the buyer has > the right to route. > The net result is Whois inaccuracy (and the fact that the buyer will have no > RSA with ARIN). > > > >I agree that ARIN should get more aggressive about removing registrations > >for addresses which are no longer > >being held by the original resource holder or its legitimate successor > >through some form of section 8 transfer. > >ARIN should then reissue those available resources to organizations with > >documented need in a timely manner. > > This is your stick to my carrot. And wielding that stick can get very > expensive for ARIN through legal costs. > And as far as legacy addresses go, ARIN can spend through the nose on > lawyers, but my reading of MS/Nortel and the Plzack declaration in the > Kremen case leads me to believe that would be money ARIN would waste. > > > >> The net effect of these types of transactions is a lack of trust in the > >> Whois table as an accurate source to check for authoritative routing > >> rights. My proposal seeks to reduce the harm to Whois accuracy by > >> extending the range of allowable transactions, providing additional > >> incentive to have transfers reflected >>accurately by ARIN's updating of > >> Whois to reflect the transfer. > > > > >There is no evidence whatsoever that this newfound range provides any > >incentive whatsoever for those > >transactions to be registered. > > Owen, you said a couple of paragraphs ago that network operators would > check > registration when asked by a customer to route addresses. > I agree that is the first place they would go, and that is one of the > incentives for address transferees to seek registration. > The other is the fact that this is really the only public venue for the > registration of ownership rights, and I believe registration increases the > resale value of the addresses. > I point again to MS/Nortel and the luckiness that MS had a need exactly > equal to a previously negotiated sale with Nortel. > Had that need not matched precisely with the addresses allocated to Nortel's > acquisitions 20 years ago, what would have happened? > I think we all know what would have happened, and that is that Microsoft > would soon be routing those addresses, and Whois would still list Nortel, or > even some Nortel acquistion, as the registrant. > This was the spur for my proposal. Had the needs requirement not been in > place, the transaction could have flowed through 8.3, and the natural > incentives towards registration would have caused Whois to accurately > reflect Microsoft as the new registrant. > In addition to this public transaction, I offered some other potential > transactions which would also fail the needs test, among which is a buyer > with a 2 year planning horizon. > I will continue to use this example, as recent proposals to extend the needs > window attest to the belief among some that having a 2 year planning > window > does not put you in the same league as spammers, speculators, and > hijackers. > > >Yes, it might actually remove some small amount of disincentive, but, I > >believe > >it would be better for ARIN to provide incentive for accurate whois through > >a more active audit and > >reclamation process as that would also better serve the community by > >reducing the probability of hijacked > >space being invisibly routed as well as making some abandoned resources > >available to the ARIN community > >for reuse. > > Again with the stick. How successfully as this stick been weilded in the > past? > > > >> As we move into a trading world, which will happen whether or not my > >> proposal passes, conflicts over address control are likely to increase, > >> and the value of trust in Whois as the routing authority will also > >> increase. Rather than sit back and watch Whois decay, I urge ARIN > >> stewards to consider making these >>changes to foster accuracy in Whois. > > > > >There is no proof these changes will foster accuracy in Whois. > > >Owen > > There is proof that transfers have occurred that have not been reflected in > Whois. John mentioned the current 8.2 requests to reflect old mergers and > acquisitions. > So we know that transfers have occurred among the non-reprobate which > are > not reflected in Whois. > I have pointed out that there is a major change afoot, the development of > an ip address transfer market. > So looking in the past for proof, or really looking anywhere for proof of > results of a change which has not occurred yet, is specious. > > Regards, > Mike > > I think Mike makes some strong points here. Let's suppose for a moment that Microsoft had not been able somehow to come up with a needs justification for the space they got and had not received ARIN's blessing. What do you think would have been the result? Would you have wanted to be the poor sap receiving an allocation from that space which Microsoft just bought? What about a Network Operator having to decide between routing what Microsoft and a bankruptcy court legally believe Microsoft owns and what ARIN claims they don't? What about after you get hit with the "restraint of trade" suit by MS lawyers? I can see how ARIN has some legal control over how space it's issued out under contract get's transferred to it.... but legacy space held by entities that have predated it and which it never had any contractual relationships over? Maybe ARIN is relatively litigation-proof since it's just offering a listing service essentially.... but I'm not really sure to what degree the network operators who would be refusing to carry routes would be? You can certainly bet that if there is a current holder and a buyer and both are legitimate organizations, If they aren't allowed to make a transfer...... there is going to be alot of pressure to bypass ARIN and seek redress from the courts and government agencies. Unless we really are talking corner cases where it mostly really is hijackers, spammers and blackhats that are getting turned away....and legitimate buyers seem to magically meet needs justifications for just the space they want to acquire... I think things could get pretty ugly. Frankly, as a member of the general public..... I'm not even sure I wouldn't prefer having the courts or a government agency calling the shots here anyway. Christopher Engel (representing only my own private views) From owen at delong.com Thu May 19 12:45:34 2011 From: owen at delong.com (Owen DeLong) Date: Thu, 19 May 2011 09:45:34 -0700 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate In-Reply-To: <0829B106605C4FE8B189DB2E56C69615@mike> References: <4DCFDB5C64DD4F738B65AB82D36B629D@mike> <15F92ECD-2BE5-48F2-B65A-9A9D39B98F54@delong.com> <0829B106605C4FE8B189DB2E56C69615@mike> Message-ID: <8FB24038-B813-4DE0-91DD-56EDAD31BC03@delong.com> On May 19, 2011, at 7:59 AM, Mike Burns wrote: > Hi Owen, > >> You also left off: > >> 4. It might actually reduce whois accuracy rather than increase it. > > Why does anybody think that removing the needs requirement for transfers would degrade whois accuracy? Because that is exactly what happened to DNS whois when stewardship was abandoned there in favor of an uncontrolled market. > The only support for that contention was the idea that because the needs requirement involved some extra informational flow, the contact information would be more accurate. No, that was ONE element of support and I believe it holds true. > I argue that registration will become more and more important, and John Curran indicated there was an uptick in 8.2 Transfers for old M&A activity, which I held to be an indication that holders of addresses find registration valuable, and likely more so as the addresses increase in monetary value. Which would argue that removing needs basis will not improve that situation. > People will naturally want their ownership rights established in whatever venue is appropriate, and for ip address holdings, that venue is Whois. > I don't think the argument that my proposal will reduce Whois accuracy holds water, is there anybody who wants to continue to make that charge? > I will continue to make the charge that it is one possible outcome and just as likely as any claim that your proposal could somehow improve it. > >> 5. Markets without additional controls inevitably lead to manipulation and dysfunction >> which requires later regulation to correct. These later corrections are rarely (if ever) >> effective at making the original victims of the manipulations and dysfunction whole. > > First, this is your opinion only, second, I already alluded to speculators and hoarders, and your number 5 is merely a restatement. > Speculators and hoarders are not the only forms of manipulation and dysfunction that tend to occur. Can you cite a single example of a long-term market that was unregulated and did not devolve as I describe? I believe that this is a statement of fact over the entire history of markets rather than merely my opinion. > >>> As far as 2, this danger seems to be manageable, and there haven't been too many objections related to this lately. I have argued that the stewards of the APNIC region, led by Geoff Huston, considered this problem when deciding whether to have needs requirements on transfers, and decided the benefits to >>Whois accuracy outweighed the potential disaggregation problems. This cost is borne most by network operators, who presumably can make decisions on minimum block size which will allow them to run profitably. Those decisions will likely shape the transfer market, so nobody expects there to be much >>value in a /32 netblock, because network operators find this size unprofitable to route today. This ability of network operators provides a constraint on disaggregation in the transfer market. >> > >> People haven't been repeating what they already said. That does not mean that it is not still a factor, merely that we didn't >> think we needed to repeat ourselves on a topic already covered. > >> In what way do you believe this danger would be manageable and/or managed under the proposed policy? > > Primarily, I associate my decision with Geoff Huston's decision at APNIC. OK... > Geoff is one of the world's top experts on BGP, I think it fair to say, and yet he viewed the danger to Whois accuracy in maintaining needs as outweighing the danger of disaggregation. Geoff's statements were actually more along the lines of what's about to happen with BGP will happen whether we register it in whois or not and he did not believe that efforts at stewardship on the part of the RIRs could prevent it, so, he thought it was better for the RIRs to attempt to accurately record the disaster than try to prevent it. I am not as fatalistic as Geoff and I think that in general, the ARIN community is less fatalistic than the APNIC community. As such, I think there is value in attempting to prevent the disaster rather than merely standing in front of the damn throwing my hands up in the air and writing down the precise time that it bursts before I am overwhelmed with water (which is basically Geoff's approach). > Secondarily, I believe that private network operators are the ultimate decisionmakers here. If they won't route a netblock, the value of the netblock is reduced significantly. > Of course they are. I believe that private network operators will see value in RIR stewardship of the resources and will look to the RIRs for guidance on what should or shouldn't get routed. If the RIRs make insane decisions, the value of the RIR data for that purpose will be degraded. Allowing a free-for-all in transfers would be an example of an insane decision that would cause just such a degradation. > >> Your belief that the ability of network operators will place a constraint on disaggregation in the transfer market >> presumes a number of facts not in evidence. Namely that: >> + There is some direct correlation between what people will buy and what they can get routed. > > What kind of evidence would satisfy you? The absence of recorded /32 transactions? > Just use common sense, and put yourself in the position of a buyer. > Buyers will believe that they can get /24s routed. However, beyond a relatively small number of additional /24s, this will prove to be impossible to sustain on the internet. I'm not talking about the obvious case of /32s. I'm talking about the fact that this market will force a shortening of acceptable prefixes to prevent collapse. The speed at which that shortening will occur is likely to exceed the speed at which the buyers can adapt. >> + There is some correlation between what engineers can profitably route and what sales people >> will actually sell. > > There is a correlation, because if the sales people continue to sell unprofitably, the company will go out of business. > But there can be a tremendous amount of disruption between event A and event B in your statement above. Also, if that were actually true, some ISPs that are in business today would be long gone. >> + The feedback mechanism on these factors is fast enough that the market can keep pace with >> the effect the market is having on them. > > To keep the market moving at its quickest pace, lower transactional costs like the artificial needs analysis. > Surely having that requirement will slow transactional pace as well as drive transactions off the books. > It may slow the transactional pace, but, I don't believe that is contrary to the goal here. The fast transaction actually makes the problem I am describing worse, not better. If it is slower, the buyer has some time to realize that the routing situation has changed since he began the transaction and adapt his behavior. If the transaction closes quickly and the routing environment changes between the time that he made his purchase and the time he can get it routed, he may have just purchased an entirely worthless block of addresses with no recourse. As to driving transactions off the books, I think that the risks associated with an off-the-books transaction are higher than most organizations will find acceptable. I think that ARIN can take steps to make them riskier still (and probably should). >> + There actually is a feedback mechanism by which the market and disaggregation will regulate >> each other to some livable equilibrium. > > The feedback mechanism is price. The network operators will effectively set the floor for size. > The price will reflect the netblock's routability. > You have not yet built the case that this feedback will actually be effective at protecting the buyer's interests. The operators may have to change the floor size faster than the market will change price, or, at the very least there will be some lag between the two. What happens to purchasers caught in that lag? >> In order to believe that this is not an issue, I think you would have to demonstrate that each of those >> assertions has at least a reasonable chance of being correct. > >>> And as far as 3, I have argued that speculators provide a value to free markets, that most attempts to corner markets fail, that supply uncertainty and IPv6 deployment provide a poor environment for speculators. But inasmuch as this forum is populated by technical types who are making decisions here based >>on their understanding of, and philosophy of, economics, I have decided to take David Farmer's advice and add an anti-speculator, anti-hoarder protection in the form of a limit of a /12 equivalent for needs-free transfers per 12 month period. If more transfers than that are desired, the recipient will have to >>demonstrate need. > >> Actually many attempts to corner markets in the case of a truly finite market with players that have effectively unlimited >> resources _AND_ motivations other than direct profit from the value of the market commodity succeed. > > Could I get some examples from the many you allude to? > Tulips Enron (Natural Gas) http://blog.uncommonwisdomdaily.com/cornering-the-copper-market-5802 (current price of copper) http://www.indexmundi.com/commodities/?commodity=cocoa-beans The spike Jan-Mar 2011 appears to be the result of a 2010 market cornering move by a British gentleman and his hedge fund. Worldcom (alternate fiber suppliers through much of the 1990s). I'm sure there are more. >> While attempts to corner relatively large, and especially dynamically elastic markets (such as finished goods) by relatively small (value >> of player as compared to overall value of market) players are, in fact, doomed, that is not an accurate description >> of the likely IPv4 address market. > > I have already pointed out the obvious risk that CGN has for anybody who tries to corner the market. And I have trouble taking that seriously as LSN is just not a technology that will suit the majority of providers or consumers well at all. > There is also the very obvious risk that IPv6 will finally take off. This will happen regardless of the IPv4 market's behavior. However, that does not prevent extreme short term disruption by the IPv4 market. > And when there is an alternative, the very action of the cornerers drives the market to that alternative, posing additional risks to these speculators. Those alternatives will take time to be implemented and become truly viable alternatives. IPv6, especially cannot be a unilateral alternative and requires implementation by at least three distinct groups to reach viability. (consumers and their hardware, ISPs, and content providers). > As to the smallness of the market, we are in fact talking about a trillion dollar network running on a pool of 3.8 billion address units worth at least $40 billion right now. So? In units of 256 addresses, that's only less than 16.7 million salable unites in the entire market. (or did you forget that you can't sell /32s?). Any market with a total of 16.7 million units defining the market is pretty small by almost any definition. > An international commodities market consisting of fungible, valuable, and transportable assets is in the offing. Hardly. > The supply source of unknown depth and availabilty, although we know the total upper bound of the market. The realistic upper bound is somewhere in the neighborhood of about 12 /8s, probably quite a bit less. That's a total market size of 786,432 /24s. Seems pretty small to me. > And of course, no evidence of this activity that you can point to in the nascent APNIC marketplace as evidenced by tradeipv4.com. > The APNIC marketplace hasn't started in earnest. Most providers haven't even gotten their final /22 from APNIC yet. Using that as an example at this time is absurd at best. >> >>> As a whole, then, my policy seeks to recognize that there are transfer transactions which provide incentives for buyers and sellers of addresses but which transactions may not meed the needs requirements which ARIN mandates for transfers. > >> There are thefts of automobiles which meet the needs of car thieves and the resellers who purchase the stolen >> cars from them. That does not make the legalization of car theft attractive. > > Geez, maybe you should have used kidnappers of children and the child-sex rings who purchase them! An equally valid example. > You obviously have an emotional view that transfers of addresses are akin to theft from the rightful owner, ARIN. Not at all. However, transfers of addresses absent justified need are akin to theft from the community as a whole. You can call that emotion if you want. I call it stewardship. > In that I think you act more as king than steward. I suspect that is a reflection of your misunderstanding of my viewpoint more than anything else. > At least in terms of legacy space, the holders of address rights *predate* ARIN, and yet in your mind, if they transfer them without telling ARIN, they are thieves and hijackers. > The holders of address registrations predate ARIN, but, ARIN is the successor in interest to the original registries that issued them. The resources are and were issued in trust in the community interest to the original resource holder. If a merger or acquisition results in the transfer of the underlying network infrastructure and the addresses go with it, that is a permitted transaction which should be recorded by the current registry. Any other transaction transferring addresses outside of policy is a theft of community resources and the registry has the obligation to reclaim them in the interests of the community. > >>> The question is whether removing the needs basis benefits the ARIN community as a whole, not just the individual participants in any particular >>> transaction. ARIN does not need to make policy to the benefit of individual participants in a transaction. >>> Our role as stewards is to make policy to the benefit of the community as a whole. Individual participants in a >>> transaction are quite capable of looking out for their own immediate interests without involving ARIN policy. > > My rationale is the stewardship of Whois, which benefits the entire Internet community. > Except you have yet to establish any link whatsoever between your policy and any positive effect on whois. >>> Additionally, I pointed out that network operators, in my experience, will route addresses whose Whois record does not reflect that the network operator's customer is the registrant. The network operator, in my experience, will normally check to make sure that nobody else is advertising the addresses, and >>will solicit from the customer some documentary evidence that the customer has the right to the route the addresses, and then the network operator will route the addresses. >> > >> This is not my general experience. Most reputable operators will refuse to route addresses unless they have >> some reason to believe that the customer asking them to route them has some legitimate registration of those >> resources. > > The legitimate reason is the documentary evidence of transfer in the form of a merger, acquisition, asset sale, or Letter of Agency. > I suspect that if the LoA is found to conflict with the whois database, it won't be worth the paper it is printed on. I suspect this will become even more so in the coming years. >> Sure, there are ISPs that specialize in routing hijacked space to the benefit of snowshoe spammers >> and the like, but, they are relatively rare and tend to get de-peered over time. > > And how is a company with a three-year planning window like a snowshoe spammer or hijacker? Huh? > These companies cannot pass the ARIN needs requirements, and would be incentivized to purchase enough addresses on the transfer market. That's true today. However, to protect the community overall, the community has come to agreement on a 1 year planning window for addressing purposes. This provides balance between those with need today and others with need tomorrow. > The seller is incentivized by the money the buyer will pay. Not seeing how this is relevant to the point. > The network operator is incentivized by the money the buyer will pay him, and is satisfied by documentary evidence of the transfer that the buyer has the right to route. Again, I suspect that when it comes down to an issue of that evidence vs. whois, most ISPs will likely go with whois and suggest that the buyer go sort it out with ARIN and come back. > The net result is Whois inaccuracy (and the fact that the buyer will have no RSA with ARIN). > I suspect not as much as you think. > >> I agree that ARIN should get more aggressive about removing registrations for addresses which are no longer >> being held by the original resource holder or its legitimate successor through some form of section 8 transfer. >> ARIN should then reissue those available resources to organizations with documented need in a timely manner. > > This is your stick to my carrot. And wielding that stick can get very expensive for ARIN through legal costs. > And as far as legacy addresses go, ARIN can spend through the nose on lawyers, but my reading of MS/Nortel and the Plzack declaration in the Kremen case leads me to believe that would be money ARIN would waste. > I guess we'll see what happens. Worst case, the market blows out the routing table and we all end up on IPv6 whether the IPv4 stuff is recorded in whois or not. Best case, the market doesn't completely destabilize IPv4 before we get migrated to IPv6 and IPv4 becomes largely irrelevant. I guess either way, this becomes a relatively temporary problem. I suppose since I favor a faster migration to IPv6, I should probably support the greater disruption to IPv4 brought about by your policy, but, in the interests of the community, I just can't bring myself to do so. > >>> The net effect of these types of transactions is a lack of trust in the Whois table as an accurate source to check for authoritative routing rights. My proposal seeks to reduce the harm to Whois accuracy by extending the range of allowable transactions, providing additional incentive to have transfers reflected >>accurately by ARIN's updating of Whois to reflect the transfer. >> > >> There is no evidence whatsoever that this newfound range provides any incentive whatsoever for those >> transactions to be registered. > > Owen, you said a couple of paragraphs ago that network operators would check registration when asked by a customer to route addresses. Yes... Regardless of the range allowed by policy, so long as it remains reasonably sane. > I agree that is the first place they would go, and that is one of the incentives for address transferees to seek registration. Exactly. > The other is the fact that this is really the only public venue for the registration of ownership rights, and I believe registration increases the resale value of the addresses. They are not ownership rights. They are registrations. > I point again to MS/Nortel and the luckiness that MS had a need exactly equal to a previously negotiated sale with Nortel. You call it luck, I call it planning. Why would you purchase an amount different than your need? > Had that need not matched precisely with the addresses allocated to Nortel's acquisitions 20 years ago, what would have happened? The deal would have been modified. > I think we all know what would have happened, and that is that Microsoft would soon be routing those addresses, and Whois would still list Nortel, or even some Nortel acquistion, as the registrant. No, I don't think that would have happened. > This was the spur for my proposal. Had the needs requirement not been in place, the transaction could have flowed through 8.3, and the natural incentives towards registration would have caused Whois to accurately reflect Microsoft as the new registrant. The transaction is flowing through 8.3 and Micr0$0ft will become the new registrant when it is complete. > In addition to this public transaction, I offered some other potential transactions which would also fail the needs test, among which is a buyer with a 2 year planning horizon. Yes, you've offered several instances in which behavior that the community has said is contrary to the interests of the community would be supported by your policy. That does not change the fact that the behavior in question is contrary to the stated interests and intents of the community. > I will continue to use this example, as recent proposals to extend the needs window attest to the belief among some that having a 2 year planning window does not put you in the same league as spammers, speculators, and hijackers. > And I will point out that there is also opposition in the community to those proposals indicating that there is belief among some that having an ability to glom more than a year of address space at a time to the exclusion of others is contrary to the interests of the community. >> Yes, it might actually remove some small amount of disincentive, but, I believe >> it would be better for ARIN to provide incentive for accurate whois through a more active audit and >> reclamation process as that would also better serve the community by reducing the probability of hijacked >> space being invisibly routed as well as making some abandoned resources available to the ARIN community >> for reuse. > > Again with the stick. How successfully as this stick been weilded in the past? > It has not been wielded yet to my knowledge, so, there is not yet a test on its success. > >>> As we move into a trading world, which will happen whether or not my proposal passes, conflicts over address control are likely to increase, and the value of trust in Whois as the routing authority will also increase. Rather than sit back and watch Whois decay, I urge ARIN stewards to consider making these >>changes to foster accuracy in Whois. >> > >> There is no proof these changes will foster accuracy in Whois. > >> Owen > > There is proof that transfers have occurred that have not been reflected in Whois. John mentioned the current 8.2 requests to reflect old mergers and acquisitions. Yes and I fully support ARIN recognizing appropriate transfers before taking action to reclaim or revoke resources by removing their registrations from the database and placing the numbers back into the allocation pool. > So we know that transfers have occurred among the non-reprobate which are not reflected in Whois. And? In most of those cases, they were unaware of ARIN and did not know how to go about registering their transfer. Upon rectification of that ignorance, most complete the transfer without issue. I fail to see how this provides any support for your proposal. > I have pointed out that there is a major change afoot, the development of an ip address transfer market. Yes. I still haven't seen you provide any evidence that said change means we should stop regulating the rate of consumption in the interests of the community as a whole as part of good stewardship. > So looking in the past for proof, or really looking anywhere for proof of results of a change which has not occurred yet, is specious. > At least some supporting evidence that your proposed change would have the results you claim it would have would be useful. So far, there is none. Owen -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike at nationwideinc.com Thu May 19 14:08:15 2011 From: mike at nationwideinc.com (Mike Burns) Date: Thu, 19 May 2011 14:08:15 -0400 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate References: <4DCFDB5C64DD4F738B65AB82D36B629D@mike> <15F92ECD-2BE5-48F2-B65A-9A9D39B98F54@delong.com> <0829B106605C4FE8B189DB2E56C69615@mike> <8FB24038-B813-4DE0-91DD-56EDAD31BC03@delong.com> Message-ID: <36A3A11C7EDF413C9E2EC07FD0C122E0@mike> Hi Owen, I'm top-posting because it's too hard to keep this readable with the black vertical lines on the left side. I guess we can let Geoff Huston speak for himself: http://www.potaroo.net/ispcol/2008-11/transfers.html As to Microsoft planning leading them to purchasing the same exact need as ARIN's particular application of its policies at the time of the transaction? Please. Remember that Microsoft was an arms-length negotiator who was solicited by the address broker in the deal along with 80 other companies. So Microsoft's planning was so excellent that they could find the exact amount of addresses they needed in the form of the very first public sale of legacy addresses ever recorded? That's believable! And their excellent planning staff, whose decision so exactly matched ARIN's ex-post-facto analysis, failed to inform management that they could save $7.5 million by getting them directly from ARIN? "I suppose since I favor a faster migration to IPv6, I should probably support the greater disruption to IPv4 brought about by your policy, but, in the interests of the community, I just can't bring myself to do so." lol. Sounds like you're shirking your longterm stewardship duties there. Regards, Mike ----- Original Message ----- From: Owen DeLong To: Mike Burns Cc: Sweeting, John ; arin-ppml at arin.net Sent: Thursday, May 19, 2011 12:45 PM Subject: Re: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate On May 19, 2011, at 7:59 AM, Mike Burns wrote: Hi Owen, You also left off: 4. It might actually reduce whois accuracy rather than increase it. Why does anybody think that removing the needs requirement for transfers would degrade whois accuracy? Because that is exactly what happened to DNS whois when stewardship was abandoned there in favor of an uncontrolled market. The only support for that contention was the idea that because the needs requirement involved some extra informational flow, the contact information would be more accurate. No, that was ONE element of support and I believe it holds true. I argue that registration will become more and more important, and John Curran indicated there was an uptick in 8.2 Transfers for old M&A activity, which I held to be an indication that holders of addresses find registration valuable, and likely more so as the addresses increase in monetary value. Which would argue that removing needs basis will not improve that situation. People will naturally want their ownership rights established in whatever venue is appropriate, and for ip address holdings, that venue is Whois. I don't think the argument that my proposal will reduce Whois accuracy holds water, is there anybody who wants to continue to make that charge? I will continue to make the charge that it is one possible outcome and just as likely as any claim that your proposal could somehow improve it. 5. Markets without additional controls inevitably lead to manipulation and dysfunction which requires later regulation to correct. These later corrections are rarely (if ever) effective at making the original victims of the manipulations and dysfunction whole. First, this is your opinion only, second, I already alluded to speculators and hoarders, and your number 5 is merely a restatement. Speculators and hoarders are not the only forms of manipulation and dysfunction that tend to occur. Can you cite a single example of a long-term market that was unregulated and did not devolve as I describe? I believe that this is a statement of fact over the entire history of markets rather than merely my opinion. As far as 2, this danger seems to be manageable, and there haven't been too many objections related to this lately. I have argued that the stewards of the APNIC region, led by Geoff Huston, considered this problem when deciding whether to have needs requirements on transfers, and decided the benefits to >>Whois accuracy outweighed the potential disaggregation problems. This cost is borne most by network operators, who presumably can make decisions on minimum block size which will allow them to run profitably. Those decisions will likely shape the transfer market, so nobody expects there to be much >>value in a /32 netblock, because network operators find this size unprofitable to route today. This ability of network operators provides a constraint on disaggregation in the transfer market. People haven't been repeating what they already said. That does not mean that it is not still a factor, merely that we didn't think we needed to repeat ourselves on a topic already covered. In what way do you believe this danger would be manageable and/or managed under the proposed policy? Primarily, I associate my decision with Geoff Huston's decision at APNIC. OK... Geoff is one of the world's top experts on BGP, I think it fair to say, and yet he viewed the danger to Whois accuracy in maintaining needs as outweighing the danger of disaggregation. Geoff's statements were actually more along the lines of what's about to happen with BGP will happen whether we register it in whois or not and he did not believe that efforts at stewardship on the part of the RIRs could prevent it, so, he thought it was better for the RIRs to attempt to accurately record the disaster than try to prevent it. I am not as fatalistic as Geoff and I think that in general, the ARIN community is less fatalistic than the APNIC community. As such, I think there is value in attempting to prevent the disaster rather than merely standing in front of the damn throwing my hands up in the air and writing down the precise time that it bursts before I am overwhelmed with water (which is basically Geoff's approach). Secondarily, I believe that private network operators are the ultimate decisionmakers here. If they won't route a netblock, the value of the netblock is reduced significantly. Of course they are. I believe that private network operators will see value in RIR stewardship of the resources and will look to the RIRs for guidance on what should or shouldn't get routed. If the RIRs make insane decisions, the value of the RIR data for that purpose will be degraded. Allowing a free-for-all in transfers would be an example of an insane decision that would cause just such a degradation. Your belief that the ability of network operators will place a constraint on disaggregation in the transfer market presumes a number of facts not in evidence. Namely that: + There is some direct correlation between what people will buy and what they can get routed. What kind of evidence would satisfy you? The absence of recorded /32 transactions? Just use common sense, and put yourself in the position of a buyer. Buyers will believe that they can get /24s routed. However, beyond a relatively small number of additional /24s, this will prove to be impossible to sustain on the internet. I'm not talking about the obvious case of /32s. I'm talking about the fact that this market will force a shortening of acceptable prefixes to prevent collapse. The speed at which that shortening will occur is likely to exceed the speed at which the buyers can adapt. + There is some correlation between what engineers can profitably route and what sales people will actually sell. There is a correlation, because if the sales people continue to sell unprofitably, the company will go out of business. But there can be a tremendous amount of disruption between event A and event B in your statement above. Also, if that were actually true, some ISPs that are in business today would be long gone. + The feedback mechanism on these factors is fast enough that the market can keep pace with the effect the market is having on them. To keep the market moving at its quickest pace, lower transactional costs like the artificial needs analysis. Surely having that requirement will slow transactional pace as well as drive transactions off the books. It may slow the transactional pace, but, I don't believe that is contrary to the goal here. The fast transaction actually makes the problem I am describing worse, not better. If it is slower, the buyer has some time to realize that the routing situation has changed since he began the transaction and adapt his behavior. If the transaction closes quickly and the routing environment changes between the time that he made his purchase and the time he can get it routed, he may have just purchased an entirely worthless block of addresses with no recourse. As to driving transactions off the books, I think that the risks associated with an off-the-books transaction are higher than most organizations will find acceptable. I think that ARIN can take steps to make them riskier still (and probably should). + There actually is a feedback mechanism by which the market and disaggregation will regulate each other to some livable equilibrium. The feedback mechanism is price. The network operators will effectively set the floor for size. The price will reflect the netblock's routability. You have not yet built the case that this feedback will actually be effective at protecting the buyer's interests. The operators may have to change the floor size faster than the market will change price, or, at the very least there will be some lag between the two. What happens to purchasers caught in that lag? In order to believe that this is not an issue, I think you would have to demonstrate that each of those assertions has at least a reasonable chance of being correct. And as far as 3, I have argued that speculators provide a value to free markets, that most attempts to corner markets fail, that supply uncertainty and IPv6 deployment provide a poor environment for speculators. But inasmuch as this forum is populated by technical types who are making decisions here based >>on their understanding of, and philosophy of, economics, I have decided to take David Farmer's advice and add an anti-speculator, anti-hoarder protection in the form of a limit of a /12 equivalent for needs-free transfers per 12 month period. If more transfers than that are desired, the recipient will have to >>demonstrate need. Actually many attempts to corner markets in the case of a truly finite market with players that have effectively unlimited resources _AND_ motivations other than direct profit from the value of the market commodity succeed. Could I get some examples from the many you allude to? Tulips Enron (Natural Gas) http://blog.uncommonwisdomdaily.com/cornering-the-copper-market-5802 (current price of copper) http://www.indexmundi.com/commodities/?commodity=cocoa-beans The spike Jan-Mar 2011 appears to be the result of a 2010 market cornering move by a British gentleman and his hedge fund. Worldcom (alternate fiber suppliers through much of the 1990s). I'm sure there are more. While attempts to corner relatively large, and especially dynamically elastic markets (such as finished goods) by relatively small (value of player as compared to overall value of market) players are, in fact, doomed, that is not an accurate description of the likely IPv4 address market. I have already pointed out the obvious risk that CGN has for anybody who tries to corner the market. And I have trouble taking that seriously as LSN is just not a technology that will suit the majority of providers or consumers well at all. There is also the very obvious risk that IPv6 will finally take off. This will happen regardless of the IPv4 market's behavior. However, that does not prevent extreme short term disruption by the IPv4 market. And when there is an alternative, the very action of the cornerers drives the market to that alternative, posing additional risks to these speculators. Those alternatives will take time to be implemented and become truly viable alternatives. IPv6, especially cannot be a unilateral alternative and requires implementation by at least three distinct groups to reach viability. (consumers and their hardware, ISPs, and content providers). As to the smallness of the market, we are in fact talking about a trillion dollar network running on a pool of 3.8 billion address units worth at least $40 billion right now. So? In units of 256 addresses, that's only less than 16.7 million salable unites in the entire market. (or did you forget that you can't sell /32s?). Any market with a total of 16.7 million units defining the market is pretty small by almost any definition. An international commodities market consisting of fungible, valuable, and transportable assets is in the offing. Hardly. The supply source of unknown depth and availabilty, although we know the total upper bound of the market. The realistic upper bound is somewhere in the neighborhood of about 12 /8s, probably quite a bit less. That's a total market size of 786,432 /24s. Seems pretty small to me. And of course, no evidence of this activity that you can point to in the nascent APNIC marketplace as evidenced by tradeipv4.com. The APNIC marketplace hasn't started in earnest. Most providers haven't even gotten their final /22 from APNIC yet. Using that as an example at this time is absurd at best. As a whole, then, my policy seeks to recognize that there are transfer transactions which provide incentives for buyers and sellers of addresses but which transactions may not meed the needs requirements which ARIN mandates for transfers. There are thefts of automobiles which meet the needs of car thieves and the resellers who purchase the stolen cars from them. That does not make the legalization of car theft attractive. Geez, maybe you should have used kidnappers of children and the child-sex rings who purchase them! An equally valid example. You obviously have an emotional view that transfers of addresses are akin to theft from the rightful owner, ARIN. Not at all. However, transfers of addresses absent justified need are akin to theft from the community as a whole. You can call that emotion if you want. I call it stewardship. In that I think you act more as king than steward. I suspect that is a reflection of your misunderstanding of my viewpoint more than anything else. At least in terms of legacy space, the holders of address rights *predate* ARIN, and yet in your mind, if they transfer them without telling ARIN, they are thieves and hijackers. The holders of address registrations predate ARIN, but, ARIN is the successor in interest to the original registries that issued them. The resources are and were issued in trust in the community interest to the original resource holder. If a merger or acquisition results in the transfer of the underlying network infrastructure and the addresses go with it, that is a permitted transaction which should be recorded by the current registry. Any other transaction transferring addresses outside of policy is a theft of community resources and the registry has the obligation to reclaim them in the interests of the community. The question is whether removing the needs basis benefits the ARIN community as a whole, not just the individual participants in any particular transaction. ARIN does not need to make policy to the benefit of individual participants in a transaction. Our role as stewards is to make policy to the benefit of the community as a whole. Individual participants in a transaction are quite capable of looking out for their own immediate interests without involving ARIN policy. My rationale is the stewardship of Whois, which benefits the entire Internet community. Except you have yet to establish any link whatsoever between your policy and any positive effect on whois. Additionally, I pointed out that network operators, in my experience, will route addresses whose Whois record does not reflect that the network operator's customer is the registrant. The network operator, in my experience, will normally check to make sure that nobody else is advertising the addresses, and >>will solicit from the customer some documentary evidence that the customer has the right to the route the addresses, and then the network operator will route the addresses. This is not my general experience. Most reputable operators will refuse to route addresses unless they have some reason to believe that the customer asking them to route them has some legitimate registration of those resources. The legitimate reason is the documentary evidence of transfer in the form of a merger, acquisition, asset sale, or Letter of Agency. I suspect that if the LoA is found to conflict with the whois database, it won't be worth the paper it is printed on. I suspect this will become even more so in the coming years. Sure, there are ISPs that specialize in routing hijacked space to the benefit of snowshoe spammers and the like, but, they are relatively rare and tend to get de-peered over time. And how is a company with a three-year planning window like a snowshoe spammer or hijacker? Huh? These companies cannot pass the ARIN needs requirements, and would be incentivized to purchase enough addresses on the transfer market. That's true today. However, to protect the community overall, the community has come to agreement on a 1 year planning window for addressing purposes. This provides balance between those with need today and others with need tomorrow. The seller is incentivized by the money the buyer will pay. Not seeing how this is relevant to the point. The network operator is incentivized by the money the buyer will pay him, and is satisfied by documentary evidence of the transfer that the buyer has the right to route. Again, I suspect that when it comes down to an issue of that evidence vs. whois, most ISPs will likely go with whois and suggest that the buyer go sort it out with ARIN and come back. The net result is Whois inaccuracy (and the fact that the buyer will have no RSA with ARIN). I suspect not as much as you think. I agree that ARIN should get more aggressive about removing registrations for addresses which are no longer being held by the original resource holder or its legitimate successor through some form of section 8 transfer. ARIN should then reissue those available resources to organizations with documented need in a timely manner. This is your stick to my carrot. And wielding that stick can get very expensive for ARIN through legal costs. And as far as legacy addresses go, ARIN can spend through the nose on lawyers, but my reading of MS/Nortel and the Plzack declaration in the Kremen case leads me to believe that would be money ARIN would waste. I guess we'll see what happens. Worst case, the market blows out the routing table and we all end up on IPv6 whether the IPv4 stuff is recorded in whois or not. Best case, the market doesn't completely destabilize IPv4 before we get migrated to IPv6 and IPv4 becomes largely irrelevant. I guess either way, this becomes a relatively temporary problem. I suppose since I favor a faster migration to IPv6, I should probably support the greater disruption to IPv4 brought about by your policy, but, in the interests of the community, I just can't bring myself to do so. The net effect of these types of transactions is a lack of trust in the Whois table as an accurate source to check for authoritative routing rights. My proposal seeks to reduce the harm to Whois accuracy by extending the range of allowable transactions, providing additional incentive to have transfers reflected >>accurately by ARIN's updating of Whois to reflect the transfer. There is no evidence whatsoever that this newfound range provides any incentive whatsoever for those transactions to be registered. Owen, you said a couple of paragraphs ago that network operators would check registration when asked by a customer to route addresses. Yes... Regardless of the range allowed by policy, so long as it remains reasonably sane. I agree that is the first place they would go, and that is one of the incentives for address transferees to seek registration. Exactly. The other is the fact that this is really the only public venue for the registration of ownership rights, and I believe registration increases the resale value of the addresses. They are not ownership rights. They are registrations. I point again to MS/Nortel and the luckiness that MS had a need exactly equal to a previously negotiated sale with Nortel. You call it luck, I call it planning. Why would you purchase an amount different than your need? Had that need not matched precisely with the addresses allocated to Nortel's acquisitions 20 years ago, what would have happened? The deal would have been modified. I think we all know what would have happened, and that is that Microsoft would soon be routing those addresses, and Whois would still list Nortel, or even some Nortel acquistion, as the registrant. No, I don't think that would have happened. This was the spur for my proposal. Had the needs requirement not been in place, the transaction could have flowed through 8.3, and the natural incentives towards registration would have caused Whois to accurately reflect Microsoft as the new registrant. The transaction is flowing through 8.3 and Micr0$0ft will become the new registrant when it is complete. In addition to this public transaction, I offered some other potential transactions which would also fail the needs test, among which is a buyer with a 2 year planning horizon. Yes, you've offered several instances in which behavior that the community has said is contrary to the interests of the community would be supported by your policy. That does not change the fact that the behavior in question is contrary to the stated interests and intents of the community. I will continue to use this example, as recent proposals to extend the needs window attest to the belief among some that having a 2 year planning window does not put you in the same league as spammers, speculators, and hijackers. And I will point out that there is also opposition in the community to those proposals indicating that there is belief among some that having an ability to glom more than a year of address space at a time to the exclusion of others is contrary to the interests of the community. Yes, it might actually remove some small amount of disincentive, but, I believe it would be better for ARIN to provide incentive for accurate whois through a more active audit and reclamation process as that would also better serve the community by reducing the probability of hijacked space being invisibly routed as well as making some abandoned resources available to the ARIN community for reuse. Again with the stick. How successfully as this stick been weilded in the past? It has not been wielded yet to my knowledge, so, there is not yet a test on its success. As we move into a trading world, which will happen whether or not my proposal passes, conflicts over address control are likely to increase, and the value of trust in Whois as the routing authority will also increase. Rather than sit back and watch Whois decay, I urge ARIN stewards to consider making these >>changes to foster accuracy in Whois. There is no proof these changes will foster accuracy in Whois. Owen There is proof that transfers have occurred that have not been reflected in Whois. John mentioned the current 8.2 requests to reflect old mergers and acquisitions. Yes and I fully support ARIN recognizing appropriate transfers before taking action to reclaim or revoke resources by removing their registrations from the database and placing the numbers back into the allocation pool. So we know that transfers have occurred among the non-reprobate which are not reflected in Whois. And? In most of those cases, they were unaware of ARIN and did not know how to go about registering their transfer. Upon rectification of that ignorance, most complete the transfer without issue. I fail to see how this provides any support for your proposal. I have pointed out that there is a major change afoot, the development of an ip address transfer market. Yes. I still haven't seen you provide any evidence that said change means we should stop regulating the rate of consumption in the interests of the community as a whole as part of good stewardship. So looking in the past for proof, or really looking anywhere for proof of results of a change which has not occurred yet, is specious. At least some supporting evidence that your proposed change would have the results you claim it would have would be useful. So far, there is none. Owen -------------- next part -------------- An HTML attachment was scrubbed... URL: From ikiris at gmail.com Thu May 19 14:34:19 2011 From: ikiris at gmail.com (Blake Dunlap) Date: Thu, 19 May 2011 13:34:19 -0500 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate In-Reply-To: <36A3A11C7EDF413C9E2EC07FD0C122E0@mike> References: <4DCFDB5C64DD4F738B65AB82D36B629D@mike> <15F92ECD-2BE5-48F2-B65A-9A9D39B98F54@delong.com> <0829B106605C4FE8B189DB2E56C69615@mike> <8FB24038-B813-4DE0-91DD-56EDAD31BC03@delong.com> <36A3A11C7EDF413C9E2EC07FD0C122E0@mike> Message-ID: On Thu, May 19, 2011 at 13:08, Mike Burns wrote: > Hi Owen, > > I'm top-posting because it's too hard to keep this readable with the black > vertical lines on the left side. > > I guess we can let Geoff Huston speak for himself: > http://www.potaroo.net/ispcol/2008-11/transfers.html > > As to Microsoft planning leading them to purchasing the same exact need as > ARIN's particular application of its policies at the time of the > transaction? > Please. > Remember that Microsoft was an arms-length negotiator who was solicited by > the address broker in the deal along with 80 other companies. > So Microsoft's planning was so excellent that they could find the exact > amount of addresses they needed in the form of the very first public sale of > legacy addresses ever recorded? > That's believable! > And their excellent planning staff, whose decision so exactly matched > ARIN's ex-post-facto analysis, failed to inform management that they could > save $7.5 million by getting them directly from ARIN? > > "I suppose since I favor a faster migration to IPv6, I should probably > support the greater disruption to IPv4 brought about by your policy, but, > in the interests of the community, I just can't bring myself to do so." > > lol. Sounds like you're shirking your longterm stewardship duties there. > > Regards, > Mike > > You were much more persuasive before you started resorting to personal attacks. I even agree with your goal somewhat, just not the current plan for getting there, or many of your justifications for such. You will have much better luck actually listening to others and working with them, instead of just yelling louder and slinging mud. As stated however, I strongly agree with Owen that this current policy is a nightmare for the community as written. -Blake -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike at nationwideinc.com Thu May 19 14:44:04 2011 From: mike at nationwideinc.com (Mike Burns) Date: Thu, 19 May 2011 14:44:04 -0400 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate References: <4DCFDB5C64DD4F738B65AB82D36B629D@mike><15F92ECD-2BE5-48F2-B65A-9A9D39B98F5 4@delong.com><0829B106605C4FE8B189DB2E56C69615@mike><8FB24038-B813-4DE0-91DD-56EDAD31BC03@delong.com><36A3A11C7EDF413C9E2EC07FD 0C122E0@mike> Message-ID: <8F23AB4955E3404393B1E03831C91054@mike> Blake, How many times have I been accused of shirking stewardship, or abandoning it? I have asked that posters refrain from that flammable language, but yet it persists. There was also Owen's point about not making policy for personal reasons, only for the good of the community. I read that as an elliptical personal attack, and consistent with his attempt to paint me as a poor steward and as somebody who is trying to make policy for selfish and not community reasons. Nonetheless, I see your point and apologize for my personal attacks and resolve to end them and not try to yell louder and sling mud. Regards, Mike ----- Original Message ----- From: Blake Dunlap To: arin-ppml at arin.net Sent: Thursday, May 19, 2011 2:34 PM Subject: Re: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate On Thu, May 19, 2011 at 13:08, Mike Burns wrote: Hi Owen, I'm top-posting because it's too hard to keep this readable with the black vertical lines on the left side. I guess we can let Geoff Huston speak for himself: http://www.potaroo.net/ispcol/2008-11/transfers.html As to Microsoft planning leading them to purchasing the same exact need as ARIN's particular application of its policies at the time of the transaction? Please. Remember that Microsoft was an arms-length negotiator who was solicited by the address broker in the deal along with 80 other companies. So Microsoft's planning was so excellent that they could find the exact amount of addresses they needed in the form of the very first public sale of legacy addresses ever recorded? That's believable! And their excellent planning staff, whose decision so exactly matched ARIN's ex-post-facto analysis, failed to inform management that they could save $7.5 million by getting them directly from ARIN? "I suppose since I favor a faster migration to IPv6, I should probably support the greater disruption to IPv4 brought about by your policy, but, in the interests of the community, I just can't bring myself to do so." lol. Sounds like you're shirking your longterm stewardship duties there. Regards, Mike You were much more persuasive before you started resorting to personal attacks. I even agree with your goal somewhat, just not the current plan for getting there, or many of your justifications for such. You will have much better luck actually listening to others and working with them, instead of just yelling louder and slinging mud. As stated however, I strongly agree with Owen that this current policy is a nightmare for the community as written. -Blake ------------------------------------------------------------------------------ _______________________________________________ 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 ikiris at gmail.com Thu May 19 15:00:30 2011 From: ikiris at gmail.com (Blake Dunlap) Date: Thu, 19 May 2011 14:00:30 -0500 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate In-Reply-To: <8F23AB4955E3404393B1E03831C91054@mike> References: <4DCFDB5C64DD4F738B65AB82D36B629D@mike> <0829B106605C4FE8B189DB2E56C69615@mike> <8FB24038-B813-4DE0-91DD-56EDAD31BC03@delong.com> <8F23AB4955E3404393B1E03831C91054@mike> Message-ID: On Thu, May 19, 2011 at 13:44, Mike Burns wrote: > Blake, > > How many times have I been accused of shirking stewardship, or abandoning > it? > I have asked that posters refrain from that flammable language, but yet it > persists. > Personally I see your proposal as doing the same harm most of the other opposition does. That doesn't mean it is a personal attack against you, or that I at least believe it is even your intent. > There was also Owen's point about not making policy for personal reasons, > only for the good of the community. > I read that as an elliptical personal attack, and consistent with his > attempt to paint me as a poor steward and as somebody who is trying to make > policy for selfish and not community reasons. > I cannot comment on Owen's reasons, as they are his own, and not available to me, but I believe you may be reading into this a bit much, and projecting his (and others including my own) criticism of your policy as personal criticism against you, and responding as such. I have not seen anything so far that stands out to me as personal attacks against you from the responses so far, except in retaliation, and even then, it was fairly muted. I could be mistaken of course. Note, I say attacks against you, and not your proposal, as those have gotten fairly intense, as the conversation has gone by. -Blake -------------- next part -------------- An HTML attachment was scrubbed... URL: From owen at delong.com Thu May 19 14:57:24 2011 From: owen at delong.com (Owen DeLong) Date: Thu, 19 May 2011 11:57:24 -0700 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate In-Reply-To: <36A3A11C7EDF413C9E2EC07FD0C122E0@mike> References: <4DCFDB5C64DD4F738B65AB82D36B629D@mike> <15F92ECD-2BE5-48F2-B65A-9A9D39B98F54@delong.com> <0829B106605C4FE8B189DB2E56C69615@mike> <8FB24038-B813-4DE0-91DD-56EDAD31BC03@delong.com> <36A3A11C7EDF413C9E2EC07FD0C122E0@mike> Message-ID: On May 19, 2011, at 11:08 AM, Mike Burns wrote: > Hi Owen, > > I'm top-posting because it's too hard to keep this readable with the black vertical lines on the left side. > > I guess we can let Geoff Huston speak for himself: > http://www.potaroo.net/ispcol/2008-11/transfers.html > Look at the ARIN policy proposals listed in that document and you will see that it was written WAY before anything was actually enacted. It does not even reference the policy that ARIN adopted (2009-1) though 2008-6 was admittedly somewhat close to 2009-1. > As to Microsoft planning leading them to purchasing the same exact need as ARIN's particular application of its policies at the time of the transaction? > Please. > Remember that Microsoft was an arms-length negotiator who was solicited by the address broker in the deal along with 80 other companies. So what? I have no reason to believe that Micr0$0ft would have agreed to purchase addresses that they did not need. > So Microsoft's planning was so excellent that they could find the exact amount of addresses they needed in the form of the very first public sale of legacy addresses ever recorded? > That's believable! > And their excellent planning staff, whose decision so exactly matched ARIN's ex-post-facto analysis, failed to inform management that they could save $7.5 million by getting them directly from ARIN? I suspect that Micr0$0ft saw some expected benefit from being able to keep the exact numbers somewhat secret and having an LRSA instead of an RSA. Apparently they were willing to pay $7.5 million for it. Of course, another possibility is that they didn't actually pay $7.5M, but, rather forgave $7.5M in debt owed by Nortel as part of the bankruptcy. > > "I suppose since I favor a faster migration to IPv6, I should probably support the greater disruption to IPv4 brought about by your policy, but, in the interests of the community, I just can't bring myself to do so." > > lol. Sounds like you're shirking your longterm stewardship duties there. No, I believe that my stewardship duties are to work to manage the address space in the least disruptive manner most beneficial to the community at large. My personal opinion in favor of faster IPv6 migration is not particularly relevant to my stewardship duties. As such, I just can't bring myself to shirk my stewardship duties as you request. Owen > > Regards, > Mike > > > > > > > > > > ----- Original Message ----- > From: Owen DeLong > To: Mike Burns > Cc: Sweeting, John ; arin-ppml at arin.net > Sent: Thursday, May 19, 2011 12:45 PM > Subject: Re: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate > > > On May 19, 2011, at 7:59 AM, Mike Burns wrote: > >> Hi Owen, >> >>> You also left off: >> >>> 4. It might actually reduce whois accuracy rather than increase it. >> >> Why does anybody think that removing the needs requirement for transfers would degrade whois accuracy? > > Because that is exactly what happened to DNS whois when stewardship was abandoned there in favor > of an uncontrolled market. > >> The only support for that contention was the idea that because the needs requirement involved some extra informational flow, the contact information would be more accurate. > > No, that was ONE element of support and I believe it holds true. > >> I argue that registration will become more and more important, and John Curran indicated there was an uptick in 8.2 Transfers for old M&A activity, which I held to be an indication that holders of addresses find registration valuable, and likely more so as the addresses increase in monetary value. > > Which would argue that removing needs basis will not improve that situation. > >> People will naturally want their ownership rights established in whatever venue is appropriate, and for ip address holdings, that venue is Whois. >> I don't think the argument that my proposal will reduce Whois accuracy holds water, is there anybody who wants to continue to make that charge? >> > > I will continue to make the charge that it is one possible outcome and just as likely as any claim that your proposal could somehow > improve it. > >> >>> 5. Markets without additional controls inevitably lead to manipulation and dysfunction >>> which requires later regulation to correct. These later corrections are rarely (if ever) >>> effective at making the original victims of the manipulations and dysfunction whole. >> >> First, this is your opinion only, second, I already alluded to speculators and hoarders, and your number 5 is merely a restatement. >> > > Speculators and hoarders are not the only forms of manipulation and dysfunction that > tend to occur. Can you cite a single example of a long-term market that was unregulated > and did not devolve as I describe? I believe that this is a statement of fact over the > entire history of markets rather than merely my opinion. > >> >>>> As far as 2, this danger seems to be manageable, and there haven't been too many objections related to this lately. I have argued that the stewards of the APNIC region, led by Geoff Huston, considered this problem when deciding whether to have needs requirements on transfers, and decided the benefits to >>Whois accuracy outweighed the potential disaggregation problems. This cost is borne most by network operators, who presumably can make decisions on minimum block size which will allow them to run profitably. Those decisions will likely shape the transfer market, so nobody expects there to be much >>value in a /32 netblock, because network operators find this size unprofitable to route today. This ability of network operators provides a constraint on disaggregation in the transfer market. >>> >> >>> People haven't been repeating what they already said. That does not mean that it is not still a factor, merely that we didn't >>> think we needed to repeat ourselves on a topic already covered. >> >>> In what way do you believe this danger would be manageable and/or managed under the proposed policy? >> >> Primarily, I associate my decision with Geoff Huston's decision at APNIC. > > OK... > >> Geoff is one of the world's top experts on BGP, I think it fair to say, and yet he viewed the danger to Whois accuracy in maintaining needs as outweighing the danger of disaggregation. > > Geoff's statements were actually more along the lines of what's about to happen with BGP will happen whether we register it in whois or not and > he did not believe that efforts at stewardship on the part of the RIRs could prevent it, so, he thought it was better for the RIRs to attempt to > accurately record the disaster than try to prevent it. > > I am not as fatalistic as Geoff and I think that in general, the ARIN community is less fatalistic than the APNIC community. As such, I think there > is value in attempting to prevent the disaster rather than merely standing in front of the damn throwing my hands up in the air and writing down > the precise time that it bursts before I am overwhelmed with water (which is basically Geoff's approach). > >> Secondarily, I believe that private network operators are the ultimate decisionmakers here. If they won't route a netblock, the value of the netblock is reduced significantly. >> > > Of course they are. I believe that private network operators will see value in RIR stewardship of the resources > and will look to the RIRs for guidance on what should or shouldn't get routed. If the RIRs make insane decisions, > the value of the RIR data for that purpose will be degraded. Allowing a free-for-all in transfers would be an example > of an insane decision that would cause just such a degradation. > >> >>> Your belief that the ability of network operators will place a constraint on disaggregation in the transfer market >>> presumes a number of facts not in evidence. Namely that: >>> + There is some direct correlation between what people will buy and what they can get routed. >> >> What kind of evidence would satisfy you? The absence of recorded /32 transactions? >> Just use common sense, and put yourself in the position of a buyer. >> > > Buyers will believe that they can get /24s routed. However, beyond a relatively small number of > additional /24s, this will prove to be impossible to sustain on the internet. > > I'm not talking about the obvious case of /32s. I'm talking about the fact that this market will force > a shortening of acceptable prefixes to prevent collapse. The speed at which that shortening will > occur is likely to exceed the speed at which the buyers can adapt. > >>> + There is some correlation between what engineers can profitably route and what sales people >>> will actually sell. >> >> There is a correlation, because if the sales people continue to sell unprofitably, the company will go out of business. >> > > But there can be a tremendous amount of disruption between event A and event B in your statement > above. Also, if that were actually true, some ISPs that are in business today would be long gone. > >>> + The feedback mechanism on these factors is fast enough that the market can keep pace with >>> the effect the market is having on them. >> >> To keep the market moving at its quickest pace, lower transactional costs like the artificial needs analysis. >> Surely having that requirement will slow transactional pace as well as drive transactions off the books. >> > > It may slow the transactional pace, but, I don't believe that is contrary to the goal here. The fast transaction > actually makes the problem I am describing worse, not better. If it is slower, the buyer has some time > to realize that the routing situation has changed since he began the transaction and adapt his > behavior. If the transaction closes quickly and the routing environment changes between the time > that he made his purchase and the time he can get it routed, he may have just purchased an > entirely worthless block of addresses with no recourse. > > As to driving transactions off the books, I think that the risks associated with an off-the-books > transaction are higher than most organizations will find acceptable. I think that ARIN can take > steps to make them riskier still (and probably should). > >>> + There actually is a feedback mechanism by which the market and disaggregation will regulate >>> each other to some livable equilibrium. >> >> The feedback mechanism is price. The network operators will effectively set the floor for size. >> The price will reflect the netblock's routability. >> > > You have not yet built the case that this feedback will actually be effective at protecting the > buyer's interests. The operators may have to change the floor size faster than the market > will change price, or, at the very least there will be some lag between the two. What > happens to purchasers caught in that lag? > >>> In order to believe that this is not an issue, I think you would have to demonstrate that each of those >>> assertions has at least a reasonable chance of being correct. >> >>>> And as far as 3, I have argued that speculators provide a value to free markets, that most attempts to corner markets fail, that supply uncertainty and IPv6 deployment provide a poor environment for speculators. But inasmuch as this forum is populated by technical types who are making decisions here based >>on their understanding of, and philosophy of, economics, I have decided to take David Farmer's advice and add an anti-speculator, anti-hoarder protection in the form of a limit of a /12 equivalent for needs-free transfers per 12 month period. If more transfers than that are desired, the recipient will have to >>demonstrate need. >> >>> Actually many attempts to corner markets in the case of a truly finite market with players that have effectively unlimited >>> resources _AND_ motivations other than direct profit from the value of the market commodity succeed. >> >> Could I get some examples from the many you allude to? >> > > Tulips > > Enron (Natural Gas) > > http://blog.uncommonwisdomdaily.com/cornering-the-copper-market-5802 (current price of copper) > > http://www.indexmundi.com/commodities/?commodity=cocoa-beans > The spike Jan-Mar 2011 appears to be the result of a 2010 market cornering move by a British gentleman and his hedge fund. > > Worldcom (alternate fiber suppliers through much of the 1990s). > > I'm sure there are more. > > >>> While attempts to corner relatively large, and especially dynamically elastic markets (such as finished goods) by relatively small (value >>> of player as compared to overall value of market) players are, in fact, doomed, that is not an accurate description >>> of the likely IPv4 address market. >> >> I have already pointed out the obvious risk that CGN has for anybody who tries to corner the market. > > And I have trouble taking that seriously as LSN is just not a technology that will suit the majority of providers > or consumers well at all. > >> There is also the very obvious risk that IPv6 will finally take off. > > This will happen regardless of the IPv4 market's behavior. However, that does not prevent extreme short term > disruption by the IPv4 market. > >> And when there is an alternative, the very action of the cornerers drives the market to that alternative, posing additional risks to these speculators. > > Those alternatives will take time to be implemented and become truly viable alternatives. IPv6, especially cannot be a unilateral alternative > and requires implementation by at least three distinct groups to reach viability. (consumers and their hardware, ISPs, and content providers). > >> As to the smallness of the market, we are in fact talking about a trillion dollar network running on a pool of 3.8 billion address units worth at least $40 billion right now. > > So? In units of 256 addresses, that's only less than 16.7 million salable unites in the entire market. (or did you forget that you can't sell /32s?). > > Any market with a total of 16.7 million units defining the market is pretty small by almost any definition. > >> An international commodities market consisting of fungible, valuable, and transportable assets is in the offing. > > Hardly. > >> The supply source of unknown depth and availabilty, although we know the total upper bound of the market. > > The realistic upper bound is somewhere in the neighborhood of about 12 /8s, probably quite a bit less. > That's a total market size of 786,432 /24s. Seems pretty small to me. > >> And of course, no evidence of this activity that you can point to in the nascent APNIC marketplace as evidenced by tradeipv4.com. >> > > The APNIC marketplace hasn't started in earnest. Most providers haven't even gotten their final /22 from APNIC yet. > Using that as an example at this time is absurd at best. > >>> >>>> As a whole, then, my policy seeks to recognize that there are transfer transactions which provide incentives for buyers and sellers of addresses but which transactions may not meed the needs requirements which ARIN mandates for transfers. >> >>> There are thefts of automobiles which meet the needs of car thieves and the resellers who purchase the stolen >>> cars from them. That does not make the legalization of car theft attractive. >> >> Geez, maybe you should have used kidnappers of children and the child-sex rings who purchase them! > > An equally valid example. > >> You obviously have an emotional view that transfers of addresses are akin to theft from the rightful owner, ARIN. > > Not at all. However, transfers of addresses absent justified need are akin to theft from the community as a whole. > You can call that emotion if you want. I call it stewardship. > >> In that I think you act more as king than steward. > > I suspect that is a reflection of your misunderstanding of my viewpoint more than anything else. > >> At least in terms of legacy space, the holders of address rights *predate* ARIN, and yet in your mind, if they transfer them without telling ARIN, they are thieves and hijackers. >> > > The holders of address registrations predate ARIN, but, ARIN is the successor in interest to the original registries that > issued them. The resources are and were issued in trust in the community interest to the original resource holder. > If a merger or acquisition results in the transfer of the underlying network infrastructure and the addresses go with > it, that is a permitted transaction which should be recorded by the current registry. Any other transaction transferring > addresses outside of policy is a theft of community resources and the registry has the obligation to reclaim them in > the interests of the community. > >> >>>> The question is whether removing the needs basis benefits the ARIN community as a whole, not just the individual participants in any particular >>>> transaction. ARIN does not need to make policy to the benefit of individual participants in a transaction. >>>> Our role as stewards is to make policy to the benefit of the community as a whole. Individual participants in a >>>> transaction are quite capable of looking out for their own immediate interests without involving ARIN policy. >> >> My rationale is the stewardship of Whois, which benefits the entire Internet community. >> > > Except you have yet to establish any link whatsoever between your policy and any positive effect on whois. > >>>> Additionally, I pointed out that network operators, in my experience, will route addresses whose Whois record does not reflect that the network operator's customer is the registrant. The network operator, in my experience, will normally check to make sure that nobody else is advertising the addresses, and >>will solicit from the customer some documentary evidence that the customer has the right to the route the addresses, and then the network operator will route the addresses. >>> >> >>> This is not my general experience. Most reputable operators will refuse to route addresses unless they have >>> some reason to believe that the customer asking them to route them has some legitimate registration of those >>> resources. >> >> The legitimate reason is the documentary evidence of transfer in the form of a merger, acquisition, asset sale, or Letter of Agency. >> > > I suspect that if the LoA is found to conflict with the whois database, it won't be worth the paper it is printed on. I suspect this > will become even more so in the coming years. > >>> Sure, there are ISPs that specialize in routing hijacked space to the benefit of snowshoe spammers >>> and the like, but, they are relatively rare and tend to get de-peered over time. >> >> And how is a company with a three-year planning window like a snowshoe spammer or hijacker? > > Huh? > >> These companies cannot pass the ARIN needs requirements, and would be incentivized to purchase enough addresses on the transfer market. > > That's true today. However, to protect the community overall, the community has come to agreement on a 1 year planning window for addressing > purposes. This provides balance between those with need today and others with need tomorrow. > >> The seller is incentivized by the money the buyer will pay. > > Not seeing how this is relevant to the point. > >> The network operator is incentivized by the money the buyer will pay him, and is satisfied by documentary evidence of the transfer that the buyer has the right to route. > > Again, I suspect that when it comes down to an issue of that evidence vs. whois, most ISPs will likely go with whois and suggest > that the buyer go sort it out with ARIN and come back. > >> The net result is Whois inaccuracy (and the fact that the buyer will have no RSA with ARIN). >> > > I suspect not as much as you think. > > >> >>> I agree that ARIN should get more aggressive about removing registrations for addresses which are no longer >>> being held by the original resource holder or its legitimate successor through some form of section 8 transfer. >>> ARIN should then reissue those available resources to organizations with documented need in a timely manner. >> >> This is your stick to my carrot. And wielding that stick can get very expensive for ARIN through legal costs. >> And as far as legacy addresses go, ARIN can spend through the nose on lawyers, but my reading of MS/Nortel and the Plzack declaration in the Kremen case leads me to believe that would be money ARIN would waste. >> > > I guess we'll see what happens. Worst case, the market blows out the routing table and we all end up on IPv6 > whether the IPv4 stuff is recorded in whois or not. Best case, the market doesn't completely destabilize IPv4 > before we get migrated to IPv6 and IPv4 becomes largely irrelevant. I guess either way, this becomes a > relatively temporary problem. I suppose since I favor a faster migration to IPv6, I should probably support > the greater disruption to IPv4 brought about by your policy, but, in the interests of the community, I just > can't bring myself to do so. > >> >>>> The net effect of these types of transactions is a lack of trust in the Whois table as an accurate source to check for authoritative routing rights. My proposal seeks to reduce the harm to Whois accuracy by extending the range of allowable transactions, providing additional incentive to have transfers reflected >>accurately by ARIN's updating of Whois to reflect the transfer. >>> >> >>> There is no evidence whatsoever that this newfound range provides any incentive whatsoever for those >>> transactions to be registered. >> >> Owen, you said a couple of paragraphs ago that network operators would check registration when asked by a customer to route addresses. > > Yes... Regardless of the range allowed by policy, so long as it remains reasonably sane. > >> I agree that is the first place they would go, and that is one of the incentives for address transferees to seek registration. > > Exactly. > >> The other is the fact that this is really the only public venue for the registration of ownership rights, and I believe registration increases the resale value of the addresses. > > They are not ownership rights. They are registrations. > >> I point again to MS/Nortel and the luckiness that MS had a need exactly equal to a previously negotiated sale with Nortel. > > You call it luck, I call it planning. Why would you purchase an amount different than your need? > >> Had that need not matched precisely with the addresses allocated to Nortel's acquisitions 20 years ago, what would have happened? > > The deal would have been modified. > >> I think we all know what would have happened, and that is that Microsoft would soon be routing those addresses, and Whois would still list Nortel, or even some Nortel acquistion, as the registrant. > > No, I don't think that would have happened. > >> This was the spur for my proposal. Had the needs requirement not been in place, the transaction could have flowed through 8.3, and the natural incentives towards registration would have caused Whois to accurately reflect Microsoft as the new registrant. > > The transaction is flowing through 8.3 and Micr0$0ft will become the new registrant when it is complete. > >> In addition to this public transaction, I offered some other potential transactions which would also fail the needs test, among which is a buyer with a 2 year planning horizon. > > Yes, you've offered several instances in which behavior that the community has said is contrary to the interests of the > community would be supported by your policy. That does not change the fact that the behavior in question is contrary > to the stated interests and intents of the community. > >> I will continue to use this example, as recent proposals to extend the needs window attest to the belief among some that having a 2 year planning window does not put you in the same league as spammers, speculators, and hijackers. >> > > And I will point out that there is also opposition in the community to those proposals indicating that there is belief among some > that having an ability to glom more than a year of address space at a time to the exclusion of others is contrary to the interests > of the community. > >>> Yes, it might actually remove some small amount of disincentive, but, I believe >>> it would be better for ARIN to provide incentive for accurate whois through a more active audit and >>> reclamation process as that would also better serve the community by reducing the probability of hijacked >>> space being invisibly routed as well as making some abandoned resources available to the ARIN community >>> for reuse. >> >> Again with the stick. How successfully as this stick been weilded in the past? >> > > It has not been wielded yet to my knowledge, so, there is not yet a test on its success. > >> >>>> As we move into a trading world, which will happen whether or not my proposal passes, conflicts over address control are likely to increase, and the value of trust in Whois as the routing authority will also increase. Rather than sit back and watch Whois decay, I urge ARIN stewards to consider making these >>changes to foster accuracy in Whois. >>> >> >>> There is no proof these changes will foster accuracy in Whois. >> >>> Owen >> >> There is proof that transfers have occurred that have not been reflected in Whois. John mentioned the current 8.2 requests to reflect old mergers and acquisitions. > > Yes and I fully support ARIN recognizing appropriate transfers before taking action to reclaim or revoke > resources by removing their registrations from the database and placing the numbers back into the allocation > pool. > >> So we know that transfers have occurred among the non-reprobate which are not reflected in Whois. > > And? In most of those cases, they were unaware of ARIN and did not know how to go about registering > their transfer. Upon rectification of that ignorance, most complete the transfer without issue. I fail to see > how this provides any support for your proposal. > >> I have pointed out that there is a major change afoot, the development of an ip address transfer market. > > Yes. I still haven't seen you provide any evidence that said change means we should stop regulating the > rate of consumption in the interests of the community as a whole as part of good stewardship. > >> So looking in the past for proof, or really looking anywhere for proof of results of a change which has not occurred yet, is specious. >> > > At least some supporting evidence that your proposed change would have the results you claim it > would have would be useful. So far, there is none. > > Owen > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From owen at delong.com Thu May 19 15:05:09 2011 From: owen at delong.com (Owen DeLong) Date: Thu, 19 May 2011 12:05:09 -0700 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate In-Reply-To: <8F23AB4955E3404393B1E03831C91054@mike> References: <4DCFDB5C64DD4F738B65AB82D36B629D@mike><15F92ECD-2BE5-48F2-B65A-9A9D39B98F5 4@delong.com><0829B106605C4FE8B189DB2E56C69615@mike><8FB24038-B813-4DE0-91DD-56EDAD31BC03@delong.com><36A3A11C7EDF413C9E2EC07FD 0C122E0@mike> <8F23AB4955E3404393B1E03831C91054@mike> Message-ID: <6397CBB3-8145-43E7-8288-132F19B89E3F@delong.com> On May 19, 2011, at 11:44 AM, Mike Burns wrote: > Blake, > > How many times have I been accused of shirking stewardship, or abandoning it? > I have asked that posters refrain from that flammable language, but yet it persists. > FWIW, I did not take your post as a personal attack. > There was also Owen's point about not making policy for personal reasons, only for the good of the community. > I read that as an elliptical personal attack, and consistent with his attempt to paint me as a poor steward and as somebody who is trying to make policy for selfish and not community reasons. > It was not intended as such and I apologize if it came across that way. My point is that your policy would serve the interest of a select few well capitalized organizations significantly better than the interests of the overall community. I really haven't intended to paint you as a poor steward, merely to point out that your proposal is a step away from stewardship for the sake of the entire community and towards stewardship that favors the mightiest few among the community as defined by capitalization. > > Nonetheless, I see your point and apologize for my personal attacks and resolve to end them and not try to yell louder and sling mud. > No apology needed as far as I was concerned, but, maybe I'm just too thick-skinned to realize I got attacked. ;-) Owen > Regards, > Mike > > > > > ----- Original Message ----- > From: Blake Dunlap > To: arin-ppml at arin.net > Sent: Thursday, May 19, 2011 2:34 PM > Subject: Re: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate > > > > On Thu, May 19, 2011 at 13:08, Mike Burns wrote: > Hi Owen, > > I'm top-posting because it's too hard to keep this readable with the black vertical lines on the left side. > > I guess we can let Geoff Huston speak for himself: > http://www.potaroo.net/ispcol/2008-11/transfers.html > > As to Microsoft planning leading them to purchasing the same exact need as ARIN's particular application of its policies at the time of the transaction? > Please. > Remember that Microsoft was an arms-length negotiator who was solicited by the address broker in the deal along with 80 other companies. > So Microsoft's planning was so excellent that they could find the exact amount of addresses they needed in the form of the very first public sale of legacy addresses ever recorded? > That's believable! > And their excellent planning staff, whose decision so exactly matched ARIN's ex-post-facto analysis, failed to inform management that they could save $7.5 million by getting them directly from ARIN? > > "I suppose since I favor a faster migration to IPv6, I should probably support the greater disruption to IPv4 brought about by your policy, but, in the interests of the community, I just can't bring myself to do so." > > lol. Sounds like you're shirking your longterm stewardship duties there. > > Regards, > Mike > > > You were much more persuasive before you started resorting to personal attacks. I even agree with your goal somewhat, just not the current plan for getting there, or many of your justifications for such. You will have much better luck actually listening to others and working with them, instead of just yelling louder and slinging mud. > > As stated however, I strongly agree with Owen that this current policy is a nightmare for the community as written. > > -Blake > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthew at matthew.at Thu May 19 15:25:47 2011 From: matthew at matthew.at (Matthew Kaufman) Date: Thu, 19 May 2011 12:25:47 -0700 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate In-Reply-To: <6397CBB3-8145-43E7-8288-132F19B89E3F@delong.com> References: <4DCFDB5C64DD4F738B65AB82D36B629D@mike><15F92ECD-2BE5-48F2-B65A-9A9D39B98F5 4@delong.com><0829B106605C4FE8B189DB2E56C69615@mike><8FB24038-B813-4DE0-91DD-56EDAD31BC03@delong.com><36A3A11C7EDF413C9E2EC07FD 0C122E0@mike> <8F23AB4955E3404393B1E03831C91054@mike> <6397CBB3-8145-43E7-8288-132F19B89E3F@delong.com> Message-ID: <4DD56EBB.70102@matthew.at> On 5/19/2011 12:05 PM, Owen DeLong wrote: > It was not intended as such and I apologize if it came across that > way. My point is that your policy > would serve the interest of a select few well capitalized > organizations significantly better than > the interests of the overall community. If "a select few well capitalized organizations" are going to corner the market on space, doesn't that require them to purchase the maximum amount of space from existing holders at fairly high prices? That might serve the *financial* interests of the overall community better than policies where the number of buyers is limited by needs assessment. It also provides existing holders with more cash to use for their IPv6 deployments. Matthew Kaufman From kkargel at polartel.com Thu May 19 15:41:53 2011 From: kkargel at polartel.com (Kevin Kargel) Date: Thu, 19 May 2011 14:41:53 -0500 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate In-Reply-To: <4DD56EBB.70102@matthew.at> References: <4DCFDB5C64DD4F738B65AB82D36B629D@mike><15F92ECD-2BE5-48F2-B65A-9A9D39B98F5 4@delong.com><0829B106605C4FE8B189DB2E56C69615@mike><8FB24038-B813-4DE0-91DD-56EDAD31BC03@delong.com><36A3A11C7EDF413C9E2EC07FD 0C122E0@mike> <8F23AB4955E3404393B1E03831C91054@mike> <6397CBB3-8145-43E7-8288-132F19B89E3F@delong.com> <4DD56EBB.70102@matthew.at> Message-ID: <8695009A81378E48879980039EEDAD289F033041@MAIL1.polartel.local> > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf Of Matthew Kaufman > Sent: Thursday, May 19, 2011 2:26 PM > To: Owen DeLong > Cc: arin-ppml at arin.net > Subject: Re: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois > Accurate > > On 5/19/2011 12:05 PM, Owen DeLong wrote: > > It was not intended as such and I apologize if it came across that > > way. My point is that your policy > > would serve the interest of a select few well capitalized > > organizations significantly better than > > the interests of the overall community. > > If "a select few well capitalized organizations" are going to corner the > market on space, doesn't that require them to purchase the maximum > amount of space from existing holders at fairly high prices? > > That might serve the *financial* interests of the overall community > better than policies where the number of buyers is limited by needs > assessment. > > It also provides existing holders with more cash to use for their IPv6 > deployments. > > Matthew Kaufman > _______________________________________________ I am a relatively small time operator. It does not benefit me one whit if the big boys buy IP's from the big boys. It might keep me from getting IP's if/when I need them. I am part of the overall community. We are managing policy for the community, not just for the top ten ISP's or for a few traders who want to organize a market to make some quick cash. Let's keep the small business and non-profit orgs in mind. This is not all about the almighty dollar and how to get more of them. Kevin From tvest at eyeconomics.com Thu May 19 16:18:53 2011 From: tvest at eyeconomics.com (Tom Vest) Date: Thu, 19 May 2011 16:18:53 -0400 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate In-Reply-To: <0829B106605C4FE8B189DB2E56C69615@mike> References: <4DCFDB5C64DD4F738B65AB82D36B629D@mike> <15F92ECD-2BE5-48F2-B65A-9A9D39B98F54@delong.com> <0829B106605C4FE8B189DB2E56C69615@mike> Message-ID: <51506A06-D2EE-4A0D-B92B-781662094A1C@eyeconomics.com> On May 19, 2011, at 10:59 AM, Mike Burns wrote: > Hi Owen, > >> You also left off: > >> 4. It might actually reduce whois accuracy rather than increase it. > > Why does anybody think that removing the needs requirement for transfers would degrade whois accuracy? > The only support for that contention was the idea that because the needs requirement involved some extra informational flow, the contact information would be more accurate. > I argue that registration will become more and more important, and John Curran indicated there was an uptick in 8.2 Transfers for old M&A activity, which I held to be an indication that holders of addresses find registration valuable, and likely more so as the addresses increase in monetary value. > People will naturally want their ownership rights established in whatever venue is appropriate, and for ip address holdings, that venue is Whois. > I don't think the argument that my proposal will reduce Whois accuracy holds water, is there anybody who wants to continue to make that charge? Hi Mike, Can you provide us with a comparable measure of the number of old address holders who have not responded to opportunity afforded by the 8.2 change? If possible, please break down the number into two groups -- those who are on the fence and holding out fin hopes of additional blandishments and concessions, and those whose philosophical or commercial priorities preclude registration regardless of the side payments. > 5. Markets without additional controls inevitably lead to manipulation and dysfunction >> which requires later regulation to correct. These later corrections are rarely (if ever) >> effective at making the original victims of the manipulations and dysfunction whole. > > First, this is your opinion only, second, I already alluded to speculators and hoarders, and your number 5 is merely a restatement. > > >>> As far as 2, this danger seems to be manageable, and there haven't been too many objections related to this lately. I have argued that the stewards of the APNIC region, led by Geoff Huston, considered this problem when deciding whether to have needs requirements on transfers, and decided the benefits to >>Whois accuracy outweighed the potential disaggregation problems. This cost is borne most by network operators, who presumably can make decisions on minimum block size which will allow them to run profitably. Those decisions will likely shape the transfer market, so nobody expects there to be much >>value in a /32 netblock, because network operators find this size unprofitable to route today. This ability of network operators provides a constraint on disaggregation in the transfer market. >> > >> People haven't been repeating what they already said. That does not mean that it is not still a factor, merely that we didn't >> think we needed to repeat ourselves on a topic already covered. > >> In what way do you believe this danger would be manageable and/or managed under the proposed policy? > > Primarily, I associate my decision with Geoff Huston's decision at APNIC. > Geoff is one of the world's top experts on BGP, I think it fair to say, and yet he viewed the danger to Whois accuracy in maintaining needs as outweighing the danger of disaggregation. > Secondarily, I believe that private network operators are the ultimate decisionmakers here. If they won't route a netblock, the value of the netblock is reduced significantly. Having enjoyed the extremely lopsided privilege of discussing broadly related matters with Geoff semi-regularly between the years 2000~2009, I wholeheartedly agree that he is one of the world's foremost experts on BGP. However, with all due respect to the man, Geoff's views about the relative merits of market-based vs. RIR-style need/capability-based number resource allocation were formed *before* BGP was widely deployed [1]. To my knowledge, the first concrete expression of those views took place in mid-1994, as documented for example in the recently published 20-year retrospective on AARNET and the early days of the Internet in Australia [2]. The second concrete expression of those views AFAIK is RFC 1744 (December 1994), which I (completely subjectively) interpret as a somewhat bitter personal reflection on the results of the first experience [3]. Regardless of whether or not that interpretation is valid, contemporaneous Australian press accounts indicate that AARNet's acquisition by Telstra was announced on January 7 1997 and implemented on July 1, and that Geoff had assumed the title of Telstra Internet's Technical Manager on or around the same time. After that he continued to advocate the same position, e.g., in the context of the IETF "Pricing for Internet Addresses and Routing Advertisements" (piara) BoF. So while Geoff's world-class expertise in BGP is unquestionable, his seemingly consistent preference for market-based vs. need/capability-based resource management must be based on something else. Besides, wasn't it you who just recently rejected (my) suggestion that observations based on the historical experience(s) of other registries could provide insight on the merits of your proposal? Or did you really mean that historical observations that seem to flatter your argument are relevant, but observations that raise doubts are not? TV [1] The gradual diffusion of BGP during this period is recorded in some detail in the IETF's old "Internet Monthly Report" series (1991-1998): ftp://ftp.rfc-editor.org/in-notes/museum/imr/. Additional good sources on both the state of EGP/BGP(x) deployment and concurrent thoughts about addressing management include the IETF meeting minutes for the area.operations, area.routing, bgpdepl, tacit, ale, cidrd, idr, and piara BoFs/working groups. [2] Described here: http://www.aarnet.edu.au/News/2009/11/26/AARNet-salutes-20th-anniversary-of-the-Internet-in-Australia.aspx The episode in question is detailed in Chapter 4, p. 48 -- which is available online at http://www.aarnet.edu.au/library/AARNet_20YearBook_Chapter4 [3] http://tools.ietf.org/html/rfc1744 > Your belief that the ability of network operators will place a constraint on disaggregation in the transfer market >> presumes a number of facts not in evidence. Namely that: >> + There is some direct correlation between what people will buy and what they can get routed. > > What kind of evidence would satisfy you? The absence of recorded /32 transactions? > Just use common sense, and put yourself in the position of a buyer. > >> + There is some correlation between what engineers can profitably route and what sales people >> will actually sell. > > There is a correlation, because if the sales people continue to sell unprofitably, the company will go out of business. > >> + The feedback mechanism on these factors is fast enough that the market can keep pace with >> the effect the market is having on them. > > To keep the market moving at its quickest pace, lower transactional costs like the artificial needs analysis. > Surely having that requirement will slow transactional pace as well as drive transactions off the books. > >> + There actually is a feedback mechanism by which the market and disaggregation will regulate >> each other to some livable equilibrium. > > The feedback mechanism is price. The network operators will effectively set the floor for size. > The price will reflect the netblock's routability. > >> In order to believe that this is not an issue, I think you would have to demonstrate that each of those >> assertions has at least a reasonable chance of being correct. > >>> And as far as 3, I have argued that speculators provide a value to free markets, that most attempts to corner markets fail, that supply uncertainty and IPv6 deployment provide a poor environment for speculators. But inasmuch as this forum is populated by technical types who are making decisions here based >>on their understanding of, and philosophy of, economics, I have decided to take David Farmer's advice and add an anti-speculator, anti-hoarder protection in the form of a limit of a /12 equivalent for needs-free transfers per 12 month period. If more transfers than that are desired, the recipient will have to >>demonstrate need. > >> Actually many attempts to corner markets in the case of a truly finite market with players that have effectively unlimited >> resources _AND_ motivations other than direct profit from the value of the market commodity succeed. > > Could I get some examples from the many you allude to? > >> While attempts to corner relatively large, and especially dynamically elastic markets (such as finished goods) by relatively small (value >> of player as compared to overall value of market) players are, in fact, doomed, that is not an accurate description >> of the likely IPv4 address market. > > I have already pointed out the obvious risk that CGN has for anybody who tries to corner the market. > There is also the very obvious risk that IPv6 will finally take off. > And when there is an alternative, the very action of the cornerers drives the market to that alternative, posing additional risks to these speculators. > As to the smallness of the market, we are in fact talking about a trillion dollar network running on a pool of 3.8 billion address units worth at least $40 billion right now. > An international commodities market consisting of fungible, valuable, and transportable assets is in the offing. > The supply source of unknown depth and availabilty, although we know the total upper bound of the market. > And of course, no evidence of this activity that you can point to in the nascent APNIC marketplace as evidenced by tradeipv4.com. > >> >>> As a whole, then, my policy seeks to recognize that there are transfer transactions which provide incentives for buyers and sellers of addresses but which transactions may not meed the needs requirements which ARIN mandates for transfers. > >> There are thefts of automobiles which meet the needs of car thieves and the resellers who purchase the stolen >> cars from them. That does not make the legalization of car theft attractive. > > Geez, maybe you should have used kidnappers of children and the child-sex rings who purchase them! > You obviously have an emotional view that transfers of addresses are akin to theft from the rightful owner, ARIN. > In that I think you act more as king than steward. > At least in terms of legacy space, the holders of address rights *predate* ARIN, and yet in your mind, if they transfer them without telling ARIN, they are thieves and hijackers. > > >>> The question is whether removing the needs basis benefits the ARIN community as a whole, not just the individual participants in any particular >>> transaction. ARIN does not need to make policy to the benefit of individual participants in a transaction. >>> Our role as stewards is to make policy to the benefit of the community as a whole. Individual participants in a >>> transaction are quite capable of looking out for their own immediate interests without involving ARIN policy. > > My rationale is the stewardship of Whois, which benefits the entire Internet community. > >>> Additionally, I pointed out that network operators, in my experience, will route addresses whose Whois record does not reflect that the network operator's customer is the registrant. The network operator, in my experience, will normally check to make sure that nobody else is advertising the addresses, and >>will solicit from the customer some documentary evidence that the customer has the right to the route the addresses, and then the network operator will route the addresses. >> > >> This is not my general experience. Most reputable operators will refuse to route addresses unless they have >> some reason to believe that the customer asking them to route them has some legitimate registration of those >> resources. > > The legitimate reason is the documentary evidence of transfer in the form of a merger, acquisition, asset sale, or Letter of Agency. > >> Sure, there are ISPs that specialize in routing hijacked space to the benefit of snowshoe spammers >> and the like, but, they are relatively rare and tend to get de-peered over time. > > And how is a company with a three-year planning window like a snowshoe spammer or hijacker? > These companies cannot pass the ARIN needs requirements, and would be incentivized to purchase enough addresses on the transfer market. > The seller is incentivized by the money the buyer will pay. > The network operator is incentivized by the money the buyer will pay him, and is satisfied by documentary evidence of the transfer that the buyer has the right to route. > The net result is Whois inaccuracy (and the fact that the buyer will have no RSA with ARIN). > > >> I agree that ARIN should get more aggressive about removing registrations for addresses which are no longer >> being held by the original resource holder or its legitimate successor through some form of section 8 transfer. >> ARIN should then reissue those available resources to organizations with documented need in a timely manner. > > This is your stick to my carrot. And wielding that stick can get very expensive for ARIN through legal costs. > And as far as legacy addresses go, ARIN can spend through the nose on lawyers, but my reading of MS/Nortel and the Plzack declaration in the Kremen case leads me to believe that would be money ARIN would waste. > > >>> The net effect of these types of transactions is a lack of trust in the Whois table as an accurate source to check for authoritative routing rights. My proposal seeks to reduce the harm to Whois accuracy by extending the range of allowable transactions, providing additional incentive to have transfers reflected >>accurately by ARIN's updating of Whois to reflect the transfer. >> > >> There is no evidence whatsoever that this newfound range provides any incentive whatsoever for those >> transactions to be registered. > > Owen, you said a couple of paragraphs ago that network operators would check registration when asked by a customer to route addresses. > I agree that is the first place they would go, and that is one of the incentives for address transferees to seek registration. > The other is the fact that this is really the only public venue for the registration of ownership rights, and I believe registration increases the resale value of the addresses. > I point again to MS/Nortel and the luckiness that MS had a need exactly equal to a previously negotiated sale with Nortel. > Had that need not matched precisely with the addresses allocated to Nortel's acquisitions 20 years ago, what would have happened? > I think we all know what would have happened, and that is that Microsoft would soon be routing those addresses, and Whois would still list Nortel, or even some Nortel acquistion, as the registrant. > This was the spur for my proposal. Had the needs requirement not been in place, the transaction could have flowed through 8.3, and the natural incentives towards registration would have caused Whois to accurately reflect Microsoft as the new registrant. > In addition to this public transaction, I offered some other potential transactions which would also fail the needs test, among which is a buyer with a 2 year planning horizon. > I will continue to use this example, as recent proposals to extend the needs window attest to the belief among some that having a 2 year planning window does not put you in the same league as spammers, speculators, and hijackers. > >> Yes, it might actually remove some small amount of disincentive, but, I believe >> it would be better for ARIN to provide incentive for accurate whois through a more active audit and >> reclamation process as that would also better serve the community by reducing the probability of hijacked >> space being invisibly routed as well as making some abandoned resources available to the ARIN community >> for reuse. > > Again with the stick. How successfully as this stick been weilded in the past? > > >>> As we move into a trading world, which will happen whether or not my proposal passes, conflicts over address control are likely to increase, and the value of trust in Whois as the routing authority will also increase. Rather than sit back and watch Whois decay, I urge ARIN stewards to consider making these >>changes to foster accuracy in Whois. >> > >> There is no proof these changes will foster accuracy in Whois. > >> Owen > > There is proof that transfers have occurred that have not been reflected in Whois. John mentioned the current 8.2 requests to reflect old mergers and acquisitions. > So we know that transfers have occurred among the non-reprobate which are not reflected in Whois. > I have pointed out that there is a major change afoot, the development of an ip address transfer market. > So looking in the past for proof, or really looking anywhere for proof of results of a change which has not occurred yet, is specious. > > Regards, > Mike > > > > > > _______________________________________________ > 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 mike at nationwideinc.com Thu May 19 16:21:34 2011 From: mike at nationwideinc.com (Mike Burns) Date: Thu, 19 May 2011 16:21:34 -0400 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate References: <4DCFDB5C64DD4F738B65AB82D36B629D@mike> <15F92ECD-2BE5-48F2-B65A-9A9D39B98F54@delong.com> <0829B106605C4FE8B189DB2E56C69615@mike> <8FB24038-B813-4DE0-91DD-56EDAD31BC03@delong.com> <36A3A11C7EDF413C9E2EC07FD0C122E0@mike> Message-ID: <0BB964E4778A4414BB36EB5929558FD1@mike> Hi Owen, replies in bold. I'm top-posting because it's too hard to keep this readable with the black vertical lines on the left side. I guess we can let Geoff Huston speak for himself: http://www.potaroo.net/ispcol/2008-11/transfers.html Look at the ARIN policy proposals listed in that document and you will see that it was written WAY before anything was actually enacted. It does not even reference the policy that ARIN adopted (2009-1) though 2008-6 was admittedly somewhat close to 2009-1. Yeah, it's old, but it's almost completely germane to the discussions we've been having here. As to Microsoft planning leading them to purchasing the same exact need as ARIN's particular application of its policies at the time of the transaction? Please. Remember that Microsoft was an arms-length negotiator who was solicited by the address broker in the deal along with 80 other companies. So what? I have no reason to believe that Micr0$0ft would have agreed to purchase addresses that they did not need. But don't you think it unlikely that Microsoft actually went shopping for a particular number of addresses in a market which didn't exist prior to their purchase, found the first such seller in history, bid on the full lot of addresses the seller was offering, won the bidding, negotiated a contract, and only then ARIN came in and found that the number of addresses in the pool was the exact amount Microsoft would have qualified for, in a single aggregate? If you think that is unlikely, then the odds of a similar deal being transacted wherein that exact match did not occur have to be recognized as non-zero, and the potential for the transaction to take place without notifying ARIN is non-zero. There are not a whole lot of deals in the public domain that we can point to, but we can infer from the fact that old mergers and acquisitions are being processed now under 8.2 that in fact, the whois data for those netblocks has been incorrect up to now. So we have some evidence that whois is inaccurate and that presumably did not affect the routability of those addresses. I have argued that the uptick in 8.2 transfer requests is in response to natural market forces at work. Prices go up and owners of address block control take steps to ensure accurate registration. Other natural forces will work to move addresses from underutilization to efficient use, and the needs requirement is not necessary to drive that, any more than it is needed to drive registration. So Microsoft's planning was so excellent that they could find the exact amount of addresses they needed in the form of the very first public sale of legacy addresses ever recorded? That's believable! And their excellent planning staff, whose decision so exactly matched ARIN's ex-post-facto analysis, failed to inform management that they could save $7.5 million by getting them directly from ARIN? I suspect that Micr0$0ft saw some expected benefit from being able to keep the exact numbers somewhat secret and having an LRSA instead of an RSA. Apparently they were willing to pay $7.5 million for it. Of course, another possibility is that they didn't actually pay $7.5M, but, rather forgave $7.5M in debt owed by Nortel as part of the bankruptcy. Microsoft could have kept the numbers secret by going straight to ARIN under NDA to get an allocation, like anybody else. And Microsoft negotiated the deal without an RSA of any kind. It was only after ARIN became notified of the deal that the negotiation between ARIN and Microsoft began, and besides, by doing the deal with a bankruptcy court, Microsoft would have known that the deal would be made public, making it *less* private than going right to ARIN. "I suppose since I favor a faster migration to IPv6, I should probably support the greater disruption to IPv4 brought about by your policy, but, in the interests of the community, I just can't bring myself to do so." lol. Sounds like you're shirking your longterm stewardship duties there. No, I believe that my stewardship duties are to work to manage the address space in the least disruptive manner most beneficial to the community at large. My personal opinion in favor of faster IPv6 migration is not particularly relevant to my stewardship duties. As such, I just can't bring myself to shirk my stewardship duties as you request. Owen Regards, Mike -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthew at matthew.at Thu May 19 17:00:50 2011 From: matthew at matthew.at (Matthew Kaufman) Date: Thu, 19 May 2011 14:00:50 -0700 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate In-Reply-To: <8695009A81378E48879980039EEDAD289F033041@MAIL1.polartel.local> References: <4DCFDB5C64DD4F738B65AB82D36B629D@mike><15F92ECD-2BE5-48F2-B65A-9A9D39B98F5 4@delong.com><0829B106605C4FE8B189DB2E56C69615@mike><8FB24038-B813-4DE0-91DD-56EDAD31BC03@delong.com><36A3A11C7EDF413C9E2EC07FD 0C122E0@mike> <8F23AB4955E3404393B1E03831C91054@mike> <6397CBB3-8145-43E7-8288-132F19B89E3F@delong.com> <4DD56EBB.70102@matthew.at> <8695009A81378E48879980039EEDAD289F033041@MAIL1.polartel.local> Message-ID: <4DD58502.7050409@matthew.at> On 5/19/2011 12:41 PM, Kevin Kargel wrote: > > We are managing policy for the community, not just for the top ten ISP's or for a few traders who want to organize a market to make some quick cash. Let's keep the small business and non-profit orgs in mind. Imagine how much farther your small business or non-profit could get if someone paid you $1M to switch to IPv6. Matthew Kaufman From mike at nationwideinc.com Thu May 19 17:08:18 2011 From: mike at nationwideinc.com (Mike Burns) Date: Thu, 19 May 2011 17:08:18 -0400 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate References: <4DCFDB5C64DD4F738B65AB82D36B629D@mike><15F92ECD-2BE5-48F2-B65A-9A9D39B98F5 4@delong.com><0829B106605C4FE8B189DB2E56C69615@mike><8FB24038-B813-4DE0-91DD-56EDAD31BC03@delong.com><36A3A11C7EDF413C9E2EC07FD 0C122E0@mike> <8F23AB4955E3404393B1E03831C91054@mike><6397CBB3-8145-43E7-8288-132F19B89E3 F@delong.com><4DD56EBB.70102@matthew.at> <8695009A81378E48879980039EEDAD289F033041@MAIL1.polartel.local> Message-ID: <52C4C669D56E48CEB8A6E74B5C4942B8@mike> Hi Kevin, Making policy which brings more supply into the market will reduce prices for the big guy and the little guy. One element of my proposal is removing the threat of ARIN recovery action for RSA holders. My hope is that this will provide the incentive for holders of underutilized assets to sell them without a fear of an audit. I think that big companies probably have the edge in gaming needs analyses; whether or not they would use that edge is of course an open question. But simplifiying transactions, as my proposal attempts to do, favors the small guy, IMO. Regards, Mike ----- Original Message ----- From: "Kevin Kargel" To: ; "Owen DeLong" Cc: Sent: Thursday, May 19, 2011 3:41 PM Subject: Re: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate > > > >> -----Original Message----- >> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On >> Behalf Of Matthew Kaufman >> Sent: Thursday, May 19, 2011 2:26 PM >> To: Owen DeLong >> Cc: arin-ppml at arin.net >> Subject: Re: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois >> Accurate >> >> On 5/19/2011 12:05 PM, Owen DeLong wrote: >> > It was not intended as such and I apologize if it came across that >> > way. My point is that your policy >> > would serve the interest of a select few well capitalized >> > organizations significantly better than >> > the interests of the overall community. >> >> If "a select few well capitalized organizations" are going to corner the >> market on space, doesn't that require them to purchase the maximum >> amount of space from existing holders at fairly high prices? >> >> That might serve the *financial* interests of the overall community >> better than policies where the number of buyers is limited by needs >> assessment. >> >> It also provides existing holders with more cash to use for their IPv6 >> deployments. >> >> Matthew Kaufman >> _______________________________________________ > > I am a relatively small time operator. It does not benefit me one whit if > the big boys buy IP's from the big boys. It might keep me from getting > IP's if/when I need them. > > I am part of the overall community. > > We are managing policy for the community, not just for the top ten ISP's > or for a few traders who want to organize a market to make some quick > cash. Let's keep the small business and non-profit orgs in mind. This is > not all about the almighty dollar and how to get more of them. > > Kevin > > _______________________________________________ > 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 Thu May 19 17:19:22 2011 From: kkargel at polartel.com (Kevin Kargel) Date: Thu, 19 May 2011 16:19:22 -0500 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate In-Reply-To: <52C4C669D56E48CEB8A6E74B5C4942B8@mike> References: <4DCFDB5C64DD4F738B65AB82D36B629D@mike><15F92ECD-2BE5-48F2-B65A-9A9D39B98F5 4@delong.com><0829B106605C4FE8B189DB2E56C69615@mike><8FB24038-B813-4DE0-91DD-56EDAD31BC03@delong.com><36A3A11C7EDF413C9E2EC07FD 0C122E0@mike> <8F23AB4955E3404393B1E03831C91054@mike><6397CBB3-8145-43E7-8288-132F19B89E3 F@delong.com><4DD56EBB.70102@matthew.at> <8695009A81378E48879980039EEDAD289F033041@MAIL1.polartel.local> <52C4C669D56E48CEB8A6E74B5C4942B8@mike> Message-ID: <8695009A81378E48879980039EEDAD289F033042@MAIL1.polartel.local> > -----Original Message----- > From: Mike Burns [mailto:mike at nationwideinc.com] > Sent: Thursday, May 19, 2011 4:08 PM > To: Kevin Kargel; matthew at matthew.at; Owen DeLong > Cc: arin-ppml at arin.net > Subject: Re: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois > Accurate > > Hi Kevin, > > Making policy which brings more supply into the market will reduce prices > for the big guy and the little guy. > One element of my proposal is removing the threat of ARIN recovery action > for RSA holders. > My hope is that this will provide the incentive for holders of > underutilized > assets to sell them without a fear of an audit. > I think that big companies probably have the edge in gaming needs > analyses; > whether or not they would use that edge is of course an open question. > But simplifiying transactions, as my proposal attempts to do, favors the > small guy, IMO. > So you are telling me that if I go to a trader and buy a /20 block of IP's it will cost me less than it does if I go to ARIN and get a /20 block of IP's? hmm.. that doesn't leave much incentive for the trader.. Please pardon my skepticism.. > Regards, > Mike > From matthew at matthew.at Thu May 19 17:19:36 2011 From: matthew at matthew.at (Matthew Kaufman) Date: Thu, 19 May 2011 14:19:36 -0700 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate In-Reply-To: <8695009A81378E48879980039EEDAD289F033042@MAIL1.polartel.local> References: <4DCFDB5C64DD4F738B65AB82D36B629D@mike><15F92ECD-2BE5-48F2-B65A-9A9D39B98F5 4@delong.com><0829B106605C4FE8B189DB2E56C69615@mike><8FB24038-B813-4DE0-91DD-56EDAD31BC03@delong.com><36A3A11C7EDF413C9E2EC07FD 0C122E0@mike> <8F23AB4955E3404393B1E03831C91054@mike><6397CBB3-8145-43E7-8288-132F19B89E3 F@delong.com><4DD56EBB.70102@matthew.at> <8695009A81378E48879980039EEDAD289F033041@MAIL1.polartel.local> <52C4C669D56E48CEB8A6E74B5C4942B8@mike> <8695009A81378E48879980039EEDAD289F033042@MAIL1.polartel.local> Message-ID: <4DD58968.1040908@matthew.at> On 5/19/2011 2:19 PM, Kevin Kargel wrote: > > So you are telling me that if I go to a trader and buy a /20 block of IP's it will cost me less than it does if I go to ARIN and get a /20 block of IP's? hmm.. that doesn't leave much incentive for the trader.. After runout, if you go to a trader and buy a /20 block of IPs you'll get a lot more address space than if you go to ARIN and ask them for a /20. Matthew Kaufman From owen at delong.com Thu May 19 17:21:01 2011 From: owen at delong.com (Owen DeLong) Date: Thu, 19 May 2011 14:21:01 -0700 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate In-Reply-To: <4DD56EBB.70102@matthew.at> References: <4DCFDB5C64DD4F738B65AB82D36B629D@mike><15F92ECD-2BE5-48F2-B65A-9A9D39B98F5 4@delong.com><0829B106605C4FE8B189DB2E56C69615@mike><8FB24038-B813-4DE0-91DD-56EDAD31BC03@delong.com><36A3A11C7EDF413C9E2EC07FD 0C122E0@mike> <8F23AB4955E3404393B1E03831C91054@mike> <6397CBB3-8145-43E7-8288-132F19B89E3F@delong.com> <4DD56EBB.70102@matthew.at> Message-ID: <5CABD084-E16C-4FA1-84E1-E5CA9F899144@delong.com> On May 19, 2011, at 12:25 PM, Matthew Kaufman wrote: > On 5/19/2011 12:05 PM, Owen DeLong wrote: >> It was not intended as such and I apologize if it came across that way. My point is that your policy >> would serve the interest of a select few well capitalized organizations significantly better than >> the interests of the overall community. > > If "a select few well capitalized organizations" are going to corner the market on space, doesn't that require them to purchase the maximum amount of space from existing holders at fairly high prices? > The prices may or may not be higher or lower than what would be the case selling to organizations with justified need. > That might serve the *financial* interests of the overall community better than policies where the number of buyers is limited by needs assessment. > While it may be more profitable to the members of the community that have addresses that they are not using, I doubt that it would be to the overall benefit of the community as a whole. The number of buyers with need will exceed the available address space. As such, I don't believe that need will serve as a significant barrier or cause undue harm to sellers. > It also provides existing holders with more cash to use for their IPv6 deployments. > I don't see any evidence to support that theory. Owen From matthew at matthew.at Thu May 19 17:27:20 2011 From: matthew at matthew.at (Matthew Kaufman) Date: Thu, 19 May 2011 14:27:20 -0700 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate In-Reply-To: <5CABD084-E16C-4FA1-84E1-E5CA9F899144@delong.com> References: <4DCFDB5C64DD4F738B65AB82D36B629D@mike><15F92ECD-2BE5-48F2-B65A-9A9D39B98F5 4@delong.com><0829B106605C4FE8B189DB2E56C69615@mike><8FB24038-B813-4DE0-91DD-56EDAD31BC03@delong.com><36A3A11C7EDF413C9E2EC07FD 0C122E0@mike> <8F23AB4955E3404393B1E03831C91054@mike> <6397CBB3-8145-43E7-8288-132F19B89E3F@delong.com> <4DD56EBB.70102@matthew.at> <5CABD084-E16C-4FA1-84E1-E5CA9F899144@delong.com> Message-ID: <4DD58B38.206@matthew.at> On 5/19/2011 2:21 PM, Owen DeLong wrote: > > The number of buyers with need will > exceed the available address space. 1) You can't prove that, and, 2) Even if that's true, adding buyers without need will increase demand and thus increase revenue for the sellers Matthew Kaufman From mike at nationwideinc.com Thu May 19 17:35:55 2011 From: mike at nationwideinc.com (Mike Burns) Date: Thu, 19 May 2011 17:35:55 -0400 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate References: <4DCFDB5C64DD4F738B65AB82D36B629D@mike> <15F92ECD-2BE5-48F2-B65A-9A9D39B98F54@delong.com> <0829B106605C4FE8B189DB2E56C69615@mike> <51506A06-D2EE-4A0D-B92B-781662094A1C@eyeconomics.com> Message-ID: <0CCB8AB89D144E89872AF0D635E95497@mike> Hi Tom, >Can you provide us with a comparable measure of the number of old address >holders who have not responded to opportunity afforded by the 8.2 change? No. >If possible, please break down the number into two groups -- those who are >on the fence and holding out fin hopes of additional blandishments and >concessions, and those whose philosophical or >commercial priorities >preclude registration regardless of the side payments. I have never met anybody whose philosophical or commercial priorites preclude registration. I imagine that many of those who have not done the 8.2 transfer have failed to see any utility in doing so. Besides, the ARIN language never required it, it only says "ARIN will consider requests for transfers." And since the addresses continued to be routed without notifying ARIN of the mergers and acquisitions, many failed to apply. Also, for legacy holders, an 8.2 transfer meant having to sign an RSA, I think, which was a disincentive. >Having enjoyed the extremely lopsided privilege of discussing broadly >related matters with Geoff semi-regularly between the years 2000~2009, I >wholeheartedly agree that he is one of the world's >foremost experts on >BGP. However, with all due respect to the man, Geoff's views about the >relative merits of market-based vs. RIR-style need/capability-based number >resource allocation were formed >*before* BGP was widely deployed [1]. To >my knowledge, the first concrete expression of those views took place in >mid-1994, as documented for example in the recently published 20-year > >retrospective on AARNET and the early days of the Internet in Australia >[2]. The second concrete expression of those views AFAIK is RFC 1744 >(December 1994), which I (completely subjectively) >interpret as a somewhat >bitter personal reflection on the results of the first experience [3]. >Regardless of whether or not that interpretation is valid, contemporaneous >Australian press accounts indicate that AARNet's acquisition by Telstra was >announced on January 7 1997 and implemented on >July 1, and that Geoff had >assumed the title of Telstra Internet's Technical Manager on or around the >same time. After that he continued to advocate the same position, e.g., in >the context of the IETF >"Pricing for Internet Addresses and Routing >Advertisements" (piara) BoF. >So while Geoff's world-class expertise in BGP is unquestionable, his >seemingly consistent preference for market-based vs. need/capability-based >resource management must be based on something else. I never claimed that Geoff Huston, whom I have never met, did not have a preference for market-based solutions, only that he did not view the danger of disaggregation as a reason to have needs requirements for transfers. Unless you are implying that his preference for market-based solutions has somehow overridden his BGP expertise, my point stands. >Besides, wasn't it you who just recently rejected (my) suggestion that >observations based on the historical experience(s) of other registries >could provide insight on the merits of your proposal? You suggested that the historical experience of the DNS registry was applicable, but I still have not seen an apples-to-apples comparison worthy of providing insights. For the DNS registry to inform us, we would have to compare an experience of for-pay DNS registries *with a needs test* to for-pay DNS registries *without a needs test*. >Or did you really mean that historical observations that seem to flatter >your argument are relevant, but observations that raise doubts are not? No. Regards, Mike TV [1] The gradual diffusion of BGP during this period is recorded in some detail in the IETF's old "Internet Monthly Report" series (1991-1998): ftp://ftp.rfc-editor.org/in-notes/museum/imr/. Additional good sources on both the state of EGP/BGP(x) deployment and concurrent thoughts about addressing management include the IETF meeting minutes for the area.operations, area.routing, bgpdepl, tacit, ale, cidrd, idr, and piara BoFs/working groups. [2] Described here: http://www.aarnet.edu.au/News/2009/11/26/AARNet-salutes-20th-anniversary-of-the-Internet-in-Australia.aspx The episode in question is detailed in Chapter 4, p. 48 -- which is available online at http://www.aarnet.edu.au/library/AARNet_20YearBook_Chapter4 [3] http://tools.ietf.org/html/rfc1744 From mike at nationwideinc.com Thu May 19 17:42:03 2011 From: mike at nationwideinc.com (Mike Burns) Date: Thu, 19 May 2011 17:42:03 -0400 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate References: <4DCFDB5C64DD4F738B65AB82D36B629D@mike><15F92ECD-2BE5-48F2-B65A-9A9D39B98F5 4@delong.com><0829B106605C4FE8B189DB2E56C69615@mike><8FB24038-B813-4DE0-91DD-56EDAD31BC03@delong.com><36A3A11C7EDF413C9E2EC07FD 0C122E0@mike> <8F23AB4955E3404393B1E03831C91054@mike><6397CBB3-8145-43E7-8288-132F19B89E3 F@delong.com><4DD56EBB.70102@matthew.at> <8695009A81378E48879980039EEDAD289F033041@MAIL1.polartel.local> <52C4C669D56E48CEB8A6E74B5C4942B8@mike> <8695009A81378E48879980039EEDAD289F033042@MAIL1.polartel.local> Message-ID: > Hi Kevin, > > Making policy which brings more supply into the market will reduce prices > for the big guy and the little guy. > One element of my proposal is removing the threat of ARIN recovery action > for RSA holders. > My hope is that this will provide the incentive for holders of > underutilized > assets to sell them without a fear of an audit. > I think that big companies probably have the edge in gaming needs > analyses; > whether or not they would use that edge is of course an open question. > But simplifiying transactions, as my proposal attempts to do, favors the > small guy, IMO. > Hi Kevin, >So you are telling me that if I go to a trader and buy a /20 block of IP's >it will cost me less than it does if I go to ARIN and get a /20 block of >IP's? hmm.. that doesn't leave much incentive for the >trader.. >Please pardon my skepticism.. Something has been lost in the translation, I am not saying anything of the sort. I am saying that once exhaust is reached, you will not be able to go to ARIN and get a /20. You will have to purchase a /20 from somebody. What I am saying is by reducing the fear of an audit, sellers are more likely to put their addresses up for sale. And when you have an increase in supply, price drops. It's the price drop that will help the little guy. Regards, Mike From ikiris at gmail.com Thu May 19 17:44:52 2011 From: ikiris at gmail.com (Blake Dunlap) Date: Thu, 19 May 2011 16:44:52 -0500 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate In-Reply-To: <0CCB8AB89D144E89872AF0D635E95497@mike> References: <4DCFDB5C64DD4F738B65AB82D36B629D@mike> <15F92ECD-2BE5-48F2-B65A-9A9D39B98F54@delong.com> <0829B106605C4FE8B189DB2E56C69615@mike> <51506A06-D2EE-4A0D-B92B-781662094A1C@eyeconomics.com> <0CCB8AB89D144E89872AF0D635E95497@mike> Message-ID: On Thu, May 19, 2011 at 16:35, Mike Burns wrote: > I never claimed that Geoff Huston, whom I have never met, did not have a > preference for market-based solutions, only that he did not view the danger > of disaggregation as a reason to have needs requirements for transfers. > Unless you are implying that his preference for market-based solutions has > somehow overridden his BGP expertise, my point stands. > > > Mike > Just want to make sure to clear this up, my basis for not wanting to remove needs requirement has nothing to do with deaggregation. Honestly I see deaggregation looming regardless of this proposal. The reason I strongly believe needs should remain is to make sure all IPs go to someone who will actually use them, instead of hoarding. If you go back and reread my proposal as an alternative to this, you'll see that I am not opposed to opening up and facilitating transfers, even to giving legacy holders free reign for selling their extra space, but I don't see any use for allowing the market to be completely cornered by players or IPs to be hoarded. They are still a very limited resource until an actual mass migration to IPv6 occurs, and we need to act accordingly. Needs basis in all its forms is not to protect the routing table, it is to protect the availability to the largest amount of players. -Blake -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike at nationwideinc.com Thu May 19 17:49:43 2011 From: mike at nationwideinc.com (Mike Burns) Date: Thu, 19 May 2011 17:49:43 -0400 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate References: <4DCFDB5C64DD4F738B65AB82D36B629D@mike> <15F92ECD-2BE5-48F2-B65A-9A9D39B98F54@delong.com> <0829B106605C4FE8B189DB2E56C69615@mike> <51506A06-D2EE-4A0D-B92B-781662094A1C@eyeconomics.com> <0CCB8AB89D144E89872AF0D635E95497@mike> Message-ID: <31B8F43F2E3545D4BB04061A0510715E@mike> Blake, My proposal includes a limit of /12 of needs-free transfers specifically to prevent hoarding and market cornering. (It's a recent addition.) Regards, Mike ----- Original Message ----- From: Blake Dunlap To: Mike Burns Cc: Tom Vest ; arin-ppml at arin.net Sent: Thursday, May 19, 2011 5:44 PM Subject: Re: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate On Thu, May 19, 2011 at 16:35, Mike Burns wrote: I never claimed that Geoff Huston, whom I have never met, did not have a preference for market-based solutions, only that he did not view the danger of disaggregation as a reason to have needs requirements for transfers. Unless you are implying that his preference for market-based solutions has somehow overridden his BGP expertise, my point stands. Mike Just want to make sure to clear this up, my basis for not wanting to remove needs requirement has nothing to do with deaggregation. Honestly I see deaggregation looming regardless of this proposal. The reason I strongly believe needs should remain is to make sure all IPs go to someone who will actually use them, instead of hoarding. If you go back and reread my proposal as an alternative to this, you'll see that I am not opposed to opening up and facilitating transfers, even to giving legacy holders free reign for selling their extra space, but I don't see any use for allowing the market to be completely cornered by players or IPs to be hoarded. They are still a very limited resource until an actual mass migration to IPv6 occurs, and we need to act accordingly. Needs basis in all its forms is not to protect the routing table, it is to protect the availability to the largest amount of players. -Blake -------------- next part -------------- An HTML attachment was scrubbed... URL: From ikiris at gmail.com Thu May 19 17:59:28 2011 From: ikiris at gmail.com (Blake Dunlap) Date: Thu, 19 May 2011 16:59:28 -0500 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate In-Reply-To: <31B8F43F2E3545D4BB04061A0510715E@mike> References: <4DCFDB5C64DD4F738B65AB82D36B629D@mike> <15F92ECD-2BE5-48F2-B65A-9A9D39B98F54@delong.com> <0829B106605C4FE8B189DB2E56C69615@mike> <51506A06-D2EE-4A0D-B92B-781662094A1C@eyeconomics.com> <0CCB8AB89D144E89872AF0D635E95497@mike> <31B8F43F2E3545D4BB04061A0510715E@mike> Message-ID: On Thu, May 19, 2011 at 16:49, Mike Burns wrote: > Blake, > > My proposal includes a limit of /12 of needs-free transfers specifically to > prevent hoarding and market cornering. > (It's a recent addition.) > > Regards, > Mike > It's not about a limit, though the above limit is ludicrously high. What benefit to the community does IP space sitting with some broker give the community post run-out? Even just a /24 of space just sitting there is a complete waste of resources that could be better used elsewhere. I am perfectly OK with existing space sitting with someone who no longer needs it waiting to be sold. I think it is a completely unnecessary waste of resources to allow someone to purchase said space that is not planning on *using* it. Be a broker if you want, and make a site like EBAY or something, proxy transfer if you really want to be aggressive, but I just don't see the use of letting space sit with a buyer who only intends to try to profit from speculation, because that is the only possible justification for removing needs is speculation, wether its your overly long planning period, or some other equivalent, its still speculation of a limited resource to bring you profit at the expense of the community. -Blake -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthew at matthew.at Thu May 19 18:13:27 2011 From: matthew at matthew.at (Matthew Kaufman) Date: Thu, 19 May 2011 15:13:27 -0700 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate In-Reply-To: References: <4DCFDB5C64DD4F738B65AB82D36B629D@mike> <15F92ECD-2BE5-48F2-B65A-9A9D39B98F54@delong.com> <0829B106605C4FE8B189DB2E56C69615@mike> <51506A06-D2EE-4A0D-B92B-781662094A1C@eyeconomics.com> <0CCB8AB89D144E89872AF0D635E95497@mike> <31B8F43F2E3545D4BB04061A0510715E@mike> Message-ID: <4DD59607.4020203@matthew.at> On 5/19/2011 2:59 PM, Blake Dunlap wrote: > > > > its still speculation of a limited resource to bring you profit at the > expense of the community. Please remember that not all speculation of limited resources, even if it brings the speculator profit from time to time, is at the expense of the community. Oftentimes it actually provides benefits to the community (market liquidity, price stability, etc.) Matthew Kaufman From ikiris at gmail.com Thu May 19 18:21:51 2011 From: ikiris at gmail.com (Blake Dunlap) Date: Thu, 19 May 2011 17:21:51 -0500 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate In-Reply-To: <4DD59607.4020203@matthew.at> References: <4DCFDB5C64DD4F738B65AB82D36B629D@mike> <15F92ECD-2BE5-48F2-B65A-9A9D39B98F54@delong.com> <0829B106605C4FE8B189DB2E56C69615@mike> <51506A06-D2EE-4A0D-B92B-781662094A1C@eyeconomics.com> <0CCB8AB89D144E89872AF0D635E95497@mike> <31B8F43F2E3545D4BB04061A0510715E@mike> <4DD59607.4020203@matthew.at> Message-ID: On Thu, May 19, 2011 at 17:13, Matthew Kaufman wrote: > On 5/19/2011 2:59 PM, Blake Dunlap wrote: > >> >> >> >> its still speculation of a limited resource to bring you profit at the >> expense of the community. >> > > Please remember that not all speculation of limited resources, even if it > brings the speculator profit from time to time, is at the expense of the > community. Oftentimes it actually provides benefits to the community (market > liquidity, price stability, etc.) > > Matthew Kaufman > Price stability does not require a middle man to hold assets, they only need to be listed, but I will give you liquidity for *sellers* absolutely. Do we really need such liquidity for *sellers* in IPv4? Is there even use for such? I thought the whole point was to free up space for use, not to allow holders to immediately profit from selling? -Blake -------------- next part -------------- An HTML attachment was scrubbed... URL: From tvest at eyeconomics.com Thu May 19 18:24:29 2011 From: tvest at eyeconomics.com (Tom Vest) Date: Thu, 19 May 2011 18:24:29 -0400 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate In-Reply-To: <0CCB8AB89D144E89872AF0D635E95497@mike> References: <4DCFDB5C64DD4F738B65AB82D36B629D@mike> <15F92ECD-2BE5-48F2-B65A-9A9D39B98F54@delong.com> <0829B106605C4FE8B189DB2E56C69615@mike> <51506A06-D2EE-4A0D-B92B-781662094A1C@eyeconomics.com> <0CCB8AB89D144E89872AF0D635E95497@mike> Message-ID: <2691B7B9-1F3C-403C-B4E8-5B82BED0E191@eyeconomics.com> On May 19, 2011, at 5:35 PM, Mike Burns wrote: > Hi Tom, > >> Can you provide us with a comparable measure of the number of old address holders who have not responded to opportunity afforded by the 8.2 change? > > No. > >> If possible, please break down the number into two groups -- those who are on the fence and holding out fin hopes of additional blandishments and concessions, and those whose philosophical or >commercial priorities preclude registration regardless of the side payments. > > I have never met anybody whose philosophical or commercial priorites preclude registration. I imagine that many of those who have not done the 8.2 transfer have failed to see any utility in doing so. > Besides, the ARIN language never required it, it only says "ARIN will consider requests for transfers." And since the addresses continued to be routed without notifying ARIN of the mergers and acquisitions, many failed to apply. Also, for legacy holders, an 8.2 transfer meant having to sign an RSA, I think, which was a disincentive. If you are uncomfortable with the second half of of the question, then a simple accounting of all of the old address holders who have not responded yet will suffice. To quote what you deleted, for the sake of clarity: "I have argued that the uptick in 8.2 transfer requests is in response to natural market forces at work. Prices go up and owners of address block control take steps to ensure accurate registration." Without some means of (at minimum) benchmarking the relative size of (or anything else about) that "slight uptick," your interpretation of its causes and relevance are completely subjective. >> Having enjoyed the extremely lopsided privilege of discussing broadly related matters with Geoff semi-regularly between the years 2000~2009, I wholeheartedly agree that he is one of the world's >foremost experts on BGP. However, with all due respect to the man, Geoff's views about the relative merits of market-based vs. RIR-style need/capability-based number resource allocation were formed >*before* BGP was widely deployed [1]. To my knowledge, the first concrete expression of those views took place in mid-1994, as documented for example in the recently published 20-year >retrospective on AARNET and the early days of the Internet in Australia [2]. The second concrete expression of those views AFAIK is RFC 1744 (December 1994), which I (completely subjectively) >interpret as a somewhat bitter personal reflection on the results of the first experience [3]. > >> Regardless of whether or not that interpretation is valid, contemporaneous Australian press accounts indicate that AARNet's acquisition by Telstra was announced on January 7 1997 and implemented on >July 1, and that Geoff had assumed the title of Telstra Internet's Technical Manager on or around the same time. After that he continued to advocate the same position, e.g., in the context of the IETF >"Pricing for Internet Addresses and Routing Advertisements" (piara) BoF. > >> So while Geoff's world-class expertise in BGP is unquestionable, his seemingly consistent preference for market-based vs. need/capability-based resource management must be based on something else. > > I never claimed that Geoff Huston, whom I have never met, did not have a preference for market-based solutions, only that he did not view the danger of disaggregation as a reason to have needs requirements for transfers. Why are you attempting to change the subject to disaggregation? I thought your proposal was based on claims about the best way to maintain whois accuracy? > Unless you are implying that his preference for market-based solutions has somehow overridden his BGP expertise, my point stands. I decline to speculate about Geoff's innermost thoughts on this matter. Geoff has a vast reserve of hard experience dealing with market mechanisms in the BGP world, but even he hasn't advocated pure free-market routing at all places and times. But then my experience discussing matters like these with people all over the world for the last decade or so has left the impression that world-class expertise in BGP is perfectly compatible with radically opposing, mutually incompatible views -- not only concerning the best way to maintain a protocol number resource registry, but even about the proper way to manage global interdomain routing. Opinions on the two subjects seem to be quite independent and unrelated, at least in most people. Of course there is undeniably a subset of people (in fact, one that's is quite well represented in this industry) who believe that unrestricted market mechanisms represent the ideal solution for every problem at all times and places. I find it a lot easier to assume that you fall within that group -- esp. since you have more-or-less self-identified yourself as a member. >> Besides, wasn't it you who just recently rejected (my) suggestion that observations based on the historical experience(s) of other registries could provide insight on the merits of your proposal? > > You suggested that the historical experience of the DNS registry was applicable, but I still have not seen an apples-to-apples comparison worthy of providing insights. For the DNS registry to inform us, we would have to compare an experience of for-pay DNS registries *with a needs test* to for-pay DNS registries *without a needs test*. Okay, I concede your point. And based on the same logic, I suggest that this proposal should be abandoned on the grounds that no one can claim to have any relevant "apples-to-apples" experience, or to have have any defensible "apples-to-apples" basis for assuming that this proposal has any chance of making it easier to maintain whois accuracy going forward. TV >> Or did you really mean that historical observations that seem to flatter your argument are relevant, but observations that raise doubts are not? > > No. > > Regards, > Mike > > > > > > TV > > [1] The gradual diffusion of BGP during this period is recorded in some detail in the IETF's old "Internet Monthly Report" series (1991-1998): ftp://ftp.rfc-editor.org/in-notes/museum/imr/. > Additional good sources on both the state of EGP/BGP(x) deployment and concurrent thoughts about addressing management include the IETF meeting minutes for the area.operations, area.routing, bgpdepl, tacit, ale, cidrd, idr, and piara BoFs/working groups. > > [2] Described here: http://www.aarnet.edu.au/News/2009/11/26/AARNet-salutes-20th-anniversary-of-the-Internet-in-Australia.aspx > The episode in question is detailed in Chapter 4, p. 48 -- which is available online at > http://www.aarnet.edu.au/library/AARNet_20YearBook_Chapter4 > > [3] http://tools.ietf.org/html/rfc1744 > > From matthew at matthew.at Thu May 19 18:28:09 2011 From: matthew at matthew.at (Matthew Kaufman) Date: Thu, 19 May 2011 15:28:09 -0700 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate In-Reply-To: References: <4DCFDB5C64DD4F738B65AB82D36B629D@mike> <15F92ECD-2BE5-48F2-B65A-9A9D39B98F54@delong.com> <0829B106605C4FE8B189DB2E56C69615@mike> <51506A06-D2EE-4A0D-B92B-781662094A1C@eyeconomics.com> <0CCB8AB89D144E89872AF0D635E95497@mike> <31B8F43F2E3545D4BB04061A0510715E@mike> <4DD59607.4020203@matthew.at> Message-ID: <4DD59979.70109@matthew.at> On 5/19/2011 3:21 PM, Blake Dunlap wrote: > On Thu, May 19, 2011 at 17:13, Matthew Kaufman > wrote: > > On 5/19/2011 2:59 PM, Blake Dunlap wrote: > > > > > its still speculation of a limited resource to bring you > profit at the expense of the community. > > > Please remember that not all speculation of limited resources, > even if it brings the speculator profit from time to time, is at > the expense of the community. Oftentimes it actually provides > benefits to the community (market liquidity, price stability, etc.) > > Matthew Kaufman > > > Price stability does not require a middle man to hold assets, they > only need to be listed, but I will give you liquidity for *sellers* > absolutely. > > Do we really need such liquidity for *sellers* in IPv4? Is there even > use for such? Sure. If you need space in 6 months, but not now, wouldn't it be nice to get it from someone who'd worked with a middleman today to start a 5-month project to free up space and transfer it to the middleman... rather than having to wait those 5 months yourself? That's just one of many examples that popped into my head. Matthew Kaufman -------------- next part -------------- An HTML attachment was scrubbed... URL: From ikiris at gmail.com Thu May 19 18:40:30 2011 From: ikiris at gmail.com (Blake Dunlap) Date: Thu, 19 May 2011 17:40:30 -0500 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate In-Reply-To: <4DD59979.70109@matthew.at> References: <4DCFDB5C64DD4F738B65AB82D36B629D@mike> <15F92ECD-2BE5-48F2-B65A-9A9D39B98F54@delong.com> <0829B106605C4FE8B189DB2E56C69615@mike> <51506A06-D2EE-4A0D-B92B-781662094A1C@eyeconomics.com> <0CCB8AB89D144E89872AF0D635E95497@mike> <31B8F43F2E3545D4BB04061A0510715E@mike> <4DD59607.4020203@matthew.at> <4DD59979.70109@matthew.at> Message-ID: On Thu, May 19, 2011 at 17:28, Matthew Kaufman wrote: > Price stability does not require a middle man to hold assets, they only > need to be listed, but I will give you liquidity for *sellers* absolutely. > > Do we really need such liquidity for *sellers* in IPv4? Is there even use > for such? > > Sure. If you need space in 6 months, but not now, wouldn't it be nice to > get it from someone who'd worked with a middleman today to start a 5-month > project to free up space and transfer it to the middleman... rather than > having to wait those 5 months yourself? > > That's just one of many examples that popped into my head. > > Matthew Kaufman > I'm trying to understand what you just said, but I am having a hard time. Can you try and rephrase? Also, assuming I am reading the above correctly, as a response, can you explain why locking out IPs for your future use (of an undetermined time period, lets try not to get pendatic) is of benefit to the community now, when there are probably a significant number of parties wanting space now, as these policies only even matter if there is resource contention? One thing to note, and I hesitate to even mention this, is that needs based justification does *not* preclude a party reserving space for you, depending on how the other policies end up being shaped as to IP space sales listings / transfers especially in regards to seller needs justification. It only currently affects you when the transfer is to take place. Hmmm, you make a good point in that regard. After thinking about what you just said, and what I just said, I do think we need to redo some of the IPv4 policy in regards to transfer, sales, and needs justification, since as it stands, there is some basic conflict in the different policies, at least on the side of sellers. -Blake -------------- next part -------------- An HTML attachment was scrubbed... URL: From owen at delong.com Thu May 19 18:54:09 2011 From: owen at delong.com (Owen DeLong) Date: Thu, 19 May 2011 15:54:09 -0700 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate In-Reply-To: <52C4C669D56E48CEB8A6E74B5C4942B8@mike> References: <4DCFDB5C64DD4F738B65AB82D36B629D@mike><15F92ECD-2BE5-48F2-B65A-9A9D39B98F5 4@delong.com><0829B106605C4FE8B189DB2E56C69615@mike><8FB24038-B813-4DE0-91DD-56EDAD31BC03@delong.com><36A3A11C7EDF413C9E2EC07FD 0C122E0@mike> <8F23AB4955E3404393B1E03831C91054@mike><6397CBB3-8145-43E7-8288-132F19B89E3 F@delong.com><4DD56EBB.70102@matthew.at> <8695009A81378E48879980039EEDAD289F033041@MAIL1.polartel.local> <52C4C669D56E48CEB8A6E74B5C4942B8@mike> Message-ID: <6BC5FD27-CDFD-4CE1-8A68-EE79799C4CF7@delong.com> On May 19, 2011, at 2:08 PM, Mike Burns wrote: > Hi Kevin, > > Making policy which brings more supply into the market will reduce prices for the big guy and the little guy. Agreed. This doesn't do that. > One element of my proposal is removing the threat of ARIN recovery action for RSA holders. Where? Oh, you mean the part where if they are offering them for sale in one particular forum, you preclude section 12 action. > My hope is that this will provide the incentive for holders of underutilized assets to sell them without a fear of an audit. ARIN has already stated that they will not peruse transfer listings looking for section 12 targets. Being on the listing will not get you targeted for audit even without this policy. However, audits are still possible regardless of whether this policy passes or not. In that regard, it is largely a no-op. > I think that big companies probably have the edge in gaming needs analyses; whether or not they would use that edge is of course an open question. I absolutely disagree. I think that large requests are looked at with much greater scrutiny than smaller ones. I also think that small organizations have little need to game the system for needs analysis. > But simplifiying transactions, as my proposal attempts to do, favors the small guy, IMO. Only if the small guy is allowed to participate. I would argue that the likely outcome of your proposal is to exclude them altogether. Owen > > Regards, > Mike > > > ----- Original Message ----- From: "Kevin Kargel" > To: ; "Owen DeLong" > Cc: > Sent: Thursday, May 19, 2011 3:41 PM > Subject: Re: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate > > >> >> >> >>> -----Original Message----- >>> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On >>> Behalf Of Matthew Kaufman >>> Sent: Thursday, May 19, 2011 2:26 PM >>> To: Owen DeLong >>> Cc: arin-ppml at arin.net >>> Subject: Re: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois >>> Accurate >>> >>> On 5/19/2011 12:05 PM, Owen DeLong wrote: >>> > It was not intended as such and I apologize if it came across that >>> > way. My point is that your policy >>> > would serve the interest of a select few well capitalized >>> > organizations significantly better than >>> > the interests of the overall community. >>> >>> If "a select few well capitalized organizations" are going to corner the >>> market on space, doesn't that require them to purchase the maximum >>> amount of space from existing holders at fairly high prices? >>> >>> That might serve the *financial* interests of the overall community >>> better than policies where the number of buyers is limited by needs >>> assessment. >>> >>> It also provides existing holders with more cash to use for their IPv6 >>> deployments. >>> >>> Matthew Kaufman >>> _______________________________________________ >> >> I am a relatively small time operator. It does not benefit me one whit if the big boys buy IP's from the big boys. It might keep me from getting IP's if/when I need them. >> >> I am part of the overall community. >> >> We are managing policy for the community, not just for the top ten ISP's or for a few traders who want to organize a market to make some quick cash. Let's keep the small business and non-profit orgs in mind. This is not all about the almighty dollar and how to get more of them. >> >> Kevin >> >> _______________________________________________ >> 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 19 19:00:41 2011 From: owen at delong.com (Owen DeLong) Date: Thu, 19 May 2011 16:00:41 -0700 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate In-Reply-To: <4DD58B38.206@matthew.at> References: <4DCFDB5C64DD4F738B65AB82D36B629D@mike><15F92ECD-2BE5-48F2-B65A-9A9D39B98F5 4@delong.com><0829B106605C4FE8B189DB2E56C69615@mike><8FB24038-B813-4DE0-91DD-56EDAD31BC03@delong.com><36A3A11C7EDF413C9E2EC07FD 0C122E0@mike> <8F23AB4955E3404393B1E03831C91054@mike> <6397CBB3-8145-43E7-8288-132F19B89E3F@delong.com> <4DD56EBB.70102@matthew.at> <5CABD084-E16C-4FA1-84E1-E5CA9F899144@delong.com> <4DD58B38.206@matthew.at> Message-ID: On May 19, 2011, at 2:27 PM, Matthew Kaufman wrote: > On 5/19/2011 2:21 PM, Owen DeLong wrote: >> >> The number of buyers with need will >> exceed the available address space. > > 1) You can't prove that, and, I can, actually. The available IPv4 space that could end up on a transfer market is bounded by those addresses not currently in use. As such, the rather limited supply is well known. The pool of buyers is known to be monotonically increasing and ARIN's average issuance of ~190,000 IPv4 /24s each year by ARIN would indicate an annual market demand for 25% of the maximum possible pool from which to develop such a market (roughly 12 /8s) Therefore, even if we assume that all possible addresses will come on the market with your policy, the supply will be gone in 4 years or less. Any churn beyond that would leave a need-gap behind unless it is the result of successful abandonment of IPv4. At the point where organizations can begin successful abandonment of IPv4 altogether, the market will invariably collapse anyway. > 2) Even if that's true, adding buyers without need will increase demand and thus increase revenue for the sellers > You say that as if it is a good thing. In fact, that is the very crux of the problem with this policy. It will drive up the price of addresses for no purpose of benefit to the community. Owen From matthew at matthew.at Thu May 19 19:03:00 2011 From: matthew at matthew.at (Matthew Kaufman) Date: Thu, 19 May 2011 16:03:00 -0700 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate In-Reply-To: References: <4DCFDB5C64DD4F738B65AB82D36B629D@mike><15F92ECD-2BE5-48F2-B65A-9A9D39B98F5 4@delong.com><0829B106605C4FE8B189DB2E56C69615@mike><8FB24038-B813-4DE0-91DD-56EDAD31BC03@delong.com><36A3A11C7EDF413C9E2EC07FD 0C122E0@mike> <8F23AB4955E3404393B1E03831C91054@mike> <6397CBB3-8145-43E7-8288-132F19B89E3F@delong.com> <4DD56EBB.70102@matthew.at> <5CABD084-E16C-4FA1-84E1-E5CA9F899144@delong.com> <4DD58B38.206@matthew.at> Message-ID: <4DD5A1A4.6070002@matthew.at> On 5/19/2011 4:00 PM, Owen DeLong wrote: > > You say that as if it is a good thing. In fact, that is the very crux of the problem with this policy. It will > drive up the price of addresses for no purpose of benefit to the community. Actually if you're right there *is* a benefit to the community, just one that you've chosen to not recognize. Note that the community includes potential buyers *and* the sellers. Matthew Kaufman From mike at nationwideinc.com Thu May 19 19:10:13 2011 From: mike at nationwideinc.com (Mike Burns) Date: Thu, 19 May 2011 19:10:13 -0400 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate References: <4DCFDB5C64DD4F738B65AB82D36B629D@mike> <15F92ECD-2BE5-48F2-B65A-9A9D39B98F54@delong.com> <0829B106605C4FE8B189DB2E56C69615@mike> <51506A06-D2EE-4A0D-B92B-781662094A1C@eyeconomics.com> <0CCB8AB89D144E89872AF0D635E95497@mike> <31B8F43F2E3545D4BB04061A0510715E@mike> Message-ID: Hi Blake, It's not about a limit, though the above limit is ludicrously high. What benefit to the community does IP space sitting with some broker give the community post run-out? Even just a /24 of space just sitting there is a complete waste of resources that could be better used elsewhere. The limit was suggested by another, and it's clearly too small an amount to hope to corner or manipulate a market. I am perfectly OK with existing space sitting with someone who no longer needs it waiting to be sold. I think it is a completely unnecessary waste of resources to allow someone to purchase said space that is not planning on *using* it. What difference does it make if space is sitting in a broker's inventory or the inventory of ARIN's STLS? What about the many other examples I gave where the current needs requirement would not be met? Like temporary use, emergency suppliers, lessors, or those with planning horizons longer than ARIIN dictat? Be a broker if you want, and make a site like EBAY or something, proxy transfer if you really want to be aggressive, but I just don't see the use of letting space sit with a buyer who only intends to try to profit from speculation, because that is the only possible justification for removing needs is speculation, wether its your overly long planning period, or some other equivalent, its still speculation of a limited resource to bring you profit at the expense of the community. -Blake The community would be free to buy and sell addresses without the added expense of trying to meet ARIN's needs requirements, which are subject to change. The other provisions of my proposal, which preclude ARIN utilization audits, would actually work to bring addresses off the sidelines by relieving sellers of the threat of an ARIN review should they seek to transfer some of their addresses. And you keep saying brokers want to keep addresses on the sidelines. To me a broker wants to increase sales to increase his commissions. That is very different from a hoarder or speculator. Regards, Mike -------------- next part -------------- An HTML attachment was scrubbed... URL: From owen at delong.com Thu May 19 19:08:05 2011 From: owen at delong.com (Owen DeLong) Date: Thu, 19 May 2011 16:08:05 -0700 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate In-Reply-To: <0CCB8AB89D144E89872AF0D635E95497@mike> References: <4DCFDB5C64DD4F738B65AB82D36B629D@mike> <15F92ECD-2BE5-48F2-B65A-9A9D39B98F54@delong.com> <0829B106605C4FE8B189DB2E56C69615@mike> <51506A06-D2EE-4A0D-B92B-781662094A1C@eyeconomics.com> <0CCB8AB89D144E89872AF0D635E95497@mike> Message-ID: <38F7CA20-FF84-46C5-9FC1-AC0B8B95E52F@delong.com> > > You suggested that the historical experience of the DNS registry was applicable, but I still have not seen an apples-to-apples comparison worthy of providing insights. For the DNS registry to inform us, we would have to compare an experience of for-pay DNS registries *with a needs test* to for-pay DNS registries *without a needs test*. > That is available. The DNS administered for a fee by NSI retained the needs basis for several months and there was no descent into chaos observed. The descent into madness occurred when WIPO got involved and the UDRP started developing. It was about this time that the needs-basis aspect of DNS administration was also abandoned as part of the efforts by WIPO to make domain names part of the trademark namespace(s). Owen >> Or did you really mean that historical observations that seem to flatter your argument are relevant, but observations that raise doubts are not? > > No. > > Regards, > Mike > > > > > > TV > > [1] The gradual diffusion of BGP during this period is recorded in some detail in the IETF's old "Internet Monthly Report" series (1991-1998): ftp://ftp.rfc-editor.org/in-notes/museum/imr/. > Additional good sources on both the state of EGP/BGP(x) deployment and concurrent thoughts about addressing management include the IETF meeting minutes for the area.operations, area.routing, bgpdepl, tacit, ale, cidrd, idr, and piara BoFs/working groups. > > [2] Described here: http://www.aarnet.edu.au/News/2009/11/26/AARNet-salutes-20th-anniversary-of-the-Internet-in-Australia.aspx > The episode in question is detailed in Chapter 4, p. 48 -- which is available online at > http://www.aarnet.edu.au/library/AARNet_20YearBook_Chapter4 > > [3] http://tools.ietf.org/html/rfc1744 > From ikiris at gmail.com Thu May 19 19:17:43 2011 From: ikiris at gmail.com (Blake Dunlap) Date: Thu, 19 May 2011 18:17:43 -0500 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate In-Reply-To: References: <4DCFDB5C64DD4F738B65AB82D36B629D@mike> <15F92ECD-2BE5-48F2-B65A-9A9D39B98F54@delong.com> <0829B106605C4FE8B189DB2E56C69615@mike> <51506A06-D2EE-4A0D-B92B-781662094A1C@eyeconomics.com> <0CCB8AB89D144E89872AF0D635E95497@mike> <31B8F43F2E3545D4BB04061A0510715E@mike> Message-ID: On Thu, May 19, 2011 at 18:10, Mike Burns wrote: > What difference does it make if space is sitting in a broker's inventory > or the inventory of ARIN's STLS? What about the many other examples I gave > where the current needs requirement would not be met? Like temporary use, > emergency suppliers, lessors, or those with planning horizons longer than > ARIIN dictat? > All of these have been previously responded to, just because you don't like the answer doesn't mean it hasn't already been answered. As a recap, every example you have listed above is a negative for the community for the benefit of one actor, or completely unrelated to what you are trying to push in this proposal. -Blake -------------- next part -------------- An HTML attachment was scrubbed... URL: From owen at delong.com Thu May 19 19:19:12 2011 From: owen at delong.com (Owen DeLong) Date: Thu, 19 May 2011 16:19:12 -0700 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate In-Reply-To: <4DD59979.70109@matthew.at> References: <4DCFDB5C64DD4F738B65AB82D36B629D@mike> <15F92ECD-2BE5-48F2-B65A-9A9D39B98F54@delong.com> <0829B106605C4FE8B189DB2E56C69615@mike> <51506A06-D2EE-4A0D-B92B-781662094A1C@eyeconomics.com> <0CCB8AB89D144E89872AF0D635E95497@mike> <31B8F43F2E3545D4BB04061A0510715E@mike> <4DD59607.4020203@matthew.at> <4DD59979.70109@matthew.at> Message-ID: <04E19261-C112-4F13-AED2-3E85C198FC6F@delong.com> On May 19, 2011, at 3:28 PM, Matthew Kaufman wrote: > On 5/19/2011 3:21 PM, Blake Dunlap wrote: >> >> On Thu, May 19, 2011 at 17:13, Matthew Kaufman wrote: >> On 5/19/2011 2:59 PM, Blake Dunlap wrote: >> >> >> >> its still speculation of a limited resource to bring you profit at the expense of the community. >> >> Please remember that not all speculation of limited resources, even if it brings the speculator profit from time to time, is at the expense of the community. Oftentimes it actually provides benefits to the community (market liquidity, price stability, etc.) >> >> Matthew Kaufman >> >> Price stability does not require a middle man to hold assets, they only need to be listed, but I will give you liquidity for *sellers* absolutely. >> >> Do we really need such liquidity for *sellers* in IPv4? Is there even use for such? > > > Sure. If you need space in 6 months, but not now, wouldn't it be nice to get it from someone who'd worked with a middleman today to start a 5-month project to free up space and transfer it to the middleman... rather than having to wait those 5 months yourself? > This presumes that without the middle-man, the project wouldn't have begun out of a desire to make the space available for sale. If you claim to believe in market forces, then, the speculator brings no value here because market forces would drive the person to begin the project early in order to satisfy the expected demand as soon as possible. Owen -------------- next part -------------- An HTML attachment was scrubbed... URL: From owen at delong.com Thu May 19 19:23:06 2011 From: owen at delong.com (Owen DeLong) Date: Thu, 19 May 2011 16:23:06 -0700 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate In-Reply-To: <4DD5A1A4.6070002@matthew.at> References: <4DCFDB5C64DD4F738B65AB82D36B629D@mike><15F92ECD-2BE5-48F2-B65A-9A9D39B98F5 4@delong.com><0829B106605C4FE8B189DB2E56C69615@mike><8FB24038-B813-4DE0-91DD-56EDAD31BC03@delong.com><36A3A11C7EDF413C9E2EC07FD 0C122E0@mike> <8F23AB4955E3404393B1E03831C91054@mike> <6397CBB3-8145-43E7-8288-132F19B89E3F@delong.com> <4DD56EBB.70102@matthew.at> <5CABD084-E16C-4FA1-84E1-E5CA9F899144@delong.com> <4DD58B38.206@matthew.at> <4DD5A1A4.6070002@matthew.at> Message-ID: On May 19, 2011, at 4:03 PM, Matthew Kaufman wrote: > On 5/19/2011 4:00 PM, Owen DeLong wrote: >> >> You say that as if it is a good thing. In fact, that is the very crux of the problem with this policy. It will >> drive up the price of addresses for no purpose of benefit to the community. > > Actually if you're right there *is* a benefit to the community, just one that you've chosen to not recognize. > > Note that the community includes potential buyers *and* the sellers. > Yes, and benefiting half of the community (or actually less than half of the community) while penalizing or negatively impacting a group which, by definition, is at least as large is not of net benefit to the community. It is, at best break-even, and, at worst, destructive. A benefit to a small fraction of the community != a benefit to the community. Owen From mike at nationwideinc.com Thu May 19 19:31:41 2011 From: mike at nationwideinc.com (Mike Burns) Date: Thu, 19 May 2011 19:31:41 -0400 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate References: <4DCFDB5C64DD4F738B65AB82D36B629D@mike> <15F92ECD-2BE5-48F2-B65A-9A9D39B98F54@delong.com> <0829B106605C4FE8B189DB2E56C69615@mike> <51506A06-D2EE-4A0D-B92B-781662094A1C@eyeconomics.com> <0CCB8AB89D144E89872AF0D635E95497@mike> <2691B7B9-1F3C-403C-B4E8-5B82BED0E191@eyeconomics.com> Message-ID: <454BB1826E7B4F2BB3A68BE1DD86A756@video> >> Can you provide us with a comparable measure of the number of old address holders who have not responded to opportunity afforded by the 8.2 change? > > No. > >> If possible, please break down the number into two groups -- those who are on the fence and holding out fin hopes of additional blandishments and concessions, and those whose philosophical or >commercial priorities preclude registration regardless of the side payments. > > I have never met anybody whose philosophical or commercial priorites preclude registration. I imagine that many of those who have not done the 8.2 transfer have failed to see any utility in doing so. > Besides, the ARIN language never required it, it only says "ARIN will consider requests for transfers." And since the addresses continued to be routed without notifying ARIN of the mergers and acquisitions, many failed to apply. Also, for legacy holders, an 8.2 transfer meant having to sign an RSA, I think, which was a disincentive. If you are uncomfortable with the second half of of the question, then a simple accounting of all of the old address holders who have not responded yet will suffice. To quote what you deleted, for the sake of clarity: "I have argued that the uptick in 8.2 transfer requests is in response to natural market forces at work. Prices go up and owners of address block control take steps to ensure accurate registration." Without some means of (at minimum) benchmarking the relative size of (or anything else about) that "slight uptick," your interpretation of its causes and relevance are completely subjective. Tom, how could I have any of the information you are soliciting? I merely held that I think the uptick in processing of 8.2 transfers for historical mergers and acquisitions that John Curran mentioned is evidence of the increasing desire to have addresses properly registered as the value of those assets increases and replacement addresses are no longer available from the free pool. And that was in response to your assertion that it is the needs requirement which increases Whois accuracy. My point was, and is, that there is a logical reason for address holders to desire registration, and that they would naturally do so if not impeded by the necessity of passing ARIN's needs analysis. Yes, I never held that this interpretation was more than my subjective opinion backed up by an understanding that registration is the clearest means of establishing ownnership rights to control of these assets, and as those rights become increasingly valuable, owners will seek accurate registration. >> Having enjoyed the extremely lopsided privilege of discussing broadly related matters with Geoff semi-regularly between the years 2000~2009, I wholeheartedly agree that he is one of the world's >foremost experts on BGP. However, with all due respect to the man, Geoff's views about the relative merits of market-based vs. RIR-style need/capability-based number resource allocation were formed >*before* BGP was widely deployed [1]. To my knowledge, the first concrete expression of those views took place in mid-1994, as documented for example in the recently published 20-year >retrospective on AARNET and the early days of the Internet in Australia [2]. The second concrete expression of those views AFAIK is RFC 1744 (December 1994), which I (completely subjectively) >interpret as a somewhat bitter personal reflection on the results of the first experience [3]. > >> Regardless of whether or not that interpretation is valid, contemporaneous Australian press accounts indicate that AARNet's acquisition by Telstra was announced on January 7 1997 and implemented on >July 1, and that Geoff had assumed the title of Telstra Internet's Technical Manager on or around the same time. After that he continued to advocate the same position, e.g., in the context of the IETF >"Pricing for Internet Addresses and Routing Advertisements" (piara) BoF. > >> So while Geoff's world-class expertise in BGP is unquestionable, his seemingly consistent preference for market-based vs. need/capability-based resource management must be based on something else. > > I never claimed that Geoff Huston, whom I have never met, did not have a preference for market-based solutions, only that he did not view the danger of disaggregation as a reason to have needs requirements for transfers. Why are you attempting to change the subject to disaggregation? I thought your proposal was based on claims about the best way to maintain whois accuracy? I'm not changing the subject to disaggregation, in fact I mentioned that this was one of the points noted in opposition, please reread the entire thread from this morning. > Unless you are implying that his preference for market-based solutions has somehow overridden his BGP expertise, my point stands. I decline to speculate about Geoff's innermost thoughts on this matter. Geoff has a vast reserve of hard experience dealing with market mechanisms in the BGP world, but even he hasn't advocated pure free-market routing at all places and times. But then my experience discussing matters like these with people all over the world for the last decade or so has left the impression that world-class expertise in BGP is perfectly compatible with radically opposing, mutually incompatible views -- not only concerning the best way to maintain a protocol number resource registry, but even about the proper way to manage global interdomain routing. Opinions on the two subjects seem to be quite independent and unrelated, at least in most people. Of course there is undeniably a subset of people (in fact, one that's is quite well represented in this industry) who believe that unrestricted market mechanisms represent the ideal solution for every problem at all times and places. I find it a lot easier to assume that you fall within that group -- esp. since you have more-or-less self-identified yourself as a member. I do support voluntary markets as optimal mechanisms for resource allocation. But Geoff was brought into this only to demonstrate that somebody with more BGP expertise than me thought that the threat of disaggregation was not greater than the threat to Whois represented by needs requirements for transfers. >> Besides, wasn't it you who just recently rejected (my) suggestion that observations based on the historical experience(s) of other registries could provide insight on the merits of your proposal? > > You suggested that the historical experience of the DNS registry was applicable, but I still have not seen an apples-to-apples comparison worthy of providing insights. For the DNS registry to inform us, we would have to compare an experience of for-pay DNS registries *with a needs test* to for-pay DNS registries *without a needs test*. Okay, I concede your point. And based on the same logic, I suggest that this proposal should be abandoned on the grounds that no one can claim to have any relevant "apples-to-apples" experience, or to have have any defensible "apples-to-apples" basis for assuming that this proposal has any chance of making it easier to maintain whois accuracy going forward. My logic says that analogies have to be apt to be informative. Your logic says that nothing new can be proposed. And I point again to the unusual aspects of the MS/Nortel deal as evidence that had the needs requirement not very fortunately aligned with the prior facts of the sale, the transaction would likely have occurred and led to Whois inaccuracy. Care to address the fact that of the universe of publicly accessible data on transfers, 100% of the deals required fortuitous needs findings in order to maintain Whois accuracy? And also please consider whether you think it legal for a legacy holder to transfer addresses without being subject to ARIN's needs requirements, and by transfer I mean pay money for and then route, NOT having ARIN update Whois. My reading of the bankruptcy docs showed the judge viewed Nortel as having the exclusive right to transfer the addresses. Per this article, it's not only Mike Burns who feels that all ARIN can do with these transactions is withhold Whois updates. http://www.networkworld.com/news/2011/051111-nortel-ipv4-sale.html Regards, Mike TV >> Or did you really mean that historical observations that seem to flatter your argument are relevant, but observations that raise doubts are not? > > No. > > Regards, > Mike > > > > > > TV > > [1] The gradual diffusion of BGP during this period is recorded in some detail in the IETF's old "Internet Monthly Report" series (1991-1998): ftp://ftp.rfc-editor.org/in-notes/museum/imr/. > Additional good sources on both the state of EGP/BGP(x) deployment and concurrent thoughts about addressing management include the IETF meeting minutes for the area.operations, area.routing, bgpdepl, tacit, ale, cidrd, idr, and piara BoFs/working groups. > > [2] Described here: http://www.aarnet.edu.au/News/2009/11/26/AARNet-salutes-20th-anniversary-of-the-Internet-in-Australia.aspx > The episode in question is detailed in Chapter 4, p. 48 -- which is available online at > http://www.aarnet.edu.au/library/AARNet_20YearBook_Chapter4 > > [3] http://tools.ietf.org/html/rfc1744 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From springer at inlandnet.com Thu May 19 19:31:57 2011 From: springer at inlandnet.com (John Springer) Date: Thu, 19 May 2011 16:31:57 -0700 (PDT) Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate In-Reply-To: <36A3A11C7EDF413C9E2EC07FD0C122E0@mike> References: <4DCFDB5C64DD4F738B65AB82D36B629D@mike> <15F92ECD-2BE5-48F2-B65A-9A9D39B98F54@delong.com> <0829B106605C4FE8B189DB2E56C69615@mike> <8FB24038-B813-4DE0-91DD-56EDAD31BC03@delong.com> <36A3A11C7EDF413C9E2EC07FD0C122E0@mike> Message-ID: <20110519141211.V77468@mail.inlandnet.com> Hi Mike, Not ready to opine on the proposal yet but I am going to quote and reply to one section of this particular post. Down below. On Thu, 19 May 2011, Mike Burns wrote: > As to Microsoft planning leading them to purchasing the same exact need as ARIN's particular application of its policies at the time of the transaction? > Please. > Remember that Microsoft was an arms-length negotiator who was solicited by the address broker in the deal along with 80 other companies. > So Microsoft's planning was so excellent that they could find the exact amount of addresses they needed in the form of the very first public sale of legacy addresses ever recorded? > That's believable! > And their excellent planning staff, whose decision so exactly matched ARIN's ex-post-facto analysis, failed to inform management that they could save $7.5 million by getting them directly from ARIN? This is, IMO, of limited utility. To reiterate, the question of whether or not the MS/NN transfer followed ARIN policy was, IIRC, asked by several and answered rather authoritatively by Curran. The actual detailed facts of the matter are unlikely to be known. Or perhaps, as you point out, there is an NDA with a time limit. Are the detailed facts of the matter so critical that we should wait until they are knowable before deciding on this policy proposal? If not, further assertions such as the above can be true as the night and still be logically useless when trying to refute something that is so completely non-falsifiable. Continuing to put forward such comments only serves to shift attention from otherwise mostly logical and considerable remarks to ones that are neither. Just sayin'. John Springer From mike at nationwideinc.com Thu May 19 19:48:53 2011 From: mike at nationwideinc.com (Mike Burns) Date: Thu, 19 May 2011 19:48:53 -0400 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate References: <4DCFDB5C64DD4F738B65AB82D36B629D@mike><15F92ECD-2BE5-48F2-B65A-9A9D39B98F5 4@delong.com><0829B106605C4FE8B189DB2E56C69615@mike><8FB24038-B813-4DE0-91DD-56EDAD31BC03@delong.com><36A3A11C7EDF413C9E2EC07FD 0C122E0@mike> <8F23AB4955E3404393B1E03831C91054@mike> <6397CBB3-8145-43E7-8288-132F19B89E3F@delong.com> <4DD56EBB.70102@matthew.at> <5CABD084-E16C-4FA1-84E1-E5CA9F899144@delong.com> <4DD58B38.206@matthew.at> Message-ID: Hi Owen, jumping in here, > On 5/19/2011 2:21 PM, Owen DeLong wrote: >> >>> The number of buyers with need will >>> exceed the available address space. > >> 1) You can't prove that, and, >>I can, actually. The available IPv4 space that could end up on a transfer >>market is bounded >>by those addresses not currently in use. As such, the rather limited >>supply is well known. Except you don't have any information on how efficiently those addresses are used. It could very well be that a great deal more efficiency can be found, freeing up more than the unrouted address space. Like those unfortunate souls who will find themselves behind CGN will likely enrich their ISP, who can sell as many addresses into the market as he can without losing too many customers who demand non-CGN access. Or even the deployment of plain old NAT could free up addresses which are currnently being advertised now for sale later. >The pool of buyers is known to be monotonically increasing and ARIN's >average issuance >of ~190,000 IPv4 /24s each year by ARIN would indicate an annual market >demand for 25% >of the maximum possible pool from which to develop such a market (roughly >12 /8s) >Therefore, even if we assume that all possible addresses will come on the >market with >your policy, the supply will be gone in 4 years or less. Any churn beyond >that would leave >a need-gap behind unless it is the result of successful abandonment of >IPv4. At the point >where organizations can begin successful abandonment of IPv4 altogether, >the market >will invariably collapse anyway. And you believe this and still think there is a danger from speculators? When the market is at most 4 years in duration and then subject to collapse due to IPv6? Regards, Mike From mike at nationwideinc.com Thu May 19 19:52:42 2011 From: mike at nationwideinc.com (Mike Burns) Date: Thu, 19 May 2011 19:52:42 -0400 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate References: <4DCFDB5C64DD4F738B65AB82D36B629D@mike> <15F92ECD-2BE5-48F2-B65A-9A9D39B98F54@delong.com> <0829B106605C4FE8B189DB2E56C69615@mike> <51506A06-D2EE-4A0D-B92B-781662094A1C@eyeconomics.com> <0CCB8AB89D144E89872AF0D635E95497@mike> <38F7CA20-FF84-46C5-9FC1-AC0B8B95E52F@delong.com> Message-ID: <4F5AB686C7C54D8E8836A8199CFE96A7@video> Hi Owen, > > You suggested that the historical experience of the DNS registry was > applicable, but I still have not seen an apples-to-apples comparison > worthy of providing insights. For the DNS registry to inform us, we would > have to compare an experience of for-pay DNS registries *with a needs > test* to for-pay DNS registries *without a needs test*. > That is available. The DNS administered for a fee by NSI retained the needs basis for several months and there was no descent into chaos observed. The descent into madness occurred when WIPO got involved and the UDRP started developing. It was about this time that the needs-basis aspect of DNS administration was also abandoned as part of the efforts by WIPO to make domain names part of the trademark namespace(s). Owen Right, so there were many changes happening in the DNS transition that make it impossible to isolate the effects of removing needs requirements on the accuracy of whois. Such as increasing registrations by three orders of magnitude. Regards, Mike From mike at nationwideinc.com Thu May 19 19:56:34 2011 From: mike at nationwideinc.com (Mike Burns) Date: Thu, 19 May 2011 19:56:34 -0400 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate References: <4DCFDB5C64DD4F738B65AB82D36B629D@mike> <15F92ECD-2BE5-48F2-B65A-9A9D39B98F54@delong.com> <0829B106605C4FE8B189DB2E56C69615@mike> <51506A06-D2EE-4A0D-B92B-781662094A1C@eyeconomics.com> <0CCB8AB89D144E89872AF0D635E95497@mike> <31B8F43F2E3545D4BB04061A0510715E@mike> Message-ID: Blake, Is having an emergency supplier of IP addresses a negative for the community? Is having a temporary supplier of IP addresses a negative for the community? Is having a supplier for long-range plans a negative for the community? Is this what stewarship has become, having a few elites making these kinds of decisions about which businesses the community finds positive or negative? What's wrong with letting the bad ones go broke and the good ones succeed as measures of their positive or negative attributes? Regards, Mike ----- Original Message ----- From: Blake Dunlap To: Mike Burns Cc: Tom Vest ; arin-ppml at arin.net Sent: Thursday, May 19, 2011 7:17 PM Subject: Re: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate On Thu, May 19, 2011 at 18:10, Mike Burns wrote: What difference does it make if space is sitting in a broker's inventory or the inventory of ARIN's STLS? What about the many other examples I gave where the current needs requirement would not be met? Like temporary use, emergency suppliers, lessors, or those with planning horizons longer than ARIIN dictat? All of these have been previously responded to, just because you don't like the answer doesn't mean it hasn't already been answered. As a recap, every example you have listed above is a negative for the community for the benefit of one actor, or completely unrelated to what you are trying to push in this proposal. -Blake -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthew at matthew.at Thu May 19 19:59:57 2011 From: matthew at matthew.at (Matthew Kaufman) Date: Thu, 19 May 2011 16:59:57 -0700 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate In-Reply-To: References: <4DCFDB5C64DD4F738B65AB82D36B629D@mike><15F92ECD-2BE5-48F2-B65A-9A9D39B98F5 4@delong.com><0829B106605C4FE8B189DB2E56C69615@mike><8FB24038-B813-4DE0-91DD-56EDAD31BC03@delong.com><36A3A11C7EDF413C9E2EC07FD 0C122E0@mike> <8F23AB4955E3404393B1E03831C91054@mike> <6397CBB3-8145-43E7-8288-132F19B89E3F@delong.com> <4DD56EBB.70102@matthew.at> <5CABD084-E16C-4FA1-84E1-E5CA9F899144@delong.com> <4DD58B38.206@matthew.at> Message-ID: <4DD5AEFD.3060901@matthew.at> On 5/19/2011 4:48 PM, Mike Burns wrote: > > And you believe this and still think there is a danger from > speculators? When the market is at most 4 years in duration and then > subject to collapse due to IPv6? That's really the best question. Who are the speculators that we're worried about who have enough cash to actually affect the price of IP address space and availability *and* who are stupid enough to do that when they know a collapse is coming soon? Also, if these speculators are really so bad, won't all the altruistic sellers (some of whom are represented in this discussion, no doubt) simply refuse to sell to them at *any* price, but have nice low prices for non-profits and other good causes that need space? Matthew Kaufman From mike at nationwideinc.com Thu May 19 20:06:17 2011 From: mike at nationwideinc.com (Mike Burns) Date: Thu, 19 May 2011 20:06:17 -0400 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate References: <4DCFDB5C64DD4F738B65AB82D36B629D@mike> <15F92ECD-2BE5-48F2-B65A-9A9D39B98F54@delong.com> <0829B106605C4FE8B189DB2E56C69615@mike> <8FB24038-B813-4DE0-91DD-56EDAD31BC03@delong.com> <36A3A11C7EDF413C9E2EC07FD0C122E0@mike> <20110519141211.V77468@mail.inlandnet.com> Message-ID: Hi John, I am being assailed with claims that very very few transactions will occur which will not meet the ARIN needs requirements. And requests for proof that these transactions have, and will, occur. The facts of the matter have been laid out, and all I said was that this alignment with ex-post-facto need determination and the already negotiated sale was fortuitous. http://www.networkworld.com/news/2011/051111-nortel-ipv4-sale.html Per the article above, I am not by any means alone in my perception that the MS/Nortel deal very easily could have occurred outside ARIN's purview had not the crucial factor of the needs analysis been met. Nothing that I said in the paragraph you reference is contrary to John Curran's answer about the MS/Nortel deal, nor does it involve NDA information. The deal was made and negotiated prior to ARIN's involvement, and should other such deals occur, if their needs requirement is not recognized by ARIN, the deal goes down off the books. And I reiterate that ARIN head Plzak declared that ARIN does not control legacy addresses. That means to me at the very least that legacy deals can be done without notifying ARIN, and if notifying ARIN requires the transactors to undergo a needs test, and not notifying ARIN has little cost in terms of routabilty, then the transaction will occur and the community will be in the dark. Regards, Mike ----- Original Message ----- From: "John Springer" To: "Mike Burns" Cc: "Owen DeLong" ; Sent: Thursday, May 19, 2011 7:31 PM Subject: Re: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate > Hi Mike, > > Not ready to opine on the proposal yet but I am going to quote and reply > to one section of this particular post. Down below. > > On Thu, 19 May 2011, Mike Burns wrote: > >> As to Microsoft planning leading them to purchasing the same exact need >> as ARIN's particular application of its policies at the time of the >> transaction? >> Please. >> Remember that Microsoft was an arms-length negotiator who was solicited >> by the address broker in the deal along with 80 other companies. >> So Microsoft's planning was so excellent that they could find the exact >> amount of addresses they needed in the form of the very first public sale >> of legacy addresses ever recorded? >> That's believable! >> And their excellent planning staff, whose decision so exactly matched >> ARIN's ex-post-facto analysis, failed to inform management that they >> could save $7.5 million by getting them directly from ARIN? > > This is, IMO, of limited utility. To reiterate, the question of whether or > not the MS/NN transfer followed ARIN policy was, IIRC, asked by several > and answered rather authoritatively by Curran. The actual detailed facts > of the matter are unlikely to be known. Or perhaps, as you point out, > there is an NDA with a time limit. Are the detailed facts of the matter so > critical that we should wait until they are knowable before deciding on > this policy proposal? If not, further assertions such as the above can be > true as the night and still be logically useless when trying to refute > something that is so completely non-falsifiable. Continuing to put forward > such comments only serves to shift attention from otherwise mostly logical > and considerable remarks to ones that are neither. > > Just sayin'. > > John Springer From ikiris at gmail.com Thu May 19 20:07:01 2011 From: ikiris at gmail.com (Blake Dunlap) Date: Thu, 19 May 2011 19:07:01 -0500 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate In-Reply-To: References: <4DCFDB5C64DD4F738B65AB82D36B629D@mike> <15F92ECD-2BE5-48F2-B65A-9A9D39B98F54@delong.com> <0829B106605C4FE8B189DB2E56C69615@mike> <51506A06-D2EE-4A0D-B92B-781662094A1C@eyeconomics.com> <0CCB8AB89D144E89872AF0D635E95497@mike> <31B8F43F2E3545D4BB04061A0510715E@mike> Message-ID: On Thu, May 19, 2011 at 18:56, Mike Burns wrote: > Blake, > > Is having an emergency supplier of IP addresses a negative for the > community? > Yes, they are by definition holding perfectly good space that could go to use now which is out of play, on the chance they will be the only seller and can make substansial money by being the only option. > Is having a temporary supplier of IP addresses a negative for the > community? > This is not prevented now by community policy, thus it was in the second category, the one that is completely unrelated to this proposal. > Is having a supplier for long-range plans a negative for the community? > For the third time yes, for the same reasons as the previous two times. It takes resources out of play *now* that could go to parties that need it *now* for the *future* *possible* benifit of one party, to the detriment of every other party *now*. > Is this what stewarship has become, having a few elites making these kinds > of decisions about which businesses the community finds positive or > negative? > (Rant removed) I'm not going to even comment on this. > What's wrong with letting the bad ones go broke and the good ones succeed > as measures of their positive or negative attributes? > What are you even talking about here? -Blake -------------- next part -------------- An HTML attachment was scrubbed... URL: From Niel.Harper at firstcaribbeanbank.com Thu May 19 20:16:18 2011 From: Niel.Harper at firstcaribbeanbank.com (Harper, Niel) Date: Thu, 19 May 2011 20:16:18 -0400 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate Message-ID: <53A7FE6DF417814CB6BB115E275463E32B63B501@fcbds_amsx1.WI.FCIB.com> -------------------------- Sent from my BlackBerry Handheld Device Niel Harper Head of Telecommunications FirstCaribbean International Bank "Internet communications are not secure and therefore FirstCaribbean International Bank does not accept legal responsibility for the contents of this message. Although FirstCaribbean International Bank operates anti-virus programmes, it does not accept responsibility for any damage whatsoever that is caused by viruses being passed. Any views or opinions presented are solely those of the author and do not necessarily represent those of FirstCaribbean International Bank. If this email has not reached the intended recipient, please disregard and delete the message." ----- Original Message ----- From: arin-ppml-bounces at arin.net To: Mike Burns Cc: arin-ppml at arin.net Sent: Thu May 19 19:59:57 2011 Subject: Re: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate On 5/19/2011 4:48 PM, Mike Burns wrote: > > And you believe this and still think there is a danger from > speculators? When the market is at most 4 years in duration and then > subject to collapse due to IPv6? That's really the best question. Who are the speculators that we're worried about who have enough cash to actually affect the price of IP address space and availability *and* who are stupid enough to do that when they know a collapse is coming soon? Also, if these speculators are really so bad, won't all the altruistic sellers (some of whom are represented in this discussion, no doubt) simply refuse to sell to them at *any* price, but have nice low prices for non-profits and other good causes that need space? Matthew Kaufman _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. ----------------------------------------- "Internet communications are not secure and therefore FirstCaribbean International Bank does not accept legal responsibility for the contents of this message. Although FirstCaribbean International Bank operates anti-virus programmes, it does not accept responsibility for any damage whatsoever that is caused by viruses being passed. Any views or opinions presented are solely those of the author and do not necessarily represent those of FirstCaribbean International Bank. If this email has not reached the intended recipient, please disregard and delete the message." -------------- next part -------------- An HTML attachment was scrubbed... URL: From rbf+arin-ppml at panix.com Thu May 19 20:42:57 2011 From: rbf+arin-ppml at panix.com (Brett Frankenberger) Date: Thu, 19 May 2011 19:42:57 -0500 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate In-Reply-To: <31B8F43F2E3545D4BB04061A0510715E@mike> References: <4DCFDB5C64DD4F738B65AB82D36B629D@mike> <15F92ECD-2BE5-48F2-B65A-9A9D39B98F54@delong.com> <0829B106605C4FE8B189DB2E56C69615@mike> <51506A06-D2EE-4A0D-B92B-781662094A1C@eyeconomics.com> <0CCB8AB89D144E89872AF0D635E95497@mike> <31B8F43F2E3545D4BB04061A0510715E@mike> Message-ID: <20110520004257.GA23891@panix.com> On Thu, May 19, 2011 at 05:49:43PM -0400, Mike Burns wrote: > Blake, > > My proposal includes a limit of /12 of needs-free transfers > specifically to prevent hoarding and market cornering. (It's a recent > addition.) I assumed it was speciifcally to create business for lawyers specializing in creating legal entities to hold address space, since someone wanting to hoard a /8 would, under your policy, need 16 different legal entities. If we assume there are going to be serious speculators involved if the needs requirement is eliminated, we would also reasonably have to assume they won't be deterred by a requirement to create a stack of entities under their control in practice, but nominally sufficiently distinct to prevent their holdings from being aggregated for the purposes of the /12 rule. In this post, I'm taking no position on the merits of transfers w/o needs justification, just pointing out that the /12 limitation is trivial to get around and is effectively a no-op. -- Brett From matthew at matthew.at Thu May 19 20:51:15 2011 From: matthew at matthew.at (Matthew Kaufman) Date: Thu, 19 May 2011 17:51:15 -0700 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate In-Reply-To: <20110520004257.GA23891@panix.com> References: <4DCFDB5C64DD4F738B65AB82D36B629D@mike> <15F92ECD-2BE5-48F2-B65A-9A9D39B98F54@delong.com> <0829B106605C4FE8B189DB2E56C69615@mike> <51506A06-D2EE-4A0D-B92B-781662094A1C@eyeconomics.com> <0CCB8AB89D144E89872AF0D635E95497@mike> <31B8F43F2E3545D4BB04061A0510715E@mike> <20110520004257.GA23891@panix.com> Message-ID: <4DD5BB03.90906@matthew.at> On 5/19/2011 5:42 PM, Brett Frankenberger wrote: > > In this post, I'm taking no position on the merits of transfers w/o > needs justification, just pointing out that the /12 limitation is > trivial to get around and is effectively a no-op. The whole needs justification to avoid speculation is effectively a no-op too. Speculators can just: 1) Buy controlling stakes in existing entities that are inefficiently using addresses today and NOT make their use more efficient unless/until they find a buyer for space at the price they want, or 2) Buy the exclusive option to trade an organization's IP address space at today's price, then charge the future price to the buyer, take the difference, and execute the transfer between the first org and the second org, never transferring the space to the speculator. ISPs that want to corner the market through hoarding can just do #1 trivially OR convince people to sell space to them in exchange for a transit arrangement such that the need is justified by the transit contract itself. Matthew Kaufman From tvest at eyeconomics.com Thu May 19 21:02:58 2011 From: tvest at eyeconomics.com (Tom Vest) Date: Thu, 19 May 2011 21:02:58 -0400 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate In-Reply-To: <454BB1826E7B4F2BB3A68BE1DD86A756@video> References: <4DCFDB5C64DD4F738B65AB82D36B629D@mike> <15F92ECD-2BE5-48F2-B65A-9A9D39B98F54@delong.com> <0829B106605C4FE8B189DB2E56C69615@mike> <51506A06-D2EE-4A0D-B92B-781662094A1C@eyeconomics.com> <0CCB8AB89D144E89872AF0D635E95497@mike> <2691B7B9-1F3C-403C-B4E8-5B82BED0E191@eyeconomics.com> <454BB1826E7B4F2BB3A68BE1DD86A756@video> Message-ID: On May 19, 2011, at 7:31 PM, Mike Burns wrote: > >> Can you provide us with a comparable measure of the number of old address holders who have not responded to opportunity afforded by the 8.2 change? > > > > No. > > > >> If possible, please break down the number into two groups -- those who are on the fence and holding out fin hopes of additional blandishments and concessions, and those whose philosophical or >commercial priorities preclude registration regardless of the side payments. > > > > I have never met anybody whose philosophical or commercial priorites preclude registration. I imagine that many of those who have not done the 8.2 transfer have failed to see any utility in doing so. > > Besides, the ARIN language never required it, it only says "ARIN will consider requests for transfers." And since the addresses continued to be routed without notifying ARIN of the mergers and acquisitions, many failed to apply. Also, for legacy holders, an 8.2 transfer meant having to sign an RSA, I think, which was a disincentive. > > If you are uncomfortable with the second half of of the question, then a simple accounting of all of the old address holders who have not responded yet will suffice. > > To quote what you deleted, for the sake of clarity: > > "I have argued that the uptick in 8.2 transfer requests is in response to natural market forces at work. Prices go up and owners of address block control take steps to ensure accurate registration." > > Without some means of (at minimum) benchmarking the relative size of (or anything else about) that "slight uptick," your interpretation of its causes and relevance are completely subjective. > Tom, how could I have any of the information you are soliciting? I merely held that I think the uptick in processing of 8.2 transfers for historical mergers and acquisitions that John Curran mentioned is evidence of the increasing desire to have addresses properly registered as the value of those assets increases and replacement addresses are no longer available from the free pool. And that was in response to your assertion that it is the needs requirement which increases Whois accuracy. My point was, and is, that there is a logical reason for address holders to desire registration, and that they would naturally do so if not impeded by the necessity of passing ARIN's needs analysis. Fair enough, you prefer to argue logic rather than facts: Please provide a negative proof that "logic" could never lead any future address user, potential address buyer, and/or potential address seller to conclude that registration would not advance their own private interests. Please provide a negative proof that "logic" could never lead any future address user, potential address buyer, and/or potential address seller to embrace "sales-friendly registration" but simultaneously reject "operationally relevant registration" (i.e., the kind that makes whois an appropriate subject of interest for community deliberation). Please provide a negative proof that "logic" will BOTH always lead all future address users, address buyers, and address sellers to self-maintain "operationally relevant registration" for themselves in perpetuity, AND that the attainment of that outcome by means of needs-free transfers could never have any unintended consequences that might be as serious or more serious than some marginal degradation of whois accuracy. > Yes, I never held that this interpretation was more than my subjective opinion backed up by an understanding that registration is the clearest means of establishing ownnership rights to control of these assets, and as those rights become increasingly valuable, owners will seek accurate registration. So you have no actual "apples-to-apples" firsthand experience to corroborate that opinion then? Perhaps someone who anticipates the possibility of buying addresses in the future but has no particular preference for registered addresses and no intention of registering purchased addresses themselves can get in touch with Mike off-list? > >> Having enjoyed the extremely lopsided privilege of discussing broadly related matters with Geoff semi-regularly between the years 2000~2009, I wholeheartedly agree that he is one of the world's >foremost experts on BGP. However, with all due respect to the man, Geoff's views about the relative merits of market-based vs. RIR-style need/capability-based number resource allocation were formed >*before* BGP was widely deployed [1]. To my knowledge, the first concrete expression of those views took place in mid-1994, as documented for example in the recently published 20-year >retrospective on AARNET and the early days of the Internet in Australia [2]. The second concrete expression of those views AFAIK is RFC 1744 (December 1994), which I (completely subjectively) >interpret as a somewhat bitter personal reflection on the results of the first experience [3]. > > > >> Regardless of whether or not that interpretation is valid, contemporaneous Australian press accounts indicate that AARNet's acquisition by Telstra was announced on January 7 1997 and implemented on >July 1, and that Geoff had assumed the title of Telstra Internet's Technical Manager on or around the same time. After that he continued to advocate the same position, e.g., in the context of the IETF >"Pricing for Internet Addresses and Routing Advertisements" (piara) BoF. > > > >> So while Geoff's world-class expertise in BGP is unquestionable, his seemingly consistent preference for market-based vs. need/capability-based resource management must be based on something else. > > > > I never claimed that Geoff Huston, whom I have never met, did not have a preference for market-based solutions, only that he did not view the danger of disaggregation as a reason to have needs requirements for transfers. > > Why are you attempting to change the subject to disaggregation? I thought your proposal was based on claims about the best way to maintain whois accuracy? > > I'm not changing the subject to disaggregation, in fact I mentioned that this was one of the points noted in opposition, please reread the entire thread from this morning. Got it -- this was a red herring. Moving on... > > Unless you are implying that his preference for market-based solutions has somehow overridden his BGP expertise, my point stands. > > I decline to speculate about Geoff's innermost thoughts on this matter. Geoff has a vast reserve of hard experience dealing with market mechanisms in the BGP world, but even he hasn't advocated pure free-market routing at all places and times. But then my experience discussing matters like these with people all over the world for the last decade or so has left the impression that world-class expertise in BGP is perfectly compatible with radically opposing, mutually incompatible views -- not only concerning the best way to maintain a protocol number resource registry, but even about the proper way to manage global interdomain routing. Opinions on the two subjects seem to be quite independent and unrelated, at least in most people. > > Of course there is undeniably a subset of people (in fact, one that's is quite well represented in this industry) who believe that unrestricted market mechanisms represent the ideal solution for every problem at all times and places. I find it a lot easier to assume that you fall within that group -- esp. since you have more-or-less self-identified yourself as a member. > > I do support voluntary markets as optimal mechanisms for resource allocation. But Geoff was brought into this only to demonstrate that somebody with more BGP expertise than me thought that the threat of disaggregation was not greater than the threat to Whois represented by needs requirements for transfers. Sigh. If only you were willing to show as much deference to those with more Internet number registry expertise than you... many of whom have been very patiently attempting to help you understand why this proposal is a bad idea. [Note: I added the word "patiently" above to clearly signal that I do not count myself among said group] > >> Besides, wasn't it you who just recently rejected (my) suggestion that observations based on the historical experience(s) of other registries could provide insight on the merits of your proposal? > > > > You suggested that the historical experience of the DNS registry was applicable, but I still have not seen an apples-to-apples comparison worthy of providing insights. For the DNS registry to inform us, we would have to compare an experience of for-pay DNS registries *with a needs test* to for-pay DNS registries *without a needs test*. > > Okay, I concede your point. > > And based on the same logic, I suggest that this proposal should be abandoned on the grounds that no one can claim to have any relevant "apples-to-apples" experience, or to have have any defensible "apples-to-apples" basis for assuming that this proposal has any chance of making it easier to maintain whois accuracy going forward. > My logic says that analogies have to be apt to be informative. Your logic says that nothing new can be proposed. As far as I can tell, you have discounted not only analogies, but also logic. Your reasoning appears to be insusceptible to any/all counter-evidence and counter-argument when it comes to the axiomatic superiority or market-based mechanisms -- which means of course that "reasoning" is not really the right term to use. You have a right to your own faith, but not to your own logic -- much less a right to redefine logic for everyone else. > And I point again to the unusual aspects of the MS/Nortel deal as evidence that had the needs requirement not very fortunately aligned with the prior facts of the sale, the transaction would likely have occurred and led to Whois inaccuracy. Care to address the fact that of the universe of publicly accessible data on transfers, 100% of the deals required fortuitous needs findings in order to maintain Whois accuracy? And also please consider whether you think it legal for a legacy holder to transfer addresses without being subject to ARIN's needs requirements, and by transfer I mean pay money for and then route, NOT having ARIN update Whois. My reading of the bankruptcy docs showed the judge viewed Nortel as having the exclusive right to transfer the addresses. > Per this article, it's not only Mike Burns who feels that all ARIN can do with these transactions is withhold Whois updates. > http://www.networkworld.com/news/2011/051111-nortel-ipv4-sale.html Per (the majority of people who have responded to your proposal on this list), I am not the only person who thinks that what you advocate would be reckless and counterproductive. Per (the majority of people who lived through the last 3-4 years), I wouldn't be the only one who believes that there are all sorts of perfectly legal market-making activities that Mike Burns could undertake to advance his own private agenda, which could if widely adopted rapidly precipitate the end of private sector governance in this domain. Per (lots of former homeowners, former employees of AIG, Lehman Brothers and many other banks, as well as former employees of every non-banking sector in the US and elsewhere), I am sure that I won't be the only one who's going to be sorry if you insist on pursuing that agenda, damn the consequences. The only real question is: will our collective regret be more like the regrets of former employees of Enron et al. who helped to trigger the dot-com collapse -- though not before a (very) few got very rich -- or more like the regrets of former employees and members of the private banks and independent clearing house associations that disappeared and/or permanently lost their self-governance prerogatives back in 1913. Mike Burns may be the only person in this debate who's willing to refer to himself in the third person, but I am not the only one who worries about such gloomy possibilities... Regards, TV > Regards, > Mike > > > > TV > > >> Or did you really mean that historical observations that seem to flatter your argument are relevant, but observations that raise doubts are not? > > > > No. > > > > Regards, > > Mike > > > > > > > > > > > > TV > > > > [1] The gradual diffusion of BGP during this period is recorded in some detail in the IETF's old "Internet Monthly Report" series (1991-1998): ftp://ftp.rfc-editor.org/in-notes/museum/imr/. > > Additional good sources on both the state of EGP/BGP(x) deployment and concurrent thoughts about addressing management include the IETF meeting minutes for the area.operations, area.routing, bgpdepl, tacit, ale, cidrd, idr, and piara BoFs/working groups. > > > > [2] Described here: http://www.aarnet.edu.au/News/2009/11/26/AARNet-salutes-20th-anniversary-of-the-Internet-in-Australia.aspx > > The episode in question is detailed in Chapter 4, p. 48 -- which is available online at > > http://www.aarnet.edu.au/library/AARNet_20YearBook_Chapter4 > > > > [3] http://tools.ietf.org/html/rfc1744 > > > > From owen at delong.com Thu May 19 21:05:22 2011 From: owen at delong.com (Owen DeLong) Date: Thu, 19 May 2011 18:05:22 -0700 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate In-Reply-To: References: <4DCFDB5C64DD4F738B65AB82D36B629D@mike><15F92ECD-2BE5-48F2-B65A-9A9D39B98F5 4@delong.com><0829B106605C4FE8B189DB2E56C69615@mike><8FB24038-B813-4DE0-91DD-56EDAD31BC03@delong.com><36A3A11C7EDF413C9E2EC07FD 0C122E0@mike> <8F23AB4955E3404393B1E03831C91054@mike> <6397CBB3-8145-43E7-8288-132F19B89E3F@delong.com> <4DD56EBB.70102@matthew.at> <5CABD084-E16C-4FA1-84E1-E5CA9F899144@delong.com> <4DD58B38.206@matthew.at> Message-ID: <0864BCD4-5990-4801-B032-360F616C987F@delong.com> On May 19, 2011, at 4:48 PM, Mike Burns wrote: > Hi Owen, jumping in here, > >> On 5/19/2011 2:21 PM, Owen DeLong wrote: >>> >>>> The number of buyers with need will >>>> exceed the available address space. >> >>> 1) You can't prove that, and, > >>> I can, actually. The available IPv4 space that could end up on a transfer market is bounded >>> by those addresses not currently in use. As such, the rather limited supply is well known. > > Except you don't have any information on how efficiently those addresses are used. > It could very well be that a great deal more efficiency can be found, freeing up more than the unrouted address space. Unlikely, but, I suppose there is a remote possibility. > Like those unfortunate souls who will find themselves behind CGN will likely enrich their ISP, who can sell as many addresses into the market as he can without losing too many customers who demand non-CGN access. So you are saying that your proposal will increase the deployment of LSN... Yet another reason to oppose. > Or even the deployment of plain old NAT could free up addresses which are currnently being advertised now for sale later. > So you are saying that your proposal will increase the deployment of NAT... Yet another reason to oppose. >> The pool of buyers is known to be monotonically increasing and ARIN's average issuance >> of ~190,000 IPv4 /24s each year by ARIN would indicate an annual market demand for 25% >> of the maximum possible pool from which to develop such a market (roughly 12 /8s) > >> Therefore, even if we assume that all possible addresses will come on the market with >> your policy, the supply will be gone in 4 years or less. Any churn beyond that would leave >> a need-gap behind unless it is the result of successful abandonment of IPv4. At the point >> where organizations can begin successful abandonment of IPv4 altogether, the market >> will invariably collapse anyway. > > And you believe this and still think there is a danger from speculators? When the market is at most 4 years in duration and then subject to collapse due to IPv6? > Yes. I think that if you open it up to speculation, the duration becomes much closer to 4 minutes than 4 years. Owen From owen at delong.com Thu May 19 21:06:41 2011 From: owen at delong.com (Owen DeLong) Date: Thu, 19 May 2011 18:06:41 -0700 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate In-Reply-To: <4F5AB686C7C54D8E8836A8199CFE96A7@video> References: <4DCFDB5C64DD4F738B65AB82D36B629D@mike> <15F92ECD-2BE5-48F2-B65A-9A9D39B98F54@delong.com> <0829B106605C4FE8B189DB2E56C69615@mike> <51506A06-D2EE-4A0D-B92B-781662094A1C@eyeconomics.com> <0CCB8AB89D144E89872AF0D635E95497@mike> <38F7CA20-FF84-46C5-9FC1-AC0B8B95E52F@delong.com> <4F5AB686C7C54D8E8836A8199CFE96A7@video> Message-ID: <2C28D3FF-246E-407C-8802-F7379F0378D1@delong.com> On May 19, 2011, at 4:52 PM, Mike Burns wrote: > Hi Owen, > >> >> You suggested that the historical experience of the DNS registry was applicable, but I still have not seen an apples-to-apples comparison worthy of providing insights. For the DNS registry to inform us, we would have to compare an experience of for-pay DNS registries *with a needs test* to for-pay DNS registries *without a needs test*. >> > > That is available. The DNS administered for a fee by NSI retained the needs basis for several months and there was > no descent into chaos observed. The descent into madness occurred when WIPO got involved and the UDRP started > developing. It was about this time that the needs-basis aspect of DNS administration was also abandoned as part of > the efforts by WIPO to make domain names part of the trademark namespace(s). > > Owen > > Right, so there were many changes happening in the DNS transition that make it impossible to isolate the effects of removing needs requirements on the accuracy of whois. Such as increasing registrations by three orders of magnitude. > > Regards, > Mike It is the removal of needs basis that cause the 3 order of magnitude increase in registration, so, I do not feel that invalidates the analogy, but, rather confirms destructive effects of removing needs basis. Owen From owen at delong.com Thu May 19 21:18:23 2011 From: owen at delong.com (Owen DeLong) Date: Thu, 19 May 2011 18:18:23 -0700 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate In-Reply-To: <4DD5AEFD.3060901@matthew.at> References: <4DCFDB5C64DD4F738B65AB82D36B629D@mike><15F92ECD-2BE5-48F2-B65A-9A9D39B98F5 4@delong.com><0829B106605C4FE8B189DB2E56C69615@mike><8FB24038-B813-4DE0-91DD-56EDAD31BC03@delong.com><36A3A11C7EDF413C9E2EC07FD 0C122E0@mike> <8F23AB4955E3404393B1E03831C91054@mike> <6397CBB3-8145-43E7-8288-132F19B89E3F@delong.com> <4DD56EBB.70102@matthew.at> <5CABD084-E16C-4FA1-84E1-E5CA9F899144@delong.com> <4DD58B38.206@matthew.at> <4DD5AEFD.3060901@matthew.at> Message-ID: On May 19, 2011, at 4:59 PM, Matthew Kaufman wrote: > On 5/19/2011 4:48 PM, Mike Burns wrote: >> >> And you believe this and still think there is a danger from speculators? When the market is at most 4 years in duration and then subject to collapse due to IPv6? > > > That's really the best question. Who are the speculators that we're worried about who have enough cash to actually affect the price of IP address space and availability *and* who are stupid enough to do that when they know a collapse is coming soon? > Speculation for profit is not the only form of speculation I am concerned about, but, even that if you corner the market at T0 and sell it all off at T2 with a 200% price increase is damaging. The form that worries me the most, however, is if $MEGA_TELCO and $MEGA_CABLECO purchase all of the available addresses as they come on the market, leaving nothing for their smaller less capitalized competitors to use, they may be bale to forestall (and would now have a financial interest in doing so) their IPv6 deployments for enough years to seriously damage their competitors that had no non-IPv6 alternative. I see no reason to produce policy that enables this behavior and many reasons not to. > Also, if these speculators are really so bad, won't all the altruistic sellers (some of whom are represented in this discussion, no doubt) simply refuse to sell to them at *any* price, but have nice low prices for non-profits and other good causes that need space? > I think this presumes a number of facts not in evidence, not the least of which is that one can readily determine that your purchaser is, in fact, such a speculator. Owen From owen at delong.com Thu May 19 21:21:16 2011 From: owen at delong.com (Owen DeLong) Date: Thu, 19 May 2011 18:21:16 -0700 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate In-Reply-To: References: <4DCFDB5C64DD4F738B65AB82D36B629D@mike> <15F92ECD-2BE5-48F2-B65A-9A9D39B98F54@delong.com> <0829B106605C4FE8B189DB2E56C69615@mike> <51506A06-D2EE-4A0D-B92B-781662094A1C@eyeconomics.com> <0CCB8AB89D144E89872AF0D635E95497@mike> <31B8F43F2E3545D4BB04061A0510715E@mike> Message-ID: <7205B9FE-6951-4B37-91A5-297E063762D0@delong.com> On May 19, 2011, at 4:56 PM, Mike Burns wrote: > Blake, > > Is having an emergency supplier of IP addresses a negative for the community? If they are charging a premium for those addresses and preventing them from being used by others with need in order to create that emergency supply, then, yes. > Is having a temporary supplier of IP addresses a negative for the community? If they are preventing the IPs from going to permanent uses with need and laying dormant in between temporary needs, then, yes. > Is having a supplier for long-range plans a negative for the community? If they are supporting the long range plans of a few at the detriment of the short term needs of the many, then, yes. > > Is this what stewarship has become, having a few elites making these kinds of decisions about which businesses the community finds positive or negative? That is not a valid characterization of what is going on or of the PDP in my opinion. > What's wrong with letting the bad ones go broke and the good ones succeed as measures of their positive or negative attributes? Cash is not the ultimate arbiter of communal good. Every attempt to make it so has failed miserably. Owen > > Regards, > Mike > > > ----- Original Message ----- > From: Blake Dunlap > To: Mike Burns > Cc: Tom Vest ; arin-ppml at arin.net > Sent: Thursday, May 19, 2011 7:17 PM > Subject: Re: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate > > On Thu, May 19, 2011 at 18:10, Mike Burns wrote: > What difference does it make if space is sitting in a broker's inventory or the inventory of ARIN's STLS? What about the many other examples I gave where the current needs requirement would not be met? Like temporary use, emergency suppliers, lessors, or those with planning horizons longer than ARIIN dictat? > > All of these have been previously responded to, just because you don't like the answer doesn't mean it hasn't already been answered. > > As a recap, every example you have listed above is a negative for the community for the benefit of one actor, or completely unrelated to what you are trying to push in this proposal. > > -Blake > _______________________________________________ > 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 george.herbert at gmail.com Thu May 19 22:07:55 2011 From: george.herbert at gmail.com (George Herbert) Date: Thu, 19 May 2011 19:07:55 -0700 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate In-Reply-To: References: <4DCFDB5C64DD4F738B65AB82D36B629D@mike> <0829B106605C4FE8B189DB2E56C69615@mike> <8FB24038-B813-4DE0-91DD-56EDAD31BC03@delong.com> <8F23AB4955E3404393B1E03831C91054@mike> <6397CBB3-8145-43E7-8288-132F19B89E3F@delong.com> <4DD56EBB.70102@matthew.at> <5CABD084-E16C-4FA1-84E1-E5CA9F899144@delong.com> <4DD58B38.206@matthew.at> Message-ID: On Thu, May 19, 2011 at 4:00 PM, Owen DeLong wrote: >[...] >> 2) Even if that's true, adding buyers without need will increase demand and thus increase revenue for the sellers >> > > You say that as if it is a good thing. In fact, that is the very crux of the problem with this policy. It will > drive up the price of addresses for no purpose of benefit to the community. It is of net benefit to the community if it helps encourage IPv6 transitions. Smooth ramp functions are less catastrophic to community members, and the community as a whole, than abrupt brick walls. -- -george william herbert george.herbert at gmail.com From tvest at eyeconomics.com Thu May 19 22:38:33 2011 From: tvest at eyeconomics.com (Tom Vest) Date: Thu, 19 May 2011 22:38:33 -0400 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate In-Reply-To: References: <4DCFDB5C64DD4F738B65AB82D36B629D@mike> <0829B106605C4FE8B189DB2E56C69615@mike> <8FB24038-B813-4DE0-91DD-56EDAD31BC03@delong.com> <8F23AB4955E3404393B1E03831C91054@mike> <6397CBB3-8145-43E7-8288-132F19B89E3F@delong.com> <4DD56EBB.70102@matthew.at> <5CABD084-E16C-4FA1-84E1-E5CA9F899144@delong.com> <4DD58B38.206@matthew.at> Message-ID: <0590BE03-4B9A-4D26-B74A-D920D91E8AFB@eyeconomics.com> On May 19, 2011, at 10:07 PM, George Herbert wrote: > On Thu, May 19, 2011 at 4:00 PM, Owen DeLong wrote: >> [...] >>> 2) Even if that's true, adding buyers without need will increase demand and thus increase revenue for the sellers >>> >> >> You say that as if it is a good thing. In fact, that is the very crux of the problem with this policy. It will >> drive up the price of addresses for no purpose of benefit to the community. > > It is of net benefit to the community if it helps encourage IPv6 transitions. I would be inclined to embrace that as a general conditional statement. However the conditional part means that it does not apply to this particular proposal. And merging your two observations together makes it clear why this is so... > Smooth ramp functions are less catastrophic to community members, and > the community as a whole, than abrupt brick walls. It is NOT of net benefit to the community to encourage a minority of members to build ramps for their own smooth (adaptation?) if/when those ramps simultaneously represent brick walls impeding the adaptation all community members -- including (eventually) the ramp builders themselves. TV > -- > -george william herbert > george.herbert at gmail.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 george.herbert at gmail.com Thu May 19 22:47:13 2011 From: george.herbert at gmail.com (George Herbert) Date: Thu, 19 May 2011 19:47:13 -0700 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate In-Reply-To: <0590BE03-4B9A-4D26-B74A-D920D91E8AFB@eyeconomics.com> References: <4DCFDB5C64DD4F738B65AB82D36B629D@mike> <0829B106605C4FE8B189DB2E56C69615@mike> <8FB24038-B813-4DE0-91DD-56EDAD31BC03@delong.com> <8F23AB4955E3404393B1E03831C91054@mike> <6397CBB3-8145-43E7-8288-132F19B89E3F@delong.com> <4DD56EBB.70102@matthew.at> <5CABD084-E16C-4FA1-84E1-E5CA9F899144@delong.com> <4DD58B38.206@matthew.at> <0590BE03-4B9A-4D26-B74A-D920D91E8AFB@eyeconomics.com> Message-ID: On Thu, May 19, 2011 at 7:38 PM, Tom Vest wrote: > > On May 19, 2011, at 10:07 PM, George Herbert wrote: > >> On Thu, May 19, 2011 at 4:00 PM, Owen DeLong wrote: >>> [...] >>>> 2) Even if that's true, adding buyers without need will increase demand and thus increase revenue for the sellers >>>> >>> >>> You say that as if it is a good thing. In fact, that is the very crux of the problem with this policy. It will >>> drive up the price of addresses for no purpose of benefit to the community. >> >> It is of net benefit to the community if it helps encourage IPv6 transitions. > > I would be inclined to embrace that as a general conditional statement. > However the conditional part means that it does not apply to this particular proposal. > And merging your two observations together makes it clear why this is so... > >> Smooth ramp functions are less catastrophic to community members, and >> the community as a whole, than abrupt brick walls. > > It is NOT of net benefit to the community to encourage a minority of members to build ramps for their own smooth (adaptation?) if/when those ramps simultaneously represent brick walls impeding the adaptation all community members -- including (eventually) the ramp builders themselves. I agree that a number of people in the community view speculation as such a brick wall; I disagree with the ASSERTION that it is the true situation. It is arguable that the effect on the community will be that, and I don't disagree with making the argument. As always, I am highly dissapointed at the politicized discussion on this point, which is significantly lacking in depth and breadth on the question. This is not a political question. This is a question that frankly someone with Hal Varian's email address (or another economist who's net-savvy) should be dragging him into, if necessary kicking and screaming, along with some thoughtful and articulate IP space user community representatives who haven't prejudged the situation (in either direction). I am entirely happy if the end result of an actual, appropriate, educated and informed discussion on these points indicates that we not speculate (in the community's interest). We're not there. I also don't recommend shocking status quo changes while we figure it out, but I would point out that creeping "deployed code-ism" will beat political internet policymaking authority action nearly 100% of the time. Creeping speculation is happening, and if the community remains wilfully unwilling to talk seriously about it (and bring in economists who understand scarcity and the net) we're going to get whatever results we negligently let happen. This is not community leadership on display... -- -george william herbert george.herbert at gmail.com From matthew at matthew.at Thu May 19 23:42:55 2011 From: matthew at matthew.at (Matthew Kaufman) Date: Thu, 19 May 2011 20:42:55 -0700 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate In-Reply-To: References: <4DCFDB5C64DD4F738B65AB82D36B629D@mike><15F92ECD-2BE5-48F2-B65A-9A9D39B98F5 4@delong.com><0829B106605C4FE8B189DB2E56C69615@mike><8FB24038-B813-4DE0-91DD-56EDAD31BC03@delong.com><36A3A11C7EDF413C9E2EC07FD 0C122E0@mike> <8F23AB4955E3404393B1E03831C91054@mike> <6397CBB3-8145-43E7-8288-132F19B89E3F@delong.com> <4DD56EBB.70102@matthew.at> <5CABD084-E16C-4FA1-84E1-E5CA9F899144@delong.com> <4DD58B38.206@matthew.at> <4DD5AEFD.3060901@matthew.at> Message-ID: <4DD5E33F.80104@matthew.at> On 5/19/2011 6:18 PM, Owen DeLong wrote: > > The form that worries me the most, however, is if $MEGA_TELCO and $MEGA_CABLECO purchase all of the available addresses as they come on > the market, leaving nothing for their smaller less capitalized competitors to use, they may be bale to forestall (and would now have a financial > interest in doing so) their IPv6 deployments for enough years to seriously damage their competitors that had no non-IPv6 alternative. What makes you think that $MEGA_TELCO and $MEGA_CABLECO haven't already written up the needs justification that shows they need pretty much all space that will ever come on-market? Matthew Kaufman From narten at us.ibm.com Fri May 20 00:53:02 2011 From: narten at us.ibm.com (Thomas Narten) Date: Fri, 20 May 2011 00:53:02 -0400 Subject: [arin-ppml] Weekly posting summary for ppml@arin.net Message-ID: <201105200453.p4K4r2vt027435@rotala.raleigh.ibm.com> Total of 211 messages in the last 7 days. script run at: Fri May 20 00:53:02 EDT 2011 Messages | Bytes | Who --------+------+--------+----------+------------------------ 14.22% | 30 | 18.85% | 394091 | owen at delong.com 13.27% | 28 | 19.19% | 401144 | mike at nationwideinc.com 8.06% | 17 | 4.55% | 95168 | matthew at matthew.at 4.27% | 9 | 6.39% | 133501 | tvest at eyeconomics.com 5.21% | 11 | 5.30% | 110739 | tedm at ipinc.net 5.21% | 11 | 4.98% | 104092 | ikiris at gmail.com 4.74% | 10 | 4.98% | 104178 | cengel at conxeo.com 5.21% | 11 | 4.20% | 87842 | info at arin.net 4.74% | 10 | 3.55% | 74140 | jeffrey.lyon at blacklotus.net 4.74% | 10 | 3.23% | 67582 | hannigan at gmail.com 3.32% | 7 | 2.56% | 53537 | cgrundemann at gmail.com 2.84% | 6 | 1.98% | 41395 | jcurran at arin.net 2.84% | 6 | 1.84% | 38571 | bill at herrin.us 1.90% | 4 | 1.76% | 36862 | ipng at 69706e6720323030352d30312d31340a.nosense.org 1.42% | 3 | 1.94% | 40515 | lar at mwtcorp.net 1.90% | 4 | 1.29% | 27047 | george.herbert at gmail.com 0.95% | 2 | 1.37% | 28587 | john.sweeting at twcable.com 0.95% | 2 | 1.11% | 23241 | billd at cait.wustl.edu 0.95% | 2 | 0.96% | 20171 | rudi.daniel at gmail.com 0.95% | 2 | 0.82% | 17219 | farmer at umn.edu 0.95% | 2 | 0.72% | 15062 | mysidia at gmail.com 0.95% | 2 | 0.61% | 12735 | vixie at isc.org 0.95% | 2 | 0.57% | 11884 | kkargel at polartel.com 0.95% | 2 | 0.56% | 11638 | joelja at bogus.com 0.95% | 2 | 0.53% | 11074 | dogwallah at gmail.com 0.95% | 2 | 0.48% | 10114 | john at egh.com 0.47% | 1 | 0.85% | 17743 | wesley.e.george at sprint.com 0.47% | 1 | 0.70% | 14715 | jradel at vantage.com 0.47% | 1 | 0.64% | 13396 | niel.harper at firstcaribbeanbank.com 0.47% | 1 | 0.45% | 9353 | mueller at syr.edu 0.47% | 1 | 0.40% | 8401 | george at dmu.edu 0.47% | 1 | 0.38% | 7923 | scottleibrand at gmail.com 0.47% | 1 | 0.34% | 7047 | narten at us.ibm.com 0.47% | 1 | 0.31% | 6486 | robert.smales at cw.com 0.47% | 1 | 0.30% | 6344 | fernattj at gmail.com 0.47% | 1 | 0.29% | 6073 | springer at inlandnet.com 0.47% | 1 | 0.27% | 5700 | gary.buhrmaster at gmail.com 0.47% | 1 | 0.25% | 5298 | mksmith at adhost.com 0.47% | 1 | 0.25% | 5295 | rbf+arin-ppml at panix.com 0.47% | 1 | 0.23% | 4766 | fw at deneb.enyo.de --------+------+--------+----------+------------------------ 100.00% | 211 |100.00% | 2090669 | Total From mysidia at gmail.com Fri May 20 01:12:24 2011 From: mysidia at gmail.com (Jimmy Hess) Date: Fri, 20 May 2011 00:12:24 -0500 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate In-Reply-To: <4DD5E33F.80104@matthew.at> References: <4DCFDB5C64DD4F738B65AB82D36B629D@mike> <0829B106605C4FE8B189DB2E56C69615@mike> <8FB24038-B813-4DE0-91DD-56EDAD31BC03@delong.com> <8F23AB4955E3404393B1E03831C91054@mike> <6397CBB3-8145-43E7-8288-132F19B89E3F@delong.com> <4DD56EBB.70102@matthew.at> <5CABD084-E16C-4FA1-84E1-E5CA9F899144@delong.com> <4DD58B38.206@matthew.at> <4DD5AEFD.3060901@matthew.at> <4DD5E33F.80104@matthew.at> Message-ID: On Thu, May 19, 2011 at 10:42 PM, Matthew Kaufman wrote: > On 5/19/2011 6:18 PM, Owen DeLong wrote: > What makes you think that $MEGA_TELCO and $MEGA_CABLECO haven't already > written up the needs justification that shows they need pretty much all > space that will ever come on-market? "All the space that will ever be released" won't come out as a single aggregate. Per the 8.3 single aggregate requirement; the addresses received must be the exact maximal amount the receiver can justify, as a single aggregate. Then writing a justification for all the address space that 'will ever come on-market' wouldn't be too useful.... -- -JH From matthew at matthew.at Fri May 20 01:24:47 2011 From: matthew at matthew.at (Matthew Kaufman) Date: Thu, 19 May 2011 22:24:47 -0700 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate In-Reply-To: References: <4DCFDB5C64DD4F738B65AB82D36B629D@mike> <0829B106605C4FE8B189DB2E56C69615@mike> <8FB24038-B813-4DE0-91DD-56EDAD31BC03@delong.com> <8F23AB4955E3404393B1E03831C91054@mike> <6397CBB3-8145-43E7-8288-132F19B89E3F@delong.com> <4DD56EBB.70102@matthew.at> <5CABD084-E16C-4FA1-84E1-E5CA9F899144@delong.com> <4DD58B38.206@matthew.at> <4DD5AEFD.3060901@matthew.at> <4DD5E33F.80104@matthew.at> Message-ID: <4DD5FB1F.3090609@matthew.at> On 5/19/2011 10:12 PM, Jimmy Hess wrote: > On Thu, May 19, 2011 at 10:42 PM, Matthew Kaufman wrote: >> On 5/19/2011 6:18 PM, Owen DeLong wrote: >> What makes you think that $MEGA_TELCO and $MEGA_CABLECO haven't already >> written up the needs justification that shows they need pretty much all >> space that will ever come on-market? > "All the space that will ever be released" > won't come out as a single aggregate. > Doesn't matter, neither did all the space Nortel released to Microsoft. > Per the 8.3 single aggregate requirement; the addresses received must > be the exact maximal amount the receiver can justify, as a single aggregate. Yes. ARIN interprets "as a single aggregate" as modifying "amount the receiver can justify", not "the addresses received". We've been through this already. And I have a policy proposal pending that removes it anyway, as the workaround just adds extra paperwork for everyone even if it is interpreted the other way. Matthew Kaufman From mike at nationwideinc.com Fri May 20 09:20:31 2011 From: mike at nationwideinc.com (Mike Burns) Date: Fri, 20 May 2011 09:20:31 -0400 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate References: <4DCFDB5C64DD4F738B65AB82D36B629D@mike><15F92ECD-2BE5-48F2-B65A-9A9D39B98F5 4@delong.com><0829B106605C4FE8B189DB2E56C69615@mike><8FB24038-B813-4DE0-91DD-56EDAD31BC03@delong.com><36A3A11C7EDF413C9E2EC07FD 0C122E0@mike> <8F23AB4955E3404393B1E03831C91054@mike> <6397CBB3-8145-43E7-8288-132F19B89E3F@delong.com> <4DD56EBB.70102@matthew.at> <5CABD084-E16C-4FA1-84E1-E5CA9F899144@delong.com> <4DD58B38.206@matthew.at> <0864BCD4-5990-4801-B032-360F616C987F@delong.com> Message-ID: <8D0E77DB18F44C86896666CA5BD9DFA7@mike> Good Morning Owen, >> Like those unfortunate souls who will find themselves behind CGN will >> likely enrich their ISP, who can sell as many addresses into the market >> as he can without losing too many customers who demand >>non-CGN access. >So you are saying that your proposal will increase the deployment of LSN... >Yet another reason to oppose. No, I am saying the deployment of LSN is likely to happen, and when it does an uncertain number of ip addresses may be freed up to supply the transfer market. >> Or even the deployment of plain old NAT could free up addresses which are >> currnently being advertised now for sale later. > >So you are saying that your proposal will increase the deployment of NAT... >Yet another reason to oppose. I am saying that your "proof" of the size of the transfer pool is not valid because you assume 100% efficiency in routed space. >> The pool of buyers is known to be monotonically increasing and ARIN's >> average issuance >> of ~190,000 IPv4 /24s each year by ARIN would indicate an annual market >> demand for 25% >> of the maximum possible pool from which to develop such a market (roughly >> 12 /8s) > >> Therefore, even if we assume that all possible addresses will come on the >> market with >> your policy, the supply will be gone in 4 years or less. Any churn beyond >> that would leave >> a need-gap behind unless it is the result of successful abandonment of >> IPv4. At the point >> where organizations can begin successful abandonment of IPv4 altogether, >> the market >> will invariably collapse anyway. > > And you believe this and still think there is a danger from speculators? > When the market is at most 4 years in duration and then subject to > collapse due to IPv6? > >Yes. I think that if you open it up to speculation, the duration becomes >much closer to 4 minutes >than 4 years. >Owen Owen, any single entity is limited to a /12. I trust the ARIN staff to be able to determine whether the entity is a sham company, and even by the size of your limited pool, a /12 can't corner the market. So maybe we can at least temper the fear that a speculator would enter into a 4 minute market. Regards, Mike From mike at nationwideinc.com Fri May 20 10:26:22 2011 From: mike at nationwideinc.com (Mike Burns) Date: Fri, 20 May 2011 10:26:22 -0400 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate References: <4DCFDB5C64DD4F738B65AB82D36B629D@mike> <15F92ECD-2BE5-48F2-B65A-9A9D39B98F54@delong.com> <0829B106605C4FE8B189DB2E56C69615@mike> <51506A06-D2EE-4A0D-B92B-781662094A1C@eyeconomics.com> <0CCB8AB89D144E89872AF0D635E95497@mike> <2691B7B9-1F3C-403C-B4E8-5B82BED0E191@eyeconomics.com> <454BB1826E7B4F2BB3A68BE1DD86A756@video> Message-ID: Hi Tom, leaving the message unsnipped, On May 19, 2011, at 7:31 PM, Mike Burns wrote: > >> Can you provide us with a comparable measure of the number of old > >> address holders who have not responded to opportunity afforded by the > >> 8.2 change? > > > > No. > > > >> If possible, please break down the number into two groups -- those who > >> are on the fence and holding out fin hopes of additional blandishments > >> and concessions, and those whose philosophical or >commercial > >> priorities preclude registration regardless of the side payments. > > > > I have never met anybody whose philosophical or commercial priorites > > preclude registration. I imagine that many of those who have not done > > the 8.2 transfer have failed to see any utility in doing so. > > Besides, the ARIN language never required it, it only says "ARIN will > > consider requests for transfers." And since the addresses continued to > > be routed without notifying ARIN of the mergers and acquisitions, many > > failed to apply. Also, for legacy holders, an 8.2 transfer meant having > > to sign an RSA, I think, which was a disincentive. > > If you are uncomfortable with the second half of of the question, then a > simple accounting of all of the old address holders who have not responded > yet will suffice. > > To quote what you deleted, for the sake of clarity: > > "I have argued that the uptick in 8.2 transfer requests is in response to > natural market forces at work. Prices go up and owners of address block > control take steps to ensure accurate registration." > > Without some means of (at minimum) benchmarking the relative size of (or > anything else about) that "slight uptick," your interpretation of its > causes and relevance are completely subjective. > Tom, how could I have any of the information you are soliciting? I merely > held that I think the uptick in processing of 8.2 transfers for historical > mergers and acquisitions that John Curran mentioned is evidence of the > increasing desire to have addresses properly registered as the value of > those assets increases and replacement addresses are no longer available > from the free pool. And that was in response to your assertion that it is > the needs requirement which increases Whois accuracy. My point was, and > is, that there is a logical reason for address holders to desire > registration, and that they would naturally do so if not impeded by the > necessity of passing ARIN's needs analysis. >Fair enough, you prefer to argue logic rather than facts: I don't understand why you would even ask me for "facts" that nobody could possibly have, like "Can you provide us with a comparable measure of the number of old address holders who have not responded to the opportunity afforded by the 8.2 change" , and then "please break that number into groups of those who are on the fence and those whose philosophical priorites preclude registration." Is that some kind of debating tool? I think everybody here knows those facts would be impossible to come by without somehow listing and polling all address holders who my have been merged or acquired in the past, and then getting accurate information as to their "philosophies". Was this just to come around to your point that unless we can prove what the results of a policy change will be, the policy shall not be changed? >Please provide a negative proof that "logic" could never lead any future >address user, potential address buyer, and/or potential address seller to >conclude that registration would not advance their own >private interests. Who cares if somebody will conclude that they will not want to register? My proposal is designed to remove disincentives toward registration. >Please provide a negative proof that "logic" could never lead any future >address user, potential address buyer, and/or potential address seller to >embrace "sales-friendly registration" but simultaneously >reject >"operationally relevant registration" (i.e., the kind that makes whois an >appropriate subject of interest for community deliberation). Again, you posit these nefarious types to what point? They can pull the same tricks with or without my proposal. >Please provide a negative proof that "logic" will BOTH always lead all >future address users, address buyers, and address sellers to self-maintain >"operationally relevant registration" for themselves in >perpetuity, AND >that the attainment of that outcome by means of needs-free transfers could >never have any unintended consequences that might be as serious or more >serious than some marginal >degradation of whois accuracy. Tom, I find it a pretty silly argument. Basically, unless I can not just demonstrate every consequence, even unintended consequences, of my proposal, but "prove" that they won't be as serious as what you, in loaded terms, calls marginal degradation of whois accuracy, then the proposal should be abandoned? If we applied the same test to any proposal, requesting proof of the seriousness of future unintended consequences, then nothing could be approved. >> Yes, I never held that this interpretation was more than my subjective >> opinion backed up by an understanding that registration is the clearest >> means of establishing ownnership rights to control of these >>assets, and >> as those rights become increasingly valuable, owners will seek accurate >> registration. >So you have no actual "apples-to-apples" firsthand experience to >corroborate that opinion then? How could anybody but ARIN staff have any experience in discerning the reason for the recent uptick in 8.2 transfer requests for historical mergers. I merely said such an uptick would be expected to occur as IP address holding rights increase in perceived value. >Perhaps someone who anticipates the possibility of buying addresses in the >future but has no particular preference for registered addresses and no >intention of registering purchased addresses themselves >can get in touch >with Mike off-list? Wow, you seem really certain such entities exist, who would want to buy ip addresses but not have Whois updated, or have Whois updated with semi-bogus information. What makes you think my proposal would have any effect on these mysterious entities? If they *want* to be off the books, I suppose they will try to be off the books. My proposal addresses those who *want* to be accurately registered in Whois, but who find an impediment to that in ARIN's needs requirements. For the record, I still have never met or heard from anybody who wanted to buy addresses and not be registered as the buyer, no such person has contacted me off-list. > >> Having enjoyed the extremely lopsided privilege of discussing broadly > >> related matters with Geoff semi-regularly between the years 2000~2009, > >> I wholeheartedly agree that he is one of the world's >foremost experts > >> on BGP. However, with all due respect to the man, Geoff's views about > >> the relative merits of market-based vs. RIR-style need/capability-based > >> number resource allocation were formed >*before* BGP was widely > >> deployed [1]. To my knowledge, the first concrete expression of those > >> views took place in mid-1994, as documented for example in the recently > >> published 20-year >retrospective on AARNET and the early days of the > >> Internet in Australia [2]. The second concrete expression of those > >> views AFAIK is RFC 1744 (December 1994), which I (completely > >> subjectively) >interpret as a somewhat bitter personal reflection on > >> the results of the first experience [3]. > > > >> Regardless of whether or not that interpretation is valid, > >> contemporaneous Australian press accounts indicate that AARNet's > >> acquisition by Telstra was announced on January 7 1997 and implemented > >> on >July 1, and that Geoff had assumed the title of Telstra Internet's > >> Technical Manager on or around the same time. After that he continued > >> to advocate the same position, e.g., in the context of the IETF > >> >"Pricing for Internet Addresses and Routing Advertisements" (piara) > >> BoF. > > > >> So while Geoff's world-class expertise in BGP is unquestionable, his > >> seemingly consistent preference for market-based vs. > >> need/capability-based resource management must be based on something > >> else. > > > > I never claimed that Geoff Huston, whom I have never met, did not have a > > preference for market-based solutions, only that he did not view the > > danger of disaggregation as a reason to have needs requirements for > > transfers. > > Why are you attempting to change the subject to disaggregation? I thought > your proposal was based on claims about the best way to maintain whois > accuracy? > > I'm not changing the subject to disaggregation, in fact I mentioned that > this was one of the points noted in opposition, please reread the entire > thread from this morning. >Got it -- this was a red herring. Moving on... A red herring is an attempt to divert. Something you have done rather consistently in this thread. My mention of disaggregation came here, in a post on 5/18 at 11:23: The objections I have noted seem to fall in three categories: 1. That's not the way we have historically dealt with addresses. 2. It could lead to disaggregation 3. Hoarders and speculators will appear and will unfairly manipulate price. I was pointing out in a recap of prior commentary, what the objections to my proposal were. How is this in any way a red herring? > > Unless you are implying that his preference for market-based solutions > > has somehow overridden his BGP expertise, my point stands. > > I decline to speculate about Geoff's innermost thoughts on this matter. > Geoff has a vast reserve of hard experience dealing with market mechanisms > in the BGP world, but even he hasn't advocated pure free-market routing at > all places and times. But then my experience discussing matters like these > with people all over the world for the last decade or so has left the > impression that world-class expertise in BGP is perfectly compatible with > radically opposing, mutually incompatible views -- not only concerning the > best way to maintain a protocol number resource registry, but even about > the proper way to manage global interdomain routing. Opinions on the two > subjects seem to be quite independent and unrelated, at least in most > people. > > Of course there is undeniably a subset of people (in fact, one that's is > quite well represented in this industry) who believe that unrestricted > market mechanisms represent the ideal solution for every problem at all > times and places. I find it a lot easier to assume that you fall within > that group -- esp. since you have more-or-less self-identified yourself as > a member. > > I do support voluntary markets as optimal mechanisms for resource > allocation. But Geoff was brought into this only to demonstrate that > somebody with more BGP expertise than me thought that the threat of > disaggregation was not greater than the threat to Whois represented by > needs requirements for transfers. >Sigh. If only you were willing to show as much deference to those with more >Internet number registry expertise than you... many of whom have been very >patiently attempting to help you understand why >this proposal is a bad >idea. Some of the posters have made intelligent points which have led to the proposal being modified to require RSA and limit needs-free transfers to a /12 as a means to gain consensus. And I'm not really sure how well you have appraised my experience level. [Note: I added the word "patiently" above to clearly signal that I do not count myself among said group] lol. > >> Besides, wasn't it you who just recently rejected (my) suggestion that > >> observations based on the historical experience(s) of other registries > >> could provide insight on the merits of your proposal? > > > > You suggested that the historical experience of the DNS registry was > > applicable, but I still have not seen an apples-to-apples comparison > > worthy of providing insights. For the DNS registry to inform us, we > > would have to compare an experience of for-pay DNS registries *with a > > needs test* to for-pay DNS registries *without a needs test*. > > Okay, I concede your point. > > And based on the same logic, I suggest that this proposal should be > abandoned on the grounds that no one can claim to have any relevant > "apples-to-apples" experience, or to have have any defensible > "apples-to-apples" basis for assuming that this proposal has any chance of > making it easier to maintain whois accuracy going forward. > My logic says that analogies have to be apt to be informative. Your logic > says that nothing new can be proposed. >As far as I can tell, you have discounted not only analogies, but also >logic. Your reasoning appears to be insusceptible to any/all >counter-evidence and counter-argument when it comes to the axiomatic > >superiority or market-based mechanisms -- which means of course that >"reasoning" is not really the right term to use. It's a ludicrous test to request proof of the extent of damage of unintended consequences before a proposal is allowed to continue. Basically, you are somehow postulating that I am stating that zero registrations will happen off the books if my proposal advances. A logical fallacy that leads to additional logical faults, like believing that a showing that a single entity who does not wish to be registrered somehow has some logical effect on my proposal. You set up a series of straw man logical arguments unrelated to my proposal, and think that the readers can't see through that? How does the existence of an entity who wishes to scam the registration system have any effect on my proposal, can you answer that direct question? >You have a right to your own faith, but not to your own logic -- much less >a right to redefine logic for everyone else. Its not a redefinition, it's just that logic has to be applied rationally. If you make a mistake on your initial logical test, as you did, then everything that follows is mistaken. Unless you can demonstrate why you think your logical questions relate to my proposal, they remain separate and independent, and meaningless. > And I point again to the unusual aspects of the MS/Nortel deal as > evidence that had the needs requirement not very fortunately aligned with > the prior facts of the sale, the transaction would likely have occurred > and led to Whois inaccuracy. Care to address the fact that of the universe > of publicly accessible data on transfers, 100% of the deals required > fortuitous needs findings in order to maintain Whois accuracy? And also > please consider whether you think it legal for a legacy holder to transfer > addresses without being subject to ARIN's needs requirements, and by > transfer I mean pay money for and then route, NOT having ARIN update > Whois. My reading of the bankruptcy docs showed the judge viewed Nortel > as having the exclusive right to transfer the addresses. > Per this article, it's not only Mike Burns who feels that all ARIN can do > with these transactions is withhold Whois updates. > http://www.networkworld.com/news/2011/051111-nortel-ipv4-sale.html >Per (the majority of people who have responded to your proposal on this >list), I am not the only person who thinks that what you advocate would be >reckless and counterproductive. The difference, Tom, is that everyone involved in this discussion reads the list and knows that, but not everyone is exposed to the words of the lawyers and academics quoted in the article. >Per (the majority of people who lived through the last 3-4 years), I >wouldn't be the only one who believes that there are all sorts of perfectly >legal market-making activities that Mike Burns could >undertake to advance >his own private agenda, which could if widely adopted rapidly precipitate >the end of private sector governance in this domain. That sentence doesn't make any sense, I suppose it's meaningful if we leave off the intitial clause. And again with the personal assault on my motivations and the presumption that I don't act out of stewardship. Congratulations on your belief. I believe that if we don't act to make Whois a title registry that accurately reflects legal transactions, we run the risk of private registries filling the void of accurate information, and THAT could precipitate the end of community governance in this domain. >Per (lots of former homeowners, former employees of AIG, Lehman Brothers >and many other banks, as well as former employees of every non-banking >sector in the US and elsewhere), I am sure that I >won't be the only one >who's going to be sorry if you insist on pursuing that agenda, damn the >consequences. Well, you certainly attribute a lot of power to me, since my pursuing my agenda will make many sorry. I only wish that were so! ;-) >The only real question is: will our collective regret be more like the >regrets of former employees of Enron et al. who helped to trigger the >dot-com collapse -- though not before a (very) few got very rich ->- or >more like the regrets of former employees and members of the private banks >and independent clearing house associations that disappeared and/or >permanently lost their self-governance prerogatives >back in 1913. >Mike Burns may be the only person in this debate who's willing to refer to >himself in the third person, but I am not the only one who worries about >such gloomy possibilities... My point above was that real transactions in the real world occur, particularly with legacy space, that run the risk of not being recorded in Whois due to the needs requirement.Often in this debate, and again in this very message (remember your "some marginal degradation") the point is made that the number of these transactions is minimal, and there are some academics who require proof of these transactions, which obviously are desired to remain private. Where the number of transactions that we can publicly point to is very limited, we have to derive as much information as we can from the public sources available. Which is what I have done, and by pointing to the article, I am hoping to establish that others have read the same public legal papers and come to the same conclusions. And yet again, you have failed to acknowledge the facts of the MS/Nortel deal which show that absent the fortunate needs finding, the deal would likely have happened, Microsoft would route the addresses, and Nortel, or one of it's ancient acquisitions, would be the Whois registrant. But I suppose that is just a marginal degradation. Regards, Mike From owen at delong.com Fri May 20 10:37:48 2011 From: owen at delong.com (Owen DeLong) Date: Fri, 20 May 2011 07:37:48 -0700 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate In-Reply-To: <8D0E77DB18F44C86896666CA5BD9DFA7@mike> References: <4DCFDB5C64DD4F738B65AB82D36B629D@mike><15F92ECD-2BE5-48F2-B65A-9A9D39B98F5 4@delong.com><0829B106605C4FE8B189DB2E56C69615@mike><8FB24038-B813-4DE0-91DD-56EDAD31BC03@delong.com><36A3A11C7EDF413C9E2EC07FD 0C122E0@mike> <8F23AB4955E3404393B1E03831C91054@mike> <6397CBB3-8145-43E7-8288-132F19B89E3F@delong.com> <4DD56EBB.70102@matthew.at> <5CABD084-E16C-4FA1-84E1-E5CA9F899144@delong.com> <4DD58B38.206@matthew.at> <0864BCD4-5990-4801-B032-360F616C987F@delong.com> <8D0E77DB18F44C86896666CA5BD9DFA7@mike> Message-ID: <3A17C2FB-E956-427D-A03E-C2D8D7AD9D5D@delong.com> On May 20, 2011, at 6:20 AM, Mike Burns wrote: > Good Morning Owen, > >>> Like those unfortunate souls who will find themselves behind CGN will likely enrich their ISP, who can sell as many addresses into the market as he can without losing too many customers who demand >>non-CGN access. > >> So you are saying that your proposal will increase the deployment of LSN... Yet another reason to oppose. > > No, I am saying the deployment of LSN is likely to happen, and when it does an uncertain number of ip addresses may be freed up to supply the transfer market. > Either your proposal makes a difference here, or, your above statement isn't relevant to the discussion. If your proposal makes a difference in this regard (encouraging LSN), that is a negative IMHO. > >>> Or even the deployment of plain old NAT could free up addresses which are currnently being advertised now for sale later. >> > >> So you are saying that your proposal will increase the deployment of NAT... Yet another reason to oppose. > > I am saying that your "proof" of the size of the transfer pool is not valid because you assume 100% efficiency in routed space. I actually don't assume that at all, but, that's OK. There may be other assumptions built in. I would argue that increasing NAT does not increase the efficiency of address utilization, but, merely increases the number of users on a single address while decreasing the utility of those addresses. The net efficiency remains roughly the same if one considers the utility factor as part of the efficiency equation. So, again, either your proposal will make a difference here (encouraging NAT) or it won't. If it doesn't, there's not a lot of relevance to your statement. > > >>> The pool of buyers is known to be monotonically increasing and ARIN's average issuance >>> of ~190,000 IPv4 /24s each year by ARIN would indicate an annual market demand for 25% >>> of the maximum possible pool from which to develop such a market (roughly 12 /8s) >> >>> Therefore, even if we assume that all possible addresses will come on the market with >>> your policy, the supply will be gone in 4 years or less. Any churn beyond that would leave >>> a need-gap behind unless it is the result of successful abandonment of IPv4. At the point >>> where organizations can begin successful abandonment of IPv4 altogether, the market >>> will invariably collapse anyway. >> >> And you believe this and still think there is a danger from speculators? When the market is at most 4 years in duration and then subject to collapse due to IPv6? >> > >> Yes. I think that if you open it up to speculation, the duration becomes much closer to 4 minutes >> than 4 years. > >> Owen > > Owen, any single entity is limited to a /12. I trust the ARIN staff to be able to determine whether the entity is a sham company, and even by the size of your limited pool, a /12 can't corner the market. So maybe we can at least temper the fear that a speculator would enter into a 4 minute market. > It doesn't have to be a sham company, it can simply be a subsidiary. For example, last year, a certain cable provider got a /9. They would have no problem whatsoever creating 8 regional operating companies each of whom needed a /12 in my estimation. The /12 limit is both absurd and utterly useless in having the effect you claim. All it would really do is penalize large providers (note, I'm seeking fairness, not penalties for either side) and increase disaggregation. Owen From mike at nationwideinc.com Fri May 20 10:55:34 2011 From: mike at nationwideinc.com (Mike Burns) Date: Fri, 20 May 2011 10:55:34 -0400 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate References: <4DCFDB5C64DD4F738B65AB82D36B629D@mike><15F92ECD-2BE5-48F2-B65A-9A9D39B98F5 4@delong.com><0829B106605C4FE8B189DB2E56C69615@mike><8FB24038-B813-4DE0-91DD-56EDAD31BC03@delong.com><36A3A11C7EDF413C9E2EC07FD 0C122E0@mike> <8F23AB4955E3404393B1E03831C91054@mike> <6397CBB3-8145-43E7-8288-132F19B89E3F@delong.com> <4DD56EBB.70102@matthew.at> <5CABD084-E16C-4FA1-84E1-E5CA9F899144@delong.com> <4DD58B38.206@matthew.at> <0864BCD4-5990-4801-B032-360F616C987F@delong.com> <8D0E77DB18F44C86896666CA5BD9DFA7@mike> <3A17C2FB-E956-427D-A03E-C2D8D7AD9D5D@delong.com> Message-ID: <1956DCF8D1074323975F9092D8A1DD1B@mike> Good Morning Owen, > >>> Like those unfortunate souls who will find themselves behind CGN will >>> likely enrich their ISP, who can sell as many addresses into the market >>> as he can without losing too many customers who demand >>non-CGN access. > >> So you are saying that your proposal will increase the deployment of >> LSN... Yet another reason to oppose. > > No, I am saying the deployment of LSN is likely to happen, and when it > does an uncertain number of ip addresses may be freed up to supply the > transfer market. > >Either your proposal makes a difference here, or, your above statement >isn't relevant to the discussion. If your >proposal makes a difference in this regard (encouraging LSN), that is a >negative IMHO. I was replying to your thread with Matthew wherein you claimed to have proof of the size of the transfer pool, which proof, combined with the known and stable demand, led you to a 4 year timeframe. I don't see any impact on my proposal, though. > >>> Or even the deployment of plain old NAT could free up addresses which >>> are currnently being advertised now for sale later. >> > >> So you are saying that your proposal will increase the deployment of >> NAT... Yet another reason to oppose. > > I am saying that your "proof" of the size of the transfer pool is not > valid because you assume 100% efficiency in routed space. >I actually don't assume that at all, but, that's OK. There may be other >assumptions built in. I would argue that increasing >NAT does not increase the efficiency of address utilization, but, merely >increases the number of users on a single >address while decreasing the utility of those addresses. The net efficiency >remains roughly the same if one considers >he utility factor as part of the efficiency equation. >So, again, either your proposal will make a difference here (encouraging >NAT) or it won't. If it doesn't, there's >not a lot of relevance to your statement. No, my proposal doesn't impact, my statment was in reply to your establishing with any accuracy the size of the transfer pool. > > >>> The pool of buyers is known to be monotonically increasing and ARIN's >>> average issuance >>> of ~190,000 IPv4 /24s each year by ARIN would indicate an annual market >>> demand for 25% >>> of the maximum possible pool from which to develop such a market >>> (roughly 12 /8s) >> >>> Therefore, even if we assume that all possible addresses will come on >>> the market with >>> your policy, the supply will be gone in 4 years or less. Any churn >>> beyond that would leave >>> a need-gap behind unless it is the result of successful abandonment of >>> IPv4. At the point >>> where organizations can begin successful abandonment of IPv4 altogether, >>> the market >>> will invariably collapse anyway. >> >> And you believe this and still think there is a danger from speculators? >> When the market is at most 4 years in duration and then subject to >> collapse due to IPv6? >> > >> Yes. I think that if you open it up to speculation, the duration becomes >> much closer to 4 minutes >> than 4 years. > >> Owen > > Owen, any single entity is limited to a /12. I trust the ARIN staff to be > able to determine whether the entity is a sham company, and even by the > size of your limited pool, a /12 can't corner the market. So maybe we can > at least temper the fear that a speculator would enter into a 4 minute > market. > >It doesn't have to be a sham company, it can simply be a subsidiary. For >example, last year, a certain >cable provider got a /9. They would have no problem whatsoever creating 8 >regional operating >companies each of whom needed a /12 in my estimation. >The /12 limit is both absurd and utterly useless in having the effect you >claim. All it would really >do is penalize large providers (note, I'm seeking fairness, not penalties >for either side) and >increase disaggregation. >Owen How does it penalize anybody but the people you have expressed such fear of, the speculators and market cornerers? If the large company can show need, it can continue to get addresses above and beyond a /12. The number is designed to allow for almost all entities to engage in fluid transactions without requiring ARIN oversight, but would prevent anybody from "buying up all the addresses", as has been very commonly expressed as a negative aspect to my proposal. Since my expressed intent for the /12 is to prevent these kinds of activities, but it has been mentioned that it could be gamed through the creation of sham companies (or subsidiaries) I am open to any suggestions to the phrasing of that limit, but my assumption is that we would rely on ARIN staff interpretation of the facts in the light of the proposal's expressed intent. Regards, Mike From owen at delong.com Fri May 20 11:21:06 2011 From: owen at delong.com (Owen DeLong) Date: Fri, 20 May 2011 08:21:06 -0700 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate In-Reply-To: <1956DCF8D1074323975F9092D8A1DD1B@mike> References: <4DCFDB5C64DD4F738B65AB82D36B629D@mike><15F92ECD-2BE5-48F2-B65A-9A9D39B98F5 4@delong.com><0829B106605C4FE8B189DB2E56C69615@mike><8FB24038-B813-4DE0-91DD-56EDAD31BC03@delong.com><36A3A11C7EDF413C9E2EC07FD 0C122E0@mike> <8F23AB4955E3404393B1E03831C91054@mike> <6397CBB3-8145-43E7-8288-132F19B89E3F@delong.com> <4DD56EBB.70102@matthew.at> <5CABD084-E16C-4FA1-84E1-E5CA9F899144@delong.com> <4DD58B38.206@matthew.at> <0864BCD4-5990-4801-B032-360F616C987F@delong.com> <8D0E77DB18F44C86896666CA5BD9DFA7@mike> <3A17C2FB-E956-427D-A03E-C2D8D7AD9D5D@delong.com> <1956DCF8D1074323975F9092D8A1DD1B@mike> Message-ID: On May 20, 2011, at 7:55 AM, Mike Burns wrote: > > > Good Morning Owen, >> >>>> Like those unfortunate souls who will find themselves behind CGN will likely enrich their ISP, who can sell as many addresses into the market as he can without losing too many customers who demand >>non-CGN access. >> >>> So you are saying that your proposal will increase the deployment of LSN... Yet another reason to oppose. >> >> No, I am saying the deployment of LSN is likely to happen, and when it does an uncertain number of ip addresses may be freed up to supply the transfer market. >> > >> Either your proposal makes a difference here, or, your above statement isn't relevant to the discussion. If your >> proposal makes a difference in this regard (encouraging LSN), that is a negative IMHO. > > I was replying to your thread with Matthew wherein you claimed to have proof of the size of the transfer pool, which proof, combined with the known and stable demand, led you to a 4 year timeframe. > I don't see any impact on my proposal, though. > If your policy doesn't have an impact here, my estimates are likely accurate. > >> >>>> Or even the deployment of plain old NAT could free up addresses which are currnently being advertised now for sale later. >>> >> >>> So you are saying that your proposal will increase the deployment of NAT... Yet another reason to oppose. >> >> I am saying that your "proof" of the size of the transfer pool is not valid because you assume 100% efficiency in routed space. > >> I actually don't assume that at all, but, that's OK. There may be other assumptions built in. I would argue that increasing >> NAT does not increase the efficiency of address utilization, but, merely increases the number of users on a single >> address while decreasing the utility of those addresses. The net efficiency remains roughly the same if one considers >> he utility factor as part of the efficiency equation. > >> So, again, either your proposal will make a difference here (encouraging NAT) or it won't. If it doesn't, there's >> not a lot of relevance to your statement. > > No, my proposal doesn't impact, my statment was in reply to your establishing with any accuracy the size of the transfer pool. > If your policy doesn't change the situation, my estimates are likely accurate. >> >> >>>> The pool of buyers is known to be monotonically increasing and ARIN's average issuance >>>> of ~190,000 IPv4 /24s each year by ARIN would indicate an annual market demand for 25% >>>> of the maximum possible pool from which to develop such a market (roughly 12 /8s) >>> >>>> Therefore, even if we assume that all possible addresses will come on the market with >>>> your policy, the supply will be gone in 4 years or less. Any churn beyond that would leave >>>> a need-gap behind unless it is the result of successful abandonment of IPv4. At the point >>>> where organizations can begin successful abandonment of IPv4 altogether, the market >>>> will invariably collapse anyway. >>> >>> And you believe this and still think there is a danger from speculators? When the market is at most 4 years in duration and then subject to collapse due to IPv6? >>> >> >>> Yes. I think that if you open it up to speculation, the duration becomes much closer to 4 minutes >>> than 4 years. >> >>> Owen >> >> Owen, any single entity is limited to a /12. I trust the ARIN staff to be able to determine whether the entity is a sham company, and even by the size of your limited pool, a /12 can't corner the market. So maybe we can at least temper the fear that a speculator would enter into a 4 minute market. >> > >> It doesn't have to be a sham company, it can simply be a subsidiary. For example, last year, a certain >> cable provider got a /9. They would have no problem whatsoever creating 8 regional operating >> companies each of whom needed a /12 in my estimation. > >> The /12 limit is both absurd and utterly useless in having the effect you claim. All it would really >> do is penalize large providers (note, I'm seeking fairness, not penalties for either side) and >> increase disaggregation. > >> Owen > > How does it penalize anybody but the people you have expressed such fear of, the speculators and market cornerers? > If the large company can show need, it can continue to get addresses above and beyond a /12. I see your point. I had missed that subtlety. OK, so, it's merely a no-op, not punitive. > The number is designed to allow for almost all entities to engage in fluid transactions without requiring ARIN oversight, but would prevent anybody from "buying up all the addresses", as has been very commonly expressed as a negative aspect to my proposal. Except it wouldn't actually prevent buying up all the addresses, it would just require more paperwork to do so. > Since my expressed intent for the /12 is to prevent these kinds of activities, but it has been mentioned that it could be gamed through the creation of sham companies (or subsidiaries) I am open to any suggestions to the phrasing of that limit, but my assumption is that we would rely on ARIN staff interpretation of the facts in the light of the proposal's expressed intent. > Needs basis works to prevent this without having to create elaborate rules to prevent gaming an indirect management scheme such as what you are proposing. Seems to me that needs basis is a superior mechanism for accomplishing this goal. Owen From cengel at conxeo.com Fri May 20 12:40:40 2011 From: cengel at conxeo.com (Chris Engel) Date: Fri, 20 May 2011 12:40:40 -0400 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate In-Reply-To: <20110520004257.GA23891@panix.com> References: <4DCFDB5C64DD4F738B65AB82D36B629D@mike> <15F92ECD-2BE5-48F2-B65A-9A9D39B98F54@delong.com> <0829B106605C4FE8B189DB2E56C69615@mike> <51506A06-D2EE-4A0D-B92B-781662094A1C@eyeconomics.com> <0CCB8AB89D144E89872AF0D635E95497@mike> <31B8F43F2E3545D4BB04061A0510715E@mike> <20110520004257.GA23891@panix.com> Message-ID: > On Thu, May 19, 2011 at 05:49:43PM -0400, Mike Burns wrote: > > Blake, > > > > My proposal includes a limit of /12 of needs-free transfers > > specifically to prevent hoarding and market cornering. (It's a recent > > addition.) > > I assumed it was speciifcally to create business for lawyers > specializing in creating legal entities to hold address space, since > someone wanting to hoard a /8 would, under your policy, need 16 > different legal entities. > > If we assume there are going to be serious speculators involved if the > needs requirement is eliminated, we would also reasonably have to > assume they won't be deterred by a requirement to create a stack of > entities under their control in practice, but nominally sufficiently > distinct to prevent their holdings from being aggregated for the > purposes of the /12 rule. > > In this post, I'm taking no position on the merits of transfers w/o > needs justification, just pointing out that the /12 limitation is > trivial to get around and is effectively a no-op. > > -- Brett > Brett, Under that same scenario, what is to stop the same speculator from creating 16 different legal entities that purchase IP-Enabled devices (i.e. pet rocks) from the parent company to show it meets it's "needs" and "utilization" requirements under a "needs" based regulatory requirement for transfers? It strikes me as a "no-op". If a dishonest actor has sufficient expertise and resources to fool ARIN staff into allowing more allocations then policy would allow, then I would argue it has equal ability to fool ARIN staff into believing it has legitimate need for those addresses when it doesn't. Tossing aside any philosophical arguments for a moment, from an entirely practical standpoint that's why I don't see a "needs" based requirement for transfers amounting to very much of anything in a scarcity market. In the past when the value of IPv4 address space was relatively low, it wasn't really worthwhile for anyone to throw alot of resources into obtaining more then they had a use for. Therefore effective enforcement didn't require a ton of resources either. If IPv4 space actually starts gaining some real monetary value (as it seems to have) in a scarcity market, unless you start throwing alot more resources at enforcement efforts then the effectiveness of enforcing adherence to policy increasingly declines. >From my perspective, in a scarcity market.....at best "needs" based justification controls are open enough that it becomes a non-factor one way or another....Anyone with a legitimate need can get approval for a transfer....AS can anyone who has enough resources and basic knowledge to fabricate legitimate need... essentially a rubber stamp. At worst, enforcement efforts get increasingly complex and arbitrary....and you do catch alot of the people attempting to game the system.... BUT you ALSO get alot of false positives where organizations with real legitimate needs get denied simply because they lack the experience and inside knowledge to know how to navigate the increasingly complex and arbitrary rules for demonstrating need..... and it simply becomes an "insiders" game....where it's not what you need but what/who you know that determines approval. Personally I'd prefer a system where speculators are allowed into a system to one where legitimate organizations are kept out simply because they lack the knowledge/experience to get past the enforcement process. YMMV. Christopher Engel (representing only my own views) From lar at mwtcorp.net Fri May 20 12:42:23 2011 From: lar at mwtcorp.net (Larry Ash) Date: Fri, 20 May 2011 10:42:23 -0600 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate In-Reply-To: References: <4DCFDB5C64DD4F738B65AB82D36B629D@mike> Message-ID: Hi Owen, Owen DeLong wrote: > > On May 19, 2011, at 4:59 PM, Matthew Kaufman wrote: > >> On 5/19/2011 4:48 PM, Mike Burns wrote: >>> >>> And you believe this and still think there is a danger from speculators? >>>When the market is at most 4 years in duration and then subject to collapse >>>due to IPv6? >> >> >> That's really the best question. Who are the speculators that we're >>worried about who have enough cash to actually affect the price of IP >>address space and availability *and* who are stupid enough to do that when >>they know a collapse is coming soon? >> > > Speculation for profit is not the only form of speculation I am concerned >about, but, even that if you corner the market at T0 and sell it all off at >T2 > with a 200% price increase is damaging. > > The form that worries me the most, however, is if $MEGA_TELCO and >$MEGA_CABLECO purchase all of the available addresses as they come on > the market, leaving nothing for their smaller less capitalized competitors >to use, they may be bale to forestall (and would now have a financial > interest in doing so) their IPv6 deployments for enough years to seriously >damage their competitors that had no non-IPv6 alternative. Unfortunately this may already have happened. One of my techs in a conversation with a cable tech (low level so take with a little grain of salt) was told that the cable company he worked for (changed owners recently so I'm not sure who the parent currently is) and comcast have gotten so much IPV4 that there is no shortage in V4 addresses and that they had no plans in converting to IPV6. The current needs basis may have been too loose to accomplish the purpose it was intended to do. > > I see no reason to produce policy that enables this behavior and many >reasons not to. > >> Also, if these speculators are really so bad, won't all the altruistic >>sellers (some of whom are represented in this discussion, no doubt) simply >>refuse to sell to them at *any* price, but have nice low prices for >>non-profits and other good causes that need space? >> > > I think this presumes a number of facts not in evidence, not the least of >which is that one can readily determine that your purchaser is, > in fact, such a speculator. > > 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. Larry Ash Network Administrator Mountain West Telephone 123 W 1st St. Casper, WY 82601 Office 307 233-8387 From kkargel at polartel.com Fri May 20 13:06:43 2011 From: kkargel at polartel.com (Kevin Kargel) Date: Fri, 20 May 2011 12:06:43 -0500 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate In-Reply-To: References: <4DCFDB5C64DD4F738B65AB82D36B629D@mike> <15F92ECD-2BE5-48F2-B65A-9A9D39B98F54@delong.com> <0829B106605C4FE8B189DB2E56C69615@mike> <51506A06-D2EE-4A0D-B92B-781662094A1C@eyeconomics.com> <0CCB8AB89D144E89872AF0D635E95497@mike> <31B8F43F2E3545D4BB04061A0510715E@mike> <20110520004257.GA23891@panix.com> Message-ID: <8695009A81378E48879980039EEDAD289F033052@MAIL1.polartel.local> > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf Of Chris Engel > Sent: Friday, May 20, 2011 11:41 AM > To: 'Brett Frankenberger'; Mike Burns > Cc: arin-ppml at arin.net > Subject: Re: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois > Accurate > > > > > On Thu, May 19, 2011 at 05:49:43PM -0400, Mike Burns wrote: > > > Blake, > > > > > > My proposal includes a limit of /12 of needs-free transfers > > > specifically to prevent hoarding and market cornering. (It's a recent > > > addition.) > > > > I assumed it was speciifcally to create business for lawyers > > specializing in creating legal entities to hold address space, since > > someone wanting to hoard a /8 would, under your policy, need 16 > > different legal entities. > > > > If we assume there are going to be serious speculators involved if the > > needs requirement is eliminated, we would also reasonably have to > > assume they won't be deterred by a requirement to create a stack of > > entities under their control in practice, but nominally sufficiently > > distinct to prevent their holdings from being aggregated for the > > purposes of the /12 rule. > > > > In this post, I'm taking no position on the merits of transfers w/o > > needs justification, just pointing out that the /12 limitation is > > trivial to get around and is effectively a no-op. > > > > -- Brett > > > > > Brett, > > Under that same scenario, what is to stop the same speculator from > creating 16 different legal entities that purchase IP-Enabled devices > (i.e. pet rocks) from the parent company to show it meets it's "needs" and > "utilization" requirements under a "needs" based regulatory requirement > for transfers? > > It strikes me as a "no-op". If a dishonest actor has sufficient expertise > and resources to fool ARIN staff into allowing more allocations then > policy would allow, then I would argue it has equal ability to fool ARIN > staff into believing it has legitimate need for those addresses when it > doesn't. > > Tossing aside any philosophical arguments for a moment, from an entirely > practical standpoint that's why I don't see a "needs" based requirement > for transfers amounting to very much of anything in a scarcity market. In > the past when the value of IPv4 address space was relatively low, it > wasn't really worthwhile for anyone to throw alot of resources into > obtaining more then they had a use for. Therefore effective enforcement > didn't require a ton of resources either. If IPv4 space actually starts > gaining some real monetary value (as it seems to have) in a scarcity > market, unless you start throwing alot more resources at enforcement > efforts then the effectiveness of enforcing adherence to policy > increasingly declines. > > >From my perspective, in a scarcity market.....at best "needs" based > justification controls are open enough that it becomes a non-factor one > way or another....Anyone with a legitimate need can get approval for a > transfer....AS can anyone who has enough resources and basic knowledge to > fabricate legitimate need... essentially a rubber stamp. At worst, > enforcement efforts get increasingly complex and arbitrary....and you do > catch alot of the people attempting to game the system.... BUT you ALSO > get alot of false positives where organizations with real legitimate needs > get denied simply because they lack the experience and inside knowledge to > know how to navigate the increasingly complex and arbitrary rules for > demonstrating need..... and it simply becomes an "insiders" game....where > it's not what you need but what/who you know that determines approval. > > Personally I'd prefer a system where speculators are allowed into a system > to one where legitimate organizations are kept out simply because they > lack the knowledge/experience to get past the enforcement process. YMMV. This is a knee-jerk reaction, but isn't participants having or gaining the knowledge/experience to participate in the process desirable? > > Christopher Engel > (representing only my own views) > > > From cengel at conxeo.com Fri May 20 13:24:05 2011 From: cengel at conxeo.com (Chris Engel) Date: Fri, 20 May 2011 13:24:05 -0400 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate In-Reply-To: References: <4DCFDB5C64DD4F738B65AB82D36B629D@mike> <15F92ECD-2BE5-48F2-B65A-9A9D39B98F54@delong.com> <0829B106605C4FE8B189DB2E56C69615@mike> <51506A06-D2EE-4A0D-B92B-781662094A1C@eyeconomics.com> <0CCB8AB89D144E89872AF0D635E95497@mike> <2691B7B9-1F3C-403C-B4E8-5B82BED0E191@eyeconomics.com> <454BB1826E7B4F2BB3A68BE1DD86A756@video> Message-ID: Tom, Excising a particular section of this thread for the sake of brevity... > Fair enough, you prefer to argue logic rather than facts: > > Please provide a negative proof that "logic" could never lead any future > address user, potential address buyer, and/or potential address seller to > conclude that registration would not advance their own private interests. > > Please provide a negative proof that "logic" could never lead any future > address user, potential address buyer, and/or potential address seller to > embrace "sales-friendly registration" but simultaneously reject > "operationally relevant registration" (i.e., the kind that makes whois an > appropriate subject of interest for community deliberation). > > Please provide a negative proof that "logic" will BOTH always lead all future > address users, address buyers, and address sellers to self-maintain > "operationally relevant registration" for themselves in perpetuity, AND that > the attainment of that outcome by means of needs-free transfers could > never have any unintended consequences that might be as serious or more > serious than some marginal degradation of whois accuracy. > I don't think the above is a fair tactic for debate. You are asking Mike to prove a logical fallacy. Furthermore, when you start using words like "never" and "always" when discussing human behavior as benchmarks for judging the legitimacy of a system...your standards themselves appear absurd. If we applied the same standards for judging the appropriateness of a "needs" based policy, it would assuredly fail as well. Systems designed to regulate human behavior cannot achieve a uniformity of results approaching mathematical perfection, nor need they do so to be effective (IMO). If you want to argue that it's likely a substantial number of individuals would have logical reasons for not wanting to maintain accurate registration under the policy Mike proposes...that's (IMO) a reasonable standard to base an argument on. Not sure whether I would agree with that proposition or not...but the standard is reasonable. Asking Mike to provide a standard of proof that couldn't allow for even a single exception isn't (IMO). Christopher Engel (Representing only my own views) From cengel at conxeo.com Fri May 20 13:33:11 2011 From: cengel at conxeo.com (Chris Engel) Date: Fri, 20 May 2011 13:33:11 -0400 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate In-Reply-To: References: <4DCFDB5C64DD4F738B65AB82D36B629D@mike><15F92ECD-2BE5-48F2-B65A-9A9D39B98F5 4@delong.com><0829B106605C4FE8B189DB2E56C69615@mike><8FB24038-B813-4DE0-91DD-56EDAD31BC03@delong.com><36A3A11C7EDF413C9E2EC07FD 0C122E0@mike> <8F23AB4955E3404393B1E03831C91054@mike> <6397CBB3-8145-43E7-8288-132F19B89E3F@delong.com> <4DD56EBB.70102@matthew.at> <5CABD084-E16C-4FA1-84E1-E5CA9F899144@delong.com> <4DD58B38.206@matthew.at> <4DD5AEFD.3060901@matthew.at> Message-ID: > > On May 19, 2011, at 4:59 PM, Matthew Kaufman wrote: > > > On 5/19/2011 4:48 PM, Mike Burns wrote: > >> > >> And you believe this and still think there is a danger from speculators? > When the market is at most 4 years in duration and then subject to collapse > due to IPv6? > > > > > > That's really the best question. Who are the speculators that we're worried > about who have enough cash to actually affect the price of IP address space > and availability *and* who are stupid enough to do that when they know a > collapse is coming soon? > > > > Speculation for profit is not the only form of speculation I am concerned > about, but, even that if you corner the market at T0 and sell it all off at T2 > with a 200% price increase is damaging. > > The form that worries me the most, however, is if $MEGA_TELCO and > $MEGA_CABLECO purchase all of the available addresses as they come on > the market, leaving nothing for their smaller less capitalized competitors to > use, they may be bale to forestall (and would now have a financial > interest in doing so) their IPv6 deployments for enough years to seriously > damage their competitors that had no non-IPv6 alternative. > > I see no reason to produce policy that enables this behavior and many > reasons not to. > > > Also, if these speculators are really so bad, won't all the altruistic sellers > (some of whom are represented in this discussion, no doubt) simply refuse > to sell to them at *any* price, but have nice low prices for non-profits and > other good causes that need space? > > > > I think this presumes a number of facts not in evidence, not the least of > which is that one can readily determine that your purchaser is, > in fact, such a speculator. > > Owen Owen, Playing devil's advocate for a moment, If an organization were able to receive substantial capital from divesting itself of it's IPv4 address space, wouldn't that go a long way toward mitigating one of the significant impediments that organizations face in regards IPv6 adoption today.....namely that the cost for adoption does not justify the perceived benefits? Christopher Engel (representing only my own views) From AStiver at forumhealth.org Fri May 20 13:48:59 2011 From: AStiver at forumhealth.org (Alan Stiver) Date: Fri, 20 May 2011 13:48:59 -0400 Subject: [arin-ppml] ARIN-PPML Digest, Vol 71, Issue 191 Message-ID: My email address has changed to: alan_stiver at valleycarehealth.net Please update your records. CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, may contain information which is confidential or privileged. This information is intended to be for the sole use of the individual or entity named above. If you are not the intended recipient, please note that any unauthorized review, disclosure, copying, distribution or use of the contents of this information is strictly prohibited. If you have received this e-mail in error, please notify the sender immediately by reply e-mail or telephone and destroy all electronic and hard copies of the communication, including attachments. From AStiver at forumhealth.org Fri May 20 13:49:02 2011 From: AStiver at forumhealth.org (Alan Stiver) Date: Fri, 20 May 2011 13:49:02 -0400 Subject: [arin-ppml] ARIN-PPML Digest, Vol 71, Issue 191 Message-ID: My email address has changed to: alan_stiver at valleycarehealth.net Please update your records. CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, may contain information which is confidential or privileged. This information is intended to be for the sole use of the individual or entity named above. If you are not the intended recipient, please note that any unauthorized review, disclosure, copying, distribution or use of the contents of this information is strictly prohibited. If you have received this e-mail in error, please notify the sender immediately by reply e-mail or telephone and destroy all electronic and hard copies of the communication, including attachments. From mike at nationwideinc.com Fri May 20 13:53:19 2011 From: mike at nationwideinc.com (Mike Burns) Date: Fri, 20 May 2011 13:53:19 -0400 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate References: <4DCFDB5C64DD4F738B65AB82D36B629D@mike> Message-ID: > Unfortunately this may already have happened. One of my techs in a > conversation > with a cable tech (low level so take with a little grain of salt) was told > that the cable company he worked for (changed owners recently so I'm not > sure > who the parent currently is) and comcast have gotten so much IPV4 that > there is > no shortage in V4 addresses and that they had no plans in converting to > IPV6. Recent reports show Centurylink and Level3 have amassed huge holdings: http://blog.connectedplanetonline.com/unfiltered/2011/05/02/unexpected-benefit-of-recent-telecom-mergers-a-treasure-trove-of-ipv4-addresses/ Maybe it's time to buy stock in these companies? (And of course HP with 2 /8s!) I agree that it is worth considering the impact on the deployment of IPv6 from the concentration of IPv4 addresses in the hands of incumbent network operators. What if you were an investor in a startup and you decided that this was a real risk, (that incumbents won't deploy IPv6) and that IPv4 may be with us for far longer than expected? How would that affect your desire to avoid supply disruptions in the future, or severe price rises? I argue that a rational investor could see this information, decide that IPv6 is still way, way off, and come to the conclusion that the best thing for him would be to acquire enough IPv4 addresses now to handle not just short-term, but long-term growth. If he finds a seller willing to sell him as many legacy addresses as he needs, then his choice under current policy is: 1. Purchase what he wants, ignore the ARIN registry, rely on the purchase documents to induce a network operator to route them. 2. Purchase what he can demonstrate a 3-month need for and process the 8.3 transfer. 3. Purchase what he wants, and attempt to game the ARIN needs requirement. I argue that there is a real danger of option 1, which reduces Whois accuracy. However, you could argue that if he chooses option 2, address use is more efficient, and I would agree with that. But I would argue back that most businessmen do not operate out of altruism, and few would choose option 2 due to future uncertainties of availability and price. (But I can't prove that not a single one would!) And if there were no needs requirement, I argue he would purchase what he wants, regardless of need, but he would want to have the purchase registered with ARIN to protect his ownership rights. In this case, Whois is accurate and the buyer is under RSA. (But I can't prove that every such buyer would!) I guess it comes down to what we think Joe Businessman would do if he came to believe that IPv6 was farther off than he was led to believe had he been reading the popular trade press over the last decade. This is another example of where business incentives drive behavior to the detriment of Whois accuracy if we maintain the needs requirement for transfers. Regards, Mike ----- Original Message ----- From: "Larry Ash" To: "Owen DeLong" ; Cc: Sent: Friday, May 20, 2011 12:42 PM Subject: Re: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate > Hi Owen, > Owen DeLong wrote: >> >> On May 19, 2011, at 4:59 PM, Matthew Kaufman wrote: >> >>> On 5/19/2011 4:48 PM, Mike Burns wrote: >>>> >>>> And you believe this and still think there is a danger from >>>> speculators? When the market is at most 4 years in duration and then >>>> subject to collapse due to IPv6? >>> >>> >>> That's really the best question. Who are the speculators that we're >>> worried about who have enough cash to actually affect the price of IP >>> address space and availability *and* who are stupid enough to do that >>> when they know a collapse is coming soon? >>> >> >> Speculation for profit is not the only form of speculation I am concerned >> about, but, even that if you corner the market at T0 and sell it all off >> at T2 >> with a 200% price increase is damaging. >> >> The form that worries me the most, however, is if $MEGA_TELCO and >> $MEGA_CABLECO purchase all of the available addresses as they come on >> the market, leaving nothing for their smaller less capitalized >> competitors to use, they may be bale to forestall (and would now have a >> financial >> interest in doing so) their IPv6 deployments for enough years to >> seriously damage their competitors that had no non-IPv6 alternative. > > Unfortunately this may already have happened. One of my techs in a > conversation > with a cable tech (low level so take with a little grain of salt) was told > that the cable company he worked for (changed owners recently so I'm not > sure > who the parent currently is) and comcast have gotten so much IPV4 that > there is > no shortage in V4 addresses and that they had no plans in converting to > IPV6. > The current needs basis may have been too loose to accomplish the purpose > it > was intended to do. > >> >> I see no reason to produce policy that enables this behavior and many >> reasons not to. >> >>> Also, if these speculators are really so bad, won't all the altruistic >>> sellers (some of whom are represented in this discussion, no doubt) >>> simply refuse to sell to them at *any* price, but have nice low prices >>> for non-profits and other good causes that need space? >>> >> >> I think this presumes a number of facts not in evidence, not the least of >> which is that one can readily determine that your purchaser is, >> in fact, such a speculator. >> >> 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. > > 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 cengel at conxeo.com Fri May 20 14:10:39 2011 From: cengel at conxeo.com (Chris Engel) Date: Fri, 20 May 2011 14:10:39 -0400 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate In-Reply-To: <8695009A81378E48879980039EEDAD289F033052@MAIL1.polartel.local> References: <4DCFDB5C64DD4F738B65AB82D36B629D@mike> <15F92ECD-2BE5-48F2-B65A-9A9D39B98F54@delong.com> <0829B106605C4FE8B189DB2E56C69615@mike> <51506A06-D2EE-4A0D-B92B-781662094A1C@eyeconomics.com> <0CCB8AB89D144E89872AF0D635E95497@mike> <31B8F43F2E3545D4BB04061A0510715E@mike> <20110520004257.GA23891@panix.com> <8695009A81378E48879980039EEDAD289F033052@MAIL1.polartel.local> Message-ID: > > > On Thu, May 19, 2011 at 05:49:43PM -0400, Mike Burns wrote: > > > > Blake, > > > > > > > > My proposal includes a limit of /12 of needs-free transfers > > > > specifically to prevent hoarding and market cornering. (It's a recent > > > > addition.) > > > > > > I assumed it was speciifcally to create business for lawyers > > > specializing in creating legal entities to hold address space, since > > > someone wanting to hoard a /8 would, under your policy, need 16 > > > different legal entities. > > > > > > If we assume there are going to be serious speculators involved if the > > > needs requirement is eliminated, we would also reasonably have to > > > assume they won't be deterred by a requirement to create a stack of > > > entities under their control in practice, but nominally sufficiently > > > distinct to prevent their holdings from being aggregated for the > > > purposes of the /12 rule. > > > > > > In this post, I'm taking no position on the merits of transfers w/o > > > needs justification, just pointing out that the /12 limitation is > > > trivial to get around and is effectively a no-op. > > > > > > -- Brett > > > > > > > > > Brett, > > > > Under that same scenario, what is to stop the same speculator from > > creating 16 different legal entities that purchase IP-Enabled devices > > (i.e. pet rocks) from the parent company to show it meets it's "needs" and > > "utilization" requirements under a "needs" based regulatory requirement > > for transfers? > > > > It strikes me as a "no-op". If a dishonest actor has sufficient expertise > > and resources to fool ARIN staff into allowing more allocations then > > policy would allow, then I would argue it has equal ability to fool ARIN > > staff into believing it has legitimate need for those addresses when it > > doesn't. > > > > Tossing aside any philosophical arguments for a moment, from an entirely > > practical standpoint that's why I don't see a "needs" based requirement > > for transfers amounting to very much of anything in a scarcity market. In > > the past when the value of IPv4 address space was relatively low, it > > wasn't really worthwhile for anyone to throw alot of resources into > > obtaining more then they had a use for. Therefore effective enforcement > > didn't require a ton of resources either. If IPv4 space actually starts > > gaining some real monetary value (as it seems to have) in a scarcity > > market, unless you start throwing alot more resources at enforcement > > efforts then the effectiveness of enforcing adherence to policy > > increasingly declines. > > > > >From my perspective, in a scarcity market.....at best "needs" based > > justification controls are open enough that it becomes a non-factor one > > way or another....Anyone with a legitimate need can get approval for a > > transfer....AS can anyone who has enough resources and basic knowledge > to > > fabricate legitimate need... essentially a rubber stamp. At worst, > > enforcement efforts get increasingly complex and arbitrary....and you do > > catch alot of the people attempting to game the system.... BUT you ALSO > > get alot of false positives where organizations with real legitimate needs > > get denied simply because they lack the experience and inside knowledge > to > > know how to navigate the increasingly complex and arbitrary rules for > > demonstrating need..... and it simply becomes an "insiders" game....where > > it's not what you need but what/who you know that determines approval. > > > > Personally I'd prefer a system where speculators are allowed into a system > > to one where legitimate organizations are kept out simply because they > > lack the knowledge/experience to get past the enforcement process. > YMMV. > > This is a knee-jerk reaction, but isn't participants having or gaining the > knowledge/experience to participate in the process desirable? > Kevin, Not if the standard that you want to base allocation on is "need" rather then "inside knowledge". I have some indirect experience with such systems as my wife used to work in the administration of one of the federal assistance programs. One of the things that invariably happened was that you had a subset of applicants who had true and legitimate need that the system was intended to address but couldn't qualify for assistance because they lacked sufficient knowledge and expertise (typical recent immigrants or people with poor English skills) to pull together the documentation required under the system to demonstrate that need. At the same time, there was another subset of applicants who really should not have qualified under the spirit of the systems intent but had sufficient knowledge of the inner workings of the qualification system and resources to pull together what was required to show justification and thus gain assistance that they really didn't need. This doesn't inherently argue against the legitimacy such systems. Sometimes the genuine good such systems do outweigh any waste or corruption built into them. However, I do believe it's a legitimate factor to take under consideration when discussing the relative merits of implementing such systems. Christopher Engel (representing only my own views) From tvest at eyeconomics.com Fri May 20 15:09:52 2011 From: tvest at eyeconomics.com (Tom Vest) Date: Fri, 20 May 2011 15:09:52 -0400 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate In-Reply-To: References: <4DCFDB5C64DD4F738B65AB82D36B629D@mike> <15F92ECD-2BE5-48F2-B65A-9A9D39B98F54@delong.com> <0829B106605C4FE8B189DB2E56C69615@mike> <51506A06-D2EE-4A0D-B92B-781662094A1C@eyeconomics.com> <0CCB8AB89D144E89872AF0D635E95497@mike> <2691B7B9-1F3C-403C-B4E8-5B82BED0E191@eyeconomics.com> <454BB1826E7B4F2BB3A68BE1DD86A756@video> Message-ID: <909D6DD7-404F-4BB3-B330-78B755FAB6DA@eyeconomics.com> On May 20, 2011, at 1:24 PM, Chris Engel wrote: > Tom, > > Excising a particular section of this thread for the sake of brevity... > >> Fair enough, you prefer to argue logic rather than facts: >> >> Please provide a negative proof that "logic" could never lead any future >> address user, potential address buyer, and/or potential address seller to >> conclude that registration would not advance their own private interests. >> >> Please provide a negative proof that "logic" could never lead any future >> address user, potential address buyer, and/or potential address seller to >> embrace "sales-friendly registration" but simultaneously reject >> "operationally relevant registration" (i.e., the kind that makes whois an >> appropriate subject of interest for community deliberation). >> >> Please provide a negative proof that "logic" will BOTH always lead all future >> address users, address buyers, and address sellers to self-maintain >> "operationally relevant registration" for themselves in perpetuity, AND that >> the attainment of that outcome by means of needs-free transfers could >> never have any unintended consequences that might be as serious or more >> serious than some marginal degradation of whois accuracy. >> > > I don't think the above is a fair tactic for debate. You are asking Mike to prove a logical fallacy. Furthermore, when you start using words like "never" and "always" when discussing human behavior as benchmarks for judging the legitimacy of a system...your standards themselves appear absurd. If we applied the same standards for judging the appropriateness of a "needs" based policy, it would assuredly fail as well. Systems designed to regulate human behavior cannot achieve a uniformity of results approaching mathematical perfection, nor need they do so to be effective (IMO). > > If you want to argue that it's likely a substantial number of individuals would have logical reasons for not wanting to maintain accurate registration under the policy Mike proposes...that's (IMO) a reasonable standard to base an argument on. Not sure whether I would agree with that proposition or not...but the standard is reasonable. Asking Mike to provide a standard of proof that couldn't allow for even a single exception isn't (IMO). > > > Christopher Engel > (Representing only my own views) Hi Chris, Thanks for the reactions. Of course you are right on this count. My apologies to Mike for demanding what is, technically, logically impossible to deliver. My intent was not to be merely hyperbolic, but rather to *strongly* suggest that we all engage our imaginations fully when considering the range of strategic responses that might seem to be "rational" from the perspective of any clever entrepreneur who may or may not have any long-term interest in what happens to the Internet or to others who count the Internet for their livelihood or anything else, once s/he is done. Granted, this year we're all operating in an environment that has been significantly shaped by the unintended consequences of last year's strategic adjustments to the previous year's entrepreneurial cleverness, and so on... I mean, who could have anticipated that DWDM might trigger changes in SFP policies that helped to ignite our first crash, or that widespread diffusion of P2P might prompt another shift in commercial strategy that could in turn precipitate a run on the ASN16 reserves? Suffice it to say that there are always plenty of smart people out there working out every conceivable new angle that might be exposed by the next change in policy and/or technology and/or market structure -- and in general, at most times, we all benefit tremendously from that fact. But that only remains true as long we do not, through omission or commission, open up any loopholes that are big enough to allow to whole industry to fall through, into who-knows-what. These days it's not really possible to doubt that such things can and in fact do happen from time to time. I submit that the removal of "capability" testing would not only represent an irreversible change, but also has the potential to create a number of potentially fatal loopholes. And so in this particular case, I recommend that we proceed only if/after we can first achieve a very high level of confidence that no serious risks or threats are immediately created thereby. TV From AStiver at forumhealth.org Fri May 20 15:10:15 2011 From: AStiver at forumhealth.org (Alan Stiver) Date: Fri, 20 May 2011 15:10:15 -0400 Subject: [arin-ppml] ARIN-PPML Digest, Vol 71, Issue 192 Message-ID: My email address has changed to: alan_stiver at valleycarehealth.net Please update your records. CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, may contain information which is confidential or privileged. This information is intended to be for the sole use of the individual or entity named above. If you are not the intended recipient, please note that any unauthorized review, disclosure, copying, distribution or use of the contents of this information is strictly prohibited. If you have received this e-mail in error, please notify the sender immediately by reply e-mail or telephone and destroy all electronic and hard copies of the communication, including attachments. From mike at nationwideinc.com Fri May 20 15:56:13 2011 From: mike at nationwideinc.com (Mike Burns) Date: Fri, 20 May 2011 15:56:13 -0400 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate References: <4DCFDB5C64DD4F738B65AB82D36B629D@mike> <15F92ECD-2BE5-48F2-B65A-9A9D39B98F54@delong.com> <0829B106605C4FE8B189DB2E56C69615@mike> <51506A06-D2EE-4A0D-B92B-781662094A1C@eyeconomics.com> <0CCB8AB89D144E89872AF0D635E95497@mike> <2691B7B9-1F3C-403C-B4E8-5B82BED0E191@eyeconomics.com> <454BB1826E7B4F2BB3A68BE1DD86A756@video> <909D6DD7-404F-4BB3-B330-78B755FAB6DA@eyeconomics.com> Message-ID: <156DA5A48E51490284BC21D982A8FDAB@mike> Hello to the list, Per what Tom wrote at the bottom, I am all for considering the consequences of my proposal, intended or otherwise. So I believe the consequences we have considered, and please add to this list if you want, are: 1. Market distortions will happen due to the selfish actions of speculators, including market cornering attempts. 2. Disaggregation will increase. 3. It is too radical a change, and change should appropriately come incrementally, like extending the length of the needs window. 4. It will make it easier for bad players like spammers to get addresses. 5. It will run the risk of actually making Whois less accurate. 6. Addresses will be used less efficiently if we only rely on price to drive their productive use. I figure we have addressed these issues enough, and that we are rehashing discussions to no additional benefit. And I have had the opportunity to address the intentions of the policy proposal, which are: 1. Provides an incentive for more transactions to be registered by ARIN 2. Provides an incentive for legacy space to be brought under RSA 3. Provides for explicit protections against review audits for RSA holders after one year, bringing RSA rights more in accord with LRSA rights. 4. Reduces transaction costs for transferers 5. Reduces ARIN costs for needs analyses 6. Aligns ARIN policy with most possible interpretations of the legal rights of legacy holders 7. Imposes a yearly limit on needs-free transactions intended to prevent cornering. And likewise we have fairly addressed these issues. Without considering (any more) the merits of those prior discussions, I would like to invite the consideration of any other potential benefits or consequences which we have not discussed. I am cognizant that this is proposal is a significant departure, and that the discussion of similar policy in APNIC consumed several years. I think we have covered pretty much all the bases in our relatively short but active discussion period, but I agree with Tom that we really should stretch our minds to consider all the potential pitfalls. So did we miss anything, or is there anything left to be said on the topics arrayed above? Any large loopholes or gotchas? Risks or threats we haven't considered? Maybe the increased/decreased exposure of ARIN to lawsuits? (I will admit to enjoying reading my own words. But as they are growing tiresome to me, they must be coma-inducing to you by now.) Of course I don't mean to cutoff any discussions about any topic, if you think there is more to add. Regards, Mike ----- Original Message ----- From: "Tom Vest" To: "Chris Engel" Cc: "Mike Burns" ; Sent: Friday, May 20, 2011 3:09 PM Subject: Re: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate On May 20, 2011, at 1:24 PM, Chris Engel wrote: > Tom, > > Excising a particular section of this thread for the sake of brevity... > >> Fair enough, you prefer to argue logic rather than facts: >> >> Please provide a negative proof that "logic" could never lead any future >> address user, potential address buyer, and/or potential address seller to >> conclude that registration would not advance their own private interests. >> >> Please provide a negative proof that "logic" could never lead any future >> address user, potential address buyer, and/or potential address seller to >> embrace "sales-friendly registration" but simultaneously reject >> "operationally relevant registration" (i.e., the kind that makes whois an >> appropriate subject of interest for community deliberation). >> >> Please provide a negative proof that "logic" will BOTH always lead all >> future >> address users, address buyers, and address sellers to self-maintain >> "operationally relevant registration" for themselves in perpetuity, AND >> that >> the attainment of that outcome by means of needs-free transfers could >> never have any unintended consequences that might be as serious or more >> serious than some marginal degradation of whois accuracy. >> > > I don't think the above is a fair tactic for debate. You are asking Mike > to prove a logical fallacy. Furthermore, when you start using words like > "never" and "always" when discussing human behavior as benchmarks for > judging the legitimacy of a system...your standards themselves appear > absurd. If we applied the same standards for judging the appropriateness > of a "needs" based policy, it would assuredly fail as well. Systems > designed to regulate human behavior cannot achieve a uniformity of results > approaching mathematical perfection, nor need they do so to be effective > (IMO). > > If you want to argue that it's likely a substantial number of individuals > would have logical reasons for not wanting to maintain accurate > registration under the policy Mike proposes...that's (IMO) a reasonable > standard to base an argument on. Not sure whether I would agree with that > proposition or not...but the standard is reasonable. Asking Mike to > provide a standard of proof that couldn't allow for even a single > exception isn't (IMO). > > > Christopher Engel > (Representing only my own views) Hi Chris, Thanks for the reactions. Of course you are right on this count. My apologies to Mike for demanding what is, technically, logically impossible to deliver. My intent was not to be merely hyperbolic, but rather to *strongly* suggest that we all engage our imaginations fully when considering the range of strategic responses that might seem to be "rational" from the perspective of any clever entrepreneur who may or may not have any long-term interest in what happens to the Internet or to others who count the Internet for their livelihood or anything else, once s/he is done. Granted, this year we're all operating in an environment that has been significantly shaped by the unintended consequences of last year's strategic adjustments to the previous year's entrepreneurial cleverness, and so on... I mean, who could have anticipated that DWDM might trigger changes in SFP policies that helped to ignite our first crash, or that widespread diffusion of P2P might prompt another shift in commercial strategy that could in turn precipitate a run on the ASN16 reserves? Suffice it to say that there are always plenty of smart people out there working out every conceivable new angle that might be exposed by the next change in policy and/or technology and/or market structure -- and in general, at most times, we all benefit tremendously from that fact. But that only remains true as long we do not, through omission or commission, open up any loopholes that are big enough to allow to whole industry to fall through, into who-knows-what. These days it's not really possible to doubt that such things can and in fact do happen from time to time. I submit that the removal of "capability" testing would not only represent an irreversible change, but also has the potential to create a number of potentially fatal loopholes. And so in this particular case, I recommend that we proceed only if/after we can first achieve a very high level of confidence that no serious risks or threats are immediately created thereby. TV From owen at delong.com Fri May 20 18:12:35 2011 From: owen at delong.com (Owen DeLong) Date: Fri, 20 May 2011 15:12:35 -0700 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate In-Reply-To: References: <4DCFDB5C64DD4F738B65AB82D36B629D@mike> Message-ID: On May 20, 2011, at 9:42 AM, Larry Ash wrote: > Hi Owen, > Owen DeLong wrote: >> On May 19, 2011, at 4:59 PM, Matthew Kaufman wrote: >>> On 5/19/2011 4:48 PM, Mike Burns wrote: >>>> And you believe this and still think there is a danger from speculators? When the market is at most 4 years in duration and then subject to collapse due to IPv6? >>> That's really the best question. Who are the speculators that we're worried about who have enough cash to actually affect the price of IP address space and availability *and* who are stupid enough to do that when they know a collapse is coming soon? >> Speculation for profit is not the only form of speculation I am concerned about, but, even that if you corner the market at T0 and sell it all off at T2 >> with a 200% price increase is damaging. >> The form that worries me the most, however, is if $MEGA_TELCO and $MEGA_CABLECO purchase all of the available addresses as they come on >> the market, leaving nothing for their smaller less capitalized competitors to use, they may be bale to forestall (and would now have a financial >> interest in doing so) their IPv6 deployments for enough years to seriously damage their competitors that had no non-IPv6 alternative. > > Unfortunately this may already have happened. One of my techs in a conversation > with a cable tech (low level so take with a little grain of salt) was told > that the cable company he worked for (changed owners recently so I'm not sure > who the parent currently is) and comcast have gotten so much IPV4 that there is > no shortage in V4 addresses and that they had no plans in converting to IPV6. > The current needs basis may have been too loose to accomplish the purpose it > was intended to do. > Comcast is definitely moving forward with IPv6, they've made numerous public statements and have even begun delivering some level of IPv6 services to trial users. Further, the idea that a single-sided retention of IPv4-only is feasible is as laughably absurd as the idea that a single-sided migration to IPv6-only is feasible. You need a common protocol at both ends to make the internet work and there are enough end-points that will be forced to go with IPv6 that nobody will be able to remain IPv4-only for all that long, regardless of their supply of addresses. Owen From owen at delong.com Fri May 20 18:15:56 2011 From: owen at delong.com (Owen DeLong) Date: Fri, 20 May 2011 15:15:56 -0700 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate In-Reply-To: References: <4DCFDB5C64DD4F738B65AB82D36B629D@mike><15F92ECD-2BE5-48F2-B65A-9A9D39B98F5 4@delong.com><0829B106605C4FE8B189DB2E56C69615@mike><8FB24038-B813-4DE0-91DD-56EDAD31BC03@delong.com><36A3A11C7EDF413C9E2EC07FD 0C122E0@mike> <8F23AB4955E3404393B1E03831C91054@mike> <6397CBB3-8145-43E7-8288-132F19B89E3F@delong.com> <4DD56EBB.70102@matthew.at> <5CABD084-E16C-4FA1-84E1-E5CA9F899144@delong.com> <4DD58B38.206@matthew.at> <4DD5AEFD.3060901@matthew.at> Message-ID: <0FEC148D-E4CE-4F70-AA15-811C5F735707@delong.com> On May 20, 2011, at 10:33 AM, Chris Engel wrote: > > >> >> On May 19, 2011, at 4:59 PM, Matthew Kaufman wrote: >> >>> On 5/19/2011 4:48 PM, Mike Burns wrote: >>>> >>>> And you believe this and still think there is a danger from speculators? >> When the market is at most 4 years in duration and then subject to collapse >> due to IPv6? >>> >>> >>> That's really the best question. Who are the speculators that we're worried >> about who have enough cash to actually affect the price of IP address space >> and availability *and* who are stupid enough to do that when they know a >> collapse is coming soon? >>> >> >> Speculation for profit is not the only form of speculation I am concerned >> about, but, even that if you corner the market at T0 and sell it all off at T2 >> with a 200% price increase is damaging. >> >> The form that worries me the most, however, is if $MEGA_TELCO and >> $MEGA_CABLECO purchase all of the available addresses as they come on >> the market, leaving nothing for their smaller less capitalized competitors to >> use, they may be bale to forestall (and would now have a financial >> interest in doing so) their IPv6 deployments for enough years to seriously >> damage their competitors that had no non-IPv6 alternative. >> >> I see no reason to produce policy that enables this behavior and many >> reasons not to. >> >>> Also, if these speculators are really so bad, won't all the altruistic sellers >> (some of whom are represented in this discussion, no doubt) simply refuse >> to sell to them at *any* price, but have nice low prices for non-profits and >> other good causes that need space? >>> >> >> I think this presumes a number of facts not in evidence, not the least of >> which is that one can readily determine that your purchaser is, >> in fact, such a speculator. >> >> Owen > > Owen, > > Playing devil's advocate for a moment, If an organization were able to receive substantial capital from divesting itself of it's IPv4 address space, wouldn't that go a long way toward mitigating one of the significant impediments that organizations face in regards IPv6 adoption today.....namely that the cost for adoption does not justify the perceived benefits? > By the time divesting of your IPv4 space would be feasible in this manner (sufficient critical mass of the rest of the internet is on IPv6), you would be at a point where there would be no impediment to adopting IPv6 and the IPv4 address value would have dropped below what would be necessary. The impediment at that point would already have migrated to the extreme cost of using IPv4 to talk to an increasingly IPv6 world. Owen From owen at delong.com Fri May 20 18:41:11 2011 From: owen at delong.com (Owen DeLong) Date: Fri, 20 May 2011 15:41:11 -0700 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate In-Reply-To: <156DA5A48E51490284BC21D982A8FDAB@mike> References: <4DCFDB5C64DD4F738B65AB82D36B629D@mike> <15F92ECD-2BE5-48F2-B65A-9A9D39B98F54@delong.com> <0829B106605C4FE8B189DB2E56C69615@mike> <51506A06-D2EE-4A0D-B92B-781662094A1C@eyeconomics.com> <0CCB8AB89D144E89872AF0D635E95497@mike> <2691B7B9-1F3C-403C-B4E8-5B82BED0E191@eyeconomics.com> <454BB1826E7B4F2BB3A68BE1DD86A756@video> <909D6DD7-404F-4BB3-B330-78B755FAB6DA@eyeconomics.com> <156DA5A48E51490284BC21D982A8FDAB@mike> Message-ID: <77310136-54C6-43F0-9923-E7810DD2736D@delong.com> On May 20, 2011, at 12:56 PM, Mike Burns wrote: > Hello to the list, > > Per what Tom wrote at the bottom, I am all for considering the consequences of my proposal, intended or otherwise. > > So I believe the consequences we have considered, and please add to this list if you want, are: > > 1. Market distortions will happen due to the selfish actions of speculators, including market cornering attempts. > 2. Disaggregation will increase. > 3. It is too radical a change, and change should appropriately come incrementally, like extending the length of the needs window. > 4. It will make it easier for bad players like spammers to get addresses. > 5. It will run the risk of actually making Whois less accurate. > 6. Addresses will be used less efficiently if we only rely on price to drive their productive use. > > I figure we have addressed these issues enough, and that we are rehashing discussions to no additional benefit. > Agreed, actually. > And I have had the opportunity to address the intentions of the policy proposal, which are: > > 1. Provides an incentive for more transactions to be registered by ARIN No, this is not accurate. It provides no incentive. It does reduce disincentive to register transactions that the community might not look upon favorably. It does not create incentives. > 2. Provides an incentive for legacy space to be brought under RSA I don't see this in any way shape or form. Can you please explain how, exactly, removal of needs basis influences this in any way? > 3. Provides for explicit protections against review audits for RSA holders after one year, bringing RSA rights more in accord with LRSA rights. Uh, yeah, I don't see that as a good thing. Quite the opposite. However, I do agree that it is an intended consequence of the proposal. > 4. Reduces transaction costs for transferers I believe it will actually increase them. > 5. Reduces ARIN costs for needs analyses Agreed, but, not necessarily something I see as a beneficial aspect. > 6. Aligns ARIN policy with most possible interpretations of the legal rights of legacy holders No, aligns ARIN policy with one possible interpretation of the legal rights of legacy holders. IMHO, not even the most probable one. > 7. Imposes a yearly limit on needs-free transactions intended to prevent cornering. Yes, but, this limit is effectively a no-op because anyone can create multiple entities needed to accomplish enough /12 transfers to meet their desires. > > And likewise we have fairly addressed these issues. > To some extent. > Without considering (any more) the merits of those prior discussions, I would like to invite the consideration of any other potential benefits or consequences which we have not discussed. > I am cognizant that this is proposal is a significant departure, and that the discussion of similar policy in APNIC consumed several years. As it did here prior to being rejected here and accepted there. > I think we have covered pretty much all the bases in our relatively short but active discussion period, but I agree with Tom that we really should stretch our minds to consider all the potential pitfalls. > So did we miss anything, or is there anything left to be said on the topics arrayed above? Any large loopholes or gotchas? Risks or threats we haven't considered? One I think worth exploring is that given the recent staff interpretation of the term RSA in policy, the requirement for RSA in the proposal may be insufficiently specific to express community intent. > Maybe the increased/decreased exposure of ARIN to lawsuits? I think this would not significantly impact the legal exposure. We are as likely to get sued by someone unable to obtain resources in the market on the basis that we failed to properly regulate need in the market as we are to get sued by someone opposed to our attempts to regulate need, IMHO. > > (I will admit to enjoying reading my own words. But as they are growing tiresome to me, they must be coma-inducing to you by now.) > It's been a good debate, IMHO and I agree we have both well established our positions. Owen From springer at inlandnet.com Fri May 20 18:55:56 2011 From: springer at inlandnet.com (John Springer) Date: Fri, 20 May 2011 15:55:56 -0700 (PDT) Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate In-Reply-To: References: <4DCFDB5C64DD4F738B65AB82D36B629D@mike> <15F92ECD-2BE5-48F2-B65A-9A9D39B98F54@delong.com> <0829B106605C4FE8B189DB2E56C69615@mike> <8FB24038-B813-4DE0-91DD-56EDAD31BC03@delong.com> <36A3A11C7EDF413C9E2EC07FD0C122E0@mike> <20110519141211.V77468@mail.inlandnet.com> Message-ID: <20110520111511.B56491@mail.inlandnet.com> Hi Mike, I am going to rearrange the top post down under the message to which you are replying, for clarity, after which I will comment upon your reply, in line. I'm getting closer to the point of replying to the actual proposal which has a different subject line. On Thu, 19 May 2011, Mike Burns wrote: > > ----- Original Message ----- From: "John Springer" > To: "Mike Burns" > Cc: "Owen DeLong" ; > Sent: Thursday, May 19, 2011 7:31 PM > Subject: Re: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate > > >> Hi Mike, >> >> Not ready to opine on the proposal yet but I am going to quote and reply to >> one section of this particular post. Down below. >> >> On Thu, 19 May 2011, Mike Burns wrote: >> >>> As to Microsoft planning leading them to purchasing the same exact need as >>> ARIN's particular application of its policies at the time of the >>> transaction? >>> Please. >>> Remember that Microsoft was an arms-length negotiator who was solicited by >>> the address broker in the deal along with 80 other companies. >>> So Microsoft's planning was so excellent that they could find the exact >>> amount of addresses they needed in the form of the very first public sale >>> of legacy addresses ever recorded? >>> That's believable! >>> And their excellent planning staff, whose decision so exactly matched >>> ARIN's ex-post-facto analysis, failed to inform management that they could >>> save $7.5 million by getting them directly from ARIN? >> >> This is, IMO, of limited utility. To reiterate, the question of whether or >> not the MS/NN transfer followed ARIN policy was, IIRC, asked by several and >> answered rather authoritatively by Curran. The actual detailed facts of the >> matter are unlikely to be known. Or perhaps, as you point out, there is an >> NDA with a time limit. Are the detailed facts of the matter so critical >> that we should wait until they are knowable before deciding on this policy >> proposal? If not, further assertions such as the above can be true as the >> night and still be logically useless when trying to refute something that >> is so completely non-falsifiable. Continuing to put forward such comments >> only serves to shift attention from otherwise mostly logical and >> considerable remarks to ones that are neither. >> >> Just sayin'. >> >> John Springer > > > Hi John, > > I am being assailed with claims that very very few transactions will > occur which will not meet the ARIN needs requirements. > And requests for proof that these transactions have, and will, occur. I noticed, but not by me, and maybe so, but such claims and requests are orthogonal to my objection. I do hear you say though, that you are responding to my objections by replying to those other claims. > The facts of the matter have been laid out, and all I said was that this > alignment with ex-post-facto need determination and the already negotiated > sale was fortuitous. Point taken. My response is that your point is not germane to my objection. > http://www.networkworld.com/news/2011/051111-nortel-ipv4-sale.html This is all typical trade press bloviation; guesses, speculation, and all equally immaterial. No one cited in that article demonstrates more facts than you, and all have less than Curran. It is very embarrassing to me to be so publicly and obviously unable to convey the concept: "The detailed facts as to whether ARIN policy was followed WRT the MS/NN transfer are not and will not be known in time to matter to this proposal". However, no amount of speculation, guessing, inferring or wishing by any amount of people can possibly provide sufficient grounds for making policy removing justified need, IMO. ARIN policy followed vs I don't think so, CANNOT BE PROVED OR DISPROVED AT THIS TIME. This is what non-falsifiable means. It means that continuing to assert otherwise is not science or logic, but unsupported denial. It does no good to continue to assert/suggest/rebut/inuend or not understand. There must be other reasons to support the proposal that we get rid of needs assessment, because the volume of posts is very large. Please use them. Exclusively. Because this one is no good. Seriously. Perhaps I am incurring additional well deserved opprobrium by not recognizing that you have conceded this single point. > Per the article above, I am not by any means alone in my perception that the > MS/Nortel deal very easily could have occurred outside ARIN's purview had not > the crucial factor of the needs analysis been met. MS and Nortel could also very easily have occured some other irrelevant nonsense and it would have had equivalent bearing on the question "Was ARIN policy followed?", which was and is just about the only subject of my post. "Not ... alone in my perception" is more bandwagon fallacy, Argumentum ad populum. Just because there are several of you who assert similar things does not prove the assertions. > Nothing that I said in the paragraph you reference is contrary to John > Curran's answer about the MS/Nortel deal, nor does it involve NDA > information. Let's examine this statement: >>> As to Microsoft planning leading them to purchasing the same exact need as >>> ARIN's particular application of its policies at the time of the >>> transaction? >>> Please. This has no value or meaning to me other than to dispute that ARIN policy was followed. >>> Remember that Microsoft was an arms-length negotiator who was solicited by >>> the address broker in the deal along with 80 other companies. >>> So Microsoft's planning was so excellent that they could find the exact >>> amount of addresses they needed in the form of the very first public sale >>> of legacy addresses ever recorded? >>> That's believable! This has no value or meaning to me other than to dispute that ARIN policy was followed. >>> And their excellent planning staff, whose decision so exactly matched >>> ARIN's ex-post-facto analysis, failed to inform management that they could >>> save $7.5 million by getting them directly from ARIN? This has no value or meaning to me other than to dispute that ARIN policy was followed. So, your statement was correct in that what you said does not involve NDA information. The rest of your statement was incorrect though, in that it is all intended to refute John Curran's statement that ARIN policy was followed WRT to the MS/NN deal. Which I'm sure you have noticed by now, I assert may not be actually done with the information currently available. > The deal was made and negotiated prior to ARIN's involvement, and should > other such deals occur, if their needs requirement is not recognized by ARIN, > the deal goes down off the books. Are you going to come right out and say that you do think you can PROVE that ARIN policy was not followed WRT to the MS/NN deal. Because that is what is implied in all of these otherwise meaningless assertions. > And I reiterate that ARIN head Plzak > declared that ARIN does not control legacy addresses. That means to me at the > very least that legacy deals can be done without notifying ARIN, and if > notifying ARIN requires the transactors to undergo a needs test, and not > notifying ARIN has little cost in terms of routabilty, then the transaction > will occur and the community will be in the dark. This is getting hard(er) to follow. Are you saying that Ray was involved with the MS/NN transfer? If not, any statements that he made while he was CEO and/or President must necessarily not be informed by any FACTS of the current matter, as he stepped down some time ago. And if he is privy to facts not in evidence now, I fail to see how that relates to a statement he made long ago. As far as the "That means to me" section (unclipped text above): if "deals can be done without notifying ARIN" OK, so I hear. andif "not notifying ARIN has little cost in terms of routabilty" I have heard a lot of hypotheticals about this, maybe yes, maybe no, but say OK. "then the transaction will occur and the community will be in the dark." I suppose that is possible. But the subject line of this thread notwithstanding, I thought you removed any Whois related rationale from this proposal. And that this proposal was only about removing the needs assessment and exempting proposed transferers from section 12 jeopardy. This section does not seem to have anything to do with either of those proposals. > Regards, > Mike regards, John Springer From mike at nationwideinc.com Fri May 20 23:08:55 2011 From: mike at nationwideinc.com (Mike Burns) Date: Fri, 20 May 2011 23:08:55 -0400 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate References: <4DCFDB5C64DD4F738B65AB82D36B629D@mike> <15F92ECD-2BE5-48F2-B65A-9A9D39B98F54@delong.com> <0829B106605C4FE8B189DB2E56C69615@mike> <51506A06-D2EE-4A0D-B92B-781662094A1C@eyeconomics.com> <0CCB8AB89D144E89872AF0D635E95497@mike> <2691B7B9-1F3C-403C-B4E8-5B82BED0E191@eyeconomics.com> <454BB1826E7B4F2BB3A68BE1DD86A756@video> <909D6DD7-404F-4BB3-B330-78B755FAB6DA@eyeconomics.com> <156DA5A48E51490284BC21D982A8FDAB@mike> <77310136-54C6-43F0-9923-E7810DD2736D@delong.com> Message-ID: <059E9D87D0D8420D8EAE18BF78F1FA88@video> Hi Owen, >No, this is not accurate. It provides no incentive. It does reduce >disincentive to register transactions >that the community might not look upon favorably. It does not create >incentives. OK, it's intention is to remove disincentives to register transactions. >> 2. Provides an incentive for legacy space to be brought under RSA >I don't see this in any way shape or form. Can you please explain how, >exactly, removal of needs >basis influences this in any way? Because legacy addresses can be bought and sold without a needs requirement, per the finding of "exclusive right to transfer" in the MS case, and the Plzak declaration as the head of ARIN, that ARIN has no authority over legacy addresses. You may disagree, but the Plzak declaration is very clear. Given this, legal legacy transfers can occur where the purchased amount may not meet ARIN's need requirement. If the buyer cannot meet the requirement, he will not register the addresses, although I have argued he will likely want the addresses registered to reflect his ownership of their rights. But if there is no needs requirement, the disincentive is removed, the registration takes place, and the buyer signs an RSA. My proposal also reduces the disincentive to sign the RSA, as it removes the utilization requirement and frees the buyer to resell the addresses to anybody, with or without need. (Unless that buyer already has transferred a /12 equivalent). So I believe the net effect of the proposal is to make the RSA more attractive, and reduce the disincentive for registration of legacy transfers which do not meet the needs test. Remember, these are the intentions of the proposal, although I know you disagree with my legal interpretation, and thus the effect. > 3. Provides for explicit protections against review audits for RSA holders > after one year, bringing RSA rights more in accord with LRSA rights. >Uh, yeah, I don't see that as a good thing. Quite the opposite. However, I >do agree that it is an intended >consequence of the proposal. >> 4. Reduces transaction costs for transferers >I believe it will actually increase them. The intent of the proposal is that transactional costs related to the needs analysis can be avoided. These may be large or small. I suppose you mean the prices will be higher due to speculation, though. >> 5. Reduces ARIN costs for needs analyses >Agreed, but, not necessarily something I see as a beneficial aspect. >> 6. Aligns ARIN policy with most possible interpretations of the legal >> rights of legacy holders >No, aligns ARIN policy with one possible interpretation of the legal rights >of legacy holders. >IMHO, not even the most probable one. See "exclusive right to transfer" and the Plzak declaration that ARIN has no authority over legacy addresses. Would it be fair to say "Aligns ARIN policy with legal interpretation most friendly to legacy holders?" My point being this alignment presents the lowest risk toARIN of being sued for tortious interference in a contract. >> 7. Imposes a yearly limit on needs-free transactions intended to prevent >> cornering. >Yes, but, this limit is effectively a no-op because anyone can create >multiple entities needed >to accomplish enough /12 transfers to meet their desires. I trust ARIN staff to detect these with the same diligence applied to needs tests and section 12 reviews. > >> And likewise we have fairly addressed these issues. > >To some extent. >> Without considering (any more) the merits of those prior discussions, I >> would like to invite the consideration of any other potential benefits or >> consequences which we have not discussed. >> I am cognizant that this is proposal is a significant departure, and that >> the discussion of similar policy in APNIC consumed several years. >As it did here prior to being rejected here and accepted there. I didn't know there had also been prior discussion here about this (or fairly similar) policy. Do you rember about when so I can search the archives? >> I think we have covered pretty much all the bases in our relatively short >> but active discussion period, but I agree with Tom that we really should >> stretch our minds to consider all the potential pitfalls. >> So did we miss anything, or is there anything left to be said on the >> topics arrayed above? Any large loopholes or gotchas? Risks or threats we >> haven't considered? >One I think worth exploring is that given the recent staff interpretation >of the term RSA in policy, >the requirement for RSA in the proposal may be insufficiently specific to >express community >intent. I agree, though my intention was that it was the RSA, not an LRSA, but the RSA modified by my proposal. >> Maybe the increased/decreased exposure of ARIN to lawsuits? >I think this would not significantly impact the legal exposure. We are as >likely to get sued >by someone unable to obtain resources in the market on the basis that we >failed to properly >regulate need in the market as we are to get sued by someone opposed to our >attempts >to regulate need, IMHO. I can't see any legal right to sue ARIN if the community decides to drop the needs policy, but I am not a lawyer. I wonder if anybody has sued APNIC on that basis? Maybe the ARIN legal staff can comment on that. But I can sure see somebody suing ARIN if ARIN re-issues their address to another allocant. If ARIN's legal interpretation is that they can revoke legacy addresses if they are not utilized, for example, that leads to their reissuance, and legal trouble. If ARIN's legal interpretation is that legacy addresses are outside its authority, that risk is minimalized. > >> (I will admit to enjoying reading my own words. But as they are growing >> tiresome to me, they must be coma-inducing to you by now.) > >It's been a good debate, IMHO and I agree we have both well established our >positions. >Owen Ditto. Regards, Mike From owen at delong.com Sat May 21 00:32:45 2011 From: owen at delong.com (Owen DeLong) Date: Fri, 20 May 2011 21:32:45 -0700 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate In-Reply-To: <059E9D87D0D8420D8EAE18BF78F1FA88@video> References: <4DCFDB5C64DD4F738B65AB82D36B629D@mike> <15F92ECD-2BE5-48F2-B65A-9A9D39B98F54@delong.com> <0829B106605C4FE8B189DB2E56C69615@mike> <51506A06-D2EE-4A0D-B92B-781662094A1C@eyeconomics.com> <0CCB8AB89D144E89872AF0D635E95497@mike> <2691B7B9-1F3C-403C-B4E8-5B82BED0E191@eyeconomics.com> <454BB1826E7B4F2BB3A68BE1DD86A756@video> <909D6DD7-404F-4BB3-B330-78B755FAB6DA@eyeconomics.com> <156DA5A48E51490284BC21D982A8FDAB@mike> <77310136-54C6-43F0-9923-E7810DD2736D@delong.com> <059E9D87D0D8420D8EAE18BF78F1FA88@video> Message-ID: <2802FCB9-1D0A-43AA-81BB-C3A93AAA7B45@delong.com> On May 20, 2011, at 8:08 PM, Mike Burns wrote: > > Hi Owen, > >> No, this is not accurate. It provides no incentive. It does reduce disincentive to register transactions >> that the community might not look upon favorably. It does not create incentives. > > OK, it's intention is to remove disincentives to register transactions. > >>> 2. Provides an incentive for legacy space to be brought under RSA > >> I don't see this in any way shape or form. Can you please explain how, exactly, removal of needs >> basis influences this in any way? > > Because legacy addresses can be bought and sold without a needs requirement, per the finding of "exclusive right to transfer" in the MS case, and the Plzak declaration as the head of ARIN, that ARIN has no authority over legacy addresses. You may disagree, but the Plzak declaration is very clear. No, this is an incorrect understanding of the ruling. The Plzak declaration is also not the final word on the subject. The exclusive right to transfer means that nobody else has the right to transfer them. It does not mean that they can be transfered regardless of policy or that ARIN must recognize a transfer outside of policy in the ARIN database. Legacy addresses were issued to a particular party for a particular purpose. Upon the end of that purpose or that party, they should be returned and are no longer legacy addresses. In the case of a transfer to a successor in interest through acquisition or merger, in some cases, the legacy status has been preserved, but, this is rare. In most cases, the receiving organization has been required to sign an ARIN standard RSA. It works this way... Legacy status is the intersection of the holder and the resources which were registered together by a registry preceding the RIR system. Once either of those conditions ceases, the resources are no longer in legacy status (in most cases). ARIN has an obligation to continue providing services to records with legacy status so long as that legacy status remains under the original terms of issue. ARIN has the right to reclaim addresses from defunct legacy organizations. > Given this, legal legacy transfers can occur where the purchased amount may not meet ARIN's need requirement. Not true. At least not if they want to be recognized by ARIN and have the transfer registered in whois. > If the buyer cannot meet the requirement, he will not register the addresses, although I have argued he will likely want the addresses registered to reflect his ownership of their rights. The unregistered addresses become subject to reclamation since they are no longer in use by the original organization under the original terms of issue. > But if there is no needs requirement, the disincentive is removed, the registration takes place, and the buyer signs an RSA. Ah, so you are once again confusing incentive with removal of disincentive. I can see how, to a limited extent, this might provide less of a disincentive for the recipient of a transfer from a legacy holder to register the transfer, but, I don't see how this is anything other than redundant to your point 1. > My proposal also reduces the disincentive to sign the RSA, as it removes the utilization requirement and frees the buyer to resell the addresses to anybody, with or without need. (Unless that buyer already has transferred a /12 equivalent). Yes, by neutering the RSA, you have removed some disincentives to sign it. However, I don't see neutering the RSA as a net positive in that regard. The community put section 12 into policy for a reason. > So I believe the net effect of the proposal is to make the RSA more attractive, and reduce the disincentive for registration of legacy transfers which do not meet the needs test. There is no such thing as a legacy transfer. There is a transfer of resources from a legacy holder, but, absent an awkward situation involving litigation these will almost always result in the space being handled as non-legacy if the transfer is recognized by ARIN. > > Remember, these are the intentions of the proposal, although I know you disagree with my legal interpretation, and thus the effect. > Yes... Your legal interpretation being contrary to statements made by ARIN counsel and John Curran, I am inclined to believe that it is not correct and therefore the effect of your proposal differs from your claimed effects. > >> 3. Provides for explicit protections against review audits for RSA holders after one year, bringing RSA rights more in accord with LRSA rights. > >> Uh, yeah, I don't see that as a good thing. Quite the opposite. However, I do agree that it is an intended >> consequence of the proposal. > >>> 4. Reduces transaction costs for transferers > >> I believe it will actually increase them. > > The intent of the proposal is that transactional costs related to the needs analysis can be avoided. These may be large or small. I suppose you mean the prices will be higher due to speculation, though. > Yes, I believe that the net price of the transaction will increase substantially. Further, the cost of needs analysis is built into the ARIN transfer fee which I do not think will change significantly as a result of this proposal. So, no price reduction and likely price increase. Doesn't look like a savings to me. >>> 5. Reduces ARIN costs for needs analyses > >> Agreed, but, not necessarily something I see as a beneficial aspect. > > >>> 6. Aligns ARIN policy with most possible interpretations of the legal rights of legacy holders > >> No, aligns ARIN policy with one possible interpretation of the legal rights of legacy holders. >> IMHO, not even the most probable one. > > See "exclusive right to transfer" and the Plzak declaration that ARIN has no authority over legacy addresses. > Would it be fair to say "Aligns ARIN policy with legal interpretation most friendly to legacy holders?" > My point being this alignment presents the lowest risk toARIN of being sued for tortious interference in a contract. > You have already been told multiple times that your interpretation of the words "exclusive right to transfer" is not correct. The Plzack declaration was substantially modified by later rulings in the Kremen case. >>> 7. Imposes a yearly limit on needs-free transactions intended to prevent cornering. > >> Yes, but, this limit is effectively a no-op because anyone can create multiple entities needed >> to accomplish enough /12 transfers to meet their desires. > > I trust ARIN staff to detect these with the same diligence applied to needs tests and section 12 reviews. > It doesn't matter. If they are different organizations, ARIN can't claim that they aren't different organizations for policy purpose just because it's clear that they were created for the purpose of doing an end-run on the policy. ARIN must interpret the policy as written, even if that interpretation appears absurd, as in the case of the single aggregate clause in the transfer policy. >> >>> And likewise we have fairly addressed these issues. >> > >> To some extent. > >>> Without considering (any more) the merits of those prior discussions, I would like to invite the consideration of any other potential benefits or consequences which we have not discussed. >>> I am cognizant that this is proposal is a significant departure, and that the discussion of similar policy in APNIC consumed several years. > >> As it did here prior to being rejected here and accepted there. > > I didn't know there had also been prior discussion here about this (or fairly similar) policy. Do you rember about when so I can search the archives? > In the early stages of 2008-2, there was discussion of a transfer policy without needs basis, at least among the AC before we formulated 2008-2. I believe it was rejected by the community pretty much out of hand fairly early in the discussion either at open policy hours and/or at the public policy meetings, but, it may have just been within the AC. After three years and a whole lot of policy work, I have to admit my memory on exactly when and where a given discussion took place is somewhat fuzzy. >>> I think we have covered pretty much all the bases in our relatively short but active discussion period, but I agree with Tom that we really should stretch our minds to consider all the potential pitfalls. >>> So did we miss anything, or is there anything left to be said on the topics arrayed above? Any large loopholes or gotchas? Risks or threats we haven't considered? > >> One I think worth exploring is that given the recent staff interpretation of the term RSA in policy, >> the requirement for RSA in the proposal may be insufficiently specific to express community >> intent. > > I agree, though my intention was that it was the RSA, not an LRSA, but the RSA modified by my proposal. > Understood, but, staff has made it quite clear that they will not interpret the policy as written in that manner. Unfortunately, I am not sure that we can actually influence the choice of RSA through policy. I'm hoping that a public clarification of this issue will be forthcoming soon. >>> Maybe the increased/decreased exposure of ARIN to lawsuits? > >> I think this would not significantly impact the legal exposure. We are as likely to get sued >> by someone unable to obtain resources in the market on the basis that we failed to properly >> regulate need in the market as we are to get sued by someone opposed to our attempts >> to regulate need, IMHO. > > I can't see any legal right to sue ARIN if the community decides to drop the needs policy, but I am not a lawyer. This is the united States. Anyone can sue anyone for just about anything. > I wonder if anybody has sued APNIC on that basis? Entirely different legal system(s). > Maybe the ARIN legal staff can comment on that. > But I can sure see somebody suing ARIN if ARIN re-issues their address to another allocant. ARIN wouldn't do that. What ARIN might do is issue addresses they have been hijacking to another registrant, but, the point of policy is that it does not protect hijackers from this. If you want the protections of guaranteed uniqueness, you have to play by the rules. If you do an unregistered transfer, then, you aren't a registrant, you are a squatter at best and a hijacker at worst. > If ARIN's legal interpretation is that they can revoke legacy addresses if they are not utilized, for example, that leads to their reissuance, and legal trouble. If they are still held by the original organization, generally ARIN will not do this. If they are being used by an unregistered organization for an unregistered purpose, ARIN will probably first try to contact the original organization to verify the intent. If a transfer was intended, ARIN would probably first attempt to work with that organization to see if an 8.2 or 8.3 transfer could be made to fit the situation somehow. If they cannot, or, the party using the addresses is unwilling to cooperate in that process, then, I have no problem with ARIN reclaiming the addresses and I think that is the correct course of action. > If ARIN's legal interpretation is that legacy addresses are outside its authority, that risk is minimalized. So long as they are held by the original legacy registrant or their successor in interest, I believe ARIN will continue to provide registration services to them. There is a difference between not reclaiming them and believing that they are outside of ARIN authority, however. > Owen -------------- next part -------------- An HTML attachment was scrubbed... URL: From dogwallah at gmail.com Sat May 21 03:34:07 2011 From: dogwallah at gmail.com (McTim) Date: Sat, 21 May 2011 10:34:07 +0300 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate In-Reply-To: <156DA5A48E51490284BC21D982A8FDAB@mike> References: <4DCFDB5C64DD4F738B65AB82D36B629D@mike> <15F92ECD-2BE5-48F2-B65A-9A9D39B98F54@delong.com> <0829B106605C4FE8B189DB2E56C69615@mike> <51506A06-D2EE-4A0D-B92B-781662094A1C@eyeconomics.com> <0CCB8AB89D144E89872AF0D635E95497@mike> <2691B7B9-1F3C-403C-B4E8-5B82BED0E191@eyeconomics.com> <454BB1826E7B4F2BB3A68BE1DD86A756@video> <909D6DD7-404F-4BB3-B330-78B755FAB6DA@eyeconomics.com> <156DA5A48E51490284BC21D982A8FDAB@mike> Message-ID: Hi, Apologies for the length of this posting. On Fri, May 20, 2011 at 10:56 PM, Mike Burns wrote: > Hello to the list, > arrayed above? Any large loopholes or gotchas? Risks or threats we haven't > considered? In November, at the AfriNIC meeting, I gave a presentation on "Emerging Threats to the RIR system". You can find that one here: http://meeting.afrinic.net/afrinic-13/images/stories/af13_presentation/AF-13-24/Emerging_threats_to_RIR.pdf This proposal has outlined a more serious threat than any in my presentation, that is the threat of removing the need any need for a PDP. I think we are on a very slippery slope to a dystopic future in which all access to IP addresses (v4 or v6) are done on a "cash n carry" basis. Currently, we are near the top of that steep and slippery slide, sitting on a sturdy branch (which we call "needs-basis" or TV's "capability" testing) of a stout tree (species STLS). The next ledge down is where APNIC sits. They call it prop-050. Below that we can see other ledges and trees where we might stop on the way down, including the shelf of inter-RIR transfer, the slender branch of RIR verification, etc, etc, all the way down into the festering swamp of de-aggregation. Put another way STLS-->removal of needs basis-->removal of RIR involvement in transfers/addition of private registries--> full commoditisation of v4-->commoditisation of v6-->removal of any needs to have policy-->elimination of IP address policy communities/PDPs. There will always be folk who will argue for the purest form of a "free-market", which as we know is mostly theoretical. Once v4 is fully commoditised, there will inevitably be folk who want to do the same to v6. I can hear the arguments now "hey if we can buy and sell v4, why not v6, after all they are the same thing, they are both IP addresses, no?" Once we have fully commoditised all IP resources (including ASNs BTW), then what is the point of having PDPs or RIR communities to engage in same? If you remove the regulator, and the rule governing IP address distribution is "the one with the deepest pocket wins", then there is no need for a rule making community. In another forum, I have used the acronym BUTOC to describe the Bottom-Up, Transparent, Open, Consensus driven Internet PDPs or what ISOC calls the Internet Ecosystem. http://www.isoc.org/pubpolpillar/docs/factsheet_ecosystem_20090310.pdf says: "The Internet is successful in large part due to its unique model: shared global ownership, development based on open standards, and freely accessible processes for technology and policy development. The Internet?s unprecedented success continues to thrive because the Internet model is open, transparent, and collaborative. The model relies on processes and products that are local, bottom-up, and accessible to users around the world" Now, if this is true, (which I believe it is), eliminating the underpinnings of this model would be detrimental to the development of the Internet. We have already commoditised IP connectivity, let's not commoditise IP addressing. -- Cheers, McTim "A name indicates what we seek. An address indicates where it is. A route indicates how we get there."? Jon Postel From mike at nationwideinc.com Sat May 21 09:45:15 2011 From: mike at nationwideinc.com (Mike Burns) Date: Sat, 21 May 2011 09:45:15 -0400 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate References: <4DCFDB5C64DD4F738B65AB82D36B629D@mike><15F92ECD-2BE5-48F2-B65A-9A9D39B98F54@delong.com> <0829B106605C4FE8B189DB2E56C69615@mike><51506A06-D2EE-4A0D-B92B-781662094A1C@eyeconomics.com> <0CCB8AB89D144E89872AF0D635E95497@mike><2691B7B9-1F3C-403C-B4E8-5B82BED0E191@eyeconomics.com> <454BB1826E7B4F2BB3A68BE1DD86A756@video> <909D6DD7-404F-4BB3-B330-78B755FAB6DA@eyeconomics.com> <156DA5A48E51490284BC21D982A8FDAB@mike> Message-ID: <62F7B0A04AEB4D88B7C351E20F825CDA@video> Hi McTim, I don't see the slippery slope. IPv4 addresses have *already* been monetized. In the near future, once the free pool has exhausted, the only way to get IPv4 addresses will be to pay for them. We can bemoan the fact, but we can't change that fact in any way I can see or that you have proposed. Let's not setup a false dichotomy, as in pass my proposal and face the monetized IPv4 market, don't pass my proposal and somehow the deep pockets don't win. With ARIN's existing policy, the deep pockets will still beat the shallow pockets. The fundamental problem I have with your post is that you fail to recognize the significant game-changer that is exhaust. If you have read what I have written, you will find no mention of monetizing IPv6, and really there was no movement towards monetizing IPv4 until the brick wall of exhaust nearly hit us in the nose. So that's where we are, like it or not, we are at the exhaust point, and moving forward in IPv4 will require the purchase of IPv4 addresses. I argue that the needs basis is the appropriate model for handing out free addresses, but the purpose of the needs requirement, that is distribution to users who will put the addresses to productive use, has been superceded by the actions of the market, which I have argued will have the same overall effect of driving these assets to their most productive use. As far as arresting what you consider a slide towards private registries, what could be better than arming our registries with the optimal tools to encourage registry at ARIN in order to forestall any flight to a private registry, which presumably would have some advantage in the customer's eyes? If we insist on maintaining the needs analysis as a roadblock to (many? some? a few?) transactions, we are driving that registration out of the system you are praising, and to what end? I say we run the risk of actually incentivizing the switch to private registries, and lest we forget, there is nothing in the world to prevent private registries from popping up and succeeding if they provide some utility to customers and to network operators. We are stewards not just of IPv4 addresses, but AS numbers, Ipv6 addresses, AND Whois. At this point let us not make policy designed for the stewardship of free resources that operates at the risk of Whois accuracy and usefulness. The Internet succeeded, in your eyes, because it was open, transparent, and collaborative. Why then, are we engineering policy which is less transparent and less open? Remember, my policy does away with NDAs and allows for transparency in transactions by removing ARIN's transactional impediments and faciliating the registration on the public Whois registry. Maintaining needs drives transactions into the darkness and threatens the functionality of Whois, of which we are stewards. Do we want transparent transactions, at least as far as knowing who controls what netblock? Then let's end the policies which prevent ARIN from registering the transfer of otherwise legal transactions. Let me just end with the crucial factor- we don't have any more IPv4 addresses left to steward, we have already moved into the commoditization of these addresses, but as long as the free pool of AS numbers and IPv6 addresses exists, stewardship requires some constraint on their allocation, and I have seen no mention anywhere, by anyone, that these things should be commoditized. Thus the fear of lifting needs requirements for addresses already allocated should not be transmogrified into some fear of ravenous capitalists set to devour the Internet model. Regards, Mike ----- Original Message ----- From: "McTim" To: "Mike Burns" Cc: "Tom Vest" ; "Chris Engel" ; Sent: Saturday, May 21, 2011 3:34 AM Subject: Re: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate Hi, Apologies for the length of this posting. On Fri, May 20, 2011 at 10:56 PM, Mike Burns wrote: > Hello to the list, > arrayed above? Any large loopholes or gotchas? Risks or threats we haven't > considered? In November, at the AfriNIC meeting, I gave a presentation on "Emerging Threats to the RIR system". You can find that one here: http://meeting.afrinic.net/afrinic-13/images/stories/af13_presentation/AF-13-24/Emerging_threats_to_RIR.pdf This proposal has outlined a more serious threat than any in my presentation, that is the threat of removing the need any need for a PDP. I think we are on a very slippery slope to a dystopic future in which all access to IP addresses (v4 or v6) are done on a "cash n carry" basis. Currently, we are near the top of that steep and slippery slide, sitting on a sturdy branch (which we call "needs-basis" or TV's "capability" testing) of a stout tree (species STLS). The next ledge down is where APNIC sits. They call it prop-050. Below that we can see other ledges and trees where we might stop on the way down, including the shelf of inter-RIR transfer, the slender branch of RIR verification, etc, etc, all the way down into the festering swamp of de-aggregation. Put another way STLS-->removal of needs basis-->removal of RIR involvement in transfers/addition of private registries--> full commoditisation of v4-->commoditisation of v6-->removal of any needs to have policy-->elimination of IP address policy communities/PDPs. There will always be folk who will argue for the purest form of a "free-market", which as we know is mostly theoretical. Once v4 is fully commoditised, there will inevitably be folk who want to do the same to v6. I can hear the arguments now "hey if we can buy and sell v4, why not v6, after all they are the same thing, they are both IP addresses, no?" Once we have fully commoditised all IP resources (including ASNs BTW), then what is the point of having PDPs or RIR communities to engage in same? If you remove the regulator, and the rule governing IP address distribution is "the one with the deepest pocket wins", then there is no need for a rule making community. In another forum, I have used the acronym BUTOC to describe the Bottom-Up, Transparent, Open, Consensus driven Internet PDPs or what ISOC calls the Internet Ecosystem. http://www.isoc.org/pubpolpillar/docs/factsheet_ecosystem_20090310.pdf says: "The Internet is successful in large part due to its unique model: shared global ownership, development based on open standards, and freely accessible processes for technology and policy development. The Internet?s unprecedented success continues to thrive because the Internet model is open, transparent, and collaborative. The model relies on processes and products that are local, bottom-up, and accessible to users around the world" Now, if this is true, (which I believe it is), eliminating the underpinnings of this model would be detrimental to the development of the Internet. We have already commoditised IP connectivity, let's not commoditise IP addressing. -- Cheers, McTim "A name indicates what we seek. An address indicates where it is. A route indicates how we get there." Jon Postel From mike at nationwideinc.com Sat May 21 10:01:22 2011 From: mike at nationwideinc.com (Mike Burns) Date: Sat, 21 May 2011 10:01:22 -0400 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate References: <4DCFDB5C64DD4F738B65AB82D36B629D@mike> <15F92ECD-2BE5-48F2-B65A-9A9D39B98F54@delong.com> <0829B106605C4FE8B189DB2E56C69615@mike> <51506A06-D2EE-4A0D-B92B-781662094A1C@eyeconomics.com> <0CCB8AB89D144E89872AF0D635E95497@mike> <2691B7B9-1F3C-403C-B4E8-5B82BED0E191@eyeconomics.com> <454BB1826E7B4F2BB3A68BE1DD86A756@video> <909D6DD7-404F-4BB3-B330-78B755FAB6DA@eyeconomics.com> <156DA5A48E51490284BC21D982A8FDAB@mike> <77310136-54C6-43F0-9923-E7810DD2736D@delong.com> <059E9D87D0D8420D8EAE18BF78F1FA88@video> <2802FCB9-1D0A-43AA-81BB-C3A93AAA7B45@delong.com> Message-ID: Hi Owen, Forgive the topposting,but we are on the merry-go-round again. I am basing my interpretation of the law on the words of the head of ARIN, which you seem to dismiss, even though he made those statements under oath to a judge. And on my reading of the MS/Nortel deal, in which I see an exclusive right to transfer, which plainly means ARIN cannot affect that transfer right. Your interpretation has become hoary with age, it was the same thing you were writing years ago. You continue to believe that ARIN will charge into the fray on its white horse and reclaim these legacy addresses. Why? When have they ever done this? I wouldn't be relying on section 12, it is poorly written and does not give ARIN the right to review and revoke for utilization, and ARIN policies do not apply to legacy holders who got their addresses before ARIN came into existence. The real power lies in section 8 of the RSA, which legacy holders for the most part have not signed, and thus ARIN has no legal rights. Sure, they control Whois registration, and that is what I have heard John Curran say. And sure, if you define a transfer as a WHois update, then ARIN controls transfers. But ARIN cannot legally stop a sale of legacy addresses to another party, if you believe that, then just keep watching as that continues to never happen, and as these legal transactions continue to the detriment of WHois. Neither you nor I am a lawyer, so it is fair to discount our interpretations, but in the article I mentioned, a real lawyer was quoted as agreeing with my interpretation. Do you have any lawyer who holds with your interpretation? Regards, Mike PS THanks for the info on the prior discussion, I will snoop around the archives for 2008 to see if anything there is enlightening. ----- Original Message ----- From: Owen DeLong To: Mike Burns Cc: Tom Vest ; Chris Engel ; arin-ppml at arin.net No, this is an incorrect understanding of the ruling. The Plzak declaration is also not the final word on the subject. The exclusive right to transfer means that nobody else has the right to transfer them. It does not mean that they can be transfered regardless of policy or that ARIN must recognize a transfer outside of policy in the ARIN database. Legacy addresses were issued to a particular party for a particular purpose. Upon the end of that purpose or that party, they should be returned and are no longer legacy addresses. In the case of a transfer to a successor in interest through acquisition or merger, in some cases, the legacy status has been preserved, but, this is rare. In most cases, the receiving organization has been required to sign an ARIN standard RSA. It works this way... Legacy status is the intersection of the holder and the resources which were registered together by a registry preceding the RIR system. Once either of those conditions ceases, the resources are no longer in legacy status (in most cases). ARIN has an obligation to continue providing services to records with legacy status so long as that legacy status remains under the original terms of issue. ARIN has the right to reclaim addresses from defunct legacy organizations. Given this, legal legacy transfers can occur where the purchased amount may not meet ARIN's need requirement. Not true. At least not if they want to be recognized by ARIN and have the transfer registered in whois. If the buyer cannot meet the requirement, he will not register the addresses, although I have argued he will likely want the addresses registered to reflect his ownership of their rights. The unregistered addresses become subject to reclamation since they are no longer in use by the original organization under the original terms of issue. But if there is no needs requirement, the disincentive is removed, the registration takes place, and the buyer signs an RSA. Ah, so you are once again confusing incentive with removal of disincentive. I can see how, to a limited extent, this might provide less of a disincentive for the recipient of a transfer from a legacy holder to register the transfer, but, I don't see how this is anything other than redundant to your point 1. My proposal also reduces the disincentive to sign the RSA, as it removes the utilization requirement and frees the buyer to resell the addresses to anybody, with or without need. (Unless that buyer already has transferred a /12 equivalent). Yes, by neutering the RSA, you have removed some disincentives to sign it. However, I don't see neutering the RSA as a net positive in that regard. The community put section 12 into policy for a reason. So I believe the net effect of the proposal is to make the RSA more attractive, and reduce the disincentive for registration of legacy transfers which do not meet the needs test. There is no such thing as a legacy transfer. There is a transfer of resources from a legacy holder, but, absent an awkward situation involving litigation these will almost always result in the space being handled as non-legacy if the transfer is recognized by ARIN. Remember, these are the intentions of the proposal, although I know you disagree with my legal interpretation, and thus the effect. Yes... Your legal interpretation being contrary to statements made by ARIN counsel and John Curran, I am inclined to believe that it is not correct and therefore the effect of your proposal differs from your claimed effects. 3. Provides for explicit protections against review audits for RSA holders after one year, bringing RSA rights more in accord with LRSA rights. Uh, yeah, I don't see that as a good thing. Quite the opposite. However, I do agree that it is an intended consequence of the proposal. 4. Reduces transaction costs for transferers I believe it will actually increase them. The intent of the proposal is that transactional costs related to the needs analysis can be avoided. These may be large or small. I suppose you mean the prices will be higher due to speculation, though. Yes, I believe that the net price of the transaction will increase substantially. Further, the cost of needs analysis is built into the ARIN transfer fee which I do not think will change significantly as a result of this proposal. So, no price reduction and likely price increase. Doesn't look like a savings to me. 5. Reduces ARIN costs for needs analyses Agreed, but, not necessarily something I see as a beneficial aspect. 6. Aligns ARIN policy with most possible interpretations of the legal rights of legacy holders No, aligns ARIN policy with one possible interpretation of the legal rights of legacy holders. IMHO, not even the most probable one. See "exclusive right to transfer" and the Plzak declaration that ARIN has no authority over legacy addresses. Would it be fair to say "Aligns ARIN policy with legal interpretation most friendly to legacy holders?" My point being this alignment presents the lowest risk toARIN of being sued for tortious interference in a contract. You have already been told multiple times that your interpretation of the words "exclusive right to transfer" is not correct. The Plzack declaration was substantially modified by later rulings in the Kremen case. 7. Imposes a yearly limit on needs-free transactions intended to prevent cornering. Yes, but, this limit is effectively a no-op because anyone can create multiple entities needed to accomplish enough /12 transfers to meet their desires. I trust ARIN staff to detect these with the same diligence applied to needs tests and section 12 reviews. It doesn't matter. If they are different organizations, ARIN can't claim that they aren't different organizations for policy purpose just because it's clear that they were created for the purpose of doing an end-run on the policy. ARIN must interpret the policy as written, even if that interpretation appears absurd, as in the case of the single aggregate clause in the transfer policy. And likewise we have fairly addressed these issues. To some extent. Without considering (any more) the merits of those prior discussions, I would like to invite the consideration of any other potential benefits or consequences which we have not discussed. I am cognizant that this is proposal is a significant departure, and that the discussion of similar policy in APNIC consumed several years. As it did here prior to being rejected here and accepted there. I didn't know there had also been prior discussion here about this (or fairly similar) policy. Do you rember about when so I can search the archives? In the early stages of 2008-2, there was discussion of a transfer policy without needs basis, at least among the AC before we formulated 2008-2. I believe it was rejected by the community pretty much out of hand fairly early in the discussion either at open policy hours and/or at the public policy meetings, but, it may have just been within the AC. After three years and a whole lot of policy work, I have to admit my memory on exactly when and where a given discussion took place is somewhat fuzzy. I think we have covered pretty much all the bases in our relatively short but active discussion period, but I agree with Tom that we really should stretch our minds to consider all the potential pitfalls. So did we miss anything, or is there anything left to be said on the topics arrayed above? Any large loopholes or gotchas? Risks or threats we haven't considered? One I think worth exploring is that given the recent staff interpretation of the term RSA in policy, the requirement for RSA in the proposal may be insufficiently specific to express community intent. I agree, though my intention was that it was the RSA, not an LRSA, but the RSA modified by my proposal. Understood, but, staff has made it quite clear that they will not interpret the policy as written in that manner. Unfortunately, I am not sure that we can actually influence the choice of RSA through policy. I'm hoping that a public clarification of this issue will be forthcoming soon. Maybe the increased/decreased exposure of ARIN to lawsuits? I think this would not significantly impact the legal exposure. We are as likely to get sued by someone unable to obtain resources in the market on the basis that we failed to properly regulate need in the market as we are to get sued by someone opposed to our attempts to regulate need, IMHO. I can't see any legal right to sue ARIN if the community decides to drop the needs policy, but I am not a lawyer. This is the united States. Anyone can sue anyone for just about anything. I wonder if anybody has sued APNIC on that basis? Entirely different legal system(s). Maybe the ARIN legal staff can comment on that. But I can sure see somebody suing ARIN if ARIN re-issues their address to another allocant. ARIN wouldn't do that. What ARIN might do is issue addresses they have been hijacking to another registrant, but, the point of policy is that it does not protect hijackers from this. If you want the protections of guaranteed uniqueness, you have to play by the rules. If you do an unregistered transfer, then, you aren't a registrant, you are a squatter at best and a hijacker at worst. If ARIN's legal interpretation is that they can revoke legacy addresses if they are not utilized, for example, that leads to their reissuance, and legal trouble. If they are still held by the original organization, generally ARIN will not do this. If they are being used by an unregistered organization for an unregistered purpose, ARIN will probably first try to contact the original organization to verify the intent. If a transfer was intended, ARIN would probably first attempt to work with that organization to see if an 8.2 or 8.3 transfer could be made to fit the situation somehow. If they cannot, or, the party using the addresses is unwilling to cooperate in that process, then, I have no problem with ARIN reclaiming the addresses and I think that is the correct course of action. If ARIN's legal interpretation is that legacy addresses are outside its authority, that risk is minimalized. So long as they are held by the original legacy registrant or their successor in interest, I believe ARIN will continue to provide registration services to them. There is a difference between not reclaiming them and believing that they are outside of ARIN authority, however. Owen -------------- next part -------------- An HTML attachment was scrubbed... URL: From rudi.daniel at gmail.com Sat May 21 11:24:06 2011 From: rudi.daniel at gmail.com (Rudolph Daniel) Date: Sat, 21 May 2011 11:24:06 -0400 Subject: [arin-ppml] IPv4 Transfer Policy Change Message-ID: Question: What would be the effect of removing the needs requirement for the transfer of resources from a legacy holder; and any transfer from the legacy holder signs an RSA as mandatory requirement and thus remove LRSA. rd No, this is an incorrect understanding of the ruling. The Plzak declaration > is also > not the final word on the subject. The exclusive right to transfer means > that nobody > else has the right to transfer them. It does not mean that they can be > transfered > regardless of policy or that ARIN must recognize a transfer outside of > policy in the > ARIN database. > > Legacy addresses were issued to a particular party for a particular > purpose. Upon the end > of that purpose or that party, they should be returned and are no longer > legacy addresses. > In the case of a transfer to a successor in interest through acquisition or > merger, in some > cases, the legacy status has been preserved, but, this is rare. In most > cases, the receiving > organization has been required to sign an ARIN standard RSA. > > It works this way... Legacy status is the intersection of the holder and > the resources which > were registered together by a registry preceding the RIR system. Once > either of those > conditions ceases, the resources are no longer in legacy status (in most > cases). > > ARIN has an obligation to continue providing services to records with > legacy status so long > as that legacy status remains under the original terms of issue. > > ARIN has the right to reclaim addresses from defunct legacy organizations. > > > Given this, legal legacy transfers can occur where the purchased amount > may not meet ARIN's need requirement. > > Not true. At least not if they want to be recognized by ARIN and have the > transfer registered > in whois. > > > If the buyer cannot meet the requirement, he will not register the > addresses, although I have argued he will likely want the addresses > registered to reflect his ownership of their rights. > > The unregistered addresses become subject to reclamation since they are no > longer in > use by the original organization under the original terms of issue. > > > But if there is no needs requirement, the disincentive is removed, the > registration takes place, and the buyer signs an RSA. > > Ah, so you are once again confusing incentive with removal of disincentive. > I can see how, to a limited extent, this > might provide less of a disincentive for the recipient of a transfer from a > legacy holder to register the transfer, but, > I don't see how this is anything other than redundant to your point 1. > > > My proposal also reduces the disincentive to sign the RSA, as it removes > the utilization requirement and frees the buyer to resell the addresses to > anybody, with or without need. (Unless that buyer already has transferred a > /12 equivalent). > > Yes, by neutering the RSA, you have removed some disincentives to sign it. > However, I don't see neutering the RSA > as a net positive in that regard. The community put section 12 into policy > for a reason. > > > So I believe the net effect of the proposal is to make the RSA more > attractive, and reduce the disincentive for registration of legacy transfers > which do not meet the needs test. > > There is no such thing as a legacy transfer. There is a transfer of > resources from a legacy holder, but, absent an > awkward situation involving litigation these will almost always result in > the space being handled as non-legacy > if the transfer is recognized by ARIN. > > > > > Remember, these are the intentions of the proposal, although I know you > disagree with my legal interpretation, and thus the effect. > > > > Yes... Your legal interpretation being contrary to statements made by ARIN > counsel and John Curran, I > am inclined to believe that it is not correct and therefore the effect of > your proposal differs from your > claimed effects. > > > > >> 3. Provides for explicit protections against review audits for RSA > holders after one year, bringing RSA rights more in accord with LRSA rights. > > > >> Uh, yeah, I don't see that as a good thing. Quite the opposite. However, > I do agree that it is an intended > >> consequence of the proposal. > > > >>> 4. Reduces transaction costs for transferers > > > >> I believe it will actually increase them. > > > > The intent of the proposal is that transactional costs related to the > needs analysis can be avoided. These may be large or small. I suppose you > mean the prices will be higher due to speculation, though. > > > > Yes, I believe that the net price of the transaction will increase > substantially. Further, the cost of > needs analysis is built into the ARIN transfer fee which I do not think > will change significantly > as a result of this proposal. So, no price reduction and likely price > increase. Doesn't look like > a savings to me. > > >>> 5. Reduces ARIN costs for needs analyses > > > >> Agreed, but, not necessarily something I see as a beneficial aspect. > > > > > >>> 6. Aligns ARIN policy with most possible interpretations of the legal > rights of legacy holders > > > >> No, aligns ARIN policy with one possible interpretation of the legal > rights of legacy holders. > >> IMHO, not even the most probable one. > > > > See "exclusive right to transfer" and the Plzak declaration that ARIN has > no authority over legacy addresses. > > Would it be fair to say "Aligns ARIN policy with legal interpretation > most friendly to legacy holders?" > > My point being this alignment presents the lowest risk toARIN of being > sued for tortious interference in a contract. > > > > You have already been told multiple times that your interpretation of the > words "exclusive right to transfer" > is not correct. The Plzack declaration was substantially modified by later > rulings in the Kremen case. > > >>> 7. Imposes a yearly limit on needs-free transactions intended to > prevent cornering. > > > >> Yes, but, this limit is effectively a no-op because anyone can create > multiple entities needed > >> to accomplish enough /12 transfers to meet their desires. > > > > I trust ARIN staff to detect these with the same diligence applied to > needs tests and section 12 reviews. > > > > It doesn't matter. If they are different organizations, ARIN can't claim > that they aren't different organizations > for policy purpose just because it's clear that they were created for the > purpose of doing an end-run on > the policy. ARIN must interpret the policy as written, even if that > interpretation appears absurd, as in > the case of the single aggregate clause in the transfer policy. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tvest at eyeconomics.com Sat May 21 17:46:45 2011 From: tvest at eyeconomics.com (Tom Vest) Date: Sat, 21 May 2011 17:46:45 -0400 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate In-Reply-To: <156DA5A48E51490284BC21D982A8FDAB@mike> References: <4DCFDB5C64DD4F738B65AB82D36B629D@mike> <15F92ECD-2BE5-48F2-B65A-9A9D39B98F54@delong.com> <0829B106605C4FE8B189DB2E56C69615@mike> <51506A06-D2EE-4A0D-B92B-781662094A1C@eyeconomics.com> <0CCB8AB89D144E89872AF0D635E95497@mike> <2691B7B9-1F3C-403C-B4E8-5B82BED0E191@eyeconomics.com> <454BB1826E7B4F2BB3A68BE1DD86A756@video> <909D6DD7-404F-4BB3-B330-78B755FAB6DA@eyeconomics.com> <156DA5A48E51490284BC21D982A8FDAB@mike> Message-ID: <2B4CEE14-49C8-429A-B087-8A2E097A35C5@eyeconomics.com> Hi Mike, Per your suggestion, I'm going to add to the to the list of anticipated adverse direct and indirect/unintended consequences that you started. However, first I want to introduce a list of general consequences stemming from the exhaustion of the unallocated IPv4 reserves that may or may not be affected positively or negatively by your proposal, or by transfers in general. I think that that is only sensible way to start such an accounting, and I submit that *this* is the context against which your proposal (and all other transfer-related proposals, past and present) should be evaluated. I'm introducing this now because of some recent off-list communications suggesting that a lack of context has made it difficult for some recent ppml subscribers to to interpret the discussion so far as anything more than the extension of a more general political argument into the address policy sphere. I. Anticipated Consequences of Exhaustion of the Unallocated IPv4 Resource Pool 1.1. IPv4's status as a critical, non-substitutable -- a.k.a. "bottleneck" -- requirement for engaging in most kinds of "commercial Internet activity" (i.e., anything involving any combination of "high volume," "high reliability," or "managerial independence") means that the exhaustion of unallocated IPv4 reserves will effective close the only neutral channel for accommodating entry into the Internet industry -- which happens to be the same channel through which all current IPv4 address holders came to possess those IPv4 holdings. 1.2. The closure of the only neutral channel for acquiring IPv4 will change current IPv4 holders in two or possibly three important ways. First, it will leave incumbent IPv4 holders as the sole potential providers of the critical, non-substitutable, bottleneck resource without which competitive entry into any segment of the Internet services sector is impossible. This change in status will significantly boost the *absolute* bargaining power of all IPv4 holders over and above whatever level that they enjoyed in the pre-exhaustion period, with the *relative* gain in market power enjoyed by individual IPv4 incumbents varying by degree and potential duration based on the absolute size of their IPv4 reserves. 1.3 The exhaustion of the neutral IPv4 reserves will also affect incumbent IPv4 holders by constraining their traditional, IPv4-dependent mechanisms for attracting and integrating new customers and for accommodating the subsequent growth of existing customers. As these traditional mechanisms become increasingly constrained, incumbent IPv4-based service providers will be compelled to choose between several unappealing options, including 1.3(a) continuing to to provide current IPv4-based customers and services, but foregoing all other revenue opportunities, 1.3(b) freeing up IPv4 for ongoing customer/revenue growth by renumbering most of their own infrastructure with IPv6, 1.3(c) pursuing customer/revenue expansion by raising prices to push low-dollar customers to seek out alternate IPv4 providers and/or to accept smaller IPv4 assignments or other/second-best attachment options -- which today would include NAT, NAT4n, and IPv6, 1.3(d) taking a one-time windfall by liquidating all of their IPv4 holdings and reducing their subsequent service offerings to native IPv6-based customers that are supportable exclusively via native IPv6-based interconnections with accessible native IPv6-based peers and transit providers, or 1.3(e) liquidating as in d and then exiting the market. 1.4 IPv4-based incumbents that opt for any of 1.3(a-d) will be significantly affected in a third way by virtue of the fact that they will compelled to choose *on behalf of all of their customers* how to accommodate inbound and outbound IPv4 and IPv6 traffic exchanges between those customers and any/all networks that are managed by someone else. As long as internal customer demand for interaction with external IPv4-based resources remains high, accommodating demand for such interconnections will create a separate operational (i.e., non-revenue-generating) IPv4 requirement that will be in direct contention with other direct revenue-generating IPv4 assignments. 1.5 Each of the above options that are available to IPv4 incumbents may or may not incorporate an additional revenue stream from the fee-simple sale of IPv4 addresses to third parties. Although there are many other kinds of contractual vehicles that incumbent IPv4 holders might employ to monetize their non-assigned IPv4 reserves in an open transfer market, all of the others produce the same kind of direct customer-provider relations -- and whois responsibilities -- associated with 1.3(a-c) and thus may be ignored. Each fee-simple sale of IPv4 would absolutely reduce internal IPv4 reserves that are required to support current revenue-generating IPv4-based customers and any/all traffic exchanges between internal customers and off-net resources that involve IPv4 on either side. Under current conditions, each offering of fee-simple IPv4 would occur in a market in which aspiring industry entrants might be in contention with other incumbent IPv4-based service providers. Let 1.5(a) denote fee-simple IPv4 transfers between two incumbent, IPv4-holding service providers, and 1.5(b) denote fee-simple transfers between an incumbent, IPv4-holding Internet service provider and a first-time IPv4 recipient, which if subject to a needs/"capability" test would make them a "new entrant." 1.6 The approval of an IPv4 transfer market effectively created a new set of stakeholders whose actions could impact the price, availability, and status of IPv4, i.e., non-Internet service providers who can claim title to IPv4 addresses that were allocated under the old system but which are currently idle. Let 1.6(a) denote fee-simple IPv4 transfers between an IPv4-holding non-ISP and a incumbent, IPv4-based service provider, and 1.6(b) indicate a fee-simple transfers between an IPv4-holding non-ISP and a first-time IPv4 recipient, which if subject to a needs/"capability" test would make them a "new entrant." 1.7 The *absolute* bifurcation of market opportunities and bargaining power that will result from the disappearance of a neutral/open source for any kind of portable IP addresses that permit unconstrained (de facto global) interoperability will persist indefinitely unless/until one of three things happens: 1.7(a) the preponderance of IPv4 holders -- i.e., almost all of 1.3(a-c) -- individually choose to forego any potential service market advantages AND any potential future windfalls from IPv4 sales by enabling all of their customers to participate in both inbound and outbound traffic exchanges with native IPv6-based destinations on a transparent, ad hoc, demand-driven basis on par with current IPv4-to-IPv4 connections [note: this would also eliminate any relative advantage associated with IPv4, and thus effectively restore the status quo ante -- i.e., an open market in which possession of any/all IP addressing conferred the same capabilities and opportunities to all address holders]. Call this this "open-at-will" scenario. 1.7 (b) Fee-simple transfers of IPv4 address continue over an extended period, until eventually the market(s) reach a point where no service provider enjoys any market advantage over any other based solely on the distribution of IP addresses. This point might correspond to a moment in the distant future when the Internet industry hits the TCP/IP-imposed ceiling of 2^32 independent service providers each holding exactly one IPv4 address. Alternately, it might happen in the marginally less distant future, e.g., when the the population of post-allocation, fee-simple IPv4 buying, IPv6-based service providers grows so vast and powerful as to dominate the population of incumbent, pre-allocation fee-simple IPv4 selling service providers that they've been competing against in the interim. Call this this "decision-by-demographics" scenario. 1.7 (c) Insufficient fee-simple IPv4 acquisition opportunities at price points that are sustainable by aspiring competitive entrants causes the transfer market to fail. Incumbent IPv4 based service providers continue to accommodate new customer growth, albeit with varying combinations of IP4, IPv6, and private addressing that have no effect on IPv4's status as a critical, non-substitutable "bottleneck" for engaging in commercial Internet activities. The Internet becomes progressively more complex and expensive to operate, but it still works -- at least for the generation of service providers that predated the exhaustion of the unallocated IPv4 address pool. After that, anyone with an ambition to become an independent commercial Internet content or service provider just has to buy one of the incumbent providers. For everyone else, the Internet is closed. Call this the "numbers-as-land" scenario. 1.7 (d) Some new, as-yet unimagined technology that eliminates the IPv4-IPv6 incompatibility emerges, or alternately a new networking paradigm that is both widely regarded as superior to TCP/IP AND is as transparent to TCP/IP as TCP/IP is to physical media makes the whole problem go away. Call this the "saved-by-magic" scenario. _____ II. Suggested Adverse Consequences of Mike's Proposal to Eliminate Needs ("Capability") Testing 2.1 Market distortions will happen due to the selfish actions of speculators, including market cornering attempts. 2.2 Disaggregation will increase. 2.3 It is too radical a change, and change should appropriately come incrementally, like extending the length of the needs window. 2.4 It will make it easier for bad players like spammers to get addresses. 2.5 It will run the risk of actually making Whois less accurate. 2.6 Addresses will be used less efficiently if we only rely on price to drive their productive use. 2.x Others, forthcoming _____ III. Suggested Positive Effects of Mike's Proposal to Eliminate Needs ("Capability") Testing 3.1 Provides an incentive for more transactions to be registered by ARIN 3.2 Provides an incentive for legacy space to be brought under RSA 3.3 Provides for explicit protections against review audits for RSA holders after one year, bringing RSA rights more in accord with LRSA rights. 3.4 Reduces transaction costs for transferrers 3.5 Reduces ARIN costs for needs analyses 3.6 Aligns ARIN policy with most possible interpretations of the legal rights of legacy holders 3.7 Imposes a yearly limit on needs-free transactions intended to prevent cornering. _____ My own initial interpretation: One immediate and direct effect of eliminating needs/"capability" testing would be to greatly expand the demand side of the IPv4 market in two way: by effectively legalizing the participation of market makers (a.k.a. "speculators") that have no direct material interest in Internet production themselves, and by enabling such speculators -- or anyone else, including incumbent, IPv4-based service providers -- to express potentially infinite demand for IPv4, limited only by whatever the (NDA-shrouded) market will bear. As a very distant second order effect, the elimination of a needs/"capability" testing might also increase the supply of IPv4 -- but the only way that I can imagine how the proposed change might have that effect would be IF the newly-legalized speculators actually turn out to be *much better and much faster* than both incumbent IPv4 holders and aspiring new Internet service providers are both at locating and liberating idled IPv4, and at moving it back into productive use as quickly as possible. In other words, if the speculators could bring IPv4 to market at a price that is actually *below* what it would cost any actual network service provider to acquire it and bring it into useful service, then the delta between those two price points would represent 100% of the "supply premium" created by eliminating the needs requirement. But in the real world, there's no way that that "supply premium" would be a positive number. Much more likely that it would be a very very large negative number. And that negative supply contribution would be *on top of* the many and varied direct and indirect/unintended consequences that would result if this proposal were approved -- details of which I'll save for a later message... Regards, TV On May 20, 2011, at 3:56 PM, Mike Burns wrote: > Hello to the list, > > Per what Tom wrote at the bottom, I am all for considering the consequences of my proposal, intended or otherwise. > > So I believe the consequences we have considered, and please add to this list if you want, are: > I figure we have addressed these issues enough, and that we are rehashing discussions to no additional benefit. > > And I have had the opportunity to address the intentions of the policy proposal, which are: > > > And likewise we have fairly addressed these issues. > > Without considering (any more) the merits of those prior discussions, I would like to invite the consideration of any other potential benefits or consequences which we have not discussed. > I am cognizant that this is proposal is a significant departure, and that the discussion of similar policy in APNIC consumed several years. > I think we have covered pretty much all the bases in our relatively short but active discussion period, but I agree with Tom that we really should stretch our minds to consider all the potential pitfalls. > So did we miss anything, or is there anything left to be said on the topics arrayed above? Any large loopholes or gotchas? Risks or threats we haven't considered? > Maybe the increased/decreased exposure of ARIN to lawsuits? > > (I will admit to enjoying reading my own words. But as they are growing tiresome to me, they must be coma-inducing to you by now.) > > Of course I don't mean to cutoff any discussions about any topic, if you think there is more to add. > > Regards, > Mike > > > > > > > > ----- Original Message ----- From: "Tom Vest" > To: "Chris Engel" > Cc: "Mike Burns" ; > Sent: Friday, May 20, 2011 3:09 PM > Subject: Re: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate > > > > On May 20, 2011, at 1:24 PM, Chris Engel wrote: > >> Tom, >> >> Excising a particular section of this thread for the sake of brevity... >> >>> Fair enough, you prefer to argue logic rather than facts: >>> >>> Please provide a negative proof that "logic" could never lead any future >>> address user, potential address buyer, and/or potential address seller to >>> conclude that registration would not advance their own private interests. >>> >>> Please provide a negative proof that "logic" could never lead any future >>> address user, potential address buyer, and/or potential address seller to >>> embrace "sales-friendly registration" but simultaneously reject >>> "operationally relevant registration" (i.e., the kind that makes whois an >>> appropriate subject of interest for community deliberation). >>> >>> Please provide a negative proof that "logic" will BOTH always lead all future >>> address users, address buyers, and address sellers to self-maintain >>> "operationally relevant registration" for themselves in perpetuity, AND that >>> the attainment of that outcome by means of needs-free transfers could >>> never have any unintended consequences that might be as serious or more >>> serious than some marginal degradation of whois accuracy. >>> >> >> I don't think the above is a fair tactic for debate. You are asking Mike to prove a logical fallacy. Furthermore, when you start using words like "never" and "always" when discussing human behavior as benchmarks for judging the legitimacy of a system...your standards themselves appear absurd. If we applied the same standards for judging the appropriateness of a "needs" based policy, it would assuredly fail as well. Systems designed to regulate human behavior cannot achieve a uniformity of results approaching mathematical perfection, nor need they do so to be effective (IMO). >> >> If you want to argue that it's likely a substantial number of individuals would have logical reasons for not wanting to maintain accurate registration under the policy Mike proposes...that's (IMO) a reasonable standard to base an argument on. Not sure whether I would agree with that proposition or not...but the standard is reasonable. Asking Mike to provide a standard of proof that couldn't allow for even a single exception isn't (IMO). >> >> >> Christopher Engel >> (Representing only my own views) > > Hi Chris, > > Thanks for the reactions. Of course you are right on this count. My apologies to Mike for demanding what is, technically, logically impossible to deliver. > > My intent was not to be merely hyperbolic, but rather to *strongly* suggest that we all engage our imaginations fully when considering the range of strategic responses that might seem to be "rational" from the perspective of any clever entrepreneur who may or may not have any long-term interest in what happens to the Internet or to others who count the Internet for their livelihood or anything else, once s/he is done. Granted, this year we're all operating in an environment that has been significantly shaped by the unintended consequences of last year's strategic adjustments to the previous year's entrepreneurial cleverness, and so on... I mean, who could have anticipated that DWDM might trigger changes in SFP policies that helped to ignite our first crash, or that widespread diffusion of P2P might prompt another shift in commercial strategy that could in turn precipitate a run on the ASN16 reserves? > > Suffice it to say that there are always plenty of smart people out there working out every conceivable new angle that might be exposed by the next change in policy and/or technology and/or market structure -- and in general, at most times, we all benefit tremendously from that fact. But that only remains true as long we do not, through omission or commission, open up any loopholes that are big enough to allow to whole industry to fall through, into who-knows-what. These days it's not really possible to doubt that such things can and in fact do happen from time to time. > > I submit that the removal of "capability" testing would not only represent an irreversible change, but also has the potential to create a number of potentially fatal loopholes. And so in this particular case, I recommend that we proceed only if/after we can first achieve a very high level of confidence that no serious risks or threats are immediately created thereby. > > TV > From jeffrey.lyon at blacklotus.net Sat May 21 18:07:22 2011 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Sat, 21 May 2011 18:07:22 -0400 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate In-Reply-To: <2B4CEE14-49C8-429A-B087-8A2E097A35C5@eyeconomics.com> References: <4DCFDB5C64DD4F738B65AB82D36B629D@mike> <15F92ECD-2BE5-48F2-B65A-9A9D39B98F54@delong.com> <0829B106605C4FE8B189DB2E56C69615@mike> <51506A06-D2EE-4A0D-B92B-781662094A1C@eyeconomics.com> <0CCB8AB89D144E89872AF0D635E95497@mike> <2691B7B9-1F3C-403C-B4E8-5B82BED0E191@eyeconomics.com> <454BB1826E7B4F2BB3A68BE1DD86A756@video> <909D6DD7-404F-4BB3-B330-78B755FAB6DA@eyeconomics.com> <156DA5A48E51490284BC21D982A8FDAB@mike> <2B4CEE14-49C8-429A-B087-8A2E097A35C5@eyeconomics.com> Message-ID: Allow me to add a 3.8: Speculators referenced in 2.1 aid market liquidity, allowing those wishing to trade IP resources to do so in an expedient manner. "Liquidity maintains order within the financial markets and is the key driver behind efficient exchanges. Speculators add huge amounts of money to the markets, and the more money they invest in the market, the more liquid it becomes. An efficient market (very liquid) allows for buyers and sellers to trade with one another with relative ease without causing large shifts in prices." Source: http://www.investopedia.com/ask/answers/09/speculators-destabilizing.asp Jeff On Sat, May 21, 2011 at 5:46 PM, Tom Vest wrote: > Hi Mike, > > Per your suggestion, I'm going to add to the to the list of anticipated adverse direct and indirect/unintended consequences that you started. > > However, first I want to introduce a list of general consequences stemming from the exhaustion of the unallocated IPv4 reserves that may or may not be affected positively or negatively by your proposal, or by transfers in general. I think that that is only sensible way to start such an accounting, and I submit that *this* is the context against which your proposal (and all other transfer-related proposals, past and present) should be evaluated. > > I'm introducing this now because of some recent off-list communications suggesting that a lack of context has made it difficult for some recent ppml subscribers to to interpret the discussion so far as anything more than the extension of a more general political argument into the address policy sphere. > > I. Anticipated Consequences of Exhaustion of the Unallocated IPv4 Resource Pool > > 1.1. IPv4's status as a critical, non-substitutable -- a.k.a. "bottleneck" -- requirement for engaging in most kinds of "commercial Internet activity" (i.e., anything involving any combination of "high volume," "high reliability," or "managerial independence") means that the exhaustion of unallocated IPv4 reserves will effective close the only neutral channel for accommodating entry into the Internet industry -- which happens to be the same channel through which all current IPv4 address holders came to possess those IPv4 holdings. > > 1.2. The closure of the only neutral channel for acquiring IPv4 will change current IPv4 holders in two or possibly three important ways. First, it will leave incumbent IPv4 holders as the sole potential providers of the critical, non-substitutable, bottleneck resource without which competitive entry into any segment of the Internet services sector is impossible. This change in status will significantly boost the *absolute* bargaining power of all IPv4 holders over and above whatever level that they enjoyed in the pre-exhaustion period, with the *relative* gain in market power enjoyed by individual IPv4 incumbents varying by degree and potential duration based on the absolute size of their IPv4 reserves. > > 1.3 The exhaustion of the neutral IPv4 reserves will also affect incumbent IPv4 holders by constraining their traditional, IPv4-dependent mechanisms for attracting and integrating new customers and for accommodating the subsequent growth of existing customers. As these traditional mechanisms become increasingly constrained, incumbent IPv4-based service providers will be compelled to choose between several unappealing options, including > ? ? ? ?1.3(a) continuing to to provide current IPv4-based customers and services, but foregoing all other revenue opportunities, > ? ? ? ?1.3(b) freeing up IPv4 for ongoing customer/revenue growth by renumbering most of their own infrastructure with IPv6, > ? ? ? ?1.3(c) pursuing customer/revenue expansion by raising prices to push low-dollar customers to seek out alternate IPv4 providers and/or to accept smaller IPv4 assignments or other/second-best attachment options -- which today would include NAT, NAT4n, and IPv6, > ? ? ? ?1.3(d) taking a one-time windfall by liquidating all of their IPv4 holdings and reducing their subsequent service offerings to native IPv6-based customers that are supportable exclusively via native IPv6-based interconnections with accessible native IPv6-based peers and transit providers, or > ? ? ? ?1.3(e) liquidating as in d and then exiting the market. > > 1.4 IPv4-based incumbents that opt for any of 1.3(a-d) will be significantly affected in a third way by virtue of the fact that they will compelled to choose *on behalf of all of their customers* how to accommodate inbound and outbound IPv4 and IPv6 traffic exchanges between those customers and any/all networks that are managed by someone else. As long as internal customer demand for interaction with external IPv4-based resources remains high, accommodating demand for such interconnections will create a separate operational (i.e., non-revenue-generating) IPv4 requirement that will be in direct contention with other direct revenue-generating IPv4 assignments. > > 1.5 Each of the above options that are available to IPv4 incumbents may or may not incorporate an additional revenue stream from the fee-simple sale of IPv4 addresses to third parties. Although there are many other kinds of contractual vehicles that incumbent IPv4 holders might employ to monetize their non-assigned IPv4 reserves in an open transfer market, all of the others produce the same kind of direct customer-provider relations -- and whois responsibilities -- associated with 1.3(a-c) and thus may be ignored. Each fee-simple sale of IPv4 would absolutely reduce internal IPv4 reserves that are required to support current revenue-generating IPv4-based customers and any/all traffic exchanges between internal customers and off-net resources that involve IPv4 on either side. Under current conditions, each offering of fee-simple IPv4 would occur in a market in which aspiring industry entrants might be in contention with other incumbent IPv4-based service providers. Let 1.5(a) > ?denote fee-simple IPv4 transfers between two incumbent, IPv4-holding service providers, and 1.5(b) denote fee-simple transfers between an incumbent, IPv4-holding Internet service provider and a first-time IPv4 recipient, which if subject to a needs/"capability" test would make them a "new entrant." > > 1.6 ?The approval of an IPv4 transfer market effectively created a new set of stakeholders whose actions could impact the price, availability, and status of IPv4, i.e., non-Internet service providers who can claim title to IPv4 addresses that were allocated under the old system but which are currently idle. Let 1.6(a) denote fee-simple IPv4 transfers between an IPv4-holding non-ISP and a incumbent, IPv4-based service provider, and 1.6(b) ?indicate a fee-simple transfers between an IPv4-holding non-ISP and a first-time IPv4 recipient, which if subject to a needs/"capability" test would make them a "new entrant." > > 1.7 The *absolute* bifurcation of market opportunities and bargaining power that will result from the disappearance of a neutral/open source for any kind of portable IP addresses that permit unconstrained (de facto global) interoperability will persist indefinitely unless/until one of three things happens: > > ? ? ? ?1.7(a) the preponderance of IPv4 holders -- i.e., almost all of 1.3(a-c) -- individually choose to forego any potential service market advantages AND any potential future windfalls from IPv4 sales by enabling ?all of their customers to participate in both inbound and outbound traffic exchanges with native IPv6-based destinations on a transparent, ad hoc, demand-driven basis on par with current IPv4-to-IPv4 connections [note: this would also eliminate any relative advantage associated with IPv4, and thus effectively restore the status quo ante -- i.e., an open market in which possession of any/all IP addressing conferred the same capabilities and opportunities to all address holders]. Call this this "open-at-will" scenario. > > ? ? ? ?1.7 (b) Fee-simple transfers of IPv4 address continue over an extended period, until eventually the market(s) reach a point where no service provider enjoys any market advantage over any other based solely on the distribution of IP addresses. This point might correspond to a moment in the distant future when the Internet industry hits the TCP/IP-imposed ceiling of 2^32 independent service providers each holding exactly one IPv4 address. Alternately, it might happen in the marginally less distant future, e.g., when the the population of post-allocation, fee-simple IPv4 buying, IPv6-based service providers grows so vast and powerful as to dominate the population of incumbent, pre-allocation fee-simple IPv4 selling service providers that they've been competing against in the interim. Call this this "decision-by-demographics" scenario. > > ? ? ? ?1.7 (c) Insufficient fee-simple IPv4 acquisition opportunities at price points that are sustainable by aspiring competitive entrants causes the transfer market to fail. Incumbent IPv4 based service providers continue to accommodate new customer growth, albeit with varying combinations of IP4, IPv6, and private addressing that have no effect on IPv4's status as a critical, non-substitutable "bottleneck" for engaging in commercial Internet activities. The Internet becomes progressively more complex and expensive to operate, but it still works -- at least for the generation of service providers that predated the exhaustion of the unallocated IPv4 address pool. After that, anyone with an ambition to become an independent commercial Internet content or service provider just has to buy one of the incumbent providers. For everyone else, the Internet is closed. Call this the "numbers-as-land" scenario. > > ? ? ? ?1.7 (d) Some new, as-yet unimagined technology that eliminates the IPv4-IPv6 incompatibility emerges, or alternately a new networking paradigm that is both widely regarded as superior to TCP/IP AND is as transparent to TCP/IP as TCP/IP is to physical media makes the whole problem go away. Call this the "saved-by-magic" scenario. > > _____ > > > II. Suggested Adverse Consequences of Mike's Proposal to Eliminate Needs ("Capability") Testing > > 2.1 Market distortions will happen due to the selfish actions of speculators, including market cornering attempts. > 2.2 Disaggregation will increase. > 2.3 It is too radical a change, and change should appropriately come incrementally, like extending the length of the needs window. > 2.4 It will make it easier for bad players like spammers to get addresses. > 2.5 It will run the risk of actually making Whois less accurate. > 2.6 Addresses will be used less efficiently if we only rely on price to drive their productive use. > 2.x Others, forthcoming > > _____ > > > III. Suggested Positive Effects of Mike's Proposal to Eliminate Needs ("Capability") Testing > > 3.1 Provides an incentive for more transactions to be registered by ARIN > 3.2 Provides an incentive for legacy space to be brought under RSA > 3.3 Provides for explicit protections against review audits for RSA holders after one year, bringing RSA rights more in accord with LRSA rights. > 3.4 Reduces transaction costs for transferrers > 3.5 Reduces ARIN costs for needs analyses > 3.6 Aligns ARIN policy with most possible interpretations of the legal rights of legacy holders > 3.7 Imposes a yearly limit on needs-free transactions intended to prevent cornering. > > _____ > > My own initial interpretation: > > One immediate and direct effect of eliminating needs/"capability" testing would be to greatly expand the demand side of the IPv4 market in two way: by effectively legalizing the participation of market makers (a.k.a. "speculators") that have no direct material interest in Internet production themselves, and by enabling such speculators -- or anyone else, including incumbent, IPv4-based service providers -- to express potentially infinite demand for IPv4, limited only by whatever the (NDA-shrouded) market will bear. > > As a very distant second order effect, the elimination of a needs/"capability" testing might also increase the supply of IPv4 -- but the only way that I can imagine how the proposed change might have that effect would be IF the newly-legalized speculators actually turn out to be *much better and much faster* than both incumbent IPv4 holders and aspiring new Internet service providers are both at locating and liberating idled IPv4, and at moving it back into productive use as quickly as possible. In other words, if the speculators could bring IPv4 to market at a price that is actually *below* what it would cost any actual network service provider to acquire it and bring it into useful service, then the delta between those two price points would represent 100% of the "supply premium" created by eliminating the needs requirement. > > But in the real world, there's no way that that "supply premium" would be a positive number. Much more likely that it would be a very very large negative number. > > And that negative supply contribution would be *on top of* the many and varied direct and indirect/unintended consequences that would result if this proposal were approved -- details of which I'll save for a later message... > > Regards, > > TV > > > > > On May 20, 2011, at 3:56 PM, Mike Burns wrote: > >> Hello to the list, >> >> Per what Tom wrote at the bottom, I am all for considering the consequences of my proposal, intended or otherwise. >> >> So I believe the consequences we have considered, and please add to this list if you want, are: > >> I figure we have addressed these issues enough, and that we are rehashing discussions to no additional benefit. >> >> And I have had the opportunity to address the intentions of the policy proposal, which are: >> >> >> And likewise we have fairly addressed these issues. >> >> Without considering (any more) the merits of those prior discussions, I would like to invite the consideration of any other potential benefits or consequences which we have not discussed. >> I am cognizant that this is proposal is a significant departure, and that the discussion of similar policy in APNIC consumed several years. >> I think we have covered pretty much all the bases in our relatively short but active discussion period, but I agree with Tom that we really should stretch our minds to consider all the potential pitfalls. >> So did we miss anything, or is there anything left to be said on the topics arrayed above? Any large loopholes or gotchas? Risks or threats we haven't considered? >> Maybe the increased/decreased exposure of ARIN to lawsuits? >> >> (I will admit to enjoying reading my own words. But as they are growing tiresome to me, they must be coma-inducing to you by now.) >> >> Of course I don't mean to cutoff any discussions about any topic, if you think there is more to add. >> >> Regards, >> Mike >> >> >> >> >> >> >> >> ----- Original Message ----- From: "Tom Vest" >> To: "Chris Engel" >> Cc: "Mike Burns" ; >> Sent: Friday, May 20, 2011 3:09 PM >> Subject: Re: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate >> >> >> >> On May 20, 2011, at 1:24 PM, Chris Engel wrote: >> >>> Tom, >>> >>> Excising a particular section of this thread for the sake of brevity... >>> >>>> Fair enough, you prefer to argue logic rather than facts: >>>> >>>> Please provide a negative proof that "logic" could never lead any future >>>> address user, potential address buyer, and/or potential address seller to >>>> conclude that registration would not advance their own private interests. >>>> >>>> Please provide a negative proof that "logic" could never lead any future >>>> address user, potential address buyer, and/or potential address seller to >>>> embrace "sales-friendly registration" but simultaneously reject >>>> "operationally relevant registration" (i.e., the kind that makes whois an >>>> appropriate subject of interest for community deliberation). >>>> >>>> Please provide a negative proof that "logic" will BOTH always lead all future >>>> address users, address buyers, and address sellers to self-maintain >>>> "operationally relevant registration" for themselves in perpetuity, AND that >>>> the attainment of that outcome by means of needs-free transfers could >>>> never have any unintended consequences that might be as serious or more >>>> serious than some marginal degradation of whois accuracy. >>>> >>> >>> I don't think the above is a fair tactic for debate. You are asking Mike to prove a logical fallacy. Furthermore, when you start using words like "never" and "always" when discussing human behavior as benchmarks for judging the legitimacy of a system...your standards themselves appear absurd. If we applied the same standards for judging the appropriateness of a "needs" based policy, it would assuredly fail as well. Systems designed to regulate human behavior cannot achieve a uniformity of results approaching mathematical perfection, nor need they do so to be effective (IMO). >>> >>> If you want to argue that it's likely a substantial number of individuals would have logical reasons for not wanting to maintain accurate registration under the policy Mike proposes...that's (IMO) a reasonable standard to base an argument on. Not sure whether I would agree with that proposition or not...but the standard is reasonable. Asking Mike to provide a standard of proof that couldn't allow for even a single exception isn't (IMO). >>> >>> >>> Christopher Engel >>> (Representing only my own views) >> >> Hi Chris, >> >> Thanks for the reactions. Of course you are right on this count. My apologies to Mike for demanding what is, technically, logically impossible to deliver. >> >> My intent was not to be merely hyperbolic, but rather to *strongly* suggest that we all engage our imaginations fully when considering the range of strategic responses that might seem to be "rational" from the perspective of any clever entrepreneur who may or may not have any long-term interest in what happens to the Internet or to others who count the Internet for their livelihood or anything else, once s/he is done. Granted, this year we're all operating in an environment that has been significantly shaped by the unintended consequences of last year's strategic adjustments to the previous year's entrepreneurial cleverness, and so on... I mean, who could have anticipated that DWDM might trigger changes in SFP policies that helped to ignite our first crash, or that widespread diffusion of P2P might prompt another shift in commercial strategy that could in turn precipitate a run on the ASN16 reserves? >> >> Suffice it to say that there are always plenty of smart people out there working out every conceivable new angle that might be exposed by the next change in policy and/or technology and/or market structure -- and in general, at most times, we all benefit tremendously from that fact. But that only remains true as long we do not, through omission or commission, open up any loopholes that are big enough to allow to whole industry to fall through, into who-knows-what. These days it's not really possible to doubt that such things can and in fact do happen from time to time. >> >> I submit that the removal of "capability" testing would not only represent an irreversible change, but also has the potential to create a number of potentially fatal loopholes. And so in this particular case, I recommend that we proceed only if/after we can first achieve a very high level of confidence that no serious risks or threats are immediately created thereby. >> >> 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. > -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications - AS32421 First and Leading in DDoS Protection Solutions From owen at delong.com Sat May 21 19:13:54 2011 From: owen at delong.com (Owen DeLong) Date: Sat, 21 May 2011 16:13:54 -0700 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate In-Reply-To: References: <4DCFDB5C64DD4F738B65AB82D36B629D@mike> <15F92ECD-2BE5-48F2-B65A-9A9D39B98F54@delong.com> <0829B106605C4FE8B189DB2E56C69615@mike> <51506A06-D2EE-4A0D-B92B-781662094A1C@eyeconomics.com> <0CCB8AB89D144E89872AF0D635E95497@mike> <2691B7B9-1F3C-403C-B4E8-5B82BED0E191@eyeconomics.com> <454BB1826E7B4F2BB3A68BE1DD86A756@video> <909D6DD7-404F-4BB3-B330-78B755FAB6DA@eyeconomics.com> <156DA5A48E51490284BC21D982A8FDAB@mike> <77310136-54C6-43F0-9923-E7810DD2736D@delong.com> <059E9D87D0D8420D8EAE18BF78F1FA88@video> <2802FCB9-1D0A-43AA-81BB-C3A93AAA7B45@delong.com> Message-ID: <69D9DBD7-286C-43B7-B4D1-09914CAB3189@delong.com> On May 21, 2011, at 7:01 AM, Mike Burns wrote: > > Hi Owen, > > Forgive the topposting,but we are on the merry-go-round again. Indeed. > > I am basing my interpretation of the law on the words of the head of ARIN, which you seem to dismiss, even though he made those statements under oath to a judge. You are basing your interpretation on a subset of the words of the head of ARIN and ignoring details of the subsequent rulings where the judge dictated that Kremen was not exempt from the requirement to sign an RSA and was not exempt from the ARIN process. I believe that Mr. Plzak (who I will note subsequently stepped down as CEO) erred in his statements in that case and that error was subsequently corrected. > And on my reading of the MS/Nortel deal, in which I see an exclusive right to transfer, which plainly means ARIN cannot affect that transfer right. No, that is not what it means. It means that no one else has the right to enact the transfer, but, it does not mean that the transfer cannot be subject to ARIN policy, as, indeed, if you examine the ruling it was, in fact, contingent on M$ signing an LRSA and certain other conditions related to ARIN policy. > Your interpretation has become hoary with age, it was the same thing you were writing years ago. It was right then and it is right now. I don't see how consistency in this belief is a bad thing. Though I do appreciate the introduction of a new word to my vocabulary, I actually had to look up hoary. I think that I am more likely to be considered hoary (and I don't think I am particularly aged at a mere 44 years old) than my views here. > > You continue to believe that ARIN will charge into the fray on its white horse and reclaim these legacy addresses. I continue to believe that ARIN will work diligently to carry out the policies set by the community. The CEO has said as much. I believe that the NRPM makes it clear that other than as permitted in section 8, ARIN considers IP number resources non-transferrable. As such, I expect transfers not registered with ARIN to become the subject of NRPM 12 audits which will result in one of several possible outcomes: + ARIN works with the recipient and/or the originator to complete and register the transfer under NRPM 8. + ARIN works with the recipient and the originator to update the POCs and get the addresses restored to the original registrant. + ARIN reclaims the addresses which were held by an earlier and now defunct organization to the detriment of the recipient who is under the misapprehension that the addresses were transferred to them outside of policy. > Why? Because it has happened in the past and is consistent with ARIN policy. > When have they ever done this? I am not privvy to specific examples, but, there is quite a bit of space listed in the revoked and reclaimed pools by ARIN staff in their statistics which would indicate that it has, indeed, happened. > I wouldn't be relying on section 12, it is poorly written and does not give ARIN the right to review and revoke for utilization, and ARIN policies do not apply to legacy holders who got their addresses before ARIN came into existence. The real power lies in section NRPM 12 does not extend or contract ARIN policy. It places limits on ARIN's ability to conduct audits too frequently, and, provides a framework under which those audits can be conducted by staff. Some LRSA signatories are exempt from usage-based review. Other than that, I don't see how you can claim NRPM 12 prevents ARIN from reviewing and reclaiming for utilization. I have repeatedly agreed with you that ARIN policies likely cannot be enforced against the original legacy registrant who got their addresses before ARIN came into existence. Even if they could (and I am not sure that they cannot), I would not advocate such. That has never been my claim and is a misrepresentation of what I have said. What I have said, consistently, is that someone other than the original registrant who believes that they are able to receive a transfer of legacy resources without working through NRPM 8 to effect the transfer is mistaken. Even in the early days, addresses were issued to a specific organization for a specific purpose and were not transferable except by acquisition and/or merger which also involved the transfer of the underlying network infrastructure. ARIN, as the successor in interest for the registry function provided by those earlier registries does maintain the ability to enforce those terms and administer the address space accordingly. > 8 of the RSA, which legacy holders for the most part have not signed, and thus ARIN has no legal rights. > Sure, they control Whois registration, and that is what I have heard John Curran say. > And sure, if you define a transfer as a WHois update, then ARIN controls transfers. There are three things that ARIN controls which can have an impact here: 1. Whois 2. rDNS 3. The ability to issue the numbers to another party and register them in (1) and (2) above. > > But ARIN cannot legally stop a sale of legacy addresses to another party, if you believe that, then just keep watching as that continues to never happen, and as these legal transactions continue to the detriment of WHois. True, but, they are not required to recognize that sale and there is no legal basis for preventing ARIN from removing the registration for the legacy holder once that legacy holder is defunct or no longer using the addresses in accordance with their original terms of issue. Once that happens, ARIN is free to issue those addresses to another party and register them accordingly in whois and rDNS, leaving the third party who thinks they bought the addresses in a rather tenuous position at best. > > Neither you nor I am a lawyer, so it is fair to discount our interpretations, but in the article I mentioned, a real lawyer was quoted as agreeing with my interpretation. > Do you have any lawyer who holds with your interpretation? I believe so, but, I will leave it to him if he wants to speak up on the matter. I know he reads PPML. Owen > > Regards, > Mike > > PS THanks for the info on the prior discussion, I will snoop around the archives for 2008 to see if anything there is enlightening. > > > > > > ----- Original Message ----- > From: Owen DeLong > To: Mike Burns > Cc: Tom Vest ; Chris Engel ; arin-ppml at arin.net > > > No, this is an incorrect understanding of the ruling. The Plzak declaration is also > not the final word on the subject. The exclusive right to transfer means that nobody > else has the right to transfer them. It does not mean that they can be transfered > regardless of policy or that ARIN must recognize a transfer outside of policy in the > ARIN database. > > > Legacy addresses were issued to a particular party for a particular purpose. Upon the end > of that purpose or that party, they should be returned and are no longer legacy addresses. > In the case of a transfer to a successor in interest through acquisition or merger, in some > cases, the legacy status has been preserved, but, this is rare. In most cases, the receiving > organization has been required to sign an ARIN standard RSA. > > It works this way... Legacy status is the intersection of the holder and the resources which > were registered together by a registry preceding the RIR system. Once either of those > conditions ceases, the resources are no longer in legacy status (in most cases). > > ARIN has an obligation to continue providing services to records with legacy status so long > as that legacy status remains under the original terms of issue. > > ARIN has the right to reclaim addresses from defunct legacy organizations. > > > > >> Given this, legal legacy transfers can occur where the purchased amount may not meet ARIN's need requirement. > > Not true. At least not if they want to be recognized by ARIN and have the transfer registered > in whois. > >> If the buyer cannot meet the requirement, he will not register the addresses, although I have argued he will likely want the addresses registered to reflect his ownership of their rights. > > The unregistered addresses become subject to reclamation since they are no longer in > use by the original organization under the original terms of issue. > >> But if there is no needs requirement, the disincentive is removed, the registration takes place, and the buyer signs an RSA. > > Ah, so you are once again confusing incentive with removal of disincentive. I can see how, to a limited extent, this > might provide less of a disincentive for the recipient of a transfer from a legacy holder to register the transfer, but, > I don't see how this is anything other than redundant to your point 1. > >> My proposal also reduces the disincentive to sign the RSA, as it removes the utilization requirement and frees the buyer to resell the addresses to anybody, with or without need. (Unless that buyer already has transferred a /12 equivalent). > > Yes, by neutering the RSA, you have removed some disincentives to sign it. However, I don't see neutering the RSA > as a net positive in that regard. The community put section 12 into policy for a reason. > >> So I believe the net effect of the proposal is to make the RSA more attractive, and reduce the disincentive for registration of legacy transfers which do not meet the needs test. > > There is no such thing as a legacy transfer. There is a transfer of resources from a legacy holder, but, absent an > awkward situation involving litigation these will almost always result in the space being handled as non-legacy > if the transfer is recognized by ARIN. > >> >> Remember, these are the intentions of the proposal, although I know you disagree with my legal interpretation, and thus the effect. >> > > Yes... Your legal interpretation being contrary to statements made by ARIN counsel and John Curran, I > am inclined to believe that it is not correct and therefore the effect of your proposal differs from your > claimed effects. > >> >>> 3. Provides for explicit protections against review audits for RSA holders after one year, bringing RSA rights more in accord with LRSA rights. >> >>> Uh, yeah, I don't see that as a good thing. Quite the opposite. However, I do agree that it is an intended >>> consequence of the proposal. >> >>>> 4. Reduces transaction costs for transferers >> >>> I believe it will actually increase them. >> >> The intent of the proposal is that transactional costs related to the needs analysis can be avoided. These may be large or small. I suppose you mean the prices will be higher due to speculation, though. >> > > Yes, I believe that the net price of the transaction will increase substantially. Further, the cost of > needs analysis is built into the ARIN transfer fee which I do not think will change significantly > as a result of this proposal. So, no price reduction and likely price increase. Doesn't look like > a savings to me. > >>>> 5. Reduces ARIN costs for needs analyses >> >>> Agreed, but, not necessarily something I see as a beneficial aspect. >> >> >>>> 6. Aligns ARIN policy with most possible interpretations of the legal rights of legacy holders >> >>> No, aligns ARIN policy with one possible interpretation of the legal rights of legacy holders. >>> IMHO, not even the most probable one. >> >> See "exclusive right to transfer" and the Plzak declaration that ARIN has no authority over legacy addresses. >> Would it be fair to say "Aligns ARIN policy with legal interpretation most friendly to legacy holders?" >> My point being this alignment presents the lowest risk toARIN of being sued for tortious interference in a contract. >> > > You have already been told multiple times that your interpretation of the words "exclusive right to transfer" > is not correct. The Plzack declaration was substantially modified by later rulings in the Kremen case. > >>>> 7. Imposes a yearly limit on needs-free transactions intended to prevent cornering. >> >>> Yes, but, this limit is effectively a no-op because anyone can create multiple entities needed >>> to accomplish enough /12 transfers to meet their desires. >> >> I trust ARIN staff to detect these with the same diligence applied to needs tests and section 12 reviews. >> > > It doesn't matter. If they are different organizations, ARIN can't claim that they aren't different organizations > for policy purpose just because it's clear that they were created for the purpose of doing an end-run on > the policy. ARIN must interpret the policy as written, even if that interpretation appears absurd, as in > the case of the single aggregate clause in the transfer policy. > >>> >>>> And likewise we have fairly addressed these issues. >>> >> >>> To some extent. >> >>>> Without considering (any more) the merits of those prior discussions, I would like to invite the consideration of any other potential benefits or consequences which we have not discussed. >>>> I am cognizant that this is proposal is a significant departure, and that the discussion of similar policy in APNIC consumed several years. >> >>> As it did here prior to being rejected here and accepted there. >> >> I didn't know there had also been prior discussion here about this (or fairly similar) policy. Do you rember about when so I can search the archives? >> > > In the early stages of 2008-2, there was discussion of a transfer policy without needs basis, at least among the AC before > we formulated 2008-2. I believe it was rejected by the community pretty much out of hand fairly early in the discussion > either at open policy hours and/or at the public policy meetings, but, it may have just been within the AC. After three > years and a whole lot of policy work, I have to admit my memory on exactly when and where a given discussion took > place is somewhat fuzzy. > >>>> I think we have covered pretty much all the bases in our relatively short but active discussion period, but I agree with Tom that we really should stretch our minds to consider all the potential pitfalls. >>>> So did we miss anything, or is there anything left to be said on the topics arrayed above? Any large loopholes or gotchas? Risks or threats we haven't considered? >> >>> One I think worth exploring is that given the recent staff interpretation of the term RSA in policy, >>> the requirement for RSA in the proposal may be insufficiently specific to express community >>> intent. >> >> I agree, though my intention was that it was the RSA, not an LRSA, but the RSA modified by my proposal. >> > > Understood, but, staff has made it quite clear that they will not interpret the policy as > written in that manner. > > Unfortunately, I am not sure that we can actually influence the choice of RSA through policy. > I'm hoping that a public clarification of this issue will be forthcoming soon. > >>>> Maybe the increased/decreased exposure of ARIN to lawsuits? >> >>> I think this would not significantly impact the legal exposure. We are as likely to get sued >>> by someone unable to obtain resources in the market on the basis that we failed to properly >>> regulate need in the market as we are to get sued by someone opposed to our attempts >>> to regulate need, IMHO. >> >> I can't see any legal right to sue ARIN if the community decides to drop the needs policy, but I am not a lawyer. > > This is the united States. Anyone can sue anyone for just about anything. > >> I wonder if anybody has sued APNIC on that basis? > > Entirely different legal system(s). > >> Maybe the ARIN legal staff can comment on that. >> But I can sure see somebody suing ARIN if ARIN re-issues their address to another allocant. > > ARIN wouldn't do that. What ARIN might do is issue addresses they have been hijacking to > another registrant, but, the point of policy is that it does not protect hijackers from this. If you > want the protections of guaranteed uniqueness, you have to play by the rules. If you do > an unregistered transfer, then, you aren't a registrant, you are a squatter at best and a > hijacker at worst. > >> If ARIN's legal interpretation is that they can revoke legacy addresses if they are not utilized, for example, that leads to their reissuance, and legal trouble. > > If they are still held by the original organization, generally ARIN will not do this. If they are being used > by an unregistered organization for an unregistered purpose, ARIN will probably first try to contact > the original organization to verify the intent. If a transfer was intended, ARIN would probably first attempt to work > with that organization to see if an 8.2 or 8.3 transfer could be made to fit the situation somehow. If they > cannot, or, the party using the addresses is unwilling to cooperate in that process, then, I have no > problem with ARIN reclaiming the addresses and I think that is the correct course of action. > >> If ARIN's legal interpretation is that legacy addresses are outside its authority, that risk is minimalized. > > So long as they are held by the original legacy registrant or their successor in interest, I believe ARIN > will continue to provide registration services to them. There is a difference between not reclaiming them > and believing that they are outside of ARIN authority, however. >> > > Owen > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From owen at delong.com Sat May 21 20:31:46 2011 From: owen at delong.com (Owen DeLong) Date: Sat, 21 May 2011 17:31:46 -0700 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate In-Reply-To: <62F7B0A04AEB4D88B7C351E20F825CDA@video> References: <4DCFDB5C64DD4F738B65AB82D36B629D@mike><15F92ECD-2BE5-48F2-B65A-9A9D39B98F54@delong.com> <0829B106605C4FE8B189DB2E56C69615@mike><51506A06-D2EE-4A0D-B92B-781662094A1C@eyeconomics.com> <0CCB8AB89D144E89872AF0D635E95497@mike><2691B7B9-1F3C-403C-B4E8-5B82BED0E191@eyeconomics.com> <454BB1826E7B4F2BB3A68BE1DD86A756@video> <909D6DD7-404F-4BB3-B330-78B755FAB6DA@eyeconomics.com> <156DA5A48E51490284BC21D982A8FDAB@mike> <62F7B0A04AEB4D88B7C351E20F825CDA@video> Message-ID: <94388F1C-C1B7-4AF6-BE33-C1ABF018BE30@delong.com> On May 21, 2011, at 6:45 AM, Mike Burns wrote: > Hi McTim, > > I don't see the slippery slope. I do. > IPv4 addresses have *already* been monetized. There is a difference between monetization and commoditization. > In the near future, once the free pool has exhausted, the only way to get IPv4 addresses will be to pay for them. > We can bemoan the fact, but we can't change that fact in any way I can see or that you have proposed. I don't see how that is particularly relevant to his point. > > Let's not setup a false dichotomy, as in pass my proposal and face the monetized IPv4 market, don't pass my proposal and somehow the deep pockets don't win. Pass your proposal and the deep pockets get an overwhelming victory handed to them on a silver platter. Don't pass you proposal and the deep pockets at least have to engage in some level of fraudulent manipulation to achieve that result. > With ARIN's existing policy, the deep pockets will still beat the shallow pockets. Perhaps, but, perhaps not to the extent or as easily or as readily or as quickly as under your proposal. Any one of those is an overall win for the community. > > The fundamental problem I have with your post is that you fail to recognize the significant game-changer that is exhaust. I disagree. > If you have read what I have written, you will find no mention of monetizing IPv6, and really there was no movement towards monetizing IPv4 until the brick wall of exhaust nearly hit us in the nose. > While you have not mentioned it, you have expressed support for competing privatized registries. The obvious and inevitable result of such a move is to dilute the public policy process with the obvious conclusion being the commoditization of all IP number resources, including IPv6 addresses and autonomous system numbers. Just because you have not mentioned something does not mean that it is not a probable future outcome of the continued evolution of policy along the lines that you have expressed support for. > So that's where we are, like it or not, we are at the exhaust point, and moving forward in IPv4 will require the purchase of IPv4 addresses. I don't think anyone has denied this, but, the question is whether the purchase of IP addresses is best managed with or without the inclusion of the existing justified need policy. McTim and I (and many others) believe that the community is best served by policy that includes the justified need. You believe that it is better to commoditize IPv4 addresses rather than merely monetize them. > > I argue that the needs basis is the appropriate model for handing out free addresses, but the purpose of the needs requirement, that is distribution to users who will put the addresses to productive use, has been superceded by the actions of the market, which I have argued will have the same overall effect of driving these assets to their most productive use. > Which argument has been refuted multiple times. You have yet to provide any proof whatsoever that your argument actually holds water. You have presented nothing to indicate that the monetization/actions of the market will somehow direct addresses to efficient use rather than to profitable acquisition. There is nothing to couple efficient use to profitable acquisition, and, in fact, many reasons to believe that the two are utterly unrelated. > As far as arresting what you consider a slide towards private registries, what could be better than arming our registries with the optimal tools to encourage registry at ARIN in order to forestall any flight to a private registry, which presumably would have some advantage in the customer's eyes? > If you eliminate policy and stewardship in favor of commoditizing address registrations by the registry, then, there is little difference between a single registry with a commoditized policy and competing registries other than a possible issue of price drivers. > If we insist on maintaining the needs analysis as a roadblock to (many? some? a few?) transactions, we are driving that registration out of the system you are praising, and to what end? I say we run the risk of actually incentivizing the switch to private registries, and lest we forget, there is nothing in the world to prevent private registries from popping up and succeeding if they provide some utility to customers and to network operators. > What you call a roadblock, many of us call proper stewardship. You are insisting that there are a significant number of transactions occurring outside of policy and that would somehow magically start being registered with ARIN if we only deleted this needs basis requirement. Further, you assert that a growing number of these transactions will occur without this policy and that the elimination of needs basis will somehow magically eliminate them. Unfortunately, you have failed to provide any evidence of any of these four assertions: 1. That such transfers are occurring. I believe that they are, but, we have no proof and there have not been enough of them to even be quantifiable. I am inclined to believe that they are occurring in such small quantities as to be insignificant. Certainly not in such quantities as to discredit the ARIN registry. 2. That such transfers will increase after runout. There's really nothing behind this assertion and no proof or strong reason to believe runout will affect the number of such transfers positively or negatively. 3. That removal of needs basis will cause such transfers that have happened to be registered with ARIN. Yes, it will remove one disincentive from registration, but, in most cases, this is not the most significant disincentive and is unlikely to make a difference to most parties unwilling to work within the ARIN policy framework. 4. That removal of needs basis will prevent such transfers from occurring in the future outside of ARIN policy. As in (3) above, there is no evidence to support this assertion. > We are stewards not just of IPv4 addresses, but AS numbers, Ipv6 addresses, AND Whois. At this point let us not make policy designed for the stewardship of free resources that operates at the risk of Whois accuracy and usefulness. > Indeed, we should not adopt this policy for exactly that reason. Not only is it poor stewardship for IPv4, but, it also sets bad precedents for the future stewardship of IPv6 and AS Number resources as well as being likely to further degrade the accuracy of whois as the IPv4 landscape degrades into a free-for-all of random trading both with and without ARIN registration. > The Internet succeeded, in your eyes, because it was open, transparent, and collaborative. Why then, are we engineering policy which is less transparent and less open? Remember, my policy does away with NDAs and allows for transparency in transactions by removing ARIN's transactional impediments and faciliating the registration on the public Whois registry. Maintaining needs drives transactions into the darkness and threatens the functionality of Whois, of which we are stewards. > The current policy is quite open and transparent. I don't see any greater openness or transparency contained in your policy. It does not do away with NDAs, nor could any policy do away with them. I'm not sure why you think it would. You again repeat the assertion that this requirement is driving transfers away from ARIN process in spite of recent evidence of an uptick in registrations of past transfers in the ARIN process with needs basis preserved. How do you explain this dichotomy between provable fact and your assertions? > Do we want transparent transactions, at least as far as knowing who controls what netblock? Then let's end the policies which prevent ARIN from registering the transfer of otherwise legal transactions. Of course we do. However, not at the cost of abandoning any proper stewardship of the resources in the process. Referring to transactions that don't meet needs basis as "otherwise legal transactions" is, IMHO, a lot like suggesting that we legalize theft so as to remove policies which prevent this "otherwise legal graft". Transactions which do not meet needs basis are harmful to the community in general and the community has long maintained that they should not be allowed. Just as theft is harmful to the community and therefore illegal in almost any society run by law. Yes, there are a certain number of these transactions that will probably manage to stay somewhat under the RADAR and survive in spite of their non-compliance with ARIN policy. In reality, this has probably been true for a very long time. However, ARIN policy like any community standard for the decent conduct of the citizens of the community in the community interest is generally dependent on voluntary compliance. Enforcement to any extent is an absolute last resort in any just structure of law. The average speed in 70 MPH zones on freeways in the US is 77.8 MPH. Something on the order of 80% of drivers operate their vehicles in excess of posted speed limits. Strangely, few seem to be calling such speed limits "unenforceable" or suggesting that they should be repealed on that basis. OTOH, I'd be surprised if there are more than 1% of resource holders who have made such transfers outside of ARIN policy and I doubt that number is likely to get above 5% even with current needs-basis preserved. As such, I think these transfers are outliers and not a sufficient body to represent any sort of consensus to change the policy. > > Let me just end with the crucial factor- we don't have any more IPv4 addresses left to steward, we have already moved into the commoditization of these addresses, but as long as the free pool of AS numbers and IPv6 addresses exists, stewardship requires some constraint on their allocation, and I have seen no mention anywhere, by anyone, that these things should be commoditized. Thus the fear of lifting needs requirements for addresses already allocated should not be transmogrified into some fear of ravenous capitalists set to devour the Internet model. > Just because they no longer sit in a free pool does not mean that our responsibility for stewardship has ended. We still have a responsibility to administer even a fully allocated address space. In some ways, the question of how we fulfill that role may be more defining than the much simpler questions of how to administer the allocation/assignment of addresses from an existing free pool. The monetization of addresses is not necessarily the same as the commoditization of the addresses. I agree that the monetization is a necessary and inevitable result of the current situation. I do not agree that commoditization is inevitable or even a proper or useful outcome for the community. You speak of fear, yet, this is not about fear from my perspective. I realize that by playing the fear card, you hope to discredit my arguments. I think that is rather transparent and useless in the debate, however. The reality is that commoditization rather than mere monetization of addresses will lead to ravenous capitalists devouring at least one aspect of the internet model. To me, the most crucial aspect of the internet is it's ability to democratize communications. If you allow ravenous capitalists to consume addresses without restriction, then, you allow that democratization to be terminated by said capitalists. Owen From mike at nationwideinc.com Sat May 21 22:29:56 2011 From: mike at nationwideinc.com (Mike Burns) Date: Sat, 21 May 2011 22:29:56 -0400 Subject: [arin-ppml] IPv4 Transfer Policy Change References: Message-ID: <49D09303B60646E492D919881F49B15E@video> Hi Rudolph, I considered restricting this proposal to legacy transfers, and I think these are the most fraught with trouble for Whois due to the uncertain legal rights that legacy holders have to transfer addresses without notifying ARIN. Right now it is not ARIN policy that the seller of legacy addresses is required to sign an LRSA, but the purchaser must sign some form of RSA. I decided to try to extend this policy to include addresses currently under RSA in an attempt to bring RSA holder rights more in alignment with those of legacy holders, by removing the utilization requirement for addresses held under RSA for 12 months. I just think that overall, it would make for a better future if we can end the class schism between legacy and non-legacy holders. It seems that ARIN's yearslong efforts to induce legacy holders to sign an LRSA have borne little fruit, so I attempted to increase the inducement to legacy buyers to sign an RSA, not an LRSA, when they make a purchase. Since this would give legacy address buyers the right to resell their addresses to anybody, and the right to purchase needs-free, it was my intention that these buyers would see registration in Whois as outweighing any negative effect of signing an RSA. But maybe I bit off too much, and I should have limited my proposal to recognizing needs-free transfers of legacy holders only. But I suppose my answer to your question is if we allow the legacy buyer to purchase needs-free, but require them to sign an RSA which currently gives ARIN the right to revoke for underutilization, the needs-free aspect is threatened by an immediate post-purchase revokation by ARIN. Regards, Mike ----- Original Message ----- From: Rudolph Daniel To: arin-ppml at arin.net Sent: Saturday, May 21, 2011 11:24 AM Subject: Re: [arin-ppml] IPv4 Transfer Policy Change Question: What would be the effect of removing the needs requirement for the transfer of resources from a legacy holder; and any transfer from the legacy holder signs an RSA as mandatory requirement and thus remove LRSA. rd No, this is an incorrect understanding of the ruling. The Plzak declaration is also not the final word on the subject. The exclusive right to transfer means that nobody else has the right to transfer them. It does not mean that they can be transfered regardless of policy or that ARIN must recognize a transfer outside of policy in the ARIN database. Legacy addresses were issued to a particular party for a particular purpose. Upon the end of that purpose or that party, they should be returned and are no longer legacy addresses. In the case of a transfer to a successor in interest through acquisition or merger, in some cases, the legacy status has been preserved, but, this is rare. In most cases, the receiving organization has been required to sign an ARIN standard RSA. It works this way... Legacy status is the intersection of the holder and the resources which were registered together by a registry preceding the RIR system. Once either of those conditions ceases, the resources are no longer in legacy status (in most cases). ARIN has an obligation to continue providing services to records with legacy status so long as that legacy status remains under the original terms of issue. ARIN has the right to reclaim addresses from defunct legacy organizations. > Given this, legal legacy transfers can occur where the purchased amount may not meet ARIN's need requirement. Not true. At least not if they want to be recognized by ARIN and have the transfer registered in whois. > If the buyer cannot meet the requirement, he will not register the addresses, although I have argued he will likely want the addresses registered to reflect his ownership of their rights. The unregistered addresses become subject to reclamation since they are no longer in use by the original organization under the original terms of issue. > But if there is no needs requirement, the disincentive is removed, the registration takes place, and the buyer signs an RSA. Ah, so you are once again confusing incentive with removal of disincentive. I can see how, to a limited extent, this might provide less of a disincentive for the recipient of a transfer from a legacy holder to register the transfer, but, I don't see how this is anything other than redundant to your point 1. > My proposal also reduces the disincentive to sign the RSA, as it removes the utilization requirement and frees the buyer to resell the addresses to anybody, with or without need. (Unless that buyer already has transferred a /12 equivalent). Yes, by neutering the RSA, you have removed some disincentives to sign it. However, I don't see neutering the RSA as a net positive in that regard. The community put section 12 into policy for a reason. > So I believe the net effect of the proposal is to make the RSA more attractive, and reduce the disincentive for registration of legacy transfers which do not meet the needs test. There is no such thing as a legacy transfer. There is a transfer of resources from a legacy holder, but, absent an awkward situation involving litigation these will almost always result in the space being handled as non-legacy if the transfer is recognized by ARIN. > > Remember, these are the intentions of the proposal, although I know you disagree with my legal interpretation, and thus the effect. > Yes... Your legal interpretation being contrary to statements made by ARIN counsel and John Curran, I am inclined to believe that it is not correct and therefore the effect of your proposal differs from your claimed effects. > >> 3. Provides for explicit protections against review audits for RSA holders after one year, bringing RSA rights more in accord with LRSA rights. > >> Uh, yeah, I don't see that as a good thing. Quite the opposite. However, I do agree that it is an intended >> consequence of the proposal. > >>> 4. Reduces transaction costs for transferers > >> I believe it will actually increase them. > > The intent of the proposal is that transactional costs related to the needs analysis can be avoided. These may be large or small. I suppose you mean the prices will be higher due to speculation, though. > Yes, I believe that the net price of the transaction will increase substantially. Further, the cost of needs analysis is built into the ARIN transfer fee which I do not think will change significantly as a result of this proposal. So, no price reduction and likely price increase. Doesn't look like a savings to me. >>> 5. Reduces ARIN costs for needs analyses > >> Agreed, but, not necessarily something I see as a beneficial aspect. > > >>> 6. Aligns ARIN policy with most possible interpretations of the legal rights of legacy holders > >> No, aligns ARIN policy with one possible interpretation of the legal rights of legacy holders. >> IMHO, not even the most probable one. > > See "exclusive right to transfer" and the Plzak declaration that ARIN has no authority over legacy addresses. > Would it be fair to say "Aligns ARIN policy with legal interpretation most friendly to legacy holders?" > My point being this alignment presents the lowest risk toARIN of being sued for tortious interference in a contract. > You have already been told multiple times that your interpretation of the words "exclusive right to transfer" is not correct. The Plzack declaration was substantially modified by later rulings in the Kremen case. >>> 7. Imposes a yearly limit on needs-free transactions intended to prevent cornering. > >> Yes, but, this limit is effectively a no-op because anyone can create multiple entities needed >> to accomplish enough /12 transfers to meet their desires. > > I trust ARIN staff to detect these with the same diligence applied to needs tests and section 12 reviews. > It doesn't matter. If they are different organizations, ARIN can't claim that they aren't different organizations for policy purpose just because it's clear that they were created for the purpose of doing an end-run on the policy. ARIN must interpret the policy as written, even if that interpretation appears absurd, as in the case of the single aggregate clause in the transfer policy. ------------------------------------------------------------------------------ _______________________________________________ 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 dogwallah at gmail.com Sun May 22 01:04:22 2011 From: dogwallah at gmail.com (McTim) Date: Sun, 22 May 2011 08:04:22 +0300 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate In-Reply-To: <62F7B0A04AEB4D88B7C351E20F825CDA@video> References: <4DCFDB5C64DD4F738B65AB82D36B629D@mike> <15F92ECD-2BE5-48F2-B65A-9A9D39B98F54@delong.com> <0829B106605C4FE8B189DB2E56C69615@mike> <51506A06-D2EE-4A0D-B92B-781662094A1C@eyeconomics.com> <0CCB8AB89D144E89872AF0D635E95497@mike> <2691B7B9-1F3C-403C-B4E8-5B82BED0E191@eyeconomics.com> <454BB1826E7B4F2BB3A68BE1DD86A756@video> <909D6DD7-404F-4BB3-B330-78B755FAB6DA@eyeconomics.com> <156DA5A48E51490284BC21D982A8FDAB@mike> <62F7B0A04AEB4D88B7C351E20F825CDA@video> Message-ID: Hi, On Sat, May 21, 2011 at 4:45 PM, Mike Burns wrote: > Hi McTim, > > I don't see the slippery slope. Can you at least recognise that different regions are at different places with respect to the degree of monetisation their policies allow? In the AfriNIC region, for example, their is no transfer policy. > IPv4 addresses have *already* been monetized. Yes, since the beginning of the RIR system, where for the first time, money changed hands in order to obtain IP resources. > In the near future, once the free pool has exhausted, the only way to get > IPv4 addresses will be to pay for them. or get in line with your RIR, but you still have to pay the RIR for services/membership. > We can bemoan the fact, but we can't change that fact in any way I can see > or that you have proposed. > Let's not setup a false dichotomy, as in pass my proposal and face the > monetized IPv4 market, don't ?pass my proposal and somehow the deep pockets > don't win. > With ARIN's existing policy, the deep pockets will still beat the shallow > pockets. see Owen's reply downthread. > > The fundamental problem I have with your post is that you fail to recognize > the significant game-changer that is exhaust. there is no failure on my part. I see it, but we just disagree on how to react to it. > If you have read what I have written, you will find no mention of monetizing > IPv6, and really there was no movement towards monetizing IPv4 until the > brick wall of exhaust nearly hit us in the nose. Apologies if I accused you of trying to monetise v6, I don't think I implied that. What I implied was that ppl will say "If I can trade v4, why can't I trade v6". There have been many attempts over the years to further monetise v4. Policy in various regions has stopped that. Now you want to change policy. I (and many others) disagree that this is a useful way forward. See Owen's reply downthread which applies to the the rest of your post. My responses are substantially the same as his, so no need for me to reiterate them. -- Cheers, McTim "A name indicates what we seek. An address indicates where it is. A route indicates how we get there."? Jon Postel From hannigan at gmail.com Sun May 22 11:49:38 2011 From: hannigan at gmail.com (Martin Hannigan) Date: Sun, 22 May 2011 11:49:38 -0400 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate In-Reply-To: <2B4CEE14-49C8-429A-B087-8A2E097A35C5@eyeconomics.com> References: <4DCFDB5C64DD4F738B65AB82D36B629D@mike> <15F92ECD-2BE5-48F2-B65A-9A9D39B98F54@delong.com> <0829B106605C4FE8B189DB2E56C69615@mike> <51506A06-D2EE-4A0D-B92B-781662094A1C@eyeconomics.com> <0CCB8AB89D144E89872AF0D635E95497@mike> <2691B7B9-1F3C-403C-B4E8-5B82BED0E191@eyeconomics.com> <454BB1826E7B4F2BB3A68BE1DD86A756@video> <909D6DD7-404F-4BB3-B330-78B755FAB6DA@eyeconomics.com> <156DA5A48E51490284BC21D982A8FDAB@mike> <2B4CEE14-49C8-429A-B087-8A2E097A35C5@eyeconomics.com> Message-ID: Tom, Thanks for the this. Very helpful and much appreciated. Best, Marty On Sat, May 21, 2011 at 5:46 PM, Tom Vest wrote: > Hi Mike, > > Per your suggestion, I'm going to add to the to the list of anticipated adverse direct and indirect/unintended consequences that you started. > > However, first I want to introduce a list of general consequences stemming from the exhaustion of the unallocated IPv4 reserves that may or may not be affected positively or negatively by your proposal, or by transfers in general. I think that that is only sensible way to start such an accounting, and I submit that *this* is the context against which your proposal (and all other transfer-related proposals, past and present) should be evaluated. > > I'm introducing this now because of some recent off-list communications suggesting that a lack of context has made it difficult for some recent ppml subscribers to to interpret the discussion so far as anything more than the extension of a more general political argument into the address policy sphere. > > I. Anticipated Consequences of Exhaustion of the Unallocated IPv4 Resource Pool > > 1.1. IPv4's status as a critical, non-substitutable -- a.k.a. "bottleneck" -- requirement for engaging in most kinds of "commercial Internet activity" (i.e., anything involving any combination of "high volume," "high reliability," or "managerial independence") means that the exhaustion of unallocated IPv4 reserves will effective close the only neutral channel for accommodating entry into the Internet industry -- which happens to be the same channel through which all current IPv4 address holders came to possess those IPv4 holdings. > > 1.2. The closure of the only neutral channel for acquiring IPv4 will change current IPv4 holders in two or possibly three important ways. First, it will leave incumbent IPv4 holders as the sole potential providers of the critical, non-substitutable, bottleneck resource without which competitive entry into any segment of the Internet services sector is impossible. This change in status will significantly boost the *absolute* bargaining power of all IPv4 holders over and above whatever level that they enjoyed in the pre-exhaustion period, with the *relative* gain in market power enjoyed by individual IPv4 incumbents varying by degree and potential duration based on the absolute size of their IPv4 reserves. > > 1.3 The exhaustion of the neutral IPv4 reserves will also affect incumbent IPv4 holders by constraining their traditional, IPv4-dependent mechanisms for attracting and integrating new customers and for accommodating the subsequent growth of existing customers. As these traditional mechanisms become increasingly constrained, incumbent IPv4-based service providers will be compelled to choose between several unappealing options, including > ? ? ? ?1.3(a) continuing to to provide current IPv4-based customers and services, but foregoing all other revenue opportunities, > ? ? ? ?1.3(b) freeing up IPv4 for ongoing customer/revenue growth by renumbering most of their own infrastructure with IPv6, > ? ? ? ?1.3(c) pursuing customer/revenue expansion by raising prices to push low-dollar customers to seek out alternate IPv4 providers and/or to accept smaller IPv4 assignments or other/second-best attachment options -- which today would include NAT, NAT4n, and IPv6, > ? ? ? ?1.3(d) taking a one-time windfall by liquidating all of their IPv4 holdings and reducing their subsequent service offerings to native IPv6-based customers that are supportable exclusively via native IPv6-based interconnections with accessible native IPv6-based peers and transit providers, or > ? ? ? ?1.3(e) liquidating as in d and then exiting the market. > > 1.4 IPv4-based incumbents that opt for any of 1.3(a-d) will be significantly affected in a third way by virtue of the fact that they will compelled to choose *on behalf of all of their customers* how to accommodate inbound and outbound IPv4 and IPv6 traffic exchanges between those customers and any/all networks that are managed by someone else. As long as internal customer demand for interaction with external IPv4-based resources remains high, accommodating demand for such interconnections will create a separate operational (i.e., non-revenue-generating) IPv4 requirement that will be in direct contention with other direct revenue-generating IPv4 assignments. > > 1.5 Each of the above options that are available to IPv4 incumbents may or may not incorporate an additional revenue stream from the fee-simple sale of IPv4 addresses to third parties. Although there are many other kinds of contractual vehicles that incumbent IPv4 holders might employ to monetize their non-assigned IPv4 reserves in an open transfer market, all of the others produce the same kind of direct customer-provider relations -- and whois responsibilities -- associated with 1.3(a-c) and thus may be ignored. Each fee-simple sale of IPv4 would absolutely reduce internal IPv4 reserves that are required to support current revenue-generating IPv4-based customers and any/all traffic exchanges between internal customers and off-net resources that involve IPv4 on either side. Under current conditions, each offering of fee-simple IPv4 would occur in a market in which aspiring industry entrants might be in contention with other incumbent IPv4-based service providers. Let 1.5(a) > ?denote fee-simple IPv4 transfers between two incumbent, IPv4-holding service providers, and 1.5(b) denote fee-simple transfers between an incumbent, IPv4-holding Internet service provider and a first-time IPv4 recipient, which if subject to a needs/"capability" test would make them a "new entrant." > > 1.6 ?The approval of an IPv4 transfer market effectively created a new set of stakeholders whose actions could impact the price, availability, and status of IPv4, i.e., non-Internet service providers who can claim title to IPv4 addresses that were allocated under the old system but which are currently idle. Let 1.6(a) denote fee-simple IPv4 transfers between an IPv4-holding non-ISP and a incumbent, IPv4-based service provider, and 1.6(b) ?indicate a fee-simple transfers between an IPv4-holding non-ISP and a first-time IPv4 recipient, which if subject to a needs/"capability" test would make them a "new entrant." > > 1.7 The *absolute* bifurcation of market opportunities and bargaining power that will result from the disappearance of a neutral/open source for any kind of portable IP addresses that permit unconstrained (de facto global) interoperability will persist indefinitely unless/until one of three things happens: > > ? ? ? ?1.7(a) the preponderance of IPv4 holders -- i.e., almost all of 1.3(a-c) -- individually choose to forego any potential service market advantages AND any potential future windfalls from IPv4 sales by enabling ?all of their customers to participate in both inbound and outbound traffic exchanges with native IPv6-based destinations on a transparent, ad hoc, demand-driven basis on par with current IPv4-to-IPv4 connections [note: this would also eliminate any relative advantage associated with IPv4, and thus effectively restore the status quo ante -- i.e., an open market in which possession of any/all IP addressing conferred the same capabilities and opportunities to all address holders]. Call this this "open-at-will" scenario. > > ? ? ? ?1.7 (b) Fee-simple transfers of IPv4 address continue over an extended period, until eventually the market(s) reach a point where no service provider enjoys any market advantage over any other based solely on the distribution of IP addresses. This point might correspond to a moment in the distant future when the Internet industry hits the TCP/IP-imposed ceiling of 2^32 independent service providers each holding exactly one IPv4 address. Alternately, it might happen in the marginally less distant future, e.g., when the the population of post-allocation, fee-simple IPv4 buying, IPv6-based service providers grows so vast and powerful as to dominate the population of incumbent, pre-allocation fee-simple IPv4 selling service providers that they've been competing against in the interim. Call this this "decision-by-demographics" scenario. > > ? ? ? ?1.7 (c) Insufficient fee-simple IPv4 acquisition opportunities at price points that are sustainable by aspiring competitive entrants causes the transfer market to fail. Incumbent IPv4 based service providers continue to accommodate new customer growth, albeit with varying combinations of IP4, IPv6, and private addressing that have no effect on IPv4's status as a critical, non-substitutable "bottleneck" for engaging in commercial Internet activities. The Internet becomes progressively more complex and expensive to operate, but it still works -- at least for the generation of service providers that predated the exhaustion of the unallocated IPv4 address pool. After that, anyone with an ambition to become an independent commercial Internet content or service provider just has to buy one of the incumbent providers. For everyone else, the Internet is closed. Call this the "numbers-as-land" scenario. > > ? ? ? ?1.7 (d) Some new, as-yet unimagined technology that eliminates the IPv4-IPv6 incompatibility emerges, or alternately a new networking paradigm that is both widely regarded as superior to TCP/IP AND is as transparent to TCP/IP as TCP/IP is to physical media makes the whole problem go away. Call this the "saved-by-magic" scenario. > > _____ > > > II. Suggested Adverse Consequences of Mike's Proposal to Eliminate Needs ("Capability") Testing > > 2.1 Market distortions will happen due to the selfish actions of speculators, including market cornering attempts. > 2.2 Disaggregation will increase. > 2.3 It is too radical a change, and change should appropriately come incrementally, like extending the length of the needs window. > 2.4 It will make it easier for bad players like spammers to get addresses. > 2.5 It will run the risk of actually making Whois less accurate. > 2.6 Addresses will be used less efficiently if we only rely on price to drive their productive use. > 2.x Others, forthcoming > > _____ > > > III. Suggested Positive Effects of Mike's Proposal to Eliminate Needs ("Capability") Testing > > 3.1 Provides an incentive for more transactions to be registered by ARIN > 3.2 Provides an incentive for legacy space to be brought under RSA > 3.3 Provides for explicit protections against review audits for RSA holders after one year, bringing RSA rights more in accord with LRSA rights. > 3.4 Reduces transaction costs for transferrers > 3.5 Reduces ARIN costs for needs analyses > 3.6 Aligns ARIN policy with most possible interpretations of the legal rights of legacy holders > 3.7 Imposes a yearly limit on needs-free transactions intended to prevent cornering. > > _____ > > My own initial interpretation: > > One immediate and direct effect of eliminating needs/"capability" testing would be to greatly expand the demand side of the IPv4 market in two way: by effectively legalizing the participation of market makers (a.k.a. "speculators") that have no direct material interest in Internet production themselves, and by enabling such speculators -- or anyone else, including incumbent, IPv4-based service providers -- to express potentially infinite demand for IPv4, limited only by whatever the (NDA-shrouded) market will bear. > > As a very distant second order effect, the elimination of a needs/"capability" testing might also increase the supply of IPv4 -- but the only way that I can imagine how the proposed change might have that effect would be IF the newly-legalized speculators actually turn out to be *much better and much faster* than both incumbent IPv4 holders and aspiring new Internet service providers are both at locating and liberating idled IPv4, and at moving it back into productive use as quickly as possible. In other words, if the speculators could bring IPv4 to market at a price that is actually *below* what it would cost any actual network service provider to acquire it and bring it into useful service, then the delta between those two price points would represent 100% of the "supply premium" created by eliminating the needs requirement. > > But in the real world, there's no way that that "supply premium" would be a positive number. Much more likely that it would be a very very large negative number. > > And that negative supply contribution would be *on top of* the many and varied direct and indirect/unintended consequences that would result if this proposal were approved -- details of which I'll save for a later message... > > Regards, > > TV > > > > > On May 20, 2011, at 3:56 PM, Mike Burns wrote: > >> Hello to the list, >> >> Per what Tom wrote at the bottom, I am all for considering the consequences of my proposal, intended or otherwise. >> >> So I believe the consequences we have considered, and please add to this list if you want, are: > >> I figure we have addressed these issues enough, and that we are rehashing discussions to no additional benefit. >> >> And I have had the opportunity to address the intentions of the policy proposal, which are: >> >> >> And likewise we have fairly addressed these issues. >> >> Without considering (any more) the merits of those prior discussions, I would like to invite the consideration of any other potential benefits or consequences which we have not discussed. >> I am cognizant that this is proposal is a significant departure, and that the discussion of similar policy in APNIC consumed several years. >> I think we have covered pretty much all the bases in our relatively short but active discussion period, but I agree with Tom that we really should stretch our minds to consider all the potential pitfalls. >> So did we miss anything, or is there anything left to be said on the topics arrayed above? Any large loopholes or gotchas? Risks or threats we haven't considered? >> Maybe the increased/decreased exposure of ARIN to lawsuits? >> >> (I will admit to enjoying reading my own words. But as they are growing tiresome to me, they must be coma-inducing to you by now.) >> >> Of course I don't mean to cutoff any discussions about any topic, if you think there is more to add. >> >> Regards, >> Mike >> >> >> >> >> >> >> >> ----- Original Message ----- From: "Tom Vest" >> To: "Chris Engel" >> Cc: "Mike Burns" ; >> Sent: Friday, May 20, 2011 3:09 PM >> Subject: Re: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate >> >> >> >> On May 20, 2011, at 1:24 PM, Chris Engel wrote: >> >>> Tom, >>> >>> Excising a particular section of this thread for the sake of brevity... >>> >>>> Fair enough, you prefer to argue logic rather than facts: >>>> >>>> Please provide a negative proof that "logic" could never lead any future >>>> address user, potential address buyer, and/or potential address seller to >>>> conclude that registration would not advance their own private interests. >>>> >>>> Please provide a negative proof that "logic" could never lead any future >>>> address user, potential address buyer, and/or potential address seller to >>>> embrace "sales-friendly registration" but simultaneously reject >>>> "operationally relevant registration" (i.e., the kind that makes whois an >>>> appropriate subject of interest for community deliberation). >>>> >>>> Please provide a negative proof that "logic" will BOTH always lead all future >>>> address users, address buyers, and address sellers to self-maintain >>>> "operationally relevant registration" for themselves in perpetuity, AND that >>>> the attainment of that outcome by means of needs-free transfers could >>>> never have any unintended consequences that might be as serious or more >>>> serious than some marginal degradation of whois accuracy. >>>> >>> >>> I don't think the above is a fair tactic for debate. You are asking Mike to prove a logical fallacy. Furthermore, when you start using words like "never" and "always" when discussing human behavior as benchmarks for judging the legitimacy of a system...your standards themselves appear absurd. If we applied the same standards for judging the appropriateness of a "needs" based policy, it would assuredly fail as well. Systems designed to regulate human behavior cannot achieve a uniformity of results approaching mathematical perfection, nor need they do so to be effective (IMO). >>> >>> If you want to argue that it's likely a substantial number of individuals would have logical reasons for not wanting to maintain accurate registration under the policy Mike proposes...that's (IMO) a reasonable standard to base an argument on. Not sure whether I would agree with that proposition or not...but the standard is reasonable. Asking Mike to provide a standard of proof that couldn't allow for even a single exception isn't (IMO). >>> >>> >>> Christopher Engel >>> (Representing only my own views) >> >> Hi Chris, >> >> Thanks for the reactions. Of course you are right on this count. My apologies to Mike for demanding what is, technically, logically impossible to deliver. >> >> My intent was not to be merely hyperbolic, but rather to *strongly* suggest that we all engage our imaginations fully when considering the range of strategic responses that might seem to be "rational" from the perspective of any clever entrepreneur who may or may not have any long-term interest in what happens to the Internet or to others who count the Internet for their livelihood or anything else, once s/he is done. Granted, this year we're all operating in an environment that has been significantly shaped by the unintended consequences of last year's strategic adjustments to the previous year's entrepreneurial cleverness, and so on... I mean, who could have anticipated that DWDM might trigger changes in SFP policies that helped to ignite our first crash, or that widespread diffusion of P2P might prompt another shift in commercial strategy that could in turn precipitate a run on the ASN16 reserves? >> >> Suffice it to say that there are always plenty of smart people out there working out every conceivable new angle that might be exposed by the next change in policy and/or technology and/or market structure -- and in general, at most times, we all benefit tremendously from that fact. But that only remains true as long we do not, through omission or commission, open up any loopholes that are big enough to allow to whole industry to fall through, into who-knows-what. These days it's not really possible to doubt that such things can and in fact do happen from time to time. >> >> I submit that the removal of "capability" testing would not only represent an irreversible change, but also has the potential to create a number of potentially fatal loopholes. And so in this particular case, I recommend that we proceed only if/after we can first achieve a very high level of confidence that no serious risks or threats are immediately created thereby. >> >> 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 mysidia at gmail.com Sun May 22 15:46:37 2011 From: mysidia at gmail.com (Jimmy Hess) Date: Sun, 22 May 2011 14:46:37 -0500 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate In-Reply-To: References: <4DCFDB5C64DD4F738B65AB82D36B629D@mike> <15F92ECD-2BE5-48F2-B65A-9A9D39B98F54@delong.com> <0829B106605C4FE8B189DB2E56C69615@mike> <51506A06-D2EE-4A0D-B92B-781662094A1C@eyeconomics.com> <0CCB8AB89D144E89872AF0D635E95497@mike> <2691B7B9-1F3C-403C-B4E8-5B82BED0E191@eyeconomics.com> <454BB1826E7B4F2BB3A68BE1DD86A756@video> <909D6DD7-404F-4BB3-B330-78B755FAB6DA@eyeconomics.com> <156DA5A48E51490284BC21D982A8FDAB@mike> <2B4CEE14-49C8-429A-B087-8A2E097A35C5@eyeconomics.com> Message-ID: On Fri, May 20, 2011 at 11:40 AM, Chris Engel wrote: > Brett, > Under that same scenario, what is to stop the same speculator from creating 16 different legal entities that purchase IP-Enabled devices (i.e. pet rocks) from the parent company to show it meets it's "needs" and "utilization" requirements under a "needs" based regulatory requirement for transfers? If they state the intended use of IP addresses is for their 'pet rocks', acquire them, and intend to speculate on, lease, or "flip" the IP addresses for a profit a few weeks later, then that would mean their application was false. There's not a lot ARIN itself can directly do about fraud, other than attempt to detect it, make it difficult, and make sure to have enough correspondence with applicants, that an applicant cannot claim ignorance. The penalties ARIN can directly impose on false applications are so limited... the threat of IP address revokation is not likely to be a deterrent for speculators, who may not have legitimate need for _any_ IP resources in the first place. And any "fine" or "penalty" ARIN could create would be mitigated by speculators' carefully designed corporate structure. -- -JH From tvest at eyeconomics.com Sun May 22 16:36:01 2011 From: tvest at eyeconomics.com (Tom Vest) Date: Sun, 22 May 2011 16:36:01 -0400 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate In-Reply-To: References: <4DCFDB5C64DD4F738B65AB82D36B629D@mike> <15F92ECD-2BE5-48F2-B65A-9A9D39B98F54@delong.com> <0829B106605C4FE8B189DB2E56C69615@mike> <51506A06-D2EE-4A0D-B92B-781662094A1C@eyeconomics.com> <0CCB8AB89D144E89872AF0D635E95497@mike> <2691B7B9-1F3C-403C-B4E8-5B82BED0E191@eyeconomics.com> <454BB1826E7B4F2BB3A68BE1DD86A756@video> <909D6DD7-404F-4BB3-B330-78B755FAB6DA@eyeconomics.com> <156DA5A48E51490284BC21D982A8FDAB@mike> <2B4CEE14-49C8-429A-B087-8A2E097A35C5@eyeconomics.com> Message-ID: Hi Jeff, When I complete my addendum to the risks section, I intend to repost all three sections with consistent quote level labeling throughout to facilitate clarity/continuity in any subsequent discussions. I'll make sure that your point 3.8 goes into that refreshed list. At the same time, I would argue that this is probably be true of "speculators" in all markets for purely financial instruments (i.e., things that only use-value within the monetary/financial exchange sector of the economy), and even of speculators in markets for most physical commodities -- at least to the degree that the requirements that the commodity in question satisfies in the non-financial/"productive" sectors of the economy can also be satisfied by other/different commodity inputs). However, it is NOT true in markets for goods that are truly non-substitutable. For example, you probably wouldn't want to argue the merits of speculation in the "market"/allocation regime for transplant organs. The same reasoning reasoning recommends the same prohibition against speculation in IP addresses. Now, for the tiny handful of people on this list who have seen any of my previous comparisons of our industry to the monetary/financial sector, this might sound like an inconsistency or self-contradiction. After all, today "money" is a commodity that's subject to massive speculation 24x7x365, and yet that doesn't seem to prevent it from working (on most days, for most people), right? The thing to remember is that the opening up of the "money market" is actually a very recent phenomenon -- one that only got started after all of the major trading economies adopted "fiat" currency regimes, i.e., the kind that empowers them technically to unilaterally print new money whenever it seems like a good idea. Before that "floating exchange rate" system became the global norm, the currencies of large trading economies were quantity constrained by the "gold standard," which technically equated every monetary unit in circulation with some fixed quantity of real/physical/scarce gold bullion. So back then, whenever a sudden outflow of gold happened, jewelers and dentists wouldn't be the only ones who would find that their day jobs had become much harder/more difficult, or perhaps completely impossible; every single person and business that used money for anything would find that getting money had become tougher. Merchants couldn't afford to slash prices too far on things that they'd already made/obtained to sell, and consumers became increasingly unable to pay the old prices -- and then unwilling to pay discounted prices since it looked like everything would probably be discounted even further in the near future. When nothing gets sold, there's no need to employ salesmen, or manufacturing workers to make refresh inventories -- or anyone else really -- and then the income that supports the demand side of the economy drops still further. Monetary policy makers back in those days understood these dynamics well, and knew from experience and history how disruptions in the supply of gold could wreck an entire economy. Eventually (barring the apocalypse), they knew that the world economy would inevitably outgrow the capacity of gold to function as a quantity constraint on the pool of monetary instruments that were used on a daily basis, but as stewards of that shared critical infrastructure they tried to make it last as long as absolutely possible. And one of the things they did to that end was to outlaw the sale, purchase, or ownership of monetary gold by anyone or any company other than a select few highly regulated national bank centers. In the US, speculation in gold was not decriminalized until 1978 -- appx. five years after the US officially abandoned the gold standard. I didn't mean for this to be a long message, but I can't resist adding one last observation: One could argue, I think, in favor of the merits of speculation in an IPv4 market, but it would have to be the same kind of argument that banks that were heavily involved in the subprime mortgage market made when it was belated discovered that they had actually earned as much if not more by short-selling subprime mortgages than they had by supplying that market themselves. at the moment it looks like the banks will probably get away with this on the premise that they needed to hedge their very very risky bets that subprime lenders would actually pay off their loans -- even though their (logically prior but chronologically simultaneous) judgments about those lending risks was already not just baked in, but was in fact a major causal factor behind the very existence of those subprime loans. If we want to force incumbent IPv4-based service providers to face the same unavoidable conflicts of interest, and want to make them feel even more tempted (and/or compelled by the competitive risks) to adopt the same perverse, ultimately catastrophic strategy, then my all means let's embrace speculation -- because every purchase of IPv4 by anyone who is not directly and actively involved in the business of transitioning the Internet of IPv6 is effectively short-selling IPv6. Regards, TV On May 21, 2011, at 6:07 PM, Jeffrey Lyon wrote: > Allow me to add a 3.8: Speculators referenced in 2.1 aid market > liquidity, allowing those wishing to trade IP resources to do so in an > expedient manner. > > "Liquidity maintains order within the financial markets and is the key > driver behind efficient exchanges. Speculators add huge amounts of > money to the markets, and the more money they invest in the market, > the more liquid it becomes. An efficient market (very liquid) allows > for buyers and sellers to trade with one another with relative ease > without causing large shifts in prices." > > Source: http://www.investopedia.com/ask/answers/09/speculators-destabilizing.asp > > Jeff > > On Sat, May 21, 2011 at 5:46 PM, Tom Vest wrote: >> Hi Mike, >> >> Per your suggestion, I'm going to add to the to the list of anticipated adverse direct and indirect/unintended consequences that you started. >> >> However, first I want to introduce a list of general consequences stemming from the exhaustion of the unallocated IPv4 reserves that may or may not be affected positively or negatively by your proposal, or by transfers in general. I think that that is only sensible way to start such an accounting, and I submit that *this* is the context against which your proposal (and all other transfer-related proposals, past and present) should be evaluated. >> >> I'm introducing this now because of some recent off-list communications suggesting that a lack of context has made it difficult for some recent ppml subscribers to to interpret the discussion so far as anything more than the extension of a more general political argument into the address policy sphere. >> >> I. Anticipated Consequences of Exhaustion of the Unallocated IPv4 Resource Pool >> >> 1.1. IPv4's status as a critical, non-substitutable -- a.k.a. "bottleneck" -- requirement for engaging in most kinds of "commercial Internet activity" (i.e., anything involving any combination of "high volume," "high reliability," or "managerial independence") means that the exhaustion of unallocated IPv4 reserves will effective close the only neutral channel for accommodating entry into the Internet industry -- which happens to be the same channel through which all current IPv4 address holders came to possess those IPv4 holdings. >> >> 1.2. The closure of the only neutral channel for acquiring IPv4 will change current IPv4 holders in two or possibly three important ways. First, it will leave incumbent IPv4 holders as the sole potential providers of the critical, non-substitutable, bottleneck resource without which competitive entry into any segment of the Internet services sector is impossible. This change in status will significantly boost the *absolute* bargaining power of all IPv4 holders over and above whatever level that they enjoyed in the pre-exhaustion period, with the *relative* gain in market power enjoyed by individual IPv4 incumbents varying by degree and potential duration based on the absolute size of their IPv4 reserves. >> >> 1.3 The exhaustion of the neutral IPv4 reserves will also affect incumbent IPv4 holders by constraining their traditional, IPv4-dependent mechanisms for attracting and integrating new customers and for accommodating the subsequent growth of existing customers. As these traditional mechanisms become increasingly constrained, incumbent IPv4-based service providers will be compelled to choose between several unappealing options, including >> 1.3(a) continuing to to provide current IPv4-based customers and services, but foregoing all other revenue opportunities, >> 1.3(b) freeing up IPv4 for ongoing customer/revenue growth by renumbering most of their own infrastructure with IPv6, >> 1.3(c) pursuing customer/revenue expansion by raising prices to push low-dollar customers to seek out alternate IPv4 providers and/or to accept smaller IPv4 assignments or other/second-best attachment options -- which today would include NAT, NAT4n, and IPv6, >> 1.3(d) taking a one-time windfall by liquidating all of their IPv4 holdings and reducing their subsequent service offerings to native IPv6-based customers that are supportable exclusively via native IPv6-based interconnections with accessible native IPv6-based peers and transit providers, or >> 1.3(e) liquidating as in d and then exiting the market. >> >> 1.4 IPv4-based incumbents that opt for any of 1.3(a-d) will be significantly affected in a third way by virtue of the fact that they will compelled to choose *on behalf of all of their customers* how to accommodate inbound and outbound IPv4 and IPv6 traffic exchanges between those customers and any/all networks that are managed by someone else. As long as internal customer demand for interaction with external IPv4-based resources remains high, accommodating demand for such interconnections will create a separate operational (i.e., non-revenue-generating) IPv4 requirement that will be in direct contention with other direct revenue-generating IPv4 assignments. >> >> 1.5 Each of the above options that are available to IPv4 incumbents may or may not incorporate an additional revenue stream from the fee-simple sale of IPv4 addresses to third parties. Although there are many other kinds of contractual vehicles that incumbent IPv4 holders might employ to monetize their non-assigned IPv4 reserves in an open transfer market, all of the others produce the same kind of direct customer-provider relations -- and whois responsibilities -- associated with 1.3(a-c) and thus may be ignored. Each fee-simple sale of IPv4 would absolutely reduce internal IPv4 reserves that are required to support current revenue-generating IPv4-based customers and any/all traffic exchanges between internal customers and off-net resources that involve IPv4 on either side. Under current conditions, each offering of fee-simple IPv4 would occur in a market in which aspiring industry entrants might be in contention with other incumbent IPv4-based service providers. Let 1.5(a) >> denote fee-simple IPv4 transfers between two incumbent, IPv4-holding service providers, and 1.5(b) denote fee-simple transfers between an incumbent, IPv4-holding Internet service provider and a first-time IPv4 recipient, which if subject to a needs/"capability" test would make them a "new entrant." >> >> 1.6 The approval of an IPv4 transfer market effectively created a new set of stakeholders whose actions could impact the price, availability, and status of IPv4, i.e., non-Internet service providers who can claim title to IPv4 addresses that were allocated under the old system but which are currently idle. Let 1.6(a) denote fee-simple IPv4 transfers between an IPv4-holding non-ISP and a incumbent, IPv4-based service provider, and 1.6(b) indicate a fee-simple transfers between an IPv4-holding non-ISP and a first-time IPv4 recipient, which if subject to a needs/"capability" test would make them a "new entrant." >> >> 1.7 The *absolute* bifurcation of market opportunities and bargaining power that will result from the disappearance of a neutral/open source for any kind of portable IP addresses that permit unconstrained (de facto global) interoperability will persist indefinitely unless/until one of three things happens: >> >> 1.7(a) the preponderance of IPv4 holders -- i.e., almost all of 1.3(a-c) -- individually choose to forego any potential service market advantages AND any potential future windfalls from IPv4 sales by enabling all of their customers to participate in both inbound and outbound traffic exchanges with native IPv6-based destinations on a transparent, ad hoc, demand-driven basis on par with current IPv4-to-IPv4 connections [note: this would also eliminate any relative advantage associated with IPv4, and thus effectively restore the status quo ante -- i.e., an open market in which possession of any/all IP addressing conferred the same capabilities and opportunities to all address holders]. Call this this "open-at-will" scenario. >> >> 1.7 (b) Fee-simple transfers of IPv4 address continue over an extended period, until eventually the market(s) reach a point where no service provider enjoys any market advantage over any other based solely on the distribution of IP addresses. This point might correspond to a moment in the distant future when the Internet industry hits the TCP/IP-imposed ceiling of 2^32 independent service providers each holding exactly one IPv4 address. Alternately, it might happen in the marginally less distant future, e.g., when the the population of post-allocation, fee-simple IPv4 buying, IPv6-based service providers grows so vast and powerful as to dominate the population of incumbent, pre-allocation fee-simple IPv4 selling service providers that they've been competing against in the interim. Call this this "decision-by-demographics" scenario. >> >> 1.7 (c) Insufficient fee-simple IPv4 acquisition opportunities at price points that are sustainable by aspiring competitive entrants causes the transfer market to fail. Incumbent IPv4 based service providers continue to accommodate new customer growth, albeit with varying combinations of IP4, IPv6, and private addressing that have no effect on IPv4's status as a critical, non-substitutable "bottleneck" for engaging in commercial Internet activities. The Internet becomes progressively more complex and expensive to operate, but it still works -- at least for the generation of service providers that predated the exhaustion of the unallocated IPv4 address pool. After that, anyone with an ambition to become an independent commercial Internet content or service provider just has to buy one of the incumbent providers. For everyone else, the Internet is closed. Call this the "numbers-as-land" scenario. >> >> 1.7 (d) Some new, as-yet unimagined technology that eliminates the IPv4-IPv6 incompatibility emerges, or alternately a new networking paradigm that is both widely regarded as superior to TCP/IP AND is as transparent to TCP/IP as TCP/IP is to physical media makes the whole problem go away. Call this the "saved-by-magic" scenario. >> >> _____ >> >> >> II. Suggested Adverse Consequences of Mike's Proposal to Eliminate Needs ("Capability") Testing >> >> 2.1 Market distortions will happen due to the selfish actions of speculators, including market cornering attempts. >> 2.2 Disaggregation will increase. >> 2.3 It is too radical a change, and change should appropriately come incrementally, like extending the length of the needs window. >> 2.4 It will make it easier for bad players like spammers to get addresses. >> 2.5 It will run the risk of actually making Whois less accurate. >> 2.6 Addresses will be used less efficiently if we only rely on price to drive their productive use. >> 2.x Others, forthcoming >> >> _____ >> >> >> III. Suggested Positive Effects of Mike's Proposal to Eliminate Needs ("Capability") Testing >> >> 3.1 Provides an incentive for more transactions to be registered by ARIN >> 3.2 Provides an incentive for legacy space to be brought under RSA >> 3.3 Provides for explicit protections against review audits for RSA holders after one year, bringing RSA rights more in accord with LRSA rights. >> 3.4 Reduces transaction costs for transferrers >> 3.5 Reduces ARIN costs for needs analyses >> 3.6 Aligns ARIN policy with most possible interpretations of the legal rights of legacy holders >> 3.7 Imposes a yearly limit on needs-free transactions intended to prevent cornering. >> >> _____ >> >> My own initial interpretation: >> >> One immediate and direct effect of eliminating needs/"capability" testing would be to greatly expand the demand side of the IPv4 market in two way: by effectively legalizing the participation of market makers (a.k.a. "speculators") that have no direct material interest in Internet production themselves, and by enabling such speculators -- or anyone else, including incumbent, IPv4-based service providers -- to express potentially infinite demand for IPv4, limited only by whatever the (NDA-shrouded) market will bear. >> >> As a very distant second order effect, the elimination of a needs/"capability" testing might also increase the supply of IPv4 -- but the only way that I can imagine how the proposed change might have that effect would be IF the newly-legalized speculators actually turn out to be *much better and much faster* than both incumbent IPv4 holders and aspiring new Internet service providers are both at locating and liberating idled IPv4, and at moving it back into productive use as quickly as possible. In other words, if the speculators could bring IPv4 to market at a price that is actually *below* what it would cost any actual network service provider to acquire it and bring it into useful service, then the delta between those two price points would represent 100% of the "supply premium" created by eliminating the needs requirement. >> >> But in the real world, there's no way that that "supply premium" would be a positive number. Much more likely that it would be a very very large negative number. >> >> And that negative supply contribution would be *on top of* the many and varied direct and indirect/unintended consequences that would result if this proposal were approved -- details of which I'll save for a later message... >> >> Regards, >> >> TV >> >> >> >> >> On May 20, 2011, at 3:56 PM, Mike Burns wrote: >> >>> Hello to the list, >>> >>> Per what Tom wrote at the bottom, I am all for considering the consequences of my proposal, intended or otherwise. >>> >>> So I believe the consequences we have considered, and please add to this list if you want, are: >> >>> I figure we have addressed these issues enough, and that we are rehashing discussions to no additional benefit. >>> >>> And I have had the opportunity to address the intentions of the policy proposal, which are: >>> >>> >>> And likewise we have fairly addressed these issues. >>> >>> Without considering (any more) the merits of those prior discussions, I would like to invite the consideration of any other potential benefits or consequences which we have not discussed. >>> I am cognizant that this is proposal is a significant departure, and that the discussion of similar policy in APNIC consumed several years. >>> I think we have covered pretty much all the bases in our relatively short but active discussion period, but I agree with Tom that we really should stretch our minds to consider all the potential pitfalls. >>> So did we miss anything, or is there anything left to be said on the topics arrayed above? Any large loopholes or gotchas? Risks or threats we haven't considered? >>> Maybe the increased/decreased exposure of ARIN to lawsuits? >>> >>> (I will admit to enjoying reading my own words. But as they are growing tiresome to me, they must be coma-inducing to you by now.) >>> >>> Of course I don't mean to cutoff any discussions about any topic, if you think there is more to add. >>> >>> Regards, >>> Mike >>> >>> >>> >>> >>> >>> >>> >>> ----- Original Message ----- From: "Tom Vest" >>> To: "Chris Engel" >>> Cc: "Mike Burns" ; >>> Sent: Friday, May 20, 2011 3:09 PM >>> Subject: Re: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate >>> >>> >>> >>> On May 20, 2011, at 1:24 PM, Chris Engel wrote: >>> >>>> Tom, >>>> >>>> Excising a particular section of this thread for the sake of brevity... >>>> >>>>> Fair enough, you prefer to argue logic rather than facts: >>>>> >>>>> Please provide a negative proof that "logic" could never lead any future >>>>> address user, potential address buyer, and/or potential address seller to >>>>> conclude that registration would not advance their own private interests. >>>>> >>>>> Please provide a negative proof that "logic" could never lead any future >>>>> address user, potential address buyer, and/or potential address seller to >>>>> embrace "sales-friendly registration" but simultaneously reject >>>>> "operationally relevant registration" (i.e., the kind that makes whois an >>>>> appropriate subject of interest for community deliberation). >>>>> >>>>> Please provide a negative proof that "logic" will BOTH always lead all future >>>>> address users, address buyers, and address sellers to self-maintain >>>>> "operationally relevant registration" for themselves in perpetuity, AND that >>>>> the attainment of that outcome by means of needs-free transfers could >>>>> never have any unintended consequences that might be as serious or more >>>>> serious than some marginal degradation of whois accuracy. >>>>> >>>> >>>> I don't think the above is a fair tactic for debate. You are asking Mike to prove a logical fallacy. Furthermore, when you start using words like "never" and "always" when discussing human behavior as benchmarks for judging the legitimacy of a system...your standards themselves appear absurd. If we applied the same standards for judging the appropriateness of a "needs" based policy, it would assuredly fail as well. Systems designed to regulate human behavior cannot achieve a uniformity of results approaching mathematical perfection, nor need they do so to be effective (IMO). >>>> >>>> If you want to argue that it's likely a substantial number of individuals would have logical reasons for not wanting to maintain accurate registration under the policy Mike proposes...that's (IMO) a reasonable standard to base an argument on. Not sure whether I would agree with that proposition or not...but the standard is reasonable. Asking Mike to provide a standard of proof that couldn't allow for even a single exception isn't (IMO). >>>> >>>> >>>> Christopher Engel >>>> (Representing only my own views) >>> >>> Hi Chris, >>> >>> Thanks for the reactions. Of course you are right on this count. My apologies to Mike for demanding what is, technically, logically impossible to deliver. >>> >>> My intent was not to be merely hyperbolic, but rather to *strongly* suggest that we all engage our imaginations fully when considering the range of strategic responses that might seem to be "rational" from the perspective of any clever entrepreneur who may or may not have any long-term interest in what happens to the Internet or to others who count the Internet for their livelihood or anything else, once s/he is done. Granted, this year we're all operating in an environment that has been significantly shaped by the unintended consequences of last year's strategic adjustments to the previous year's entrepreneurial cleverness, and so on... I mean, who could have anticipated that DWDM might trigger changes in SFP policies that helped to ignite our first crash, or that widespread diffusion of P2P might prompt another shift in commercial strategy that could in turn precipitate a run on the ASN16 reserves? >>> >>> Suffice it to say that there are always plenty of smart people out there working out every conceivable new angle that might be exposed by the next change in policy and/or technology and/or market structure -- and in general, at most times, we all benefit tremendously from that fact. But that only remains true as long we do not, through omission or commission, open up any loopholes that are big enough to allow to whole industry to fall through, into who-knows-what. These days it's not really possible to doubt that such things can and in fact do happen from time to time. >>> >>> I submit that the removal of "capability" testing would not only represent an irreversible change, but also has the potential to create a number of potentially fatal loopholes. And so in this particular case, I recommend that we proceed only if/after we can first achieve a very high level of confidence that no serious risks or threats are immediately created thereby. >>> >>> 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. >> > > > > -- > Jeffrey Lyon, Leadership Team > jeffrey.lyon at blacklotus.net | http://www.blacklotus.net > Black Lotus Communications - AS32421 > First and Leading in DDoS Protection Solutions From mysidia at gmail.com Mon May 23 01:51:10 2011 From: mysidia at gmail.com (Jimmy Hess) Date: Mon, 23 May 2011 00:51:10 -0500 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate In-Reply-To: References: <4DCFDB5C64DD4F738B65AB82D36B629D@mike> <15F92ECD-2BE5-48F2-B65A-9A9D39B98F54@delong.com> <0829B106605C4FE8B189DB2E56C69615@mike> <51506A06-D2EE-4A0D-B92B-781662094A1C@eyeconomics.com> <0CCB8AB89D144E89872AF0D635E95497@mike> <2691B7B9-1F3C-403C-B4E8-5B82BED0E191@eyeconomics.com> <454BB1826E7B4F2BB3A68BE1DD86A756@video> <909D6DD7-404F-4BB3-B330-78B755FAB6DA@eyeconomics.com> <156DA5A48E51490284BC21D982A8FDAB@mike> <2B4CEE14-49C8-429A-B087-8A2E097A35C5@eyeconomics.com> Message-ID: [snip] > [...] If ARIN revokes > the addresses from the speculators, the value they can get for them becomes If ARIN revokes resources from a pure speculator who has no need for IPs and is ignoring NRPM, the speculator incurs a loss that is limited to the cost of acquiring the revoked resources, and any anticipated proceeds of selling revoked resources. That's the point -- the threat of revokation has very few teeth, if the applicant does not actually need any IP resources. They really have nothing extra to lose, other than the item being speculated upon. This may be a very small loss, compared to the potential award, if the speculator believes IPv4 number resources will become valuable. An IPv4 address speculator might operate hundreds of organizations, each with their own "speculated" block. The speculator is likely to be able to avoid revokation long enough to either dispose of the resources through 8.3 transfer, OR by transferring the "IP address holding organizations" containing the various speculated upon blocks, to the resource recipients. If an end user or ISP who requires number resources for addressing their network has resources revoked, the loss is much larger. The possibility of 'speculation organizations', and using M and A transfers to dispose of speculated resources (where a speculator simply buys or sells _organizations_ to indirectly transfer IP resources) might be good argument (if speculation is to be discouraged) for requiring IP address resources involved in non-legacy merger/acquisition transfers to be efficiently utilized _both_ before and after the transfer, for the transfer to be allowed, or for it to be allowed for the organization to continue to utilize resources after being acquired. Yes... it should be considered whether it is likely / whether it will be likely for there to be sufficient encouragement for rogues to ignore ARIN policies, and even the law, to any significant extent, and/or if that type of speculation will have any adverse effect on the IPv4 community. Not that it should be _assumed_ there are masses of rogue speculators waiting as we speak for their opportunity to ignore agreements/the law/ARIN policies and start making false apps or doing secret transfers under the table, either. It's not even going to be too well known outside of the RIRs and technical community that IPv4 resources are running out; the very idea of more than one or two speculators /could/ be a fiction. -- -JH From jcurran at arin.net Mon May 23 14:18:29 2011 From: jcurran at arin.net (John Curran) Date: Mon, 23 May 2011 18:18:29 +0000 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate In-Reply-To: References: <4DCFDB5C64DD4F738B65AB82D36B629D@mike> <15F92ECD-2BE5-48F2-B65A-9A9D39B98F54@delong.com> <0829B106605C4FE8B189DB2E56C69615@mike> <51506A06-D2EE-4A0D-B92B-781662094A1C@eyeconomics.com> <0CCB8AB89D144E89872AF0D635E95497@mike> <2691B7B9-1F3C-403C-B4E8-5B82BED0E191@eyeconomics.com> <454BB1826E7B4F2BB3A68BE1DD86A756@video> <909D6DD7-404F-4BB3-B330-78B755FAB6DA@eyeconomics.com> <156DA5A48E51490284BC21D982A8FDAB@mike> <77310136-54C6-43F0-9923-E7810DD2736D@delong.com> <059E9D87D0D8420D8EAE18BF78F1FA88@video> <2802FCB9-1D0A-43AA-81BB-C3A93AAA7B45@delong.com> Message-ID: <5F1AB819-C436-42B8-9CE9-14CF74F5E385@arin.net> On May 21, 2011, at 10:01 AM, Mike Burns wrote: > > I am basing my interpretation of the law on the words of the head of ARIN Mike - In 2006, ARIN CEO's Ray Plzak said the following in his statement on the Kremen matter: 'Like other ?legacy? address holder?s issued resources before ARIN began, ARIN has never had an agreement with UUNET that would give it authority over those specific resources.' I am certain that Ray believed those words to be true and accurate at the time he stated them. I will point out that he was referring specifically to lack of an agreement with that particular legacy holder that would provide the ability to unilaterally implement the court's order, and also note that he goes on to state furthermore that sub-allocations had been made out of those blocks to other parties uncertain to ARIN. Based on his statements, you've determined that "ARIN head Plzak declared that ARIN does not control legacy addresses." That's your prerogative, but it looks to me to be a rather creative generalization of his points. Unlike Ray, I was at ARIN's inception. I am also the President and CEO of ARIN today, and I have stated for the record that ARIN does not control what IP addresses people choose to use in their routers, but we definitely and with full authority control the entries in the ARIN Whois DB and that those entries shall be maintained in accordance with law and the policies developed by the community. Feel free to keep this more current statement in mind when developing policies for this region as it will help reduce your confusion greatly. Thanks! /John John Curran President and CEO ARIN From mike at nationwideinc.com Mon May 23 15:09:06 2011 From: mike at nationwideinc.com (Mike Burns) Date: Mon, 23 May 2011 15:09:06 -0400 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate References: <4DCFDB5C64DD4F738B65AB82D36B629D@mike><15F92ECD-2BE5-48F2-B65A-9A9D39B98F5 4@delong.com><0829B106605C4FE8B189DB2E56C69615@mike><51506A06-D2EE-4A0D-B92B-781662094A1C@eyeconomics.com><0CCB8AB89D144E89872A F0D635E95497@mike><2691B7B9-1F3C-403C-B4E8-5B82BED0E191@eyeconomics.com><454BB1826E7B4F2BB3A68BE1DD86A756@video><909D6DD7-404F-4BB3-B330-78B755FAB6D A@eyeconomics.com><156DA5A48E51490284BC21D982A8FDAB@mike><77310136-54C6-43F0-9923-E7810DD2736D@delong.com><059E9D87D0D8420D8EAE 18BF78F1FA88@video><2802FCB9-1D0A-43AA-81BB-C3A93AAA7B45@delong.com> <5F1AB819-C436-42B8-9CE9-14CF74F5E385@arin.net> Message-ID: Hi John, >In 2006, ARIN CEO's Ray Plzak said the following in his statement on the >Kremen matter: 'Like other ?legacy? address holder?s issued resources before ARIN began, ARIN has never had an agreement with UUNET that would give it authority over those specific resources.' >I am certain that Ray believed those words to be true and accurate at the >time >he stated them. I will point out that he was referring specifically to >lack of an >agreement with that particular legacy holder No, John, he explicitly said "Like other legacy address holders". > that would provide the ability to >unilaterally implement the court's order, and also note that he goes on to >state >furthermore that sub-allocations had been made out of those blocks to other >parties uncertain to ARIN. Yes, ARIN was basically saying that a subset of addresses Kremen was claiming "ownership" of were legacy addresses. And in that context, ARIN was saying to the judge, "We have no authority over legacy addresses." >Based on his statements, you've determined that "ARIN head Plzak declared >that ARIN does not control legacy addresses." That's your prerogative, >but >it looks to me to be a rather creative generalization of his points. It looks to me like precisely what he was saying when you parse his statement to get rid of extraneous information: "ARIN has never had an agreement that would give it authority over legacy addresses." Do you quibble with my parsing? >Unlike Ray, I was at ARIN's inception. I am also the President and CEO of >ARIN >today, and I have stated for the record that ARIN does not control what IP >addresses >people choose to use in their routers, but we definitely and with full >authority control >the entries in the ARIN Whois DB and that those entries shall be maintained >in >accordance with law and the policies developed by the community. >Feel free to keep this more current statement in mind when developing >policies >for this region as it will help reduce your confusion greatly. >Thanks! >/John John, whenever confronted with this question, you resort to boilerplate language relating to control over Whois. Which is a red herring. So I will try to pin you down, to reduce everybody's confusion. If I was allocated legacy space and never signed an LRSA, would it be illegal for me to sell those addresses to Company A? If Company A tried to route those addresses, would that be illegal? Please answer without relating to Whois. I realize that Whois would not be updated to reflect the sale, that is the whole point of my proposal. I am not asking about "transfers", okay? I am asking about sales. I'm not asking whether you could allocate those addresses to somebody else and have Whois reflect the new allocation. I'm not asking whether a string of numbers has any value. I'm not claiming ARIN can tell anybody what numbers to configure into their routers. I'm not looking for a flip answer like "It would not be illegal for me to sell you the address 192.168.1.1, either." I'm asking if it is illegal to sell legacy addresses without notifying ARIN, as this goes directly to the rationale for my proposal. In the real world, if it is not illegal, and if it provides incentives to buyer and to seller, these tranactions WILL happen. And still in the real world, if the addresses continue to be usable after the sale, these sales WILL happen, and Whois accuracy will be lost. Regards, Mike From jcurran at arin.net Mon May 23 15:31:05 2011 From: jcurran at arin.net (John Curran) Date: Mon, 23 May 2011 19:31:05 +0000 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate In-Reply-To: References: <4DCFDB5C64DD4F738B65AB82D36B629D@mike><15F92ECD-2BE5-48F2-B65A-9A9D39B98F5 4@delong.com><0829B106605C4FE8B189DB2E56C69615@mike><51506A06-D2EE-4A0D-B92B-781662094A1C@eyeconomics.com><0CCB8AB89D144E89872A F0D635E95497@mike><2691B7B9-1F3C-403C-B4E8-5B82BED0E191@eyeconomics.com><454BB1826E7B4F2BB3A68BE1DD86A756@video><909D6DD7-404F-4BB3-B330-78B755FAB6D A@eyeconomics.com><156DA5A48E51490284BC21D982A8FDAB@mike><77310136-54C6-43F0-9923-E7810DD2736D@delong.com><059E9D87D0D8420D8EAE 18BF78F1FA88@video><2802FCB9-1D0A-43AA-81BB-C3A93AAA7B45@delong.com> <5F1AB819-C436-42B8-9CE9-14CF74F5E385@arin.net> Message-ID: <9D6E8A5B-A7B4-40BC-960E-7B40640B3F90@arin.net> On May 23, 2011, at 3:09 PM, Mike Burns wrote: > It looks to me like precisely what he was saying when you parse his statement to get rid of extraneous information: > > "ARIN has never had an agreement that would give it authority over legacy addresses." > > Do you quibble with my parsing? Indeed. To be accurate: In 2006, ARIN did not have an agreement with UUNET (or other legacy address holders) which would give it authority over their specific legacy addresses. > If I was allocated legacy space and never signed an LRSA, would it be illegal for me to sell those addresses to Company A? What *exactly* would you allegedly be selling to Company A? You have already indicated that it is not related to Whois, so do you believe it is related to Company A's ability to use those numbers in the Internet? > If Company A tried to route those addresses, would that be illegal? Not to the best of my knowledge (regardless of the status at ARIN and/or whatever Company A thinks they bought from you...) /John John Curran President and CEO ARIN From mike at nationwideinc.com Mon May 23 16:09:28 2011 From: mike at nationwideinc.com (Mike Burns) Date: Mon, 23 May 2011 16:09:28 -0400 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate References: <4DCFDB5C64DD4F738B65AB82D36B629D@mike><15F92ECD-2BE5-48F2-B65A-9A9D39B98F5 4@delong.com><0829B106605C4FE8B189DB2E56C69615@mike><51506A06-D2EE-4A0D-B92B-781662094A1C@eyeconomics.com><0CCB8AB89D144E89872A F0D635E95497@mike><2691B7B9-1F3C-403C-B4E8-5B82BED0E191@eyeconomics.com><454BB1826E7B4F2BB3A68BE1DD86A756@video><909D6DD7-404F-4BB3-B330-78B755FAB6D A@eyeconomics.com><156DA5A48E51490284BC21D982A8FDAB@mike><77310136-54C6-43F0-9923-E7810DD2736D@delong.com><059E9D87D0D8420D8EAE 18BF78F1FA88@video><2802FCB9-1D0A-43AA-81BB-C3A93AAA7B45@delong.com><5F1AB819-C436-42B8 -9CE9-14CF74F5E385@arin.net> <9D6E8A5B-A7B4-40BC-960E-7B40640B3F90@arin.net> Message-ID: <444EE1BDC07D4D9F895D0ACB6C7CDB02@mike> Hi John, > >> Do you quibble with my parsing? >Indeed. To be accurate: >In 2006, ARIN did not have an agreement with UUNET (or other legacy >address holders) which would give it authority over their specific >legacy addresses. OK, does ARIN have an agreement today (excepting LRSA signers) which would give it authority over legacy addresses? >> If I was allocated legacy space and never signed an LRSA, would it be >> illegal for me to sell those addresses to Company A? >What *exactly* would you allegedly be selling to Company A? You >have already indicated that it is not related to Whois, so do you >believe it is related to Company A's ability to use those numbers >in the Internet? Let's just say it's an asset sale, exactly like the one we have on public record in the MS/Nortel deal. And the listed assets showed the rights to control a specific netblock. Would that be a legal transaction? >> If Company A tried to route those addresses, would that be illegal? >Not to the best of my knowledge (regardless of the status at ARIN >and/or whatever Company A thinks they bought from you...) >/John My legal interpretation seems correct. All I have ever said is that ARIN has no authority over legacy address holders control rights and cannot stop a sale of legacy addresses from one party to another, legally. What ARIN can do is fail to update Whois, and maybe re-allocate them to somebody else and have Whois reflect the new allocant's information. You wrote, along with Ray Plzak and ARIN counsel Steve Ryan, in 2008: This paper demonstrates the heightened need for a consistent legal and public policy approach to critical management issues regarding "Internet number resources," which include Internet Protocol ("IP") addresses and Autonomous System numbers. I believe that if anything, the need for consistency is even more heightened now. There is a need for ARIN policy to be consistent with legal policy, in order to minimize legal conflict, and more importantly, to maintain Whois as an accurate and reliable registry of who controls what netblocks. Regards, Mike From owen at delong.com Mon May 23 16:31:52 2011 From: owen at delong.com (Owen DeLong) Date: Mon, 23 May 2011 15:31:52 -0500 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate In-Reply-To: References: <4DCFDB5C64DD4F738B65AB82D36B629D@mike> <15F92ECD-2BE5-48F2-B65A-9A9D39B98F5 4@delong.com> <0829B106605C4FE8B189DB2E56C69615@mike> <51506A06-D2EE-4A0D-B92B-781662094A1C@eyeconomics.com> <0CCB8AB89D144E89872A F0D635E95497@mike> <2691B7B9-1F3C-403C-B4E8-5B82BED0E191@eyeconomics.com> <454BB1826E7B4F2BB3A68BE1DD86A756@video> <909D6DD7-404F-4BB3-B330-78B755FAB6D A@eyeconomics.com> <156DA5A48E51490284BC21D982A8FDAB@mike> <77310136-54C6-43F0-9923-E7810DD2736D@delong.com> <059E9D87D0D8420D8EAE 18BF78F1FA88@video> <2802FCB9-1D0A-43AA-81BB-C3A93AAA7B45@delong.com> <5F1AB819-C436-42B8-9CE9-14CF74F5E385@arin.net> Message-ID: <434391EF-8E3A-4BE4-945B-96378F79ED5A@delong.com> Sent from my iPad On May 23, 2011, at 14:09, "Mike Burns" wrote: > Hi John, > >> In 2006, ARIN CEO's Ray Plzak said the following in his statement on the Kremen matter: > > 'Like other ?legacy? address holder?s issued resources before ARIN began, > ARIN has never had an agreement with UUNET that would give it authority > over those specific resources.' > >> I am certain that Ray believed those words to be true and accurate at the time >> he stated them. I will point out that he was referring specifically to lack of an >> agreement with that particular legacy holder > > No, John, he explicitly said "Like other legacy address holders". > Point being a lack of agreements with the legacy holders themselves, separate from agreements that do exist with IANA/ICANN, etc. > >> that would provide the ability to >> unilaterally implement the court's order, and also note that he goes on to state >> furthermore that sub-allocations had been made out of those blocks to other >> parties uncertain to ARIN. > > Yes, ARIN was basically saying that a subset of addresses Kremen was claiming "ownership" of were legacy addresses. > And in that context, ARIN was saying to the judge, "We have no authority over legacy addresses." > Most definitely NOT what ARIN was saying to the judge or what was reflected in the final rulings. > >> Based on his statements, you've determined that "ARIN head Plzak declared >> that ARIN does not control legacy addresses." That's your prerogative, but >> it looks to me to be a rather creative generalization of his points. > > It looks to me like precisely what he was saying when you parse his statement to get rid of extraneous information: > > "ARIN has never had an agreement that would give it authority over legacy addresses." > > Do you quibble with my parsing? I'll let John speak for himself as to whether or not he quibbles, but, I most certainly do. "ARIN has never had an agreement with particular legacy holders that give them clear authority over the conduct of the legacy holders with respect to the addresses." would probably be accurate. However, ARIN also has no agreement with particular legacy holders that would give those legacy holders authority over the content of the ARIN databases, either. In the interests of good stewardship and smooth reliable functioning of the internet, ARIN maintains services for legacy holders free of charge within the bounds of ARIN policy. Legacy holders that feel this gives them a blanket exemption from policy and/or the ability to force changes to the ARIN database(s) outside of policy are mistaken. The don't have any contract that would allow that. > >> Unlike Ray, I was at ARIN's inception. I am also the President and CEO of ARIN >> today, and I have stated for the record that ARIN does not control what IP addresses >> people choose to use in their routers, but we definitely and with full authority control >> the entries in the ARIN Whois DB and that those entries shall be maintained in >> accordance with law and the policies developed by the community. > >> Feel free to keep this more current statement in mind when developing policies >> for this region as it will help reduce your confusion greatly. > >> Thanks! >> /John > > John, whenever confronted with this question, you resort to boilerplate language relating to control over Whois. > Which is a red herring. So I will try to pin you down, to reduce everybody's confusion. > It really isn't. > If I was allocated legacy space and never signed an LRSA, would it be illegal for me to sell those addresses to Company A? > If Company A tried to route those addresses, would that be illegal? > As John has stated, ARIN is not a regulatory authority and does not control what people put into their routers. However, it would be against ARIN policy for company A to sell those addresses to you unless it was done in line with section 8 of the NRPM. Were ARIN to become aware of the unrecognized transfer, I believe their correct action would be (and John, please chime in here if you believe I have anything wrong about what would likely happen here): 1. Contact the original legacy holder and confirm that they are no longer using the resources and have transferred them to the current user. Comfirmed: Continue to step 2. Denied: Reclaim (if no longer in use) or maintain existing record and make sure original holder is aware of the problem with the hijacker. 2. Contact the current user and attempt to resolve the matter and complete the transfer under NRPM 8. User works with ARIN and complies: Continue to step 3. User refuses or doesn't qualify: Go to step 4. 3. Complete updating of whois/rDNS and move on. Exit process. 4. Attempt to work with user to come to agreement on the portion of resources that can be reclaimed and bring the other resources in line with policy and work out an RSA. User works with ARIN and complies: Go to step 3. User refuses: Reclaim all affected resources and return them to the free pool. > Please answer without relating to Whois. I realize that Whois would not be updated to reflect the sale, that is the whole point of my proposal. > I am not asking about "transfers", okay? I am asking about sales. ARIN has no involvement in sales of number resources or number resource registrations, whether or not the resulting transfer is recognized under NRPM 8, so, the question is malformed. ARIN's role is limited to recognizing the transfer of number resource registration as per NRPM 8 (or refusing to do so). Further, ARIN has a role where they should reclaim resources they become aware have been abandoned by the legitimate registrant unless ARIN can identify a valid successor in interest (NRPM 8.2) or a recipient that otherwise qualifies under the provisions of NRPM 8.3. > I'm not asking whether you could allocate those addresses to somebody else and have Whois reflect the new allocation. > I'm not asking whether a string of numbers has any value. > I'm not claiming ARIN can tell anybody what numbers to configure into their routers. > I'm not looking for a flip answer like "It would not be illegal for me to sell you the address 192.168.1.1, either." Whether or not you consider that flip, that is the real answer. > > I'm asking if it is illegal to sell legacy addresses without notifying ARIN, as this goes directly to the rationale for my proposal. It's not illegal to sell non-legacy addresses without notifying ARIN. The legacy or non-legacy or RFC-1918 or non-RFC-1918 status is irrelevant to the issue. OTOH, selling integers is sort of questionable and I doubt that anyone thinks they are actually purchasing the integers, but, rather at best the ability to register those integers for uniqueness in an internet registry or at worst, some form of right to use those integers on the internet. In the case of the former, selling them outside of policy is arguably fraud since the registry will not recognize such a right sold outside of policy. In the case of the latter, it might be considered fraud, since nobody really has the power to universally grant or revoke such a right, but, rather it is up to the individual operators of each router in the various networks that make up the internet to make that particular determination for themselves. > In the real world, if it is not illegal, and if it provides incentives to buyer and to seller, these tranactions WILL happen. Ah, but, doesn't that also depend on the disincentives that may or may not also be present? Would you not agree that selling numbers themselves (selling integers) is rather silly? How can one actually claim to own the number 5? What, exactly, would ownership of the number 5 (or the number 4.4.4.5 or any other number sequence) mean? I think the idea of number ownership is, at best, a legal fiction. Would you not agree that the best case you could possibly make for your proposal would be if there was the ability to sell some form of exclusive right to use the particular integers for addressing on the internet? However, for that to be what is sold, wouldn't the seller have to possess such a right to begin with? Who, exactly would have granted that right to them? How does that right extend to control over what other people do with their routers and by what authority? Isn't the right to use a set of addresses on any particular network subject to and by the permission of the owner of that individual network? Isn't the right to use a set of IPv4 addresses globally across the internet subject to and by permission of the owners of each and every individual network that makes up the internet? As such, wouldn't it be, in the real world, impossible to create, produce, possess, or maintain such a right absent a multilateral agreement signed by each and every network operator on the entire internet (or at least all of the ones with active ASNs present in the superset of all known BGP tables)? So, I think I have established that an exclusive right to use numbers is also a legal fiction, which leaves us only with the idea of the exclusive registration of a particular set of numbers within an internet registry. John has been using the "ARIN Whois Database" as shorthand, really, for the complete set of registration services provided by ARIN in uniquely registering the association of a particular unique set of number resources with a particular unique organization identified in the database. ARIN manages its database according to policies set by the community, as has been stated by John several times. It turns out that a lot of ISPs (those ones you'd have to build agreements with to create an exclusive right to use), happen to use the ARIN registration database as a source of authoritative information about legitimacy of coordinated use of number resources. > And still in the real world, if the addresses continue to be usable after the sale, these sales WILL happen, and Whois accuracy will be lost. > And here is the crux of the matter. Will the addresses continue to be usable? What would prevent ARIN from registering them to someone else after removing the records for the original holder who clearly abandoned them from the database per ARIN policy? What will ensure that ISPs remain willing to route those addresses to the purchaser outside of policy vs. the third party now registered in the RIR database? Do you not believe that this uncertainty would actually serve as a disincentive to these sales? Again, I think you need to make it clear what, exactly, you think is being sold in the real world in these instances of sales that you propose. Owen -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcurran at arin.net Mon May 23 16:49:14 2011 From: jcurran at arin.net (John Curran) Date: Mon, 23 May 2011 20:49:14 +0000 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate In-Reply-To: <444EE1BDC07D4D9F895D0ACB6C7CDB02@mike> References: <4DCFDB5C64DD4F738B65AB82D36B629D@mike> <"15F92ECD-2BE5-48F2-B65A-9A9D39B98F5 4"@delong.com> <0829B106605C4FE8B189DB2E56C69615@mike> <51506A06-D2EE-4A0D-B92B-781662094A1C@eyeconomics.com> <"0CCB8AB89D144E89872A F0D635E95497"@mike> <2691B7B9-1F3C-403C-B4E8-5B82BED0E191@eyeconomics.com> <454BB1826E7B4F2BB3A68BE1DD86A756@video> <"A79D04FB-C1DC- 4F74-BC3B-4552161CF401"@eyeconomics.com> <"909D6DD7-404F-4BB3-B330-78B755FAB6D A"@eyeconomics.com> <156DA5A48E51490284BC21D982A8FDAB@mike> <77310136-54C6-43F0-9923-E7810DD2736D@delong.com> <"059E9D87D0D8420D8EAE 18BF78F1FA88"@video> <2802FCB9-1D0A-43AA-81BB-C3A93AAA7B45@delong.com> <"5F1AB819-C436-42B8 -9CE9-14CF74F5E385"@arin.net> <9D6E8A5B-A7B4-40BC-960E-7B40640B3F90@arin.net> <444EE1BDC07D4D9F895D0ACB6C7CDB02@mike> Message-ID: <7ECDBCCC-A3AD-4359-9760-51B22343AF60@arin.net> On May 23, 2011, at 4:09 PM, Mike Burns wrote: > >> Indeed. To be accurate: > >> In 2006, ARIN did not have an agreement with UUNET (or other legacy >> address holders) which would give it authority over their specific >> legacy addresses. > > OK, does ARIN have an agreement today (excepting LRSA signers) which would give it authority over legacy addresses? In 2008, we rolled out the LRSA to help formalize relations between legacy address holders and ARIN. Maintenance of other legacy address entries is done pursuant to several documents including those from ARIN's formation and MOU's related to ICANN. I can see clearly how these make ARIN responsible for maintenance of these entries in the registry, but I do not know if they meet your particular criteria of "authority". >>> If I was allocated legacy space and never signed an LRSA, would it be illegal for me to sell those addresses to Company A? > >> What *exactly* would you allegedly be selling to Company A? You >> have already indicated that it is not related to Whois, so do you >> believe it is related to Company A's ability to use those numbers >> in the Internet? > > Let's just say it's an asset sale, exactly like the one we have on public record in the MS/Nortel deal. > And the listed assets showed the rights to control a specific netblock. Would that be a legal transaction? Ah, perhaps you mean "Seller's rights in the number resources", not actual integers? If indeed done on the same terms that the judge approved, including: "For the avoidance of doubt, this Order shall not affect the LRSA and the Purchaser?s rights in the Internet Numbers transferred pursuant to this Order shall be subject to the terms of the LRSA." then quite likely. Recognize also that many other parties potentially have overlapping rights on the your same number resources (although only he registrant has the exclusive rights of use in the registry and right of transfer). > My legal interpretation seems correct. All I have ever said is that ARIN has no authority over legacy address holders control rights and cannot stop a sale of legacy addresses from one party to another, legally. I would significantly disagree, but to be clear the matter remains TBD. Where we have intervened, we've had resolution in compliance with the community developed policies. > I believe that if anything, the need for consistency is even more heightened now. There is a need for ARIN policy to be consistent with legal policy, in order to minimize legal conflict, and more importantly, to maintain Whois as an accurate and reliable registry of who controls what netblocks. ARIN's policy is consistent with law. However, someone who knowingly entices another to trade in "magic numbers" with claims that they have no relation to the ARIN registry (despite being recorded therein) may be a different matter. Enjoy, /John John Curran President and CEO ARIN From scottleibrand at gmail.com Mon May 23 16:54:40 2011 From: scottleibrand at gmail.com (Scott Leibrand) Date: Mon, 23 May 2011 13:54:40 -0700 Subject: [arin-ppml] Integrating Draft Policy ARIN-2011-1 into NRPM 8.3 Message-ID: In light of the discomfort a number of community and AC members feel with the original 2011-1 text, I thought I'd make an attempt at integrating it into the framework of NRPM 8.3, to see if the result would be tighter and less ambiguous. Here's what I came up with: 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, in whole or in part, for transfer: - to a specified organizational recipient within the ARIN region, or - to another RIR, for transfer to a specified organizational recipient in that RIR's service region, if the two RIRs agree and maintain compatible, needs-based transfer policies. Such transferred number resources may only be received under RSA by organizations that can demonstrate the need for such resources, as a single aggregate, in the exact amount which they can justify under current ARIN policies. Thoughts? -Scott For reference, existing policy reads: 8.3. Transfers to Specified Recipients In addition to transfers under section 8.2, IPv4 number resources within the ARIN region may be released to ARIN by the authorized resource holder, in whole or in part, for transfer to another specified organizational recipient. Such transferred number resources may only be received under RSA by organizations that are within the ARIN region and can demonstrate the need for such resources, as a single aggregate, in the exact amount which they can justify under current ARIN policies. And original 2011-1 text reads: Any RIR's resource registrant may transfer IPv4 addresses to the resource registrant of another RIR as long as the two RIRs agree and maintain compatible, needs-based transfer policies that exercise Internet stewardship consistent with the values expressed in RFC2050. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike at nationwideinc.com Mon May 23 17:00:44 2011 From: mike at nationwideinc.com (Mike Burns) Date: Mon, 23 May 2011 17:00:44 -0400 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate References: <4DCFDB5C64DD4F738B65AB82D36B629D@mike> <15F92ECD-2BE5-48F2-B65A-9A9D39B98F5 4@delong.com> <0829B106605C4FE8B189DB2E56C69615@mike> <51506A06-D2EE-4A0D-B92B-781662094A1C@eyeconomics.com> <0CCB8AB89D144E89872A F0D635E95497@mike> <2691B7B9-1F3C-403C-B4E8-5B82BED0E191@eyeconomics.com> <454BB1826E7B4F2BB3A68BE1DD86A756@video> <909D6DD7-404F-4BB3-B330-78B755FAB6D A@eyeconomics.com> <156DA5A48E51490284BC21D982A8FDAB@mike> <77310136-54C6-43F0-9923-E7810DD2736D@delong.com> <059E9D87D0D8420D8EAE 18BF78F1FA88@video> <2802FCB9-1D0A-43AA-81BB-C3A93AAA7B45@delong.com> <5F1AB819-C436-42B8-9CE9-14CF74F5E385@arin.net> <434391EF-8E3A-4BE4-945B-96378F79ED5A@delong.com> Message-ID: <0A15C39DE25646E3BF45B695BC8727BF@mike> >>And still in the real world, if the addresses continue to be usable after >>the sale, these sales WILL happen, and Whois accuracy will be lost. Hi Owen, >And here is the crux of the matter. Will the addresses continue to be >usable? >What would prevent ARIN from registering them to someone else after >removing >the records for the original holder who clearly abandoned them from the >database >per ARIN policy? Nothing except a claim of tortious interference in a contract, I would guess. If you reread my last post, I clearly state that this is an option ARIN has, to reissue to another allocant and have Whois list the new allocant. ARIN controls Whois. >What will ensure that ISPs remain willing to route those addresses to the >purchaser >outside of policy vs. the third party now registered in the RIR database? You are correct, this is the crux of the matter. ARIN has no control over network operators, and who is to say what they will do? Will they band together and make pariahs out of anybody who routes in contravention to Whois data? Will they look to another routing authority, like another registry? Will they rely on their own review of chain-of-custody documents? Will they solicit a CYA document, route the addresses, and pocket the revenue from the connection? Maybe we need some more information on this. Do carrier ToS announcements state any requirement to match Whois? I can understand the reluctance people to speak on this issue, though. >Do you not believe that this uncertainty would actually serve as a >disincentive >to these sales? Again, I think you need to make it clear what, exactly, you >think >is being sold in the real world in these instances of sales that you >propose. >Owen Yes, the uncertainty will devalue the addresses and the normal incentive would be to have the addresses registered. But then again, if network operators continue to route addresses with Whois mismatches, then maybe those addresses become even more valuable, as it becomes clearer that those addresses are not subject to ARIN's dues, fees, and needs requirements. It comes down to what the network operators decide to do, and whether ARIN would have the confidence to reissue ip addresses known to have control conflicts to some hapless applicant. Regards, Mike From owen at delong.com Mon May 23 17:05:11 2011 From: owen at delong.com (Owen DeLong) Date: Mon, 23 May 2011 16:05:11 -0500 Subject: [arin-ppml] Integrating Draft Policy ARIN-2011-1 into NRPM 8.3 In-Reply-To: References: Message-ID: I could support this, but, I have a couple of lingering concerns. I think that the last sentence dictates too much in the case of a transfer to another region and should only apply to transfers within the ARIN region. I would like to see us relocate the single aggregate clause to make it binding on the actual community intent and if we're going to turn 2011-1 into a policy to modify 8.3 anyway, we should incorporate that change. Owen Sent from my iPad On May 23, 2011, at 15:54, Scott Leibrand wrote: > In light of the discomfort a number of community and AC members feel with the original 2011-1 text, I thought I'd make an attempt at integrating it into the framework of NRPM 8.3, to see if the result would be tighter and less ambiguous. Here's what I came up with: > > 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, in whole or in part, for transfer: > to a specified organizational recipient within the ARIN region, or > to another RIR, for transfer to a specified organizational recipient in that RIR's service region, if the two RIRs agree and maintain compatible, needs-based transfer policies. > Such transferred number resources may only be received under RSA by organizations that can demonstrate the need for such resources, as a single aggregate, in the exact amount which they can justify under current ARIN policies. > > Thoughts? > -Scott > > > For reference, existing policy reads: > 8.3. Transfers to Specified Recipients > > In addition to transfers under section 8.2, IPv4 number resources within the ARIN region may be released to ARIN by the authorized resource holder, in whole or in part, for transfer to another specified organizational recipient. Such transferred number resources may only be received under RSA by organizations that are within the ARIN region and can demonstrate the need for such resources, as a single aggregate, in the exact amount which they can justify under current ARIN policies. > > And original 2011-1 text reads: > Any RIR's resource registrant may transfer IPv4 addresses to the resource registrant of another RIR as long as the two RIRs agree and maintain compatible, needs-based transfer policies that exercise Internet stewardship consistent with the values expressed in RFC2050. > _______________________________________________ > 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 23 17:00:57 2011 From: owen at delong.com (Owen DeLong) Date: Mon, 23 May 2011 16:00:57 -0500 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate In-Reply-To: <444EE1BDC07D4D9F895D0ACB6C7CDB02@mike> References: <4DCFDB5C64DD4F738B65AB82D36B629D@mike> <15F92ECD-2BE5-48F2-B65A-9A9D39B98F5 4@delong.com> <0829B106605C4FE8B189DB2E56C69615@mike> <51506A06-D2EE-4A0D-B92B-781662094A1C@eyeconomics.com> <0CCB8AB89D144E89872A F0D635E95497@mike> <2691B7B9-1F3C-403C-B4E8-5B82BED0E191@eyeconomics.com> <454BB1826E7B4F2BB3A68BE1DD86A756@video> <909D6DD7-404F-4BB3-B330-78B755FAB6D A@eyeconomics.com> <156DA5A48E51490284BC21D982A8FDAB@mike> <77310136-54C6-43F0-9923-E7810DD2736D@delong.com> <059E9D87D0D8420D8EAE 18BF78F1FA88@video> <2802FCB9-1D0A-43AA-81BB-C3A93AAA7B45@delong.com> <5F1AB819-C436-42B8 -9CE9-14CF74F5E385@arin.net> <9D6E8A5B-A7B4-40BC-960E-7B40640B3F90@arin.net> <444EE1BDC07D4D9F895D0ACB6C7CDB02@mike> Message-ID: <5B319FD9-5EED-433F-8E50-681C1ABFC0AB@delong.com> Sent from my iPad On May 23, 2011, at 15:09, "Mike Burns" wrote: > Hi John, > >> >>> Do you quibble with my parsing? > >> Indeed. To be accurate: > >> In 2006, ARIN did not have an agreement with UUNET (or other legacy >> address holders) which would give it authority over their specific >> legacy addresses. > > OK, does ARIN have an agreement today (excepting LRSA signers) which would give it authority over legacy addresses? Certainly certain interpretations of the MoU between ICANN and the RIRs could be seen to at least give some authority in this regard. > >>> If I was allocated legacy space and never signed an LRSA, would it be illegal for me to sell those addresses to Company A? > >> What *exactly* would you allegedly be selling to Company A? You >> have already indicated that it is not related to Whois, so do you >> believe it is related to Company A's ability to use those numbers >> in the Internet? > > Let's just say it's an asset sale, exactly like the one we have on public record in the MS/Nortel deal. > And the listed assets showed the rights to control a specific netblock. Would that be a legal transaction? > Control it in what respects? What, exactly would the "rights to control a specific net block" mean in this context? What rights does Nortel/MS have to control what I put in my routers? What right do they have to control what any other ISP they aren't paying puts in their routers? Does their right to control what ISPs they are paying come from this right to control the net blocks, or, does it come from their other contract? >>> If Company A tried to route those addresses, would that be illegal? > >> Not to the best of my knowledge (regardless of the status at ARIN >> and/or whatever Company A thinks they bought from you...) > >> /John > > > My legal interpretation seems correct. All I have ever said is that ARIN has no authority over legacy address holders control rights and cannot stop a sale of legacy addresses from one party to another, legally. > Uh, sure, but, what exactly are those rights you speak of? As near as I can tell, other than the right to update whois and or the hope that some significant fraction of ISPs will accept the route, there's really no there there. > What ARIN can do is fail to update Whois, and maybe re-allocate them to somebody else and have Whois reflect the new allocant's information. > Exactly. > You wrote, along with Ray Plzak and ARIN counsel Steve Ryan, in 2008: > > This paper demonstrates the heightened need for a consistent > legal and public policy approach to critical management issues > > regarding "Internet number resources," which include Internet > > Protocol ("IP") addresses and Autonomous System numbers. > > I believe that if anything, the need for consistency is even more heightened now. There is a need for ARIN policy to be consistent with legal policy, in order to minimize legal conflict, and more importantly, to maintain Whois as an accurate and reliable registry of who controls what netblocks. > Again, this comes down to the question of what control of a net block means. If you believe it means the ability to control other's people's behaviors on their routers in regards to the net block, I think you are mistaken. If you believe it means the ability to update whois and/or maintain some hope that some fraction of ISPs will accept your ability to influence their behavior in their routers with regards to the net block in question, well, that's more feasible, but, I believe in that case, what ARIN recognizes will, in many ways, be more important than "legal policy" as I find it hard to imagine a judge ruling against a number of ISPs that are not even party to a case and forcing them to update their routers in a particular way. Owen From cengel at conxeo.com Mon May 23 17:15:19 2011 From: cengel at conxeo.com (Chris Engel) Date: Mon, 23 May 2011 17:15:19 -0400 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate In-Reply-To: <9D6E8A5B-A7B4-40BC-960E-7B40640B3F90@arin.net> References: <4DCFDB5C64DD4F738B65AB82D36B629D@mike><15F92ECD-2BE5-48F2-B65A-9A9D39B98F5 4@delong.com><0829B106605C4FE8B189DB2E56C69615@mike><51506A06-D2EE-4A0D-B92B-781662094A1C@eyeconomics.com><0CCB8AB89D144E89872A F0D635E95497@mike><2691B7B9-1F3C-403C-B4E8-5B82BED0E191@eyeconomics.com><454BB1826E7B4F2BB3A68BE1DD86A756@video><909D6DD7-404F-4BB3-B330-78B755FAB6D A@eyeconomics.com><156DA5A48E51490284BC21D982A8FDAB@mike><77310136-54C6-43F0-9923-E7810DD2736D@delong.com><059E9D87D0D8420D8EAE 18BF78F1FA88@video><2802FCB9-1D0A-43AA-81BB-C3A93AAA7B45@delong.com> <5F1AB819-C436-42B8-9CE9-14CF74F5E385@arin.net> <9D6E8A5B-A7B4-40BC-960E-7B40640B3F90@arin.net> Message-ID: > Subject: Re: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate > > On May 23, 2011, at 3:09 PM, Mike Burns wrote: > > > It looks to me like precisely what he was saying when you parse his > statement to get rid of extraneous information: > > > > "ARIN has never had an agreement that would give it authority over legacy > addresses." > > > > Do you quibble with my parsing? > > Indeed. To be accurate: > > In 2006, ARIN did not have an agreement with UUNET (or other legacy > address holders) which would give it authority over their specific > legacy addresses. > > > If I was allocated legacy space and never signed an LRSA, would it be illegal > for me to sell those addresses to Company A? > > What *exactly* would you allegedly be selling to Company A? You > have already indicated that it is not related to Whois, so do you > believe it is related to Company A's ability to use those numbers > in the Internet? > > > If Company A tried to route those addresses, would that be illegal? > > Not to the best of my knowledge (regardless of the status at ARIN > and/or whatever Company A thinks they bought from you...) > > /John > > John Curran > President and CEO > ARIN > > I'm not really sure whether ARIN would be in the position to determine the "legality" or "illegality" of any such transactions or the legitimacy of any particular claims of "ownership". Generally you need a Judicial, Legislative or at least Government Executive body to weigh in on those with any degree of authority...and since ARIN is none of those, I'm not sure it would be in a position to make such a determination. I think the most anyone could expect to ask of it (unless I misunderstand it's role) is who it considered the official registrant of a given address space was in it's database, and whether a particular action was in accordance with it's policies or not. Unless I'm mistaken, ARIN's policies don't carry with them any force of law....although individual contractual agreements ARIN has with specific entities might be enforceable (for those entities only) with the force of contract law. Also, given that we're dealing with numbers and not necessarly assets tied to any specific physical location, it's entirely possible that any number of jurisdictions might weigh in with different and conflicting rulings over who "owned" what and was allowed to do what with a given resource....and that ruling would probably only be enforceable as far as entities that operated within that jurisdiction or recognized that jurisdictions authority to rule. For example, the government of North Korea could rule that the entirety of the internet address space was "owned" by Daffy Duck (I hear they are quite fond of Daffy over there) and it could likely enforce that ruling as far as the portion of the internets physical topology located within the bounds of North Korea was concerned. However, that wouldn't necessarily mean squat to anyone in Topeka. Generally speaking, absent a law or judicial ruling entities are allowed to do whatever they want in recognizing the status of something according to their own records. I assume, aside from any contractual agreements it might have, ARIN could change it's policies to recognize Mickey Mouse as the official registrant of the entire IPv4 address block. It seems that the only thing that could prevent that is if a Court that had jurisdiction over a location where ARIN operated (the state it was incorporated in?) recognized "ownership" of an address block in contradiction of ARIN's records and ordered ARIN to change it's registration entries accordingly. Has such a ruling ever happened (and been allowed to stand)? Christopher Engel (representing only my own views) From owen at delong.com Mon May 23 17:19:31 2011 From: owen at delong.com (Owen DeLong) Date: Mon, 23 May 2011 16:19:31 -0500 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate In-Reply-To: <0A15C39DE25646E3BF45B695BC8727BF@mike> References: <4DCFDB5C64DD4F738B65AB82D36B629D@mike> <15F92ECD-2BE5-48F2-B65A-9A9D39B98F5 4@delong.com> <0829B106605C4FE8B189DB2E56C69615@mike> <51506A06-D2EE-4A0D-B92B-781662094A1C@eyeconomics.com> <0CCB8AB89D144E89872A F0D635E95497@mike> <2691B7B9-1F3C-403C-B4E8-5B82BED0E191@eyeconomics.com> <454BB1826E7B4F2BB3A68BE1DD86A756@video> <909D6DD7-404F-4BB3-B330-78B755FAB6D A@eyeconomics.com> <156DA5A48E51490284BC21D982A8FDAB@mike> <77310136-54C6-43F0-9923-E7810DD2736D@delong.com> <059E9D87D0D8420D8EAE 18BF78F1FA88@video> <2802FCB9-1D0A-43AA-81BB-C3A93AAA7B45@delong.com> <5F1AB819-C436-42B8-9CE9-14CF74F5E385@arin.net> <434391EF-8E3A-4BE4-945B-96378F79ED5A@delong.com> <0A15C39DE25646E3BF45B695BC8727BF@mike> Message-ID: <25803769-E674-47DC-9307-10A45578635D@delong.com> Sent from my iPad On May 23, 2011, at 16:00, "Mike Burns" wrote: > > >>> And still in the real world, if the addresses continue to be usable after the sale, these sales WILL happen, and Whois accuracy will be lost. > > > > Hi Owen, > >> And here is the crux of the matter. Will the addresses continue to be usable? > > >> What would prevent ARIN from registering them to someone else after removing >> the records for the original holder who clearly abandoned them from the database >> per ARIN policy? > > Nothing except a claim of tortious interference in a contract, I would guess. Ah, but, you can't have it both ways... Either registry in the ARIN database isn't relevant to the ability to route addresses (the addresses keep working) and there isn't interference, or, it is relevant (the addresses don't keep working) and the buyers will look askance at such deals. > If you reread my last post, I clearly state that this is an option ARIN has, to reissue to another allocant and have Whois list the new allocant. > ARIN controls Whois. > >> What will ensure that ISPs remain willing to route those addresses to the purchaser >> outside of policy vs. the third party now registered in the RIR database? > > You are correct, this is the crux of the matter. > ARIN has no control over network operators, and who is to say what they will do? So far, they pretty much have. > Will they band together and make pariahs out of anybody who routes in contravention to Whois data? I think this is an extreme. The other extreme is routing whatever on a free-for-all basis. Neither extreme is likely. However, I suspect that the most likely outcome is to continue as in the past until a conflict arises. At the point where a conflict arises, I believe that the RIR database(s) will be considered authoritative in virtually all likely circumstances. > Will they look to another routing authority, like another registry? I think this unlikely. > Will they rely on their own review of chain-of-custody documents? I think this is even more unlikely as such reviews are high overhead and would not scale beyond one or two levels of ASN indirection. > Will they solicit a CYA document, route the addresses, and pocket the revenue from the connection? That's certainly what happens today, at least until a conflict occurs. Now, the interesting part is that when conflicts have occurred, to the best of my knowledge, the RIR database has always emerged as the authoritative information that is believed and the other party loses. > Maybe we need some more information on this. Do carrier ToS announcements state any requirement to match Whois? Not that I am aware of, but, I'm not sure that matters. > I can understand the reluctance people to speak on this issue, though. > Ah, yeah... So can I. Especially people wanting to operate contrary to RIR policy. >> Do you not believe that this uncertainty would actually serve as a disincentive >> to these sales? Again, I think you need to make it clear what, exactly, you think >> is being sold in the real world in these instances of sales that you propose. > >> Owen > > Yes, the uncertainty will devalue the addresses and the normal incentive would be to have the addresses registered. Exactly. I believe this incentive is strong enough to resolve the problem to a sufficient extent without abandoning needs basis. > But then again, if network operators continue to route addresses with Whois mismatches, then maybe those addresses become even more valuable, as it becomes clearer that those addresses are not subject to ARIN's dues, fees, and needs requirements. Unlikely. I think that as conflicts increase, the probability of network operators continuing to route addresses with whois mismatches will continue to decrease. > It comes down to what the network operators decide to do, and whether ARIN would have the confidence to reissue ip addresses known to have control conflicts to some hapless applicant. > I think that eventually ARIN will have no choice but to do so. I also think that they will responsibly advise the applicant of the situation and give them the option of remaining on the waiting list hoping to obtain cleaner addresses through the transfer market or other uncontested reclamation/revocation/abandonment processes. However, I think that there will be some (large) applicants that will accept the space out of desperation and be able to convince network operators in general that the squatter needs to be evicted as it were. Owen From jcurran at arin.net Mon May 23 17:21:18 2011 From: jcurran at arin.net (John Curran) Date: Mon, 23 May 2011 21:21:18 +0000 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate In-Reply-To: References: <4DCFDB5C64DD4F738B65AB82D36B629D@mike> <"15F92ECD-2BE5-48F2-B65A-9A9D39B98F5 4"@delong.com> <0829B106605C4FE8B189DB2E56C69615@mike> <51506A06-D2EE-4A0D-B92B-781662094A1C@eyeconomics.com> <"0CCB8AB89D144E89872A F0D635E95497"@mike> <2691B7B9-1F3C-403C-B4E8-5B82BED0E191@eyeconomics.com> <454BB1826E7B4F2BB3A68BE1DD86A756@video> <"A79D04FB-C1DC- 4F74-BC3B-4552161CF401"@eyeconomics.com> <"909D6DD7-404F-4BB3-B330-78B755FAB6D A"@eyeconomics.com> <156DA5A48E51490284BC21D982A8FDAB@mike> <77310136-54C6-43F0-9923-E7810DD2736D@delong.com> <"059E9D87D0D8420D8EAE 18BF78F1FA88"@video> <2802FCB9-1D0A-43AA-81BB-C3A93AAA7B45@delong.com> <5F1AB819-C436-42B8-9CE9-14CF74F5E385@arin.net> <9D6E8A5B-A7B4-40BC-960E-7B40640B3F90@arin.net> Message-ID: <02C5AF0C-57A7-4E61-B19D-42F79925EC56@arin.net> On May 23, 2011, at 5:15 PM, Chris Engel wrote: > Has such a ruling ever happened (and been allowed to stand)? No (i.e. we have been successful in interventions to date) /John John Curran President and CEO ARIN From scottleibrand at gmail.com Mon May 23 17:21:45 2011 From: scottleibrand at gmail.com (Scott Leibrand) Date: Mon, 23 May 2011 14:21:45 -0700 Subject: [arin-ppml] Integrating Draft Policy ARIN-2011-1 into NRPM 8.3 In-Reply-To: References: Message-ID: On Mon, May 23, 2011 at 2:05 PM, Owen DeLong wrote: > I could support this, but, I have a couple of lingering concerns. > > I think that the last sentence dictates too much in the case of a transfer > to another region and should only apply to transfers within the ARIN region. > Yeah, I was wondering about that myself. Possible slight revision inline below... > I would like to see us relocate the > single aggregate clause to make it binding on the actual community intent > and if we're > going to turn 2011-1 into a policy to modify 8.3 anyway, we should > incorporate that > change. > I would like to see another proposal to do this (and to be discussed as a counterpoint to ARIN-prop-144 in Philadelphia). > On May 23, 2011, at 15:54, Scott Leibrand wrote: > > In light of the discomfort a number of community and AC members feel with > the original 2011-1 text, I thought I'd make an attempt at integrating it > into the framework of NRPM 8.3, to see if the result would be tighter and > less ambiguous. Here's what I came up with: > > 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, in whole or in part, for > transfer: > > - to a specified organizational recipient within the ARIN region, or > - to another RIR, for transfer to a specified organizational recipient > in that RIR's service region, if the two RIRs agree and maintain compatible, > needs-based transfer policies. > > Such transferred number resources may only be received under RSA by > organizations that can demonstrate the need for such resources, as a single > aggregate, in the exact amount which they can justify under current ARIN > policies. > > How about "Such number resources may only be received under RSA by organizations that can demonstrate the need for such resources, as a single aggregate, in the exact amount which they can justify under current ARIN, or recipient RIR, policies." ? Or, feel free to suggest text... -Scott > > For reference, existing policy reads: > 8.3. Transfers to Specified Recipients > > In addition to transfers under section 8.2, IPv4 number resources within > the ARIN region may be released to ARIN by the authorized resource holder, > in whole or in part, for transfer to another specified organizational > recipient. Such transferred number resources may only be received under RSA > by organizations that are within the ARIN region and can demonstrate the > need for such resources, as a single aggregate, in the exact amount which > they can justify under current ARIN policies. > > And original 2011-1 text reads: > Any RIR's resource registrant may transfer IPv4 addresses to the resource > registrant of another RIR as long as the two RIRs agree and maintain > compatible, needs-based transfer policies that exercise Internet stewardship > consistent with the values expressed in RFC2050. > > _______________________________________________ > 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 mike at nationwideinc.com Mon May 23 17:36:02 2011 From: mike at nationwideinc.com (Mike Burns) Date: Mon, 23 May 2011 17:36:02 -0400 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate References: <4DCFDB5C64DD4F738B65AB82D36B629D@mike><15F92ECD-2BE5-48F2-B65A-9A9D39B98F54@delong.com><0829B106605C4FE8B189DB2E56C69615@mike><51506A06-D2EE-4A0D-B92B-781662094A1C@eyeconomics.com><0CCB8AB89D144E89872AF0D635E95497@mike><2691B7B9-1F3C-403C-B4E8-5B82BED0E191@eyeconomics.com><454BB1826E7B4F2BB3A68BE1DD86A756@video><909D6DD7-404F-4BB3-B330-78B755FAB6DA@eyeconomics.com><156DA5A48E51490284BC21D982A8FDAB@mike><77310136-54C6-43F0-9923-E7810DD2736D@delong.com><059E9D87D0D8420D8EAE18BF78F1FA88@video><2802FCB9-1D0A-43AA-81BB-C3A93AAA7B45@delong.com><5F1AB819-C436-42B8-9CE9-14CF74F5E385@arin.net> <9D6E8A5B-A7B4-40BC-960E-7B40640B3F90@arin.net> Message-ID: <4AD7C11ED3C74C2BAE247B9470662094@mike> > I'm not really sure whether ARIN would be in the position to determine the "legality" or "illegality" of any such transactions or the legitimacy of any particular claims of "ownership". Generally you need a Judicial, Legislative or at least Government Executive body to weigh in on those with any degree of authority...and since ARIN is none of those, I'm not sure it would be in a position to make such a determination. I think the most anyone could expect to ask of it (unless I misunderstand it's role) is who it considered the official registrant of a given address space was in it's database, and whether a particular action was in accordance with it's policies or not. Unless I'm mistaken, ARIN's policies don't carry with them any force of law....although individual contractual agreements ARIN has with specific entities might be enforceable (for those entities only) with the force of contract law. Also, given that we're dealing with numbers and not necessarly assets tied to any specific physical location, it's entirely possible that any number of jurisdictions might weigh in with different and conflicting rulings over who "owned" what and was allowed to do what with a given resource....and that ruling would probably only be enforceable as far as entities that operated within that jurisdiction or recognized that jurisdictions authority to rule. For example, the government of North Korea could rule that the entirety of the internet address space was "owned" by Daffy Duck (I hear they are quite fond of Daffy over there) and it could likely enforce that ruling as far as the portion of the internets physical topology located within the bounds of North Korea was concerned. However, that wouldn't necessarily mean squat to anyone in Topeka. Generally speaking, absent a law or judicial ruling entities are allowed to do whatever they want in recognizing the status of something according to their own records. I assume, aside from any contractual agreements it might have, ARIN could change it's policies to recognize Mickey Mouse as the official registrant of the entire IPv4 address block. It seems that the only thing that could prevent that is if a Court that had jurisdiction over a location where ARIN operated (the state it was incorporated in?) recognized "ownership" of an address block in contradiction of ARIN's records and ordered ARIN to change it's registration entries accordingly. Has such a ruling ever happened (and been allowed to stand)? Christopher Engel (representing only my own views) Hi Chris, It's important to understand that ARIN *does* have legal contractual rights with all address holders under RSA. The RSA is the contract which gives ARIN those legal rights. But the legacy holders don't have any agreement, and so ARIN does not have any contractual rights over legacy space, as they do over RSA space. This is the clear implication of Ray Plzak's words in his declaration. Trying to bind legacy holders to ARIN policy is a difficult legal row to hoe, absent these agreements. But ARIN doesn't need any agreement with legacy holders to control Whois. I believe ARIN could legally reissue *all* legacy addresses to new allocants and update Whois. ARIN has exclusive rights to control Whois in accordance with community policy. But your points about multiple jurisdictions is important, and goes to my argument that ARIN should recognize the most liberal address holder rights as possible to go furthest in preventing potential conflict between ARIN and address holder, or ARIN and some local government. When you tighten up restrictions and begin the process Owen is talking about, the revokation and reissuance of space, the potential for conflict is ripe. Regards, Mike From mike at nationwideinc.com Mon May 23 18:00:32 2011 From: mike at nationwideinc.com (Mike Burns) Date: Mon, 23 May 2011 18:00:32 -0400 Subject: [arin-ppml] Integrating Draft Policy ARIN-2011-1 into NRPM 8.3 References: Message-ID: <07DCA09506E941C3AEE0B6562DF8DB4E@mike> Hi Scott, In the context of this proposal, may I ask what would happen if APNIC accepted a transfer of ARIN legacy addresses and updated their Whois, even if ARIN refused the transfer? (Because the language of the proposal pointedly excludes APNIC, if their current policy remains in place.) I know that ARIN could revoke and reissue. How is inter-RIR conflict resolved, is there a process in place for conflict resolution? Do the RIRs generally have compatible needs-based transfer policies, I mean I know APNIC doesn't, but do the other RIRs have the same 3-month window, for example? Is a difference in the needs window enough to prevent a transfer? If so, do we need to consider other RIRs and the impact on inter-RIR transfers when we consider proposals to change the needs window? What if RIPE joins APNIC with a requirement like a /24 maximum, is that something that makes the needs requirements incompatible? I guess I am asking for a more detailed definition of the word "compatible" in your proposed language. Maybe that language is extraneous, as you are already requiring both RIRs to agree? Regards, Mike ----- Original Message ----- From: Scott Leibrand To: Owen DeLong Cc: ARIN-PPML List Sent: Monday, May 23, 2011 5:21 PM Subject: Re: [arin-ppml] Integrating Draft Policy ARIN-2011-1 into NRPM 8.3 On Mon, May 23, 2011 at 2:05 PM, Owen DeLong wrote: I could support this, but, I have a couple of lingering concerns. I think that the last sentence dictates too much in the case of a transfer to another region and should only apply to transfers within the ARIN region. Yeah, I was wondering about that myself. Possible slight revision inline below... I would like to see us relocate the single aggregate clause to make it binding on the actual community intent and if we're going to turn 2011-1 into a policy to modify 8.3 anyway, we should incorporate that change. I would like to see another proposal to do this (and to be discussed as a counterpoint to ARIN-prop-144 in Philadelphia). On May 23, 2011, at 15:54, Scott Leibrand wrote: In light of the discomfort a number of community and AC members feel with the original 2011-1 text, I thought I'd make an attempt at integrating it into the framework of NRPM 8.3, to see if the result would be tighter and less ambiguous. Here's what I came up with: 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, in whole or in part, for transfer: a.. to a specified organizational recipient within the ARIN region, or b.. to another RIR, for transfer to a specified organizational recipient in that RIR's service region, if the two RIRs agree and maintain compatible, needs-based transfer policies. Such transferred number resources may only be received under RSA by organizations that can demonstrate the need for such resources, as a single aggregate, in the exact amount which they can justify under current ARIN policies. How about "Such number resources may only be received under RSA by organizations that can demonstrate the need for such resources, as a single aggregate, in the exact amount which they can justify under current ARIN, or recipient RIR, policies." ? Or, feel free to suggest text... -Scott For reference, existing policy reads: 8.3. Transfers to Specified Recipients In addition to transfers under section 8.2, IPv4 number resources within the ARIN region may be released to ARIN by the authorized resource holder, in whole or in part, for transfer to another specified organizational recipient. Such transferred number resources may only be received under RSA by organizations that are within the ARIN region and can demonstrate the need for such resources, as a single aggregate, in the exact amount which they can justify under current ARIN policies. And original 2011-1 text reads: Any RIR's resource registrant may transfer IPv4 addresses to the resource registrant of another RIR as long as the two RIRs agree and maintain compatible, needs-based transfer policies that exercise Internet stewardship consistent with the values expressed in RFC2050. _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. ------------------------------------------------------------------------------ _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcurran at arin.net Mon May 23 18:11:11 2011 From: jcurran at arin.net (John Curran) Date: Mon, 23 May 2011 22:11:11 +0000 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate In-Reply-To: <4AD7C11ED3C74C2BAE247B9470662094@mike> References: <4DCFDB5C64DD4F738B65AB82D36B629D@mike> <15F92ECD-2BE5-48F2-B65A-9A9D39B98F54@delong.com> <0829B106605C4FE8B189DB2E56C69615@mike> <51506A06-D2EE-4A0D-B92B-781662094A1C@eyeconomics.com> <0CCB8AB89D144E89872AF0D635E95497@mike> <2691B7B9-1F3C-403C-B4E8-5B82BED0E191@eyeconomics.com> <454BB1826E7B4F2BB3A68BE1DD86A756@video> <909D6DD7-404F-4BB3-B330-78B755FAB6DA@eyeconomics.com> <156DA5A48E51490284BC21D982A8FDAB@mike> <77310136-54C6-43F0-9923-E7810DD2736D@delong.com> <059E9D87D0D8420D8EAE18BF78F1FA88@video> <2802FCB9-1D0A-43AA-81BB-C3A93AAA7B45@delong.com> <5F1AB819-C436-42B8-9CE9-14CF74F5E385@arin.net> <9D6E8A5B-A7B4-40BC-960E-7B40640B3F90@arin.net> <4AD7C11ED3C74C2BAE247B9470662094@mike> Message-ID: <4D0748DB-63C7-4F61-AE41-E4A7467459B4@arin.net> On May 23, 2011, at 5:36 PM, Mike Burns wrote: > It's important to understand that ARIN *does* have legal contractual rights with all address holders under RSA. The RSA is the contract which gives ARIN those legal rights. But the legacy holders don't have any agreement, and so ARIN does not have any contractual rights over legacy space, as they do over RSA space. I'm actually not certain I agree with the last part of that statement as written, but that is a legal matter best left for judges at another time. (As a thought exercise, one has to first decide whether ICANN has contractual rights over the entire IP address space by means of the NTIA IANA functions contract, and then follow the various agreements from there.) A related point worth noting regarding applicability of the RSA is that if a legacy holder is dealing with a recipient that has an RSA with ARIN (i.e. the vast majority of ISPs in the region), then some aspects of that RSA will apply to any number resource transfers to that recipient in any case. > This is the clear implication of Ray Plzak's words in his declaration. Trying to bind legacy holders to ARIN policy is a difficult legal row to hoe, absent these agreements. But ARIN doesn't need any agreement with legacy holders to control Whois. I believe ARIN could legally reissue *all* legacy addresses to new allocants and update Whois. ARIN has exclusive rights to control Whois in accordance with community policy. > > But your points about multiple jurisdictions is important, and goes to my argument that ARIN should recognize the most liberal address holder rights as possible to go furthest in preventing potential conflict between ARIN and address holder, or ARIN and some local government. When you tighten up restrictions and begin the process Owen is talking about, the revokation and reissuance of space, the potential for conflict is ripe. Agreed - ARIN's policies should only constrain resources to the extent necessary for "good stewardship of Internet number resources by ensuring fair distribution of resources and facilitating the operation of the Internet by those who use them." The ARIN Advisory Council is tasked with getting this done based on the input from the community, and it takes a serious level of effort which not only includes keeping up with the PPML mailing list but also shaping the evolution of the policy proposals based on the input expressed here. FYI, /John John Curran President and CEO ARIN From scottleibrand at gmail.com Mon May 23 18:17:02 2011 From: scottleibrand at gmail.com (Scott Leibrand) Date: Mon, 23 May 2011 15:17:02 -0700 Subject: [arin-ppml] Integrating Draft Policy ARIN-2011-1 into NRPM 8.3 In-Reply-To: <07DCA09506E941C3AEE0B6562DF8DB4E@mike> References: <07DCA09506E941C3AEE0B6562DF8DB4E@mike> Message-ID: On Mon, May 23, 2011 at 3:00 PM, Mike Burns wrote: > Hi Scott, > > In the context of this proposal, may I ask what would happen if APNIC > accepted a transfer of ARIN legacy addresses and updated their Whois, even > if ARIN refused the transfer? > I suppose what would matter in that case is who IANA pointed to. To date, we haven't seen cases where two different RIRs were both claiming authority for the same address block, and I don't expect to see that, as all of the RIRs are committed to operating within the "RIR system". > (Because the language of the proposal pointedly excludes APNIC, if their > current policy remains in place.) > I know that ARIN could revoke and reissue. > How is inter-RIR conflict resolved, is there a process in place for > conflict resolution? > Yes, I believe there is, but I don't know the details. I presume it would be a largely consensual process within the ASO/NRO/IANA framework (perhaps within the NRO EC?). > Do the RIRs generally have compatible needs-based transfer policies, I mean > I know APNIC doesn't, but do the other RIRs have the same 3-month window, > for example? > Is a difference in the needs window enough to prevent a transfer? > If so, do we need to consider other RIRs and the impact on inter-RIR > transfers when we consider proposals to change the needs window? > What if RIPE joins APNIC with a requirement like a /24 maximum, is that > something that makes the needs requirements incompatible? > I don't consider any such differences in timeframes, size minimums/maximums, etc. to be incompatibilities in the context of 2011-1. But ARIN has said that, as things stand today, the lack of explicit needs basis in APNIC's transfer policy would make it incompatible with 2011-1's requirement for "compatible, needs-based transfer policies". I hope we can come to an agreement with the APNIC community on language or interpretation that would be compatible with both regions' needs and preferences, but 2011-1 as I see it is just the first step in that direction: setting up a framework that would allow inter-RIR transfers once such incompatibilities are resolved somehow (or with other RIRs where such incompatibilities may not exist). > I guess I am asking for a more detailed definition of the word "compatible" > in your proposed language. > Maybe that language is extraneous, as you are already requiring both RIRs > to agree? > Operationally, the two are quite related, in that ARIN will not agree unless they assess the other RIR's transfer policy to be compatible. But the "RIRs agree" language is also there as a safety valve to explicitly allow an RIR to not agree to a transfer if it has reason to believe that the transfer would violate policy or law. -Scott (speaking only for myself, as usual) > > > > > > ----- Original Message ----- > *From:* Scott Leibrand > *To:* Owen DeLong > *Cc:* ARIN-PPML List > *Sent:* Monday, May 23, 2011 5:21 PM > *Subject:* Re: [arin-ppml] Integrating Draft Policy ARIN-2011-1 into NRPM > 8.3 > > On Mon, May 23, 2011 at 2:05 PM, Owen DeLong wrote: > >> I could support this, but, I have a couple of lingering concerns. >> >> I think that the last sentence dictates too much in the case of a transfer >> to another region and should only apply to transfers within the ARIN region. >> > > Yeah, I was wondering about that myself. Possible slight revision inline > below... > > >> I would like to see us relocate the >> single aggregate clause to make it binding on the actual community intent >> and if we're >> going to turn 2011-1 into a policy to modify 8.3 anyway, we should >> incorporate that >> change. >> > > I would like to see another proposal to do this (and to be discussed as a > counterpoint to ARIN-prop-144 in Philadelphia). > > >> On May 23, 2011, at 15:54, Scott Leibrand >> wrote: >> >> In light of the discomfort a number of community and AC members feel >> with the original 2011-1 text, I thought I'd make an attempt at integrating >> it into the framework of NRPM 8.3, to see if the result would be tighter and >> less ambiguous. Here's what I came up with: >> >> 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, in whole or in part, for >> transfer: >> >> - to a specified organizational recipient within the ARIN region, or >> - to another RIR, for transfer to a specified organizational recipient >> in that RIR's service region, if the two RIRs agree and maintain compatible, >> needs-based transfer policies. >> >> Such transferred number resources may only be received under RSA by >> organizations that can demonstrate the need for such resources, as a single >> aggregate, in the exact amount which they can justify under current ARIN >> policies. >> >> > How about "Such number resources may only be received under RSA by > organizations that can demonstrate the need for such resources, as a single > aggregate, in the exact amount which they can justify under current ARIN, or > recipient RIR, policies." ? > > Or, feel free to suggest text... > > -Scott > > >> >> For reference, existing policy reads: >> 8.3. Transfers to Specified Recipients >> >> In addition to transfers under section 8.2, IPv4 number resources within >> the ARIN region may be released to ARIN by the authorized resource holder, >> in whole or in part, for transfer to another specified organizational >> recipient. Such transferred number resources may only be received under RSA >> by organizations that are within the ARIN region and can demonstrate the >> need for such resources, as a single aggregate, in the exact amount which >> they can justify under current ARIN policies. >> >> And original 2011-1 text reads: >> Any RIR's resource registrant may transfer IPv4 addresses to the resource >> registrant of another RIR as long as the two RIRs agree and maintain >> compatible, needs-based transfer policies that exercise Internet stewardship >> consistent with the values expressed in RFC2050. >> >> _______________________________________________ >> 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 owen at delong.com Mon May 23 18:15:45 2011 From: owen at delong.com (Owen DeLong) Date: Mon, 23 May 2011 17:15:45 -0500 Subject: [arin-ppml] Integrating Draft Policy ARIN-2011-1 into NRPM 8.3 In-Reply-To: References: Message-ID: <753A8B71-9504-412B-AE81-BECC781F9FA4@delong.com> How about this, instead... 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, in whole or in part, for transfer: + to specified organizational recipient(s) within the ARIN region that will receive such resources as a single aggregate, in the exact amount which they can justify under current ARIN policies + to another RIR, for transfer to a specified recipient in that RIR's service region, if the two RIRs agree and maintain compatible, needs-based transfer policies. In other words, let's bind the latter requirements only to the intra-regional transfers as I believe that they are out of scope for the burdens we should be allowed to place on inter-regional transfers on the part of the other RIR. > I would like to see us relocate the > single aggregate clause to make it binding on the actual community intent and if we're > going to turn 2011-1 into a policy to modify 8.3 anyway, we should incorporate that > change. > > I would like to see another proposal to do this (and to be discussed as a counterpoint to ARIN-prop-144 in Philadelphia). > Fair enough... Remember, you asked for it. ;-) Owen > On May 23, 2011, at 15:54, Scott Leibrand wrote: > >> In light of the discomfort a number of community and AC members feel with the original 2011-1 text, I thought I'd make an attempt at integrating it into the framework of NRPM 8.3, to see if the result would be tighter and less ambiguous. Here's what I came up with: >> >> 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, in whole or in part, for transfer: >> to a specified organizational recipient within the ARIN region, or >> to another RIR, for transfer to a specified organizational recipient in that RIR's service region, if the two RIRs agree and maintain compatible, needs-based transfer policies. >> Such transferred number resources may only be received under RSA by organizations that can demonstrate the need for such resources, as a single aggregate, in the exact amount which they can justify under current ARIN policies. > > > How about "Such number resources may only be received under RSA by organizations that can demonstrate the need for such resources, as a single aggregate, in the exact amount which they can justify under current ARIN, or recipient RIR, policies." ? > > Or, feel free to suggest text... > > -Scott > >> >> For reference, existing policy reads: >> 8.3. Transfers to Specified Recipients >> >> In addition to transfers under section 8.2, IPv4 number resources within the ARIN region may be released to ARIN by the authorized resource holder, in whole or in part, for transfer to another specified organizational recipient. Such transferred number resources may only be received under RSA by organizations that are within the ARIN region and can demonstrate the need for such resources, as a single aggregate, in the exact amount which they can justify under current ARIN policies. >> >> And original 2011-1 text reads: >> Any RIR's resource registrant may transfer IPv4 addresses to the resource registrant of another RIR as long as the two RIRs agree and maintain compatible, needs-based transfer policies that exercise Internet stewardship consistent with the values expressed in RFC2050. >> _______________________________________________ >> 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 mike at nationwideinc.com Mon May 23 18:24:49 2011 From: mike at nationwideinc.com (Mike Burns) Date: Mon, 23 May 2011 18:24:49 -0400 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate References: <4DCFDB5C64DD4F738B65AB82D36B629D@mike><15F92ECD-2BE5-48F2-B65A-9A9D39B98F5 F0D635E95497@mike><2691B7B9-1F3C-403C-B4E8-5B82BED0E191@eyeconomics.com><454BB1826E7B4F2BB3A68BE1DD86A756@video><909D6DD7-404F-4BB3-B330-78B755FAB6D A@eyeconomics.com><156DA5A48E51490284BC21D982A8FDAB@mike><77310136-54C6-43F0-9923-E7810DD2736D@delong.com><059E9D87D0D8420D8EAE 18BF78F1FA88@video><2802FCB9-1D0A-43AA-81BB-C3A93AAA7B45@delong.com><5F1AB819-C436-42B8 -9CE9-14CF74F5E385@arin.net><9D6E8A5B-A7B4-40BC-960E-7B40640B3F90@arin.net><4AD7C11ED3C74C2BAE247B9470662094@mike> <4D0748DB-63C7-4F61-AE41-E4A7467459B4@arin.net> Message-ID: <539E3CDED41F475F8D2049C4E088CB6B@mike> Agreed - ARIN's policies should only constrain resources to the extent necessary for "good stewardship of Internet number resources by ensuring fair distribution of resources and facilitating the operation of the Internet by those who use them." The ARIN Advisory Council is tasked with getting this done based on the input from the community, and it takes a serious level of effort which not only includes keeping up with the PPML mailing list but also shaping the evolution of the policy proposals based on the input expressed here. FYI, /John Hi John, I know that you keep up not just with the PPML mailing list, but with most of the articles on these issues that appear on the Internet. Plus you write articles and do interviews and manage an entire organization. Do you use google alerts to notify you when one of these articles comes out? If so, what do you think the best key words are? (One key word that I find actually locates most relevant articles (to me, anyway) is simply "IPv4". It locates almost all articles related to exhaust and ancillary issues.) I think you and the AC have some busy times ahead, I think you in particular have done a good job of staying on top of the list and providing valuable input. I hope we're paying you well! Regards, Mike From jcurran at arin.net Mon May 23 18:38:44 2011 From: jcurran at arin.net (John Curran) Date: Mon, 23 May 2011 22:38:44 +0000 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate In-Reply-To: <539E3CDED41F475F8D2049C4E088CB6B@mike> References: <4DCFDB5C64DD4F738B65AB82D36B629D@mike><15F92ECD-2BE5-48F2-B65A-9A9D39B98F5 F0D635E95497@mike><2691B7B9-1F3C-403C-B4E8-5B82BED0E191@eyeconomics.com><454BB1826E7B4F2BB3A68BE1DD86A756@video><909D6DD7-404F-4BB3-B330-78B755FAB6D A@eyeconomics.com><156DA5A48E51490284BC21D982A8FDAB@mike><77310136-54C6-43F0-9923-E7810DD2736D@delong.com><059E9D87D0D8420D8EAE 18BF78F1FA88@video><2802FCB9-1D0A-43AA-81BB-C3A93AAA7B45@delong.com><5F1AB819-C436-42B8 -9CE9-14CF74F5E385@arin.net><9D6E8A5B-A7B4-40BC-960E-7B40640B3F90@arin.net><4AD7C11ED3C74C2BAE247B9470662094@mike> <4D0748DB-63C7-4F61-AE41-E4A7467459B4@arin.net> <539E3CDED41F475F8D2049C4E088CB6B@mike> Message-ID: <01553EBC-54F3-46C1-B684-243028E57092@arin.net> On May 23, 2011, at 6:24 PM, Mike Burns wrote: > Do you use google alerts to notify you when one of these articles comes out? > If so, what do you think the best key words are? > (One key word that I find actually locates most relevant articles (to me, anyway) is simply "IPv4". It locates almost all articles related to exhaust and ancillary issues.) My secret is out! Yes, I receive notifications for "ARIN AND IPv4" as well as "ARIN AND IPv6" (note - there's also an entire communications team at ARIN which monitors various publications and mailing lists) > I think you and the AC have some busy times ahead, I think you in particular have done a good job of staying on top of the list and providing valuable input. As you noted, I'm paid for my efforts, but the ARIN Board and the ARIN Advisory Council actually carry quite a bit of work and are composed of volunteers... We have elections every year, and it is getting time to begin thinking about those who have both the time and commitment level necessary to serve on either of those teams. FYI, /John John Curran President and CEO ARIN From owen at delong.com Mon May 23 18:43:16 2011 From: owen at delong.com (Owen DeLong) Date: Mon, 23 May 2011 17:43:16 -0500 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate In-Reply-To: <4AD7C11ED3C74C2BAE247B9470662094@mike> References: <4DCFDB5C64DD4F738B65AB82D36B629D@mike> <15F92ECD-2BE5-48F2-B65A-9A9D39B98F54@delong.com> <0829B106605C4FE8B189DB2E56C69615@mike> <51506A06-D2EE-4A0D-B92B-781662094A1C@eyeconomics.com> <0CCB8AB89D144E89872AF0D635E95497@mike> <2691B7B9-1F3C-403C-B4E8-5B82BED0E191@eyeconomics.com> <454BB1826E7B4F2BB3A68BE1DD86A756@video> <909D6DD7-404F-4BB3-B330-78B755FAB6DA@eyeconomics.com> <156DA5A48E51490284BC21D982A8FDAB@mike> <77310136-54C6-43F0-9923-E7810DD2736D@delong.com> <059E9D87D0D8420D8EAE18BF78F1FA88@video> <2802FCB9-1D0A-43AA-81BB-C3A93AAA7B45@delong.com> <5F1AB819-C436-42B8-9CE9-14CF74F5E385@arin.net> <9D6E8A5B-A7B4-40BC-960E-7B40640B3F90@arin.net> <4AD7C11ED3C74C2BAE247B9470662094@mike> Message-ID: <36D226BD-E507-487B-9B69-A5315854023C@delong.com> > > Hi Chris, > > It's important to understand that ARIN *does* have legal contractual rights with all address holders under RSA. The RSA is the contract which gives ARIN those legal rights. But the legacy holders don't have any agreement, and so ARIN does not have any contractual rights over legacy space, as they do over RSA space. > Ah, but, this cuts both ways. Legacy holders don't have any agreement and so don't have any contractual rights, either, unless they're under LRSA or RSA with ARIN. > This is the clear implication of Ray Plzak's words in his declaration. Trying to bind legacy holders to ARIN policy is a difficult legal row to hoe, absent these agreements. But ARIN doesn't need any agreement with legacy holders to control Whois. I believe ARIN could legally reissue *all* legacy addresses to new allocants and update Whois. ARIN has exclusive rights to control Whois in accordance with community policy. With respect to registrations, all ARIN really does is control the various databases maintained by ARIN. All ARIN policy really governs is how ARIN manages those databases. They include Whois, ARIN's internal registration databases, the database from which ARIN generates it's in-addr.arpa and ip6.arpa zones, and certain other ancillary databases. Any other belief about exclusive rights to use, sell, buy, route, or otherwise use the number resources registered (or not registered) by ARIN is a somewhat separate matter. The internet works because ISPs choose to cooperate with the RIR system and make routing decisions based on what is in the ARIN and other RIR databases. There is nothing that prevents any ISP or group of ISPs from developing their own independent internet, registry structure, etc. and doing as they wish with it, including starting over with all numbers freshly unregistered an an entire 32-bit IPv4 greenfield address space. However, if they expect those registrations to be able to talk to the current IPv4 internet, well, there are some problems. However, in terms of ARIN policy, that governs how ARIN administers the registration database that ARIN maintains, regardless of whether the entries are legacy holders or not. Traditionally ARIN has bent over backwards to accommodate legacy holders to the greatest extent possible in favor of preserving a coherent community and a useful internet. I'm not advocating that we change this, but, I do _NOT_ want to expand the pool of resource holders accommodated in this manner and would rather seek ways in which we can reduce the size of that pool. Eventually, IPv6 will move the meaningful size of that pool to very nearly zero anyway. > > But your points about multiple jurisdictions is important, and goes to my argument that ARIN should recognize the most liberal address holder rights as possible to go furthest in preventing potential conflict between ARIN and address holder, or ARIN and some local government. Actually, it is not at all unlikely that many of the governments within the ARIN region would consider ARIN abandoning it's needs-basis stewardship of the addresses as an unauthorized abdication and conflict in the opposite direction. > When you tighten up restrictions and begin the process Owen is talking about, the revokation and reissuance of space, the potential for conflict is ripe. We aren't talking about tightening up restrictions. We're talking about not removing existing restrictions. The reclamation and reissuance that I have advocated is already there in current policy. You are the one proposing a change. I have been describing the current state of policy. Mischaracterizing my position as advocating for change (with the implication that you are advocating codifying existing practice) really doesn't reflect the reality of the situation. > Owen From scottleibrand at gmail.com Mon May 23 18:50:04 2011 From: scottleibrand at gmail.com (Scott Leibrand) Date: Mon, 23 May 2011 15:50:04 -0700 Subject: [arin-ppml] Integrating Draft Policy ARIN-2011-1 into NRPM 8.3 In-Reply-To: <753A8B71-9504-412B-AE81-BECC781F9FA4@delong.com> References: <753A8B71-9504-412B-AE81-BECC781F9FA4@delong.com> Message-ID: On Mon, May 23, 2011 at 3:15 PM, Owen DeLong wrote: > How about this, instead... > > 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, in whole or in part, for transfer: > > + to specified organizational recipient(s) within the ARIN region > that will receive such resources as a single aggregate, in the > exact amount which they can justify under current ARIN policies > > + to another RIR, for transfer to a specified recipient in that RIR's > service > region, if the two RIRs agree and maintain compatible, needs-based > transfer policies. > > In other words, let's bind the latter requirements only to the > intra-regional transfers > as I believe that they are out of scope for the burdens we should be > allowed to > place on inter-regional transfers on the part of the other RIR. > That might work. I notice that you changed the language you moved to the first bullet, though (dropping the RSA requirement, for example). Perhaps the following text would minimize the side effects (good and bad) of moving the text: In addition to transfers under section 8.2, IPv4 number resources may be released to ARIN by the authorized resource holder, in whole or in part, for transfer: + under RSA, to specified organizational recipient(s) within the ARIN region that can demonstrate the need for such resources, as a single aggregate, in the exact amount which they can justify under current ARIN policies. + to another RIR, for transfer to a specified recipient in that RIR's service region, if the two RIRs agree and maintain compatible, needs-based transfer policies. But I wonder if we're not losing some specificity by making that language apply only to in-region transfers... Thoughts? (Especially from anyone else who hasn't spoken up yet?) > I would like to see us relocate the >> single aggregate clause to make it binding on the actual community intent >> and if we're >> going to turn 2011-1 into a policy to modify 8.3 anyway, we should >> incorporate that >> change. >> > > I would like to see another proposal to do this (and to be discussed as a > counterpoint to ARIN-prop-144 in Philadelphia). > > > > Fair enough... Remember, you asked for it. ;-) > Heh. I didn't say I'd support it, but I think we should discuss it. -Scott On May 23, 2011, at 15:54, Scott Leibrand < scottleibrand at gmail.com> wrote: > >> In light of the discomfort a number of community and AC members feel with >> the original 2011-1 text, I thought I'd make an attempt at integrating it >> into the framework of NRPM 8.3, to see if the result would be tighter and >> less ambiguous. Here's what I came up with: >> >> 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, in whole or in part, for >> transfer: >> >> - to a specified organizational recipient within the ARIN region, or >> - to another RIR, for transfer to a specified organizational recipient >> in that RIR's service region, if the two RIRs agree and maintain compatible, >> needs-based transfer policies. >> >> Such transferred number resources may only be received under RSA by >> organizations that can demonstrate the need for such resources, as a single >> aggregate, in the exact amount which they can justify under current ARIN >> policies. >> >> > How about "Such number resources may only be received under RSA by > organizations that can demonstrate the need for such resources, as a single > aggregate, in the exact amount which they can justify under current ARIN, or > recipient RIR, policies." ? > > Or, feel free to suggest text... > > -Scott > > >> >> For reference, existing policy reads: >> 8.3. Transfers to Specified Recipients >> >> In addition to transfers under section 8.2, IPv4 number resources within >> the ARIN region may be released to ARIN by the authorized resource holder, >> in whole or in part, for transfer to another specified organizational >> recipient. Such transferred number resources may only be received under RSA >> by organizations that are within the ARIN region and can demonstrate the >> need for such resources, as a single aggregate, in the exact amount which >> they can justify under current ARIN policies. >> >> And original 2011-1 text reads: >> Any RIR's resource registrant may transfer IPv4 addresses to the resource >> registrant of another RIR as long as the two RIRs agree and maintain >> compatible, needs-based transfer policies that exercise Internet stewardship >> consistent with the values expressed in RFC2050. >> >> _______________________________________________ >> 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 23 18:55:16 2011 From: owen at delong.com (Owen DeLong) Date: Mon, 23 May 2011 17:55:16 -0500 Subject: [arin-ppml] Integrating Draft Policy ARIN-2011-1 into NRPM 8.3 In-Reply-To: <07DCA09506E941C3AEE0B6562DF8DB4E@mike> References: <07DCA09506E941C3AEE0B6562DF8DB4E@mike> Message-ID: <4C3A5149-3F3E-4566-8C0B-56E527649D80@delong.com> Sent from my iPad On May 23, 2011, at 17:00, "Mike Burns" wrote: > Hi Scott, > > In the context of this proposal, may I ask what would happen if APNIC accepted a transfer of ARIN legacy addresses and updated their Whois, even if ARIN refused the transfer? Uncertain at best... However, I'd be _VERY_ surprised if APNIC would do such a thing without consent from ARIN and even more surprised if they did not reverse it upon request from ARIN. I believe it would be a violation of the agreements in place among the NRO. > (Because the language of the proposal pointedly excludes APNIC, if their current policy remains in place.) > I know that ARIN could revoke and reissue. > How is inter-RIR conflict resolved, is there a process in place for conflict resolution? So far, it's resolved by discussion among the RIRs through the NRO and so far, that has been successful. > Do the RIRs generally have compatible needs-based transfer policies, I mean I know APNIC doesn't, but do the other RIRs have the same 3-month window, for example? The 3-month window wouldn't be a requirement for a "compatible" needs-basis. The other RIRs all have some form of needs basis so far. Only APNIC has abandoned needs-basis altogether. I believe that the other RIRs needs-basis policies would all be sufficient to meet the likely interpretation of "compatible needs-basis transfer policy" except for at least one RIR that has no transfer policy as yet. > Is a difference in the needs window enough to prevent a transfer? No, it would require the absence of a needs-basis altogether or some other radical difference in the meaning of "needs-basis" such as "Need can be satisfied by requiring an address for each goat on the given rancher's farm." > If so, do we need to consider other RIRs and the impact on inter-RIR transfers when we consider proposals to change the needs window? I doubt it. I expect such windows and similar issues to be considered localized phenomena and one of the reasons that we have RIRs instead of a single global IR. > What if RIPE joins APNIC with a requirement like a /24 maximum, is that something that makes the needs requirements incompatible? I wouldn't think so at least from ARIN's perspective, but, the point of the "as long as both RIRs agree and" part of the phrase is that it is up to the RIR staff to exercise discretion in interpreting to what extent variations in local policy can be accommodated and still considered compatible. > I guess I am asking for a more detailed definition of the word "compatible" in your proposed language. > Maybe that language is extraneous, as you are already requiring both RIRs to agree? I don't think it is extraneous as I believe it provides a level of guidance to staff. I believe that providing more specific guidance to staff in light of the amount of effort ongoing to change various policies around the world would be difficult and ill-advised. I believe that providing less guidance to staff would be too ambiguous and lead to unfortunate results. Even the current wording may have unfortunate results, but, I think it is better than the likely unfortunate results from current policy. Owen > -------------- next part -------------- An HTML attachment was scrubbed... URL: From owen at delong.com Mon May 23 18:57:34 2011 From: owen at delong.com (Owen DeLong) Date: Mon, 23 May 2011 17:57:34 -0500 Subject: [arin-ppml] Integrating Draft Policy ARIN-2011-1 into NRPM 8.3 In-Reply-To: References: <07DCA09506E941C3AEE0B6562DF8DB4E@mike> Message-ID: Sent from my iPad On May 23, 2011, at 17:17, Scott Leibrand wrote: > On Mon, May 23, 2011 at 3:00 PM, Mike Burns wrote: > Hi Scott, > > In the context of this proposal, may I ask what would happen if APNIC accepted a transfer of ARIN legacy addresses and updated their Whois, even if ARIN refused the transfer? > > I suppose what would matter in that case is who IANA pointed to. To date, we haven't seen cases where two different RIRs were both claiming authority for the same address block, and I don't expect to see that, as all of the RIRs are committed to operating within the "RIR system". > We did see it briefly with some ASNs and the two RIRs worked together to resolve the issue. It was the result of an allocation error somewhere, but, it was a duplicate registration issue. Owen -------------- next part -------------- An HTML attachment was scrubbed... URL: From owen at delong.com Mon May 23 19:01:31 2011 From: owen at delong.com (Owen DeLong) Date: Mon, 23 May 2011 18:01:31 -0500 Subject: [arin-ppml] Integrating Draft Policy ARIN-2011-1 into NRPM 8.3 In-Reply-To: References: <753A8B71-9504-412B-AE81-BECC781F9FA4@delong.com> Message-ID: Sent from my iPad On May 23, 2011, at 17:50, Scott Leibrand wrote: > On Mon, May 23, 2011 at 3:15 PM, Owen DeLong wrote: > How about this, instead... > > 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, in whole or in part, for transfer: > > + to specified organizational recipient(s) within the ARIN region > that will receive such resources under RSA as a single aggregate, in the > exact amount which they can justify under current ARIN policies > > + to another RIR, for transfer to a specified recipient in that RIR's service > region, if the two RIRs agree and maintain compatible, needs-based > transfer policies. > > In other words, let's bind the latter requirements only to the intra-regional transfers > as I believe that they are out of scope for the burdens we should be allowed to > place on inter-regional transfers on the part of the other RIR. > > That might work. I notice that you changed the language you moved to the first bullet, though (dropping the RSA requirement, for example). Perhaps the following text would minimize the side effects (good and bad) of moving the text: That was a mistake on my part... Resolved above. I intended only to make the edits necessary to accommodate syntax and grammar. > > In addition to transfers under section 8.2, IPv4 number resources may be released to ARIN > by the authorized resource holder, in whole or in part, for transfer: > > + under RSA, to specified organizational recipient(s) within the ARIN region that can demonstrate the need for such resources, as a single aggregate, in the exact amount which they can justify under current ARIN policies. > > + to another RIR, for transfer to a specified recipient in that RIR's service region, if the two RIRs agree and maintain compatible, needs-based transfer policies. > > But I wonder if we're not losing some specificity by making that language apply only to in-region transfers... > That could work too. We do lose some specificity, but, I believe that applying the specificity that we lose to another region is out of scope and beyond our reach or at least beyond that reach we should be attempting here. I really think we should make a genuine effort not to dictate policy to other regions beyond the bare minimum necessary to preserve needs-basis in light of that particular incompatibility. I don't think, for example, that a recipient in another region should have to sign an ARIN RSA or that it is up to us to require an RSA exist in other regions. > Thoughts? (Especially from anyone else who hasn't spoken up yet?) Thoughts, anyway. Owen > >> I would like to see us relocate the >> single aggregate clause to make it binding on the actual community intent and if we're >> going to turn 2011-1 into a policy to modify 8.3 anyway, we should incorporate that >> change. >> >> I would like to see another proposal to do this (and to be discussed as a counterpoint to ARIN-prop-144 in Philadelphia). >> > > Fair enough... Remember, you asked for it. ;-) > > Heh. I didn't say I'd support it, but I think we should discuss it. > > -Scott > > On May 23, 2011, at 15:54, Scott Leibrand wrote: >> >>> In light of the discomfort a number of community and AC members feel with the original 2011-1 text, I thought I'd make an attempt at integrating it into the framework of NRPM 8.3, to see if the result would be tighter and less ambiguous. Here's what I came up with: >>> >>> 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, in whole or in part, for transfer: >>> to a specified organizational recipient within the ARIN region, or >>> to another RIR, for transfer to a specified organizational recipient in that RIR's service region, if the two RIRs agree and maintain compatible, needs-based transfer policies. >>> Such transferred number resources may only be received under RSA by organizations that can demonstrate the need for such resources, as a single aggregate, in the exact amount which they can justify under current ARIN policies. >> >> >> How about "Such number resources may only be received under RSA by organizations that can demonstrate the need for such resources, as a single aggregate, in the exact amount which they can justify under current ARIN, or recipient RIR, policies." ? >> >> Or, feel free to suggest text... >> >> -Scott >> >>> >>> For reference, existing policy reads: >>> 8.3. Transfers to Specified Recipients >>> >>> In addition to transfers under section 8.2, IPv4 number resources within the ARIN region may be released to ARIN by the authorized resource holder, in whole or in part, for transfer to another specified organizational recipient. Such transferred number resources may only be received under RSA by organizations that are within the ARIN region and can demonstrate the need for such resources, as a single aggregate, in the exact amount which they can justify under current ARIN policies. >>> >>> And original 2011-1 text reads: >>> Any RIR's resource registrant may transfer IPv4 addresses to the resource registrant of another RIR as long as the two RIRs agree and maintain compatible, needs-based transfer policies that exercise Internet stewardship consistent with the values expressed in RFC2050. >>> _______________________________________________ >>> PPML >>> You are receiving this message because you are subscribed to >>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >>> Unsubscribe or manage your mailing list subscription at: >>> http://lists.arin.net/mailman/listinfo/arin-ppml >>> Please contact info at arin.net if you experience any issues. >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From scottleibrand at gmail.com Mon May 23 19:41:34 2011 From: scottleibrand at gmail.com (Scott Leibrand) Date: Mon, 23 May 2011 16:41:34 -0700 Subject: [arin-ppml] Integrating Draft Policy ARIN-2011-1 into NRPM 8.3 In-Reply-To: References: <753A8B71-9504-412B-AE81-BECC781F9FA4@delong.com> Message-ID: On Mon, May 23, 2011 at 4:01 PM, Owen DeLong wrote: > > On May 23, 2011, at 17:50, Scott Leibrand wrote: > > On Mon, May 23, 2011 at 3:15 PM, Owen DeLong < > owen at delong.com> wrote: > >> How about this, instead... >> >> 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, in whole or in part, for transfer: >> >> + to specified organizational recipient(s) within the ARIN region >> that will receive such resources under RSA as a single aggregate, in the >> exact amount which they can justify under current ARIN policies >> >> + to another RIR, for transfer to a specified recipient in that RIR's >> service >> region, if the two RIRs agree and maintain compatible, needs-based >> transfer policies. >> >> In other words, let's bind the latter requirements only to the >> intra-regional transfers >> as I believe that they are out of scope for the burdens we should be >> allowed to >> place on inter-regional transfers on the part of the other RIR. >> > > That might work. I notice that you changed the language you moved to the > first bullet, though (dropping the RSA requirement, for example). Perhaps > the following text would minimize the side effects (good and bad) of moving > the text: > > > That was a mistake on my part... Resolved above. I intended only to make > the edits > necessary to accommodate syntax and grammar. > No fair fixing the single aggregate thing while you're at it. ;-) > In addition to transfers under section 8.2, IPv4 number resources may be > released to ARIN > by the authorized resource holder, in whole or in part, for transfer: > > + under RSA, to specified organizational recipient(s) within the ARIN > region that can demonstrate the need for such resources, as a single > aggregate, in the exact amount which they can justify under current ARIN > policies. > > + to another RIR, for transfer to a specified recipient in that RIR's > service region, if the two RIRs agree and maintain compatible, > needs-based transfer policies. > > But I wonder if we're not losing some specificity by making that language > apply only to in-region transfers... > > That could work too. We do lose some specificity, but, I believe that > applying the specificity > that we lose to another region is out of scope and beyond our reach or at > least beyond > that reach we should be attempting here. > > I really think we should make a genuine effort not to dictate policy to > other regions beyond > the bare minimum necessary to preserve needs-basis in light of that > particular incompatibility. > Agreed. I suspect there is a way to preserve needs-basis on inter-RIR transfers even in light of the differences in ARIN and APNIC's transfer policies, but that is likely the topic for another thread... I don't think, for example, that a recipient in another region should have > to sign an ARIN RSA > or that it is up to us to require an RSA exist in other regions. > Well, I think all the other regions have an equivalent to the RSA, but agreed nonetheless. > Thoughts? (Especially from anyone else who hasn't spoken up yet?) > > > Thoughts, anyway. > I know I don't have to ask for yours. ;-) Thanks, Scott On May 23, 2011, at 15:54, Scott Leibrand < scottleibrand at gmail.com> wrote: > >> In light of the discomfort a number of community and AC members feel with >> the original 2011-1 text, I thought I'd make an attempt at integrating it >> into the framework of NRPM 8.3, to see if the result would be tighter and >> less ambiguous. Here's what I came up with: >> >> 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, in whole or in part, for >> transfer: >> >> - to a specified organizational recipient within the ARIN region, or >> - to another RIR, for transfer to a specified organizational recipient >> in that RIR's service region, if the two RIRs agree and maintain compatible, >> needs-based transfer policies. >> >> Such transferred number resources may only be received under RSA by >> organizations that can demonstrate the need for such resources, as a single >> aggregate, in the exact amount which they can justify under current ARIN >> policies. >> >> > How about "Such number resources may only be received under RSA by > organizations that can demonstrate the need for such resources, as a single > aggregate, in the exact amount which they can justify under current ARIN, or > recipient RIR, policies." ? > > Or, feel free to suggest text... > > -Scott > > >> >> For reference, existing policy reads: >> 8.3. Transfers to Specified Recipients >> >> In addition to transfers under section 8.2, IPv4 number resources within >> the ARIN region may be released to ARIN by the authorized resource holder, >> in whole or in part, for transfer to another specified organizational >> recipient. Such transferred number resources may only be received under RSA >> by organizations that are within the ARIN region and can demonstrate the >> need for such resources, as a single aggregate, in the exact amount which >> they can justify under current ARIN policies. >> >> And original 2011-1 text reads: >> Any RIR's resource registrant may transfer IPv4 addresses to the resource >> registrant of another RIR as long as the two RIRs agree and maintain >> compatible, needs-based transfer policies that exercise Internet stewardship >> consistent with the values expressed in RFC2050. >> >> _______________________________________________ >> 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 frnkblk at iname.com Mon May 23 23:53:42 2011 From: frnkblk at iname.com (Frank Bulk) Date: Mon, 23 May 2011 22:53:42 -0500 Subject: [arin-ppml] Integrating Draft Policy ARIN-2011-1 into NRPM 8.3 In-Reply-To: References: <07DCA09506E941C3AEE0B6562DF8DB4E@mike> Message-ID: <00ac01cc19c6$2c803340$858099c0$@iname.com> Why don't we change the second point to: + to another RIR, for transfer to a specified recipient in that RIR's service region, if the request meets both RIRS' transfer policies. Frank From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Scott Leibrand Sent: Monday, May 23, 2011 5:17 PM To: Mike Burns Cc: ARIN-PPML List Subject: Re: [arin-ppml] Integrating Draft Policy ARIN-2011-1 into NRPM 8.3 On Mon, May 23, 2011 at 3:00 PM, Mike Burns wrote: Hi Scott, In the context of this proposal, may I ask what would happen if APNIC accepted a transfer of ARIN legacy addresses and updated their Whois, even if ARIN refused the transfer? I suppose what would matter in that case is who IANA pointed to. To date, we haven't seen cases where two different RIRs were both claiming authority for the same address block, and I don't expect to see that, as all of the RIRs are committed to operating within the "RIR system". (Because the language of the proposal pointedly excludes APNIC, if their current policy remains in place.) I know that ARIN could revoke and reissue. How is inter-RIR conflict resolved, is there a process in place for conflict resolution? Yes, I believe there is, but I don't know the details. I presume it would be a largely consensual process within the ASO/NRO/IANA framework (perhaps within the NRO EC?). Do the RIRs generally have compatible needs-based transfer policies, I mean I know APNIC doesn't, but do the other RIRs have the same 3-month window, for example? Is a difference in the needs window enough to prevent a transfer? If so, do we need to consider other RIRs and the impact on inter-RIR transfers when we consider proposals to change the needs window? What if RIPE joins APNIC with a requirement like a /24 maximum, is that something that makes the needs requirements incompatible? I don't consider any such differences in timeframes, size minimums/maximums, etc. to be incompatibilities in the context of 2011-1. But ARIN has said that, as things stand today, the lack of explicit needs basis in APNIC's transfer policy would make it incompatible with 2011-1's requirement for "compatible, needs-based transfer policies". I hope we can come to an agreement with the APNIC community on language or interpretation that would be compatible with both regions' needs and preferences, but 2011-1 as I see it is just the first step in that direction: setting up a framework that would allow inter-RIR transfers once such incompatibilities are resolved somehow (or with other RIRs where such incompatibilities may not exist). I guess I am asking for a more detailed definition of the word "compatible" in your proposed language. Maybe that language is extraneous, as you are already requiring both RIRs to agree? Operationally, the two are quite related, in that ARIN will not agree unless they assess the other RIR's transfer policy to be compatible. But the "RIRs agree" language is also there as a safety valve to explicitly allow an RIR to not agree to a transfer if it has reason to believe that the transfer would violate policy or law. -Scott (speaking only for myself, as usual) ----- Original Message ----- From: Scott Leibrand To: Owen DeLong Cc: ARIN-PPML List Sent: Monday, May 23, 2011 5:21 PM Subject: Re: [arin-ppml] Integrating Draft Policy ARIN-2011-1 into NRPM 8.3 On Mon, May 23, 2011 at 2:05 PM, Owen DeLong wrote: I could support this, but, I have a couple of lingering concerns. I think that the last sentence dictates too much in the case of a transfer to another region and should only apply to transfers within the ARIN region. Yeah, I was wondering about that myself. Possible slight revision inline below... I would like to see us relocate the single aggregate clause to make it binding on the actual community intent and if we're going to turn 2011-1 into a policy to modify 8.3 anyway, we should incorporate that change. I would like to see another proposal to do this (and to be discussed as a counterpoint to ARIN-prop-144 in Philadelphia). On May 23, 2011, at 15:54, Scott Leibrand wrote: In light of the discomfort a number of community and AC members feel with the original 2011-1 text, I thought I'd make an attempt at integrating it into the framework of NRPM 8.3, to see if the result would be tighter and less ambiguous. Here's what I came up with: 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, in whole or in part, for transfer: * to a specified organizational recipient within the ARIN region, or * to another RIR, for transfer to a specified organizational recipient in that RIR's service region, if the two RIRs agree and maintain compatible, needs-based transfer policies. Such transferred number resources may only be received under RSA by organizations that can demonstrate the need for such resources, as a single aggregate, in the exact amount which they can justify under current ARIN policies. How about "Such number resources may only be received under RSA by organizations that can demonstrate the need for such resources, as a single aggregate, in the exact amount which they can justify under current ARIN, or recipient RIR, policies." ? Or, feel free to suggest text... -Scott For reference, existing policy reads: 8.3. Transfers to Specified Recipients In addition to transfers under section 8.2, IPv4 number resources within the ARIN region may be released to ARIN by the authorized resource holder, in whole or in part, for transfer to another specified organizational recipient. Such transferred number resources may only be received under RSA by organizations that are within the ARIN region and can demonstrate the need for such resources, as a single aggregate, in the exact amount which they can justify under current ARIN policies. And original 2011-1 text reads: Any RIR's resource registrant may transfer IPv4 addresses to the resource registrant of another RIR as long as the two RIRs agree and maintain compatible, needs-based transfer policies that exercise Internet stewardship consistent with the values expressed in RFC2050. _______________________________________________ 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 owen at delong.com Tue May 24 00:55:41 2011 From: owen at delong.com (Owen DeLong) Date: Mon, 23 May 2011 21:55:41 -0700 Subject: [arin-ppml] Integrating Draft Policy ARIN-2011-1 into NRPM 8.3 In-Reply-To: <00ac01cc19c6$2c803340$858099c0$@iname.com> References: <07DCA09506E941C3AEE0B6562DF8DB4E@mike> <00ac01cc19c6$2c803340$858099c0$@iname.com> Message-ID: <0114D408-5D5F-4EC3-A193-BE10687D7A8C@delong.com> I prefer to preserve the safety valve of requiring agreement from both RIRs. Owen On May 23, 2011, at 8:53 PM, Frank Bulk wrote: > Why don?t we change the second point to: > > + to another RIR, for transfer to a specified recipient in that RIR's service > region, if the request meets both RIRS? transfer policies. > > Frank > > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Scott Leibrand > Sent: Monday, May 23, 2011 5:17 PM > To: Mike Burns > Cc: ARIN-PPML List > Subject: Re: [arin-ppml] Integrating Draft Policy ARIN-2011-1 into NRPM 8.3 > > On Mon, May 23, 2011 at 3:00 PM, Mike Burns wrote: > Hi Scott, > > In the context of this proposal, may I ask what would happen if APNIC accepted a transfer of ARIN legacy addresses and updated their Whois, even if ARIN refused the transfer? > > I suppose what would matter in that case is who IANA pointed to. To date, we haven't seen cases where two different RIRs were both claiming authority for the same address block, and I don't expect to see that, as all of the RIRs are committed to operating within the "RIR system". > > (Because the language of the proposal pointedly excludes APNIC, if their current policy remains in place.) > I know that ARIN could revoke and reissue. > How is inter-RIR conflict resolved, is there a process in place for conflict resolution? > > Yes, I believe there is, but I don't know the details. I presume it would be a largely consensual process within the ASO/NRO/IANA framework (perhaps within the NRO EC?). > > Do the RIRs generally have compatible needs-based transfer policies, I mean I know APNIC doesn't, but do the other RIRs have the same 3-month window, for example? > Is a difference in the needs window enough to prevent a transfer? > If so, do we need to consider other RIRs and the impact on inter-RIR transfers when we consider proposals to change the needs window? > What if RIPE joins APNIC with a requirement like a /24 maximum, is that something that makes the needs requirements incompatible? > > I don't consider any such differences in timeframes, size minimums/maximums, etc. to be incompatibilities in the context of 2011-1. But ARIN has said that, as things stand today, the lack of explicit needs basis in APNIC's transfer policy would make it incompatible with 2011-1's requirement for "compatible, needs-based transfer policies". I hope we can come to an agreement with the APNIC community on language or interpretation that would be compatible with both regions' needs and preferences, but 2011-1 as I see it is just the first step in that direction: setting up a framework that would allow inter-RIR transfers once such incompatibilities are resolved somehow (or with other RIRs where such incompatibilities may not exist). > > I guess I am asking for a more detailed definition of the word "compatible" in your proposed language. > Maybe that language is extraneous, as you are already requiring both RIRs to agree? > > Operationally, the two are quite related, in that ARIN will not agree unless they assess the other RIR's transfer policy to be compatible. But the "RIRs agree" language is also there as a safety valve to explicitly allow an RIR to not agree to a transfer if it has reason to believe that the transfer would violate policy or law. > > -Scott (speaking only for myself, as usual) > > > > > > ----- Original Message ----- > From: Scott Leibrand > To: Owen DeLong > Cc: ARIN-PPML List > Sent: Monday, May 23, 2011 5:21 PM > Subject: Re: [arin-ppml] Integrating Draft Policy ARIN-2011-1 into NRPM 8.3 > > On Mon, May 23, 2011 at 2:05 PM, Owen DeLong wrote: > I could support this, but, I have a couple of lingering concerns. > > I think that the last sentence dictates too much in the case of a transfer to another region and should only apply to transfers within the ARIN region. > > Yeah, I was wondering about that myself. Possible slight revision inline below... > > I would like to see us relocate the > single aggregate clause to make it binding on the actual community intent and if we're > going to turn 2011-1 into a policy to modify 8.3 anyway, we should incorporate that > change. > > I would like to see another proposal to do this (and to be discussed as a counterpoint to ARIN-prop-144 in Philadelphia). > > On May 23, 2011, at 15:54, Scott Leibrand wrote: > > In light of the discomfort a number of community and AC members feel with the original 2011-1 text, I thought I'd make an attempt at integrating it into the framework of NRPM 8.3, to see if the result would be tighter and less ambiguous. Here's what I came up with: > > 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, in whole or in part, for transfer: > to a specified organizational recipient within the ARIN region, or > to another RIR, for transfer to a specified organizational recipient in that RIR's service region, if the two RIRs agree and maintain compatible, needs-based transfer policies. > Such transferred number resources may only be received under RSA by organizations that can demonstrate the need for such resources, as a single aggregate, in the exact amount which they can justify under current ARIN policies. > > How about "Such number resources may only be received under RSA by organizations that can demonstrate the need for such resources, as a single aggregate, in the exact amount which they can justify under current ARIN, or recipient RIR, policies." ? > > Or, feel free to suggest text... > > -Scott > > > For reference, existing policy reads: > 8.3. Transfers to Specified Recipients > > In addition to transfers under section 8.2, IPv4 number resources within the ARIN region may be released to ARIN by the authorized resource holder, in whole or in part, for transfer to another specified organizational recipient. Such transferred number resources may only be received under RSA by organizations that are within the ARIN region and can demonstrate the need for such resources, as a single aggregate, in the exact amount which they can justify under current ARIN policies. > > And original 2011-1 text reads: > Any RIR's resource registrant may transfer IPv4 addresses to the resource registrant of another RIR as long as the two RIRs agree and maintain compatible, needs-based transfer policies that exercise Internet stewardship consistent with the values expressed in RFC2050. > _______________________________________________ > 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 frnkblk at iname.com Tue May 24 01:00:09 2011 From: frnkblk at iname.com (Frank Bulk) Date: Tue, 24 May 2011 00:00:09 -0500 Subject: [arin-ppml] Integrating Draft Policy ARIN-2011-1 into NRPM 8.3 In-Reply-To: <0114D408-5D5F-4EC3-A193-BE10687D7A8C@delong.com> References: <07DCA09506E941C3AEE0B6562DF8DB4E@mike> <00ac01cc19c6$2c803340$858099c0$@iname.com> <0114D408-5D5F-4EC3-A193-BE10687D7A8C@delong.com> Message-ID: <00b101cc19cf$750f6690$5f2e33b0$@iname.com> Can you explain why? It's not that ARIN-2011-1 binds the non-ARIN RIR to receive the netblock. Frank From: Owen DeLong [mailto:owen at delong.com] Sent: Monday, May 23, 2011 11:56 PM To: frnkblk at iname.com Cc: ARIN-PPML List Subject: Re: [arin-ppml] Integrating Draft Policy ARIN-2011-1 into NRPM 8.3 I prefer to preserve the safety valve of requiring agreement from both RIRs. Owen On May 23, 2011, at 8:53 PM, Frank Bulk wrote: Why don't we change the second point to: + to another RIR, for transfer to a specified recipient in that RIR's service region, if the request meets both RIRS' transfer policies. Frank From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Scott Leibrand Sent: Monday, May 23, 2011 5:17 PM To: Mike Burns Cc: ARIN-PPML List Subject: Re: [arin-ppml] Integrating Draft Policy ARIN-2011-1 into NRPM 8.3 On Mon, May 23, 2011 at 3:00 PM, Mike Burns wrote: Hi Scott, In the context of this proposal, may I ask what would happen if APNIC accepted a transfer of ARIN legacy addresses and updated their Whois, even if ARIN refused the transfer? I suppose what would matter in that case is who IANA pointed to. To date, we haven't seen cases where two different RIRs were both claiming authority for the same address block, and I don't expect to see that, as all of the RIRs are committed to operating within the "RIR system". (Because the language of the proposal pointedly excludes APNIC, if their current policy remains in place.) I know that ARIN could revoke and reissue. How is inter-RIR conflict resolved, is there a process in place for conflict resolution? Yes, I believe there is, but I don't know the details. I presume it would be a largely consensual process within the ASO/NRO/IANA framework (perhaps within the NRO EC?). Do the RIRs generally have compatible needs-based transfer policies, I mean I know APNIC doesn't, but do the other RIRs have the same 3-month window, for example? Is a difference in the needs window enough to prevent a transfer? If so, do we need to consider other RIRs and the impact on inter-RIR transfers when we consider proposals to change the needs window? What if RIPE joins APNIC with a requirement like a /24 maximum, is that something that makes the needs requirements incompatible? I don't consider any such differences in timeframes, size minimums/maximums, etc. to be incompatibilities in the context of 2011-1. But ARIN has said that, as things stand today, the lack of explicit needs basis in APNIC's transfer policy would make it incompatible with 2011-1's requirement for "compatible, needs-based transfer policies". I hope we can come to an agreement with the APNIC community on language or interpretation that would be compatible with both regions' needs and preferences, but 2011-1 as I see it is just the first step in that direction: setting up a framework that would allow inter-RIR transfers once such incompatibilities are resolved somehow (or with other RIRs where such incompatibilities may not exist). I guess I am asking for a more detailed definition of the word "compatible" in your proposed language. Maybe that language is extraneous, as you are already requiring both RIRs to agree? Operationally, the two are quite related, in that ARIN will not agree unless they assess the other RIR's transfer policy to be compatible. But the "RIRs agree" language is also there as a safety valve to explicitly allow an RIR to not agree to a transfer if it has reason to believe that the transfer would violate policy or law. -Scott (speaking only for myself, as usual) ----- Original Message ----- From: Scott Leibrand To: Owen DeLong Cc: ARIN-PPML List Sent: Monday, May 23, 2011 5:21 PM Subject: Re: [arin-ppml] Integrating Draft Policy ARIN-2011-1 into NRPM 8.3 On Mon, May 23, 2011 at 2:05 PM, Owen DeLong wrote: I could support this, but, I have a couple of lingering concerns. I think that the last sentence dictates too much in the case of a transfer to another region and should only apply to transfers within the ARIN region. Yeah, I was wondering about that myself. Possible slight revision inline below... I would like to see us relocate the single aggregate clause to make it binding on the actual community intent and if we're going to turn 2011-1 into a policy to modify 8.3 anyway, we should incorporate that change. I would like to see another proposal to do this (and to be discussed as a counterpoint to ARIN-prop-144 in Philadelphia). On May 23, 2011, at 15:54, Scott Leibrand wrote: In light of the discomfort a number of community and AC members feel with the original 2011-1 text, I thought I'd make an attempt at integrating it into the framework of NRPM 8.3, to see if the result would be tighter and less ambiguous. Here's what I came up with: 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, in whole or in part, for transfer: * to a specified organizational recipient within the ARIN region, or * to another RIR, for transfer to a specified organizational recipient in that RIR's service region, if the two RIRs agree and maintain compatible, needs-based transfer policies. Such transferred number resources may only be received under RSA by organizations that can demonstrate the need for such resources, as a single aggregate, in the exact amount which they can justify under current ARIN policies. How about "Such number resources may only be received under RSA by organizations that can demonstrate the need for such resources, as a single aggregate, in the exact amount which they can justify under current ARIN, or recipient RIR, policies." ? Or, feel free to suggest text... -Scott For reference, existing policy reads: 8.3. Transfers to Specified Recipients In addition to transfers under section 8.2, IPv4 number resources within the ARIN region may be released to ARIN by the authorized resource holder, in whole or in part, for transfer to another specified organizational recipient. Such transferred number resources may only be received under RSA by organizations that are within the ARIN region and can demonstrate the need for such resources, as a single aggregate, in the exact amount which they can justify under current ARIN policies. And original 2011-1 text reads: Any RIR's resource registrant may transfer IPv4 addresses to the resource registrant of another RIR as long as the two RIRs agree and maintain compatible, needs-based transfer policies that exercise Internet stewardship consistent with the values expressed in RFC2050. _______________________________________________ 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 scottleibrand at gmail.com Tue May 24 01:07:45 2011 From: scottleibrand at gmail.com (Scott Leibrand) Date: Mon, 23 May 2011 22:07:45 -0700 Subject: [arin-ppml] Integrating Draft Policy ARIN-2011-1 into NRPM 8.3 In-Reply-To: <0114D408-5D5F-4EC3-A193-BE10687D7A8C@delong.com> References: <07DCA09506E941C3AEE0B6562DF8DB4E@mike> <00ac01cc19c6$2c803340$858099c0$@iname.com> <0114D408-5D5F-4EC3-A193-BE10687D7A8C@delong.com> Message-ID: <-5099803936536899096@unknownmsgid> So perhaps: + to another RIR, for transfer to a specified recipient in that RIR's service region, if both RIRs agree and the request meets both RIRs' transfer policies. I agree it's useful to preserve discretion. I think I might prefer this to the text I originally had below... Thoughts? Scott On May 23, 2011, at 9:56 PM, Owen DeLong < owen at delong.com> wrote: I prefer to preserve the safety valve of requiring agreement from both RIRs. Owen On May 23, 2011, at 8:53 PM, Frank Bulk wrote: Why don?t we change the second point to: + to another RIR, for transfer to a specified recipient in that RIR's service region, if the request meets both RIRS? transfer policies. Frank * * ----- Original Message ----- *From:* Scott Leibrand *To:* Owen DeLong *Cc:* ARIN-PPML List *Sent:* Monday, May 23, 2011 5:21 PM *Subject:* Re: [arin-ppml] Integrating Draft Policy ARIN-2011-1 into NRPM 8.3 On Mon, May 23, 2011 at 2:05 PM, Owen DeLong < owen at delong.com> wrote: I could support this, but, I have a couple of lingering concerns. I think that the last sentence dictates too much in the case of a transfer to another region and should only apply to transfers within the ARIN region. Yeah, I was wondering about that myself. Possible slight revision inline below... On May 23, 2011, at 15:54, Scott Leibrand < scottleibrand at gmail.com> wrote: In light of the discomfort a number of community and AC members feel with the original 2011-1 text, I thought I'd make an attempt at integrating it into the framework of NRPM 8.3, to see if the result would be tighter and less ambiguous. Here's what I came up with: 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, in whole or in part, for transfer: - to a specified organizational recipient within the ARIN region, or - to another RIR, for transfer to a specified organizational recipient in that RIR's service region, if the two RIRs agree and maintain compatible, needs-based transfer policies. Such transferred number resources may only be received under RSA by organizations that can demonstrate the need for such resources, as a single aggregate, in the exact amount which they can justify under current ARIN policies. How about "Such number resources may only be received under RSA by organizations that can demonstrate the need for such resources, as a single aggregate, in the exact amount which they can justify under current ARIN, or recipient RIR, policies." ? Or, feel free to suggest text... -Scott For reference, existing policy reads: 8.3. Transfers to Specified Recipients In addition to transfers under section 8.2, IPv4 number resources within the ARIN region may be released to ARIN by the authorized resource holder, in whole or in part, for transfer to another specified organizational recipient. Such transferred number resources may only be received under RSA by organizations that are within the ARIN region and can demonstrate the need for such resources, as a single aggregate, in the exact amount which they can justify under current ARIN policies. And original 2011-1 text reads: Any RIR's resource registrant may transfer IPv4 addresses to the resource registrant of another RIR as long as the two RIRs agree and maintain compatible, needs-based transfer policies that exercise Internet stewardship consistent with the values expressed in RFC2050. _______________________________________________ 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. _______________________________________________ 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 Tue May 24 01:47:01 2011 From: owen at delong.com (Owen DeLong) Date: Mon, 23 May 2011 22:47:01 -0700 Subject: [arin-ppml] Integrating Draft Policy ARIN-2011-1 into NRPM 8.3 In-Reply-To: <-5099803936536899096@unknownmsgid> References: <07DCA09506E941C3AEE0B6562DF8DB4E@mike> <00ac01cc19c6$2c803340$858099c0$@iname.com> <0114D408-5D5F-4EC3-A193-BE10687D7A8C@delong.com> <-5099803936536899096@unknownmsgid> Message-ID: <349C8AD2-9C4B-4B0F-8875-A6040341F476@delong.com> I still would prefer to see the needs-basis comment preserved as well. Owen On May 23, 2011, at 10:07 PM, Scott Leibrand wrote: > So perhaps: > > + to another RIR, for transfer to a specified recipient in that RIR's service region, if both RIRs agree and the request meets both RIRs' transfer policies. > > I agree it's useful to preserve discretion. I think I might prefer this to the text I originally had below... Thoughts? > > Scott > > On May 23, 2011, at 9:56 PM, Owen DeLong wrote: > >> I prefer to preserve the safety valve of requiring agreement from both RIRs. >> >> Owen >> >> On May 23, 2011, at 8:53 PM, Frank Bulk wrote: >> >>> Why don?t we change the second point to: >>> >>> + to another RIR, for transfer to a specified recipient in that RIR's service >>> region, if the request meets both RIRS? transfer policies. >>> >>> Frank >>> >>> >>> >>> >>> >>> >>> ----- Original Message ----- >>> From: Scott Leibrand >>> To: Owen DeLong >>> Cc: ARIN-PPML List >>> Sent: Monday, May 23, 2011 5:21 PM >>> Subject: Re: [arin-ppml] Integrating Draft Policy ARIN-2011-1 into NRPM 8.3 >>> >>> On Mon, May 23, 2011 at 2:05 PM, Owen DeLong wrote: >>> I could support this, but, I have a couple of lingering concerns. >>> >>> I think that the last sentence dictates too much in the case of a transfer to another region and should only apply to transfers within the ARIN region. >>> >>> Yeah, I was wondering about that myself. Possible slight revision inline below... >>> >>> >>> On May 23, 2011, at 15:54, Scott Leibrand wrote: >>> >>> In light of the discomfort a number of community and AC members feel with the original 2011-1 text, I thought I'd make an attempt at integrating it into the framework of NRPM 8.3, to see if the result would be tighter and less ambiguous. Here's what I came up with: >>> >>> 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, in whole or in part, for transfer: >>> to a specified organizational recipient within the ARIN region, or >>> to another RIR, for transfer to a specified organizational recipient in that RIR's service region, if the two RIRs agree and maintain compatible, needs-based transfer policies. >>> Such transferred number resources may only be received under RSA by organizations that can demonstrate the need for such resources, as a single aggregate, in the exact amount which they can justify under current ARIN policies. >>> >>> How about "Such number resources may only be received under RSA by organizations that can demonstrate the need for such resources, as a single aggregate, in the exact amount which they can justify under current ARIN, or recipient RIR, policies." ? >>> >>> Or, feel free to suggest text... >>> >>> -Scott >>> >>> >>> For reference, existing policy reads: >>> 8.3. Transfers to Specified Recipients >>> >>> In addition to transfers under section 8.2, IPv4 number resources within the ARIN region may be released to ARIN by the authorized resource holder, in whole or in part, for transfer to another specified organizational recipient. Such transferred number resources may only be received under RSA by organizations that are within the ARIN region and can demonstrate the need for such resources, as a single aggregate, in the exact amount which they can justify under current ARIN policies. >>> >>> And original 2011-1 text reads: >>> Any RIR's resource registrant may transfer IPv4 addresses to the resource registrant of another RIR as long as the two RIRs agree and maintain compatible, needs-based transfer policies that exercise Internet stewardship consistent with the values expressed in RFC2050. >>> _______________________________________________ >>> 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. >> >> _______________________________________________ >> 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 Tue May 24 02:18:22 2011 From: owen at delong.com (Owen DeLong) Date: Mon, 23 May 2011 23:18:22 -0700 Subject: [arin-ppml] Integrating Draft Policy ARIN-2011-1 into NRPM 8.3 In-Reply-To: <00b101cc19cf$750f6690$5f2e33b0$@iname.com> References: <07DCA09506E941C3AEE0B6562DF8DB4E@mike> <00ac01cc19c6$2c803340$858099c0$@iname.com> <0114D408-5D5F-4EC3-A193-BE10687D7A8C@delong.com> <00b101cc19cf$750f6690$5f2e33b0$@iname.com> Message-ID: <138BFC71-19BE-4717-869E-71728C069234@delong.com> There may be some other policy or legal reason that either RIR may wish to block the transfer and I want to give staff the ability to address unforeseen circumstances in a complicated and shifting environment that could change without input through our PDP by doing the closest they can come to "the right thing" based on sound judgment rather than being ratholed by our policy which cannot possibly adapt fast enough. Owen On May 23, 2011, at 10:00 PM, Frank Bulk wrote: > Can you explain why? It?s not that ARIN-2011-1 binds the non-ARIN RIR to receive the netblock. > > Frank > > From: Owen DeLong [mailto:owen at delong.com] > Sent: Monday, May 23, 2011 11:56 PM > To: frnkblk at iname.com > Cc: ARIN-PPML List > Subject: Re: [arin-ppml] Integrating Draft Policy ARIN-2011-1 into NRPM 8.3 > > I prefer to preserve the safety valve of requiring agreement from both RIRs. > > Owen > > On May 23, 2011, at 8:53 PM, Frank Bulk wrote: > > > Why don?t we change the second point to: > > + to another RIR, for transfer to a specified recipient in that RIR's service > region, if the request meets both RIRS? transfer policies. > > Frank > > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Scott Leibrand > Sent: Monday, May 23, 2011 5:17 PM > To: Mike Burns > Cc: ARIN-PPML List > Subject: Re: [arin-ppml] Integrating Draft Policy ARIN-2011-1 into NRPM 8.3 > > On Mon, May 23, 2011 at 3:00 PM, Mike Burns wrote: > Hi Scott, > > In the context of this proposal, may I ask what would happen if APNIC accepted a transfer of ARIN legacy addresses and updated their Whois, even if ARIN refused the transfer? > > I suppose what would matter in that case is who IANA pointed to. To date, we haven't seen cases where two different RIRs were both claiming authority for the same address block, and I don't expect to see that, as all of the RIRs are committed to operating within the "RIR system". > > (Because the language of the proposal pointedly excludes APNIC, if their current policy remains in place.) > I know that ARIN could revoke and reissue. > How is inter-RIR conflict resolved, is there a process in place for conflict resolution? > > Yes, I believe there is, but I don't know the details. I presume it would be a largely consensual process within the ASO/NRO/IANA framework (perhaps within the NRO EC?). > > Do the RIRs generally have compatible needs-based transfer policies, I mean I know APNIC doesn't, but do the other RIRs have the same 3-month window, for example? > Is a difference in the needs window enough to prevent a transfer? > If so, do we need to consider other RIRs and the impact on inter-RIR transfers when we consider proposals to change the needs window? > What if RIPE joins APNIC with a requirement like a /24 maximum, is that something that makes the needs requirements incompatible? > > I don't consider any such differences in timeframes, size minimums/maximums, etc. to be incompatibilities in the context of 2011-1. But ARIN has said that, as things stand today, the lack of explicit needs basis in APNIC's transfer policy would make it incompatible with 2011-1's requirement for "compatible, needs-based transfer policies". I hope we can come to an agreement with the APNIC community on language or interpretation that would be compatible with both regions' needs and preferences, but 2011-1 as I see it is just the first step in that direction: setting up a framework that would allow inter-RIR transfers once such incompatibilities are resolved somehow (or with other RIRs where such incompatibilities may not exist). > > I guess I am asking for a more detailed definition of the word "compatible" in your proposed language. > Maybe that language is extraneous, as you are already requiring both RIRs to agree? > > Operationally, the two are quite related, in that ARIN will not agree unless they assess the other RIR's transfer policy to be compatible. But the "RIRs agree" language is also there as a safety valve to explicitly allow an RIR to not agree to a transfer if it has reason to believe that the transfer would violate policy or law. > > -Scott (speaking only for myself, as usual) > > > > > > ----- Original Message ----- > From: Scott Leibrand > To: Owen DeLong > Cc: ARIN-PPML List > Sent: Monday, May 23, 2011 5:21 PM > Subject: Re: [arin-ppml] Integrating Draft Policy ARIN-2011-1 into NRPM 8.3 > > On Mon, May 23, 2011 at 2:05 PM, Owen DeLong wrote: > I could support this, but, I have a couple of lingering concerns. > > I think that the last sentence dictates too much in the case of a transfer to another region and should only apply to transfers within the ARIN region. > > Yeah, I was wondering about that myself. Possible slight revision inline below... > > I would like to see us relocate the > single aggregate clause to make it binding on the actual community intent and if we're > going to turn 2011-1 into a policy to modify 8.3 anyway, we should incorporate that > change. > > I would like to see another proposal to do this (and to be discussed as a counterpoint to ARIN-prop-144 in Philadelphia). > > On May 23, 2011, at 15:54, Scott Leibrand wrote: > > In light of the discomfort a number of community and AC members feel with the original 2011-1 text, I thought I'd make an attempt at integrating it into the framework of NRPM 8.3, to see if the result would be tighter and less ambiguous. Here's what I came up with: > > 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, in whole or in part, for transfer: > to a specified organizational recipient within the ARIN region, or > to another RIR, for transfer to a specified organizational recipient in that RIR's service region, if the two RIRs agree and maintain compatible, needs-based transfer policies. > Such transferred number resources may only be received under RSA by organizations that can demonstrate the need for such resources, as a single aggregate, in the exact amount which they can justify under current ARIN policies. > > How about "Such number resources may only be received under RSA by organizations that can demonstrate the need for such resources, as a single aggregate, in the exact amount which they can justify under current ARIN, or recipient RIR, policies." ? > > Or, feel free to suggest text... > > -Scott > > > For reference, existing policy reads: > 8.3. Transfers to Specified Recipients > > In addition to transfers under section 8.2, IPv4 number resources within the ARIN region may be released to ARIN by the authorized resource holder, in whole or in part, for transfer to another specified organizational recipient. Such transferred number resources may only be received under RSA by organizations that are within the ARIN region and can demonstrate the need for such resources, as a single aggregate, in the exact amount which they can justify under current ARIN policies. > > And original 2011-1 text reads: > Any RIR's resource registrant may transfer IPv4 addresses to the resource registrant of another RIR as long as the two RIRs agree and maintain compatible, needs-based transfer policies that exercise Internet stewardship consistent with the values expressed in RFC2050. > _______________________________________________ > 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 BillD at cait.wustl.edu Tue May 24 06:34:06 2011 From: BillD at cait.wustl.edu (Bill Darte) Date: Tue, 24 May 2011 05:34:06 -0500 Subject: [arin-ppml] Integrating Draft Policy ARIN-2011-1 into NRPM 8.3 References: <07DCA09506E941C3AEE0B6562DF8DB4E@mike><00ac01cc19c6$2c803340$858099c0$@iname.com><0114D408-5D5F-4EC3-A193-BE10687D7A8C@delong.com><-5099803936536899096@unknownmsgid> <349C8AD2-9C4B-4B0F-8875-A6040341F476@delong.com> Message-ID: Early on in the formulation and debate of 2011-1, needs-basis was established as a principle which the ARIN community wished to retain. In that, it was suggested that having such language would allow ARIN to identify those RIRs which did and did not have that basis for their policy and easily allow or disallow transfer accordingly.... This was said to also make it explicit why ARIN 'did not agree' to transfer blocks to a region where no such basis exists. In this way, those applicants that were refused would know why. But would they actually know? Would ARIN really 'stamp' the denial with that explanation? Of course, RIRs may find other reasons to 'not agree' as Owen points out and these would not (without amendment) be called out explicitly and would not therefore notify potential recipients in the same way. Would ARIN still have to publish its reasons for denying applications?...or would ARIN really comment on the basis for denial in either case?...and if such a notice was attendant to the denial, I'm quite sure it wouldn't be made public. So, the debate over having a needs-basis goes on. I believe that needs basis has been fundamental to our community's past principles and the RIR regime. IF that is to change, if 'the market' is the new regime which can 'best' distribute Internet number resources....then needs-basis as we have known it can be omitted from both policy and practice. But 'best' must be assessed across all its objectives....is it simply efficiency? Is it efficiency along with fairness where fairness anticipates something more than ability to pay the going price? Does it really matter that need is assessed ultimately by a for-profit agency rather than a do-gooder organization like an RIR beholden to a large and diverse community rather than a few executives? Is it any different if that for-profit agency is a public corporation with the backing of many shareholders as its ultimate constituency? What is 'right' for the overall interest of the community...the whole community? How will 'others' who are for and against the RIR regime interpret this policy and its 'rightness'....which principles of 'best' and 'right' ultimately matter? All this, and more is what the inclusion or exclusion of a needs-basis clause anticipates. My personal, non-AC affiliated belief, is that a needs-based regime is the best regime and that our current system of grass-roots policy development is as fair as it can be and thus, I personally favor retaining a needs-based clause. bd -----Original Message----- From: arin-ppml-bounces at arin.net on behalf of Owen DeLong Sent: Tue 5/24/2011 12:47 AM To: Scott Leibrand Cc: ARIN-PPML List Subject: Re: [arin-ppml] Integrating Draft Policy ARIN-2011-1 into NRPM 8.3 I still would prefer to see the needs-basis comment preserved as well. Owen On May 23, 2011, at 10:07 PM, Scott Leibrand wrote: > So perhaps: > > + to another RIR, for transfer to a specified recipient in that RIR's service region, if both RIRs agree and the request meets both RIRs' transfer policies. > > I agree it's useful to preserve discretion. I think I might prefer this to the text I originally had below... Thoughts? > > Scott > > On May 23, 2011, at 9:56 PM, Owen DeLong wrote: > >> I prefer to preserve the safety valve of requiring agreement from both RIRs. >> >> Owen >> >> On May 23, 2011, at 8:53 PM, Frank Bulk wrote: >> >>> Why don't we change the second point to: >>> >>> + to another RIR, for transfer to a specified recipient in that RIR's service >>> region, if the request meets both RIRS' transfer policies. >>> >>> Frank >>> >>> >>> >>> >>> >>> >>> ----- Original Message ----- >>> From: Scott Leibrand >>> To: Owen DeLong >>> Cc: ARIN-PPML List >>> Sent: Monday, May 23, 2011 5:21 PM >>> Subject: Re: [arin-ppml] Integrating Draft Policy ARIN-2011-1 into NRPM 8.3 >>> >>> On Mon, May 23, 2011 at 2:05 PM, Owen DeLong wrote: >>> I could support this, but, I have a couple of lingering concerns. >>> >>> I think that the last sentence dictates too much in the case of a transfer to another region and should only apply to transfers within the ARIN region. >>> >>> Yeah, I was wondering about that myself. Possible slight revision inline below... >>> >>> >>> On May 23, 2011, at 15:54, Scott Leibrand wrote: >>> >>> In light of the discomfort a number of community and AC members feel with the original 2011-1 text, I thought I'd make an attempt at integrating it into the framework of NRPM 8.3, to see if the result would be tighter and less ambiguous. Here's what I came up with: >>> >>> 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, in whole or in part, for transfer: >>> to a specified organizational recipient within the ARIN region, or >>> to another RIR, for transfer to a specified organizational recipient in that RIR's service region, if the two RIRs agree and maintain compatible, needs-based transfer policies. >>> Such transferred number resources may only be received under RSA by organizations that can demonstrate the need for such resources, as a single aggregate, in the exact amount which they can justify under current ARIN policies. >>> >>> How about "Such number resources may only be received under RSA by organizations that can demonstrate the need for such resources, as a single aggregate, in the exact amount which they can justify under current ARIN, or recipient RIR, policies." ? >>> >>> Or, feel free to suggest text... >>> >>> -Scott >>> >>> >>> For reference, existing policy reads: >>> 8.3. Transfers to Specified Recipients >>> >>> In addition to transfers under section 8.2, IPv4 number resources within the ARIN region may be released to ARIN by the authorized resource holder, in whole or in part, for transfer to another specified organizational recipient. Such transferred number resources may only be received under RSA by organizations that are within the ARIN region and can demonstrate the need for such resources, as a single aggregate, in the exact amount which they can justify under current ARIN policies. >>> >>> And original 2011-1 text reads: >>> Any RIR's resource registrant may transfer IPv4 addresses to the resource registrant of another RIR as long as the two RIRs agree and maintain compatible, needs-based transfer policies that exercise Internet stewardship consistent with the values expressed in RFC2050. >>> _______________________________________________ >>> 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. >> >> _______________________________________________ >> 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 mike at nationwideinc.com Tue May 24 09:55:10 2011 From: mike at nationwideinc.com (Mike Burns) Date: Tue, 24 May 2011 09:55:10 -0400 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate References: <15F92ECD-2BE5-48F2-B65A-9A9D39B98F54@delong.com> <0829B106605C4FE8B189DB2E56C69615@mike> <51506A06-D2EE-4A0D-B92B-781662094A1C@eyeconomics.com> <0CCB8AB89D144E89872AF0D635E95497@mike> <2691B7B9-1F3C-403C-B4E8-5B82BED0E191@eyeconomics.com> <454BB1826E7B4F2BB3A68BE1DD86A756@video> <909D6DD7-404F-4BB3-B330-78B755FAB6DA@eyeconomics.com> <156DA5A48E51490284BC21D982A8FDAB@mike> <77310136-54C6-43F0-9923-E7810DD2736D@delong.com> <059E9D87D0D8420D8EAE18BF78F1FA88@video> <2802FCB9-1D0A-43AA-81BB-C3A93AAA7B45@delong.com> <5F1AB819-C436-42B8-9CE9-14CF74F5E385@arin.net> <9D6E8A5B-A7B4-40BC-960E-7B40640B3F90@arin.net> <4AD7C11ED3C74C2BAE247B9470662094@mike> <36D226BD-E507-487B-9B69-A5315854023C@ delong.com> Message-ID: <0A627BD19D7340F49F296028DDDF82FE@mike> Good morning Owen, > When you tighten up restrictions and begin the process Owen is talking > about, the revokation and reissuance of space, the potential for conflict > is ripe. We aren't talking about tightening up restrictions. We're talking about not removing existing restrictions. The reclamation and reissuance that I have advocated is already there in current policy. You are the one proposing a change. I have been describing the current state of policy. Mischaracterizing my position as advocating for change (with the implication that you are advocating codifying existing practice) really doesn't reflect the reality of the situation. > >Owen OK, not tightening up restrictions, but maybe applying them more forcefully or frequently than in the past? I was saying (and I know it's hard to follow) that since network operators do route sold space currently, the only way they would not do that, IMO, is if there was a conflict. Either somebody else is claiming the rights to the address space, or it is being advertised by somebody else. You have suggested that in that case they will likely view the RIR as authoritative, which I agree with. You have suggested that the sale of legacy space from the original registrant leaves the buyer subject to revokation under ARIN policy, equivalent to a hijacker, should he fail to come to terms with ARIN on a transfer. And your prescription in this event is to utilize existing policy, which in your view gives ARIN the right to revoke and reissue those addresses. My point is that if we take that approach, we end up in conflict, with ARIN in the possible position of defending a suit for tortious interference in the contract between a network operator and his customer. On the other hand, if ARIN's policy were more in alignment with the legal mileu, wherein huge amounts of companies have been bought and sold using asset sale agreements which list the IP addresses as assets to be sold, and where a federal bankruptcy judge found that selling them through this mechanism was legal, then there would likely be less legal peril for ARIN. Sure, there will be fights over address rights ownership, like over any other asset, and courts will use the same tools used today, namely chain-of-custody review from the original owner to the current claimants. If ARIN were to content itself with recording the transactions and not acting as a market regulator, I believe we would see the same effect, namely efficient use of addresses, with less risk than the confrontational stance you seem to advocate. Regards, Mike From jcurran at arin.net Tue May 24 10:03:14 2011 From: jcurran at arin.net (John Curran) Date: Tue, 24 May 2011 14:03:14 +0000 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate In-Reply-To: <0A627BD19D7340F49F296028DDDF82FE@mike> References: <15F92ECD-2BE5-48F2-B65A-9A9D39B98F54@delong.com> <0829B106605C4FE8B189DB2E56C69615@mike> <51506A06-D2EE-4A0D-B92B-781662094A1C@eyeconomics.com> <0CCB8AB89D144E89872AF0D635E95497@mike> <2691B7B9-1F3C-403C-B4E8-5B82BED0E191@eyeconomics.com> <454BB1826E7B4F2BB3A68BE1DD86A756@video> <909D6DD7-404F-4BB3-B330-78B755FAB6DA@eyeconomics.com> <156DA5A48E51490284BC21D982A8FDAB@mike> <77310136-54C6-43F0-9923-E7810DD2736D@delong.com> <059E9D87D0D8420D8EAE18BF78F1FA88@video> <2802FCB9-1D0A-43AA-81BB-C3A93AAA7B45@delong.com> <5F1AB819-C436-42B8-9CE9-14CF74F5E385@arin.net> <9D6E8A5B-A7B4-40BC-960E-7B40640B3F90@arin.net> <4AD7C11ED3C74C2BAE247B9470662094@mike> <36D226BD-E507-487B-9B69-A5315854023C@mac.com> <0A627BD19D7340F49F296028DDDF82FE@mike> Message-ID: <3B9D6DF5-14E3-4086-BE2D-EF89562EDC7C@arin.net> On May 24, 2011, at 9:55 AM, Mike Burns wrote: > > If ARIN were to content itself with recording the transactions and not acting as a market regulator, I believe we would see the same effect, namely efficient use of addresses, with less risk than the confrontational stance you seem to advocate. Mike - Efficient use of address space is a reasonable match to the goal of "conservation", but what do you propose with respect to the goal of "aggregation" under such a model? /John John Curran President and CEO ARIN From owen at delong.com Tue May 24 10:11:56 2011 From: owen at delong.com (Owen DeLong) Date: Tue, 24 May 2011 07:11:56 -0700 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate In-Reply-To: <0A627BD19D7340F49F296028DDDF82FE@mike> References: <15F92ECD-2BE5-48F2-B65A-9A9D39B98F54@delong.com> <0829B106605C4FE8B189DB2E56C69615@mike> <51506A06-D2EE-4A0D-B92B-781662094A1C@eyeconomics.com> <0CCB8AB89D144E89872AF0D635E95497@mike> <2691B7B9-1F3C-403C-B4E8-5B82BED0E191@eyeconomics.com> <454BB1826E7B4F2BB3A68BE1DD86A756@video> <909D6DD7-404F-4BB3-B330-78B755FAB6DA@eyeconomics.com> <156DA5A48E51490284BC21D982A8FDAB@mike> <77310136-54C6-43F0-9923-E7810DD2736D@delong.com> <059E9D87D0D8420D8EAE18BF78F1FA88@video> <2802FCB9-1D0A-43AA-81BB-C3A93AAA7B45@delong.com> <5F1AB819-C436-42B8-9CE9-14CF74F5E385@arin.net> <9D6E8A5B-A7B4-40BC-960E-7B40640B3F90@arin.net> <4AD7C11ED3C74C2BAE247B9470662094@mike> <36D226BD-E507-487B-9B69-A5315854023C! @delong.com> <0A627BD19D7340F49F296028DDDF82FE@mike> Message-ID: On May 24, 2011, at 6:55 AM, Mike Burns wrote: > Good morning Owen, > >> When you tighten up restrictions and begin the process Owen is talking about, the revokation and reissuance of space, the potential for conflict is ripe. > > We aren't talking about tightening up restrictions. We're talking about not removing existing > restrictions. The reclamation and reissuance that I have advocated is already there in > current policy. > > You are the one proposing a change. I have been describing the current state of policy. > > Mischaracterizing my position as advocating for change (with the implication that you > are advocating codifying existing practice) really doesn't reflect the reality of the > situation. >> >> Owen > > > > OK, not tightening up restrictions, but maybe applying them more forcefully or frequently than in the past? > No, not really. > I was saying (and I know it's hard to follow) that since network operators do route sold space currently, the only way they would not do that, IMO, is if there was a conflict. True... > Either somebody else is claiming the rights to the address space, or it is being advertised by somebody else. You have suggested that in that case they will likely view the RIR as authoritative, which I agree with. > In which case I don't see a problem developing that requires your policy. > You have suggested that the sale of legacy space from the original registrant leaves the buyer subject to revokation under ARIN policy, equivalent to a hijacker, should he fail to come to terms with ARIN on a transfer. > Yes. > And your prescription in this event is to utilize existing policy, which in your view gives ARIN the right to revoke and reissue those addresses. > Yes. As ARIN would currently do upon learning of such a transfer if I understand things correctly. As I said, they would first approach the original registrant and confirm that they had released the addresses. Then they would contact the recipient and see if an 8.2 or 8.3 transfer could be processed. Failing that, I believe ARIN has an obligation to treat the resources as abandoned under current policy. It would be great if John would comment on whether my understanding is correct. > My point is that if we take that approach, we end up in conflict, with ARIN in the possible position of defending a suit for tortious interference in the contract between a network operator and his customer. > We haven't ended up in a conflict where ARIN didn't prevail so far. Further, I don't see how controlling records in their own database can be construed as tortious interference in someone else's contract unrelated to ARIN. Especially when they refused to cooperate with ARIN in updating the records and knew full well about the likely outcome before they engaged in the contract. > On the other hand, if ARIN's policy were more in alignment with the legal mileu, wherein huge amounts of companies have been bought and sold using asset sale agreements which list the IP addresses as assets to be sold, and where a federal bankruptcy judge found that selling them through this mechanism was legal, then there would likely be less legal peril for ARIN. > Again, it's completely and utterly unclear what the federal judge thought the assets in this regard actually constituted. Further, the judge made it very clear that the transfer was subject to the terms of the registration services agreement between ARIN and Micr0$0ft. It seems to me that the federal bankruptcy judge ruled very clearly that ARIN did have authority over the registration of the transfer. As such, I believe current policy is completely in line with the current legal milieu and there is no need to grant additional rights based on your bogey-man argument. > Sure, there will be fights over address rights ownership, like over any other asset, and courts will use the same tools used today, namely chain-of-custody review from the original owner to the current claimants. > Looks to me like the court used ARIN as much as anything else and clearly recognized ARIN's authority over registrations of IP addresses. > If ARIN were to content itself with recording the transactions and not acting as a market regulator, I believe we would see the same effect, namely efficient use of addresses, with less risk than the confrontational stance you seem to advocate. > I believe you are entirely mistaken in this and I have presented plenty of evidence to back up that belief, including historical examples of the behavior I have predicted under such a system. You have yet to present any evidence to refute my claims, instead relying on the idea that continuing to recite your belief will somehow make it come true. Owen From kkargel at polartel.com Tue May 24 11:17:26 2011 From: kkargel at polartel.com (Kevin Kargel) Date: Tue, 24 May 2011 10:17:26 -0500 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate In-Reply-To: <36D226BD-E507-487B-9B69-A5315854023C@delong.com> References: <4DCFDB5C64DD4F738B65AB82D36B629D@mike> <15F92ECD-2BE5-48F2-B65A-9A9D39B98F54@delong.com> <0829B106605C4FE8B189DB2E56C69615@mike> <51506A06-D2EE-4A0D-B92B-781662094A1C@eyeconomics.com> <0CCB8AB89D144E89872AF0D635E95497@mike> <2691B7B9-1F3C-403C-B4E8-5B82BED0E191@eyeconomics.com> <454BB1826E7B4F2BB3A68BE1DD86A756@video> <909D6DD7-404F-4BB3-B330-78B755FAB6DA@eyeconomics.com> <156DA5A48E51490284BC21D982A8FDAB@mike> <77310136-54C6-43F0-9923-E7810DD2736D@delong.com> <059E9D87D0D8420D8EAE18BF78F1FA88@video> <2802FCB9-1D0A-43AA-81BB-C3A93AAA7B45@delong.com> <5F1AB819-C436-42B8-9CE9-14CF74F5E385@arin.net> <9D6E8A5B-A7B4-40BC-960E-7B40640B3F90@arin.net> <4AD7C11ED3C74C2BAE247B9470662094@mike> <36D226BD-E507-487B-9B69-A5315854023C@delong.com> Message-ID: <8695009A81378E48879980039EEDAD289F033068@MAIL1.polartel.local> > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf Of Owen DeLong > Sent: Monday, May 23, 2011 5:43 PM > To: Mike Burns > Cc: arin-ppml at arin.net > Subject: Re: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois > Accurate > > > > > Hi Chris, > > > > It's important to understand that ARIN *does* have legal contractual > rights with all address holders under RSA. The RSA is the contract which > gives ARIN those legal rights. But the legacy holders don't have any > agreement, and so ARIN does not have any contractual rights over legacy > space, as they do over RSA space. > > > > Ah, but, this cuts both ways. Legacy holders don't have any agreement and > so don't have > any contractual rights, either, unless they're under LRSA or RSA with > ARIN. > > > This is the clear implication of Ray Plzak's words in his declaration. > Trying to bind legacy holders to ARIN policy is a difficult legal row to > hoe, absent these agreements. But ARIN doesn't need any agreement with > legacy holders to control Whois. I believe ARIN could legally reissue > *all* legacy addresses to new allocants and update Whois. ARIN has > exclusive rights to control Whois in accordance with community policy. > > With respect to registrations, all ARIN really does is control the various > databases > maintained by ARIN. All ARIN policy really governs is how ARIN manages > those > databases. They include Whois, ARIN's internal registration databases, the > database > from which ARIN generates it's in-addr.arpa and ip6.arpa zones, and > certain other > ancillary databases. > > Any other belief about exclusive rights to use, sell, buy, route, or > otherwise use > the number resources registered (or not registered) by ARIN is a somewhat > separate matter. The internet works because ISPs choose to cooperate with > the RIR system and make routing decisions based on what is in the ARIN > and other RIR databases. There is nothing that prevents any ISP or group > of ISPs from developing their own independent internet, registry > structure, > etc. and doing as they wish with it, including starting over with all > numbers > freshly unregistered an an entire 32-bit IPv4 greenfield address space. > > However, if they expect those registrations to be able to talk to the > current > IPv4 internet, well, there are some problems. What Owen is saying is to the crux of the matter. What ARIN does is simply to maintain a database pursuant to rules and agreements arrived at by members represented in the database. If you want to be represented in the database then you must agree to play along with the other members according to the rules. ARIN does not directly control any numbers, netblocks or the rights to use those numbers or netblocks other than as agreed upon by cooperating networks. All ARIN does is to manage a database. I, for one, am a little confused as to how an agreement between ARIN and another party is construed to be unilaterally transferable and treatable as property. Internet users *choose* to reference the ARIN database because it works and it makes life simpler than individually keeping track of where we route data and who we want to route it to. To my understanding (IANAL) neither ARIN nor any force of law require any network to operate referencing the ARIN database so long as you do not disrupt the operation of other networks. All the talk of ARIN controlling netblocks and routing is really obfuscation. If anyone doesn't like the way ARIN manages the database all they really have to do is maintain their own database. (Sounds simple, doesn't it..) So long as you and all the parties you wish to communicate with are using the same database life is good. What I suspect would be the biggest problem if a network did maintain their own database is that when their non-aligned peers discover they are using a different database then those non-aligned peers will stop accepting routing advertisements from the network. This has happened to networks in the past when network operators have had incorrect routes in their tables whether by intention or typo. To keep life simple and reduce my workload I choose to be represented in the ARIN database and follow the rules that go along with that. Kevin > > However, in terms of ARIN policy, that governs how ARIN administers the > registration database that ARIN maintains, regardless of whether the > entries > are legacy holders or not. Traditionally ARIN has bent over backwards to > accommodate legacy holders to the greatest extent possible in favor of > preserving a coherent community and a useful internet. > > I'm not advocating that we change this, but, I do _NOT_ want to expand > the pool of resource holders accommodated in this manner and would > rather seek ways in which we can reduce the size of that pool. Eventually, > IPv6 will move the meaningful size of that pool to very nearly zero > anyway. > > > > > But your points about multiple jurisdictions is important, and goes to > my argument that ARIN should recognize the most liberal address holder > rights as possible to go furthest in preventing potential conflict between > ARIN and address holder, or ARIN and some local government. > > Actually, it is not at all unlikely that many of the governments within > the ARIN region > would consider ARIN abandoning it's needs-basis stewardship of the > addresses > as an unauthorized abdication and conflict in the opposite direction. > > > When you tighten up restrictions and begin the process Owen is talking > about, the revokation and reissuance of space, the potential for conflict > is ripe. > > We aren't talking about tightening up restrictions. We're talking about > not removing existing > restrictions. The reclamation and reissuance that I have advocated is > already there in > current policy. > > You are the one proposing a change. I have been describing the current > state of policy. > > Mischaracterizing my position as advocating for change (with the > implication that you > are advocating codifying existing practice) really doesn't reflect the > reality of the > situation. > > > > > 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 rbf+arin-ppml at panix.com Tue May 24 11:29:52 2011 From: rbf+arin-ppml at panix.com (Brett Frankenberger) Date: Tue, 24 May 2011 10:29:52 -0500 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate In-Reply-To: References: <2802FCB9-1D0A-43AA-81BB-C3A93AAA7B45@delong.com> <5F1AB819-C436-42B8-9CE9-14CF74F5E385@arin.net> <9D6E8A5B-A7B4-40BC-960E-7B40640B3F90@arin.net> <4AD7C11ED3C74C2BAE247B9470662094@mike> <36D226BD-E507-487B-9B69-A5315854023C!@delong.com> <0A627BD19D7340F49F296028DDDF82FE@mike> Message-ID: <20110524152952.GA16145@panix.com> On Tue, May 24, 2011 at 07:11:56AM -0700, Owen DeLong wrote: > > Again, it's completely and utterly unclear what the federal judge > thought the assets in this regard actually constituted. Further, the > judge made it very clear that the transfer was subject to the terms > of the registration services agreement between ARIN and Micr0$0ft. It > seems to me that the federal bankruptcy judge ruled very clearly that > ARIN did have authority over the registration of the transfer. The court's ruling in the Microsoft case is a red herring. What one bankruptcy judge said about one transfer in one bankruptcy case, in a decision that was not appealed, is of minimal value going forward. I agree with what you've written above; but it's not precedent that can be used with much effect in any other case. (This works both ways. Even if the judge said and meant exactly what Mike thinks he said and meant, it's still not useful for much.) Sure, future litigants might refer to that case or the judges reasoning if it is favorable to them, but it's not binding precedent on any other court (or even on that same court in its next case). We'll never *really* know the status until there's a fight that gets to appellate courts, and that addresses these issues head on. (Note that in the bankruptcy case in question, all parties involved wanted the transfer to occur. There was no one going into court arguing the "you can't transfer them this way" position. You don't get good precedent absent an adverserial hearing on the issue.) -- Brett From matthew at matthew.at Tue May 24 11:31:59 2011 From: matthew at matthew.at (Matthew Kaufman) Date: Tue, 24 May 2011 17:31:59 +0200 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate In-Reply-To: <8695009A81378E48879980039EEDAD289F033068@MAIL1.polartel.local> References: <4DCFDB5C64DD4F738B65AB82D36B629D@mike> <15F92ECD-2BE5-48F2-B65A-9A9D39B98F54@delong.com> <0829B106605C4FE8B189DB2E56C69615@mike> <51506A06-D2EE-4A0D-B92B-781662094A1C@eyeconomics.com> <0CCB8AB89D144E89872AF0D635E95497@mike> <2691B7B9-1F3C-403C-B4E8-5B82BED0E191@eyeconomics.com> <454BB1826E7B4F2BB3A68BE1DD86A756@video> <909D6DD7-404F-4BB3-B330-78B755FAB6DA@eyeconomics.com> <156DA5A48E51490284BC21D982A8FDAB@mike> <77310136-54C6-43F0-9923-E7810DD2736D@delong.com> <059E9D87D0D8420D8EAE18BF78F1FA88@video> <2802FCB9-1D0A-43AA-81BB-C3A93AAA7B45@delong.com> <5F1AB819-C436-42B8-9CE9-14CF74F5E385@arin.net> <9D6E8A5B-A7B4-40BC-960E-7B40640B3F90@arin.net> <4AD7C11ED3C74C2BAE247B9470662094@mike> <36D226BD-E507-487B-9B69-A5315854023C@delong.com> <8695009A81378E48879980039EEDAD289F033068@MAIL1.polartel.local> Message-ID: <7D7CCB5E-C28D-46BC-9D06-B164699C56B7@matthew.at> On May 24, 2011, at 5:17 PM, Kevin Kargel wrote: > > > All the talk of ARIN controlling netblocks and routing is really obfuscation. If anyone doesn't like the way ARIN manages the database all they really have to do is maintain their own database. (Sounds simple, doesn't it..) It would be easier if ARIN bulk transfer rules didn't prohibit bulk transfer for this purpose. > So long as you and all the parties you wish to communicate with are using the same database life is good. > > What I suspect would be the biggest problem if a network did maintain their own database is that when their non-aligned peers discover they are using a different database then those non-aligned peers will stop accepting routing advertisements from the network. This has happened to networks in the past when network operators have had incorrect routes in their tables whether by intention or typo. To keep life simple and reduce my workload I choose to be represented in the ARIN database and follow the rules that go along with that. This will get much much more interesting if/when RPKI happens. And even more interesting if some jurisdiction requires the use of it. Matthew Kaufman From mike at nationwideinc.com Tue May 24 11:39:28 2011 From: mike at nationwideinc.com (Mike Burns) Date: Tue, 24 May 2011 11:39:28 -0400 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate References: <15F92ECD-2BE5-48F2-B65A-9A9D39B98F54@delong.com><0829B106605C4FE8B189DB2E5 4E8-5B82BED0E191@eyeconomics.com><454BB1826E7B4F2BB3A68BE1DD86A756@video> <909D6DD7-404F-4BB3-B330-78B755FAB6DA@eyeconomics.com><156DA5A48E51490284BC 21D982A8FDAB@mike><77310136-54C6-43F0-9923-E7810DD2736D@delong.com><059E9D87D0D8420D8EAE18BF78F1FA88@video><2802FCB9-1D0A-43AA- 81BB-C3A93AAA7B45@delong.com><5F1AB819-C436-42B8-9CE9-14CF74F5E385@arin.net><9D6E8A5B-A7B4-40BC-960E-7B40640B3F90@arin.net> <4AD7C11ED3C74C2BAE247B9470662094@mike><36D226BD-E507-487B-9B69-A5315854023C@mac.com> <0A627BD19D7340F49F296028DDDF82FE@mike> <3B9D6DF5-14E3-4086-BE2D-EF89562EDC7C@arin.net> Message-ID: <736BE84CE646460D8D82CD2CE93679F6@mike> Mike - Efficient use of address space is a reasonable match to the goal of "conservation", but what do you propose with respect to the goal of "aggregation" under such a model? /John Hi John, First, I don't see the evidence in the transfers we are aware of that aggregation was much of a consideration. And especially with the ARIN staff decision to apply the single aggregate terminology to the needs requirement and not to the actual transfer. Second, it is up to the network operators, who bear the costs of disaggregation, to make the decisions as to what is an acceptable prefix. In the long run, we will have disaggregation either way. The minimal generally acceptable prefix length may vary, and I think the price of netblocks near the border of the minimum size would reflect their potential routability. I'm unclear on how current transfer policy affects aggregation, can you help? If I qualified for a /20 but I found two suppliers with /21s, would I be allowed to make two purchases under the current policy? If I qualified for a /20 but I found one suppler with two /21s, would I be allowed to make the purchase of both netblocks under current policy? If there was a /20 available on STLS but the price was higher, would I be required to make the purchase as a single block? If it were cheaper to buy some /24s, and some /23s to make up a /20 in aggregate would that be okay? I guess the goal of aggregation can be viewed as applying to the free pool, and with allocations from a free pool it is possible to dole out the most efficient large blocks that would serve the goal of aggregation. But in the trading market, regardless of needs requirements, how can we maintain that goal when we don't have the big block of free pool addresses to carve allocations out of? I think aggregation is out of our hands now, and up to the network operator community to deal with. Regards, Mike From springer at inlandnet.com Tue May 24 12:03:22 2011 From: springer at inlandnet.com (John Springer) Date: Tue, 24 May 2011 09:03:22 -0700 (PDT) Subject: [arin-ppml] ARIN-prop-151 Limiting Needs Requirements for IPv4 Transfers In-Reply-To: References: <0CCB8AB89D144E89872AF0D635E95497@mike> <2691B7B9-1F3C-403C-B4E8-5B82BED0E191@eyeconomics.com> <454BB1826E7B4F2BB3A68BE1DD86A756@video> <909D6DD7-404F-4BB3-B330-78B755FAB6DA@eyeconomics.com> <156DA5A48E51490284BC21D982A8FDAB@mike> <77310136-54C6-43F0-9923-E7810DD2736D@delong.com> <059E9D87D0D8420D8EAE18BF78F1FA88@video> <2802FCB9-1D0A-43AA-81BB-C3A93AAA7B45@delong.com> <5F1AB819-C436-42B8-9CE9-14CF74F5E385@arin.net> <9D6E8A5B-A7B4-40BC-960E-7B40640B3F90@arin.net> <4AD7C11ED3C74C2BAE247B9470662094@mike> <36D226BD-E507-487B-9B69-A5315854023C! @delong.com> <0A627BD19D7340F49F296028DDDF82FE@mike> Message-ID: <20110524074051.K34494@mail.inlandnet.com> Hi Mike, Owen, ARIN, Still not ready to declare for or against, but leaning... OK, not for it exactly as written, but I do think this needs to be discussed from now to and through Philadelphia. At base, the policy change under discussion is to remove needs assessment from the process of transfering IPV4 addresses. There is another clause dealing with the section 12 review that I am going to skip in this post. The major idea SEEMS to be that the author feels that the invisible hand of the free market will do a better (fairer?) job of fitting available addresses to their best destination in the context of a marketplace. A marketplace. So far, the traffic in IP addresses has taken place in an orderly manner, not unlike a harvest does. An RIR gets a crop of addresses in, in a quasi-seasonal manner and they enter into a regulated, distribution situation. Take a number, no pushing, no shoving, parcel 'em all out, rinse repeat. Not a modern NAFTA, WTO market, granted, but predictable. But the harvest has failed in IPV4 numbers and we seem to be faced with famine, first in APNIC and then in the rest of the RIRs. Oh sure, we can't eat IP numbers and they are endlessly recyclable and we have a new food supply ready and waiting, blah, blah, blah. But it will resemble a famine, nontheless. And there are a number of features about famines, with which mankind has wide experience. There will be a black market, there will be hoarding. There will be haves trying to help havenots. There will be bandits, both individual and collective. There will be bad behavior and good behavior. There will be starvation and gluttony and all the inefficiencies that man can devise. But in every famine with which I am familiar, I've never heard of the body that had control of the grain throwing open the doors of the granaries and declaring, "Everything goes to the highest bidder! First come, first served! Get it today before it's gone!" Someone said something earlier about an invisible fist. That's what this sounds like. But wait!, I can hear someone saying. We're not talking about the central granary here. We just want some well capitalized benefactors to be able to come in and buy up all the unused grain from folks who don't need it anyway, hang onto it and sell it at a modest profit later when the price really goes up. What's wrong with that? They're taking all the risk, right? RIGHT? Pay no attention to those guys with the pick handles by the gates. They're just keeping order. And Mom and Pop and their little windfall and all the rest. Now, I recognize that the author is not proposing throwing open the doors precisely. And the horrors of IPV4 starvation don't have the same punch as say, Biafra. But in this orderly marketplace, the needs basis is the door, and we should think long and hard before taking it out of the jamb and setting it aside. And, quelle surprise, that seems to be exactly what we are doing. Looking toward Philadelphia, I think I might be in favor of dealing (so to speak) with the question of needs and the market as its own solo subject, without the section 12 stuff. This would allow for the appropriate recapitulation of the development of modern economics since the ancien regime, in this context. :) My thanks to the participants in this important discussion. John Springer From owen at delong.com Tue May 24 12:37:18 2011 From: owen at delong.com (Owen DeLong) Date: Tue, 24 May 2011 09:37:18 -0700 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate In-Reply-To: <7D7CCB5E-C28D-46BC-9D06-B164699C56B7@matthew.at> References: <4DCFDB5C64DD4F738B65AB82D36B629D@mike> <15F92ECD-2BE5-48F2-B65A-9A9D39B98F54@delong.com> <0829B106605C4FE8B189DB2E56C69615@mike> <51506A06-D2EE-4A0D-B92B-781662094A1C@eyeconomics.com> <0CCB8AB89D144E89872AF0D635E95497@mike> <2691B7B9-1F3C-403C-B4E8-5B82BED0E191@eyeconomics.com> <454BB1826E7B4F2BB3A68BE1DD86A756@video> <909D6DD7-404F-4BB3-B330-78B755FAB6DA@eyeconomics.com> <156DA5A48E51490284BC21D982A8FDAB@mike> <77310136-54C6-43F0-9923-E7810DD2736D@delong.com> <059E9D87D0D8420D8EAE18BF78F1FA88@video> <2802FCB9-1D0A-43AA-81BB-C3A93AAA7B45@delong.com> <5F1AB819-C436-42B8-9CE9-14CF74F5E385@arin.net> <9D6E8A5B-A7B4-40BC-960E-7B40640B3F90@arin.net> <4AD7C11ED3C74C2BAE247B9470662094@mike>! <36D226BD-E507-487B-9B69-A5315854023C@delong.com> <8695009A81378E48879980039EEDAD289F033068@MAIL1.polartel.local> <7D7CCB5E-C28D-46BC-9D06-B164699C56B7@matthew.at> Message-ID: <065A911A-39C6-4A1A-B492-B1CCD2DCD665@delong.com> On May 24, 2011, at 8:31 AM, Matthew Kaufman wrote: > > On May 24, 2011, at 5:17 PM, Kevin Kargel wrote: > >> >> >> All the talk of ARIN controlling netblocks and routing is really obfuscation. If anyone doesn't like the way ARIN manages the database all they really have to do is maintain their own database. (Sounds simple, doesn't it..) > > It would be easier if ARIN bulk transfer rules didn't prohibit bulk transfer for this purpose. > Ah, but, why should ARIN make it easier to hijack the community's resources, which is the net effect of allowing such bulk transfers? >> So long as you and all the parties you wish to communicate with are using the same database life is good. >> >> What I suspect would be the biggest problem if a network did maintain their own database is that when their non-aligned peers discover they are using a different database then those non-aligned peers will stop accepting routing advertisements from the network. This has happened to networks in the past when network operators have had incorrect routes in their tables whether by intention or typo. To keep life simple and reduce my workload I choose to be represented in the ARIN database and follow the rules that go along with that. > > This will get much much more interesting if/when RPKI happens. And even more interesting if some jurisdiction requires the use of it. > Yep. I don't expect that to be at all likely, and, there's nothing dictating which trust anchors any given network does or does not accept even when they do RPKI. Owen > Matthew Kaufman > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From mike at nationwideinc.com Tue May 24 12:55:08 2011 From: mike at nationwideinc.com (Mike Burns) Date: Tue, 24 May 2011 12:55:08 -0400 Subject: [arin-ppml] ARIN-prop-151 Limiting Needs Requirements for IPv4 Transfers References: <0CCB8AB89D144E89872AF0D635E95497@mike> <2691B7B9-1F3C-403C-B4E8-5B82BED0E191@eyeconomics.com> <454BB1826E7B4F2BB3A68BE1DD86A756@video> <909D6DD7-404F-4BB3-B330-78B755FAB6DA@eyeconomics.com> <156DA5A48E51490284BC21D982A8FDAB@mike> <77310136-54C6-43F0-9923-E7810DD2736D@delong.com> <059E9D87D0D8420D8EAE18BF78F1FA88@video> <2802FCB9-1D0A-43AA-81BB-C3A93AAA7B45@delong.com> <5F1AB819-C436-42B8-9CE9-14CF74F5E385@arin.net> <9D6E8A5B-A7B4-40BC-960E-7B40640B3F90@arin.net> <4AD7C11ED3C74C2BAE247B9470662094@mike> <36D226BD-E507-487B-9B69-A5315854023C! @delong.com> <0A627BD19D7340F49F296028DDDF82FE@mike> <20110524074051.K34494@mail.inlandnet.com> Message-ID: > Hi Mike, Owen, ARIN, > > Still not ready to declare for or against, but leaning... OK, not for it > exactly as written, but I do think this needs to be discussed from now to > and through Philadelphia. > > At base, the policy change under discussion is to remove needs assessment > from the process of transfering IPV4 addresses. There is another clause > dealing with the section 12 review that I am going to skip in this post. > The major idea SEEMS to be that the author feels that the invisible hand > of the free market will do a better (fairer?) job of fitting available > addresses to their best destination in the context of a marketplace. > > A marketplace. > > So far, the traffic in IP addresses has taken place in an orderly manner, > not unlike a harvest does. An RIR gets a crop of addresses in, in a > quasi-seasonal manner and they enter into a regulated, distribution > situation. Take a number, no pushing, no shoving, parcel 'em all out, > rinse repeat. Not a modern NAFTA, WTO market, granted, but predictable. > > But the harvest has failed in IPV4 numbers and we seem to be faced with > famine, first in APNIC and then in the rest of the RIRs. Oh sure, we can't > eat IP numbers and they are endlessly recyclable and we have a new food > supply ready and waiting, blah, blah, blah. But it will resemble a famine, > nontheless. And there are a number of features about famines, with which > mankind has wide experience. There will be a black market, there will be > hoarding. There will be haves trying to help havenots. There will be > bandits, both individual and collective. There will be bad behavior and > good behavior. There will be starvation and gluttony and all the > inefficiencies that man can devise. > > But in every famine with which I am familiar, I've never heard of the body > that had control of the grain throwing open the doors of the granaries and > declaring, "Everything goes to the highest bidder! First come, first > served! Get it today before it's gone!" Someone said something earlier > about an invisible fist. That's what this sounds like. > > But wait!, I can hear someone saying. We're not talking about the central > granary here. We just want some well capitalized benefactors to be able to > come in and buy up all the unused grain from folks who don't need it > anyway, hang onto it and sell it at a modest profit later when the price > really goes up. What's wrong with that? They're taking all the risk, > right? RIGHT? Pay no attention to those guys with the pick handles by the > gates. They're just keeping order. > > And Mom and Pop and their little windfall and all the rest. > > Now, I recognize that the author is not proposing throwing open the doors > precisely. And the horrors of IPV4 starvation don't have the same punch as > say, Biafra. But in this orderly marketplace, the needs basis is the door, > and we should think long and hard before taking it out of the jamb and > setting it aside. And, quelle surprise, that seems to be exactly what we > are doing. > > Looking toward Philadelphia, I think I might be in favor of dealing (so to > speak) with the question of needs and the market as its own solo subject, > without the section 12 stuff. This would allow for the appropriate > recapitulation of the development of modern economics since the ancien > regime, in this context. :) > > My thanks to the participants in this important discussion. > > John Springer Thanks for your input, John, Please understand that although I do think addresses will be more efficiently used in the future when they have monetary value than currently, or in the past, when they didn't, I am not making this the crux of my proposal. What I am saying is that needs testing was a requirement for free pool allocations, and that is why we imposed needs tests on applicants for address space. Actually some kind of constraint was required, as it always is, for the distribution of unpriced but valuable resources. So the stewards chose needs-testing of applicants, with the idea that we want allocated addresses put into actual and efficient use, and this method of constraint would serve those goals. Now, however, we do not need needs-testing to drive addresses towards efficient use, because we are allowing them to be priced, and that is a fundamental difference. Maybe I haven't made clear why we didn't just give addresses out first-come-first-served, from the free pool. I have referred to the Tragedy of the Commons, and if you are unfamiliar with this concept, you can google it. Basically, the British used to refuse villagers from allowing their sheep to graze on the commons, a publicly held land usually at the center of the village. Then it was decided to open the Commons to the villagers for this purpose. Since the villagers would have had to pay any other landholder to allow their sheeps to graze on their land, all the villagers herded their sheep on to the freely available Commons. Whereupon the sheep ate all the grass and destroyed the Commons. Whether this actually happened is immaterial, it instructs us as to what happens when a valuable commodity is not contrained by price. The commodity is almost immediately consumed. So the stewards were wise in choosing to constrain allocation by some mechanism. They could have chosen price, as the government does when it auctions spectrum, for example. I think there would have been many problems with that choice. But instead they chose a needs-test, which to me was an excellent choice. Now, however, whether with or without my policy, the stewards at ARIN chose to allow individuals to buy and sell addresses, and thus for addresses to have a price. The price is the constraint on wasteful use that the needs test used to be. So maintaining the needs test is not a requirement for stewardship, as other forces outside of our control will work towards the same ends of efficient usage that the needs test was designed to incentivize. I think some stewards have gotten it into their heads that their role is to decide the best, or at least better, use of addresses, but I argue that was never a goal of stewardship. Now on to your analogy. There is simply no granary in control of the addresses. The food has already been allocated from the granary into the hands of a bunch of individuals. In our case, tens of thousands of individual ARIN allocants. (I just made up tens of thousands maybe it's just thousands.) But in your famine scenario, they would be selling, buying, stealing, and donating to each other. Unless and until some third party came in to say they could not engage in certain of these transactions. Which would make that third party a lightning rod for conflict, and a very potential source of corruption. I know that you are presupposing that some speculator or hoarder will come and buy up everybody's available grain. So your objection comes down to fear of speculators and hoarders, once again. What about the /12 limit in my proposal, specifically designed to prevent speculation and hoarding? In your analogy, I guess you could say that everybody had a limit to the size of their storage silo, which would prevent them from hoarding. Thanks for your thoughtful consideration of the matter, though, and your belief that this is a proper topic for the AC to discuss. Regards, Mike From cengel at conxeo.com Tue May 24 13:09:38 2011 From: cengel at conxeo.com (Chris Engel) Date: Tue, 24 May 2011 13:09:38 -0400 Subject: [arin-ppml] ARIN-prop-151 Limiting Needs Requirements for IPv4 Transfers In-Reply-To: <20110524074051.K34494@mail.inlandnet.com> References: <0CCB8AB89D144E89872AF0D635E95497@mike> <2691B7B9-1F3C-403C-B4E8-5B82BED0E191@eyeconomics.com> <454BB1826E7B4F2BB3A68BE1DD86A756@video> <909D6DD7-404F-4BB3-B330-78B755FAB6DA@eyeconomics.com> <156DA5A48E51490284BC21D982A8FDAB@mike> <77310136-54C6-43F0-9923-E7810DD2736D@delong.com> <059E9D87D0D8420D8EAE18BF78F1FA88@video> <2802FCB9-1D0A-43AA-81BB-C3A93AAA7B45@delong.com> <5F1AB819-C436-42B8-9CE9-14CF74F5E385@arin.net> <9D6E8A5B-A7B4-40BC-960E-7B40640B3F90@arin.net> <4AD7C11ED3C74C2BAE247B9470662094@mike> <36D226BD-E507-487B-9B69-A5315854023C! @delong.com> <0A627BD19D7340F49F296028DDDF82FE@mike> <20110524074051.K34494@mail.inlandnet.com> Message-ID: > IPv4 Transfers > > Hi Mike, Owen, ARIN, > > Still not ready to declare for or against, but leaning... OK, not for it > exactly as written, but I do think this needs to be discussed from now to > and through Philadelphia. > > At base, the policy change under discussion is to remove needs assessment > from the process of transfering IPV4 addresses. There is another clause > dealing with the section 12 review that I am going to skip in this post. > The major idea SEEMS to be that the author feels that the invisible hand > of the free market will do a better (fairer?) job of fitting available > addresses to their best destination in the context of a marketplace. > > A marketplace. > > So far, the traffic in IP addresses has taken place in an orderly manner, > not unlike a harvest does. An RIR gets a crop of addresses in, in a > quasi-seasonal manner and they enter into a regulated, distribution > situation. Take a number, no pushing, no shoving, parcel 'em all out, > rinse repeat. Not a modern NAFTA, WTO market, granted, but predictable. > > But the harvest has failed in IPV4 numbers and we seem to be faced with > famine, first in APNIC and then in the rest of the RIRs. Oh sure, we can't > eat IP numbers and they are endlessly recyclable and we have a new food > supply ready and waiting, blah, blah, blah. But it will resemble a famine, > nontheless. And there are a number of features about famines, with which > mankind has wide experience. There will be a black market, there will be > hoarding. There will be haves trying to help havenots. There will be > bandits, both individual and collective. There will be bad behavior and > good behavior. There will be starvation and gluttony and all the > inefficiencies that man can devise. > > But in every famine with which I am familiar, I've never heard of the body > that had control of the grain throwing open the doors of the granaries and > declaring, "Everything goes to the highest bidder! First come, first > served! Get it today before it's gone!" Someone said something earlier > about an invisible fist. That's what this sounds like. > > But wait!, I can hear someone saying. We're not talking about the central > granary here. We just want some well capitalized benefactors to be able to > come in and buy up all the unused grain from folks who don't need it > anyway, hang onto it and sell it at a modest profit later when the price > really goes up. What's wrong with that? They're taking all the risk, > right? RIGHT? Pay no attention to those guys with the pick handles by the > gates. They're just keeping order. > > And Mom and Pop and their little windfall and all the rest. > > Now, I recognize that the author is not proposing throwing open the doors > precisely. And the horrors of IPV4 starvation don't have the same punch as > say, Biafra. But in this orderly marketplace, the needs basis is the door, > and we should think long and hard before taking it out of the jamb and > setting it aside. And, quelle surprise, that seems to be exactly what we > are doing. > > Looking toward Philadelphia, I think I might be in favor of dealing (so to > speak) with the question of needs and the market as its own solo subject, > without the section 12 stuff. This would allow for the appropriate > recapitulation of the development of modern economics since the ancien > regime, in this context. :) > > My thanks to the participants in this important discussion. > > John Springer John, it's an interesting analogy but I'm not sure it's entirely apt in this case. In the case of grain, you have a resource that has a definite physical form that control can be exerted over.... and in the case of a grain regulator, you have someone that has the capability to exercise real control (i.e. the guys with pipe-handles) over the distribution of resource. That doesn't really seem to be so much the case here. Maybe if ARIN were an actual government agency with teeth to enforce things the case would be a bit different. The reality is that ARIN seems to act more like a parking attendant in the grain distribution center parking lot. ARIN gives direction (absent contracts without any real ability to enforce such direction) about who should pull into what spot and when. Pretty much people choose to listen to the parking attendant because it benefits them to have a nice orderly process without the risk of accidents to go get their grain. That all works great as long as there are plenty of parking spaces and plenty of grain and most people who want a reasonable amount of grain have a reasonable expectation of getting it. Not sure how well such a system holds up once the grain and parking spaces fill up and the grain becomes more valuable then getting your car dinged. More pointedly I'm not sure ARIN's methodology for determining who should get the grain is fairer, more equitable or more efficient then simply letting the current resource holder and those who want such resources work out the details amongst themselves (i.e. cash, usually). Speaking only for myself, I get a little uncomfortable when a private organization places itself in charge of something as important as number resource allocation (in a scarcity market) and is going to allocate on the basis of what it considers as "need". If that is a function that is really desirable then, I personally, would be more comfortable with an actual governmental agency filling that role. At least, theoretically (in the US at least) they are accountable to whole of the voting public and are subject to some level of transparency through things like FIA requests. Christopher Engel (Speaking only for myself) From owen at delong.com Tue May 24 13:25:33 2011 From: owen at delong.com (Owen DeLong) Date: Tue, 24 May 2011 10:25:33 -0700 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate In-Reply-To: <736BE84CE646460D8D82CD2CE93679F6@mike> References: <15F92ECD-2BE5-48F2-B65A-9A9D39B98F54@delong.com><0829B106605C4FE8B189DB2E5 4E8-5B82BED0E191@eyeconomics.com><454BB1826E7B4F2BB3A68BE1DD86A756@video> <909D6DD7-404F-4BB3-B330-78B755FAB6DA@eyeconomics.com><156DA5A48E51490284BC 21D982A8FDAB@mike><77310136-54C6-43F0-9923-E7810DD2736D@delong.com><059E9D87D0D8420D8EAE18BF78F1FA88@video><2802FCB9-1D0A-43AA- 81BB-C3A93AAA7B45@delong.com><5F1AB819-C436-42B8-9CE9-14CF74F5E385@arin.net><9D6E8A5B-A7B4-40BC-960E-7B40640B3F90@arin.net> <4AD7C11ED3C74C2BAE247B9470662094@mike><36D226BD-E507-487B-9B69-A5315854023C@mac.com> <0A627BD19D7340F49F296028DDDF82FE@mike> <3B9D6DF5-14E3-4086-BE2D-EF89562EDC7C@arin.net> <736BE84CE646460D8D82CD! 2CE93679F6@mike> Message-ID: <9EBF637F-5032-44A8-A91D-F88662E5427A@delong.com> On May 24, 2011, at 8:39 AM, Mike Burns wrote: > > Mike - > > Efficient use of address space is a reasonable match to the goal of > "conservation", but what do you propose with respect to the goal of > "aggregation" under such a model? > > /John > > > > > Hi John, > > First, I don't see the evidence in the transfers we are aware of that aggregation was much of a consideration. > And especially with the ARIN staff decision to apply the single aggregate terminology to the needs requirement and not to the actual transfer. > It was somewhat, but, yes, that mistake in the transfer policy should get rectified and I'll be submitting a proposal to do that shortly. > Second, it is up to the network operators, who bear the costs of disaggregation, to make the decisions as to what is an acceptable prefix. > In the long run, we will have disaggregation either way. > This may be true, but, I see no reason for policy to favor increasing it or accelerating it. > The minimal generally acceptable prefix length may vary, and I think the price of netblocks near the border of the minimum size would reflect their potential routability. > This is less clear and it is even less clear how the market could or would keep pace of knowledge as this shifted. > I'm unclear on how current transfer policy affects aggregation, can you help? > There are some protections, but, the syntax error in the positioning of the single aggregate clause definitely reduces the intended effectiveness. It was intended to (single aggregate clause), but, that turned into an accidental no-op due to improper syntactic positioning. I'll be submitting policy to fix this shortly. > If I qualified for a /20 but I found two suppliers with /21s, would I be allowed to make two purchases under the current policy? Not entirely clear. You would definitely be able to purchase a pair of /21s from the same supplier in the same transaction, but, I think that the current policy still prohibits other permutations. The single aggregate clause getting moved to its correct position will hopefully close the existing loophole. > If I qualified for a /20 but I found one suppler with two /21s, would I be allowed to make the purchase of both netblocks under current policy? Yes, so long as you did it in a single transaction. > If there was a /20 available on STLS but the price was higher, would I be required to make the purchase as a single block? Due to a syntax error in the current policy, no. > If it were cheaper to buy some /24s, and some /23s to make up a /20 in aggregate would that be okay? Under current policy, only if you got them all from one supplier in a single transaction. > > I guess the goal of aggregation can be viewed as applying to the free pool, and with allocations from a free pool it is possible to dole out the most efficient large blocks that would serve the goal of aggregation. But in the trading market, regardless of needs requirements, how can we maintain that goal when we don't have the big block of free pool addresses to carve allocations out of? > By correcting the syntax error in 8.3 > I think aggregation is out of our hands now, and up to the network operator community to deal with. > I think this is true to some extent, but, not completely and there are certainly things we can do that would accelerate disaggregation. I would argue that removing needs basis is likely to do so, for example. Owen From owen at delong.com Tue May 24 13:37:08 2011 From: owen at delong.com (Owen DeLong) Date: Tue, 24 May 2011 10:37:08 -0700 Subject: [arin-ppml] ARIN-prop-151 Limiting Needs Requirements for IPv4 Transfers In-Reply-To: <20110524074051.K34494@mail.inlandnet.com> References: <0CCB8AB89D144E89872AF0D635E95497@mike> <2691B7B9-1F3C-403C-B4E8-5B82BED0E191@eyeconomics.com> <454BB1826E7B4F2BB3A68BE1DD86A756@video> <909D6DD7-404F-4BB3-B330-78B755FAB6DA@eyeconomics.com> <156DA5A48E51490284BC21D982A8FDAB@mike> <77310136-54C6-43F0-9923-E7810DD2736D@delong.com> <059E9D87D0D8420D8EAE18BF78F1FA88@video> <2802FCB9-1D0A-43AA-81BB-C3A93AAA7B45@delong.com> <5F1AB819-C436-42B8-9CE9-14CF74F5E385@arin.net> <9D6E8A5B-A7B4-40BC-960E-7B40640B3F90@arin.net> <4AD7C11ED3C74C2BAE247B9470662094@mike> <36D226BD-E507-487B-9B69-A5315854023C! @delong.com> <0A627BD19D7340F49F296028DDDF82FE@mike> <20110524074051.K34494@mail.inlandnet.com> Message-ID: <819F4E7F-B3D6-4675-B4A1-4361147B09AD@delong.com> I don't think you can handle it independent of the section 12 stuff, because if you don't include provisions in section 12, the transfer immediately becomes subject to a utilization audit which could result in reclamation of the space based on the non-existent need. So, for the policy to have effect, the section 12 issues have to be addressed. Owen On May 24, 2011, at 9:03 AM, John Springer wrote: > Hi Mike, Owen, ARIN, > > Still not ready to declare for or against, but leaning... OK, not for it exactly as written, but I do think this needs to be discussed from now to and through Philadelphia. > > At base, the policy change under discussion is to remove needs assessment from the process of transfering IPV4 addresses. There is another clause dealing with the section 12 review that I am going to skip in this post. The major idea SEEMS to be that the author feels that the invisible hand of the free market will do a better (fairer?) job of fitting available addresses to their best destination in the context of a marketplace. > > A marketplace. > > So far, the traffic in IP addresses has taken place in an orderly manner, not unlike a harvest does. An RIR gets a crop of addresses in, in a quasi-seasonal manner and they enter into a regulated, distribution situation. Take a number, no pushing, no shoving, parcel 'em all out, rinse repeat. Not a modern NAFTA, WTO market, granted, but predictable. > > But the harvest has failed in IPV4 numbers and we seem to be faced with famine, first in APNIC and then in the rest of the RIRs. Oh sure, we can't eat IP numbers and they are endlessly recyclable and we have a new food supply ready and waiting, blah, blah, blah. But it will resemble a famine, nontheless. And there are a number of features about famines, with which mankind has wide experience. There will be a black market, there will be hoarding. There will be haves trying to help havenots. There will be bandits, both individual and collective. There will be bad behavior and good behavior. There will be starvation and gluttony and all the inefficiencies that man can devise. > > But in every famine with which I am familiar, I've never heard of the body that had control of the grain throwing open the doors of the granaries and declaring, "Everything goes to the highest bidder! First come, first served! Get it today before it's gone!" Someone said something earlier about an invisible fist. That's what this sounds like. > > But wait!, I can hear someone saying. We're not talking about the central granary here. We just want some well capitalized benefactors to be able to come in and buy up all the unused grain from folks who don't need it anyway, hang onto it and sell it at a modest profit later when the price really goes up. What's wrong with that? They're taking all the risk, right? RIGHT? Pay no attention to those guys with the pick handles by the gates. They're just keeping order. > > And Mom and Pop and their little windfall and all the rest. > > Now, I recognize that the author is not proposing throwing open the doors precisely. And the horrors of IPV4 starvation don't have the same punch as say, Biafra. But in this orderly marketplace, the needs basis is the door, and we should think long and hard before taking it out of the jamb and setting it aside. And, quelle surprise, that seems to be exactly what we are doing. > > Looking toward Philadelphia, I think I might be in favor of dealing (so to speak) with the question of needs and the market as its own solo subject, without the section 12 stuff. This would allow for the appropriate > recapitulation of the development of modern economics since the ancien regime, in this context. :) > > My thanks to the participants in this important discussion. > > John Springer From springer at inlandnet.com Tue May 24 14:02:57 2011 From: springer at inlandnet.com (John Springer) Date: Tue, 24 May 2011 11:02:57 -0700 (PDT) Subject: [arin-ppml] ARIN-prop-151 Limiting Needs Requirements for IPv4 Transfers In-Reply-To: References: <454BB1826E7B4F2BB3A68BE1DD86A756@video> <909D6DD7-404F-4BB3-B330-78B755FAB6DA@eyeconomics.com> <156DA5A48E51490284BC21D982A8FDAB@mike> <77310136-54C6-43F0-9923-E7810DD2736D@delong.com> <059E9D87D0D8420D8EAE18BF78F1FA88@video> <2802FCB9-1D0A-43AA-81BB-C3A93AAA7B45@delong.com> <5F1AB819-C436-42B8-9CE9-14CF74F5E385@arin.net> <9D6E8A5B-A7B4-40BC-960E-7B40640B3F90@arin.net> <4AD7C11ED3C74C2BAE247B9470662094@mike> <36D226BD-E507-487B-9B69-A5315854023C! @delong.com> <0A627BD19D7340F49F296028DDDF82FE@mike> <20110524074051.K34494@mail.inlandnet.com> Message-ID: <20110524101850.N34494@mail.inlandnet.com> Hi Mike, On Tue, 24 May 2011, Mike Burns wrote: > > Please understand that although I do think addresses will be more efficiently > used in the future when they have monetary value than currently, or in the > past, when they didn't, I am not making this the crux of my proposal. OK, how about the idea of making this a one crux proposal? > What I am saying is that needs testing was a requirement for free pool > allocations, and that is why we imposed needs tests on applicants for address > space. Actually some kind of constraint was required, as it always is, for > the distribution of unpriced but valuable resources. One thing that I have seen a lot of lately is asserting that something happened _for_a_particular_reason_, and then using that _reason_ as a launching pad. WRT the above, I agree that needs testing was imposed, but saying that it was a requirement, which is why we imposed it seems circular. > So the stewards chose needs-testing of applicants, with the idea that we want > allocated addresses put into actual and efficient use, and this method of > constraint would serve those goals. Check. > Now, however, we do not need needs-testing to drive addresses towards > efficient use, because we are allowing them to be priced, and that is a > fundamental difference. Not so much check. We could restate this in reverse with equally valid effect: We have needs testing to drive addresses toward efficient use, so we don't need to be allowing them to be priced. > Maybe I haven't made clear why we didn't just give addresses out > first-come-first-served, from the free pool. > I have referred to the Tragedy of the Commons, and if you are unfamiliar > with this concept, you can google it. Thanks for the tip! > Basically, the British used to refuse villagers from allowing their sheep to > graze on the commons, a publicly held land usually at the center of the > village. > Then it was decided to open the Commons to the villagers for this purpose. > Since the villagers would have had to pay any other landholder to allow their > sheeps to graze on their land, all the villagers herded their sheep on to the > freely available Commons. > > Whereupon the sheep ate all the grass and destroyed the Commons. Man, that does not sound good. > Whether this actually happened is immaterial, it instructs us as to what > happens when a valuable commodity is not contrained by price. The commodity > is almost immediately consumed. > > So the stewards were wise in choosing to constrain allocation by some > mechanism. They could have chosen price, as the government does when it > auctions spectrum, for example. > I think there would have been many problems with that choice. > But instead they chose a needs-test, which to me was an excellent choice. The ARIN stewards, I presume, not the sheep stewards. > Now, however, whether with or without my policy, the stewards at ARIN chose > to allow individuals to buy and sell addresses, and thus for addresses to > have a price. Don't think so. I know you keep saying so, but IIRC the STLS allows the right to transfer the right to use, presumably, but not necessarily for a consideration. Seems to me there is a lot of care exercised to be sure that the phrasing does not give even the appearance of sell and buy. > The price is the constraint on wasteful use that the needs test used to be. Would be. Maybe. Among other things. Happy to talk about it. > So maintaining the needs test is not a requirement for stewardship, as other > forces outside of our control will work towards the same ends of efficient > usage that the needs test was designed to incentivize. Maybe not, if we were absolutely determined that at all costs the needs test had to go. But we have not so determined. You propose that this is desireable and are experiencing some discussion. Not everyone agrees. > I think some stewards have gotten it into their heads that their role is to > decide the best, or at least better, use of addresses, but I argue that was > never a goal of stewardship. Here again: some stewards _MAY_ be considering that it might be better if existing uses of addresses be prefered to proposed and possibly undesirable uses. I would think YOU have to justify convincingly the advantages of previously prohibited practices, not just assert repeatedly those advantages. > Now on to your analogy. I don't intend to spend a lot of time defending the details of the analogy/illustration/metaphor/whositz. > There is simply no granary in control of the addresses. The food has already > been allocated from the granary into the hands of a bunch of individuals. > In our case, tens of thousands of individual ARIN allocants. (I just made up > tens of thousands maybe it's just thousands.) > > But in your famine scenario, they would be selling, buying, stealing, and > donating to each other. > > Unless and until some third party came in to say they could not engage in > certain of these transactions. > > Which would make that third party a lightning rod for conflict, and a very > potential source of corruption. > > I know that you are presupposing that some speculator or hoarder will come > and buy up everybody's available grain. > So your objection comes down to fear of speculators and hoarders, once again. That's me, crippled with fear, repeatedly. OTOH, I also think speculators and hoarders may be odious. My outward appearances to such can be similar. > What about the /12 limit in my proposal, specifically designed to prevent > speculation and hoarding? > In your analogy, I guess you could say that everybody had a limit to the size > of their storage silo, which would prevent them from hoarding. No opinion so far, seems kinda large. > Thanks for your thoughtful consideration of the matter, though, and your > belief that this is a proper topic for the AC to discuss. Pleasure, likewise, John Springer > Regards, > Mike > > > From carlosm3011 at gmail.com Tue May 24 14:22:23 2011 From: carlosm3011 at gmail.com (Carlos Martinez-Cagnazzo) Date: Tue, 24 May 2011 13:22:23 -0500 Subject: [arin-ppml] HIJACKED: AS18466, courtesy of Global Crossing (AS3549) In-Reply-To: <30315.1305887154@tristatelogic.com> References: <30315.1305887154@tristatelogic.com> Message-ID: Hello Ronald, I do work for LACNIC i'm really late in my NANOG followups > P.P.S. ?Although I have previously bemoaned ARIN's lack of agressivness in > reclaiming abandoned ASNs and IP blocks that have been hijacked, I feel > compelled to note that at least they (ARIN) do have a proccess in place > for doing so, i.e. when and if they are motivated in that direction. > I have it on good authority however that LACNIC does not even have an > established process for reclaiming abandoned number resources. ?Given > that the problem of hijacked number resources, rather than disappearing, > is in fact accelerating, over time, I do believe that it would behove > LACNIC and other RiRs to develop processes for reclaiming abandoned > resources, in particular when and where it becomes evident that these > resources have been hijacked. I would like to get in touch with the good authority you mention as he/she seems to be quite misinformed. LACNIC has, and has applied in the past, policies and procedures for resource recovery due to abandonment and other issues. The original resource recovery policy is LACNIC-2009-06 and the English text can be found here: http://www.lacnic.net/en/politicas/manual7-1.html You can also find the list of recovered prefixes and ASNs here http://www.lacnic.net/en/registro/revocacion.html I am not the expert on how the recovery process actually works but I can get you or the person who mentioned this alleged lack of process to you in touch with the staff who actually do work with resource recovery. regards Carlos -- -- ========================= Carlos M. Martinez-Cagnazzo http://www.labs.lacnic.net ========================= From ikiris at gmail.com Tue May 24 14:32:22 2011 From: ikiris at gmail.com (Blake Dunlap) Date: Tue, 24 May 2011 13:32:22 -0500 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate In-Reply-To: <9EBF637F-5032-44A8-A91D-F88662E5427A@delong.com> References: <15F92ECD-2BE5-48F2-B65A-9A9D39B98F54@delong.com> <454BB1826E7B4F2BB3A68BE1DD86A756@video> <909D6DD7-404F-4BB3-B330-78B755FAB6DA@eyeconomics.com> <77310136-54C6-43F0-9923-E7810DD2736D@delong.com> <059E9D87D0D8420D8EAE18BF78F1FA88@video> <5F1AB819-C436-42B8-9CE9-14CF74F5E385@arin.net> <9D6E8A5B-A7B4-40BC-960E-7B40640B3F90@arin.net> <4AD7C11ED3C74C2BAE247B9470662094@mike> <36D226BD-E507-487B-9B69-A5315854023C@mac.com> <0A627BD19D7340F49F296028DDDF82FE@mike> <3B9D6DF5-14E3-4086-BE2D-EF89562EDC7C@arin.net> <736BE84CE646460D8D82CD2CE93679F6@mike> <9EBF637F-5032-44A8-A91D-F88662E5427A@delong.com> Message-ID: I hate to say it, but on aggregation issue, I do agree with Mike, in that the anti-disaggregation clause likely makes it fairly difficult to find space. I do think the clause could work, but I think without a full single market front, it makes it extremely difficult to pair need with availability for exact sized blocks. Are we just leaving it to the market to create such service and until then, its on the needers to find their exact aggregated blocks? -Blake -------------- next part -------------- An HTML attachment was scrubbed... URL: From info at arin.net Tue May 24 15:04:53 2011 From: info at arin.net (ARIN) Date: Tue, 24 May 2011 15:04:53 -0400 Subject: [arin-ppml] Advisory Council Meeting Results - May 2011 Message-ID: <4DDC0155.6000501@arin.net> In accordance with the ARIN Policy Development Process the ARIN Advisory Council (AC) held a meeting on 19 May 2011 and made decisions about several draft policies and proposals. The AC recommended the following draft policies to the ARIN Board for adoption: ARIN-2011-3: Better IPv6 Allocations for ISPs (revised) ARIN-2011-4: Reserved Pool for Critical Infrastructure ARIN-2011-5: Shared Transition Space for IPv4 Address Extension ARIN-2011-6: Returned IPv4 Addresses ARIN-2011-3 was revised. The renumbering requirement in 6.5.7 was removed. This was an oversight; it was something that was discussed before and during Last Call. The following draft policy remains on the AC's docket (motions to send to last call and to abandon were unsuccessful): ARIN-2011-1: Globally Coordinated Transfer Policy The AC selected the following proposal as a draft policy for adoption discussion online and at the ARIN XXVIII Public Policy Meeting in Philadelphia in October. The draft policy will be posted shortly to the PPML. ARIN-prop-126 Compliance Requirement The AC accepted the following proposals on to the AC's docket for development and evaluation: ARIN-prop-140 Business Failure Clarification ARIN-prop-141 Combined M&A and Specified Transfers ARIN-prop-144 Remove Single Aggregate requirement from Specified Transfer ARIN-prop-146 Clarify Justified Need for Transfers ARIN-prop-147 Set Transfer Need to 24 months and Clarify Exception The AC abandoned the following proposal: ARIN-prop-139 No reassignment without network service ARIN-prop-142 Define RSA ARIN-prop-143 Clarify Specified Transfer RSA Requirement ARIN-prop-145 STLS Listing Immunity The AC chose to abandon prop-139 because the AC determined that there was a significant lack of support in the community based on its observations of the public policy mailing list. Reasons for the lack of support expressed on PPML included the perception that the problems addressed by the proposal are not a significant issue in the ARIN region, that it would disallow activity generally seen as beneficial, that such restrictions would be beyond ARIN's scope, and that the restriction may be difficult to enforce. The author of the proposal also suggested abandonment which further underscored the AC's conclusion. The AC abandoned prop-142 because the majority of the AC felt that the RSA is an adjunct document to the NRPM and its definition should not reside in policy. The Advisory Council of ARIN abandoned prop-143: Clarify Specified Transfer RSA Requirement. The AC believes that the content and terms of contracts between ARIN and holders of address space is an operational and legal issue. Prescribing that content is not an appropriate function of the ARIN Policy Development Process. The proper avenue for input regrading such issues is the ARIN Consultation and Suggestion Process (ACSP). The AC chose to abandon prop-145 because the AC agreed with ARIN staff that this is an issue for the terms of service for the STLS and as such is outside the scope of the PDP and NRPM. The AC also believes that except in cases of fraud, it is unlikely that ARIN staff would forcibly revoke resources that have already been approved to be on the STLS. The AC advises the community to use the ACSP if they would like to provide ARIN input on the terms of service for the STLS or the L/RSA. The AC thanks the authors and the community for their continuing effort and contributions to these and all other policy considerations. The AC abandoned proposals 139, 142, 143 and 144. Anyone dissatisfied with these decisions may initiate a petition. The petition to advance these proposals 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 24 15:10:11 2011 From: info at arin.net (ARIN) Date: Tue, 24 May 2011 15:10:11 -0400 Subject: [arin-ppml] Draft Policy 2011-7 Compliance Requirement Message-ID: <4DDC0293.4020104@arin.net> Draft Policy ARIN-2011-7 Compliance Requirement On 19 May 2011 the ARIN Advisory Council (AC) selected "Returned IPv4 Addresses" as a draft policy for adoption discussion on the PPML and at the Public Policy Meeting in San Juan, Puerto Rico in April. The draft was developed by the AC from policy proposal "ARIN-prop-126 Compliance Requirement." Per the Policy Development Process the AC submitted text to ARIN for a staff and legal assessment prior to its selection as a draft policy. Below the draft policy is the ARIN staff and legal assessment, followed by the text that was submitted by the AC. Note that the AC revised the draft policy text after they received the assessment from staff. Draft Policy ARIN-2011-7 is below and can be found at: https://www.arin.net/policy/proposals/2011_7.html You are encouraged to discuss Draft Policy 2011-7 on the PPML prior to the October Public Policy Meeting. Both the discussion on the list and at the meeting will be used by the ARIN Advisory Council to determine the community consensus for adopting this as policy. The ARIN Policy Development Process can be found at: https://www.arin.net/policy/pdp.html Draft Policies and Proposals under discussion can be found at: https://www.arin.net/policy/proposals/index.html Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## Draft Policy ARIN-2011-7 Compliance Requirement Date/version: 24 May 2011 Policy statement: Resource Review Update the following NRPM Sections: 12.4 - Update to: Organizations found by ARIN to be out of compliance with current ARIN policy shall be required to update reassignment information or return resources as needed to bring them into (or reasonably close to) compliance 1. The degree to which an organization may remain out of compliance shall be based on the reasonable judgment of the ARIN staff and shall balance all facts known, including the organization's utilization rate, available address pool, and other factors as appropriate so as to avoid forcing returns which will result in near-term additional requests or unnecessary route de-aggregation. 2. To the extent possible, entire blocks should be returned. Partial address blocks shall be returned in such a way that the portion retained will comprise a single aggregate block. (leave 12.5 as is) 12.6 - Update to: Except in cases of fraud, an organization shall be given a minimum of thirty (30) days to respond. If an organization does not respond within those thirty (30) days, ARIN may cease providing reverse DNS services to that organization. If progress of resource returns or record corrections is not visible within sixty (60) days after correspondence with ARIN began, ARIN will cease providing reverse DNS services for the resources in question. At any time after ninety (90) days have passed, ARIN may initiate resource revocation as allowed in paragraph 12.5. ARIN shall negotiate a longer term with the organization if ARIN believes the organization is working in good faith to substantially restore compliance and has a valid need for additional time to renumber out of the affected blocks. Rationale: This version addresses several staff and legal concerns with the original text of this policy by clarifying the language and making it more concrete. To date the community has not documented or firmly established use of an effective enforcement mechanism. This policy will support current policy and compel those who are allocated ARIN resources to maintain the proper WHOIS records in accordance with ARIN NRPM. While it is recognized this is not an absolute solution to ensure compliance, it is the best method under current ARIN policies. Timetable for implementation: Immediate ##### This is an assessment of the proposal as originally submitted by the AC. The AC subsequently revised the proposal/draft policy text (see current version above). STAFF ASSESSMENT Proposal: Compliance Requirement (ARIN-prop-126) Policy Version (Date): 11 January 2011 Date of Assessment: 28 January 2011 1. Proposal Summary (Staff Understanding) This policy requires ARIN staff to not only identify customers who are out of compliance with policy, but to withhold services for those who fail to come into compliance within a designated time. Staff is to contact customers who are out of compliance with policy and give them 30 days to respond to our contact and to demonstrate they've begun to take corrective measures within 60 days. If either of these criteria is not met, the policy instructs staff to cease providing reverse DNS services to the customer or to begin reclamation efforts. 2. Comments A. ARIN Staff Comments ? The policy says either "take away reverse" or "reclaim the numbers". It would be helpful to staff if there was clear guidance as to when revocation was to be used over reverse dns removal. Without clear guidance, staff would implement this in such a way that reverse dns removal would be used as the first step of the enforcement, and revocation of the resource as the final step when an organization is unable to come into compliance within a defined time period. ? The term ?materially out of compliance? is not well defined anywhere within this policy. Without additional criteria, staff will continue to interpret this term somewhat liberally, and to apply it at our discretion using our best judgment and consideration of existing factors. Only those organizations that we deem to be significantly in violation of existing policy will be flagged for further review and audit. B. ARIN General Counsel This policy has significant legal implications. It needs to be carefully edited to remove unnecessary ambiguities that might require enforcement when it should be discretionary and to avoid giving those ?enforced against? arguments that will require case-by-case adjudication. For example, the first line of the policy at 12.4 uses ?materiality? as a standard. I strongly recommend against such a standard, as anyone who is treated adversely will argue their ?noncompliance? is ?not material.? If lack of compliance is the issue, it must be ?black or white? as a review matter to protect against such drafting problems. If you believe noncompliance with a limited number of policies is a better approach, you can define such a set rather than overall compliance. Second, the ?requested or required? (emphasis added) language is conceptually quite different ? one is ?a request,? the other ?a command.? They must be separated if an escalation from ?requested? to ?required? is intended. Third, a similar drafting problem appears in 12.6 where ?fraud? (a bad and intentional thing) is equated to ?violations of policy? which could be trivial and not intended. Overall, if the policy was enacted as is, the risk of legal issues being thrust upon ARIN is unattractive and unwise. Counsel respectfully suggests a thorough rewrite of the draft to remove these and other issues of concern. 3. Resource Impact This policy would have moderate resource impact from an implementation aspect. It is estimated that implementation could occur within 6 - 9 months after ratification by the ARIN Board of Trustees. The implementation of this policy will require new software tools to track these newly defined deadlines. Additionally, there will likely be a significant increase in time and workload for the RS team as the potential for a significant increase in resource audits due to non-compliance with IPv6 reassignment requirements is great. This may even require additional personnel, although it is too early to tell right now. The following would be needed in order to implement: ? Updated guidelines and website documentation ? Staff training ? Software tools would need to be developed to track the 30 and 60-day deadlines. 4. Proposal Text ARIN-prop-126 Policy statement: Resource Review Update the following NRPM Sections: 12.4 Update to: Organizations found by ARIN to be materially out of compliance with current ARIN policy shall be requested or required to return resources or update reassignment information as needed to bring them into (or reasonably close to) compliance. 12.5 Update to: If the organization does not voluntarily return resources or update reassignment information as requested, ARIN will cease providing reverse DNS services and/or revoke any resources issued by ARIN as required to bring the organization into overall compliance. ARIN shall follow the same guidelines for revocation that are required for voluntary return in the previous paragraph. 12.6 Update to: Except in cases of fraud, or violations of policy, an organization shall be given a minimum (30) days to respond. Progress of record(s) correction(s) must be visible within (60) days after correspondence with ARIN began or ARIN will start proceeding with removal of DNS services and/or resources issued by ARIN. ARIN shall negotiate a longer term with the organization if ARIN believes the organization is working in good faith to substantially restore compliance and has a valid need for additional time to renumber out of the affected blocks. Rationale: To date the community has not documented or firmly established use of an effective enforcement mechanism. This policy will support current policy and compel those who are allocated ARIN resources to maintain the proper WHOIS records in accordance with ARIN NRPM. While it is recognized this is not an absolute solution to ensure compliance, it is the best method under current ARIN policies. From dogwallah at gmail.com Tue May 24 15:45:44 2011 From: dogwallah at gmail.com (McTim) Date: Tue, 24 May 2011 22:45:44 +0300 Subject: [arin-ppml] ARIN-prop-151 Limiting Needs Requirements for IPv4 Transfers In-Reply-To: References: <0CCB8AB89D144E89872AF0D635E95497@mike> <2691B7B9-1F3C-403C-B4E8-5B82BED0E191@eyeconomics.com> <454BB1826E7B4F2BB3A68BE1DD86A756@video> <909D6DD7-404F-4BB3-B330-78B755FAB6DA@eyeconomics.com> <156DA5A48E51490284BC21D982A8FDAB@mike> <77310136-54C6-43F0-9923-E7810DD2736D@delong.com> <059E9D87D0D8420D8EAE18BF78F1FA88@video> <2802FCB9-1D0A-43AA-81BB-C3A93AAA7B45@delong.com> <5F1AB819-C436-42B8-9CE9-14CF74F5E385@arin.net> <9D6E8A5B-A7B4-40BC-960E-7B40640B3F90@arin.net> <4AD7C11ED3C74C2BAE247B9470662094@mike> <0A627BD19D7340F49F296028DDDF82FE@mike> <20110524074051.K34494@mail.inlandnet.com> Message-ID: On Tue, May 24, 2011 at 7:55 PM, Mike Burns wrote: > > So the stewards chose needs-testing of applicants, with the idea that we > want allocated addresses put into actual and efficient use, and this method > of constraint would serve those goals. It will still serve those goals (admirably IMO) even when the costs go up. Allocations have always cost money in a "market". The "market" (as in the place to go to when you need something) has in recent years been your friendly RIR. > > Now, however, we do not need needs-testing to drive addresses towards > efficient use, because we are allowing them to be priced, and that is a > fundamental difference. Priced higher (probably) you mean. I contend that "needs-testing" is still a useful mechanism even when the RIR has nothing left to allocate or assign. -- Cheers, McTim "A name indicates what we seek. An address indicates where it is. A route indicates how we get there."? Jon Postel From mike at nationwideinc.com Tue May 24 16:11:45 2011 From: mike at nationwideinc.com (Mike Burns) Date: Tue, 24 May 2011 16:11:45 -0400 Subject: [arin-ppml] ARIN-prop-151 Limiting Needs Requirements for IPv4 Transfers In-Reply-To: <0EF360E766F94AD88D3D56AA3C568CE5@mike> References: <0EF360E766F94AD88D3D56AA3C568CE5@mike> Message-ID: <20110524201152.8AA0D213643@smtp2.arin.net> Hi John, >>Hi Mike, >> >>On Tue, 24 May 2011, Mike Burns wrote: >> >> >>> >>>Please understand that although I do think addresses will be more >>>efficiently used in the future when they have monetary value than >>>currently, or in the past, when they didn't, I am not making this >>>the crux of my proposal. >> >>OK, how about the idea of making this a one crux proposal? >> >>>What I am saying is that needs testing was a requirement for free >>>pool allocations, and that is why we imposed needs tests on >>>applicants for address space. Actually some kind of constraint was >>>required, as it always is, for the distribution of unpriced but >>>valuable resources. >> >>One thing that I have seen a lot of lately is asserting that >>something happened _for_a_particular_reason_, and then using that >>_reason_ as a launching pad. WRT the above, I agree that needs >>testing was imposed, but saying that it was a requirement, which is >>why we imposed it seems circular. I have tried to show that having some constraint was an absolute minimum requirement, and that a needs-based justification was the steward's softest touch which would meet the goals of conservation and aggregation. >>>So the stewards chose needs-testing of applicants, with the idea >>>that we want allocated addresses put into actual and efficient >>>use, and this method of constraint would serve those goals. >> >>Check. >> >>>Now, however, we do not need needs-testing to drive addresses >>>towards efficient use, because we are allowing them to be priced, >>>and that is a fundamental difference. >> >>Not so much check. We could restate this in reverse with equally >>valid effect: We have needs testing to drive addresses toward >>efficient use, so we don't need to be allowing them to be priced. You could say exactly that. Indeed, we did have needs testing to drive addresses toward efficient use, so we did not need to price them. Except that only works for allocations from the free pool, and we have already decided to price them for transfers. My proposal is meant to be considered in an environment with priced addresses, like our current one. >>>Maybe I haven't made clear why we didn't just give addresses out >>>first-come-first-served, from the free pool. >>>I have referred to the Tragedy of the Commons, and if you are >>>unfamiliar with this concept, you can google it. >> >>Thanks for the tip! >> >>>Basically, the British used to refuse villagers from allowing >>>their sheep to graze on the commons, a publicly held land usually >>>at the center of the village. >>>Then it was decided to open the Commons to the villagers for this >>>purpose. Since the villagers would have had to pay any other >>>landholder to allow their sheeps to graze on their land, all the >>>villagers herded their sheep on to the freely available Commons. >>> >>>Whereupon the sheep ate all the grass and destroyed the Commons. >> >>Man, that does not sound good. >> >>>Whether this actually happened is immaterial, it instructs us as >>>to what happens when a valuable commodity is not contrained by >>>price. The commodity is almost immediately consumed. >>> >>>So the stewards were wise in choosing to constrain allocation by >>>some mechanism. They could have chosen price, as the government >>>does when it auctions spectrum, for example. >>>I think there would have been many problems with that choice. >>>But instead they chose a needs-test, which to me was an excellent choice. >> >>The ARIN stewards, I presume, not the sheep stewards. >> >>>Now, however, whether with or without my policy, the stewards at >>>ARIN chose to allow individuals to buy and sell addresses, and >>>thus for addresses to have a price. >> >>Don't think so. I know you keep saying so, but IIRC the STLS allows >>the right to transfer the right to use, presumably, but not >>necessarily for a consideration. Seems to me there is a lot of care >>exercised to be sure that the phrasing does not give even the >>appearance of sell and buy. I agree the text looks like the tortured work of a group nearly evenly split between allowing transfers for money and not allowing them. Yes, clearly there is no requirement for payment for transfers. But we already have a $7.5 million dollar example of an ARIN-blessed 8.3 transfer. Which I take to mean that we are already in the trading-for-money world. >>>The price is the constraint on wasteful use that the needs test used to be. >> >>Would be. Maybe. Among other things. Happy to talk about it. OK, my assertion is that holding other conditions constant, raising the price of a commodity leads to more efficient use of it. Like, I figure that there is less left uneaten on the plate at Ruth's Chris than there is at Sizzlers, in general, because people don't like to waste expensive things. (There must have been some psychological test run at some point to test my hypothesis, I will see if I can find one.) (And I suppose the taste of a Ruth's Chris steak is not constant with the taste of a Sizzlers steak.) >>>So maintaining the needs test is not a requirement for >>>stewardship, as other forces outside of our control will work >>>towards the same ends of efficient usage that the needs test was >>>designed to incentivize. >> >>Maybe not, if we were absolutely determined that at all costs the >>needs test had to go. But we have not so determined. You propose >>that this is desireable and are experiencing some discussion. Not >>everyone agrees. I guess I should say if you accept the general notion that increased value leads to decreased waste, then address space will trend towards meeting the goal of conservation as it obtains monetary value. >>>I think some stewards have gotten it into their heads that their >>>role is to decide the best, or at least better, use of addresses, >>>but I argue that was never a goal of stewardship. >> >>Here again: some stewards _MAY_ be considering that it might be >>better if existing uses of addresses be prefered to proposed and >>possibly undesirable uses. I would think YOU have to justify >>convincingly the advantages of previously prohibited practices, not >>just assert repeatedly those advantages. Yes, I agree the proposer of a policy change has the burden of having to justifiably convince others before any change should be effected. >>>Now on to your analogy. >> >>I don't intend to spend a lot of time defending the details of the >>analogy/illustration/metaphor/whositz. >> >>>There is simply no granary in control of the addresses. The food >>>has already been allocated from the granary into the hands of a >>>bunch of individuals. >>>In our case, tens of thousands of individual ARIN allocants. (I >>>just made up tens of thousands maybe it's just thousands.) >>> >>>But in your famine scenario, they would be selling, buying, >>>stealing, and donating to each other. >>> >>>Unless and until some third party came in to say they could not >>>engage in certain of these transactions. >>> >>>Which would make that third party a lightning rod for conflict, >>>and a very potential source of corruption. >>> >>>I know that you are presupposing that some speculator or hoarder >>>will come and buy up everybody's available grain. >>>So your objection comes down to fear of speculators and hoarders, >>>once again. >> >>That's me, crippled with fear, repeatedly. OTOH, I also think >>speculators and hoarders may be odious. My outward appearances to >>such can be similar. It's just that the same basic objection, speculation, seems to be presented in many ways. I have tried to illustrate the inherent risks which would disincentivize speculation in this market. >>>What about the /12 limit in my proposal, specifically designed to >>>prevent speculation and hoarding? >>>In your analogy, I guess you could say that everybody had a limit >>>to the size of their storage silo, which would prevent them from hoarding. >> >>No opinion so far, seems kinda large. The /12 is open for negotiation, but I think it seems too small to hope to corner a market to the point you could affect price. But I suppose that depends on how large and vibrant a market we expect. >>>Thanks for your thoughtful consideration of the matter, though, >>>and your belief that this is a proper topic for the AC to discuss. >> >>Pleasure, likewise, >> >>John Springer >> >>>Regards, >>>Mike >>> >>> Regards and thanks for replying to the right Subject line, Mike From owen at delong.com Tue May 24 16:12:04 2011 From: owen at delong.com (Owen DeLong) Date: Tue, 24 May 2011 13:12:04 -0700 Subject: [arin-ppml] ARIN-prop-151 Limiting Needs Requirements for IPv4 Transfers In-Reply-To: <20110524101850.N34494@mail.inlandnet.com> References: <454BB1826E7B4F2BB3A68BE1DD86A756@video> <909D6DD7-404F-4BB3-B330-78B755FAB6DA@eyeconomics.com> <156DA5A48E51490284BC21D982A8FDAB@mike> <77310136-54C6-43F0-9923-E7810DD2736D@delong.com> <059E9D87D0D8420D8EAE18BF78F1FA88@video> <2802FCB9-1D0A-43AA-81BB-C3A93AAA7B45@delong.com> <5F1AB819-C436-42B8-9CE9-14CF74F5E385@arin.net> <9D6E8A5B-A7B4-40BC-960E-7B40640B3F90@arin.net> <4AD7C11ED3C74C2BAE247B9470662094@mike> <36D226BD-E507-487B-9B69-A5315854023C! @delong.com> <0A627BD19D7340F49F296028DDDF82FE@mike> <20110524074051.K34494@mail.inlandnet.com> <20110524101850.N34494@mail.inlandnet.com> Message-ID: On May 24, 2011, at 11:02 AM, John Springer wrote: > Hi Mike, > > On Tue, 24 May 2011, Mike Burns wrote: > > >> >> Please understand that although I do think addresses will be more efficiently used in the future when they have monetary value than currently, or in the past, when they didn't, I am not making this the crux of my proposal. > > OK, how about the idea of making this a one crux proposal? > LoL >> What I am saying is that needs testing was a requirement for free pool allocations, and that is why we imposed needs tests on applicants for address space. Actually some kind of constraint was required, as it always is, for the distribution of unpriced but valuable resources. > > One thing that I have seen a lot of lately is asserting that something happened _for_a_particular_reason_, and then using that _reason_ as a launching pad. WRT the above, I agree that needs testing was imposed, but saying that it was a requirement, which is why we imposed it seems circular. >> >> Now, however, whether with or without my policy, the stewards at ARIN chose to allow individuals to buy and sell addresses, and thus for addresses to have a price. > > Don't think so. I know you keep saying so, but IIRC the STLS allows the right to transfer the right to use, presumably, but not necessarily for a consideration. Seems to me there is a lot of care exercised to be sure that the phrasing does not give even the appearance of sell and buy. > Indeed we were very careful not to include buying or selling and not to involve ARIN in any financial side-deal that may or may not accompany the transfer. >> The price is the constraint on wasteful use that the needs test used to be. > > Would be. Maybe. Among other things. Happy to talk about it. > I believe that this is not the case. I believe that price, to the extent that it enters into directed transfers serves as a motivator to make addresses available for (more) efficient use, but, does not actually drive efficient use. There are enough obvious cases where inefficient use would be of financial benefit to the (potential) resource holder that price alone cannot possibly drive efficient usage and thus, the stewards, wisely (IMHO) proposed and the community accepted a policy that preserved needs-basis and still allowed directed transfers with the possibility that price may or may not be involved as determined by the individual parties to the transfer. >> So maintaining the needs test is not a requirement for stewardship, as other forces outside of our control will work towards the same ends of efficient usage that the needs test was designed to incentivize. > > Maybe not, if we were absolutely determined that at all costs the needs test had to go. But we have not so determined. You propose that this is desireable and are experiencing some discussion. Not everyone agrees. > Indeed, I believe that Mike's assertion here is far from proven and rather inaccurate. I agree that with market forces, forces out of our control will work towards SOME ends. I do not believe that there is anything to show that the ends will necessarily be any form of efficient usage, let alone the SAME ends of efficient usage that the needs test was designed to incentivize. The question here is whether there is any advantage to the community at large from a free-for-all in the transfer process vs. a transfer process where the recipient is still governed by needs-basis. Absent some clear benefit, I fail to see a reason to make such a radical change to policy. So far, no clear benefit has been shown, but, many negatives have been presented. (Admittedly, there is some disagreement about whether certain negatives are actually benefits). >> I think some stewards have gotten it into their heads that their role is to decide the best, or at least better, use of addresses, but I argue that was never a goal of stewardship. > > Here again: some stewards _MAY_ be considering that it might be better if existing uses of addresses be prefered to proposed and possibly undesirable uses. I would think YOU have to justify convincingly the advantages of previously prohibited practices, not just assert repeatedly those advantages. > I don't think that is the case at all. Certainly I don't believe that my role on the AC is to make any such determination. However, I do think that restricting the consumption of addresses to those with justified need instead of opening it up entirely to those with capital and no other basis will lead to a net reduction in the efficient utilization (which you have claimed is a valid goal) of the address space while simultaneously increasing costs and reducing availability. Given such an outcome being the likely result of your policy, I cannot see how the goal of efficient utilization can possibly be served. Given the other likely results (increased and accelerated disaggregation, anti-competitive tactics, etc.), I believe that the proposal, if enacted, could be quite damaging to the community as a whole. As such, given little or no demonstrable benefit and significant probable downsides and costs, how could I responsibly consider this good policy? Owen From owen at delong.com Tue May 24 16:29:35 2011 From: owen at delong.com (Owen DeLong) Date: Tue, 24 May 2011 13:29:35 -0700 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate In-Reply-To: References: <15F92ECD-2BE5-48F2-B65A-9A9D39B98F54@delong.com> <454BB1826E7B4F2BB3A68BE1DD86A756@video> <909D6DD7-404F-4BB3-B330-78B755FAB6DA@eyeconomics.com> <77310136-54C6-43F0-9923-E7810DD2736D@delong.com> <059E9D87D0D8420D8EAE18BF78F1FA88@video> <5F1AB819-C436-42B8-9CE9-14CF74F5E385@arin.net> <9D6E8A5B-A7B4-40BC-960E-7B40640B3F90@arin.net> <4AD7C11ED3C74C2BAE247B9470662094@mike> <36D226BD-E507-487B-9B69-A5315854023C@mac.com> <0A627BD19D7340F49F296028DDDF82FE@mike> <3B9D6DF5-14E3-4086-BE2D-EF89562EDC7C@arin.net> <736BE84CE646460D8D82CD2CE93679F6@mike> <9EBF637F-5032-44A8-A91D-F88662E5427A@delong.com> Message-ID: Wouldn't STLS facilitate this? What am I missing? Owen On May 24, 2011, at 11:32 AM, Blake Dunlap wrote: > I hate to say it, but on aggregation issue, I do agree with Mike, in that the anti-disaggregation clause likely makes it fairly difficult to find space. I do think the clause could work, but I think without a full single market front, it makes it extremely difficult to pair need with availability for exact sized blocks. Are we just leaving it to the market to create such service and until then, its on the needers to find their exact aggregated blocks? > > -Blake > _______________________________________________ > 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 Tue May 24 16:57:53 2011 From: scottleibrand at gmail.com (Scott Leibrand) Date: Tue, 24 May 2011 13:57:53 -0700 Subject: [arin-ppml] Advisory Council Meeting Results - May 2011 In-Reply-To: <4DDC0155.6000501@arin.net> References: <4DDC0155.6000501@arin.net> Message-ID: As some people seem to find it useful, I'll inject my own personal opinions on these inline... On Tue, May 24, 2011 at 12:04 PM, ARIN wrote: > In accordance with the ARIN Policy Development Process the ARIN Advisory > Council (AC) held a meeting on 19 May 2011 and made decisions about > several draft policies and proposals. > > The AC recommended the following draft policies to the ARIN Board for > adoption: > > ARIN-2011-3: Better IPv6 Allocations for ISPs (revised) > ARIN-2011-4: Reserved Pool for Critical Infrastructure > ARIN-2011-5: Shared Transition Space for IPv4 Address Extension > ARIN-2011-6: Returned IPv4 Addresses > > ARIN-2011-3 was revised. The renumbering requirement in 6.5.7 was > removed. This was an oversight; it was something that was discussed > before and during Last Call. > IMO these were all pretty clearly supported by the community during Last Call, and are generally good ideas. I won't rehash any of the arguments here. > The following draft policy remains on the AC's docket (motions to send > to last call and to abandon were unsuccessful): > > ARIN-2011-1: Globally Coordinated Transfer Policy > There was quite a bit of concern around whether this one is ready to go to Last Call (based on solid consensus for the idea in principle), or whether the revisions since Puerto Rico have sufficiently addressed the community (and AC members') concerns with the original text (for which there was only a slight plurality of support in San Juan). I was in the minority who thought this was ready for last call, but in light of these concerns, I've started up another thread to discuss further revisions to text to address the concerns. I would encourage everyone to participate in those discussions so we can address them promptly. I am of the opinion that this proposal is somewhat urgent, as the longer we go without an inter-RIR transfer policy, the more likely we are to see interregional transfers occurring outside the RIR system. > The AC selected the following proposal as a draft policy for adoption > discussion online and at the ARIN XXVIII Public Policy Meeting in > Philadelphia in October. The draft policy will be posted shortly to the > PPML. > > ARIN-prop-126 Compliance Requirement > It sounds like we're leaning towards removing the "ARIN must remove rDNS after 60 days" requirement. Other than that I think this one is ready to get its formal staff and legal review, and if nothing else comes up, to be discussed in Philly. The AC accepted the following proposals on to the AC's docket for > development and evaluation: > > ARIN-prop-140 Business Failure Clarification > ARIN-prop-141 Combined M&A and Specified Transfers > ARIN-prop-144 Remove Single Aggregate requirement from Specified Transfer > ARIN-prop-146 Clarify Justified Need for Transfers > ARIN-prop-147 Set Transfer Need to 24 months and Clarify Exception > I think all of these are worth discussing further, and am glad to see the author's revisions to address most of the issues identified with them thus far. > The AC abandoned the following proposal: > > ARIN-prop-139 No reassignment without network service > ARIN-prop-142 Define RSA > ARIN-prop-143 Clarify Specified Transfer RSA Requirement > ARIN-prop-145 STLS Listing Immunity > > The AC chose to abandon prop-139 because the AC determined that there > was a significant lack of support in the community based on its > observations of the public policy mailing list. Reasons for the lack of > support expressed on PPML included the perception that the problems > addressed by the proposal are not a significant issue in the ARIN > region, that it would disallow activity generally seen as beneficial, > that such restrictions would be beyond ARIN's scope, and that the > restriction may be difficult to enforce. The author of the proposal > also suggested abandonment which further underscored the AC's conclusion. > > The AC abandoned prop-142 because the majority of the AC felt that the > RSA is an adjunct document to the NRPM and its definition should not > reside in policy. > > The Advisory Council of ARIN abandoned prop-143: Clarify Specified > Transfer RSA Requirement. The AC believes that the content and terms of > contracts between ARIN and holders of address space is an operational > and legal issue. Prescribing that content is not an appropriate function > of the ARIN Policy Development Process. The proper avenue for input > regrading such issues is the ARIN Consultation and Suggestion Process > (ACSP). > > The AC chose to abandon prop-145 because the AC agreed with ARIN staff > that this is an issue for the terms of service for the STLS and as such > is outside the scope of the PDP and NRPM. The AC also believes that > except in cases of fraud, it is unlikely that ARIN staff would forcibly > revoke resources that have already been approved to be on the STLS. The > AC advises the community to use the ACSP if they would like to provide > ARIN input on the terms of service for the STLS or the L/RSA. > I think these summaries all speak fairly well for themselves, but if anyone has any questions about them I'll be happy to opine further. The AC thanks the authors and the community for their continuing effort > and contributions to these and all other policy considerations. > In particular, I think Matthew Kaufman deserves a special thanks for his recent contributions. -Scott > The AC abandoned proposals 139, 142, 143 and 144. Anyone dissatisfied > with these decisions may initiate a petition. The petition to advance > these proposals 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) > > > > > > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcurran at arin.net Tue May 24 17:28:58 2011 From: jcurran at arin.net (John Curran) Date: Tue, 24 May 2011 21:28:58 +0000 Subject: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate In-Reply-To: References: <15F92ECD-2BE5-48F2-B65A-9A9D39B98F54@delong.com> <454BB1826E7B4F2BB3A68BE1DD86A756@video> <909D6DD7-404F-4BB3-B330-78B755FAB6DA@eyeconomics.com> <77310136-54C6-43F0-9923-E7810DD2736D@delong.com> <059E9D87D0D8420D8EAE18BF78F1FA88@video> <5F1AB819-C436-42B8-9CE9-14CF74F5E385@arin.net> <9D6E8A5B-A7B4-40BC-960E-7B40640B3F90@arin.net> <4AD7C11ED3C74C2BAE247B9470662094@mike> <36D226BD-E507-487B-9B69-A5315854023C@mac.com> <0A627BD19D7340F49F296028DDDF82FE@mike> <3B9D6DF5-14E3-4086-BE2D-EF89562EDC7C@arin.net> <736BE84CE646460D8D82CD2CE93679F6@mike> <9EBF637F-5032-44A8-A91D-F88662E5427A@delong.com> Message-ID: <6F6DF8CB-6FFC-4C0D-9B04-1C1A805C5025@arin.net> On May 24, 2011, at 4:29 PM, Owen DeLong wrote: > Wouldn't STLS facilitate this? > > What am I missing? > > Owen > > On May 24, 2011, at 11:32 AM, Blake Dunlap wrote: > >> I hate to say it, but on aggregation issue, I do agree with Mike, in that the anti-disaggregation clause likely makes it fairly difficult to find space. I do think the clause could work, but I think without a full single market front, it makes it extremely difficult to pair need with availability for exact sized blocks. Are we just leaving it to the market to create such service and until then, its on the needers to find their exact aggregated blocks? >> >> -Blake Owen - I do not know the extent that the Specified Transfer Listing Service (STLS) will be utilized by parties looking for others with address space. It is presently available, and parties that have space, need space, or wish to match parties can all participate. (ARIN does not do any matching of parties, as that is a function that the industry appears quite capable of serving) To date, none of the 10 specified transfers that have occurred have made use of the STLS (to my knowledge). Of course, it is also true that ARIN still has IPv4 space generally available, so we likely have not seen the real start of the demand curve for such transfers, and the future may indeed hold much greater use of the specified transfer listing service In any case, if use of STLS is the expected mechanism to address specific policy side effects, then that should be made clear to the extent possible. Operationally, a disaggregation clause may require additional information to be requested and considered on the part of the buyer, with potential for additional uncertainty in a transfer. It may still be desirable by the community to have such a disaggregation clause, but the benefits provided should be carefully considered in light of potential consequences. FYI, /John John Curran President and CEO ARIN From kkargel at polartel.com Tue May 24 17:52:36 2011 From: kkargel at polartel.com (Kevin Kargel) Date: Tue, 24 May 2011 16:52:36 -0500 Subject: [arin-ppml] ARIN-prop-151 Limiting Needs Requirements for IPv4 Transfers In-Reply-To: <20110524201152.8AA0D213643@smtp2.arin.net> References: <0EF360E766F94AD88D3D56AA3C568CE5@mike> <20110524201152.8AA0D213643@smtp2.arin.net> Message-ID: <8695009A81378E48879980039EEDAD289F03306C@MAIL1.polartel.local> > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf Of Mike Burns > Sent: Tuesday, May 24, 2011 3:12 PM > To: arin-ppml at arin.net > Subject: Re: [arin-ppml] ARIN-prop-151 Limiting Needs Requirements for > IPv4 Transfers > Snippage to a single point... > > OK, my assertion is that holding other conditions constant, raising > the price of a commodity leads to more efficient use of it. > Like, I figure that there is less left uneaten on the plate at Ruth's > Chris than there is at Sizzlers, in general, because people don't > like to waste expensive things. > (There must have been some psychological test run at some point to > test my hypothesis, I will see if I can find one.) > (And I suppose the taste of a Ruth's Chris steak is not constant with > the taste of a Sizzlers steak.) > > I will argue that there is probably more waste at Ruth's Chris than there is at Sizzler, because the patrons at Ruth's have more money than they know what to do with and they are not concerned about waste. It is the poor folks at Sizzler who have saved up for a month to go out and have a half inch steak that are more likely to lick the plates clean and eat the potato skins. The rich folks will leave stuff on the plate to save room for that $16 chocolate sin cake and a $40 cognac. The same is what I think will happen with a non-needs based market. The big boys with huge budgets because of scale will have no problem with snapping up a few million dollars worth of netblocks and warehousing them because the netblocks are now a non-depreciating capital asset and buying them will not affect the bottom line on the balance sheet. The big boys will do this in part to make sure that nobody else can use them. In a non-needs based market IP's are a speculative investment, whether or not you actually use them. Another risk is that as in the game of Monopoly, the act of depriving your competitor from access to an asset can be more important even than owning the asset. It could well be worth a few million to deprive a competitor from resources they need to succeed. Kevin From mike at nationwideinc.com Tue May 24 20:25:14 2011 From: mike at nationwideinc.com (Mike Burns) Date: Tue, 24 May 2011 20:25:14 -0400 Subject: [arin-ppml] ARIN-prop-151 Limiting Needs Requirements for IPv4 Transfers References: <0EF360E766F94AD88D3D56AA3C568CE5@mike> <20110524201152.8AA0D213643@smtp2.arin.net> <8695009A81378E48879980039EEDAD289F03306C@MAIL1.polartel.local> Message-ID: <841FC7BFE0CC44A2A8D54F616B0814E6@video> Hi Kevin, But the big boys are limited to a /12 each. There's like 1000 times that much space allocated but unrouted. And if you are planning on buying addresses to keep your competitor from getting them, by definition you need to be at the end of the current pool of available addresses, and certain that no more will enter the pool. And when that happens, the price of addresses will go up, and more will enter the pool. OK, I should not have engaged in an analogy, I must have been hungry. Regards, Mike > Snippage to a single point... > > OK, my assertion is that holding other conditions constant, raising > the price of a commodity leads to more efficient use of it. > Like, I figure that there is less left uneaten on the plate at Ruth's > Chris than there is at Sizzlers, in general, because people don't > like to waste expensive things. > (There must have been some psychological test run at some point to > test my hypothesis, I will see if I can find one.) > (And I suppose the taste of a Ruth's Chris steak is not constant with > the taste of a Sizzlers steak.) > > I will argue that there is probably more waste at Ruth's Chris than there is at Sizzler, because the patrons at Ruth's have more money than they know what to do with and they are not concerned about waste. It is the poor folks at Sizzler who have saved up for a month to go out and have a half inch steak that are more likely to lick the plates clean and eat the potato skins. The rich folks will leave stuff on the plate to save room for that $16 chocolate sin cake and a $40 cognac. The same is what I think will happen with a non-needs based market. The big boys with huge budgets because of scale will have no problem with snapping up a few million dollars worth of netblocks and warehousing them because the netblocks are now a non-depreciating capital asset and buying them will not affect the bottom line on the balance sheet. The big boys will do this in part to make sure that nobody else can use them. In a non-needs based market IP's are a speculative investment, whether or not you actually use them. Another risk is that as in the game of Monopoly, the act of depriving your competitor from access to an asset can be more important even than owning the asset. It could well be worth a few million to deprive a competitor from resources they need to succeed. Kevin From mysidia at gmail.com Tue May 24 20:50:44 2011 From: mysidia at gmail.com (Jimmy Hess) Date: Tue, 24 May 2011 19:50:44 -0500 Subject: [arin-ppml] ARIN-prop-151 Limiting Needs Requirements for IPv4 Transfers In-Reply-To: <20110524201152.8AA0D213643@smtp2.arin.net> References: <0EF360E766F94AD88D3D56AA3C568CE5@mike> <20110524201152.8AA0D213643@smtp2.arin.net> Message-ID: On Tue, May 24, 2011 at 3:11 PM, Mike Burns wrote: [snip] > The /12 is open for negotiation, but I think it seems too small to hope to > corner a market to the point you could affect price. > But I suppose that depends on how large and vibrant a market we expect. /12 doesn't prevent hoarding; it just leads to inefficient hoarding. 16 shell organizations can hold a /8 for the real speculator.... one /12 at a time. If ARIN were to want to remove needs justification, and thereby throw the door open to speculators, Then, at that point, once ARIN's done that, they should encourage as much competition on the sell side as possible. One or two speculators with a /12, could lead to an IP address liquidity problem, if IPs are not coming up from other sources, which might result in a bidding war, and therefore, a high price per IP in response to a small number of transactions. If ARIN wants to waive needs justification but set limits, it should be _how long_ anyone can hold on to any specific IP addresses they don't need, more so than how many IP addresses they can hold on to. ARIN could also mitigate this by setting a price "per IP" that ARIN is willing to pay for addresses returned to ARIN. E.g. "Return 50% or more of a /16 or longer allocation, and get $0.001 per IP address." "Return 50% or more of a /8 or longer allocation and get $0.0005 per IP address" That could then help protect the liquidity of IP addresses, by encouraging more returns to the free pools. At some point, ARIN would probably need to stop handling the clearing of new IP addresses, using maintenance fees, and instead rely on third party "market makers" to hold IP addresses. ARIN could more efficiently cover their expenses by getting the _market value_ of IP addresses for new allocations. It doesn't make sense that you have a market in one corner and allow it to benefit certain third parties financially, and in the other corner have the community itself, still getting any free pool allocations under the old rules, and not benefitting from the "efficiency" introduced by having a market -- -JH From mysidia at gmail.com Tue May 24 21:04:56 2011 From: mysidia at gmail.com (Jimmy Hess) Date: Tue, 24 May 2011 20:04:56 -0500 Subject: [arin-ppml] ARIN-prop-151 Limiting Needs Requirements for IPv4 Transfers In-Reply-To: <841FC7BFE0CC44A2A8D54F616B0814E6@video> References: <0EF360E766F94AD88D3D56AA3C568CE5@mike> <20110524201152.8AA0D213643@smtp2.arin.net> <8695009A81378E48879980039EEDAD289F03306C@MAIL1.polartel.local> <841FC7BFE0CC44A2A8D54F616B0814E6@video> Message-ID: On Tue, May 24, 2011 at 7:25 PM, Mike Burns wrote: > And if you are planning on buying addresses to keep your competitor from > getting them, by definition you need to be at the end of the current pool of > available addresses, and certain that no more will enter the pool. Not necessarily. That depends on how many IPs the competitor needs, and how fast they will probably need them. Sometimes _delaying_ a competitor by a few months might be worth millions or hundreds of millions; it may undermine the competitor's product or any significant chance they had to get a foothold. > And when that happens, the price of addresses will go up, and more will > enter the pool. A win in two ways... (1) the victim competitor has to wait, maybe months for more addresses to come to market; this gives the aggressor a chance to get a bigger head start. (2) the aggressor competitor has effectively manipulated the market, by taking advantage of the limited size of the market, they have increased the price -- this means the victim competitor's price per IP address goes up. The large increase in IP address costs (depending how much), might derail the victim competitor's plans entirely -- if IP addresses are too expensive, their ROI might change from being excellent, to being so poor the project must be cancelled. > OK, I should not have engaged in an analogy, I must have been hungry. > > Regards, > Mike > -- -JH From springer at inlandnet.com Tue May 24 22:33:26 2011 From: springer at inlandnet.com (John Springer) Date: Tue, 24 May 2011 19:33:26 -0700 (PDT) Subject: [arin-ppml] ARIN-prop-151 Limiting Needs Requirements for IPv4 Transfers In-Reply-To: References: <0EF360E766F94AD88D3D56AA3C568CE5@mike> <20110524201152.8AA0D213643@smtp2.arin.net> <8695009A81378E48879980039EEDAD289F03306C@MAIL1.polartel.local> <841FC7BFE0CC44A2A8D54F616B0814E6@video> Message-ID: <20110524192001.C48569@mail.inlandnet.com> Hi Jimmy, I usually like to read and respond to posts in rough chron order, but I am kind of skipping to the front to respond to this post because you have hit on something pure here. Delay. Inline. On Tue, 24 May 2011, Jimmy Hess wrote: > On Tue, May 24, 2011 at 7:25 PM, Mike Burns wrote: > >> And if you are planning on buying addresses to keep your competitor from >> getting them, by definition you need to be at the end of the current pool of >> available addresses, and certain that no more will enter the pool. > > Not necessarily. That depends on how many IPs the competitor needs, > and how fast they will probably need them. > Sometimes _delaying_ a competitor by a few months might be worth > millions or hundreds of millions; > it may undermine the competitor's product or any significant chance > they had to get a foothold. > >> And when that happens, the price of addresses will go up, and more will >> enter the pool. > > A win in two ways... (1) the victim competitor has to wait, maybe > months for more addresses > to come to market; this gives the aggressor a chance to get a bigger > head start. > > (2) the aggressor competitor has effectively manipulated the market, > by taking advantage of > the limited size of the market, they have increased the price -- this > means the victim competitor's > price per IP address goes up. > > The large increase in IP address costs (depending how much), might > derail the victim competitor's > plans entirely -- if IP addresses are too expensive, their ROI > might change from being excellent, > to being so poor the project must be cancelled. Magnificent. I can see how this might be desirable to some. This does not seem to be currently possible except in end game positioning scenarios. I don't like the sound of it. Nice catch. John Springer >> OK, I should not have engaged in an analogy, I must have been hungry. >> >> Regards, >> Mike >> > > -- > -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 Tue May 24 22:46:39 2011 From: owen at delong.com (Owen DeLong) Date: Tue, 24 May 2011 19:46:39 -0700 Subject: [arin-ppml] ARIN-prop-151 Limiting Needs Requirements for IPv4 Transfers In-Reply-To: <841FC7BFE0CC44A2A8D54F616B0814E6@video> References: <0EF360E766F94AD88D3D56AA3C568CE5@mike> <20110524201152.8AA0D213643@smtp2.arin.net> <8695009A81378E48879980039EEDAD289F03306C@MAIL1.polartel.local> <841FC7BFE0CC44A2A8D54F616B0814E6@video> Message-ID: <515472D9-98F2-47AA-A714-21318B8689BD@delong.com> On May 24, 2011, at 5:25 PM, Mike Burns wrote: > Hi Kevin, > > But the big boys are limited to a /12 each. Uh, no, they're limited to a /12 per organization they create. > There's like 1000 times that much space allocated but unrouted. Unallocated != inefficiently used. I know you don't like hearing that, but, it remains a fact. > And if you are planning on buying addresses to keep your competitor from getting them, by definition you need to be at the end of the current pool of available addresses, and certain that no more will enter the pool. Or willing to continue buying as they continue to come on the market. > And when that happens, the price of addresses will go up, and more will enter the pool. > And the big boys will buy them, too. I'm not sure why you can't see this. > OK, I should not have engaged in an analogy, I must have been hungry. > LoL Owen > Regards, > Mike > > > >> > Snippage to a single point... >> >> OK, my assertion is that holding other conditions constant, raising >> the price of a commodity leads to more efficient use of it. >> Like, I figure that there is less left uneaten on the plate at Ruth's >> Chris than there is at Sizzlers, in general, because people don't >> like to waste expensive things. >> (There must have been some psychological test run at some point to >> test my hypothesis, I will see if I can find one.) >> (And I suppose the taste of a Ruth's Chris steak is not constant with >> the taste of a Sizzlers steak.) >> >> > I will argue that there is probably more waste at Ruth's Chris than there is at Sizzler, because the patrons at Ruth's have more money than they know what to do with and they are not concerned about waste. > It is the poor folks at Sizzler who have saved up for a month to go out and have a half inch steak that are more likely to lick the plates clean and eat the potato skins. > The rich folks will leave stuff on the plate to save room for that $16 chocolate sin cake and a $40 cognac. > > The same is what I think will happen with a non-needs based market. The big boys with huge budgets because of scale will have no problem with snapping up a few million dollars worth of netblocks and warehousing them because the netblocks are now a non-depreciating capital asset and buying them will not affect the bottom line on the balance sheet. The big boys will do this in part to make sure that nobody else can use them. In a non-needs based market IP's are a speculative investment, whether or not you actually use them. > > Another risk is that as in the game of Monopoly, the act of depriving your competitor from access to an asset can be more important even than owning the asset. It could well be worth a few million to deprive a competitor from resources they need to succeed. > > Kevin > > > > _______________________________________________ > 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 springer at inlandnet.com Tue May 24 23:34:36 2011 From: springer at inlandnet.com (John Springer) Date: Tue, 24 May 2011 20:34:36 -0700 (PDT) Subject: [arin-ppml] ARIN-prop-151 Limiting Needs Requirements for IPv4 Transfers In-Reply-To: <20110524201152.8AA0D213643@smtp2.arin.net> References: <0EF360E766F94AD88D3D56AA3C568CE5@mike> <20110524201152.8AA0D213643@smtp2.arin.net> Message-ID: <20110524195006.K48569@mail.inlandnet.com> Hi Mike, Brrrr, this is growing massive already. I'll try to edit judiciously. On Tue, 24 May 2011, Mike Burns wrote: >>> >>>> What I am saying is that needs testing was a requirement for free pool >>>> allocations, and that is why we imposed needs tests on applicants for >>>> address space. Actually some kind of constraint was required, as it >>>> always is, for the distribution of unpriced but valuable resources. >>> >>> One thing that I have seen a lot of lately is asserting that something >>> happened _for_a_particular_reason_, and then using that _reason_ as a >>> launching pad. WRT the above, I agree that needs testing was imposed, but >>> saying that it was a requirement, which is why we imposed it seems >>> circular. > > I have tried to show that having some constraint was an absolute minimum > requirement, and that a needs-based justification was the steward's softest > touch which would meet the goals of conservation and aggregation. Was and is. Needs basis remains despite suggestions that recent events have obliterated it. >>>> So the stewards chose needs-testing of applicants, with the idea that we >>>> want allocated addresses put into actual and efficient use, and this >>>> method of constraint would serve those goals. >>> >>> Check. >>> >>>> Now, however, we do not need needs-testing to drive addresses towards >>>> efficient use, because we are allowing them to be priced, and that is a >>>> fundamental difference. >>> >>> Not so much check. We could restate this in reverse with equally valid >>> effect: We have needs testing to drive addresses toward efficient use, so >>> we don't need to be allowing them to be priced. > > You could say exactly that. > Indeed, we did have needs testing to drive addresses toward efficient use, so > we did not need to price them. And we still do and we still don't. > Except that only works for allocations from the free pool, and we have > already decided to price them for transfers. Not proven and not you and me, surely! > My proposal is meant to be considered in an environment with priced > addresses, like our current one. The proposal is being considered in a place that Gibson called "a consensual hallucination". Statements like the above may or my not have less semantic content than you think here, at least yet. >>>> Tragedy of the Commons tip, cant delete that! >>>> Now, however, whether with or without my policy, the stewards at ARIN >>>> chose to allow individuals to buy and sell addresses, and thus for >>>> addresses to have a price. >>> >>> Don't think so. I know you keep saying so, but IIRC the STLS allows the >>> right to transfer the right to use, presumably, but not necessarily for a >>> consideration. Seems to me there is a lot of care exercised to be sure >>> that the phrasing does not give even the appearance of sell and buy. > > I agree the text looks like the tortured work of a group nearly evenly split > between allowing transfers for money and not allowing them. > Yes, clearly there is no requirement for payment for transfers. > But we already have a $7.5 million dollar example of an ARIN-blessed 8.3 > transfer. > Which I take to mean that we are already in the trading-for-money world. When did we leave? I thought I talked to you about drawing conclusions from the MS/NN deal. >>>> The price is the constraint on wasteful use that the needs test used to >>>> be. >>> >>> Would be. Maybe. Among other things. Happy to talk about it. > > OK, my assertion is that holding other conditions constant, raising the price > of a commodity leads to more efficient use of it. > Like, I figure that there is less left uneaten on the plate at Ruth's Chris > than there is at Sizzlers, in general, because people don't like to waste > expensive things. > (There must have been some psychological test run at some point to test my > hypothesis, I will see if I can find one.) > (And I suppose the taste of a Ruth's Chris steak is not constant with the > taste of a Sizzlers steak.) And you chide me on my analogy/illustration/metaphor/whositz. >>>> So maintaining the needs test is not a requirement for stewardship, as >>>> other forces outside of our control will work towards the same ends of >>>> efficient usage that the needs test was designed to incentivize. >>> >>> Maybe not, if we were absolutely determined that at all costs the needs >>> test had to go. But we have not so determined. You propose that this is >>> desireable and are experiencing some discussion. Not everyone agrees. > > I guess I should say if you accept the general notion that increased value > leads to decreased waste, It might be time to slow here because I don't necessarily accept general notions. It is hard to tell the context of this conjecture from the proceeding text. > then address space will trend towards meeting the > goal of conservation as it obtains monetary value. This is almost poetry, and I almost understand what you mean, my soul almost begins to soar, but no. >>>> I think some stewards have gotten it into their heads that their role is >>>> to decide the best, or at least better, use of addresses, but I argue >>>> that was never a goal of stewardship. >>> >>> Here again: some stewards _MAY_ be considering that it might be better if >>> existing uses of addresses be prefered to proposed and possibly >>> undesirable uses. I would think YOU have to justify convincingly the >>> advantages of previously prohibited practices, not just assert repeatedly >>> those advantages. > > Yes, I agree the proposer of a policy change has the burden of having to > justifiably convince others before any change should be effected. > Well, good. I'll just note that Owen disclaims any such getting it into their heads. regards John Springer From frnkblk at iname.com Tue May 24 23:35:32 2011 From: frnkblk at iname.com (Frank Bulk) Date: Tue, 24 May 2011 22:35:32 -0500 Subject: [arin-ppml] Integrating Draft Policy ARIN-2011-1 into NRPM 8.3 In-Reply-To: <349C8AD2-9C4B-4B0F-8875-A6040341F476@delong.com> References: <07DCA09506E941C3AEE0B6562DF8DB4E@mike> <00ac01cc19c6$2c803340$858099c0$@iname.com> <0114D408-5D5F-4EC3-A193-BE10687D7A8C@delong.com> <-5099803936536899096@unknownmsgid> <349C8AD2-9C4B-4B0F-8875-A6040341F476@delong.com> Message-ID: <00d901cc1a8c$cd5ba260$6812e720$@iname.com> Since currently ARIN policy implements the needs-basis, isn't mentioning that requirement in 2011-1 redundant? Or are you concerned that some ARIN policies might remove the needs-basis requirement and you want to preserve the requirement in the inter-RIR transfer? Frank From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Owen DeLong Sent: Tuesday, May 24, 2011 12:47 AM To: Scott Leibrand Cc: ARIN-PPML List Subject: Re: [arin-ppml] Integrating Draft Policy ARIN-2011-1 into NRPM 8.3 I still would prefer to see the needs-basis comment preserved as well. Owen On May 23, 2011, at 10:07 PM, Scott Leibrand wrote: So perhaps: + to another RIR, for transfer to a specified recipient in that RIR's service region, if both RIRs agree and the request meets both RIRs' transfer policies. I agree it's useful to preserve discretion. I think I might prefer this to the text I originally had below... Thoughts? Scott On May 23, 2011, at 9:56 PM, Owen DeLong wrote: I prefer to preserve the safety valve of requiring agreement from both RIRs. Owen On May 23, 2011, at 8:53 PM, Frank Bulk wrote: Why don't we change the second point to: + to another RIR, for transfer to a specified recipient in that RIR's service region, if the request meets both RIRS' transfer policies. Frank ----- Original Message ----- From: Scott Leibrand To: Owen DeLong Cc: ARIN-PPML List Sent: Monday, May 23, 2011 5:21 PM Subject: Re: [arin-ppml] Integrating Draft Policy ARIN-2011-1 into NRPM 8.3 On Mon, May 23, 2011 at 2:05 PM, Owen DeLong wrote: I could support this, but, I have a couple of lingering concerns. I think that the last sentence dictates too much in the case of a transfer to another region and should only apply to transfers within the ARIN region. Yeah, I was wondering about that myself. Possible slight revision inline below... On May 23, 2011, at 15:54, Scott Leibrand wrote: In light of the discomfort a number of community and AC members feel with the original 2011-1 text, I thought I'd make an attempt at integrating it into the framework of NRPM 8.3, to see if the result would be tighter and less ambiguous. Here's what I came up with: 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, in whole or in part, for transfer: * to a specified organizational recipient within the ARIN region, or * to another RIR, for transfer to a specified organizational recipient in that RIR's service region, if the two RIRs agree and maintain compatible, needs-based transfer policies. Such transferred number resources may only be received under RSA by organizations that can demonstrate the need for such resources, as a single aggregate, in the exact amount which they can justify under current ARIN policies. How about "Such number resources may only be received under RSA by organizations that can demonstrate the need for such resources, as a single aggregate, in the exact amount which they can justify under current ARIN, or recipient RIR, policies." ? Or, feel free to suggest text... -Scott For reference, existing policy reads: 8.3. Transfers to Specified Recipients In addition to transfers under section 8.2, IPv4 number resources within the ARIN region may be released to ARIN by the authorized resource holder, in whole or in part, for transfer to another specified organizational recipient. Such transferred number resources may only be received under RSA by organizations that are within the ARIN region and can demonstrate the need for such resources, as a single aggregate, in the exact amount which they can justify under current ARIN policies. And original 2011-1 text reads: Any RIR's resource registrant may transfer IPv4 addresses to the resource registrant of another RIR as long as the two RIRs agree and maintain compatible, needs-based transfer policies that exercise Internet stewardship consistent with the values expressed in RFC2050. _______________________________________________ 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. _______________________________________________ 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 frnkblk at iname.com Tue May 24 23:38:32 2011 From: frnkblk at iname.com (Frank Bulk) Date: Tue, 24 May 2011 22:38:32 -0500 Subject: [arin-ppml] Integrating Draft Policy ARIN-2011-1 into NRPM 8.3 In-Reply-To: <138BFC71-19BE-4717-869E-71728C069234@delong.com> References: <07DCA09506E941C3AEE0B6562DF8DB4E@mike> <00ac01cc19c6$2c803340$858099c0$@iname.com> <0114D408-5D5F-4EC3-A193-BE10687D7A8C@delong.com> <00b101cc19cf$750f6690$5f2e33b0$@iname.com> <138BFC71-19BE-4717-869E-71728C069234@delong.com> Message-ID: <00de01cc1a8d$38566a00$a9033e00$@iname.com> The risk of including the requirement of agreement by the RIRs is that it leaves transfers to their whim. We could rephrase it in some way to presume that that transfer will go through, but that either party reserves the right to reject the transfer out or in. Frank From: Owen DeLong [mailto:owen at delong.com] Sent: Tuesday, May 24, 2011 1:18 AM To: frnkblk at iname.com Cc: ARIN-PPML List Subject: Re: [arin-ppml] Integrating Draft Policy ARIN-2011-1 into NRPM 8.3 There may be some other policy or legal reason that either RIR may wish to block the transfer and I want to give staff the ability to address unforeseen circumstances in a complicated and shifting environment that could change without input through our PDP by doing the closest they can come to "the right thing" based on sound judgment rather than being ratholed by our policy which cannot possibly adapt fast enough. Owen On May 23, 2011, at 10:00 PM, Frank Bulk wrote: Can you explain why? It's not that ARIN-2011-1 binds the non-ARIN RIR to receive the netblock. Frank From: Owen DeLong [mailto:owen at delong.com] Sent: Monday, May 23, 2011 11:56 PM To: frnkblk at iname.com Cc: ARIN-PPML List Subject: Re: [arin-ppml] Integrating Draft Policy ARIN-2011-1 into NRPM 8.3 I prefer to preserve the safety valve of requiring agreement from both RIRs. Owen On May 23, 2011, at 8:53 PM, Frank Bulk wrote: Why don't we change the second point to: + to another RIR, for transfer to a specified recipient in that RIR's service region, if the request meets both RIRS' transfer policies. Frank From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Scott Leibrand Sent: Monday, May 23, 2011 5:17 PM To: Mike Burns Cc: ARIN-PPML List Subject: Re: [arin-ppml] Integrating Draft Policy ARIN-2011-1 into NRPM 8.3 On Mon, May 23, 2011 at 3:00 PM, Mike Burns wrote: Hi Scott, In the context of this proposal, may I ask what would happen if APNIC accepted a transfer of ARIN legacy addresses and updated their Whois, even if ARIN refused the transfer? I suppose what would matter in that case is who IANA pointed to. To date, we haven't seen cases where two different RIRs were both claiming authority for the same address block, and I don't expect to see that, as all of the RIRs are committed to operating within the "RIR system". (Because the language of the proposal pointedly excludes APNIC, if their current policy remains in place.) I know that ARIN could revoke and reissue. How is inter-RIR conflict resolved, is there a process in place for conflict resolution? Yes, I believe there is, but I don't know the details. I presume it would be a largely consensual process within the ASO/NRO/IANA framework (perhaps within the NRO EC?). Do the RIRs generally have compatible needs-based transfer policies, I mean I know APNIC doesn't, but do the other RIRs have the same 3-month window, for example? Is a difference in the needs window enough to prevent a transfer? If so, do we need to consider other RIRs and the impact on inter-RIR transfers when we consider proposals to change the needs window? What if RIPE joins APNIC with a requirement like a /24 maximum, is that something that makes the needs requirements incompatible? I don't consider any such differences in timeframes, size minimums/maximums, etc. to be incompatibilities in the context of 2011-1. But ARIN has said that, as things stand today, the lack of explicit needs basis in APNIC's transfer policy would make it incompatible with 2011-1's requirement for "compatible, needs-based transfer policies". I hope we can come to an agreement with the APNIC community on language or interpretation that would be compatible with both regions' needs and preferences, but 2011-1 as I see it is just the first step in that direction: setting up a framework that would allow inter-RIR transfers once such incompatibilities are resolved somehow (or with other RIRs where such incompatibilities may not exist). I guess I am asking for a more detailed definition of the word "compatible" in your proposed language. Maybe that language is extraneous, as you are already requiring both RIRs to agree? Operationally, the two are quite related, in that ARIN will not agree unless they assess the other RIR's transfer policy to be compatible. But the "RIRs agree" language is also there as a safety valve to explicitly allow an RIR to not agree to a transfer if it has reason to believe that the transfer would violate policy or law. -Scott (speaking only for myself, as usual) ----- Original Message ----- From: Scott Leibrand To: Owen DeLong Cc: ARIN-PPML List Sent: Monday, May 23, 2011 5:21 PM Subject: Re: [arin-ppml] Integrating Draft Policy ARIN-2011-1 into NRPM 8.3 On Mon, May 23, 2011 at 2:05 PM, Owen DeLong wrote: I could support this, but, I have a couple of lingering concerns. I think that the last sentence dictates too much in the case of a transfer to another region and should only apply to transfers within the ARIN region. Yeah, I was wondering about that myself. Possible slight revision inline below... I would like to see us relocate the single aggregate clause to make it binding on the actual community intent and if we're going to turn 2011-1 into a policy to modify 8.3 anyway, we should incorporate that change. I would like to see another proposal to do this (and to be discussed as a counterpoint to ARIN-prop-144 in Philadelphia). On May 23, 2011, at 15:54, Scott Leibrand wrote: In light of the discomfort a number of community and AC members feel with the original 2011-1 text, I thought I'd make an attempt at integrating it into the framework of NRPM 8.3, to see if the result would be tighter and less ambiguous. Here's what I came up with: 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, in whole or in part, for transfer: * to a specified organizational recipient within the ARIN region, or * to another RIR, for transfer to a specified organizational recipient in that RIR's service region, if the two RIRs agree and maintain compatible, needs-based transfer policies. Such transferred number resources may only be received under RSA by organizations that can demonstrate the need for such resources, as a single aggregate, in the exact amount which they can justify under current ARIN policies. How about "Such number resources may only be received under RSA by organizations that can demonstrate the need for such resources, as a single aggregate, in the exact amount which they can justify under current ARIN, or recipient RIR, policies." ? Or, feel free to suggest text... -Scott For reference, existing policy reads: 8.3. Transfers to Specified Recipients In addition to transfers under section 8.2, IPv4 number resources within the ARIN region may be released to ARIN by the authorized resource holder, in whole or in part, for transfer to another specified organizational recipient. Such transferred number resources may only be received under RSA by organizations that are within the ARIN region and can demonstrate the need for such resources, as a single aggregate, in the exact amount which they can justify under current ARIN policies. And original 2011-1 text reads: Any RIR's resource registrant may transfer IPv4 addresses to the resource registrant of another RIR as long as the two RIRs agree and maintain compatible, needs-based transfer policies that exercise Internet stewardship consistent with the values expressed in RFC2050. _______________________________________________ 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 matthew at matthew.at Wed May 25 02:01:11 2011 From: matthew at matthew.at (Matthew Kaufman) Date: Wed, 25 May 2011 08:01:11 +0200 Subject: [arin-ppml] ARIN-prop-151 Limiting Needs Requirements for IPv4 Transfers In-Reply-To: <515472D9-98F2-47AA-A714-21318B8689BD@delong.com> References: <0EF360E766F94AD88D3D56AA3C568CE5@mike> <20110524201152.8AA0D213643@smtp2.arin.net> <8695009A81378E48879980039EEDAD289F03306C@MAIL1.polartel.local> <841FC7BFE0CC44A2A8D54F616B0814E6@video> <515472D9-98F2-47AA-A714-21318B8689BD@delong.com> Message-ID: <47FCE48A-839E-46DB-AE55-91A21777FF08@matthew.at> On May 25, 2011, at 4:46 AM, Owen DeLong wrote: > > >> And when that happens, the price of addresses will go up, and more will enter the pool. >> > > And the big boys will buy them, too. I'm not sure why you can't see this. Who cares? The "big boys" already have a huge advantage in IPv4 space and this will continue. There's nothing you can do at this point to mitigate the problem. We're arguing over a policy change that would make everything much easier to manage post-runout and which moves the needle, in the worst case, from 99.9% to 100%. (Though with the /12 limit, probably not even that far) Matthew Kaufman From matthew at matthew.at Wed May 25 02:02:59 2011 From: matthew at matthew.at (Matthew Kaufman) Date: Wed, 25 May 2011 08:02:59 +0200 Subject: [arin-ppml] ARIN-prop-151 Limiting Needs Requirements for IPv4 Transfers In-Reply-To: References: <0EF360E766F94AD88D3D56AA3C568CE5@mike> <20110524201152.8AA0D213643@smtp2.arin.net> Message-ID: On May 25, 2011, at 2:50 AM, Jimmy Hess wrote: > > > ARIN could also mitigate this by setting a price "per IP" that ARIN is > willing to pay > for addresses returned to ARIN. > > E.g. "Return 50% or more of a /16 or longer allocation, and get > $0.001 per IP address." > "Return 50% or more of a /8 or longer allocation and get $0.0005 > per IP address" I'm afraid that the price is already over $11/ea. Matthew Kaufman From matthew at matthew.at Wed May 25 02:03:28 2011 From: matthew at matthew.at (Matthew Kaufman) Date: Wed, 25 May 2011 08:03:28 +0200 Subject: [arin-ppml] ARIN-prop-151 Limiting Needs Requirements for IPv4 Transfers In-Reply-To: <515472D9-98F2-47AA-A714-21318B8689BD@delong.com> References: <0EF360E766F94AD88D3D56AA3C568CE5@mike> <20110524201152.8AA0D213643@smtp2.arin.net> <8695009A81378E48879980039EEDAD289F03306C@MAIL1.polartel.local> <841FC7BFE0CC44A2A8D54F616B0814E6@video> <515472D9-98F2-47AA-A714-21318B8689BD@delong.com> Message-ID: On May 25, 2011, at 4:46 AM, Owen DeLong wrote: > > On May 24, 2011, at 5:25 PM, Mike Burns wrote: > >> Hi Kevin, >> >> But the big boys are limited to a /12 each. > > Uh, no, they're limited to a /12 per organization they create. Come on. If they're going to game the system by creating multiple orgs to beat the /12 rule, they'll also game the system by using their extensive experience working with ARIN to pass needs assessment tests, or create new fake multihomed orgs and use their untestable 3-month need to get a bunch of space, or lots of other things. And either *all* of those are fraud, or none of them are. Matthew Kaufman From mysidia at gmail.com Wed May 25 02:36:33 2011 From: mysidia at gmail.com (Jimmy Hess) Date: Wed, 25 May 2011 01:36:33 -0500 Subject: [arin-ppml] ARIN-prop-151 Limiting Needs Requirements for IPv4 Transfers In-Reply-To: References: <0EF360E766F94AD88D3D56AA3C568CE5@mike> <20110524201152.8AA0D213643@smtp2.arin.net> <8695009A81378E48879980039EEDAD289F03306C@MAIL1.polartel.local> <841FC7BFE0CC44A2A8D54F616B0814E6@video> <515472D9-98F2-47AA-A714-21318B8689BD@delong.com> Message-ID: On Wed, May 25, 2011 at 1:03 AM, Matthew Kaufman wrote: > Come on. If they're going to game the system by creating multiple orgs to beat the /12 rule, they'll also game the system by using their extensive experience working with ARIN to pass needs assessment tests, or create new fake multihomed orgs and use their untestable 3-month need to get a bunch of space, or lots of other things. > > And either *all* of those are fraud, or none of them are. Creating new organizations = Easy. Just a little extra paperwork, some nominal filing fees, legal documents, and about five minutes for a clerk to register the additional organizations with the relevant authorities. And not fraudulent. Each entity applying for addresses really could easily be made a separate legitimate organization, and they would not be "lying" to say they are not the same org. Passing needs assessments tests, following the rules, without justified need existing = Hard/Impossible. > Matthew Kaufman -- -JH From matthew at matthew.at Wed May 25 02:43:34 2011 From: matthew at matthew.at (Matthew Kaufman) Date: Wed, 25 May 2011 08:43:34 +0200 Subject: [arin-ppml] ARIN-prop-151 Limiting Needs Requirements for IPv4 Transfers In-Reply-To: References: <0EF360E766F94AD88D3D56AA3C568CE5@mike> <20110524201152.8AA0D213643@smtp2.arin.net> <8695009A81378E48879980039EEDAD289F03306C@MAIL1.polartel.local> <841FC7BFE0CC44A2A8D54F616B0814E6@video> <515472D9-98F2-47AA-A714-21318B8689BD@delong.com> Message-ID: On May 25, 2011, at 8:36 AM, Jimmy Hess wrote: > On Wed, May 25, 2011 at 1:03 AM, Matthew Kaufman wrote: >> Come on. If they're going to game the system by creating multiple orgs to beat the /12 rule, they'll also game the system by using their extensive experience working with ARIN to pass needs assessment tests, or create new fake multihomed orgs and use their untestable 3-month need to get a bunch of space, or lots of other things. >> >> And either *all* of those are fraud, or none of them are. > > Creating new organizations = Easy. Just a little extra paperwork, > some nominal filing fees, legal documents, and about five minutes for a > clerk to register the additional organizations with the relevant authorities. > > And not fraudulent. Each entity applying for addresses really could easily be > made a separate legitimate organization, and they would not be "lying" to > say they are not the same org. > > > Passing needs assessments tests, following the rules, without > justified need existing = Hard/Impossible. Totally disagree. There's any number of consultants who specialize in this. Plus you simply create new orgs (which you claim is easy) and ask for an initial allocation for them associated with their grandiose (and plausible) business plans. Matthew Kaufman From info at arin.net Wed May 25 10:37:58 2011 From: info at arin.net (ARIN) Date: Wed, 25 May 2011 10:37:58 -0400 Subject: [arin-ppml] Draft Policy 2011-7 Compliance Requirement In-Reply-To: <4DDC0293.4020104@arin.net> References: <4DDC0293.4020104@arin.net> Message-ID: <4DDD1446.1090103@arin.net> Correction: This draft policy will be on the agenda at the ARIN Public Policy Meeting in Philadelphia in October. Regards, Member Services American Registry for Internet Numbers (ARIN) ARIN wrote: > Draft Policy ARIN-2011-7 > Compliance Requirement > > On 19 May 2011 the ARIN Advisory Council (AC) selected "Returned > IPv4 Addresses" as a draft policy for adoption discussion on the PPML > and at the Public Policy Meeting in San Juan, Puerto Rico in April. > > The draft was developed by the AC from policy proposal "ARIN-prop-126 > Compliance Requirement." Per the Policy Development Process the AC > submitted text to ARIN for a staff and legal assessment prior to its > selection as a draft policy. Below the draft policy is the ARIN staff > and legal assessment, followed by the text that was submitted by the AC. > Note that the AC revised the draft policy text after they received the > assessment from staff. > > Draft Policy ARIN-2011-7 is below and can be found at: > https://www.arin.net/policy/proposals/2011_7.html > > You are encouraged to discuss Draft Policy 2011-7 on the PPML prior to > the October Public Policy Meeting. Both the discussion on the list and > at the meeting will be used by the ARIN Advisory Council to determine > the community consensus for adopting this as policy. > > The ARIN Policy Development Process can be found at: > https://www.arin.net/policy/pdp.html > > Draft Policies and Proposals under discussion can be found at: > https://www.arin.net/policy/proposals/index.html > > Regards, > > Member Services > American Registry for Internet Numbers (ARIN) > > > ## * ## > > > Draft Policy ARIN-2011-7 > Compliance Requirement > > Date/version: 24 May 2011 > > Policy statement: > > Resource Review > Update the following NRPM Sections: > > 12.4 - Update to: > Organizations found by ARIN to be out of compliance with current ARIN > policy shall be required to update reassignment information or return > resources as needed to bring them into (or reasonably close to) > compliance > > 1. The degree to which an organization may remain out of compliance > shall be based on the reasonable judgment of the ARIN staff and shall > balance all facts known, including the organization's utilization rate, > available address pool, and other factors as appropriate so as to avoid > forcing returns which will result in near-term additional requests or > unnecessary route de-aggregation. > > 2. To the extent possible, entire blocks should be returned. Partial > address blocks shall be returned in such a way that the portion retained > will comprise a single aggregate block. > > (leave 12.5 as is) > > 12.6 - Update to: > Except in cases of fraud, an organization shall be given a minimum of > thirty (30) days to respond. If an organization does not respond within > those thirty (30) days, ARIN may cease providing reverse DNS services to > that organization. If progress of resource returns or record corrections > is not visible within sixty (60) days after correspondence with ARIN > began, ARIN will cease providing reverse DNS services for the resources > in question. At any time after ninety (90) days have passed, ARIN may > initiate resource revocation as allowed > in paragraph 12.5. ARIN shall negotiate a longer term with the > organization if ARIN believes the organization is working in good faith > to substantially restore compliance and has a valid need for additional > time to renumber out of the affected blocks. > > > Rationale: > > This version addresses several staff and legal concerns with the > original text of this policy by clarifying the language and making it > more concrete. > > To date the community has not documented or firmly established use of an > effective enforcement mechanism. This policy will support current policy > and compel those who are allocated ARIN resources to maintain the proper > WHOIS records in accordance with ARIN NRPM. While it is recognized this > is not an absolute solution to ensure compliance, it is the best method > under current ARIN policies. > > Timetable for implementation: Immediate > > > ##### > > > This is an assessment of the proposal as originally submitted by the AC. > The AC subsequently revised the proposal/draft policy text (see current > version above). > > STAFF ASSESSMENT > > Proposal: Compliance Requirement (ARIN-prop-126) > Policy Version (Date): 11 January 2011 > Date of Assessment: 28 January 2011 > > 1. Proposal Summary (Staff Understanding) > > This policy requires ARIN staff to not only identify customers who are > out of compliance with policy, but to withhold services for those who > fail to come into compliance within a designated time. Staff is to > contact customers who are out of compliance with policy and give them 30 > days to respond to our contact and to demonstrate they've begun to take > corrective measures within 60 days. If either of these criteria is not > met, the policy instructs staff to cease providing reverse DNS services > to the customer or to begin reclamation efforts. > > 2. Comments > A. ARIN Staff Comments > > ? The policy says either "take away reverse" or "reclaim the numbers". > It would be helpful to staff if there was clear guidance as to when > revocation was to be used over reverse dns removal. Without clear > guidance, staff would implement this in such a way that reverse dns > removal would be used as the first step of the enforcement, and > revocation of the resource as the final step when an organization is > unable to come into compliance within a defined time period. > ? The term ?materially out of compliance? is not well defined anywhere > within this policy. Without additional criteria, staff will continue to > interpret this term somewhat liberally, and to apply it at our > discretion using our best judgment and consideration of existing > factors. Only those organizations that we deem to be significantly in > violation of existing policy will be flagged for further review and > audit. > > B. ARIN General Counsel > > This policy has significant legal implications. It needs to be > carefully edited to remove unnecessary ambiguities that might require > enforcement when it should be discretionary and to avoid giving those > ?enforced against? arguments that will require case-by-case adjudication. > > For example, the first line of the policy at 12.4 uses ?materiality? as > a standard. I strongly recommend against such a standard, as anyone who > is treated adversely will argue their ?noncompliance? is ?not material.? > If lack of compliance is the issue, it must be ?black or white? as a > review matter to protect against such drafting problems. If you believe > noncompliance with a limited number of policies is a better approach, > you can define such a set rather than overall compliance. > > Second, the ?requested or required? (emphasis added) language is > conceptually quite different ? one is ?a request,? the other ?a > command.? They must be separated if an escalation from ?requested? to > ?required? is intended. > > Third, a similar drafting problem appears in 12.6 where ?fraud? (a bad > and intentional thing) is equated to ?violations of policy? which could > be trivial and not intended. > > Overall, if the policy was enacted as is, the risk of legal issues being > thrust upon ARIN is unattractive and unwise. Counsel respectfully > suggests a thorough rewrite of the draft to remove these and other > issues of concern. > > 3. Resource Impact > > This policy would have moderate resource impact from an implementation > aspect. It is estimated that implementation could occur within 6 - 9 > months after ratification by the ARIN Board of Trustees. > > The implementation of this policy will require new software tools to > track these newly defined deadlines. Additionally, there will likely be > a significant increase in time and workload for the RS team as the > potential for a significant increase in resource audits due to > non-compliance with IPv6 reassignment requirements is great. This may > even require additional personnel, although it is too early to tell > right now. > > The following would be needed in order to implement: > ? Updated guidelines and website documentation > ? Staff training > ? Software tools would need to be developed to track the 30 and 60-day > deadlines. > > 4. Proposal Text > > ARIN-prop-126 > > Policy statement: > Resource Review > Update the following NRPM Sections: > 12.4 Update to: > Organizations found by ARIN to be materially out of compliance with > current ARIN policy shall be requested or required to return resources > or update reassignment information as needed to bring them into (or > reasonably close to) compliance. > 12.5 Update to: > If the organization does not voluntarily return resources or update > reassignment information as requested, ARIN will cease providing reverse > DNS services and/or revoke any resources issued by ARIN as required to > bring the organization into overall compliance. ARIN shall follow the > same guidelines for revocation that are required for voluntary return in > the previous paragraph. > 12.6 Update to: > Except in cases of fraud, or violations of policy, an organization shall > be given a minimum (30) days to respond. Progress of record(s) > correction(s) must be visible within (60) days after correspondence with > ARIN began or ARIN will start proceeding with removal of DNS services > and/or resources issued by ARIN. ARIN shall negotiate a longer term > with the organization if ARIN believes the organization is working in > good faith to substantially restore compliance and has a valid need for > additional time to renumber out of the affected blocks. > Rationale: > To date the community has not documented or firmly established use of an > effective enforcement mechanism. This policy will support current > policy and compel those who are allocated ARIN resources to maintain the > proper WHOIS records in accordance with ARIN NRPM. While it is > recognized this is not an absolute solution to ensure compliance, it is > the best method under current ARIN policies. > > > > > > > From owen at delong.com Wed May 25 12:05:10 2011 From: owen at delong.com (Owen DeLong) Date: Wed, 25 May 2011 09:05:10 -0700 Subject: [arin-ppml] ARIN-prop-151 Limiting Needs Requirements for IPv4 Transfers In-Reply-To: <47FCE48A-839E-46DB-AE55-91A21777FF08@matthew.at> References: <0EF360E766F94AD88D3D56AA3C568CE5@mike> <20110524201152.8AA0D213643@smtp2.arin.net> <8695009A81378E48879980039EEDAD289F03306C@MAIL1.polartel.local> <841FC7BFE0CC44A2A8D54F616B0814E6@video> <515472D9-98F2-47AA-A714-21318B8689BD@delong.com> <47FCE48A-839E-46DB-AE55-91A21777FF08@matthew.at> Message-ID: <7386C146-6F1B-47DB-B10C-221B78CE229C@delong.com> On May 24, 2011, at 11:01 PM, Matthew Kaufman wrote: > > On May 25, 2011, at 4:46 AM, Owen DeLong wrote: > >> >> >>> And when that happens, the price of addresses will go up, and more will enter the pool. >>> >> >> And the big boys will buy them, too. I'm not sure why you can't see this. > > Who cares? The "big boys" already have a huge advantage in IPv4 space and this will continue. There's nothing you can do at this point to mitigate the problem. > > We're arguing over a policy change that would make everything much easier to manage post-runout and which moves the needle, in the worst case, from 99.9% to 100%. (Though with the /12 limit, probably not even that far) > > Matthew Kaufman I disagree. I think we're talking about moving the needle from 25 or 30% to 100% and that's not a good move for the community. So, to answer your first question... I care and I believe many other members of the community, some of whom have spoken up in this debate also care. Owen From owen at delong.com Wed May 25 12:01:56 2011 From: owen at delong.com (Owen DeLong) Date: Wed, 25 May 2011 09:01:56 -0700 Subject: [arin-ppml] Integrating Draft Policy ARIN-2011-1 into NRPM 8.3 In-Reply-To: <00de01cc1a8d$38566a00$a9033e00$@iname.com> References: <07DCA09506E941C3AEE0B6562DF8DB4E@mike> <00ac01cc19c6$2c803340$858099c0$@iname.com> <0114D408-5D5F-4EC3-A193-BE10687D7A8C@delong.com> <00b101cc19cf$750f6690$5f2e33b0$@iname.com> <138BFC71-19BE-4717-869E-71728C069234@delong.com> <00de01cc1a8d$38566a00$a9033e00$@iname.com> Message-ID: <41070BA2-1792-4056-95C7-4A5A94BDFE9B@delong.com> RIRs are not particularly whimsical folks. I think this is a non-risk. Owen On May 24, 2011, at 8:38 PM, Frank Bulk wrote: > The risk of including the requirement of agreement by the RIRs is that it leaves transfers to their whim. > > We could rephrase it in some way to presume that that transfer will go through, but that either party reserves the right to reject the transfer out or in. > > Frank > > From: Owen DeLong [mailto:owen at delong.com] > Sent: Tuesday, May 24, 2011 1:18 AM > To: frnkblk at iname.com > Cc: ARIN-PPML List > Subject: Re: [arin-ppml] Integrating Draft Policy ARIN-2011-1 into NRPM 8.3 > > There may be some other policy or legal reason that either RIR may wish to block the > transfer and I want to give staff the ability to address unforeseen circumstances in a > complicated and shifting environment that could change without input through our > PDP by doing the closest they can come to "the right thing" based on sound judgment > rather than being ratholed by our policy which cannot possibly adapt fast enough. > > Owen > > On May 23, 2011, at 10:00 PM, Frank Bulk wrote: > > > Can you explain why? It?s not that ARIN-2011-1 binds the non-ARIN RIR to receive the netblock. > > Frank > > From: Owen DeLong [mailto:owen at delong.com] > Sent: Monday, May 23, 2011 11:56 PM > To: frnkblk at iname.com > Cc: ARIN-PPML List > Subject: Re: [arin-ppml] Integrating Draft Policy ARIN-2011-1 into NRPM 8.3 > > I prefer to preserve the safety valve of requiring agreement from both RIRs. > > Owen > > On May 23, 2011, at 8:53 PM, Frank Bulk wrote: > > > > Why don?t we change the second point to: > > + to another RIR, for transfer to a specified recipient in that RIR's service > region, if the request meets both RIRS? transfer policies. > > Frank > > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Scott Leibrand > Sent: Monday, May 23, 2011 5:17 PM > To: Mike Burns > Cc: ARIN-PPML List > Subject: Re: [arin-ppml] Integrating Draft Policy ARIN-2011-1 into NRPM 8.3 > > On Mon, May 23, 2011 at 3:00 PM, Mike Burns wrote: > Hi Scott, > > In the context of this proposal, may I ask what would happen if APNIC accepted a transfer of ARIN legacy addresses and updated their Whois, even if ARIN refused the transfer? > > I suppose what would matter in that case is who IANA pointed to. To date, we haven't seen cases where two different RIRs were both claiming authority for the same address block, and I don't expect to see that, as all of the RIRs are committed to operating within the "RIR system". > > (Because the language of the proposal pointedly excludes APNIC, if their current policy remains in place.) > I know that ARIN could revoke and reissue. > How is inter-RIR conflict resolved, is there a process in place for conflict resolution? > > Yes, I believe there is, but I don't know the details. I presume it would be a largely consensual process within the ASO/NRO/IANA framework (perhaps within the NRO EC?). > > Do the RIRs generally have compatible needs-based transfer policies, I mean I know APNIC doesn't, but do the other RIRs have the same 3-month window, for example? > Is a difference in the needs window enough to prevent a transfer? > If so, do we need to consider other RIRs and the impact on inter-RIR transfers when we consider proposals to change the needs window? > What if RIPE joins APNIC with a requirement like a /24 maximum, is that something that makes the needs requirements incompatible? > > I don't consider any such differences in timeframes, size minimums/maximums, etc. to be incompatibilities in the context of 2011-1. But ARIN has said that, as things stand today, the lack of explicit needs basis in APNIC's transfer policy would make it incompatible with 2011-1's requirement for "compatible, needs-based transfer policies". I hope we can come to an agreement with the APNIC community on language or interpretation that would be compatible with both regions' needs and preferences, but 2011-1 as I see it is just the first step in that direction: setting up a framework that would allow inter-RIR transfers once such incompatibilities are resolved somehow (or with other RIRs where such incompatibilities may not exist). > > I guess I am asking for a more detailed definition of the word "compatible" in your proposed language. > Maybe that language is extraneous, as you are already requiring both RIRs to agree? > > Operationally, the two are quite related, in that ARIN will not agree unless they assess the other RIR's transfer policy to be compatible. But the "RIRs agree" language is also there as a safety valve to explicitly allow an RIR to not agree to a transfer if it has reason to believe that the transfer would violate policy or law. > > -Scott (speaking only for myself, as usual) > > > > > > ----- Original Message ----- > From: Scott Leibrand > To: Owen DeLong > Cc: ARIN-PPML List > Sent: Monday, May 23, 2011 5:21 PM > Subject: Re: [arin-ppml] Integrating Draft Policy ARIN-2011-1 into NRPM 8.3 > > On Mon, May 23, 2011 at 2:05 PM, Owen DeLong wrote: > I could support this, but, I have a couple of lingering concerns. > > I think that the last sentence dictates too much in the case of a transfer to another region and should only apply to transfers within the ARIN region. > > Yeah, I was wondering about that myself. Possible slight revision inline below... > > I would like to see us relocate the > single aggregate clause to make it binding on the actual community intent and if we're > going to turn 2011-1 into a policy to modify 8.3 anyway, we should incorporate that > change. > > I would like to see another proposal to do this (and to be discussed as a counterpoint to ARIN-prop-144 in Philadelphia). > > On May 23, 2011, at 15:54, Scott Leibrand wrote: > > In light of the discomfort a number of community and AC members feel with the original 2011-1 text, I thought I'd make an attempt at integrating it into the framework of NRPM 8.3, to see if the result would be tighter and less ambiguous. Here's what I came up with: > > 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, in whole or in part, for transfer: > to a specified organizational recipient within the ARIN region, or > to another RIR, for transfer to a specified organizational recipient in that RIR's service region, if the two RIRs agree and maintain compatible, needs-based transfer policies. > Such transferred number resources may only be received under RSA by organizations that can demonstrate the need for such resources, as a single aggregate, in the exact amount which they can justify under current ARIN policies. > > How about "Such number resources may only be received under RSA by organizations that can demonstrate the need for such resources, as a single aggregate, in the exact amount which they can justify under current ARIN, or recipient RIR, policies." ? > > Or, feel free to suggest text... > > -Scott > > > For reference, existing policy reads: > 8.3. Transfers to Specified Recipients > > In addition to transfers under section 8.2, IPv4 number resources within the ARIN region may be released to ARIN by the authorized resource holder, in whole or in part, for transfer to another specified organizational recipient. Such transferred number resources may only be received under RSA by organizations that are within the ARIN region and can demonstrate the need for such resources, as a single aggregate, in the exact amount which they can justify under current ARIN policies. > > And original 2011-1 text reads: > Any RIR's resource registrant may transfer IPv4 addresses to the resource registrant of another RIR as long as the two RIRs agree and maintain compatible, needs-based transfer policies that exercise Internet stewardship consistent with the values expressed in RFC2050. > _______________________________________________ > 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 owen at delong.com Wed May 25 12:00:47 2011 From: owen at delong.com (Owen DeLong) Date: Wed, 25 May 2011 09:00:47 -0700 Subject: [arin-ppml] Integrating Draft Policy ARIN-2011-1 into NRPM 8.3 In-Reply-To: <00d901cc1a8c$cd5ba260$6812e720$@iname.com> References: <07DCA09506E941C3AEE0B6562DF8DB4E@mike> <00ac01cc19c6$2c803340$858099c0$@iname.com> <0114D408-5D5F-4EC3-A193-BE10687D7A8C@delong.com> <-5099803936536899096@unknownmsgid> <349C8AD2-9C4B-4B0F-8875-A6040341F476@delong.com> <00d901cc1a8c$cd5ba260$6812e720$@iname.com> Message-ID: <680F5536-8FF7-48F0-9EC0-5831BEA9418F@delong.com> I would prefer since we are venturing into inter-RIR territory to have this policy be as specific and complete as possible and stand alone to the greatest possible extent. In this case, I think excessive clarity where practicable is worth while. Owen On May 24, 2011, at 8:35 PM, Frank Bulk wrote: > Since currently ARIN policy implements the needs-basis, isn?t mentioning that requirement in 2011-1 redundant? Or are you concerned that some ARIN policies might remove the needs-basis requirement and you want to preserve the requirement in the inter-RIR transfer? > > Frank > > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Owen DeLong > Sent: Tuesday, May 24, 2011 12:47 AM > To: Scott Leibrand > Cc: ARIN-PPML List > Subject: Re: [arin-ppml] Integrating Draft Policy ARIN-2011-1 into NRPM 8.3 > > I still would prefer to see the needs-basis comment preserved as well. > > Owen > > On May 23, 2011, at 10:07 PM, Scott Leibrand wrote: > > > So perhaps: > > + to another RIR, for transfer to a specified recipient in that RIR's service region, if both RIRs agree and the request meets both RIRs' transfer policies. > > I agree it's useful to preserve discretion. I think I might prefer this to the text I originally had below... Thoughts? > > Scott > > On May 23, 2011, at 9:56 PM, Owen DeLong wrote: > > I prefer to preserve the safety valve of requiring agreement from both RIRs. > > Owen > > On May 23, 2011, at 8:53 PM, Frank Bulk wrote: > > > Why don?t we change the second point to: > > + to another RIR, for transfer to a specified recipient in that RIR's service > region, if the request meets both RIRS? transfer policies. > > Frank > > > > > > > ----- Original Message ----- > From: Scott Leibrand > To: Owen DeLong > Cc: ARIN-PPML List > Sent: Monday, May 23, 2011 5:21 PM > Subject: Re: [arin-ppml] Integrating Draft Policy ARIN-2011-1 into NRPM 8.3 > > On Mon, May 23, 2011 at 2:05 PM, Owen DeLong wrote: > I could support this, but, I have a couple of lingering concerns. > > I think that the last sentence dictates too much in the case of a transfer to another region and should only apply to transfers within the ARIN region. > > Yeah, I was wondering about that myself. Possible slight revision inline below... > > > On May 23, 2011, at 15:54, Scott Leibrand wrote: > > In light of the discomfort a number of community and AC members feel with the original 2011-1 text, I thought I'd make an attempt at integrating it into the framework of NRPM 8.3, to see if the result would be tighter and less ambiguous. Here's what I came up with: > > 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, in whole or in part, for transfer: > to a specified organizational recipient within the ARIN region, or > to another RIR, for transfer to a specified organizational recipient in that RIR's service region, if the two RIRs agree and maintain compatible, needs-based transfer policies. > Such transferred number resources may only be received under RSA by organizations that can demonstrate the need for such resources, as a single aggregate, in the exact amount which they can justify under current ARIN policies. > > How about "Such number resources may only be received under RSA by organizations that can demonstrate the need for such resources, as a single aggregate, in the exact amount which they can justify under current ARIN, or recipient RIR, policies." ? > > Or, feel free to suggest text... > > -Scott > > > For reference, existing policy reads: > 8.3. Transfers to Specified Recipients > > In addition to transfers under section 8.2, IPv4 number resources within the ARIN region may be released to ARIN by the authorized resource holder, in whole or in part, for transfer to another specified organizational recipient. Such transferred number resources may only be received under RSA by organizations that are within the ARIN region and can demonstrate the need for such resources, as a single aggregate, in the exact amount which they can justify under current ARIN policies. > > And original 2011-1 text reads: > Any RIR's resource registrant may transfer IPv4 addresses to the resource registrant of another RIR as long as the two RIRs agree and maintain compatible, needs-based transfer policies that exercise Internet stewardship consistent with the values expressed in RFC2050. > _______________________________________________ > 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. > > _______________________________________________ > 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 25 12:06:46 2011 From: owen at delong.com (Owen DeLong) Date: Wed, 25 May 2011 09:06:46 -0700 Subject: [arin-ppml] ARIN-prop-151 Limiting Needs Requirements for IPv4 Transfers In-Reply-To: References: <0EF360E766F94AD88D3D56AA3C568CE5@mike> <20110524201152.8AA0D213643@smtp2.arin.net> <8695009A81378E48879980039EEDAD289F03306C@MAIL1.polartel.local> <841FC7BFE0CC44A2A8D54F616B0814E6@video> <515472D9-98F2-47AA-A714-21318B8689BD@delong.com> Message-ID: On May 24, 2011, at 11:03 PM, Matthew Kaufman wrote: > > On May 25, 2011, at 4:46 AM, Owen DeLong wrote: > >> >> On May 24, 2011, at 5:25 PM, Mike Burns wrote: >> >>> Hi Kevin, >>> >>> But the big boys are limited to a /12 each. >> >> Uh, no, they're limited to a /12 per organization they create. > > Come on. If they're going to game the system by creating multiple orgs to beat the /12 rule, they'll also game the system by using their extensive experience working with ARIN to pass needs assessment tests, or create new fake multihomed orgs and use their untestable 3-month need to get a bunch of space, or lots of other things. > Perhaps, but, I think this is actually less likely and many of those actions are obviously fraud. > And either *all* of those are fraud, or none of them are. > I disagree. If the rule you make is a /12 per organization, then, there's nothing fraudulent about creating organizations. On the other hand, under current policy, most of the things you described to circumvent current policy are, indeed, fraud. Owen From owen at delong.com Wed May 25 12:08:13 2011 From: owen at delong.com (Owen DeLong) Date: Wed, 25 May 2011 09:08:13 -0700 Subject: [arin-ppml] ARIN-prop-151 Limiting Needs Requirements for IPv4 Transfers In-Reply-To: References: <0EF360E766F94AD88D3D56AA3C568CE5@mike> <20110524201152.8AA0D213643@smtp2.arin.net> <8695009A81378E48879980039EEDAD289F03306C@MAIL1.polartel.local> <841FC7BFE0CC44A2A8D54F616B0814E6@video> <515472D9-98F2-47AA-A714-21318B8689BD@delong.com> Message-ID: On May 24, 2011, at 11:43 PM, Matthew Kaufman wrote: > > On May 25, 2011, at 8:36 AM, Jimmy Hess wrote: > >> On Wed, May 25, 2011 at 1:03 AM, Matthew Kaufman wrote: >>> Come on. If they're going to game the system by creating multiple orgs to beat the /12 rule, they'll also game the system by using their extensive experience working with ARIN to pass needs assessment tests, or create new fake multihomed orgs and use their untestable 3-month need to get a bunch of space, or lots of other things. >>> >>> And either *all* of those are fraud, or none of them are. >> >> Creating new organizations = Easy. Just a little extra paperwork, >> some nominal filing fees, legal documents, and about five minutes for a >> clerk to register the additional organizations with the relevant authorities. >> >> And not fraudulent. Each entity applying for addresses really could easily be >> made a separate legitimate organization, and they would not be "lying" to >> say they are not the same org. >> >> >> Passing needs assessments tests, following the rules, without >> justified need existing = Hard/Impossible. > > Totally disagree. There's any number of consultants who specialize in this. > > Plus you simply create new orgs (which you claim is easy) and ask for an initial allocation for them associated with their grandiose (and plausible) business plans. > > Matthew Kaufman Under existing policy, you have to create not only a legitimate new organization, but, also a fraudulent grandiose business plan. Under proposed policy, you only have to create the legitimate new organization. To me, this is a significant difference. Owen From mike at nationwideinc.com Wed May 25 12:21:13 2011 From: mike at nationwideinc.com (Mike Burns) Date: Wed, 25 May 2011 12:21:13 -0400 Subject: [arin-ppml] Integrating Draft Policy ARIN-2011-1 into NRPM 8.3 References: <07DCA09506E941C3AEE0B6562DF8DB4E@mike> <00ac01cc19c6$2c803340$858099c0$@iname.com> <0114D408-5D5F-4EC3-A193-BE10687D7A8C@delong.com> <-5099803936536899096@unknownmsgid><349C8AD2-9C4B-4B0F-8875-A6040341F476@delong.com><00d901cc1a8c$cd5ba260$6812e720$@iname.com> <680F5536-8FF7-48F0-9EC0-5831BEA9418F@delong.com> Message-ID: <282597B677794DB49A1E3CE343BEF17B@mike> RIPE requires their final /8 to be distributed in /22 chunks, and you have to already have an IPv6 allocation. What if they regard us as not having compatible needs requirements? What is to be gained by including that language, except to engender Inter-RIR conflict? The wording already includes both RIRs to approve the transfer. There is no definition in the policy or elsewhere in the NRPM of "compatible" needs policies. I don't see the point in including it. Mike ----- Original Message ----- From: Owen DeLong To: frnkblk at iname.com Cc: ARIN-PPML List Sent: Wednesday, May 25, 2011 12:00 PM Subject: Re: [arin-ppml] Integrating Draft Policy ARIN-2011-1 into NRPM 8.3 I would prefer since we are venturing into inter-RIR territory to have this policy be as specific and complete as possible and stand alone to the greatest possible extent. In this case, I think excessive clarity where practicable is worth while. Owen On May 24, 2011, at 8:35 PM, Frank Bulk wrote: Since currently ARIN policy implements the needs-basis, isn?t mentioning that requirement in 2011-1 redundant? Or are you concerned that some ARIN policies might remove the needs-basis requirement and you want to preserve the requirement in the inter-RIR transfer? Frank From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Owen DeLong Sent: Tuesday, May 24, 2011 12:47 AM To: Scott Leibrand Cc: ARIN-PPML List Subject: Re: [arin-ppml] Integrating Draft Policy ARIN-2011-1 into NRPM 8.3 I still would prefer to see the needs-basis comment preserved as well. Owen On May 23, 2011, at 10:07 PM, Scott Leibrand wrote: So perhaps: + to another RIR, for transfer to a specified recipient in that RIR's service region, if both RIRs agree and the request meets both RIRs' transfer policies. I agree it's useful to preserve discretion. I think I might prefer this to the text I originally had below... Thoughts? Scott On May 23, 2011, at 9:56 PM, Owen DeLong wrote: I prefer to preserve the safety valve of requiring agreement from both RIRs. Owen On May 23, 2011, at 8:53 PM, Frank Bulk wrote: Why don?t we change the second point to: + to another RIR, for transfer to a specified recipient in that RIR's service region, if the request meets both RIRS? transfer policies. Frank ----- Original Message ----- From: Scott Leibrand To: Owen DeLong Cc: ARIN-PPML List Sent: Monday, May 23, 2011 5:21 PM Subject: Re: [arin-ppml] Integrating Draft Policy ARIN-2011-1 into NRPM 8.3 On Mon, May 23, 2011 at 2:05 PM, Owen DeLong wrote: I could support this, but, I have a couple of lingering concerns. I think that the last sentence dictates too much in the case of a transfer to another region and should only apply to transfers within the ARIN region. Yeah, I was wondering about that myself. Possible slight revision inline below... On May 23, 2011, at 15:54, Scott Leibrand wrote: In light of the discomfort a number of community and AC members feel with the original 2011-1 text, I thought I'd make an attempt at integrating it into the framework of NRPM 8.3, to see if the result would be tighter and less ambiguous. Here's what I came up with: 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, in whole or in part, for transfer: a.. to a specified organizational recipient within the ARIN region, or b.. to another RIR, for transfer to a specified organizational recipient in that RIR's service region, if the two RIRs agree and maintain compatible, needs-based transfer policies. Such transferred number resources may only be received under RSA by organizations that can demonstrate the need for such resources, as a single aggregate, in the exact amount which they can justify under current ARIN policies. How about "Such number resources may only be received under RSA by organizations that can demonstrate the need for such resources, as a single aggregate, in the exact amount which they can justify under current ARIN, or recipient RIR, policies." ? Or, feel free to suggest text... -Scott For reference, existing policy reads: 8.3. Transfers to Specified Recipients In addition to transfers under section 8.2, IPv4 number resources within the ARIN region may be released to ARIN by the authorized resource holder, in whole or in part, for transfer to another specified organizational recipient. Such transferred number resources may only be received under RSA by organizations that are within the ARIN region and can demonstrate the need for such resources, as a single aggregate, in the exact amount which they can justify under current ARIN policies. And original 2011-1 text reads: Any RIR's resource registrant may transfer IPv4 addresses to the resource registrant of another RIR as long as the two RIRs agree and maintain compatible, needs-based transfer policies that exercise Internet stewardship consistent with the values expressed in RFC2050. _______________________________________________ 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. _______________________________________________ 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 owen at delong.com Wed May 25 13:57:22 2011 From: owen at delong.com (Owen DeLong) Date: Wed, 25 May 2011 10:57:22 -0700 Subject: [arin-ppml] Integrating Draft Policy ARIN-2011-1 into NRPM 8.3 In-Reply-To: <282597B677794DB49A1E3CE343BEF17B@mike> References: <07DCA09506E941C3AEE0B6562DF8DB4E@mike> <00ac01cc19c6$2c803340$858099c0$@iname.com> <0114D408-5D5F-4EC3-A193-BE10687D7A8C@delong.com> <-5099803936536899096@unknownmsgid><349C8AD2-9C4B-4B0F-8875-A6040341F476@delong.com><00d901cc1a8c$cd5ba260$6812e720$@iname.com> <680F5536-8FF7-48F0-9EC0-5831BEA9418F@delong.com> <282597B677794DB49A1E3CE343BEF17B@mike> Message-ID: It doesn't surprise me to see that we will disagree on this. Since you are opposed to needs-basis in general, I don't expect you to understand the need to preserve it here or to agree with it. Owen On May 25, 2011, at 9:21 AM, Mike Burns wrote: > RIPE requires their final /8 to be distributed in /22 chunks, and you have to already have an IPv6 allocation. > What if they regard us as not having compatible needs requirements? > What is to be gained by including that language, except to engender Inter-RIR conflict? > The wording already includes both RIRs to approve the transfer. > There is no definition in the policy or elsewhere in the NRPM of "compatible" needs policies. > I don't see the point in including it. > > Mike > > > ----- Original Message ----- > From: Owen DeLong > To: frnkblk at iname.com > Cc: ARIN-PPML List > Sent: Wednesday, May 25, 2011 12:00 PM > Subject: Re: [arin-ppml] Integrating Draft Policy ARIN-2011-1 into NRPM 8.3 > > I would prefer since we are venturing into inter-RIR territory to have this policy be as specific and complete > as possible and stand alone to the greatest possible extent. In this case, I think excessive clarity where > practicable is worth while. > > Owen > > On May 24, 2011, at 8:35 PM, Frank Bulk wrote: > >> Since currently ARIN policy implements the needs-basis, isn?t mentioning that requirement in 2011-1 redundant? Or are you concerned that some ARIN policies might remove the needs-basis requirement and you want to preserve the requirement in the inter-RIR transfer? >> Frank >> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Owen DeLong >> Sent: Tuesday, May 24, 2011 12:47 AM >> To: Scott Leibrand >> Cc: ARIN-PPML List >> Subject: Re: [arin-ppml] Integrating Draft Policy ARIN-2011-1 into NRPM 8.3 >> I still would prefer to see the needs-basis comment preserved as well. >> Owen >> On May 23, 2011, at 10:07 PM, Scott Leibrand wrote: >> >> >> So perhaps: >> + to another RIR, for transfer to a specified recipient in that RIR's service region, if both RIRs agree and the request meets both RIRs' transfer policies. >> I agree it's useful to preserve discretion. I think I might prefer this to the text I originally had below... Thoughts? >> >> Scott >> >> On May 23, 2011, at 9:56 PM, Owen DeLong wrote: >> >> I prefer to preserve the safety valve of requiring agreement from both RIRs. >> Owen >> On May 23, 2011, at 8:53 PM, Frank Bulk wrote: >> >> >> Why don?t we change the second point to: >> + to another RIR, for transfer to a specified recipient in that RIR's service >> region, if the request meets both RIRS? transfer policies. >> Frank >> ----- Original Message ----- >> From: Scott Leibrand >> To: Owen DeLong >> Cc: ARIN-PPML List >> Sent: Monday, May 23, 2011 5:21 PM >> Subject: Re: [arin-ppml] Integrating Draft Policy ARIN-2011-1 into NRPM 8.3 >> On Mon, May 23, 2011 at 2:05 PM, Owen DeLong wrote: >> I could support this, but, I have a couple of lingering concerns. >> I think that the last sentence dictates too much in the case of a transfer to another region and should only apply to transfers within the ARIN region. >> Yeah, I was wondering about that myself. Possible slight revision inline below... >> On May 23, 2011, at 15:54, Scott Leibrand wrote: >> >> In light of the discomfort a number of community and AC members feel with the original 2011-1 text, I thought I'd make an attempt at integrating it into the framework of NRPM 8.3, to see if the result would be tighter and less ambiguous. Here's what I came up with: >> 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, in whole or in part, for transfer: >> to a specified organizational recipient within the ARIN region, or >> to another RIR, for transfer to a specified organizational recipient in that RIR's service region, if the two RIRs agree and maintain compatible, needs-based transfer policies. >> Such transferred number resources may only be received under RSA by organizations that can demonstrate the need for such resources, as a single aggregate, in the exact amount which they can justify under current ARIN policies. >> How about "Such number resources may only be received under RSA by organizations that can demonstrate the need for such resources, as a single aggregate, in the exact amount which they can justify under current ARIN, or recipient RIR, policies." ? >> Or, feel free to suggest text... >> -Scott >> For reference, existing policy reads: >> 8.3. Transfers to Specified Recipients >> >> In addition to transfers under section 8.2, IPv4 number resources within the ARIN region may be released to ARIN by the authorized resource holder, in whole or in part, for transfer to another specified organizational recipient. Such transferred number resources may only be received under RSA by organizations that are within the ARIN region and can demonstrate the need for such resources, as a single aggregate, in the exact amount which they can justify under current ARIN policies. >> And original 2011-1 text reads: >> Any RIR's resource registrant may transfer IPv4 addresses to the resource registrant of another RIR as long as the two RIRs agree and maintain compatible, needs-based transfer policies that exercise Internet stewardship consistent with the values expressed in RFC2050. >> _______________________________________________ >> 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. >> _______________________________________________ >> 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 jeffrey.lyon at blacklotus.net Wed May 25 17:06:27 2011 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Wed, 25 May 2011 17:06:27 -0400 Subject: [arin-ppml] Integrating Draft Policy ARIN-2011-1 into NRPM 8.3 In-Reply-To: References: <07DCA09506E941C3AEE0B6562DF8DB4E@mike> <00ac01cc19c6$2c803340$858099c0$@iname.com> <0114D408-5D5F-4EC3-A193-BE10687D7A8C@delong.com> <-5099803936536899096@unknownmsgid> <349C8AD2-9C4B-4B0F-8875-A6040341F476@delong.com> <00d901cc1a8c$cd5ba260$6812e720$@iname.com> <680F5536-8FF7-48F0-9EC0-5831BEA9418F@delong.com> <282597B677794DB49A1E3CE343BEF17B@mike> Message-ID: On Wed, May 25, 2011 at 1:57 PM, Owen DeLong wrote: > It doesn't surprise me to see that we will disagree on this. > Since you are opposed to needs-basis in general, I don't expect you to > understand > the need to preserve it here or to agree with it. > Owen > On May 25, 2011, at 9:21 AM, Mike Burns wrote: Similarly, I don't expect you to entertain any logic that free markets are beneficial. I suspect spending a lot of time in the Bay Area has that effect. Best regards, -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications - AS32421 First and Leading in DDoS Protection Solutions From owen at delong.com Thu May 26 01:34:44 2011 From: owen at delong.com (Owen DeLong) Date: Wed, 25 May 2011 22:34:44 -0700 Subject: [arin-ppml] Integrating Draft Policy ARIN-2011-1 into NRPM 8.3 In-Reply-To: References: <07DCA09506E941C3AEE0B6562DF8DB4E@mike> <00ac01cc19c6$2c803340$858099c0$@iname.com> <0114D408-5D5F-4EC3-A193-BE10687D7A8C@delong.com> <-5099803936536899096@unknownmsgid> <349C8AD2-9C4B-4B0F-8875-A6040341F476@delong.com> <00d901cc1a8c$cd5ba260$6812e720$@iname.com> <680F5536-8FF7-48F0-9EC0-5831BEA9418F@delong.com> <282597B677794DB49A1E3CE343BEF17B@mike> Message-ID: <8DB5F2EE-8444-4CF0-8C5F-B5F48BDB3570@delong.com> On May 25, 2011, at 2:06 PM, Jeffrey Lyon wrote: > On Wed, May 25, 2011 at 1:57 PM, Owen DeLong wrote: >> It doesn't surprise me to see that we will disagree on this. >> Since you are opposed to needs-basis in general, I don't expect you to >> understand >> the need to preserve it here or to agree with it. >> Owen >> On May 25, 2011, at 9:21 AM, Mike Burns wrote: > > Similarly, I don't expect you to entertain any logic that free markets > are beneficial. I suspect spending a lot of time in the Bay Area has > that effect. > I think there are places where regulated free markets can be beneficial. If you can point to a single historical example of an unregulated free market that remained beneficial and unregulated for more than 5 years, I'll be surprised. Owen From adudek16 at gmail.com Thu May 26 15:45:33 2011 From: adudek16 at gmail.com (Aaron Dudek) Date: Thu, 26 May 2011 15:45:33 -0400 Subject: [arin-ppml] Integrating Draft Policy ARIN-2011-1 into NRPM 8.3 In-Reply-To: References: <07DCA09506E941C3AEE0B6562DF8DB4E@mike> <00ac01cc19c6$2c803340$858099c0$@iname.com> <0114D408-5D5F-4EC3-A193-BE10687D7A8C@delong.com> <-5099803936536899096@unknownmsgid> <349C8AD2-9C4B-4B0F-8875-A6040341F476@delong.com> <00d901cc1a8c$cd5ba260$6812e720$@iname.com> <680F5536-8FF7-48F0-9EC0-5831BEA9418F@delong.com> <282597B677794DB49A1E3CE343BEF17B@mike> <8DB5F2EE-8444-4CF0-8C5F-B5F48BDB3570@delong.com> Message-ID: Since we are discussing 8.3. I feel that there should be language to allow for transfers of IPv6. Currently there is no language to allow for transfers of IPv6 allocations. So essentially 8.3. Transfers to Specified Recipients In addition to transfers under section 8.2, IPv4? and IPv6 number resources within the ARIN region may be released to ARIN by the authorized resource holder, in whole or in part, for transfer to another specified organizational recipient....... The other option would to remove the version number and just leave IP number resources.... Thank you, Aaron Dudek > On Thu, May 26, 2011 at 01:34, Owen DeLong wrote: >> >> On May 25, 2011, at 2:06 PM, Jeffrey Lyon wrote: >> >> > On Wed, May 25, 2011 at 1:57 PM, Owen DeLong wrote: >> >> It doesn't surprise me to see that we will disagree on this. >> >> Since you are opposed to needs-basis in general, I don't expect you to >> >> understand >> >> the need to preserve it here or to agree with it. >> >> Owen >> >> On May 25, 2011, at 9:21 AM, Mike Burns wrote: >> > >> > Similarly, I don't expect you to entertain any logic that free markets >> > are beneficial. I suspect spending a lot of time in the Bay Area has >> > that effect. >> > >> >> I think there are places where regulated free markets can be beneficial. >> >> If you can point to a single historical example of an unregulated free >> market that >> remained beneficial and unregulated for more than 5 years, I'll be >> surprised. >> >> 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 jcurran at arin.net Thu May 26 15:54:57 2011 From: jcurran at arin.net (John Curran) Date: Thu, 26 May 2011 19:54:57 +0000 Subject: [arin-ppml] Integrating Draft Policy ARIN-2011-1 into NRPM 8.3 In-Reply-To: References: <07DCA09506E941C3AEE0B6562DF8DB4E@mike> <00ac01cc19c6$2c803340$858099c0$@iname.com> <0114D408-5D5F-4EC3-A193-BE10687D7A8C@delong.com> <-5099803936536899096@unknownmsgid> <349C8AD2-9C4B-4B0F-8875-A6040341F476@delong.com> <00d901cc1a8c$cd5ba260$6812e720$@iname.com> <680F5536-8FF7-48F0-9EC0-5831BEA9418F@delong.com> <282597B677794DB49A1E3CE343BEF17B@mike> <8DB5F2EE-8444-4CF0-8C5F-B5F48BDB3570@delong.com> Message-ID: On May 26, 2011, at 3:45 PM, Aaron Dudek wrote: > Since we are discussing 8.3. > I feel that there should be language to allow for transfers of IPv6. > Currently there is no language to allow for transfers of IPv6 allocations. > So essentially > > 8.3. Transfers to Specified Recipients > > In addition to transfers under section 8.2, IPv4 and IPv6 number resources > within the ARIN region may be released to ARIN by the authorized resource > holder, in whole or in part, for transfer to another specified > organizational recipient....... > > The other option would to remove the version number and just leave IP number > resources.... Noted. There have been some requests for IPv6 specified transfers to allow resolution of "recordkeeping" issues (just as several of the IPv4 transfers to date have been), where a party may have delegated a portion of their address space but no longer has a formal relationship to recipient and wants to permanently note the actual user of a particular address block. While not necessarily an option that will be wildly used, the ability to transfer IPv6 address blocks may improve Whois accuracy in some cases. FYI, /John John Curran President and CEO ARIN From owen at delong.com Thu May 26 16:14:10 2011 From: owen at delong.com (Owen DeLong) Date: Thu, 26 May 2011 13:14:10 -0700 Subject: [arin-ppml] Integrating Draft Policy ARIN-2011-1 into NRPM 8.3 In-Reply-To: References: <07DCA09506E941C3AEE0B6562DF8DB4E@mike> <00ac01cc19c6$2c803340$858099c0$@iname.com> <0114D408-5D5F-4EC3-A193-BE10687D7A8C@delong.com> <-5099803936536899096@unknownmsgid> <349C8AD2-9C4B-4B0F-8875-A6040341F476@delong.com> <00d901cc1a8c$cd5ba260$6812e720$@iname.com> <680F5536-8FF7-48F0-9EC0-5831BEA9418F@delong.com> <282597B677794DB49A1E3CE343BEF17B@mike> <8DB5F2EE-8444-4CF0-8C5F-B5F48BDB3570@delong.com> Message-ID: <6CDF97E7-11C5-486D-9ECD-ADB4A215DDF1@delong.com> On May 26, 2011, at 12:45 PM, Aaron Dudek wrote: > Since we are discussing 8.3. > I feel that there should be language to allow for transfers of IPv6. > Currently there is no language to allow for transfers of IPv6 allocations. > So essentially > IMHO, there should not. The need to facilitate directed transfers in IPv4 is strictly a result of the intersection of legacy addresses and failure to have a strong mechanism for address policy with legacy resources combined with the shortage of addresses. Neither of these factors applies to IPv6 and such transfers have no positive effect. Owen > 8.3. Transfers to Specified Recipients > > In addition to transfers under section 8.2, IPv4 and IPv6 number resources > within the ARIN region may be released to ARIN by the authorized resource > holder, in whole or in part, for transfer to another specified > organizational recipient....... > > The other option would to remove the version number and just leave IP number > resources.... > > Thank you, > > Aaron Dudek > >> On Thu, May 26, 2011 at 01:34, Owen DeLong wrote: >>> >>> On May 25, 2011, at 2:06 PM, Jeffrey Lyon wrote: >>> >>>> On Wed, May 25, 2011 at 1:57 PM, Owen DeLong wrote: >>>>> It doesn't surprise me to see that we will disagree on this. >>>>> Since you are opposed to needs-basis in general, I don't expect you to >>>>> understand >>>>> the need to preserve it here or to agree with it. >>>>> Owen >>>>> On May 25, 2011, at 9:21 AM, Mike Burns wrote: >>>> >>>> Similarly, I don't expect you to entertain any logic that free markets >>>> are beneficial. I suspect spending a lot of time in the Bay Area has >>>> that effect. >>>> >>> >>> I think there are places where regulated free markets can be beneficial. >>> >>> If you can point to a single historical example of an unregulated free >>> market that >>> remained beneficial and unregulated for more than 5 years, I'll be >>> surprised. >>> >>> 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. >> >> > _______________________________________________ > 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 cgrundemann at gmail.com Thu May 26 16:19:37 2011 From: cgrundemann at gmail.com (Chris Grundemann) Date: Thu, 26 May 2011 14:19:37 -0600 Subject: [arin-ppml] Integrating Draft Policy ARIN-2011-1 into NRPM 8.3 In-Reply-To: <282597B677794DB49A1E3CE343BEF17B@mike> References: <07DCA09506E941C3AEE0B6562DF8DB4E@mike> <00ac01cc19c6$2c803340$858099c0$@iname.com> <0114D408-5D5F-4EC3-A193-BE10687D7A8C@delong.com> <-5099803936536899096@unknownmsgid> <349C8AD2-9C4B-4B0F-8875-A6040341F476@delong.com> <00d901cc1a8c$cd5ba260$6812e720$@iname.com> <680F5536-8FF7-48F0-9EC0-5831BEA9418F@delong.com> <282597B677794DB49A1E3CE343BEF17B@mike> Message-ID: On Wed, May 25, 2011 at 10:21, Mike Burns wrote: > What is to be gained by including that language, except to engender > Inter-RIR conflict? > The wording already includes both RIRs to approve the transfer. > There is no definition in the policy or elsewhere in the?NRPM?of > "compatible" needs policies. > I don't see the point in including it. The point of that statement is to signal the intentions of the ARIN community both to ARIN staff and to other RIRs. It provides guidance to ARIN staff that they should not agree to any transfer that does not include needs-based policy on the recipient end. It also ensures that recipients in other regions will not be surprised when a transfer is denied for lack of said needs-based policies. The point, in short, is clarity and transparency. Cheers, ~Chris > Mike > > _______________________________________________ > 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 weblog.chrisgrundemann.com www.burningwiththebush.com www.theIPv6experts.net www.coisoc.org From mike at nationwideinc.com Thu May 26 17:28:59 2011 From: mike at nationwideinc.com (Mike Burns) Date: Thu, 26 May 2011 17:28:59 -0400 Subject: [arin-ppml] Integrating Draft Policy ARIN-2011-1 into NRPM 8.3 References: <07DCA09506E941C3AEE0B6562DF8DB4E@mike> <00ac01cc19c6$2c803340$858099c0$@iname.com><0114D408-5D5F-4EC3-A193-BE10687D7A8C@delong.com><-5099803936536899096@unknownmsgid> <349C8AD2-9C4B-4B0F-8875-A6040341F476@delong.com><00d901cc1a8c$cd5ba260$6812e720$@iname.com><680F5536-8FF7-48F0-9EC0-5831BEA941 8F@delong.com><282597B677794DB49A1E3CE343BEF17B@mike> Message-ID: <0A2DA7DD4C6443EA98172A5EFBE04A38@mike> > What is to be gained by including that language, except to engender > Inter-RIR conflict? > The wording already includes both RIRs to approve the transfer. > There is no definition in the policy or elsewhere in the NRPM of > "compatible" needs policies. > I don't see the point in including it. The point of that statement is to signal the intentions of the ARIN community both to ARIN staff and to other RIRs. It provides guidance to ARIN staff that they should not agree to any transfer that does not include needs-based policy on the recipient end. It also ensures that recipients in other regions will not be surprised when a transfer is denied for lack of said needs-based policies. The point, in short, is clarity and transparency. Cheers, ~Chris Hi Chris, But how clear is it exactly? Do you mean it to signal that *any* needs test is compatible? If that is the intent, then I think the language can be clearer. If you want clarity, then using a subjective word like "compatible" which is undefined in the proposal is sub-optimal. Since its definition and application is left to ARIN staff, and ARIN staff is required to decide on transfer approval anyway, I don't see any great clarity or transparency. What I do see reads like a political statement added onto a policy proposal, to no real effect except to exacerbate inter-RIR tensions. What better way to incite the APNIC stewards to unilaterally decide to accept transfers into their region of legacy space with no RSA in place? This is currently a lacuna in policy awaiting a test case, as far as I know. It's not like there are hundreds of different transfer policies, I'm sure those requesting inter-RIR transfers will be aware of the current policies without brandishing our disdain for their version of stewardship in additional and functionally inoperative language. Regards, Mike From owen at delong.com Thu May 26 19:12:19 2011 From: owen at delong.com (Owen DeLong) Date: Thu, 26 May 2011 16:12:19 -0700 Subject: [arin-ppml] Integrating Draft Policy ARIN-2011-1 into NRPM 8.3 In-Reply-To: <0A2DA7DD4C6443EA98172A5EFBE04A38@mike> References: <07DCA09506E941C3AEE0B6562DF8DB4E@mike> <00ac01cc19c6$2c803340$858099c0$@iname.com><0114D408-5D5F-4EC3-A193-BE10687D7A8C@delong.com><-5099803936536899096@unknownmsgid> <349C8AD2-9C4B-4B0F-8875-A6040341F476@delong.com><00d901cc1a8c$cd5ba260$6812e720$@iname.com><680F5536-8FF7-48F0-9EC0-5831BEA941 8F@delong.com><282597B677794DB49A1E3CE343BEF17B@mike> <0A2DA7DD4C6443EA98172A5EFBE04A38@mike> Message-ID: <7B8D537D-82BD-4473-8B5C-1170D88DD1EF@delong.com> On May 26, 2011, at 2:28 PM, Mike Burns wrote: >> What is to be gained by including that language, except to engender >> Inter-RIR conflict? >> The wording already includes both RIRs to approve the transfer. >> There is no definition in the policy or elsewhere in the NRPM of >> "compatible" needs policies. >> I don't see the point in including it. > > The point of that statement is to signal the intentions of the ARIN > community both to ARIN staff and to other RIRs. It provides guidance > to ARIN staff that they should not agree to any transfer that does not > include needs-based policy on the recipient end. It also ensures that > recipients in other regions will not be surprised when a transfer is > denied for lack of said needs-based policies. The point, in short, is > clarity and transparency. > > Cheers, > ~Chris > > > Hi Chris, > > But how clear is it exactly? Pretty clear, actually. Especially to the RIRs whose staff have a pretty good understanding of what we mean. > Do you mean it to signal that *any* needs test is compatible? I believe that all of the RIRs would consider the current needs-basis in the other RIRs to be compatible. They are relatively similar. The incompatibility that exists today to the best of my knowledge would be limited to APNIC where their transfer policy contains the same defect you are proposing to add to ARIN policy. However, I can imagine needs tests that could be devised that would be incompatible. > If that is the intent, then I think the language can be clearer. It isn't the exact intent. > If you want clarity, then using a subjective word like "compatible" which is undefined in the proposal is sub-optimal. We want greater clarity than we can achieve without it. Due to the dynamic nature of the situation, however, perfect clarity would be suboptimal, even if it could be achieved. > Since its definition and application is left to ARIN staff, and ARIN staff is required to decide on transfer approval anyway, I don't see any great clarity or transparency. Actually, it is left to the staff of both RIRs, but, this still serves as notice to ARIN staff that they must include this test in one of their considerations of whether or not to approve the transfer. Without it, ARIN might not consider that one of the necessary items for approval. > What I do see reads like a political statement added onto a policy proposal, to no real effect except to exacerbate inter-RIR tensions. Perhaps this comes from your unique perspective which doesn't seem to be shared by the RIRs. > What better way to incite the APNIC stewards to unilaterally decide to accept transfers into their region of legacy space with no RSA in place? There's really no facility for them to do so and short of passing a policy that specifically permitted that in the ARIN region, I do not believe they would act in such a manner. > This is currently a lacuna in policy awaiting a test case, as far as I know. > "Lacuna policy"? Not familiar with the term and couldn't find a reference with a quick google. > It's not like there are hundreds of different transfer policies, I'm sure those requesting inter-RIR transfers will be aware of the current policies without brandishing our disdain for their version of stewardship in additional and functionally inoperative language. > It is neither functionally inoperative, nor a statement of disdain. It is a statement of intent. Nothing more, nothing less. Owen From adudek16 at gmail.com Thu May 26 21:44:06 2011 From: adudek16 at gmail.com (Aaron Dudek) Date: Thu, 26 May 2011 21:44:06 -0400 Subject: [arin-ppml] Integrating Draft Policy ARIN-2011-1 into NRPM 8.3 In-Reply-To: <6CDF97E7-11C5-486D-9ECD-ADB4A215DDF1@delong.com> References: <07DCA09506E941C3AEE0B6562DF8DB4E@mike> <00ac01cc19c6$2c803340$858099c0$@iname.com> <0114D408-5D5F-4EC3-A193-BE10687D7A8C@delong.com> <-5099803936536899096@unknownmsgid> <349C8AD2-9C4B-4B0F-8875-A6040341F476@delong.com> <00d901cc1a8c$cd5ba260$6812e720$@iname.com> <680F5536-8FF7-48F0-9EC0-5831BEA9418F@delong.com> <282597B677794DB49A1E3CE343BEF17B@mike> <8DB5F2EE-8444-4CF0-8C5F-B5F48BDB3570@delong.com> <6CDF97E7-11C5-486D-9ECD-ADB4A215DDF1@delong.com> Message-ID: Currently the only way to transfer owner ship is through 8.2 Mergers and Acquisitions. Company A received an initial allocation. Company B received a significant allocation from Company A. Company A goes out of business. There is no method for company B to take over the block from company A. Company A has to migrate to a larger block. There is no method for company B to take over the block from company A. These are just a couple of examples. ARIN still has the final say of any transfers as per the rest of 8.3 as the "new owner" has to show need and justification just as before. Aaron On Thu, May 26, 2011 at 16:14, Owen DeLong wrote: > > On May 26, 2011, at 12:45 PM, Aaron Dudek wrote: > >> Since we are discussing 8.3. >> I feel that there should be language to allow for transfers of IPv6. >> Currently there is no language to allow for transfers of IPv6 allocations. >> So essentially >> > > IMHO, there should not. The need to facilitate directed transfers > in IPv4 is strictly a result of the intersection of legacy addresses and > failure to have a strong mechanism for address policy with legacy > resources combined with the shortage of addresses. > > Neither of these factors applies to IPv6 and such transfers have no > positive effect. > > Owen > > >> 8.3. Transfers to Specified Recipients >> >> In addition to transfers under section 8.2, IPv4 ?and IPv6 number resources >> within the ARIN region may be released to ARIN by the authorized resource >> holder, in whole or in part, for transfer to another specified >> organizational recipient....... >> >> The other option would to remove the version number and just leave IP number >> resources.... >> >> Thank you, >> >> Aaron Dudek >> >>> On Thu, May 26, 2011 at 01:34, Owen DeLong wrote: >>>> >>>> On May 25, 2011, at 2:06 PM, Jeffrey Lyon wrote: >>>> >>>>> On Wed, May 25, 2011 at 1:57 PM, Owen DeLong wrote: >>>>>> It doesn't surprise me to see that we will disagree on this. >>>>>> Since you are opposed to needs-basis in general, I don't expect you to >>>>>> understand >>>>>> the need to preserve it here or to agree with it. >>>>>> Owen >>>>>> On May 25, 2011, at 9:21 AM, Mike Burns wrote: >>>>> >>>>> Similarly, I don't expect you to entertain any logic that free markets >>>>> are beneficial. I suspect spending a lot of time in the Bay Area has >>>>> that effect. >>>>> >>>> >>>> I think there are places where regulated free markets can be beneficial. >>>> >>>> If you can point to a single historical example of an unregulated free >>>> market that >>>> remained beneficial and unregulated for more than 5 years, I'll be >>>> surprised. >>>> >>>> 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. >>> >>> >> _______________________________________________ >> 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 27 00:09:14 2011 From: owen at delong.com (Owen DeLong) Date: Thu, 26 May 2011 21:09:14 -0700 Subject: [arin-ppml] Integrating Draft Policy ARIN-2011-1 into NRPM 8.3 In-Reply-To: References: <07DCA09506E941C3AEE0B6562DF8DB4E@mike> <00ac01cc19c6$2c803340$858099c0$@iname.com> <0114D408-5D5F-4EC3-A193-BE10687D7A8C@delong.com> <-5099803936536899096@unknownmsgid> <349C8AD2-9C4B-4B0F-8875-A6040341F476@delong.com> <00d901cc1a8c$cd5ba260$6812e720$@iname.com> <680F5536-8FF7-48F0-9EC0-5831BEA9418F@delong.com> <282597B677794DB49A1E3CE343BEF17B@mike> <8DB5F2EE-8444-4CF0-8C5F-B5F48BDB3570@delong.com> <6CDF97E7-11C5-486D-9ECD-ADB4A215DDF1@delong.com> Message-ID: On May 26, 2011, at 6:44 PM, Aaron Dudek wrote: > Currently the only way to transfer owner ship is through 8.2 Mergers > and Acquisitions. > Company A received an initial allocation. Company B received a > significant allocation from Company A. > > Company A goes out of business. There is no method for company B to > take over the block from company A. If company B has a large enough need to meet the criteria for a direct assignment (I doubt they received an allocation as you describe), then, why didn't they go to ARIN instead of Company A? If they didn't meet and/or don't meet the criteria, then, why should they be able to transfer a smaller netblock rather than renumber as an end-run on policy? I don't think that B's poor planning is something we should codify in ARIN policy. > Company A has to migrate to a larger block. There is no method for > company B to take over the block from company A. > Right. I think this falls into the same answers as above. > These are just a couple of examples. > ARIN still has the final say of any transfers as per the rest of 8.3 > as the "new owner" has to show need and justification just as before. > ARIN policy has the final say. ARIN's ability to say no is limited to exactly those things proscribed by policy, not even the ones obviously intended to be proscribed by policy as recent experience has shown. Owen > Aaron > > On Thu, May 26, 2011 at 16:14, Owen DeLong wrote: >> >> On May 26, 2011, at 12:45 PM, Aaron Dudek wrote: >> >>> Since we are discussing 8.3. >>> I feel that there should be language to allow for transfers of IPv6. >>> Currently there is no language to allow for transfers of IPv6 allocations. >>> So essentially >>> >> >> IMHO, there should not. The need to facilitate directed transfers >> in IPv4 is strictly a result of the intersection of legacy addresses and >> failure to have a strong mechanism for address policy with legacy >> resources combined with the shortage of addresses. >> >> Neither of these factors applies to IPv6 and such transfers have no >> positive effect. >> >> Owen >> >> >>> 8.3. Transfers to Specified Recipients >>> >>> In addition to transfers under section 8.2, IPv4 and IPv6 number resources >>> within the ARIN region may be released to ARIN by the authorized resource >>> holder, in whole or in part, for transfer to another specified >>> organizational recipient....... >>> >>> The other option would to remove the version number and just leave IP number >>> resources.... >>> >>> Thank you, >>> >>> Aaron Dudek >>> >>>> On Thu, May 26, 2011 at 01:34, Owen DeLong wrote: >>>>> >>>>> On May 25, 2011, at 2:06 PM, Jeffrey Lyon wrote: >>>>> >>>>>> On Wed, May 25, 2011 at 1:57 PM, Owen DeLong wrote: >>>>>>> It doesn't surprise me to see that we will disagree on this. >>>>>>> Since you are opposed to needs-basis in general, I don't expect you to >>>>>>> understand >>>>>>> the need to preserve it here or to agree with it. >>>>>>> Owen >>>>>>> On May 25, 2011, at 9:21 AM, Mike Burns wrote: >>>>>> >>>>>> Similarly, I don't expect you to entertain any logic that free markets >>>>>> are beneficial. I suspect spending a lot of time in the Bay Area has >>>>>> that effect. >>>>>> >>>>> >>>>> I think there are places where regulated free markets can be beneficial. >>>>> >>>>> If you can point to a single historical example of an unregulated free >>>>> market that >>>>> remained beneficial and unregulated for more than 5 years, I'll be >>>>> surprised. >>>>> >>>>> 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. >>>> >>>> >>> _______________________________________________ >>> PPML >>> You are receiving this message because you are subscribed to >>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >>> Unsubscribe or manage your mailing list subscription at: >>> http://lists.arin.net/mailman/listinfo/arin-ppml >>> Please contact info at arin.net if you experience any issues. >> >> From narten at us.ibm.com Fri May 27 00:53:03 2011 From: narten at us.ibm.com (Thomas Narten) Date: Fri, 27 May 2011 00:53:03 -0400 Subject: [arin-ppml] Weekly posting summary for ppml@arin.net Message-ID: <201105270453.p4R4r3Pl007348@rotala.raleigh.ibm.com> Total of 129 messages in the last 7 days. script run at: Fri May 27 00:53:02 EDT 2011 Messages | Bytes | Who --------+------+--------+----------+------------------------ 27.91% | 36 | 37.07% | 683719 | owen at delong.com 17.05% | 22 | 16.68% | 307710 | mike at nationwideinc.com 5.43% | 7 | 8.00% | 147637 | scottleibrand at gmail.com 3.10% | 4 | 8.24% | 151925 | frnkblk at iname.com 6.98% | 9 | 3.30% | 60799 | jcurran at arin.net 4.65% | 6 | 2.67% | 49163 | cengel at conxeo.com 4.65% | 6 | 2.16% | 39783 | mysidia at gmail.com 4.65% | 6 | 1.95% | 35892 | matthew at matthew.at 3.88% | 5 | 2.67% | 49266 | springer at inlandnet.com 2.33% | 3 | 3.43% | 63230 | tvest at eyeconomics.com 2.33% | 3 | 1.90% | 35129 | info at arin.net 2.33% | 3 | 1.44% | 26564 | kkargel at polartel.com 2.33% | 3 | 1.27% | 23505 | dogwallah at gmail.com 1.55% | 2 | 1.73% | 31841 | jeffrey.lyon at blacklotus.net 2.33% | 3 | 0.70% | 12989 | astiver at forumhealth.org 1.55% | 2 | 0.90% | 16579 | adudek16 at gmail.com 0.78% | 1 | 1.35% | 24922 | hannigan at gmail.com 0.78% | 1 | 1.29% | 23747 | billd at cait.wustl.edu 0.78% | 1 | 1.03% | 19014 | rudi.daniel at gmail.com 0.78% | 1 | 0.42% | 7780 | narten at us.ibm.com 0.78% | 1 | 0.38% | 7000 | ikiris at gmail.com 0.78% | 1 | 0.37% | 6858 | lar at mwtcorp.net 0.78% | 1 | 0.36% | 6713 | cgrundemann at gmail.com 0.78% | 1 | 0.36% | 6649 | carlosm3011 at gmail.com 0.78% | 1 | 0.32% | 5953 | rbf+arin-ppml at panix.com --------+------+--------+----------+------------------------ 100.00% | 129 |100.00% | 1844367 | Total From BillD at cait.wustl.edu Fri May 27 07:38:57 2011 From: BillD at cait.wustl.edu (Bill Darte) Date: Fri, 27 May 2011 06:38:57 -0500 Subject: [arin-ppml] Integrating Draft Policy ARIN-2011-1 into NRPM 8.3 References: <07DCA09506E941C3AEE0B6562DF8DB4E@mike><00ac01cc19c6$2c803340$858099c0$@iname.com><0114D408-5D5F-4EC3-A193-BE10687D7A8C@delong.com><-5099803936536899096@unknownmsgid><349C8AD2-9C4B-4B0F-8875-A6040341F476@delong.com><00d901cc1a8c$cd5ba260$6812e720$@iname.com><680F5536-8FF7-48F0-9EC0-5831BEA9418F@delong.com><282597B677794DB49A1E3CE343BEF17B@mike> <0A2DA7DD4C6443EA98172A5EFBE04A38@mike> Message-ID: The word you say is subjective...'compatible'... in the DP is interpreted by.. 'that exercise Internet stewardship consistent with the values expressed in RFC2050' -----Original Message----- From: arin-ppml-bounces at arin.net on behalf of Mike Burns Sent: Thu 5/26/2011 4:28 PM To: Chris Grundemann Cc: ARIN-PPML List Subject: Re: [arin-ppml] Integrating Draft Policy ARIN-2011-1 into NRPM 8.3 > What is to be gained by including that language, except to engender > Inter-RIR conflict? > The wording already includes both RIRs to approve the transfer. > There is no definition in the policy or elsewhere in the NRPM of > "compatible" needs policies. > I don't see the point in including it. The point of that statement is to signal the intentions of the ARIN community both to ARIN staff and to other RIRs. It provides guidance to ARIN staff that they should not agree to any transfer that does not include needs-based policy on the recipient end. It also ensures that recipients in other regions will not be surprised when a transfer is denied for lack of said needs-based policies. The point, in short, is clarity and transparency. Cheers, ~Chris Hi Chris, But how clear is it exactly? Do you mean it to signal that *any* needs test is compatible? If that is the intent, then I think the language can be clearer. If you want clarity, then using a subjective word like "compatible" which is undefined in the proposal is sub-optimal. Since its definition and application is left to ARIN staff, and ARIN staff is required to decide on transfer approval anyway, I don't see any great clarity or transparency. What I do see reads like a political statement added onto a policy proposal, to no real effect except to exacerbate inter-RIR tensions. What better way to incite the APNIC stewards to unilaterally decide to accept transfers into their region of legacy space with no RSA in place? This is currently a lacuna in policy awaiting a test case, as far as I know. It's not like there are hundreds of different transfer policies, I'm sure those requesting inter-RIR transfers will be aware of the current policies without brandishing our disdain for their version of stewardship in additional and functionally inoperative language. Regards, Mike _______________________________________________ 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 info at arin.net Fri May 27 09:31:05 2011 From: info at arin.net (ARIN) Date: Fri, 27 May 2011 09:31:05 -0400 Subject: [arin-ppml] ARIN-prop-152 RSA Modification Limits Message-ID: <4DDFA799.6060005@arin.net> ARIN-prop-152 RSA Modification Limits 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-152 RSA Modification Limits Proposal Originator: Owen DeLong Proposal Version: 1 Date: 27 May 2011 Proposal type: new Policy term: permanent Policy statement: Add the following to section 8.1 of the NRPM All transfers conducted under section 8 of the NRPM shall require the recipient to sign an RSA which provides at least the same limitations and restrictions as the standard RSA that would be used with any new allocation or assignment of number resources in at least the following areas: a. Justified Need Requirements b. Subject to and Effect of NRPM 12 c. Requirement for an annual fee to be paid d. Subject to future policy revisions adopted by the community The above requirements may be waived to the extent necessary to meet a court order or settlement, but, such court order must be public or such settlement must include terms allowing the settlement terms to be published by ARIN, including the list of affected addresses and the exact resulting RSA. ARIN shall publish the terms of any such settlement and the resulting RSA within 10 days of drafting the settlement or RSA whichever comes later. Rationale: There have been a tremendous number of questions of late as to whether ARIN policies were followed and to what extent the modified LRSA issued to some transfer recipients allows such policy to be enforced. Since it is not possible to make the modified LRSAs public and it is not possible for the community to exercise any form of independent verification or validation of staff actions, this policy serves to provide guidelines and set limits on the extent to which an RSA can be modified to meet the needs of a transfer. Timetable for implementation: Immediate From info at arin.net Fri May 27 09:31:18 2011 From: info at arin.net (ARIN) Date: Fri, 27 May 2011 09:31:18 -0400 Subject: [arin-ppml] ARIN-prop-153 Correct erroneous syntax in NRPM 8.3 Message-ID: <4DDFA7A6.105@arin.net> ARIN-prop-153 Correct erroneous syntax in NRPM 8.3 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-153 Correct erroneous syntax in NRPM 8.3 Proposal Originator: Owen DeLong Proposal Version: 1 Date: 27 May 2011 Proposal type: new Policy term: permanent Policy statement: Change NPRM 8.3 to read: 8.3. Transfers to Specified Recipients In addition to transfers under section 8.2, IPv4 number resources within the ARIN region may be released to ARIN by the authorized resource holder, in whole or in part, for transfer to another specified organizational recipient. Such transferred number resources may only be received under RSA as a single aggregate, in the exact amount which they can justify under current ARIN policies by organizations that are within the ARIN region. Rationale: Recent events have shown that the legal construction of NRPM 8.3 did not accomplish the clear and obvious intent which achieved consensus in the community when the policy was adopted. The above re-ordering of the exact same words (modulo a deleted "and") should ensure proper binding of the single-aggregate clause as originally intended. Timetable for implementation: Immediate From mike at nationwideinc.com Fri May 27 10:15:35 2011 From: mike at nationwideinc.com (Mike Burns) Date: Fri, 27 May 2011 10:15:35 -0400 Subject: [arin-ppml] Integrating Draft Policy ARIN-2011-1 into NRPM 8.3 References: <07DCA09506E941C3AEE0B6562DF8DB4E@mike> <00ac01cc19c6$2c803340$858099c0$@iname.com><0114D408-5D5F-4EC3-A193-BE10687D7A8C@delong.com><-5099803936536899096@unknownmsgid> <349C8AD2-9C4B-4B0F-8875-A6040341F476@delong.com><00d901cc1a8c$cd5ba260$6812e720$@iname.com><680F5536-8FF7-48F0-9EC0-5831BEA941 8F@delong.com><282597B677794DB49A1E3CE343BEF17B@mike> <0A2DA7DD4C6443EA98172A5EFBE04A38@mike> Message-ID: <3D07D5E448F14437B85F94B95A62976A@mike> RE: [arin-ppml] Integrating Draft Policy ARIN-2011-1 into NRPM 8.3Hi Bill, It's still not clear to me. Referencing "values" of an RFC is not terribly clarifying when attempting to match transfer needs requirements which already are out of sync with RFC2050's 1 year window. And anyway, I say that requiring a needs test is *NOT* consistent with the values expressed here in RFC2050: 4. Operational Guidelines For Registries 1. Regional Registries provide registration services as its primary function. By requiring a needs test for inter-RIR transfers, we run the risk of driving these transfers off the books in contravention of our PRIMARY function as stewards. Just so we all understand. APNIC has a great need, and probably less underutilized addresses in its market to supply that need. A good chunk of available space is likely to be found in the legacy pools which are overrepresented in our region. The majority of this legacy space is not under any RSA with any RIR. You can route legacy space from inside Asia. A likely action that will occur is the purchases of address blocks from legacy holders which will be routed in Asia by network operators there, but ARIN will not be notified and Whois will not be updated. I have said that I think we are moving into a future with more, rather than less, conflict over IPv4 address control. This is only to be expected, as the availability of free pool addresses has always provided a replacement option for any addresses in conflict. In addition, the underlying monetary value of address control, once understood, provides ample motive to drive conflict. In an age of conflict, the accuracy of Whois will be related to the level of trust afforded to it. The absence of a strong trust authority could open the doors to a private registry. Suppose there is conflict between private organizations over address control. Then add to that conflict between RIRs over which registry is the authoritative. What is to stop a real international trust authority, say Lloyds of London, from using its trust to establish a pricey but generally recognized registry? Or even worse, what if the door is opened to the ITU to claim the RIR system was failing in a post-exhaust era, and seek to create its own registry system, or otherwise take control? Once again, I make the point that a market in IPv4 addresses, such as envisaged in 8.3 or in the APNIC transfer policy, meets the stewardship goal of conservation through natural market forces. If we ladle on an extra helping of steward meddling, we are taking action in contravention of our primary duty to maintain a viable and trusted registry. So I would support the proposal if the requirement was simply that both RIRs approve, leaving off the "signal" sent by the needs language, which signal reads like a shot across the bow to me. Regards, Mike ----- Original Message ----- From: Bill Darte To: Mike Burns ; Chris Grundemann Cc: ARIN-PPML List Sent: Friday, May 27, 2011 7:38 AM Subject: RE: [arin-ppml] Integrating Draft Policy ARIN-2011-1 into NRPM 8.3 The word you say is subjective...'compatible'... in the DP is interpreted by.. 'that exercise Internet stewardship consistent with the values expressed in RFC2050' -----Original Message----- From: arin-ppml-bounces at arin.net on behalf of Mike Burns Sent: Thu 5/26/2011 4:28 PM To: Chris Grundemann Cc: ARIN-PPML List Subject: Re: [arin-ppml] Integrating Draft Policy ARIN-2011-1 into NRPM 8.3 > What is to be gained by including that language, except to engender > Inter-RIR conflict? > The wording already includes both RIRs to approve the transfer. > There is no definition in the policy or elsewhere in the NRPM of > "compatible" needs policies. > I don't see the point in including it. The point of that statement is to signal the intentions of the ARIN community both to ARIN staff and to other RIRs. It provides guidance to ARIN staff that they should not agree to any transfer that does not include needs-based policy on the recipient end. It also ensures that recipients in other regions will not be surprised when a transfer is denied for lack of said needs-based policies. The point, in short, is clarity and transparency. Cheers, ~Chris Hi Chris, But how clear is it exactly? Do you mean it to signal that *any* needs test is compatible? If that is the intent, then I think the language can be clearer. If you want clarity, then using a subjective word like "compatible" which is undefined in the proposal is sub-optimal. Since its definition and application is left to ARIN staff, and ARIN staff is required to decide on transfer approval anyway, I don't see any great clarity or transparency. What I do see reads like a political statement added onto a policy proposal, to no real effect except to exacerbate inter-RIR tensions. What better way to incite the APNIC stewards to unilaterally decide to accept transfers into their region of legacy space with no RSA in place? This is currently a lacuna in policy awaiting a test case, as far as I know. It's not like there are hundreds of different transfer policies, I'm sure those requesting inter-RIR transfers will be aware of the current policies without brandishing our disdain for their version of stewardship in additional and functionally inoperative language. Regards, Mike _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthew at matthew.at Fri May 27 10:33:11 2011 From: matthew at matthew.at (Matthew Kaufman) Date: Fri, 27 May 2011 16:33:11 +0200 Subject: [arin-ppml] ARIN-prop-153 Correct erroneous syntax in NRPM 8.3 In-Reply-To: <4DDFA7A6.105@arin.net> References: <4DDFA7A6.105@arin.net> Message-ID: On May 27, 2011, at 3:31 PM, ARIN wrote: > ARIN-prop-153 Correct erroneous syntax in NRPM 8.3 > I am opposed to this policy. It directly contradicts my proposal to delete the single-aggregate requirement. Also, I have noted in that proposal that the single-aggregate transfer requirement as it would apply with this proposal in effect can be trivially worked around simply by submitting a large number of individual transfers, each of which comes with justification. This just increases the amount of paperwork for both parties *and* ARIN with no other benefit. (Even the Nortel-Microsoft paperwork filed with the court talks about multiple subsequent transfers, if needed, and how payment works in this case.) Matthew Kaufman From matthew at matthew.at Fri May 27 10:35:15 2011 From: matthew at matthew.at (Matthew Kaufman) Date: Fri, 27 May 2011 16:35:15 +0200 Subject: [arin-ppml] ARIN-prop-152 RSA Modification Limits In-Reply-To: <4DDFA799.6060005@arin.net> References: <4DDFA799.6060005@arin.net> Message-ID: <4B0472A3-14D8-46E4-8D03-DD860428DA1D@matthew.at> On May 27, 2011, at 3:31 PM, ARIN wrote: > ARIN-prop-152 RSA Modification Limits > I am opposed to this proposal as I believe it places ARIN in an untenable position that will then force ARIN to violate policy in order to comply with legal requirements and advice. At best, some parts of this should be a matter for ASCP... none is appropriate for the PDP. Matthew Kaufman From ikiris at gmail.com Fri May 27 10:36:49 2011 From: ikiris at gmail.com (Blake Dunlap) Date: Fri, 27 May 2011 09:36:49 -0500 Subject: [arin-ppml] ARIN-prop-153 Correct erroneous syntax in NRPM 8.3 In-Reply-To: References: <4DDFA7A6.105@arin.net> Message-ID: To keep companies from gaming transfers with multiple discreet requests, perhaps add a blackout period for transfers then after each transfer? While I tend to disagree with the single aggregate clause itself, I do wish to see the goals of the community met as desired. -Blake On Fri, May 27, 2011 at 09:33, Matthew Kaufman wrote: > > On May 27, 2011, at 3:31 PM, ARIN wrote: > > > ARIN-prop-153 Correct erroneous syntax in NRPM 8.3 > > > > I am opposed to this policy. It directly contradicts my proposal to delete > the single-aggregate requirement. > > Also, I have noted in that proposal that the single-aggregate transfer > requirement as it would apply with this proposal in effect can be trivially > worked around simply by submitting a large number of individual transfers, > each of which comes with justification. This just increases the amount of > paperwork for both parties *and* ARIN with no other benefit. > > (Even the Nortel-Microsoft paperwork filed with the court talks about > multiple subsequent transfers, if needed, and how payment works in this > case.) > > Matthew Kaufman > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike at nationwideinc.com Fri May 27 10:43:08 2011 From: mike at nationwideinc.com (Mike Burns) Date: Fri, 27 May 2011 10:43:08 -0400 Subject: [arin-ppml] ARIN-prop-153 Correct erroneous syntax in NRPM 8.3 References: <4DDFA7A6.105@arin.net> Message-ID: <342163658FC54310912C8378B5FDFEEF@mike> Opposed. This requirement would create additional incentives for parties to engage in a deal, but to avoid telling ARIN about it. And particularly early in the transfer market, there may not be enough supply to ensure that every sized single-aggregate will be available for the same cost as the sum of a bunch of smaller purchases. What does the buyer do then? In other words, supposed the buyer is sized like Microsoft and has a need for 660,000 addresses? How long must they wait for a seller to appear? The effect of this policy would be for an entity with justified needs to be unable to use an aggregate of smaller, but available blocks, and for those smaller blocks to be left on the sidelines. Neither of these things comports with our role as stewards to get addresses into productive use. -Mike Burns ----- Original Message ----- From: "Matthew Kaufman" To: "ARIN" Cc: Sent: Friday, May 27, 2011 10:33 AM Subject: Re: [arin-ppml] ARIN-prop-153 Correct erroneous syntax in NRPM 8.3 > > On May 27, 2011, at 3:31 PM, ARIN wrote: > >> ARIN-prop-153 Correct erroneous syntax in NRPM 8.3 >> > > I am opposed to this policy. It directly contradicts my proposal to delete > the single-aggregate requirement. > > Also, I have noted in that proposal that the single-aggregate transfer > requirement as it would apply with this proposal in effect can be > trivially worked around simply by submitting a large number of individual > transfers, each of which comes with justification. This just increases the > amount of paperwork for both parties *and* ARIN with no other benefit. > > (Even the Nortel-Microsoft paperwork filed with the court talks about > multiple subsequent transfers, if needed, and how payment works in this > case.) > > Matthew Kaufman > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From jcurran at arin.net Fri May 27 10:45:28 2011 From: jcurran at arin.net (John Curran) Date: Fri, 27 May 2011 14:45:28 +0000 Subject: [arin-ppml] Integrating Draft Policy ARIN-2011-1 into NRPM 8.3 In-Reply-To: <3D07D5E448F14437B85F94B95A62976A@mike> References: <"BANLkTinshsKWXc V+BoP1r=NxKsBhTcZ8Xg"@mail.gmail.com> <07DCA09506E941C3AEE0B6562DF8DB4E@mike> <00ac01cc19c6$2c803340$858099c0$@iname.com> <0114D408-5D5F-4EC3-A193-BE10687D7A8C@delong.com> <-5099803936536899096@unknownmsgid> <349C8AD2-9C4B-4B0F-8875-A6040341F476@delong.com> <00d901cc1a8c$cd5ba260$6812e720$@iname.com> <"680F5536-8FF7-48F0-9EC0-5831BEA941 8F"@delong.com> <282597B677794DB49A1E3CE343BEF17B@mike> <0A2DA7DD4C6443EA98172A5EFBE04A38@mike> <3D07D5E448F14437B85F94B95A62976A@mike> Message-ID: <5D8CE88A-A30B-4417-8AA6-742FD26171E8@arin.net> On May 27, 2011, at 10:15 AM, Mike Burns wrote: > > By requiring a needs test for inter-RIR transfers, we run the risk of driving these transfers off the books in contravention of our PRIMARY function as stewards. > > Just so we all understand. > APNIC has a great need, and probably less underutilized addresses in its market to supply that need. > A good chunk of available space is likely to be found in the legacy pools which are overrepresented in our region. Mike - Presuming your statements above, there are several ways to make policy which would allow such transfers - No needs assessment - Needs assessment performed by the other RIR - Needs assessment performed by ARIN - Needs assessment performed by qualified third-party - etc. Since there will be lots of parties in other regions with clear need, setting policy which requires some demonstration of such need should not necessarily drive the transactions away. By "risk" above, are you referring to parties that actually need the address space for their network growth? > Once again, I make the point that a market in IPv4 addresses, such as envisaged in 8.3 or in the APNIC transfer policy, meets the stewardship goal of conservation through natural market forces. > If we ladle on an extra helping of steward meddling, we are taking action in contravention of our primary duty to maintain a viable and trusted registry. You assert 'conservation via natural market forces'... While I do believe that such an approach works over a long-term in a perfect market, is there any reason to believe that it will work in the face of precipitous runout? If there is finite supply, absolutely steady demand, and no constraint on recipient to actually use the number resources, wouldn't such a market represent a perfect opportunity to corner? While the total size is approx 4.3 billion IP addresses, there is actually a much lower number that are readily redeployable, so the total capital commitment would not be unachievable by many investment firms. When combined with a lack of visibility and regulation of any sort, it appears ready-made for speculation (and that is not even considering the possibility of informal coordination of price among multiple players) Does the 'invisible hand' actually work in environment where to the total resource supply is fixed and the market supply is uncertain in appearance, irregular in flow, and transactions (including pricing) generally not visible to the other parties? I will note that we can establish regulatory mechanisms to improve market visibility, etc., but that very quickly makes one wonder the cost of establishing such systems and whether they'll actually meaningfully reduce the risk of market capture. Thanks for your insights here, /John John Curran President and CEO ARIN From farmer at umn.edu Fri May 27 10:48:02 2011 From: farmer at umn.edu (David Farmer) Date: Fri, 27 May 2011 09:48:02 -0500 Subject: [arin-ppml] ARIN-prop-152 RSA Modification Limits In-Reply-To: <4DDFA799.6060005@arin.net> References: <4DDFA799.6060005@arin.net> Message-ID: <4DDFB9A2.8070304@umn.edu> On 5/27/11 08:31 CDT, ARIN wrote: > The above requirements may be waived to the extent necessary to meet a > court order or settlement, but, such court order must be public or such > settlement must include terms allowing the settlement terms to be > published by ARIN, including the list of affected addresses and the > exact resulting RSA. ARIN shall publish the terms of any such settlement > and the resulting RSA within 10 days of drafting the settlement or RSA > whichever comes later. This paragraph has some significant issues. It is not possible for ARIN to dictate what information regarding a court order is public information, that is only in the control of the judge issuing the order. If some information regarded a court order were ordered confidential, ARIN would be in contempt of such a court order if it improperly disclosed such confidential information, which this policy seems to require. ARIN evaluates and protects confidential contract and business information on behalf of the community all the time, I'm not sure why this situation should be any different than all the others. While transparency is an important objective, I feel this policy goes to far, and can not support it as written. The rest of the policy other than this paragraph seems like it could be a useful policy improvement if it accurately reflects the community's intent. -- =============================================== 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 BillD at cait.wustl.edu Fri May 27 11:11:21 2011 From: BillD at cait.wustl.edu (Bill Darte) Date: Fri, 27 May 2011 10:11:21 -0500 Subject: [arin-ppml] Integrating Draft Policy ARIN-2011-1 into NRPM 8.3 In-Reply-To: <3D07D5E448F14437B85F94B95A62976A@mike> References: <07DCA09506E941C3AEE0B6562DF8DB4E@mike> <00ac01cc19c6$2c803340$858099c0$@iname.com><0114D408-5D5F-4EC3-A193-BE10687D7A8C@delong.com><-5099803936536899096@unknownmsgid> <349C8AD2-9C4B-4B0F-8875-A6040341F476@delong.com><00d901cc1a8c$cd5ba260$6812e720$@iname.com><680F5536-8FF7-48F0-9EC0-5831BEA941 8F@delong.com><282597B677794DB49A1E3CE343BEF17B@mike> <0A2DA7DD4C6443EA98172A5EFBE04A38@mike> <3D07D5E448F14437B85F94B95A62976A@mike> Message-ID: Mike, Please don't cherry-pick the guidance of RFC 2050. It also says, more pertinent and fundamental to the issues of transfers and efficiency.... 1. Introduction Internet address space is distributed according to the following three goals: 1) Conservation: Fair distribution of globally unique Internet address space according to the operational needs of the end-users and Internet Service Providers operating networks using this address space. Prevention of stockpiling in order to maximize the lifetime of the Internet address space. 2) Routability: Distribution of globally unique Internet addresses in a hierarchical manner, permitting the routing scalability of the addresses. This scalability is necessary to ensure proper operation of Internet routing, although it must be stressed that routability is in no way guaranteed with the allocation or assignment of IPv4 addresses. 3) Registration: Provision of a public registry documenting address space allocation and assignment. This is necessary to ensure uniqueness and to provide information for Internet trouble shooting at all levels. Conservation is the first principle, registration services is a primary duty of the RIR, to be sure, but its goals are not record keeping alone, but for the purposes of achieving the goals otherwise described. Moreover, 3.1 Common Registry Requirements Because the number of available IP addresses on the Internet is limited, the utilization rate of address space will be a key factor in network number assignment. Therefore, in the best interest of the Internet as a whole, specific guidelines have been created to govern the assignment of addresses based on utilization rates. Although topological issues may make exceptions necessary, the basic criteria that should be met to receive network numbers are listed below: 25% immediate utilization rate 50% utilization rate within 1 year The utilization rate above is to be used as a guideline, there may be be occasions when the 1 year rate does not fall exactly in this range. Organizations must exhibit a high confidence level in its 1 year utilization rate and supply documentation to justify the level of confidence. Organizations will be assigned address space based on immediate utilization plus 1 year projected utilization. A prefix longer than /24 may be issued if deemed appropriate. Organizations with less than 128 hosts will not be issued an IP address directly from the IRs. Organizations may be issued a prefix longer than /24 if the organization can provide documentation from a registry recognized ISP indicating the ISP will accept the long prefix for injection into the global routing system. Exceptions to the criteria will not be made based on insufficient equipment without additional detailed justification. Organizations should implement variable length subnet mask (VLSM) internally to maximize the effective utilization of address space. Address assignments will be made under the assumption that VLSM is or will be implemented. IP addresses are valid as long as the criteria continues to be met. The IANA reserves the right to invalidate any IP assignments once it is determined the the requirement for the address space no longer exists. In the event of address invalidation, reasonable efforts will be made by the appropriate registry to inform the organization that the addresses have been returned to the free pool of IPv4 address space. 4. Operational Guidelines For Registries 7. The transfer of IP addresses from one party to another must be approved by the regional registries. The party trying to obtain the IP address must meet the same criteria as if they were requesting an IP address directly from the IR. Clearly, the guidelines call for efficient utilization by entities that have need and can justtify the need and transfers would be according to local policies of RIRs....which have all agreed to conform to these principles. bd ________________________________ From: Mike Burns [mailto:mike at nationwideinc.com] Sent: Friday, May 27, 2011 9:16 AM To: Bill Darte; Chris Grundemann Cc: ARIN-PPML List Subject: Re: [arin-ppml] Integrating Draft Policy ARIN-2011-1 into NRPM 8.3 Hi Bill, It's still not clear to me. Referencing "values" of an RFC is not terribly clarifying when attempting to match transfer needs requirements which already are out of sync with RFC2050's 1 year window. And anyway, I say that requiring a needs test is *NOT* consistent with the values expressed here in RFC2050: 4. Operational Guidelines For Registries 1. Regional Registries provide registration services as its primary function. By requiring a needs test for inter-RIR transfers, we run the risk of driving these transfers off the books in contravention of our PRIMARY function as stewards. Just so we all understand. APNIC has a great need, and probably less underutilized addresses in its market to supply that need. A good chunk of available space is likely to be found in the legacy pools which are overrepresented in our region. The majority of this legacy space is not under any RSA with any RIR. You can route legacy space from inside Asia. A likely action that will occur is the purchases of address blocks from legacy holders which will be routed in Asia by network operators there, but ARIN will not be notified and Whois will not be updated. I have said that I think we are moving into a future with more, rather than less, conflict over IPv4 address control. This is only to be expected, as the availability of free pool addresses has always provided a replacement option for any addresses in conflict. In addition, the underlying monetary value of address control, once understood, provides ample motive to drive conflict. In an age of conflict, the accuracy of Whois will be related to the level of trust afforded to it. The absence of a strong trust authority could open the doors to a private registry. Suppose there is conflict between private organizations over address control. Then add to that conflict between RIRs over which registry is the authoritative. What is to stop a real international trust authority, say Lloyds of London, from using its trust to establish a pricey but generally recognized registry? Or even worse, what if the door is opened to the ITU to claim the RIR system was failing in a post-exhaust era, and seek to create its own registry system, or otherwise take control? Once again, I make the point that a market in IPv4 addresses, such as envisaged in 8.3 or in the APNIC transfer policy, meets the stewardship goal of conservation through natural market forces. If we ladle on an extra helping of steward meddling, we are taking action in contravention of our primary duty to maintain a viable and trusted registry. So I would support the proposal if the requirement was simply that both RIRs approve, leaving off the "signal" sent by the needs language, which signal reads like a shot across the bow to me. Regards, Mike ----- Original Message ----- From: Bill Darte To: Mike Burns ; Chris Grundemann Cc: ARIN-PPML List Sent: Friday, May 27, 2011 7:38 AM Subject: RE: [arin-ppml] Integrating Draft Policy ARIN-2011-1 into NRPM 8.3 The word you say is subjective...'compatible'... in the DP is interpreted by.. 'that exercise Internet stewardship consistent with the values expressed in RFC2050' -----Original Message----- From: arin-ppml-bounces at arin.net on behalf of Mike Burns Sent: Thu 5/26/2011 4:28 PM To: Chris Grundemann Cc: ARIN-PPML List Subject: Re: [arin-ppml] Integrating Draft Policy ARIN-2011-1 into NRPM 8.3 > What is to be gained by including that language, except to engender > Inter-RIR conflict? > The wording already includes both RIRs to approve the transfer. > There is no definition in the policy or elsewhere in the NRPM of > "compatible" needs policies. > I don't see the point in including it. The point of that statement is to signal the intentions of the ARIN community both to ARIN staff and to other RIRs. It provides guidance to ARIN staff that they should not agree to any transfer that does not include needs-based policy on the recipient end. It also ensures that recipients in other regions will not be surprised when a transfer is denied for lack of said needs-based policies. The point, in short, is clarity and transparency. Cheers, ~Chris Hi Chris, But how clear is it exactly? Do you mean it to signal that *any* needs test is compatible? If that is the intent, then I think the language can be clearer. If you want clarity, then using a subjective word like "compatible" which is undefined in the proposal is sub-optimal. Since its definition and application is left to ARIN staff, and ARIN staff is required to decide on transfer approval anyway, I don't see any great clarity or transparency. What I do see reads like a political statement added onto a policy proposal, to no real effect except to exacerbate inter-RIR tensions. What better way to incite the APNIC stewards to unilaterally decide to accept transfers into their region of legacy space with no RSA in place? This is currently a lacuna in policy awaiting a test case, as far as I know. It's not like there are hundreds of different transfer policies, I'm sure those requesting inter-RIR transfers will be aware of the current policies without brandishing our disdain for their version of stewardship in additional and functionally inoperative language. Regards, Mike _______________________________________________ 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 hannigan at gmail.com Fri May 27 11:13:21 2011 From: hannigan at gmail.com (Martin Hannigan) Date: Fri, 27 May 2011 11:13:21 -0400 Subject: [arin-ppml] Integrating Draft Policy ARIN-2011-1 into NRPM 8.3 In-Reply-To: <3D07D5E448F14437B85F94B95A62976A@mike> References: <07DCA09506E941C3AEE0B6562DF8DB4E@mike> <00ac01cc19c6$2c803340$858099c0$@iname.com> <0114D408-5D5F-4EC3-A193-BE10687D7A8C@delong.com> <-5099803936536899096@unknownmsgid> <349C8AD2-9C4B-4B0F-8875-A6040341F476@delong.com> <00d901cc1a8c$cd5ba260$6812e720$@iname.com> <282597B677794DB49A1E3CE343BEF17B@mike> <0A2DA7DD4C6443EA98172A5EFBE04A38@mike> <3D07D5E448F14437B85F94B95A62976A@mike> Message-ID: On Fri, May 27, 2011 at 10:15 AM, Mike Burns wrote: > Hi Bill, > > It's still not clear to me. > Referencing "values" of an RFC is not terribly clarifying when attempting to > match transfer needs requirements which already are out of sync with > RFC2050's 1 year window. Especially an RFC that was written in 1996. In fact, it acknowledges this quite clearly: " It is in the interest of the Internet community as a whole that the above goals be pursued. However it should be noted that "Conservation" and "Routability" are often conflicting goals. All the above goals may sometimes be in conflict with the interests of individual end-users or Internet service providers. Careful analysis and judgement is necessary in each individual case to find an appropriate compromise." The "values of 2050" is a dead issue IMHO. The idea of inter-RIR transfer should go back to the drawing board entirely. Both interest and opinion have grown significantly and the path that this proposal is taking does not reflect that. Trying to adjust it midstream to rush something in is a grave error all considered. I'm not in favor of this approach, or any approach that has presented to date. Best, -M< From BillD at cait.wustl.edu Fri May 27 11:31:57 2011 From: BillD at cait.wustl.edu (Bill Darte) Date: Fri, 27 May 2011 10:31:57 -0500 Subject: [arin-ppml] FW: Integrating Draft Policy ARIN-2011-1 into NRPM 8.3 Message-ID: Sorry, meant to copy the PPML on this response... bd > -----Original Message----- > From: Bill Darte > Sent: Friday, May 27, 2011 10:31 AM > To: 'Martin Hannigan' > Subject: RE: [arin-ppml] Integrating Draft Policy ARIN-2011-1 > into NRPM 8.3 > > Marty, > See comments below... > > > -----Original Message----- > > From: arin-ppml-bounces at arin.net > > [mailto:arin-ppml-bounces at arin.net] On Behalf Of Martin Hannigan > > Sent: Friday, May 27, 2011 10:13 AM > > To: Mike Burns > > Cc: ARIN-PPML List > > Subject: Re: [arin-ppml] Integrating Draft Policy ARIN-2011-1 into > > NRPM 8.3 > > > > On Fri, May 27, 2011 at 10:15 AM, Mike Burns > > > wrote: > > > Hi Bill, > > > > > > It's still not clear to me. > > > Referencing "values" of an RFC is not terribly clarifying when > > > attempting to match transfer needs requirements which > > already are out > > > of sync with RFC2050's 1 year window. > > > > Especially an RFC that was written in 1996. In fact, it > acknowledges > > this quite clearly: > > > > " It is in the interest of the Internet community as a > > whole that the > > above goals be pursued. However it should be noted that > > "Conservation" and "Routability" are often conflicting > goals. All > > the above goals may sometimes be in conflict with the > interests of > > individual end-users or Internet service providers. > > Careful analysis > > and judgement is necessary in each individual case to find an > > appropriate compromise." > > > > The "values of 2050" is a dead issue IMHO. The idea of inter-RIR > > transfer should go back to the drawing board entirely. Both > interest > > and opinion have grown significantly and the path that this > proposal > > is taking does not reflect that. Trying to adjust it > midstream to rush > > something in is a grave error all considered. > > I believe that the efforts to date have been serious and the > PDP is the mechanism through which current need is assessed > in the ARIN region, DP 2011-1 is in the phase for discussion > and compromise and your input along with all other is important. > > > > > > I'm not in favor of this approach, or any approach that has > presented > > to date. > > The 'approach' that you refer to is related to and Inter-RIR > transfer itself, the 'values of 2050', the RIR's agreement, > needs basis for tansfer? > > I'm unsure of exactly what you are requesting when you say > "back to the drawing board"...as I believe that we are at the > drawing board related to Inter-RIR transfers of IPv4 resources. > > bd > > > > > Best, > > > > -M< > > _______________________________________________ > > 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 adudek16 at gmail.com Fri May 27 11:38:56 2011 From: adudek16 at gmail.com (Aaron Dudek) Date: Fri, 27 May 2011 11:38:56 -0400 Subject: [arin-ppml] Integrating Draft Policy ARIN-2011-1 into NRPM 8.3 In-Reply-To: References: <07DCA09506E941C3AEE0B6562DF8DB4E@mike> <00ac01cc19c6$2c803340$858099c0$@iname.com> <0114D408-5D5F-4EC3-A193-BE10687D7A8C@delong.com> <-5099803936536899096@unknownmsgid> <349C8AD2-9C4B-4B0F-8875-A6040341F476@delong.com> <00d901cc1a8c$cd5ba260$6812e720$@iname.com> <680F5536-8FF7-48F0-9EC0-5831BEA9418F@delong.com> <282597B677794DB49A1E3CE343BEF17B@mike> <8DB5F2EE-8444-4CF0-8C5F-B5F48BDB3570@delong.com> <6CDF97E7-11C5-486D-9ECD-ADB4A215DDF1@delong.com> Message-ID: On Fri, May 27, 2011 at 00:09, Owen DeLong wrote: > > On May 26, 2011, at 6:44 PM, Aaron Dudek wrote: > >> Currently the only way to transfer owner ship is through 8.2 Mergers >> and Acquisitions. >> Company A received an initial allocation. Company B received a >> significant allocation from Company A. >> > > >> Company A goes out of business. There is no method for company B to >> take over the block from company A. > > If company B has a large enough need to meet the criteria for a direct > assignment (I doubt they received an allocation as you describe), > then, why didn't they go to ARIN instead of Company A? > > If they didn't meet and/or don't meet the criteria, then, why should they > be able to transfer a smaller netblock rather than renumber as an end-run > on policy? Why are you assuming that they would get a smaller netblock? Why is that a bad thing? Renumbering is not easy even with ipv6. Why are you assuming that they may not be able to meet the criteria now? How is this an end-run on polcy when they still have to meet the ARIN guidelines? > > I don't think that B's poor planning is something we should codify in > ARIN policy. > Polices change over time. What may have be forbidden before may now be allowed. There once was a time that end-users where not allowed to get IPv6 space and had to get it from the LIRs. That is not poor planning, just following policy has policy dictated at the time. The policy doesn't allow for clean ups of ipv6 whois allocations outside of mergers and acquisitions. There have been requests to do so, but since they are outside of 8.2, 8.3 doesn't allow for it. >> Company A has to migrate to a larger block. There is no method for >> company B to take over the block from company A. >> > > Right. I think this falls into the same answers as above. > >> These are just a couple of examples. >> ARIN still has the final say of any transfers as per the rest of 8.3 >> as the "new owner" has to show need and justification just as before. >> > > ARIN policy has the final say. ARIN's ability to say no is limited to exactly > those things proscribed by policy, not even the ones obviously intended > to be proscribed by policy as recent experience has shown. > > Owen > >> Aaron >> >> On Thu, May 26, 2011 at 16:14, Owen DeLong wrote: >>> >>> On May 26, 2011, at 12:45 PM, Aaron Dudek wrote: >>> >>>> Since we are discussing 8.3. >>>> I feel that there should be language to allow for transfers of IPv6. >>>> Currently there is no language to allow for transfers of IPv6 allocations. >>>> So essentially >>>> >>> >>> IMHO, there should not. The need to facilitate directed transfers >>> in IPv4 is strictly a result of the intersection of legacy addresses and >>> failure to have a strong mechanism for address policy with legacy >>> resources combined with the shortage of addresses. >>> >>> Neither of these factors applies to IPv6 and such transfers have no >>> positive effect. >>> >>> Owen >>> >>> >>>> 8.3. Transfers to Specified Recipients >>>> >>>> In addition to transfers under section 8.2, IPv4 ?and IPv6 number resources >>>> within the ARIN region may be released to ARIN by the authorized resource >>>> holder, in whole or in part, for transfer to another specified >>>> organizational recipient....... >>>> >>>> The other option would to remove the version number and just leave IP number >>>> resources.... >>>> >>>> Thank you, >>>> >>>> Aaron Dudek >>>> >>>>> On Thu, May 26, 2011 at 01:34, Owen DeLong wrote: >>>>>> >>>>>> On May 25, 2011, at 2:06 PM, Jeffrey Lyon wrote: >>>>>> >>>>>>> On Wed, May 25, 2011 at 1:57 PM, Owen DeLong wrote: >>>>>>>> It doesn't surprise me to see that we will disagree on this. >>>>>>>> Since you are opposed to needs-basis in general, I don't expect you to >>>>>>>> understand >>>>>>>> the need to preserve it here or to agree with it. >>>>>>>> Owen >>>>>>>> On May 25, 2011, at 9:21 AM, Mike Burns wrote: >>>>>>> >>>>>>> Similarly, I don't expect you to entertain any logic that free markets >>>>>>> are beneficial. I suspect spending a lot of time in the Bay Area has >>>>>>> that effect. >>>>>>> >>>>>> >>>>>> I think there are places where regulated free markets can be beneficial. >>>>>> >>>>>> If you can point to a single historical example of an unregulated free >>>>>> market that >>>>>> remained beneficial and unregulated for more than 5 years, I'll be >>>>>> surprised. >>>>>> >>>>>> 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. >>>>> >>>>> >>>> _______________________________________________ >>>> 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 mike at nationwideinc.com Fri May 27 12:06:38 2011 From: mike at nationwideinc.com (Mike Burns) Date: Fri, 27 May 2011 12:06:38 -0400 Subject: [arin-ppml] Integrating Draft Policy ARIN-2011-1 into NRPM 8.3 References: <07DCA09506E941C3AEE0B6562DF8DB4E@mike> <00ac01cc19c6$2c803340$858099c0$@iname.com><0114D408-5D5F-4EC3-A193-BE10687D7A8C@delong.com><-5099803936536899096@unknownmsgid> <349C8AD2-9C4B-4B0F-8875-A6040341F476@delong.com><00d901cc1a8c$cd5ba260$6812e720$@iname.com><680F5536-8FF7-48F0-9EC0-5831BEA941 8F@delong.com><282597B677794DB49A1E3CE343BEF17B@mike> <0A2DA7DD4C6443EA98172A5EFBE04A38@mike> <3D07D5E448F14437B85F94B95A62976A@mike> Message-ID: <2C77B471DBD04A9294266A257090C63C@mike> RE: [arin-ppml] Integrating Draft Policy ARIN-2011-1 into NRPM 8.3Bill, My point is that the guidelines you posted are already obseleted by current transfer requirements involving not 12 months, but three months of usage in the current needs test. Could RIPE refuse to transfer to us because we are violating the "values" of RFC2050 by not allowing a 12 months of need? So attempting to claim that RFC2050 somehow clears up the uncertainty about the word "compatible" doesn't suffice. And as far as cherry picking, my quote of 4.1 says "the primary", while you degrade that language to "a primary" in your reply. And anyway, what is the point of trying to use RFC 2050 to justify or explain language that could be clearly inserted in the NRPM? This is similar to when I pointed out that section 12 of the NRPM would not give ARIN the right to revoke addresses for utilization as it is written now, and John proffered RFC2050 as providing that justification, which is lacking in the current NRPM language. That is like using the Declaration of Independence to make a legal finding absent from the Constitution. Sure it can give guidance, but the actual rules are better clearly established in the NRPM, if that is an option. Regards, Mike ----- Original Message ----- From: Bill Darte To: Mike Burns Cc: ARIN-PPML List Sent: Friday, May 27, 2011 11:11 AM Subject: RE: [arin-ppml] Integrating Draft Policy ARIN-2011-1 into NRPM 8.3 Mike, Please don't cherry-pick the guidance of RFC 2050. It also says, more pertinent and fundamental to the issues of transfers and efficiency.... 1. Introduction Internet address space is distributed according to the following three goals: 1) Conservation: Fair distribution of globally unique Internet address space according to the operational needs of the end-users and Internet Service Providers operating networks using this address space. Prevention of stockpiling in order to maximize the lifetime of the Internet address space. 2) Routability: Distribution of globally unique Internet addresses in a hierarchical manner, permitting the routing scalability of the addresses. This scalability is necessary to ensure proper operation of Internet routing, although it must be stressed that routability is in no way guaranteed with the allocation or assignment of IPv4 addresses. 3) Registration: Provision of a public registry documenting address space allocation and assignment. This is necessary to ensure uniqueness and to provide information for Internet trouble shooting at all levels. Conservation is the first principle, registration services is a primary duty of the RIR, to be sure, but its goals are not record keeping alone, but for the purposes of achieving the goals otherwise described.Moreover, 3.1 Common Registry Requirements Because the number of available IP addresses on the Internet is limited, the utilization rate of address space will be a key factor in network number assignment. Therefore, in the best interest of the Internet as a whole, specific guidelines have been created to govern the assignment of addresses based on utilization rates. Although topological issues may make exceptions necessary, the basic criteria that should be met to receive network numbers are listed below: 25% immediate utilization rate 50% utilization rate within 1 year The utilization rate above is to be used as a guideline, there may be be occasions when the 1 year rate does not fall exactly in this range. Organizations must exhibit a high confidence level in its 1 year utilization rate and supply documentation to justify the level of confidence. Organizations will be assigned address space based on immediate utilization plus 1 year projected utilization. A prefix longer than /24 may be issued if deemed appropriate. Organizations with less than 128 hosts will not be issued an IP address directly from the IRs. Organizations may be issued a prefix longer than /24 if the organization can provide documentation from a registry recognized ISP indicating the ISP will accept the long prefix for injection into the global routing system. Exceptions to the criteria will not be made based on insufficient equipment without additional detailed justification. Organizations should implement variable length subnet mask (VLSM) internally to maximize the effective utilization of address space. Address assignments will be made under the assumption that VLSM is or will be implemented. IP addresses are valid as long as the criteria continues to be met. The IANA reserves the right to invalidate any IP assignments once it is determined the the requirement for the address space no longer exists. In the event of address invalidation, reasonable efforts will be made by the appropriate registry to inform the organization that the addresses have been returned to the free pool of IPv4 address space. 4. Operational Guidelines For Registries 7. The transfer of IP addresses from one party to another must be approved by the regional registries. The party trying to obtain the IP address must meet the same criteria as if they were requesting an IP address directly from the IR. Clearly, the guidelines call for efficient utilization by entities that have need and can justtify the needand transfers would be according to local policies of RIRs....which have all agreed to conform to these principles.bd ---------------------------------------------------------------------------- From: Mike Burns [mailto:mike at nationwideinc.com] Sent: Friday, May 27, 2011 9:16 AM To: Bill Darte; Chris Grundemann Cc: ARIN-PPML List Subject: Re: [arin-ppml] Integrating Draft Policy ARIN-2011-1 into NRPM 8.3 Hi Bill, It's still not clear to me. Referencing "values" of an RFC is not terribly clarifying when attempting to match transfer needs requirements which already are out of sync with RFC2050's 1 year window. And anyway, I say that requiring a needs test is *NOT* consistent with the values expressed here in RFC2050: 4. Operational Guidelines For Registries 1. Regional Registries provide registration services as its primary function. By requiring a needs test for inter-RIR transfers, we run the risk of driving these transfers off the books in contravention of our PRIMARY function as stewards. Just so we all understand. APNIC has a great need, and probably less underutilized addresses in its market to supply that need. A good chunk of available space is likely to be found in the legacy pools which are overrepresented in our region. The majority of this legacy space is not under any RSA with any RIR. You can route legacy space from inside Asia. A likely action that will occur is the purchases of address blocks from legacy holders which will be routed in Asia by network operators there, but ARIN will not be notified and Whois will not be updated. I have said that I think we are moving into a future with more, rather than less, conflict over IPv4 address control. This is only to be expected, as the availability of free pool addresses has always provided a replacement option for any addresses in conflict. In addition, the underlying monetary value of address control, once understood, provides ample motive to drive conflict. In an age of conflict, the accuracy of Whois will be related to the level of trust afforded to it. The absence of a strong trust authority could open the doors to a private registry. Suppose there is conflict between private organizations over address control. Then add to that conflict between RIRs over which registry is the authoritative. What is to stop a real international trust authority, say Lloyds of London, from using its trust to establish a pricey but generally recognized registry? Or even worse, what if the door is opened to the ITU to claim the RIR system was failing in a post-exhaust era, and seek to create its own registry system, or otherwise take control? Once again, I make the point that a market in IPv4 addresses, such as envisaged in 8.3 or in the APNIC transfer policy, meets the stewardship goal of conservation through natural market forces. If we ladle on an extra helping of steward meddling, we are taking action in contravention of our primary duty to maintain a viable and trusted registry. So I would support the proposal if the requirement was simply that both RIRs approve, leaving off the "signal" sent by the needs language, which signal reads like a shot across the bow to me. Regards, Mike ----- Original Message ----- From: Bill Darte To: Mike Burns ; Chris Grundemann Cc: ARIN-PPML List Sent: Friday, May 27, 2011 7:38 AM Subject: RE: [arin-ppml] Integrating Draft Policy ARIN-2011-1 into NRPM 8.3 The word you say is subjective...'compatible'... in the DP is interpreted by.. 'that exercise Internet stewardship consistent with the values expressed in RFC2050' -----Original Message----- From: arin-ppml-bounces at arin.net on behalf of Mike Burns Sent: Thu 5/26/2011 4:28 PM To: Chris Grundemann Cc: ARIN-PPML List Subject: Re: [arin-ppml] Integrating Draft Policy ARIN-2011-1 into NRPM 8.3 > What is to be gained by including that language, except to engender > Inter-RIR conflict? > The wording already includes both RIRs to approve the transfer. > There is no definition in the policy or elsewhere in the NRPM of > "compatible" needs policies. > I don't see the point in including it. The point of that statement is to signal the intentions of the ARIN community both to ARIN staff and to other RIRs. It provides guidance to ARIN staff that they should not agree to any transfer that does not include needs-based policy on the recipient end. It also ensures that recipients in other regions will not be surprised when a transfer is denied for lack of said needs-based policies. The point, in short, is clarity and transparency. Cheers, ~Chris Hi Chris, But how clear is it exactly? Do you mean it to signal that *any* needs test is compatible? If that is the intent, then I think the language can be clearer. If you want clarity, then using a subjective word like "compatible" which is undefined in the proposal is sub-optimal. Since its definition and application is left to ARIN staff, and ARIN staff is required to decide on transfer approval anyway, I don't see any great clarity or transparency. What I do see reads like a political statement added onto a policy proposal, to no real effect except to exacerbate inter-RIR tensions. What better way to incite the APNIC stewards to unilaterally decide to accept transfers into their region of legacy space with no RSA in place? This is currently a lacuna in policy awaiting a test case, as far as I know. It's not like there are hundreds of different transfer policies, I'm sure those requesting inter-RIR transfers will be aware of the current policies without brandishing our disdain for their version of stewardship in additional and functionally inoperative language. Regards, Mike _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcurran at arin.net Fri May 27 12:52:18 2011 From: jcurran at arin.net (John Curran) Date: Fri, 27 May 2011 16:52:18 +0000 Subject: [arin-ppml] Integrating Draft Policy ARIN-2011-1 into NRPM 8.3 In-Reply-To: <2C77B471DBD04A9294266A257090C63C@mike> References: <"BANLkTinshsKWXc V+BoP1r=NxKsBhTcZ8Xg"@mail.gmail.com> <07DCA09506E941C3AEE0B6562DF8DB4E@mike> <00ac01cc19c6$2c803340$858099c0$@iname.com> <0114D408-5D5F-4EC3-A193-BE10687D7A8C@delong.com> <-5099803936536899096@unknownmsgid> <349C8AD2-9C4B-4B0F-8875-A6040341F476@delong.com> <00d901cc1a8c$cd5ba260$6812e720$@iname.com> <"680F5536-8FF7-48F0-9EC0-5831BEA941 8F"@delong.com> <282597B677794DB49A1E3CE343BEF17B@mike> <0A2DA7DD4C6443EA98172A5EFBE04A38@mike> <3D07D5E448F14437B85F94B95A62976A@mike> <2C77B471DBD04A9294266A257090C63C@mike> Message-ID: <2DEDBE16-AA9A-4503-BC3A-CF7EBD8AFDB4@arin.net> On May 27, 2011, at 12:06 PM, Mike Burns wrote: This is similar to when I pointed out that section 12 of the NRPM would not give ARIN the right to revoke addresses for utilization as it is written now, and John proffered RFC2050 as providing that justification, which is lacking in the current NRPM language. That is like using the Declaration of Independence to make a legal finding absent from the Constitution. Sure it can give guidance, but the actual rules are better clearly established in the NRPM, if that is an option. Mike - My full response on the topic of NRPM 12 is attached, and I disagree with your summary above to the effect that the present language in the NRPM is insufficient to support reclamation to bring into compliance. Organizations which no longer meet the criteria by which they were assigned resources (including utilization criteria contained in ARIN policy) are indeed out of compliance with ARIN policy and could technically be required to returned their number resources. As I noted, before, I am unaware of ARIN performing reclamation against any organization acting in good faith under such circumstances, but it would technically be a valid course of action. In light of the specified transfer policy, it might be helpful for the community to clarify the use of NRPM 12 with respect to utilization, but ARIN staff will our best to implement the policies as adopted. Thanks! /John John Curran President and CEO ARIN Begin forwarded message: From: John Curran > Date: May 10, 2011 2:22:16 PM EDT To: Mike Burns > Cc: "arin-ppml at arin.net" > Subject: Re: [arin-ppml] Draft Proposal for Needs-Free IPv4 Transfers On May 10, 2011, at 11:01 AM, Mike Burns wrote: Can you elaborate some? If I were allocated a /18 in 2002 order to host websites, and I have sold or lost the customers but retain the corporation, could my resources be reviewed and revoked per NRPM section 12 without recourse to the RSA section 8? Yes, see below. My reading of it says no, section 12 does not give ARIN the right to request a return for under-utilization only. I think this is the salient section, 12.4: "Organizations found by ARIN to be materially out of compliance with current ARIN policy shall be requested or required to return resources as needed to bring them into (or reasonably close to) compliance." In my example, what current ARIN policy would I be materially out of compliance with? ARIN policy talks quite a bit about utilization, but always in the context of a new allocation, not the utilization of a prior allocation outside that context. While the criteria are provided in context of a new allocation, the actual IP assignment or allocation remains "valid as long as the criteria continues to be met" (RFC 2050). The RFC 2050 guidance is specifically included per NRPM 4.1.7 (IPv4 General Principles). I'm unaware of ARIN performing reclamation against any organization acting in good faith under such circumstances, but it would technically be a valid course of action. Of course, the RSA section 8 would provide this authority as a result of its "compliance with intended purposes" language. Correct. My concern was that I thought section 12 was toothless in this regard, so I left it unmodified in my proposal and instead modified the RSA, which I now know is not possible via this policy proposal mechanism. However, in order to have a viable proposal to eliminate needs requirements for transfers, like APNIC, it is clear that whatever agreement is required of transfer recipients must not have utilization review language in it, or it would vitiate the whole idea of needs-free transfers, and the whole idea of booking every transaction in whois to maintain its integrity. Best to make explicit via a policy proposal which states the goal. We will amend the agreements accordingly if the draft policy supported by the community and adopted. If I make a proposal to change the RSA to remove the language about "intended purposes" via the ARIN ACSP as you indicate, can I make my policy proposal to change NRPM 8.3 linked, or contingent upon, action to change the RSA? Are there any examples of prior policy proposals which required changes to agreements that I can use as guidance? Nothing is needed other than a simple statement in the policy rationale that notes that changes to the registration service agreements may be necessary if the policy is adopted. Thanks! /John John Curran President and CEO ARIN _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: From owen at delong.com Fri May 27 16:10:08 2011 From: owen at delong.com (Owen DeLong) Date: Fri, 27 May 2011 13:10:08 -0700 Subject: [arin-ppml] ARIN-prop-152 RSA Modification Limits In-Reply-To: <4B0472A3-14D8-46E4-8D03-DD860428DA1D@matthew.at> References: <4DDFA799.6060005@arin.net> <4B0472A3-14D8-46E4-8D03-DD860428DA1D@matthew.at> Message-ID: On May 27, 2011, at 7:35 AM, Matthew Kaufman wrote: > > On May 27, 2011, at 3:31 PM, ARIN wrote: > >> ARIN-prop-152 RSA Modification Limits >> > > I am opposed to this proposal as I believe it places ARIN in an untenable position that will then force ARIN to violate policy in order to comply with legal requirements and advice. > > At best, some parts of this should be a matter for ASCP... none is appropriate for the PDP. > I discussed the issues raised in this proposal with the ARIN CEO prior to submitting this proposal. I believe that the proposal is in line with the advice he gave me on steering clear of the issues which would cause the problems you describe and/or be an issue inappropriate for the PDP. Note that it does not attempt to set the level of fees or change or control the fee structure. It merely states that fees cannot be waived altogether as part of the RSA modifications. Owen From owen at delong.com Fri May 27 16:08:07 2011 From: owen at delong.com (Owen DeLong) Date: Fri, 27 May 2011 13:08:07 -0700 Subject: [arin-ppml] ARIN-prop-153 Correct erroneous syntax in NRPM 8.3 In-Reply-To: References: <4DDFA7A6.105@arin.net> Message-ID: <11189C06-3B22-491B-8A81-972250BA537D@delong.com> On May 27, 2011, at 7:33 AM, Matthew Kaufman wrote: > > On May 27, 2011, at 3:31 PM, ARIN wrote: > >> ARIN-prop-153 Correct erroneous syntax in NRPM 8.3 >> > > I am opposed to this policy. It directly contradicts my proposal to delete the single-aggregate requirement. > Yes, that would be exactly the point... To restore community intent instead of abandon it. > Also, I have noted in that proposal that the single-aggregate transfer requirement as it would apply with this proposal in effect can be trivially worked around simply by submitting a large number of individual transfers, each of which comes with justification. This just increases the amount of paperwork for both parties *and* ARIN with no other benefit. > So you have said, however, the reality is that the language in 8.3 was put there by the AC for a reason and with an intent which was supported by the consensus of the community. You prefer to abandon that intent based on the interpretation of the language. I prefer to correct the language so that it matches the original intent. Subsequent transfers would be the result of subsequent needs, presumably, so, I'm not seeing that this is necessarily in conflict. Owen From owen at delong.com Fri May 27 16:14:18 2011 From: owen at delong.com (Owen DeLong) Date: Fri, 27 May 2011 13:14:18 -0700 Subject: [arin-ppml] ARIN-prop-153 Correct erroneous syntax in NRPM 8.3 In-Reply-To: <342163658FC54310912C8378B5FDFEEF@mike> References: <4DDFA7A6.105@arin.net> <342163658FC54310912C8378B5FDFEEF@mike> Message-ID: <89A1FF1F-21C2-4A26-8C9F-5D763F16FD90@delong.com> On May 27, 2011, at 7:43 AM, Mike Burns wrote: > Opposed. > This requirement would create additional incentives for parties to engage in a deal, but to avoid telling ARIN about it. Not really... In fact, it will probably make such deals easier to identify and make it easier to reclaim blocks transferred fraudulently in contravention of policies developed through the consent of the community. > And particularly early in the transfer market, there may not be enough supply to ensure that every sized single-aggregate will be available for the same cost as the sum of a bunch of smaller purchases. There will probably never be enough supply in the transfer market to ensure this. So what? That's the reality. There's not enough IPv4. Don't like it? Move to IPv6. > What does the buyer do then? Same thing they do when the transfer market is empty... Move to IPv6. > In other words, supposed the buyer is sized like Microsoft and has a need for 660,000 addresses? And? > How long must they wait for a seller to appear? If they're smart, not long... They'll go to IPv6 instead. In case you haven't noticed, we're running out of available IPv4. The market will run out of available IPv4 relatively quickly too. Anyone building or staking their business strategy on the continued availability of IPv4 is impressively optimistic about the future of IPv4 at best. > The effect of this policy would be for an entity with justified needs to be unable to use an aggregate of smaller, but available blocks, and for those smaller blocks to be left on the sidelines. I doubt the smaller blocks will be left on the sidelines. I'm quite certain they will get used by others who have justified need for them. > Neither of these things comports with our role as stewards to get addresses into productive use. > It aligns with the intent of the policy which received community consensus. Owen > -Mike Burns > > > > ----- Original Message ----- From: "Matthew Kaufman" > To: "ARIN" > Cc: > Sent: Friday, May 27, 2011 10:33 AM > Subject: Re: [arin-ppml] ARIN-prop-153 Correct erroneous syntax in NRPM 8.3 > > >> >> On May 27, 2011, at 3:31 PM, ARIN wrote: >> >>> ARIN-prop-153 Correct erroneous syntax in NRPM 8.3 >>> >> >> I am opposed to this policy. It directly contradicts my proposal to delete the single-aggregate requirement. >> >> Also, I have noted in that proposal that the single-aggregate transfer requirement as it would apply with this proposal in effect can be trivially worked around simply by submitting a large number of individual transfers, each of which comes with justification. This just increases the amount of paperwork for both parties *and* ARIN with no other benefit. >> >> (Even the Nortel-Microsoft paperwork filed with the court talks about multiple subsequent transfers, if needed, and how payment works in this case.) >> >> Matthew Kaufman >> >> _______________________________________________ >> PPML >> You are receiving this message because you are subscribed to >> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/arin-ppml >> Please contact info at arin.net if you experience any issues. > > _______________________________________________ > 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 27 16:04:53 2011 From: owen at delong.com (Owen DeLong) Date: Fri, 27 May 2011 13:04:53 -0700 Subject: [arin-ppml] Integrating Draft Policy ARIN-2011-1 into NRPM 8.3 In-Reply-To: <3D07D5E448F14437B85F94B95A62976A@mike> References: <07DCA09506E941C3AEE0B6562DF8DB4E@mike> <00ac01cc19c6$2c803340$858099c0$@iname.com><0114D408-5D5F-4EC3-A193-BE10687D7A8C@delong.com><-5099803936536899096@unknownmsgid> <349C8AD2-9C4B-4B0F-8875-A6040341F476@delong.com><00d901cc1a8c$cd5ba260$6812e720$@iname.com><680F5536-8FF7-48F0-9EC0-5831BEA941 8F@delong.com><282597B677794DB49A1E3CE343BEF17B@mike> <0A2DA7DD4C6443EA98172A5EFBE04A38@mike> <3D07D5E448F14437B85F94B95A62976A@mike> Message-ID: On May 27, 2011, at 7:15 AM, Mike Burns wrote: > Hi Bill, > > It's still not clear to me. > Referencing "values" of an RFC is not terribly clarifying when attempting to match transfer needs requirements which already are out of sync with RFC2050's 1 year window. > Where do you find a 1 year window in RFC 2050? > And anyway, I say that requiring a needs test is *NOT* consistent with the values expressed here in RFC2050: You are mistaken. > > 4. Operational Guidelines For Registries > > 1. Regional Registries provide registration services as its > primary function. > > By requiring a needs test for inter-RIR transfers, we run the risk of driving these transfers off the books in contravention of our PRIMARY function as stewards. By failing to require a needs test, we would open the door to transfers that are in gross violation of our PRIMARY functions as stewards. > > Just so we all understand. > APNIC has a great need, and probably less underutilized addresses in its market to supply that need. > A good chunk of available space is likely to be found in the legacy pools which are overrepresented in our region. > The majority of this legacy space is not under any RSA with any RIR. > So? > You can route legacy space from inside Asia. Yes. > > A likely action that will occur is the purchases of address blocks from legacy holders which will be routed in Asia by network operators there, but ARIN will not be notified and Whois will not be updated. Then they risk ARIN noticing that the blocks are no longer in use by the registrant, and proceeding as I have repeatedly described to you. Further, they'd have to come to the US to get a ruling against ARIN on the matter when ARIN issues the space to someone else if there isn't some other within-policy solution available. Frankly, I'm not seeing this as necessarily a bad thing. Certainly the few instances of this which might occur and disruption effects limited to two parties: The party that hijacked the space contrary to policy and The party that received the space from ARIN under RSA legitimately, but, when ARIN had no cleaner space to give and was apprised of the situation by ARIN prior to receiving the space. Is vastly superior to the disruption to all parties that I see likely from removing needs basis. > > I have said that I think we are moving into a future with more, rather than less, conflict over IPv4 address control. This is only to be expected, as the availability of free pool addresses has always provided a replacement option for any addresses in conflict. In addition, the underlying monetary value of address control, once understood, provides ample motive to drive conflict. Yes. All the more reason that transfer records need to reflect good stewardship and that we need to continue to administer the address space and recognize transfers within the policy framework set by the community. All the more reason to preserve a needs basis for allowing people to take address space out of the community pool and use it for their own purposes. > > In an age of conflict, the accuracy of Whois will be related to the level of trust afforded to it. The absence of a strong trust authority could open the doors to a private registry. I would think that if we preserve the integrity of our policies and administer whois according to those policies with integrity, it would only serve to increase the level of trust. If we start recognizing anything that looks like a transfer because we guess that the parties involved are probably the ones that should be involved and they say so, I can imagine only a few better ways to devalue the trust placed in the database. > > Suppose there is conflict between private organizations over address control. Then add to that conflict between RIRs over which registry is the authoritative. What is to stop a real international trust authority, say Lloyds of London, from using its trust to establish a pricey but generally recognized registry? Here you once again go careening off the rails.. There is no conflict between the RIRs over which registry is authoritative. They have all come to agreements on the matter. As to Lloyds, they're welcome to try to do that now, but, the question is what would make ISPs listen to them? > > Or even worse, what if the door is opened to the ITU to claim the RIR system was failing in a post-exhaust era, and seek to create its own registry system, or otherwise take control? I think if we start eating our responsibilities for breakfast after sacrificing them on the altar of greed, this is virtually assured. > > Once again, I make the point that a market in IPv4 addresses, such as envisaged in 8.3 or in the APNIC transfer policy, meets the stewardship goal of conservation through natural market forces. > If we ladle on an extra helping of steward meddling, we are taking action in contravention of our primary duty to maintain a viable and trusted registry. 8.3 does, yes. The APNIC policy, IMHO, does not because it allows those without need to obtain addresses for purposes contrary to the best interests and wishes of the community. This is not about making qualitative judgment about needs. There is no comparison of worthiness of a need. Merely the evaluation of whether need exists or not and to what extent. This is a perfectly valid criteria to apply and to continue to apply. > > So I would support the proposal if the requirement was simply that both RIRs approve, leaving off the "signal" sent by the needs language, which signal reads like a shot across the bow to me. Yes, but, this is because you are in general in favor of eliminating needs basis. I think we all get that, but, I think as long as the community chooses to preserve needs basis within the region, this phrase is critical and vital to preserve that intent in this policy. You may read it however you want. I doubt that the APNIC staff will consider it a shot across the bow, but, I'm sure that some of the community members in APNIC will oppose it. I will point out that if that is the case, they are welcome to express that opposition here if they care to. Owen -------------- next part -------------- An HTML attachment was scrubbed... URL: From owen at delong.com Fri May 27 16:23:30 2011 From: owen at delong.com (Owen DeLong) Date: Fri, 27 May 2011 13:23:30 -0700 Subject: [arin-ppml] ARIN-prop-152 RSA Modification Limits In-Reply-To: <4DDFB9A2.8070304@umn.edu> References: <4DDFA799.6060005@arin.net> <4DDFB9A2.8070304@umn.edu> Message-ID: <5ED5190C-A5D9-4B97-943D-CAC1602F0D8C@delong.com> On May 27, 2011, at 7:48 AM, David Farmer wrote: > On 5/27/11 08:31 CDT, ARIN wrote: > >> The above requirements may be waived to the extent necessary to meet a >> court order or settlement, but, such court order must be public or such >> settlement must include terms allowing the settlement terms to be >> published by ARIN, including the list of affected addresses and the >> exact resulting RSA. ARIN shall publish the terms of any such settlement >> and the resulting RSA within 10 days of drafting the settlement or RSA >> whichever comes later. > > This paragraph has some significant issues. It is not possible for ARIN to dictate what information regarding a court order is public information, that is only in the control of the judge issuing the order. If some information regarded a court order were ordered confidential, ARIN would be in contempt of such a court order if it improperly disclosed such confidential information, which this policy seems to require. > It doesn't It merely requires the order itself to be public. It does, however, prohibit ARIN from agreeing to a settlement which requires confidentiality. > ARIN evaluates and protects confidential contract and business information on behalf of the community all the time, I'm not sure why this situation should be any different than all the others. While transparency is an important objective, I feel this policy goes to far, and can not support it as written. > Fair enough. I would be willing to strike the part requiring a court order to be public, but, I would prefer to preserve the settlement language. Would that be acceptable to you? > The rest of the policy other than this paragraph seems like it could be a useful policy improvement if it accurately reflects the community's intent. > Thanks. Owen From owen at delong.com Fri May 27 16:35:27 2011 From: owen at delong.com (Owen DeLong) Date: Fri, 27 May 2011 13:35:27 -0700 Subject: [arin-ppml] Integrating Draft Policy ARIN-2011-1 into NRPM 8.3 In-Reply-To: References: <07DCA09506E941C3AEE0B6562DF8DB4E@mike> <00ac01cc19c6$2c803340$858099c0$@iname.com> <0114D408-5D5F-4EC3-A193-BE10687D7A8C@delong.com> <-5099803936536899096@unknownmsgid> <349C8AD2-9C4B-4B0F-8875-A6040341F476@delong.com> <00d901cc1a8c$cd5ba260$6812e720$@iname.com> <680F5536-8FF7-48F0-9EC0-5831BEA9418F@delong.com> <282597B677794DB49A1E3CE343BEF17B@mike> <8DB5F2EE-8444-4CF0-8C5F-B5F48BDB3570@delong.com> <6CDF97E7-11C5-486D-9ECD-ADB4A215DDF1@delong.com> Message-ID: On May 27, 2011, at 8:38 AM, Aaron Dudek wrote: > On Fri, May 27, 2011 at 00:09, Owen DeLong wrote: >> >> On May 26, 2011, at 6:44 PM, Aaron Dudek wrote: >> >>> Currently the only way to transfer owner ship is through 8.2 Mergers >>> and Acquisitions. >>> Company A received an initial allocation. Company B received a >>> significant allocation from Company A. >>> >> >> >>> Company A goes out of business. There is no method for company B to >>> take over the block from company A. >> >> If company B has a large enough need to meet the criteria for a direct >> assignment (I doubt they received an allocation as you describe), >> then, why didn't they go to ARIN instead of Company A? >> >> If they didn't meet and/or don't meet the criteria, then, why should they >> be able to transfer a smaller netblock rather than renumber as an end-run >> on policy? > > Why are you assuming that they would get a smaller netblock? Why is > that a bad thing? If they don't fit in a smaller netblock, then, they were using Company A's entire block, in which case, they qualify under policy to get their own netblock, right? This would fit the first case above, rather than the second. > Renumbering is not easy even with ipv6. True. So? > Why are you assuming that they may not be able to meet the criteria > now? How is this an > end-run on polcy when they still have to meet the ARIN guidelines? I am not. I listed too cases... Case one: IF THEY DO and explained why this policy is unnecessary in that case. Case two: IF THEY DO NOT and explained why this policy is unnecessary in that case. > > > >> >> I don't think that B's poor planning is something we should codify in >> ARIN policy. >> > > Polices change over time. What may have be forbidden before may now be > allowed. There once > was a time that end-users where not allowed to get IPv6 space and had > to get it from the LIRs. > That is not poor planning, just following policy has policy dictated > at the time. > True. However, the number of IPv6 assignments issued prior to this time by LIRs was, uh, trivial and I suspect that the number of significant IPv6 deployments built prior to that was even smaller. The simple approach would be to clean these up by getting and renumbering into ARIN direct assignments. Policy even allows you to do this over a very long time as things currently stand, assuming that your LIR continues to allow you to use the space. > The policy doesn't allow for clean ups of ipv6 whois allocations > outside of mergers and acquisitions. Sure it does. Get your ARIN direct assignment and renumber. Simple, really. > There have been requests to do so, but since they are outside of 8.2, > 8.3 doesn't allow for it. > And it shouldn't. This would create significant cruft mixing assignment and allocation spaces. In addition, there would be other negative side effects of this proposed policy, such as creating a potential market in IPv6 address space which if current proposals are enacted could also result in an easy ability to do end-runs on IP number resource policy through this process. Owen >>> Company A has to migrate to a larger block. There is no method for >>> company B to take over the block from company A. >>> >> >> Right. I think this falls into the same answers as above. >> >>> These are just a couple of examples. >>> ARIN still has the final say of any transfers as per the rest of 8.3 >>> as the "new owner" has to show need and justification just as before. >>> >> >> ARIN policy has the final say. ARIN's ability to say no is limited to exactly >> those things proscribed by policy, not even the ones obviously intended >> to be proscribed by policy as recent experience has shown. >> >> Owen >> >>> Aaron >>> >>> On Thu, May 26, 2011 at 16:14, Owen DeLong wrote: >>>> >>>> On May 26, 2011, at 12:45 PM, Aaron Dudek wrote: >>>> >>>>> Since we are discussing 8.3. >>>>> I feel that there should be language to allow for transfers of IPv6. >>>>> Currently there is no language to allow for transfers of IPv6 allocations. >>>>> So essentially >>>>> >>>> >>>> IMHO, there should not. The need to facilitate directed transfers >>>> in IPv4 is strictly a result of the intersection of legacy addresses and >>>> failure to have a strong mechanism for address policy with legacy >>>> resources combined with the shortage of addresses. >>>> >>>> Neither of these factors applies to IPv6 and such transfers have no >>>> positive effect. >>>> >>>> Owen >>>> >>>> >>>>> 8.3. Transfers to Specified Recipients >>>>> >>>>> In addition to transfers under section 8.2, IPv4 and IPv6 number resources >>>>> within the ARIN region may be released to ARIN by the authorized resource >>>>> holder, in whole or in part, for transfer to another specified >>>>> organizational recipient....... >>>>> >>>>> The other option would to remove the version number and just leave IP number >>>>> resources.... >>>>> >>>>> Thank you, >>>>> >>>>> Aaron Dudek >>>>> >>>>>> On Thu, May 26, 2011 at 01:34, Owen DeLong wrote: >>>>>>> >>>>>>> On May 25, 2011, at 2:06 PM, Jeffrey Lyon wrote: >>>>>>> >>>>>>>> On Wed, May 25, 2011 at 1:57 PM, Owen DeLong wrote: >>>>>>>>> It doesn't surprise me to see that we will disagree on this. >>>>>>>>> Since you are opposed to needs-basis in general, I don't expect you to >>>>>>>>> understand >>>>>>>>> the need to preserve it here or to agree with it. >>>>>>>>> Owen >>>>>>>>> On May 25, 2011, at 9:21 AM, Mike Burns wrote: >>>>>>>> >>>>>>>> Similarly, I don't expect you to entertain any logic that free markets >>>>>>>> are beneficial. I suspect spending a lot of time in the Bay Area has >>>>>>>> that effect. >>>>>>>> >>>>>>> >>>>>>> I think there are places where regulated free markets can be beneficial. >>>>>>> >>>>>>> If you can point to a single historical example of an unregulated free >>>>>>> market that >>>>>>> remained beneficial and unregulated for more than 5 years, I'll be >>>>>>> surprised. >>>>>>> >>>>>>> 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. >>>>>> >>>>>> >>>>> _______________________________________________ >>>>> 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 27 16:57:36 2011 From: bill at herrin.us (William Herrin) Date: Fri, 27 May 2011 16:57:36 -0400 Subject: [arin-ppml] ARIN-prop-152 RSA Modification Limits In-Reply-To: <4DDFA799.6060005@arin.net> References: <4DDFA799.6060005@arin.net> Message-ID: On Fri, May 27, 2011 at 9:31 AM, ARIN wrote: > ARIN-prop-152 RSA Modification Limits > All transfers conducted under section 8 of the NRPM shall require the > recipient to sign an RSA which provides at least the same limitations > and restrictions as the standard RSA that would be used with any new > allocation or assignment of number resources in at least the following > areas: > > ?a. Justified Need Requirements > ?b. Subject to and Effect of NRPM 12 > ?c. Requirement for an annual fee to be paid > ?d. Subject to future policy revisions adopted by the community > > The above requirements may be waived to the extent necessary to meet a > court order or settlement, but, such court order must be public or such > settlement must include terms allowing the settlement terms to be > published by ARIN, including the list of affected addresses and the > exact resulting RSA. ARIN shall publish the terms of any such settlement > and the resulting RSA within 10 days of drafting the settlement or RSA > whichever comes later. Opposed. For one thing, section 8.2 transfers occur because an organization and its network has new ownership. The organization hasn't changed. It's not even necessarily a transfer, it may just be a name change. The RSA rules belong under section 8.3 only, which is where we thought we had them. For another, this language is needlessly verbose. "The recipient of an 8.3 transfer shall sign and adhere to the same RSA as a recipient of number resources under NRPM section 4." Nothing more needs be said. 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 Fri May 27 17:40:23 2011 From: owen at delong.com (Owen DeLong) Date: Fri, 27 May 2011 14:40:23 -0700 Subject: [arin-ppml] ARIN-prop-152 RSA Modification Limits In-Reply-To: References: <4DDFA799.6060005@arin.net> Message-ID: On May 27, 2011, at 1:57 PM, William Herrin wrote: > On Fri, May 27, 2011 at 9:31 AM, ARIN wrote: >> ARIN-prop-152 RSA Modification Limits > >> All transfers conducted under section 8 of the NRPM shall require the >> recipient to sign an RSA which provides at least the same limitations >> and restrictions as the standard RSA that would be used with any new >> allocation or assignment of number resources in at least the following >> areas: >> >> a. Justified Need Requirements >> b. Subject to and Effect of NRPM 12 >> c. Requirement for an annual fee to be paid >> d. Subject to future policy revisions adopted by the community >> >> The above requirements may be waived to the extent necessary to meet a >> court order or settlement, but, such court order must be public or such >> settlement must include terms allowing the settlement terms to be >> published by ARIN, including the list of affected addresses and the >> exact resulting RSA. ARIN shall publish the terms of any such settlement >> and the resulting RSA within 10 days of drafting the settlement or RSA >> whichever comes later. > > > Opposed. > > For one thing, section 8.2 transfers occur because an organization and > its network has new ownership. The organization hasn't changed. It's > not even necessarily a transfer, it may just be a name change. The RSA > rules belong under section 8.3 only, which is where we thought we had > them. > Regardless I believe it should still require a standard RSA or something as reasonably close to it as we can get. > For another, this language is needlessly verbose. "The recipient of an > 8.3 transfer shall sign and adhere to the same RSA as a recipient of > number resources under NRPM section 4." Nothing more needs be said. > We've been advised by staff that such a restriction will be viewed as operational and not a policy matter and that we need to address the specific RSA aspects that are a policy concern. So, while I agree with you about it, the reality we are faced with is that such a requirement has been deemed a non-policy matter by staff and we need to do what we can within the bounds of policy. Owen From matthew at matthew.at Fri May 27 18:46:41 2011 From: matthew at matthew.at (Matthew Kaufman) Date: Sat, 28 May 2011 00:46:41 +0200 Subject: [arin-ppml] ARIN-prop-153 Correct erroneous syntax in NRPM 8.3 In-Reply-To: <11189C06-3B22-491B-8A81-972250BA537D@delong.com> References: <4DDFA7A6.105@arin.net> <11189C06-3B22-491B-8A81-972250BA537D@delong.com> Message-ID: <9CB0235C-44EF-4FF8-A771-50DB827F0727@matthew.at> On May 27, 2011, at 10:08 PM, Owen DeLong wrote: > >> Also, I have noted in that proposal that the single-aggregate transfer requirement as it would apply with this proposal in effect can be trivially worked around simply by submitting a large number of individual transfers, each of which comes with justification. This just increases the amount of paperwork for both parties *and* ARIN with no other benefit. >> > > So you have said, however, the reality is that the language in 8.3 was put there by the AC for a reason > and with an intent which was supported by the consensus of the community. > > You prefer to abandon that intent based on the interpretation of the language. I prefer to correct the > language so that it matches the original intent. I think experience shows that the current interpretation of the language reduces cost for everyone involved, and that restoring the "original intent" changes absolutely nothing... in other words, transfers of 660,000 addresses from multiple blocks will still occur between a pair of entities, only this time it'll be a whole raft of need justification and transfer request forms instead of just one. > > Subsequent transfers would be the result of subsequent needs, presumably, so, I'm not seeing that > this is necessarily in conflict. Sure, "subsequent" in that the next needs justification was submitted 30 seconds after the previous one. Matthew Kaufman From owen at delong.com Fri May 27 19:09:45 2011 From: owen at delong.com (Owen DeLong) Date: Fri, 27 May 2011 16:09:45 -0700 Subject: [arin-ppml] ARIN-prop-153 Correct erroneous syntax in NRPM 8.3 In-Reply-To: <9CB0235C-44EF-4FF8-A771-50DB827F0727@matthew.at> References: <4DDFA7A6.105@arin.net> <11189C06-3B22-491B-8A81-972250BA537D@delong.com> <9CB0235C-44EF-4FF8-A771-50DB827F0727@matthew.at> Message-ID: On May 27, 2011, at 3:46 PM, Matthew Kaufman wrote: > > On May 27, 2011, at 10:08 PM, Owen DeLong wrote: > >> >>> Also, I have noted in that proposal that the single-aggregate transfer requirement as it would apply with this proposal in effect can be trivially worked around simply by submitting a large number of individual transfers, each of which comes with justification. This just increases the amount of paperwork for both parties *and* ARIN with no other benefit. >>> >> >> So you have said, however, the reality is that the language in 8.3 was put there by the AC for a reason >> and with an intent which was supported by the consensus of the community. >> >> You prefer to abandon that intent based on the interpretation of the language. I prefer to correct the >> language so that it matches the original intent. > > I think experience shows that the current interpretation of the language reduces cost for everyone involved, and that restoring the "original intent" changes absolutely nothing... in other words, transfers of 660,000 addresses from multiple blocks will still occur between a pair of entities, only this time it'll be a whole raft of need justification and transfer request forms instead of just one. > I don't think experience shows anything of the sort. I think experience shows that the current interpretation makes it easy to circumvent the intent. I don't think we have any experience with what would happen with the language change. >> >> Subsequent transfers would be the result of subsequent needs, presumably, so, I'm not seeing that >> this is necessarily in conflict. > > Sure, "subsequent" in that the next needs justification was submitted 30 seconds after the previous one. > Given the time ARIN takes to evaluate and turn around a request, I don't think that's actually true. I also trust that staff would become suspicious and investigate such situations appropriately as well. Owen From matthew at matthew.at Fri May 27 19:25:20 2011 From: matthew at matthew.at (Matthew Kaufman) Date: Sat, 28 May 2011 01:25:20 +0200 Subject: [arin-ppml] ARIN-prop-153 Correct erroneous syntax in NRPM 8.3 In-Reply-To: References: <4DDFA7A6.105@arin.net> <11189C06-3B22-491B-8A81-972250BA537D@delong.com> <9CB0235C-44EF-4FF8-A771-50DB827F0727@matthew.at> Message-ID: <5DF3E997-21AC-4287-B4AB-D3CE84BF5EB8@matthew.at> On May 28, 2011, at 1:09 AM, Owen DeLong wrote: >> > > Given the time ARIN takes to evaluate and turn around a request, I don't think that's actually true. I also > trust that staff would become suspicious and investigate such situations appropriately as well. What's "suspicious" about it? I tell ARIN "look, I need 660,000 addresses... I found someone with that many, but they're in a bunch of different blocks. Over the next few hours you'll be getting a bunch of transfer request forms with associated justification" "Here's my justification that I need 660,000 addresses... which of course also justifies the 65536 for this /16" "Here's my justification that I still need over 594k addresses... which of course is sufficient to justify the 131072 for this /15" "Here's my justification that I still need over 463k addresses... which of course is sufficient to justify the 512 for this /23" And so on and so on until they get down to the last block. Nothing suspicious, nothing that violates the policy, just a big waste of time for all three parties involved. I think this is one case where the staff outsmarted the AC for a good reason. Matthew Kaufman From bill at herrin.us Fri May 27 19:37:33 2011 From: bill at herrin.us (William Herrin) Date: Fri, 27 May 2011 19:37:33 -0400 Subject: [arin-ppml] ARIN-prop-152 RSA Modification Limits In-Reply-To: References: <4DDFA799.6060005@arin.net> Message-ID: On Fri, May 27, 2011 at 5:40 PM, Owen DeLong wrote: > On May 27, 2011, at 1:57 PM, William Herrin wrote: >> For another, this language is needlessly verbose. "The recipient of an >> 8.3 transfer shall sign and adhere to the same RSA as a recipient of >> number resources under NRPM section 4." Nothing more needs be said. > > We've been advised by staff that such a restriction will be viewed as > operational and not a policy matter and that we need to address the > specific RSA aspects that are a policy concern. > > So, while I agree with you about it, the reality we are faced with is that > such a requirement has been deemed a non-policy matter by staff > and we need to do what we can within the bounds of policy. No problem. Old: 8.3. Transfers to Specified Recipients In addition to transfers under section 8.2, IPv4 number resources within the ARIN region may be released to ARIN by the authorized resource holder, in whole or in part, for transfer to another specified organizational recipient. Such transferred number resources may only be received under RSA by organizations that are within the ARIN region and can demonstrate the need for such resources, as a single aggregate, in the exact amount which they can justify under current ARIN policies. New: 8.3. Transfers to Specified Recipients In addition to transfers under section 8.2, IPv4 number resources within the ARIN region may be released to ARIN by the authorized resource holder, in whole or in part, for transfer to another specified organizational recipient. Receipt of the released number resources to the designated organization shall occur pursuant to the ordinary policies and procedures applied in and for section 4. 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 27 19:58:19 2011 From: bill at herrin.us (William Herrin) Date: Fri, 27 May 2011 19:58:19 -0400 Subject: [arin-ppml] ARIN-prop-152 RSA Modification Limits In-Reply-To: References: <4DDFA799.6060005@arin.net> Message-ID: On Fri, May 27, 2011 at 7:37 PM, William Herrin wrote: > On Fri, May 27, 2011 at 5:40 PM, Owen DeLong wrote: >> On May 27, 2011, at 1:57 PM, William Herrin wrote: >>> For another, this language is needlessly verbose. "The recipient of an >>> 8.3 transfer shall sign and adhere to the same RSA as a recipient of >>> number resources under NRPM section 4." Nothing more needs be said. >> >> We've been advised by staff that such a restriction will be viewed as >> operational and not a policy matter and that we need to address the >> specific RSA aspects that are a policy concern. >> >> So, while I agree with you about it, the reality we are faced with is that >> such a requirement has been deemed a non-policy matter by staff >> and we need to do what we can within the bounds of policy. > > No problem. > > Old: > > 8.3. Transfers to Specified Recipients > > In addition to transfers under section 8.2, IPv4 number resources > within the ARIN region may be released to ARIN by the authorized > resource holder, in whole or in part, for transfer to another > specified organizational recipient. Such transferred number resources > may only be received under RSA by organizations that are within the > ARIN region and can demonstrate the need for such resources, as a > single aggregate, in the exact amount which they can justify under > current ARIN policies. > > > New: > > 8.3. Transfers to Specified Recipients > > In addition to transfers under section 8.2, IPv4 number resources > within the ARIN region may be released to ARIN by the authorized > resource holder, in whole or in part, for transfer to another > specified organizational recipient. Receipt of the released number > resources to the designated organization shall occur pursuant to the > ordinary policies and procedures applied in and for section 4. And if you don't like that one, try this one: 4.11 Source of IPv4 addresses An organization requesting number resources under section 4 may specify whether they want the request satisfied from ARIN's free pool of addresses or from number resources released to ARIN under section 8.3. If not specified, approved requests will be filled from the first available source. 8.3. Transfers to Specified Recipients In addition to transfers under section 8.2, IPv4 number resources within the ARIN region may be released to ARIN by the authorized resource holder, in whole or in part, to be used when filling a specified, pre-approved request under section 4. -Bill -- 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 Fri May 27 20:03:03 2011 From: owen at delong.com (Owen DeLong) Date: Fri, 27 May 2011 17:03:03 -0700 Subject: [arin-ppml] ARIN-prop-153 Correct erroneous syntax in NRPM 8.3 In-Reply-To: <5DF3E997-21AC-4287-B4AB-D3CE84BF5EB8@matthew.at> References: <4DDFA7A6.105@arin.net> <11189C06-3B22-491B-8A81-972250BA537D@delong.com> <9CB0235C-44EF-4FF8-A771-50DB827F0727@matthew.at> <5DF3E997-21AC-4287-B4AB-D3CE84BF5EB8@matthew.at> Message-ID: On May 27, 2011, at 4:25 PM, Matthew Kaufman wrote: > > On May 28, 2011, at 1:09 AM, Owen DeLong wrote: > >>> >> >> Given the time ARIN takes to evaluate and turn around a request, I don't think that's actually true. I also >> trust that staff would become suspicious and investigate such situations appropriately as well. > > > What's "suspicious" about it? I tell ARIN "look, I need 660,000 addresses... I found someone with that many, but they're in a bunch of different blocks. Over the next few hours you'll be getting a bunch of transfer request forms with associated justification" > > "Here's my justification that I need 660,000 addresses... which of course also justifies the 65536 for this /16" > > "Here's my justification that I still need over 594k addresses... which of course is sufficient to justify the 131072 for this /15" > > "Here's my justification that I still need over 463k addresses... which of course is sufficient to justify the 512 for this /23" > ARIN would quickly identify this as an end-run on the policy and block it, I believe. John, care to comment? > And so on and so on until they get down to the last block. > > Nothing suspicious, nothing that violates the policy, just a big waste of time for all three parties involved. > Actually it does. However, I'll be happy to correct the language to prevent such a workaround if you think it is necessary. > I think this is one case where the staff outsmarted the AC for a good reason. > We can agree to disagree. Owen From owen at delong.com Fri May 27 20:05:12 2011 From: owen at delong.com (Owen DeLong) Date: Fri, 27 May 2011 17:05:12 -0700 Subject: [arin-ppml] ARIN-prop-152 RSA Modification Limits In-Reply-To: References: <4DDFA799.6060005@arin.net> Message-ID: <39F8FA0C-05BA-4482-AFF0-94DFD7F0D3E3@delong.com> On May 27, 2011, at 4:37 PM, William Herrin wrote: > On Fri, May 27, 2011 at 5:40 PM, Owen DeLong wrote: >> On May 27, 2011, at 1:57 PM, William Herrin wrote: >>> For another, this language is needlessly verbose. "The recipient of an >>> 8.3 transfer shall sign and adhere to the same RSA as a recipient of >>> number resources under NRPM section 4." Nothing more needs be said. >> >> We've been advised by staff that such a restriction will be viewed as >> operational and not a policy matter and that we need to address the >> specific RSA aspects that are a policy concern. >> >> So, while I agree with you about it, the reality we are faced with is that >> such a requirement has been deemed a non-policy matter by staff >> and we need to do what we can within the bounds of policy. > > No problem. > > Old: > > 8.3. Transfers to Specified Recipients > > In addition to transfers under section 8.2, IPv4 number resources > within the ARIN region may be released to ARIN by the authorized > resource holder, in whole or in part, for transfer to another > specified organizational recipient. Such transferred number resources > may only be received under RSA by organizations that are within the > ARIN region and can demonstrate the need for such resources, as a > single aggregate, in the exact amount which they can justify under > current ARIN policies. > > > New: > > 8.3. Transfers to Specified Recipients > > In addition to transfers under section 8.2, IPv4 number resources > within the ARIN region may be released to ARIN by the authorized > resource holder, in whole or in part, for transfer to another > specified organizational recipient. Receipt of the released number > resources to the designated organization shall occur pursuant to the > ordinary policies and procedures applied in and for section 4. > I actually rather like that. However, I'd still like to place some limitations on the ability to preserve legacy status across an M&A transfer as well. Owen From ikiris at gmail.com Fri May 27 20:14:37 2011 From: ikiris at gmail.com (Blake Dunlap) Date: Fri, 27 May 2011 19:14:37 -0500 Subject: [arin-ppml] ARIN-prop-153 Correct erroneous syntax in NRPM 8.3 Message-ID: On Fri, May 27, 2011 at 18:09, Owen DeLong wrote: > > > On May 27, 2011, at 3:46 PM, Matthew Kaufman wrote: > > > > > On May 27, 2011, at 10:08 PM, Owen DeLong wrote: > > > >> > >>> Also, I have noted in that proposal that the single-aggregate transfer requirement as it would apply with this proposal in effect can be trivially worked around simply by submitting a large number of individual transfers, each of which comes with justification. This just increases the amount of paperwork for both parties *and* ARIN with no other benefit. > >>> > >> > >> So you have said, however, the reality is that the language in 8.3 was put there by the AC for a reason > >> and with an intent which was supported by the consensus of the community. > >> > >> You prefer to abandon that intent based on the interpretation of the language. I prefer to correct the > >> language so that it matches the original intent. > > > > I think experience shows that the current interpretation of the language reduces cost for everyone involved, and that restoring the "original intent" changes absolutely nothing... in other words, transfers of 660,000 addresses from multiple blocks will still occur between a pair of entities, only this time it'll be a whole raft of need justification and transfer request forms instead of just one. > > > > I don't think experience shows anything of the sort. I think experience shows that the current interpretation > makes it easy to circumvent the intent. I don't think we have any experience with what would happen > with the language change. > > >> > >> Subsequent transfers would be the result of subsequent needs, presumably, so, I'm not seeing that > >> this is necessarily in conflict. > > > > Sure, "subsequent" in that the next needs justification was submitted 30 seconds after the previous one. > > > > Given the time ARIN takes to evaluate and turn around a request, I don't think that's actually true. I also > trust that staff would become suspicious and investigate such situations appropriately as well. > > Owen I would prefer to add a minimum blackout period, as opposed to relying on the above, as we already have evidence of ARIN staff creatively interpreting policy to facilitate transfers for requestors, to a much greater degree than required to simply allow back to back to back transfers. -Blake -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthew at matthew.at Sat May 28 01:22:36 2011 From: matthew at matthew.at (Matthew Kaufman) Date: Sat, 28 May 2011 07:22:36 +0200 Subject: [arin-ppml] ARIN-prop-153 Correct erroneous syntax in NRPM 8.3 In-Reply-To: References: <4DDFA7A6.105@arin.net> <11189C06-3B22-491B-8A81-972250BA537D@delong.com> <9CB0235C-44EF-4FF8-A771-50DB827F0727@matthew.at> <5DF3E997-21AC-4287-B4AB-D3CE84BF5EB8@matthew.at> Message-ID: On May 28, 2011, at 2:03 AM, Owen DeLong wrote: > > On May 27, 2011, at 4:25 PM, Matthew Kaufman wrote: > >> >> On May 28, 2011, at 1:09 AM, Owen DeLong wrote: >> >>>> >>> >>> Given the time ARIN takes to evaluate and turn around a request, I don't think that's actually true. I also >>> trust that staff would become suspicious and investigate such situations appropriately as well. >> >> >> What's "suspicious" about it? I tell ARIN "look, I need 660,000 addresses... I found someone with that many, but they're in a bunch of different blocks. Over the next few hours you'll be getting a bunch of transfer request forms with associated justification" >> >> "Here's my justification that I need 660,000 addresses... which of course also justifies the 65536 for this /16" >> >> "Here's my justification that I still need over 594k addresses... which of course is sufficient to justify the 131072 for this /15" >> >> "Here's my justification that I still need over 463k addresses... which of course is sufficient to justify the 512 for this /23" >> > > ARIN would quickly identify this as an end-run on the policy and block it, I believe. John, care to comment? > This isn't an "end run" around the policy change you've written. The recipient has a valid need for 660,000 addresses and they can be fulfilled by one or more transfers of blocks. >> And so on and so on until they get down to the last block. >> >> Nothing suspicious, nothing that violates the policy, just a big waste of time for all three parties involved. >> > Actually it does. However, I'll be happy to correct the language to prevent such a workaround if you > think it is necessary. I don't think it is necessary at all. I think this change is a waste of time and that my change is more appropriate. > > >> I think this is one case where the staff outsmarted the AC for a good reason. >> > > We can agree to disagree. Or not. Matthew Kaufman From frnkblk at iname.com Sat May 28 02:29:12 2011 From: frnkblk at iname.com (Frank Bulk) Date: Sat, 28 May 2011 01:29:12 -0500 Subject: [arin-ppml] Integrating Draft Policy ARIN-2011-1 into NRPM 8.3 In-Reply-To: <680F5536-8FF7-48F0-9EC0-5831BEA9418F@delong.com> References: <07DCA09506E941C3AEE0B6562DF8DB4E@mike> <00ac01cc19c6$2c803340$858099c0$@iname.com> <0114D408-5D5F-4EC3-A193-BE10687D7A8C@delong.com> <-5099803936536899096@unknownmsgid> <349C8AD2-9C4B-4B0F-8875-A6040341F476@delong.com> <00d901cc1a8c$cd5ba260$6812e720$@iname.com> <680F5536-8FF7-48F0-9EC0-5831BEA9418F@delong.com> Message-ID: <010b01cc1d00$8f7162c0$ae542840$@iname.com> In this case you chose one (important, to be sure!) element of the transfer policy. Singling out one element of the policy could be perceived as trying to make some kind of statement - in fact, that has already been noted in this thread. If it wasn't for APNIC's elimination of needs, could I assume "needs" wouldn't have been suggested? So, for the second item, I still suggest the wording: to another RIR, for transfer to a specified recipient in that RIR's service region, if the request meets both RIRS' transfer policies. Frank From: Owen DeLong [mailto:owen at delong.com] Sent: Wednesday, May 25, 2011 11:01 AM To: frnkblk at iname.com Cc: ARIN-PPML List; Scott Leibrand Subject: Re: [arin-ppml] Integrating Draft Policy ARIN-2011-1 into NRPM 8.3 I would prefer since we are venturing into inter-RIR territory to have this policy be as specific and complete as possible and stand alone to the greatest possible extent. In this case, I think excessive clarity where practicable is worth while. Owen On May 24, 2011, at 8:35 PM, Frank Bulk wrote: Since currently ARIN policy implements the needs-basis, isn't mentioning that requirement in 2011-1 redundant? Or are you concerned that some ARIN policies might remove the needs-basis requirement and you want to preserve the requirement in the inter-RIR transfer? Frank From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Owen DeLong Sent: Tuesday, May 24, 2011 12:47 AM To: Scott Leibrand Cc: ARIN-PPML List Subject: Re: [arin-ppml] Integrating Draft Policy ARIN-2011-1 into NRPM 8.3 I still would prefer to see the needs-basis comment preserved as well. Owen On May 23, 2011, at 10:07 PM, Scott Leibrand wrote: So perhaps: + to another RIR, for transfer to a specified recipient in that RIR's service region, if both RIRs agree and the request meets both RIRs' transfer policies. I agree it's useful to preserve discretion. I think I might prefer this to the text I originally had below... Thoughts? Scott On May 23, 2011, at 9:56 PM, Owen DeLong wrote: I prefer to preserve the safety valve of requiring agreement from both RIRs. Owen On May 23, 2011, at 8:53 PM, Frank Bulk wrote: Why don't we change the second point to: + to another RIR, for transfer to a specified recipient in that RIR's service region, if the request meets both RIRS' transfer policies. Frank ----- Original Message ----- From: Scott Leibrand To: Owen DeLong Cc: ARIN-PPML List Sent: Monday, May 23, 2011 5:21 PM Subject: Re: [arin-ppml] Integrating Draft Policy ARIN-2011-1 into NRPM 8.3 On Mon, May 23, 2011 at 2:05 PM, Owen DeLong wrote: I could support this, but, I have a couple of lingering concerns. I think that the last sentence dictates too much in the case of a transfer to another region and should only apply to transfers within the ARIN region. Yeah, I was wondering about that myself. Possible slight revision inline below... On May 23, 2011, at 15:54, Scott Leibrand wrote: In light of the discomfort a number of community and AC members feel with the original 2011-1 text, I thought I'd make an attempt at integrating it into the framework of NRPM 8.3, to see if the result would be tighter and less ambiguous. Here's what I came up with: 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, in whole or in part, for transfer: * to a specified organizational recipient within the ARIN region, or * to another RIR, for transfer to a specified organizational recipient in that RIR's service region, if the two RIRs agree and maintain compatible, needs-based transfer policies. Such transferred number resources may only be received under RSA by organizations that can demonstrate the need for such resources, as a single aggregate, in the exact amount which they can justify under current ARIN policies. How about "Such number resources may only be received under RSA by organizations that can demonstrate the need for such resources, as a single aggregate, in the exact amount which they can justify under current ARIN, or recipient RIR, policies." ? Or, feel free to suggest text... -Scott For reference, existing policy reads: 8.3. Transfers to Specified Recipients In addition to transfers under section 8.2, IPv4 number resources within the ARIN region may be released to ARIN by the authorized resource holder, in whole or in part, for transfer to another specified organizational recipient. Such transferred number resources may only be received under RSA by organizations that are within the ARIN region and can demonstrate the need for such resources, as a single aggregate, in the exact amount which they can justify under current ARIN policies. And original 2011-1 text reads: Any RIR's resource registrant may transfer IPv4 addresses to the resource registrant of another RIR as long as the two RIRs agree and maintain compatible, needs-based transfer policies that exercise Internet stewardship consistent with the values expressed in RFC2050. _______________________________________________ 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. _______________________________________________ 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 frnkblk at iname.com Sat May 28 02:56:09 2011 From: frnkblk at iname.com (Frank Bulk) Date: Sat, 28 May 2011 01:56:09 -0500 Subject: [arin-ppml] Draft Policy 2011-7 Compliance Requirement In-Reply-To: <4DDC0293.4020104@arin.net> References: <4DDC0293.4020104@arin.net> Message-ID: <011001cc1d04$53248a00$f96d9e00$@iname.com> In regard to ARIN counsel's discussion about "lack of compliance" -- ARIN staff make that determination on new requests each and every day (i.e. the request meets the policies or they don't). It's not clear to me how reviewing a current resource holder's compliancy requires "black and white", or only to look at a subset of policies. To be sure, a review does not include the applicant's documentation, but that could be requested if what's readily available is insufficient to verify compliancy. I agree that words "fraud" and "materially" are loaded words and that by itself requires that this proposal be re-written. Frank -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of ARIN Sent: Tuesday, May 24, 2011 2:10 PM To: arin-ppml at arin.net Subject: [arin-ppml] Draft Policy 2011-7 Compliance Requirement Draft Policy ARIN-2011-7 Compliance Requirement On 19 May 2011 the ARIN Advisory Council (AC) selected "Returned IPv4 Addresses" as a draft policy for adoption discussion on the PPML and at the Public Policy Meeting in San Juan, Puerto Rico in April. The draft was developed by the AC from policy proposal "ARIN-prop-126 Compliance Requirement." Per the Policy Development Process the AC submitted text to ARIN for a staff and legal assessment prior to its selection as a draft policy. Below the draft policy is the ARIN staff and legal assessment, followed by the text that was submitted by the AC. Note that the AC revised the draft policy text after they received the assessment from staff. Draft Policy ARIN-2011-7 is below and can be found at: https://www.arin.net/policy/proposals/2011_7.html You are encouraged to discuss Draft Policy 2011-7 on the PPML prior to the October Public Policy Meeting. Both the discussion on the list and at the meeting will be used by the ARIN Advisory Council to determine the community consensus for adopting this as policy. The ARIN Policy Development Process can be found at: https://www.arin.net/policy/pdp.html Draft Policies and Proposals under discussion can be found at: https://www.arin.net/policy/proposals/index.html Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## Draft Policy ARIN-2011-7 Compliance Requirement Date/version: 24 May 2011 Policy statement: Resource Review Update the following NRPM Sections: 12.4 - Update to: Organizations found by ARIN to be out of compliance with current ARIN policy shall be required to update reassignment information or return resources as needed to bring them into (or reasonably close to) compliance 1. The degree to which an organization may remain out of compliance shall be based on the reasonable judgment of the ARIN staff and shall balance all facts known, including the organization's utilization rate, available address pool, and other factors as appropriate so as to avoid forcing returns which will result in near-term additional requests or unnecessary route de-aggregation. 2. To the extent possible, entire blocks should be returned. Partial address blocks shall be returned in such a way that the portion retained will comprise a single aggregate block. (leave 12.5 as is) 12.6 - Update to: Except in cases of fraud, an organization shall be given a minimum of thirty (30) days to respond. If an organization does not respond within those thirty (30) days, ARIN may cease providing reverse DNS services to that organization. If progress of resource returns or record corrections is not visible within sixty (60) days after correspondence with ARIN began, ARIN will cease providing reverse DNS services for the resources in question. At any time after ninety (90) days have passed, ARIN may initiate resource revocation as allowed in paragraph 12.5. ARIN shall negotiate a longer term with the organization if ARIN believes the organization is working in good faith to substantially restore compliance and has a valid need for additional time to renumber out of the affected blocks. Rationale: This version addresses several staff and legal concerns with the original text of this policy by clarifying the language and making it more concrete. To date the community has not documented or firmly established use of an effective enforcement mechanism. This policy will support current policy and compel those who are allocated ARIN resources to maintain the proper WHOIS records in accordance with ARIN NRPM. While it is recognized this is not an absolute solution to ensure compliance, it is the best method under current ARIN policies. Timetable for implementation: Immediate ##### This is an assessment of the proposal as originally submitted by the AC. The AC subsequently revised the proposal/draft policy text (see current version above). STAFF ASSESSMENT Proposal: Compliance Requirement (ARIN-prop-126) Policy Version (Date): 11 January 2011 Date of Assessment: 28 January 2011 1. Proposal Summary (Staff Understanding) This policy requires ARIN staff to not only identify customers who are out of compliance with policy, but to withhold services for those who fail to come into compliance within a designated time. Staff is to contact customers who are out of compliance with policy and give them 30 days to respond to our contact and to demonstrate they've begun to take corrective measures within 60 days. If either of these criteria is not met, the policy instructs staff to cease providing reverse DNS services to the customer or to begin reclamation efforts. 2. Comments A. ARIN Staff Comments . The policy says either "take away reverse" or "reclaim the numbers". It would be helpful to staff if there was clear guidance as to when revocation was to be used over reverse dns removal. Without clear guidance, staff would implement this in such a way that reverse dns removal would be used as the first step of the enforcement, and revocation of the resource as the final step when an organization is unable to come into compliance within a defined time period. . The term "materially out of compliance" is not well defined anywhere within this policy. Without additional criteria, staff will continue to interpret this term somewhat liberally, and to apply it at our discretion using our best judgment and consideration of existing factors. Only those organizations that we deem to be significantly in violation of existing policy will be flagged for further review and audit. B. ARIN General Counsel This policy has significant legal implications. It needs to be carefully edited to remove unnecessary ambiguities that might require enforcement when it should be discretionary and to avoid giving those "enforced against" arguments that will require case-by-case adjudication. For example, the first line of the policy at 12.4 uses "materiality" as a standard. I strongly recommend against such a standard, as anyone who is treated adversely will argue their "noncompliance" is "not material." If lack of compliance is the issue, it must be "black or white" as a review matter to protect against such drafting problems. If you believe noncompliance with a limited number of policies is a better approach, you can define such a set rather than overall compliance. Second, the "requested or required" (emphasis added) language is conceptually quite different - one is "a request," the other "a command." They must be separated if an escalation from "requested" to "required" is intended. Third, a similar drafting problem appears in 12.6 where "fraud" (a bad and intentional thing) is equated to "violations of policy" which could be trivial and not intended. Overall, if the policy was enacted as is, the risk of legal issues being thrust upon ARIN is unattractive and unwise. Counsel respectfully suggests a thorough rewrite of the draft to remove these and other issues of concern. 3. Resource Impact This policy would have moderate resource impact from an implementation aspect. It is estimated that implementation could occur within 6 - 9 months after ratification by the ARIN Board of Trustees. The implementation of this policy will require new software tools to track these newly defined deadlines. Additionally, there will likely be a significant increase in time and workload for the RS team as the potential for a significant increase in resource audits due to non-compliance with IPv6 reassignment requirements is great. This may even require additional personnel, although it is too early to tell right now. The following would be needed in order to implement: . Updated guidelines and website documentation . Staff training . Software tools would need to be developed to track the 30 and 60-day deadlines. 4. Proposal Text ARIN-prop-126 Policy statement: Resource Review Update the following NRPM Sections: 12.4 Update to: Organizations found by ARIN to be materially out of compliance with current ARIN policy shall be requested or required to return resources or update reassignment information as needed to bring them into (or reasonably close to) compliance. 12.5 Update to: If the organization does not voluntarily return resources or update reassignment information as requested, ARIN will cease providing reverse DNS services and/or revoke any resources issued by ARIN as required to bring the organization into overall compliance. ARIN shall follow the same guidelines for revocation that are required for voluntary return in the previous paragraph. 12.6 Update to: Except in cases of fraud, or violations of policy, an organization shall be given a minimum (30) days to respond. Progress of record(s) correction(s) must be visible within (60) days after correspondence with ARIN began or ARIN will start proceeding with removal of DNS services and/or resources issued by ARIN. ARIN shall negotiate a longer term with the organization if ARIN believes the organization is working in good faith to substantially restore compliance and has a valid need for additional time to renumber out of the affected blocks. Rationale: To date the community has not documented or firmly established use of an effective enforcement mechanism. This policy will support current policy and compel those who are allocated ARIN resources to maintain the proper WHOIS records in accordance with ARIN NRPM. While it is recognized this is not an absolute solution to ensure compliance, it is the best method under current ARIN policies. _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. From jcurran at arin.net Sat May 28 10:47:42 2011 From: jcurran at arin.net (John Curran) Date: Sat, 28 May 2011 14:47:42 +0000 Subject: [arin-ppml] ARIN-prop-153 Correct erroneous syntax in NRPM 8.3 In-Reply-To: References: <4DDFA7A6.105@arin.net> <11189C06-3B22-491B-8A81-972250BA537D@delong.com> <9CB0235C-44EF-4FF8-A771-50DB827F0727@matthew.at> <5DF3E997-21AC-4287-B4AB-D3CE84BF5EB8@matthew.at> Message-ID: <961410C0-2A51-4F77-AC90-E84CE59FDF18@arin.net> On May 27, 2011, at 8:03 PM, Owen DeLong wrote: > On May 27, 2011, at 4:25 PM, Matthew Kaufman wrote: > >> What's "suspicious" about it? I tell ARIN "look, I need 660,000 addresses... I found someone with that many, but they're in a bunch of different blocks. Over the next few hours you'll be getting a bunch of transfer request forms with associated justification" >> >> "Here's my justification that I need 660,000 addresses... which of course also justifies the 65536 for this /16" >> >> "Here's my justification that I still need over 594k addresses... which of course is sufficient to justify the 131072 for this /15" >> >> "Here's my justification that I still need over 463k addresses... which of course is sufficient to justify the 512 for this /23" >> > > ARIN would quickly identify this as an end-run on the policy and block it, I believe. John, care to comment? We need to understand how you wish ARIN to interpret *exact amount* in the proposal language with respect to receipt of smaller blocks than actual need: "Such transferred number resources may only be received under RSA as a single aggregate, in the exact amount which they can justify under current ARIN policies by organizations that are within the ARIN region." Under the current NRPM 8.3 language, the resources transferred in total must match in exact amount the documented need. Generally, it is not hard for a party to show documented need for less space if the space available is less than desired. In such cases, if they are able to rather quickly utilize the received block, it may also be possible (depending on the policy used and their total resource utilization) that they could then apply for a subsequent transfer (per 4.1.8 no sooner than 3 months later, unless they can explain why their need has changed in an unforeseen manner) Under the ARIN-prop-153 proposed text, the same conditions apply but it is now much more likely to have transfer requests which do not match the exact amount due to the single aggregate phrase. To answer your question we would first need to know how to handle the transfer of a smaller block than the party actually qualifies for, and whether it is as a circumvention of policy. For example: a party (X), needing a /15 for 12 months growth, will get told by ARIN that they will actually only receive a /17 (because we're only providing space to meet 3 months of need). If X instead opts to get space from party (Y), who is is willing to transfer their /16 to X, does ARIN approve the transfer fully knowing that it is not an exact match but is actually less then X's documented need? Or do we tell X that they need to find a willing party Z who has two contiguous /16's available in order to meet X's *exact* need? If we do approve the /16 transfer to X, then a subsequent request for a transfer to meet their residual need is both quite likely and would not be circumvention of policy. If we reject the transfer due to being smaller than the documented need, then the "end-run" described above cannot occur. Which interpretation best matches your policy intent? Thanks! /John John Curran President and CEO ARIN From rbf+arin-ppml at panix.com Sat May 28 12:36:52 2011 From: rbf+arin-ppml at panix.com (Brett Frankenberger) Date: Sat, 28 May 2011 11:36:52 -0500 Subject: [arin-ppml] ARIN-prop-153 Correct erroneous syntax in NRPM 8.3 In-Reply-To: <5DF3E997-21AC-4287-B4AB-D3CE84BF5EB8@matthew.at> References: <4DDFA7A6.105@arin.net> <11189C06-3B22-491B-8A81-972250BA537D@delong.com> <9CB0235C-44EF-4FF8-A771-50DB827F0727@matthew.at> <5DF3E997-21AC-4287-B4AB-D3CE84BF5EB8@matthew.at> Message-ID: <20110528163651.GA1338@panix.com> On Sat, May 28, 2011 at 01:25:20AM +0200, Matthew Kaufman wrote: > > On May 28, 2011, at 1:09 AM, Owen DeLong wrote: > > > Given the time ARIN takes to evaluate and turn around a request, I don't think that's actually true. I also > > trust that staff would become suspicious and investigate such situations appropriately as well. > > What's "suspicious" about it? I tell ARIN "look, I need 660,000 > addresses... I found someone with that many, but they're in a bunch > of different blocks. Over the next few hours you'll be getting a > bunch of transfer request forms with associated justification" > > "Here's my justification that I need 660,000 addresses... which of > course also justifies the 65536 for this /16" So they transfer the /16. > "Here's my justification that I still need over 594k addresses... > which of course is sufficient to justify the 131072 for this /15" Except that need over the next 12 months is not the only criteria. Efficient utilization of all previous allocations is also a requirement. Assuming the /16 that they just got (with the first transfer) hasn't yet been actually used, this transfer would be rejected under NRPM 4.2.4.1 (unless their need is so immediate that they are able to immediately utilize 80% of that first /16). If we assume their rate of usage is constant over the one year justification period, then they need around one /16 per 1.2 months, so we'd expect it to take about a month to utilize the the first /16 to the 80% threshold and be eligible to request more space. Of course, this might not be an issue. The transfer agreement between the two parties might specify payment for all 660K addresses up front, and require the seller to then transfer them to the purchaser, one aggregate at a time, as requested by the purchaser and approved by ARIN. So the receipient just uses one aggregate to the 80% level, requests transfer of the next one, and so on. So, there's not much of a functional difference -- it's just that the unused portion of the space remains registerd to the seller until the purchaser needs to actually use it. (The only risk would perhaps be related to section 12. If all 660K addresses were immediately transferred, then any resource review would be dependent on the recipient organizations need (and presumably they'd have no trouble passing any such review, since they had just justified the addresses); but if a large part of the addresses remain with the seller for many months, then a resource review would be based on the seller's need, which might not exist. Practically speaking, at least with current practice related to resource reviews, there's not much risk, though.) If "one aggregate" really is what we want, I don't see how to get there except limiting recipients to one transfer per some period of time. -- Brett From owen at delong.com Sat May 28 15:13:53 2011 From: owen at delong.com (Owen DeLong) Date: Sat, 28 May 2011 12:13:53 -0700 Subject: [arin-ppml] ARIN-prop-153 Correct erroneous syntax in NRPM 8.3 In-Reply-To: <961410C0-2A51-4F77-AC90-E84CE59FDF18@arin.net> References: <4DDFA7A6.105@arin.net> <11189C06-3B22-491B-8A81-972250BA537D@delong.com> <9CB0235C-44EF-4FF8-A771-50DB827F0727@matthew.at> <5DF3E997-21AC-4287-B4AB-D3CE84BF5EB8@matthew.at> <961410C0-2A51-4F77-AC90-E84CE59FDF18@arin.net> Message-ID: <6CC67B69-8061-4C80-B11F-A37A2693C486@delong.com> On May 28, 2011, at 7:47 AM, John Curran wrote: > On May 27, 2011, at 8:03 PM, Owen DeLong wrote: > >> On May 27, 2011, at 4:25 PM, Matthew Kaufman wrote: >> >>> What's "suspicious" about it? I tell ARIN "look, I need 660,000 addresses... I found someone with that many, but they're in a bunch of different blocks. Over the next few hours you'll be getting a bunch of transfer request forms with associated justification" >>> >>> "Here's my justification that I need 660,000 addresses... which of course also justifies the 65536 for this /16" >>> >>> "Here's my justification that I still need over 594k addresses... which of course is sufficient to justify the 131072 for this /15" >>> >>> "Here's my justification that I still need over 463k addresses... which of course is sufficient to justify the 512 for this /23" >>> >> >> ARIN would quickly identify this as an end-run on the policy and block it, I believe. John, care to comment? > > We need to understand how you wish ARIN to interpret *exact amount* > in the proposal language with respect to receipt of smaller blocks > than actual need: > > "Such transferred number resources may only be received under RSA as > a single aggregate, in the exact amount which they can justify under > current ARIN policies by organizations that are within the ARIN region." > > Under the current NRPM 8.3 language, the resources transferred in total > must match in exact amount the documented need. Generally, it is not hard > for a party to show documented need for less space if the space available > is less than desired. In such cases, if they are able to rather quickly > utilize the received block, it may also be possible (depending on the policy > used and their total resource utilization) that they could then apply for > a subsequent transfer (per 4.1.8 no sooner than 3 months later, unless they > can explain why their need has changed in an unforeseen manner) > > Under the ARIN-prop-153 proposed text, the same conditions apply but it is > now much more likely to have transfer requests which do not match the exact > amount due to the single aggregate phrase. > > To answer your question we would first need to know how to handle the > transfer of a smaller block than the party actually qualifies for, and > whether it is as a circumvention of policy. For example: a party (X), > needing a /15 for 12 months growth, will get told by ARIN that they > will actually only receive a /17 (because we're only providing space > to meet 3 months of need). If X instead opts to get space from party > (Y), who is is willing to transfer their /16 to X, does ARIN approve > the transfer fully knowing that it is not an exact match but is actually > less then X's documented need? Or do we tell X that they need to find > a willing party Z who has two contiguous /16's available in order to > meet X's *exact* need? > The intent of the policy would be that ARIN would decline the particular transfer due to mismatch and could reiterate the need to find a /15 or blocks which can be assembled into a /15 (contiguous bit-aligned /16s would qualify, disjoint or non-bit-aligned /16s would not, but 8 contiguous bit-aligned /18s would also qualify, for example). > If we do approve the /16 transfer to X, then a subsequent request for > a transfer to meet their residual need is both quite likely and would > not be circumvention of policy. If we reject the transfer due to being > smaller than the documented need, then the "end-run" described above > cannot occur. > > Which interpretation best matches your policy intent? > Rejecting the transfer and, as I expected, said end-run would be blocked by ARIN. Would the language in 153 as written be interpreted to mean that the transfer would be rejected, or, is there further clarification of that needed? Owen From jcurran at arin.net Sat May 28 16:20:10 2011 From: jcurran at arin.net (John Curran) Date: Sat, 28 May 2011 20:20:10 +0000 Subject: [arin-ppml] ARIN-prop-153 Correct erroneous syntax in NRPM 8.3 In-Reply-To: <6CC67B69-8061-4C80-B11F-A37A2693C486@delong.com> References: <4DDFA7A6.105@arin.net> <11189C06-3B22-491B-8A81-972250BA537D@delong.com> <9CB0235C-44EF-4FF8-A771-50DB827F0727@matthew.at> <5DF3E997-21AC-4287-B4AB-D3CE84BF5EB8@matthew.at> <961410C0-2A51-4F77-AC90-E84CE59FDF18@arin.net> <6CC67B69-8061-4C80-B11F-A37A2693C486@delong.com> Message-ID: <8C1130BD-D6F7-42AC-861A-35CB4DF3E92C@arin.net> On May 28, 2011, at 3:13 PM, Owen DeLong wrote: >> To answer your question we would first need to know how to handle the >> transfer of a smaller block than the party actually qualifies for, and >> whether it is as a circumvention of policy. For example: a party (X), >> needing a /15 for 12 months growth, will get told by ARIN that they >> will actually only receive a /17 (because we're only providing space >> to meet 3 months of need). If X instead opts to get space from party >> (Y), who is is willing to transfer their /16 to X, does ARIN approve >> the transfer fully knowing that it is not an exact match but is actually >> less then X's documented need? Or do we tell X that they need to find >> a willing party Z who has two contiguous /16's available in order to >> meet X's *exact* need? >> > > The intent of the policy would be that ARIN would decline the particular > transfer due to mismatch and could reiterate the need to find a /15 > or blocks which can be assembled into a /15 (contiguous bit-aligned > /16s would qualify, disjoint or non-bit-aligned /16s would not, but > 8 contiguous bit-aligned /18s would also qualify, for example). Acknowledged. The exact match constraint will obviously make finding acceptable address space much more difficult, due to the need to find not just any available space up to the documented need, but instead require finding a party which has the exact amount of space available and as a contiguous block. >> If we do approve the /16 transfer to X, then a subsequent request for >> a transfer to meet their residual need is both quite likely and would >> not be circumvention of policy. If we reject the transfer due to being >> smaller than the documented need, then the "end-run" described above >> cannot occur. >> >> Which interpretation best matches your policy intent? >> > > Rejecting the transfer and, as I expected, said end-run would be blocked > by ARIN. Would the language in 153 as written be interpreted to > mean that the transfer would be rejected, or, is there further clarification > of that needed? As the general principles in 4.1.8 may easily be read to allow a party to request a transfer of a smaller block due to availability, and your intent is clearly to disallow such, it might be best to clarify that point when changing the syntax to require transfers in the exact amount the documented need of the recipient. Thanks, /John John Curran President and CEO ARIN From stephen at sprunk.org Sat May 28 16:46:31 2011 From: stephen at sprunk.org (Stephen Sprunk) Date: Sat, 28 May 2011 15:46:31 -0500 Subject: [arin-ppml] Draft Policy 2011-7 Compliance Requirement In-Reply-To: <011001cc1d04$53248a00$f96d9e00$@iname.com> References: <4DDC0293.4020104@arin.net> <011001cc1d04$53248a00$f96d9e00$@iname.com> Message-ID: <4DE15F27.3020301@sprunk.org> On 28-May-11 01:56, Frank Bulk wrote: > In regard to ARIN counsel's discussion about "lack of compliance" -- ARIN staff make that determination on new requests each and every day (i.e. the request meets the policies or they don't). It's not clear to me how reviewing a current resource holder's compliancy requires "black and white", or only to look at a subset of policies. To be sure, a review does not include the applicant's documentation, but that could be requested if what's readily available is insufficient to verify compliancy. NRPM 12.4 and the original version of this proposal use the expression "materially out of compliance". It is fairly easy to determine if someone is out of compliance, but how does staff (or a court, if ARIN is sued) determine whether the non-compliance is material? That was the point of 12.4(a), which this proposal would rename to 12.4.1. The authors' intent was to leave that to staff's discretion, which is known to be rather liberal. To strike the word "materially" from this policy, as the most recent revision of this proposal does, will radically alter its effect by forcing ARIN staff to do evil and/or stupid things. If the current wording is legally challenging, I would suggest that it is a better course of action to find a more defensible wording rather than to abandon the idea of letting smart people do smart things. > I agree that words "fraud" and "materially" are loaded words and that by itself requires that this proposal be re-written. Those words are in the current text, so they are not defects in this proposal per se, and editorial changes should be separate from deliberate policy changes. S -- Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3646 bytes Desc: S/MIME Cryptographic Signature URL: From owen at delong.com Sun May 29 01:20:44 2011 From: owen at delong.com (Owen DeLong) Date: Sat, 28 May 2011 22:20:44 -0700 Subject: [arin-ppml] ARIN-prop-153 Correct erroneous syntax in NRPM 8.3 In-Reply-To: <8C1130BD-D6F7-42AC-861A-35CB4DF3E92C@arin.net> References: <4DDFA7A6.105@arin.net> <11189C06-3B22-491B-8A81-972250BA537D@delong.com> <9CB0235C-44EF-4FF8-A771-50DB827F0727@matthew.at> <5DF3E997-21AC-4287-B4AB-D3CE84BF5EB8@matthew.at> <961410C0-2A51-4F77-AC90-E84CE59FDF18@arin.net> <6CC67B69-8061-4C80-B11F-A37A2693C486@delong.com> <8C1130BD-D6F7-42AC-861A-35CB4DF3E92C@arin.net> Message-ID: On May 28, 2011, at 1:20 PM, John Curran wrote: > On May 28, 2011, at 3:13 PM, Owen DeLong wrote: >>> To answer your question we would first need to know how to handle the >>> transfer of a smaller block than the party actually qualifies for, and >>> whether it is as a circumvention of policy. For example: a party (X), >>> needing a /15 for 12 months growth, will get told by ARIN that they >>> will actually only receive a /17 (because we're only providing space >>> to meet 3 months of need). If X instead opts to get space from party >>> (Y), who is is willing to transfer their /16 to X, does ARIN approve >>> the transfer fully knowing that it is not an exact match but is actually >>> less then X's documented need? Or do we tell X that they need to find >>> a willing party Z who has two contiguous /16's available in order to >>> meet X's *exact* need? >>> >> >> The intent of the policy would be that ARIN would decline the particular >> transfer due to mismatch and could reiterate the need to find a /15 >> or blocks which can be assembled into a /15 (contiguous bit-aligned >> /16s would qualify, disjoint or non-bit-aligned /16s would not, but >> 8 contiguous bit-aligned /18s would also qualify, for example). > > Acknowledged. > > The exact match constraint will obviously make finding acceptable address > space much more difficult, due to the need to find not just any available > space up to the documented need, but instead require finding a party which > has the exact amount of space available and as a contiguous block. > Exact amount or more, technically. Strangely enough, the community came to consensus around the idea of allowing someone to sell off pieces of their netblock without limitations on the fragmentation, but, each recipient is supposed to only get a single chunk. >>> If we do approve the /16 transfer to X, then a subsequent request for >>> a transfer to meet their residual need is both quite likely and would >>> not be circumvention of policy. If we reject the transfer due to being >>> smaller than the documented need, then the "end-run" described above >>> cannot occur. >>> >>> Which interpretation best matches your policy intent? >>> >> >> Rejecting the transfer and, as I expected, said end-run would be blocked >> by ARIN. Would the language in 153 as written be interpreted to >> mean that the transfer would be rejected, or, is there further clarification >> of that needed? > > As the general principles in 4.1.8 may easily be read to allow a party to > request a transfer of a smaller block due to availability, and your intent > is clearly to disallow such, it might be best to clarify that point when > changing the syntax to require transfers in the exact amount the documented > need of the recipient. > I'd appreciate it if staff can provide words that would do that. It is my reading of the language in 153 that it says exactly that. Since it sounds like staff has a different reading, I think I have made the intent clear and will instead request that staff provide language that will have the desired effect. Owen > Thanks, > /John > > John Curran > President and CEO > ARIN From owen at delong.com Sun May 29 01:26:11 2011 From: owen at delong.com (Owen DeLong) Date: Sat, 28 May 2011 22:26:11 -0700 Subject: [arin-ppml] Draft Policy 2011-7 Compliance Requirement In-Reply-To: <4DE15F27.3020301@sprunk.org> References: <4DDC0293.4020104@arin.net> <011001cc1d04$53248a00$f96d9e00$@iname.com> <4DE15F27.3020301@sprunk.org> Message-ID: <9C430E41-4973-4BA8-A360-2F72A48DF669@delong.com> On May 28, 2011, at 1:46 PM, Stephen Sprunk wrote: > On 28-May-11 01:56, Frank Bulk wrote: >> In regard to ARIN counsel's discussion about "lack of compliance" -- ARIN staff make that determination on new requests each and every day (i.e. the request meets the policies or they don't). It's not clear to me how reviewing a current resource holder's compliancy requires "black and white", or only to look at a subset of policies. To be sure, a review does not include the applicant's documentation, but that could be requested if what's readily available is insufficient to verify compliancy. > > NRPM 12.4 and the original version of this proposal use the expression > "materially out of compliance". It is fairly easy to determine if > someone is out of compliance, but how does staff (or a court, if ARIN is > sued) determine whether the non-compliance is material? That was the > point of 12.4(a), which this proposal would rename to 12.4.1. The > authors' intent was to leave that to staff's discretion, which is known > to be rather liberal. > The intent of requiring an organization to be materially out of compliance was so that an organization that was out of compliance, but, by a reasonably small amount and/or likely to grow into compliance in a relatively short period of time wouldn't have to undergo renumbering/reclamation and then submit another request in short order. > To strike the word "materially" from this policy, as the most recent > revision of this proposal does, will radically alter its effect by > forcing ARIN staff to do evil and/or stupid things. If the current > wording is legally challenging, I would suggest that it is a better > course of action to find a more defensible wording rather than to > abandon the idea of letting smart people do smart things. > Yes, this is a very bad change, IMHO. I don't believe that the word materially is a problem and Steve Ryan didn't have a problem with it in the original section 12. >> I agree that words "fraud" and "materially" are loaded words and that by itself requires that this proposal be re-written. > > Those words are in the current text, so they are not defects in this > proposal per se, and editorial changes should be separate from > deliberate policy changes. > Correct. I don't see them as particularly loaded in the way they were implemented in the original section 12 and I see no reason to shy away from them here. Owen From jcurran at arin.net Sun May 29 07:01:45 2011 From: jcurran at arin.net (John Curran) Date: Sun, 29 May 2011 11:01:45 +0000 Subject: [arin-ppml] ARIN-prop-153 Correct erroneous syntax in NRPM 8.3 In-Reply-To: References: <4DDFA7A6.105@arin.net> <11189C06-3B22-491B-8A81-972250BA537D@delong.com> <9CB0235C-44EF-4FF8-A771-50DB827F0727@matthew.at> <5DF3E997-21AC-4287-B4AB-D3CE84BF5EB8@matthew.at> <961410C0-2A51-4F77-AC90-E84CE59FDF18@arin.net> <6CC67B69-8061-4C80-B11F-A37A2693C486@delong.com> <8C1130BD-D6F7-42AC-861A-35CB4DF3E92C@arin.net> Message-ID: On May 29, 2011, at 1:20 AM, Owen DeLong wrote: >> As the general principles in 4.1.8 may easily be read to allow a party to >> request a transfer of a smaller block due to availability, and your intent >> is clearly to disallow such, it might be best to clarify that point when >> changing the syntax to require transfers in the exact amount the documented >> need of the recipient. >> > I'd appreciate it if staff can provide words that would do that. It is my > reading of the language in 153 that it says exactly that. Since it sounds > like staff has a different reading, I think I have made the intent clear > and will instead request that staff provide language that will have > the desired effect. Owen - The language in ARIN-prop-153 is clear enough, but it is not when read with the general concepts in 4.1.8 and their potential application to specified transfers under your proposal, in particular: - Does the requesting organization have the option to specify the transfer of a smaller block than their need, as long as it is equal to or larger than the applicable minimum size specified elsewhere in ARIN policy? From your response, I believe your intent is "No". This point will be readily argued by those requesting transfers (by pointing to the text in 4.1.8) unless otherwise directly addressed in your proposal. It could be as simple as adding a statement to 153 that "An organization may not receive a smaller block than their documented need." Note that we would still apply the remainder of the 4.1.8 regarding disallowing repeated requests as a means of circumvention, i.e. an organization may only receive one transfer every 3 months, but ARIN, at its sole discretion, may waive this requirement if the requester can document a change in circumstances since their last request that could not have been reasonably foreseen at the time of the original request, and which now justifies additional space. FYI, /John John Curran President and CEO ARIN From jcurran at arin.net Sun May 29 07:15:47 2011 From: jcurran at arin.net (John Curran) Date: Sun, 29 May 2011 11:15:47 +0000 Subject: [arin-ppml] Draft Policy 2011-7 Compliance Requirement In-Reply-To: <9C430E41-4973-4BA8-A360-2F72A48DF669@delong.com> References: <4DDC0293.4020104@arin.net> <011001cc1d04$53248a00$f96d9e00$@iname.com> <4DE15F27.3020301@sprunk.org> <9C430E41-4973-4BA8-A360-2F72A48DF669@delong.com> Message-ID: On May 29, 2011, at 1:26 AM, Owen DeLong wrote: > >> To strike the word "materially" from this policy, as the most recent >> revision of this proposal does, will radically alter its effect by >> forcing ARIN staff to do evil and/or stupid things. If the current >> wording is legally challenging, I would suggest that it is a better >> course of action to find a more defensible wording rather than to >> abandon the idea of letting smart people do smart things. >> > Yes, this is a very bad change, IMHO. > > I don't believe that the word materially is a problem and Steve Ryan > didn't have a problem with it in the original section 12. Agreed. There is no problem with having the word "materially" in the policy, and maintaining it in the section provides clearer guidance to ARIN staff and hence is much preferred. Thanks, /John John Curran President and CEO ARIN From rbf+arin-ppml at panix.com Sun May 29 09:01:17 2011 From: rbf+arin-ppml at panix.com (Brett Frankenberger) Date: Sun, 29 May 2011 08:01:17 -0500 Subject: [arin-ppml] ARIN-prop-153 Correct erroneous syntax in NRPM 8.3 In-Reply-To: References: <11189C06-3B22-491B-8A81-972250BA537D@delong.com> <9CB0235C-44EF-4FF8-A771-50DB827F0727@matthew.at> <5DF3E997-21AC-4287-B4AB-D3CE84BF5EB8@matthew.at> <961410C0-2A51-4F77-AC90-E84CE59FDF18@arin.net> <6CC67B69-8061-4C80-B11F-A37A2693C486@delong.com> <8C1130BD-D6F7-42AC-861A-35CB4DF3E92C@arin.net> Message-ID: <20110529130117.GA12888@panix.com> On Sun, May 29, 2011 at 11:01:45AM +0000, John Curran wrote: > > Owen - > > The language in ARIN-prop-153 is clear enough, but it is not when read with > the general concepts in 4.1.8 and their potential application to specified > transfers under your proposal, in particular: > > - Does the requesting organization have the option to specify the > transfer of a smaller block than their need, as long as it is > equal to or larger than the applicable minimum size specified > elsewhere in ARIN policy? > > From your response, I believe your intent is "No". > > This point will be readily argued by those requesting transfers (by pointing > to the text in 4.1.8) unless otherwise directly addressed in your proposal. > It could be as simple as adding a statement to 153 that "An organization may > not receive a smaller block than their documented need." > > Note that we would still apply the remainder of the 4.1.8 regarding disallowing > repeated requests as a means of circumvention, i.e. an organization may only > receive one transfer every 3 months, but ARIN, at its sole discretion, may waive > this requirement if the requester can document a change in circumstances since > their last request that could not have been reasonably foreseen at the time of > the original request, and which now justifies additional space. The "once every three months" restriction would be useful in preventing repeated transfers. I don't see that the "an organization may not receive a smaller block than their documented need" is going to have much practical effect. ARIN has not had a practice of asking organizations to demonstrate that their actual need is not actually greater than what they've attempted to justify, and I doubt ARIN would start doing that. So the effect of the "may not receive a smaller block" clause is going to be that organizations are going to find the largest block they can on the transfer market, and then go to ARIN with justification for that size (or smaller, if they can't justify the whole block), and then transfer it. Someone who can justify a /15 will have no trouble justifying a /16, and ARIN isn't likely (at least not absent specific policy) to attempt to determine that the organization could really justify a /15. So all that really changes if thay provision is added is organizations have to negotiate the transfer before going to ARIN with the justification. This obviously creates a risk that the justification will not be accepted, or that the seller will find another buyer before ARIN completes its review of the request (possible mitigated by the buyer paying a portion of the sales price to get the seller to hold it). And the buyer would have to accept the risk of successfully justifying a certain amount of space and then having the transfer fail for some reason, at which point he'd be stuck with that size and not be able to find a smaller block to transfer. Overall, that would seem to inject a lot of risk into the process, for very little gain in actual efficiency. -- Brett From jcurran at arin.net Sun May 29 09:21:41 2011 From: jcurran at arin.net (John Curran) Date: Sun, 29 May 2011 13:21:41 +0000 Subject: [arin-ppml] ARIN-prop-153 Correct erroneous syntax in NRPM 8.3 In-Reply-To: <20110529130117.GA12888@panix.com> References: <11189C06-3B22-491B-8A81-972250BA537D@delong.com> <9CB0235C-44EF-4FF8-A771-50DB827F0727@matthew.at> <5DF3E997-21AC-4287-B4AB-D3CE84BF5EB8@matthew.at> <961410C0-2A51-4F77-AC90-E84CE59FDF18@arin.net> <6CC67B69-8061-4C80-B11F-A37A2693C486@delong.com> <8C1130BD-D6F7-42AC-861A-35CB4DF3E92C@arin.net> <20110529130117.GA12888@panix.com> Message-ID: <8D833FC2-C5B7-4A18-907F-0C6AC385E020@arin.net> On May 29, 2011, at 9:01 AM, Brett Frankenberger wrote: > On Sun, May 29, 2011 at 11:01:45AM +0000, John Curran wrote: >> >> Owen - >> >> The language in ARIN-prop-153 is clear enough, but it is not when read with >> the general concepts in 4.1.8 and their potential application to specified >> transfers under your proposal, in particular: >> >> - Does the requesting organization have the option to specify the >> transfer of a smaller block than their need, as long as it is >> equal to or larger than the applicable minimum size specified >> elsewhere in ARIN policy? >> >> From your response, I believe your intent is "No". >> >> This point will be readily argued by those requesting transfers (by pointing >> to the text in 4.1.8) unless otherwise directly addressed in your proposal. >> It could be as simple as adding a statement to 153 that "An organization may >> not receive a smaller block than their documented need." >> >> Note that we would still apply the remainder of the 4.1.8 regarding disallowing >> repeated requests as a means of circumvention, i.e. an organization may only >> receive one transfer every 3 months, but ARIN, at its sole discretion, may waive >> this requirement if the requester can document a change in circumstances since >> their last request that could not have been reasonably foreseen at the time of >> the original request, and which now justifies additional space. > > The "once every three months" restriction would be useful in preventing > repeated transfers. > > I don't see that the "an organization may not receive a smaller block > than their documented need" is going to have much practical effect. > ARIN has not had a practice of asking organizations to demonstrate that > their actual need is not actually greater than what they've attempted > to justify, and I doubt ARIN would start doing that. So the effect of > the "may not receive a smaller block" clause is going to be that > organizations are going to find the largest block they can on the > transfer market, and then go to ARIN with justification for that size > (or smaller, if they can't justify the whole block), and then transfer > it. Someone who can justify a /15 will have no trouble justifying a > /16, and ARIN isn't likely (at least not absent specific policy) to > attempt to determine that the organization could really justify a /15. I agree that is the most likely outcome of such a policy proposal being adopted. > So all that really changes if thay provision is added is organizations > have to negotiate the transfer before going to ARIN with the > justification. This obviously creates a risk that the justification > will not be accepted, or that the seller will find another buyer before > ARIN completes its review of the request (possible mitigated by the > buyer paying a portion of the sales price to get the seller to hold > it). And the buyer would have to accept the risk of successfully > justifying a certain amount of space and then having the transfer fail > for some reason, at which point he'd be stuck with that size and not be > able to find a smaller block to transfer. > > Overall, that would seem to inject a lot of risk into the process, for > very little gain in actual efficiency. My goal in responding to Owen was to solely provide clear guidance as to how to insure that implementation will match his policy goal; I'll leave it to Owen to speak to the concerns and benefits of the policy proposal. Thanks! /John John Curran President and CEO ARIN From bill at herrin.us Sun May 29 09:53:39 2011 From: bill at herrin.us (William Herrin) Date: Sun, 29 May 2011 09:53:39 -0400 Subject: [arin-ppml] ARIN-prop-153 Correct erroneous syntax in NRPM 8.3 In-Reply-To: <4DDFA7A6.105@arin.net> References: <4DDFA7A6.105@arin.net> Message-ID: On Fri, May 27, 2011 at 9:31 AM, ARIN wrote: > ARIN-prop-153 Correct erroneous syntax in NRPM 8.3 > > Such transferred number resources may only be > received under RSA as a single aggregate, in the exact amount which they > can justify under current ARIN policies by organizations that are within > the ARIN region. > > Rationale: > > The above re-ordering of the > exact same words (modulo a deleted "and") should ensure proper binding > of the single-aggregate clause as originally intended. The problem is: that wasn't the original intent. The original intent was to minimize disaggregation. The language was never intended to prevent multiple whole blocks from being transferred. It got butchered by more than a single "and." If you want to get close to the original intent, try something along the lines of, "Organizations may transfer multiple address blocks but no organization shall offer nor shall any organization receive more than one address block per year where said address block is smaller than its original registered size." Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From bill at herrin.us Sun May 29 10:52:54 2011 From: bill at herrin.us (William Herrin) Date: Sun, 29 May 2011 10:52:54 -0400 Subject: [arin-ppml] ARIN-prop-153 Correct erroneous syntax in NRPM 8.3 In-Reply-To: References: <4DDFA7A6.105@arin.net> Message-ID: On Sun, May 29, 2011 at 9:53 AM, William Herrin wrote: > On Fri, May 27, 2011 at 9:31 AM, ARIN wrote: >> ARIN-prop-153 Correct erroneous syntax in NRPM 8.3 >> > The original intent was to minimize disaggregation. The language was > never intended to prevent multiple whole blocks from being > transferred. It got butchered by more than a single "and." Allow me to rephrase for clarity: the original intent was to prevent 30,000 disaggregate /24's from being split out of somebody's /8, whether to one recipient or many. It was not intended to prevent 30,000 complete ARIN registrations from being transferred from one registrant to another. Expressing that in terms of binding policy turns out to be hard. 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 Sun May 29 13:26:58 2011 From: owen at delong.com (Owen DeLong) Date: Sun, 29 May 2011 10:26:58 -0700 Subject: [arin-ppml] ARIN-prop-153 Correct erroneous syntax in NRPM 8.3 In-Reply-To: References: <4DDFA7A6.105@arin.net> <11189C06-3B22-491B-8A81-972250BA537D@delong.com> <9CB0235C-44EF-4FF8-A771-50DB827F0727@matthew.at> <5DF3E997-21AC-4287-B4AB-D3CE84BF5EB8@matthew.at> <961410C0-2A51-4F77-AC90-E84CE59FDF18@arin.net> <6CC67B69-8061-4C80-B11F-A37A2693C486@delong.com> <8C1130BD-D6F7-42AC-861A-35CB4DF3E92C@arin.net> Message-ID: <82F95F8C-C989-4014-95C9-6F908B82D63F@delong.com> On May 29, 2011, at 4:01 AM, John Curran wrote: > On May 29, 2011, at 1:20 AM, Owen DeLong wrote: > >>> As the general principles in 4.1.8 may easily be read to allow a party to >>> request a transfer of a smaller block due to availability, and your intent >>> is clearly to disallow such, it might be best to clarify that point when >>> changing the syntax to require transfers in the exact amount the documented >>> need of the recipient. >>> >> I'd appreciate it if staff can provide words that would do that. It is my >> reading of the language in 153 that it says exactly that. Since it sounds >> like staff has a different reading, I think I have made the intent clear >> and will instead request that staff provide language that will have >> the desired effect. > > Owen - > > The language in ARIN-prop-153 is clear enough, but it is not when read with > the general concepts in 4.1.8 and their potential application to specified > transfers under your proposal, in particular: > > - Does the requesting organization have the option to specify the > transfer of a smaller block than their need, as long as it is > equal to or larger than the applicable minimum size specified > elsewhere in ARIN policy? > > From your response, I believe your intent is "No". > > This point will be readily argued by those requesting transfers (by pointing > to the text in 4.1.8) unless otherwise directly addressed in your proposal. > It could be as simple as adding a statement to 153 that "An organization may > not receive a smaller block than their documented need." > I dont' necessarily want to preclude them from receiving a smaller block, but, I want to preclude them from receiving MULTIPLE smaller blocks over a short time. > Note that we would still apply the remainder of the 4.1.8 regarding disallowing > repeated requests as a means of circumvention, i.e. an organization may only > receive one transfer every 3 months, but ARIN, at its sole discretion, may waive > this requirement if the requester can document a change in circumstances since > their last request that could not have been reasonably foreseen at the time of > the original request, and which now justifies additional space. > OK, then, it probably comes about as close as possible to the intent as is. Owen > FYI, > /John > > John Curran > President and CEO > ARIN > > From owen at delong.com Sun May 29 13:39:23 2011 From: owen at delong.com (Owen DeLong) Date: Sun, 29 May 2011 10:39:23 -0700 Subject: [arin-ppml] ARIN-prop-153 Correct erroneous syntax in NRPM 8.3 In-Reply-To: References: <4DDFA7A6.105@arin.net> Message-ID: I actually do think that Bill's language might be closer to community intent. I was trying to do the minimal surgical language change, but, I would like to get feedback from the community as to which language they think is preferable. Owen On May 29, 2011, at 6:53 AM, William Herrin wrote: > On Fri, May 27, 2011 at 9:31 AM, ARIN wrote: >> ARIN-prop-153 Correct erroneous syntax in NRPM 8.3 >> >> Such transferred number resources may only be >> received under RSA as a single aggregate, in the exact amount which they >> can justify under current ARIN policies by organizations that are within >> the ARIN region. > If you want to get close to the original intent, try something along > the lines of, "Organizations may transfer multiple address blocks but > no organization shall offer nor shall any organization receive more > than one address block per year where said address block is smaller > than its original registered size." > > 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 rbf+arin-ppml at panix.com Sun May 29 15:15:06 2011 From: rbf+arin-ppml at panix.com (Brett Frankenberger) Date: Sun, 29 May 2011 14:15:06 -0500 Subject: [arin-ppml] ARIN-prop-153 Correct erroneous syntax in NRPM 8.3 In-Reply-To: References: <4DDFA7A6.105@arin.net> Message-ID: <20110529191506.GA28505@panix.com> On Sun, May 29, 2011 at 10:39:23AM -0700, Owen DeLong wrote: > I actually do think that Bill's language might be closer to community intent. > I was trying to do the minimal surgical language change, but, I would like > to get feedback from the community as to which language they think is > preferable. So an organization with a largely unused legacy /8 would be limited to one transfer per year? (Even though, after transferring one /16, they would be able to, for example, transfer another /16 (i.e. the /16 adjacent to the one they first transferred) without causing any further deaggregation?) > On May 29, 2011, at 6:53 AM, William Herrin wrote: > > > If you want to get close to the original intent, try something along > > the lines of, "Organizations may transfer multiple address blocks but > > no organization shall offer nor shall any organization receive more > > than one address block per year where said address block is smaller > > than its original registered size." -- Brett From matthew at matthew.at Sun May 29 16:03:39 2011 From: matthew at matthew.at (Matthew Kaufman) Date: Sun, 29 May 2011 13:03:39 -0700 Subject: [arin-ppml] ARIN-prop-153 Correct erroneous syntax in NRPM 8.3 In-Reply-To: <6CC67B69-8061-4C80-B11F-A37A2693C486@delong.com> References: <4DDFA7A6.105@arin.net> <11189C06-3B22-491B-8A81-972250BA537D@delong.com> <9CB0235C-44EF-4FF8-A771-50DB827F0727@matthew.at> <5DF3E997-21AC-4287-B4AB-D3CE84BF5EB8@matthew.at> <961410C0-2A51-4F77-AC90-E84CE59FDF18@arin.net> <6CC67B69-8061-4C80-B11F-A37A2693C486@delong.com> Message-ID: <4DE2A69B.9010309@matthew.at> On 5/28/2011 12:13 PM, Owen DeLong wrote: > On May 28, 2011, at 7:47 AM, John Curran wrote: > >> To answer your question we would first need to know how to handle the >> transfer of a smaller block than the party actually qualifies for, and >> whether it is as a circumvention of policy. For example: a party (X), >> needing a /15 for 12 months growth, will get told by ARIN that they >> will actually only receive a /17 (because we're only providing space >> to meet 3 months of need). If X instead opts to get space from party >> (Y), who is is willing to transfer their /16 to X, does ARIN approve >> the transfer fully knowing that it is not an exact match but is actually >> less then X's documented need? Or do we tell X that they need to find >> a willing party Z who has two contiguous /16's available in order to >> meet X's *exact* need? >> > The intent of the policy would be that ARIN would decline the particular > transfer due to mismatch and could reiterate the need to find a /15 > or blocks which can be assembled into a /15 (contiguous bit-aligned > /16s would qualify, disjoint or non-bit-aligned /16s would not, but > 8 contiguous bit-aligned /18s would also qualify, for example). > Ok, now I absolutely, positively, oppose this policy as being as huge distorting force on any possible transfer market *and* forcing either unregistered transfers or legal action or more. Consider the following case: Organization A is in immediate need of a /19 of space in order to continue their operations through the IPv6 transition. They've gone ahead and had ARIN sign off on this need, because they don't want any delays if and when a /19 comes up in the market. But if they can't get at least one or two /24s in the next few weeks, they're going to start losing customers. But the market has been really tight the last few weeks or months, and only some /24s have been up recently... certainly no /19s. They find a seller with a /24, and decide they must act now. Do they: A) Go back to ARIN and explain how the /19 of need magically evaporated, send in paperwork to justify the /24, transfer it, knowing they'll be locked out of getting the additional space they need for some time. B) Wait for a /19 to become available C) Transfer the /24 but don't tell ARIN, so their /19 of need is still in the system A few weeks later, a /19 does become available and they can afford it. If they chose (A) above, do they: 1) Purchase the /19 but delay filing the transfer with ARIN 2) Purchase the /19 but never file the transfer with ARIN 3) Engage in a lease of the /19 and never tell ARIN 4) Sue ARIN to force recognition of both transfers 5) Simply pass up the opportunity to get the space they need If they chose (B) above, do they: 6) purchase the /19 and register the transfer with ARIN 7) not act, because not having the /24 in the meantime has cost them their business If they chose (C) above, do they: 8) Purchase the /19 and register the transfer with ARIN 9) Purchase the /19 and not register the transfer, in case they need more space in the allotted time interval? >> If we do approve the /16 transfer to X, then a subsequent request for >> a transfer to meet their residual need is both quite likely and would >> not be circumvention of policy. If we reject the transfer due to being >> smaller than the documented need, then the "end-run" described above >> cannot occur. >> >> Which interpretation best matches your policy intent? >> > Rejecting the transfer and, as I expected, said end-run would be blocked > by ARIN. Unacceptable answer to the point of being ridiculous. Clearly the "residual need" might be much much larger than the initial transfer (see the case above) Matthew Kaufman From matthew at matthew.at Sun May 29 16:09:20 2011 From: matthew at matthew.at (Matthew Kaufman) Date: Sun, 29 May 2011 13:09:20 -0700 Subject: [arin-ppml] ARIN-prop-153 Correct erroneous syntax in NRPM 8.3 In-Reply-To: <20110528163651.GA1338@panix.com> References: <4DDFA7A6.105@arin.net> <11189C06-3B22-491B-8A81-972250BA537D@delong.com> <9CB0235C-44EF-4FF8-A771-50DB827F0727@matthew.at> <5DF3E997-21AC-4287-B4AB-D3CE84BF5EB8@matthew.at> <20110528163651.GA1338@panix.com> Message-ID: <4DE2A7F0.1080004@matthew.at> On 5/28/2011 9:36 AM, Brett Frankenberger wrote: > On Sat, May 28, 2011 at 01:25:20AM +0200, Matthew Kaufman wrote: >> On May 28, 2011, at 1:09 AM, Owen DeLong wrote: >> >>> Given the time ARIN takes to evaluate and turn around a request, I don't think that's actually true. I also >>> trust that staff would become suspicious and investigate such situations appropriately as well. >> What's "suspicious" about it? I tell ARIN "look, I need 660,000 >> addresses... I found someone with that many, but they're in a bunch >> of different blocks. Over the next few hours you'll be getting a >> bunch of transfer request forms with associated justification" >> >> "Here's my justification that I need 660,000 addresses... which of >> course also justifies the 65536 for this /16" > So they transfer the /16. > >> "Here's my justification that I still need over 594k addresses... >> which of course is sufficient to justify the 131072 for this /15" > Except that need over the next 12 months is not the only criteria. > Efficient utilization of all previous allocations is also a > requirement. > > Assuming the /16 that they just got (with the first transfer) hasn't > yet been actually used, this transfer would be rejected under NRPM > 4.2.4.1 (unless their need is so immediate that they are able to > immediately utilize 80% of that first /16). Lets assume that their need is so immediate that they can immediately use 80% of the first /16. Or immediately enough... they can simply write the purchase contract to allow the transfers to be spread out over just enough time to achieve this (even the Nortel-Microsoft deal is written with subsequent transfer language) > If we assume their rate of usage is constant over the one year > justification period, then they need around one /16 per 1.2 months, so > we'd expect it to take about a month to utilize the the first /16 to > the 80% threshold and be eligible to request more space. Maybe this long, even so it doesn't matter (see above) > Of course, this might not be an issue. The transfer agreement between > the two parties might specify payment for all 660K addresses up front, > and require the seller to then transfer them to the purchaser, one > aggregate at a time, as requested by the purchaser and approved by > ARIN. Exactly. For all we know this has *already happened* for some huge amount of the address space, and we just haven't seen the transfers trickle through yet. Of course if the seller doesn't really need the space, there's not much preventing the buyer from starting to use it before the transfers are approved... which just reduces the accuracy of the whois database. > > If "one aggregate" really is what we want, I don't see how to get there > except limiting recipients to one transfer per some period of time. Right, which is unfair to a recipient who thinks they can only find /24s but then next week finds some /16s on the market that are what they really needed, only they took one of the /24s in desperation. Matthew Kaufman From matthew at matthew.at Sun May 29 16:10:28 2011 From: matthew at matthew.at (Matthew Kaufman) Date: Sun, 29 May 2011 13:10:28 -0700 Subject: [arin-ppml] ARIN-prop-153 Correct erroneous syntax in NRPM 8.3 In-Reply-To: <8C1130BD-D6F7-42AC-861A-35CB4DF3E92C@arin.net> References: <4DDFA7A6.105@arin.net> <11189C06-3B22-491B-8A81-972250BA537D@delong.com> <9CB0235C-44EF-4FF8-A771-50DB827F0727@matthew.at> <5DF3E997-21AC-4287-B4AB-D3CE84BF5EB8@matthew.at> <961410C0-2A51-4F77-AC90-E84CE59FDF18@arin.net> <6CC67B69-8061-4C80-B11F-A37A2693C486@delong.com> <8C1130BD-D6F7-42AC-861A-35CB4DF3E92C@arin.net> Message-ID: <4DE2A834.30302@matthew.at> On 5/28/2011 1:20 PM, John Curran wrote: > > The exact match constraint will obviously make finding acceptable address > space much more difficult, due to the need to find not just any available > space up to the documented need, but instead require finding a party which > has the exact amount of space available and as a contiguous block. > Agreed. I suppose if Owen's intent here is to allow transfers but break the market so badly that they can't actually happen (and hope that nobody just does them without notifying ARIN), this might succeed. Matthew Kaufman From jeffrey.lyon at blacklotus.net Sun May 29 16:12:17 2011 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Sun, 29 May 2011 16:12:17 -0400 Subject: [arin-ppml] ARIN-prop-153 Correct erroneous syntax in NRPM 8.3 In-Reply-To: <4DE2A69B.9010309@matthew.at> References: <4DDFA7A6.105@arin.net> <11189C06-3B22-491B-8A81-972250BA537D@delong.com> <9CB0235C-44EF-4FF8-A771-50DB827F0727@matthew.at> <5DF3E997-21AC-4287-B4AB-D3CE84BF5EB8@matthew.at> <961410C0-2A51-4F77-AC90-E84CE59FDF18@arin.net> <6CC67B69-8061-4C80-B11F-A37A2693C486@delong.com> <4DE2A69B.9010309@matthew.at> Message-ID: On Sun, May 29, 2011 at 4:03 PM, Matthew Kaufman wrote: > On 5/28/2011 12:13 PM, Owen DeLong wrote: >> >> On May 28, 2011, at 7:47 AM, John Curran wrote: >> >>> To answer your question we would first need to know how to handle the >>> transfer of a smaller block than the party actually qualifies for, and >>> whether it is as a circumvention of policy. ?For example: a party (X), >>> needing a /15 for 12 months growth, will get told by ARIN that they >>> will actually only receive a /17 (because we're only providing space >>> to meet 3 months of need). ?If X instead opts to get space from party >>> (Y), who is is willing to transfer their /16 to X, does ARIN approve >>> the transfer fully knowing that it is not an exact match but is actually >>> less then X's documented need? ?Or do we tell X that they need to find >>> a willing party Z who has two contiguous /16's available in order to >>> meet X's *exact* need? >>> >> The intent of the policy would be that ARIN would decline the particular >> transfer due to mismatch and could reiterate the need to find a /15 >> or blocks which can be assembled into a /15 (contiguous bit-aligned >> /16s would qualify, disjoint or non-bit-aligned /16s would not, but >> 8 contiguous bit-aligned /18s would also qualify, for example). >> > > Ok, now I absolutely, positively, oppose this policy as being as huge > distorting force on any possible transfer market *and* forcing either > unregistered transfers or legal action or more. > > Consider the following case: > > Organization A is in immediate need of a /19 of space in order to continue > their operations through the IPv6 transition. They've gone ahead and had > ARIN sign off on this need, because they don't want any delays if and when a > /19 comes up in the market. But if they can't get at least one or two /24s > in the next few weeks, they're going to start losing customers. > > But the market has been really tight the last few weeks or months, and only > some /24s have been up recently... certainly no /19s. They find a seller > with a /24, and decide they must act now. > > Do they: > A) Go back to ARIN and explain how the /19 of need magically evaporated, > send in paperwork to justify the /24, transfer it, knowing they'll be locked > out of getting the additional space they need for some time. > > B) Wait for a /19 to become available > > C) Transfer the /24 but don't tell ARIN, so their /19 of need is still in > the system > > A few weeks later, a /19 does become available and they can afford it. > > If they chose (A) above, do they: > > 1) Purchase the /19 but delay filing the transfer with ARIN > > 2) Purchase the /19 but never file the transfer with ARIN > > 3) Engage in a lease of the /19 and never tell ARIN > > 4) Sue ARIN to force recognition of both transfers > > 5) Simply pass up the opportunity to get the space they need > > If they chose (B) above, do they: > > 6) purchase the /19 and register the transfer with ARIN > > 7) not act, because not having the /24 in the meantime has cost them their > business > > If they chose (C) above, do they: > > 8) Purchase the /19 and register the transfer with ARIN > > 9) Purchase the /19 and not register the transfer, in case they need more > space in the allotted time interval? > > >>> If we do approve the /16 transfer to X, then a subsequent request for >>> a transfer to meet their residual need is both quite likely and would >>> not be circumvention of policy. ?If we reject the transfer due to being >>> smaller than the documented need, then the "end-run" described above >>> cannot occur. >>> >>> Which interpretation best matches your policy intent? >>> >> Rejecting the transfer and, as I expected, said end-run would be blocked >> by ARIN. > > > Unacceptable answer to the point of being ridiculous. Clearly the "residual > need" might be much much larger than the initial transfer (see the case > above) > > Matthew Kaufman > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > Good points all around. With that said, I oppose ARIN-prop-153. -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications - AS32421 First and Leading in DDoS Protection Solutions From matthew at matthew.at Sun May 29 16:13:38 2011 From: matthew at matthew.at (Matthew Kaufman) Date: Sun, 29 May 2011 13:13:38 -0700 Subject: [arin-ppml] ARIN-prop-153 Correct erroneous syntax in NRPM 8.3 In-Reply-To: <20110529130117.GA12888@panix.com> References: <11189C06-3B22-491B-8A81-972250BA537D@delong.com> <9CB0235C-44EF-4FF8-A771-50DB827F0727@matthew.at> <5DF3E997-21AC-4287-B4AB-D3CE84BF5EB8@matthew.at> <961410C0-2A51-4F77-AC90-E84CE59FDF18@arin.net> <6CC67B69-8061-4C80-B11F-A37A2693C486@delong.com> <8C1130BD-D6F7-42AC-861A-35CB4DF3E92C@arin.net> <20110529130117.GA12888@panix.com> Message-ID: <4DE2A8F2.9000102@matthew.at> On 5/29/2011 6:01 AM, Brett Frankenberger wrote: > > I don't see that the "an organization may not receive a smaller block > than their documented need" is going to have much practical effect. > ARIN has not had a practice of asking organizations to demonstrate that > their actual need is not actually greater than what they've attempted > to justify, and I doubt ARIN would start doing that. So the effect of > the "may not receive a smaller block" clause is going to be that > organizations are going to find the largest block they can on the > transfer market, and then go to ARIN with justification for that size > (or smaller, if they can't justify the whole block), and then transfer > it. Someone who can justify a /15 will have no trouble justifying a > /16, and ARIN isn't likely (at least not absent specific policy) to > attempt to determine that the organization could really justify a /15. I suspect that it is impossible to prove than an organization actually needs a larger block than they're requesting. This isn't like the fire code, where there's a minimum square footage per employee, after all. > So all that really changes if thay provision is added is organizations > have to negotiate the transfer before going to ARIN with the > justification. This obviously creates a risk that the justification > will not be accepted, or that the seller will find another buyer before > ARIN completes its review of the request (possible mitigated by the > buyer paying a portion of the sales price to get the seller to hold > it). And the buyer would have to accept the risk of successfully > justifying a certain amount of space and then having the transfer fail > for some reason, at which point he'd be stuck with that size and not be > able to find a smaller block to transfer. > > Overall, that would seem to inject a lot of risk into the process, for > very little gain in actual efficiency. Agree, and you also missed "creates a risk that the buyer will purchase the biggest block they can find, but then the next day the amount of space they *actually* needed comes on the market and they're locked out of getting it" Matthew Kaufman From rudi.daniel at gmail.com Sun May 29 16:27:46 2011 From: rudi.daniel at gmail.com (Rudolph Daniel) Date: Sun, 29 May 2011 16:27:46 -0400 Subject: [arin-ppml] ARIN-Prop 153 Message-ID: My opinion is that Bill Herrin's effort seems closer to the current ARIN policy...however I do not really support the proposal right now. rd On May 29, 2011, at 6:53 AM, William Herrin wrote: > > > On Fri, May 27, 2011 at 9:31 AM, ARIN wrote: > >> ARIN-prop-153 Correct erroneous syntax in NRPM 8.3 > >> > >> Such transferred number resources may only be > >> received under RSA as a single aggregate, in the exact amount which they > >> can justify under current ARIN policies by organizations that are within > >> the ARIN region. > > > If you want to get close to the original intent, try something along > > the lines of, "Organizations may transfer multiple address blocks but > > no organization shall offer nor shall any organization receive more > > than one address block per year where said address block is smaller > > than its original registered size." > > > > 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. > > > > ------------------------------ > > Message: 3 > Date: Sun, 29 May 2011 14:15:06 -0500 > From: Brett Frankenberger > To: Owen DeLong > Cc: arin-ppml at arin.net > Subject: Re: [arin-ppml] ARIN-prop-153 Correct erroneous syntax in > NRPM 8.3 > Message-ID: <20110529191506.GA28505 at panix.com> > Content-Type: text/plain; charset=us-ascii > > On Sun, May 29, 2011 at 10:39:23AM -0700, Owen DeLong wrote: > > I actually do think that Bill's language might be closer to community > intent. > > I was trying to do the minimal surgical language change, but, I would > like > > to get feedback from the community as to which language they think is > > preferable. > > So an organization with a largely unused legacy /8 would be limited to > one transfer per year? (Even though, after transferring one /16, they > would be able to, for example, transfer another /16 (i.e. the /16 > adjacent to the one they first transferred) without causing any further > deaggregation?) > > > On May 29, 2011, at 6:53 AM, William Herrin wrote: > > > > > If you want to get close to the original intent, try something along > > > the lines of, "Organizations may transfer multiple address blocks but > > > no organization shall offer nor shall any organization receive more > > > than one address block per year where said address block is smaller > > > than its original registered size." > > -- Brett > > > ------------------------------ > > Message: 4 > Date: Sun, 29 May 2011 13:03:39 -0700 > From: Matthew Kaufman > To: Owen DeLong > Cc: John Curran , "arin-ppml at arin.net List" > > Subject: Re: [arin-ppml] ARIN-prop-153 Correct erroneous syntax in > NRPM 8.3 > Message-ID: <4DE2A69B.9010309 at matthew.at> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > On 5/28/2011 12:13 PM, Owen DeLong wrote: > > On May 28, 2011, at 7:47 AM, John Curran wrote: > > > >> To answer your question we would first need to know how to handle the > >> transfer of a smaller block than the party actually qualifies for, and > >> whether it is as a circumvention of policy. For example: a party (X), > >> needing a /15 for 12 months growth, will get told by ARIN that they > >> will actually only receive a /17 (because we're only providing space > >> to meet 3 months of need). If X instead opts to get space from party > >> (Y), who is is willing to transfer their /16 to X, does ARIN approve > >> the transfer fully knowing that it is not an exact match but is actually > >> less then X's documented need? Or do we tell X that they need to find > >> a willing party Z who has two contiguous /16's available in order to > >> meet X's *exact* need? > >> > > The intent of the policy would be that ARIN would decline the particular > > transfer due to mismatch and could reiterate the need to find a /15 > > or blocks which can be assembled into a /15 (contiguous bit-aligned > > /16s would qualify, disjoint or non-bit-aligned /16s would not, but > > 8 contiguous bit-aligned /18s would also qualify, for example). > > > > Ok, now I absolutely, positively, oppose this policy as being as huge > distorting force on any possible transfer market *and* forcing either > unregistered transfers or legal action or more. > > Consider the following case: > > Organization A is in immediate need of a /19 of space in order to > continue their operations through the IPv6 transition. They've gone > ahead and had ARIN sign off on this need, because they don't want any > delays if and when a /19 comes up in the market. But if they can't get > at least one or two /24s in the next few weeks, they're going to start > losing customers. > > But the market has been really tight the last few weeks or months, and > only some /24s have been up recently... certainly no /19s. They find a > seller with a /24, and decide they must act now. > > Do they: > A) Go back to ARIN and explain how the /19 of need magically evaporated, > send in paperwork to justify the /24, transfer it, knowing they'll be > locked out of getting the additional space they need for some time. > > B) Wait for a /19 to become available > > C) Transfer the /24 but don't tell ARIN, so their /19 of need is still > in the system > > A few weeks later, a /19 does become available and they can afford it. > > If they chose (A) above, do they: > > 1) Purchase the /19 but delay filing the transfer with ARIN > > 2) Purchase the /19 but never file the transfer with ARIN > > 3) Engage in a lease of the /19 and never tell ARIN > > 4) Sue ARIN to force recognition of both transfers > > 5) Simply pass up the opportunity to get the space they need > > If they chose (B) above, do they: > > 6) purchase the /19 and register the transfer with ARIN > > 7) not act, because not having the /24 in the meantime has cost them > their business > > If they chose (C) above, do they: > > 8) Purchase the /19 and register the transfer with ARIN > > 9) Purchase the /19 and not register the transfer, in case they need > more space in the allotted time interval? > > > >> If we do approve the /16 transfer to X, then a subsequent request for > >> a transfer to meet their residual need is both quite likely and would > >> not be circumvention of policy. If we reject the transfer due to being > >> smaller than the documented need, then the "end-run" described above > >> cannot occur. > >> > >> Which interpretation best matches your policy intent? > >> > > Rejecting the transfer and, as I expected, said end-run would be blocked > > by ARIN. > > > Unacceptable answer to the point of being ridiculous. Clearly the > "residual need" might be much much larger than the initial transfer (see > the case above) > > Matthew Kaufman > > > ------------------------------ > > Message: 5 > Date: Sun, 29 May 2011 13:09:20 -0700 > From: Matthew Kaufman > To: Brett Frankenberger > Cc: "arin-ppml at arin.net List" > Subject: Re: [arin-ppml] ARIN-prop-153 Correct erroneous syntax in > NRPM 8.3 > Message-ID: <4DE2A7F0.1080004 at matthew.at> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > On 5/28/2011 9:36 AM, Brett Frankenberger wrote: > > On Sat, May 28, 2011 at 01:25:20AM +0200, Matthew Kaufman wrote: > >> On May 28, 2011, at 1:09 AM, Owen DeLong wrote: > >> > >>> Given the time ARIN takes to evaluate and turn around a request, I > don't think that's actually true. I also > >>> trust that staff would become suspicious and investigate such > situations appropriately as well. > >> What's "suspicious" about it? I tell ARIN "look, I need 660,000 > >> addresses... I found someone with that many, but they're in a bunch > >> of different blocks. Over the next few hours you'll be getting a > >> bunch of transfer request forms with associated justification" > >> > >> "Here's my justification that I need 660,000 addresses... which of > >> course also justifies the 65536 for this /16" > > So they transfer the /16. > > > >> "Here's my justification that I still need over 594k addresses... > >> which of course is sufficient to justify the 131072 for this /15" > > Except that need over the next 12 months is not the only criteria. > > Efficient utilization of all previous allocations is also a > > requirement. > > > > Assuming the /16 that they just got (with the first transfer) hasn't > > yet been actually used, this transfer would be rejected under NRPM > > 4.2.4.1 (unless their need is so immediate that they are able to > > immediately utilize 80% of that first /16). > > Lets assume that their need is so immediate that they can immediately > use 80% of the first /16. Or immediately enough... they can simply write > the purchase contract to allow the transfers to be spread out over just > enough time to achieve this (even the Nortel-Microsoft deal is written > with subsequent transfer language) > > > If we assume their rate of usage is constant over the one year > > justification period, then they need around one /16 per 1.2 months, so > > we'd expect it to take about a month to utilize the the first /16 to > > the 80% threshold and be eligible to request more space. > > Maybe this long, even so it doesn't matter (see above) > > > Of course, this might not be an issue. The transfer agreement between > > the two parties might specify payment for all 660K addresses up front, > > and require the seller to then transfer them to the purchaser, one > > aggregate at a time, as requested by the purchaser and approved by > > ARIN. > > Exactly. For all we know this has *already happened* for some huge > amount of the address space, and we just haven't seen the transfers > trickle through yet. > > Of course if the seller doesn't really need the space, there's not much > preventing the buyer from starting to use it before the transfers are > approved... which just reduces the accuracy of the whois database. > > > > > If "one aggregate" really is what we want, I don't see how to get there > > except limiting recipients to one transfer per some period of time. > > Right, which is unfair to a recipient who thinks they can only find /24s > but then next week finds some /16s on the market that are what they > really needed, only they took one of the /24s in desperation. > > Matthew Kaufman > > > > ------------------------------ > > Message: 6 > Date: Sun, 29 May 2011 13:10:28 -0700 > From: Matthew Kaufman > To: John Curran > Cc: "arin-ppml at arin.net List" > Subject: Re: [arin-ppml] ARIN-prop-153 Correct erroneous syntax in > NRPM 8.3 > Message-ID: <4DE2A834.30302 at matthew.at> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > On 5/28/2011 1:20 PM, John Curran wrote: > > > > The exact match constraint will obviously make finding acceptable address > > space much more difficult, due to the need to find not just any available > > space up to the documented need, but instead require finding a party > which > > has the exact amount of space available and as a contiguous block. > > > > Agreed. I suppose if Owen's intent here is to allow transfers but break > the market so badly that they can't actually happen (and hope that > nobody just does them without notifying ARIN), this might succeed. > > Matthew Kaufman > > > > ------------------------------ > > Message: 7 > Date: Sun, 29 May 2011 16:12:17 -0400 > From: Jeffrey Lyon > To: matthew at matthew.at > Cc: John Curran , "arin-ppml at arin.net List" > > Subject: Re: [arin-ppml] ARIN-prop-153 Correct erroneous syntax in > NRPM 8.3 > Message-ID: > Content-Type: text/plain; charset=ISO-8859-1 > > On Sun, May 29, 2011 at 4:03 PM, Matthew Kaufman > wrote: > > On 5/28/2011 12:13 PM, Owen DeLong wrote: > >> > >> On May 28, 2011, at 7:47 AM, John Curran wrote: > >> > >>> To answer your question we would first need to know how to handle the > >>> transfer of a smaller block than the party actually qualifies for, and > >>> whether it is as a circumvention of policy. ?For example: a party (X), > >>> needing a /15 for 12 months growth, will get told by ARIN that they > >>> will actually only receive a /17 (because we're only providing space > >>> to meet 3 months of need). ?If X instead opts to get space from party > >>> (Y), who is is willing to transfer their /16 to X, does ARIN approve > >>> the transfer fully knowing that it is not an exact match but is > actually > >>> less then X's documented need? ?Or do we tell X that they need to find > >>> a willing party Z who has two contiguous /16's available in order to > >>> meet X's *exact* need? > >>> > >> The intent of the policy would be that ARIN would decline the particular > >> transfer due to mismatch and could reiterate the need to find a /15 > >> or blocks which can be assembled into a /15 (contiguous bit-aligned > >> /16s would qualify, disjoint or non-bit-aligned /16s would not, but > >> 8 contiguous bit-aligned /18s would also qualify, for example). > >> > > > > Ok, now I absolutely, positively, oppose this policy as being as huge > > distorting force on any possible transfer market *and* forcing either > > unregistered transfers or legal action or more. > > > > Consider the following case: > > > > Organization A is in immediate need of a /19 of space in order to > continue > > their operations through the IPv6 transition. They've gone ahead and had > > ARIN sign off on this need, because they don't want any delays if and > when a > > /19 comes up in the market. But if they can't get at least one or two > /24s > > in the next few weeks, they're going to start losing customers. > > > > But the market has been really tight the last few weeks or months, and > only > > some /24s have been up recently... certainly no /19s. They find a seller > > with a /24, and decide they must act now. > > > > Do they: > > A) Go back to ARIN and explain how the /19 of need magically evaporated, > > send in paperwork to justify the /24, transfer it, knowing they'll be > locked > > out of getting the additional space they need for some time. > > > > B) Wait for a /19 to become available > > > > C) Transfer the /24 but don't tell ARIN, so their /19 of need is still in > > the system > > > > A few weeks later, a /19 does become available and they can afford it. > > > > If they chose (A) above, do they: > > > > 1) Purchase the /19 but delay filing the transfer with ARIN > > > > 2) Purchase the /19 but never file the transfer with ARIN > > > > 3) Engage in a lease of the /19 and never tell ARIN > > > > 4) Sue ARIN to force recognition of both transfers > > > > 5) Simply pass up the opportunity to get the space they need > > > > If they chose (B) above, do they: > > > > 6) purchase the /19 and register the transfer with ARIN > > > > 7) not act, because not having the /24 in the meantime has cost them > their > > business > > > > If they chose (C) above, do they: > > > > 8) Purchase the /19 and register the transfer with ARIN > > > > 9) Purchase the /19 and not register the transfer, in case they need more > > space in the allotted time interval? > > > > > >>> If we do approve the /16 transfer to X, then a subsequent request for > >>> a transfer to meet their residual need is both quite likely and would > >>> not be circumvention of policy. ?If we reject the transfer due to being > >>> smaller than the documented need, then the "end-run" described above > >>> cannot occur. > >>> > >>> Which interpretation best matches your policy intent? > >>> > >> Rejecting the transfer and, as I expected, said end-run would be blocked > >> by ARIN. > > > > > > Unacceptable answer to the point of being ridiculous. Clearly the > "residual > > need" might be much much larger than the initial transfer (see the case > > above) > > > > Matthew Kaufman > > _______________________________________________ > > PPML > > You are receiving this message because you are subscribed to > > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > > Unsubscribe or manage your mailing list subscription at: > > http://lists.arin.net/mailman/listinfo/arin-ppml > > Please contact info at arin.net if you experience any issues. > > > > Good points all around. With that said, I oppose ARIN-prop-153. > > -- > Jeffrey Lyon, Leadership Team > jeffrey.lyon at blacklotus.net | http://www.blacklotus.net > Black Lotus Communications - AS32421 > First and Leading in DDoS Protection Solutions > > > ------------------------------ > > _______________________________________________ > ARIN-PPML mailing list > ARIN-PPML at arin.net > http://lists.arin.net/mailman/listinfo/arin-ppml > > End of ARIN-PPML Digest, Vol 71, Issue 245 > ****************************************** > -- Rudi Daniel *danielcharles consulting **1-784 498 8277 * * * -------------- next part -------------- An HTML attachment was scrubbed... URL: From owen at delong.com Sun May 29 17:43:11 2011 From: owen at delong.com (Owen DeLong) Date: Sun, 29 May 2011 14:43:11 -0700 Subject: [arin-ppml] ARIN-prop-153 Correct erroneous syntax in NRPM 8.3 In-Reply-To: <20110529191506.GA28505@panix.com> References: <4DDFA7A6.105@arin.net> <20110529191506.GA28505@panix.com> Message-ID: On May 29, 2011, at 12:15 PM, Brett Frankenberger wrote: > On Sun, May 29, 2011 at 10:39:23AM -0700, Owen DeLong wrote: >> I actually do think that Bill's language might be closer to community intent. >> I was trying to do the minimal surgical language change, but, I would like >> to get feedback from the community as to which language they think is >> preferable. > > So an organization with a largely unused legacy /8 would be limited to > one transfer per year? (Even though, after transferring one /16, they > would be able to, for example, transfer another /16 (i.e. the /16 > adjacent to the one they first transferred) without causing any further > deaggregation?) > No... They would not be limited. The limitation being expressed would be on the recipients, not the supplier. So, for example, an organization that needed a /14 and wanted to get it from the organization with a largely unused legacy /8 would need to get a /14 from them, or take 4 years to transfer it in /16 sized chunks that were not contiguous. What would not be allowed would be to satisfy their need for a /14 by carving up the /18 into 4 separate /16 sized chunks (or an even larger number of even smaller chunks). Owen >> On May 29, 2011, at 6:53 AM, William Herrin wrote: >> >>> If you want to get close to the original intent, try something along >>> the lines of, "Organizations may transfer multiple address blocks but >>> no organization shall offer nor shall any organization receive more >>> than one address block per year where said address block is smaller >>> than its original registered size." > > -- Brett From matthew at matthew.at Sun May 29 18:02:34 2011 From: matthew at matthew.at (Matthew Kaufman) Date: Sun, 29 May 2011 15:02:34 -0700 Subject: [arin-ppml] ARIN-prop-153 Correct erroneous syntax in NRPM 8.3 In-Reply-To: References: <4DDFA7A6.105@arin.net> <20110529191506.GA28505@panix.com> Message-ID: <4DE2C27A.2080701@matthew.at> On 5/29/2011 2:43 PM, Owen DeLong wrote: > On May 29, 2011, at 12:15 PM, Brett Frankenberger wrote: > >> On Sun, May 29, 2011 at 10:39:23AM -0700, Owen DeLong wrote: >>> I actually do think that Bill's language might be closer to community intent. >>> I was trying to do the minimal surgical language change, but, I would like >>> to get feedback from the community as to which language they think is >>> preferable. >> So an organization with a largely unused legacy /8 would be limited to >> one transfer per year? (Even though, after transferring one /16, they >> would be able to, for example, transfer another /16 (i.e. the /16 >> adjacent to the one they first transferred) without causing any further >> deaggregation?) >> > No... They would not be limited. The limitation being expressed would > be on the recipients, not the supplier. So, for example, an organization > that needed a /14 and wanted to get it from the organization with a > largely unused legacy /8 would need to get a /14 from them, or take > 4 years to transfer it in /16 sized chunks that were not contiguous. What > would not be allowed would be to satisfy their need for a /14 by carving > up the /18 into 4 separate /16 sized chunks (or an even larger number > of even smaller chunks). I'm not sure what you're trying to do here. If the problem is dis-aggregation of blocks, why don't we propose a change that limits the dis-aggregation on the supply side? Org A getting the even-numbered /24 from a /8 and Org B getting the odd-numbered /24 from a /8 is just as bad as Org 1 - Org 65536 each getting one /24 from a /8. And in response the the situation above, is your intent that an org that needed a /14 get it as two /15s, one from each of two suppliers? Or must they take a /15 from one and then wait a year for the /15 from the other? I'm arguing strongly against the latter restriction. Matthew Kaufman From frnkblk at iname.com Sun May 29 18:24:23 2011 From: frnkblk at iname.com (Frank Bulk) Date: Sun, 29 May 2011 17:24:23 -0500 Subject: [arin-ppml] ARIN-prop-153 Correct erroneous syntax in NRPM 8.3 In-Reply-To: References: <4DDFA7A6.105@arin.net> Message-ID: <013301cc1e4f$29e820b0$7db86210$@iname.com> I support Bill's language, as I believe it supports the original intent and properly minimizes disaggregation. Yes, minimizing disaggregation will make the transfer of IPv4 addresses less "liquid" than what some might prefer, but it's not an unreasonable measure to temper routing table growth in light of the also-increasing IPv6 table growth. I believe we should allow organizations with documented need greater than what's exactly available on the market to be allowed to transfer several smaller (originally registered, non-disaggregated) blocks. For example, if an organization needs a /22 and there's only /20's and /24's out there, and if they can buy three (originally registered) /24's, let them do it. In the short term we're going to see more and more examples where filling exact need is not possible, so getting some is better than none. Owen gave an example of a where a supplier disaggregates their unused /8 into several /16 chunks. I would actually like to discourage that behavior where possible, as that increases the routing table size. Frank -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of William Herrin Sent: Sunday, May 29, 2011 8:54 AM To: arin-ppml at arin.net Subject: Re: [arin-ppml] ARIN-prop-153 Correct erroneous syntax in NRPM 8.3 On Fri, May 27, 2011 at 9:31 AM, ARIN wrote: > ARIN-prop-153 Correct erroneous syntax in NRPM 8.3 > > Such transferred number resources may only be > received under RSA as a single aggregate, in the exact amount which they > can justify under current ARIN policies by organizations that are within > the ARIN region. > > Rationale: > > The above re-ordering of the > exact same words (modulo a deleted "and") should ensure proper binding > of the single-aggregate clause as originally intended. The problem is: that wasn't the original intent. The original intent was to minimize disaggregation. The language was never intended to prevent multiple whole blocks from being transferred. It got butchered by more than a single "and." If you want to get close to the original intent, try something along the lines of, "Organizations may transfer multiple address blocks but no organization shall offer nor shall any organization receive more than one address block per year where said address block is smaller than its original registered size." 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 gary.buhrmaster at gmail.com Sun May 29 18:54:09 2011 From: gary.buhrmaster at gmail.com (Gary Buhrmaster) Date: Sun, 29 May 2011 22:54:09 +0000 Subject: [arin-ppml] ARIN-prop-153 Correct erroneous syntax in NRPM 8.3 In-Reply-To: <4DE2C27A.2080701@matthew.at> References: <4DDFA7A6.105@arin.net> <20110529191506.GA28505@panix.com> <4DE2C27A.2080701@matthew.at> Message-ID: On Sun, May 29, 2011 at 22:02, Matthew Kaufman wrote: .... > I'm not sure what you're trying to do here. If the problem is > dis-aggregation of blocks, why don't we propose a change that limits the > dis-aggregation on the supply side? I think this is one of the problems I continue to struggle with regarding the entire transfer policy. It attempts to try to accomplish many things. Among those I would include: * Ensure that any/all such transactions are properly recorded. * Allow underused numbers to be better used. * Minimize dis-aggregation * Allow $DESPERATE_CORP$ to move to the head of the number queue via the directed transfer policy by paying for that privilege (to the supplier). * Prevent $MEGA_CORP$ from buying all available numbers (perhaps one /24 at a time, infinitum). I am not entirely sure that the existing policy consensus will actually do these things well (and while I can conjecture with the best, until we get deeper into runout/transfers, my crystal ball is still cloudy). However, that all said, I think it is important that if the intent of the consensus is not being implemented (because of vague or inconsistent language), we should try to *just fix that* now (and let another policy proposal open all the discussion on what is the "right"/"best"/"different" policy). So, I support this proposal moving forward to correct the implementation to match consensus. Gary (*) However I also struggle here with the case that why should a supplier have any additional restrictions to dis-aggregate than would ARIN, if the same numbers were available to ARIN. I know I have multiple minds regarding this issue. From owen at delong.com Sun May 29 19:46:12 2011 From: owen at delong.com (Owen DeLong) Date: Sun, 29 May 2011 16:46:12 -0700 Subject: [arin-ppml] ARIN-prop-153 Correct erroneous syntax in NRPM 8.3 In-Reply-To: <4DE2C27A.2080701@matthew.at> References: <4DDFA7A6.105@arin.net> <20110529191506.GA28505@panix.com> <4DE2C27A.2080701@matthew.at> Message-ID: <3C290767-8470-4E72-B7D4-7F96EBA5E8EE@delong.com> On May 29, 2011, at 3:02 PM, Matthew Kaufman wrote: > On 5/29/2011 2:43 PM, Owen DeLong wrote: >> On May 29, 2011, at 12:15 PM, Brett Frankenberger wrote: >> >>> On Sun, May 29, 2011 at 10:39:23AM -0700, Owen DeLong wrote: >>>> I actually do think that Bill's language might be closer to community intent. >>>> I was trying to do the minimal surgical language change, but, I would like >>>> to get feedback from the community as to which language they think is >>>> preferable. >>> So an organization with a largely unused legacy /8 would be limited to >>> one transfer per year? (Even though, after transferring one /16, they >>> would be able to, for example, transfer another /16 (i.e. the /16 >>> adjacent to the one they first transferred) without causing any further >>> deaggregation?) >>> >> No... They would not be limited. The limitation being expressed would >> be on the recipients, not the supplier. So, for example, an organization >> that needed a /14 and wanted to get it from the organization with a >> largely unused legacy /8 would need to get a /14 from them, or take >> 4 years to transfer it in /16 sized chunks that were not contiguous. What >> would not be allowed would be to satisfy their need for a /14 by carving >> up the /18 into 4 separate /16 sized chunks (or an even larger number >> of even smaller chunks). > > I'm not sure what you're trying to do here. If the problem is dis-aggregation of blocks, why don't we propose a change that limits the dis-aggregation on the supply side? > > Org A getting the even-numbered /24 from a /8 and Org B getting the odd-numbered /24 from a /8 is just as bad as Org 1 - Org 65536 each getting one /24 from a /8. > Which would not be allowed by the proposed policy in either case. Neither the odd or even /24s from a /8 would be a "single aggregate". > And in response the the situation above, is your intent that an org that needed a /14 get it as two /15s, one from each of two suppliers? Or must they take a /15 from one and then wait a year for the /15 from the other? I'm arguing strongly against the latter restriction. > > Matthew Kaufman No... The intent is that an org that needed a /14 could only get it as a /14 from one supplier or if they choose to take a /15, they wait some period of time (possibly a year) before they could get a /15 from another. Owen From rbf+arin-ppml at panix.com Sun May 29 22:14:06 2011 From: rbf+arin-ppml at panix.com (Brett Frankenberger) Date: Sun, 29 May 2011 21:14:06 -0500 Subject: [arin-ppml] ARIN-prop-153 Correct erroneous syntax in NRPM 8.3 In-Reply-To: References: <4DDFA7A6.105@arin.net> <20110529191506.GA28505@panix.com> Message-ID: <20110530021405.GA22407@panix.com> On Sun, May 29, 2011 at 02:43:11PM -0700, Owen DeLong wrote: > > On May 29, 2011, at 12:15 PM, Brett Frankenberger wrote: > > > On Sun, May 29, 2011 at 10:39:23AM -0700, Owen DeLong wrote: > >> I actually do think that Bill's language might be closer to community intent. > >> I was trying to do the minimal surgical language change, but, I would like > >> to get feedback from the community as to which language they think is > >> preferable. > > > > So an organization with a largely unused legacy /8 would be limited to > > one transfer per year? (Even though, after transferring one /16, they > > would be able to, for example, transfer another /16 (i.e. the /16 > > adjacent to the one they first transferred) without causing any further > > deaggregation?) > > > No... They would not be limited. The limitation being expressed would > be on the recipients, not the supplier. So, for example, an organization > that needed a /14 and wanted to get it from the organization with a > largely unused legacy /8 would need to get a /14 from them, or take > 4 years to transfer it in /16 sized chunks that were not contiguous. What > would not be allowed would be to satisfy their need for a /14 by carving > up the /18 into 4 separate /16 sized chunks (or an even larger number > of even smaller chunks). Now I'm confused . The language below says "No organization shall offer ... more than one address block per year where said address block is smaller than its original registered size". So Organization A with a lightly used /8 offers a /16 to Organization B (which has justified it's need for a /16) and the transfer is completed. The transferred /16 is smaller than the original registered size (the /8), of course. Now Organization A wants to transfer another /16 from the same /8 to Organization C (which has justified need for a /16). That /16, of course, is smaller than the originally registered /8 from which it came. How is that transfer going to be allowed (assuming less than one year has elapsed) -- they're offering a second address block that is smaller than its originally registered size? Moreover, in subsequent posts, Matthew Kaufman asked: Org A getting the even-numbered /24 from a /8 and Org B getting the odd-numbered /24 from a /8 is just as bad as Org 1 - Org 65536 each getting one /24 from a /8. and you replied: Which would not be allowed by the proposed policy in either case. So assuming "the proposed policy" means Bill's language (which I've left below), you seem to now be saying that an Org with a legacy /8 can't carve it up into numerous blocks and transfer one block each to each of several different organizations. Right after stating, in response to me (see above) that it would not be limited. What am I missing? > > >> On May 29, 2011, at 6:53 AM, William Herrin wrote: > >> > >>> If you want to get close to the original intent, try something along > >>> the lines of, "Organizations may transfer multiple address blocks but > >>> no organization shall offer nor shall any organization receive more > >>> than one address block per year where said address block is smaller > >>> than its original registered size." -- Brett From matthew at matthew.at Sun May 29 22:36:37 2011 From: matthew at matthew.at (Matthew Kaufman) Date: Sun, 29 May 2011 19:36:37 -0700 Subject: [arin-ppml] ARIN-prop-153 Correct erroneous syntax in NRPM 8.3 In-Reply-To: <3C290767-8470-4E72-B7D4-7F96EBA5E8EE@delong.com> References: <4DDFA7A6.105@arin.net> <20110529191506.GA28505@panix.com> <4DE2C27A.2080701@matthew.at> <3C290767-8470-4E72-B7D4-7F96EBA5E8EE@delong.com> Message-ID: <4DE302B5.4070703@matthew.at> On 5/29/2011 4:46 PM, Owen DeLong wrote: > > No... The intent is that an org that needed a /14 could only get it as a /14 from one supplier or if they choose to take a /15, they wait some period > of time (possibly a year) before they could get a /15 from another. Ok, then it is confirmed that I am opposed to your proposal. If the *only* way to fulfill a /14 is to get two /15s, one from each of two suppliers, that should be allowed as long as there is demonstrated need for the /14. Matthew Kaufman From matthew at matthew.at Sun May 29 22:49:36 2011 From: matthew at matthew.at (Matthew Kaufman) Date: Sun, 29 May 2011 19:49:36 -0700 Subject: [arin-ppml] ARIN-prop-153 Correct erroneous syntax in NRPM 8.3 In-Reply-To: References: <4DDFA7A6.105@arin.net> <20110529191506.GA28505@panix.com> <4DE2C27A.2080701@matthew.at> Message-ID: <4DE305C0.9010103@matthew.at> On 5/29/2011 3:54 PM, Gary Buhrmaster wrote: > On Sun, May 29, 2011 at 22:02, Matthew Kaufman wrote: > .... >> I'm not sure what you're trying to do here. If the problem is >> dis-aggregation of blocks, why don't we propose a change that limits the >> dis-aggregation on the supply side? > I think this is one of the problems I continue to struggle with > regarding the entire transfer policy. It attempts to try to > accomplish many things. Among those I would include: > > * Ensure that any/all such transactions are properly recorded. Definitely required. > * Allow underused numbers to be better used. Good, but not absolutely mandatory. > * Minimize dis-aggregation Agreed. Somewhere on the spectrum between "no transfers that are smaller than /24" and "no transfers that are smaller than the size of the block as originally allocated by ARIN" makes sense. The former could cause a lot of table bloat, the latter makes it very hard for the /8 holders to help anyone in need. I think there's probably a good policy proposal here around "carving limits"... like "a supplier may divide their block into as many as 4 pieces on bit-aligned boundaries once per year"... perhaps adding something like like "a block originally allocated as bigger than /16 may be broken into pieces no smaller than a /16, and thence per the above" to get the /8s in circulation sooner. And then make sure that the limits follow the block so that the buyer is on the same timer. > * Allow $DESPERATE_CORP$ to move to the head of the number > queue via the directed transfer policy by paying for that privilege > (to the supplier). That's the whole point of transfer, yes. > * Prevent $MEGA_CORP$ from buying all available numbers (perhaps > one /24 at a time, infinitum). Not sure this can be prevented if they have enough money. For all we know, someone has already purchased the right of first refusal on nearly all of the space and the holders just haven't mentioned that to anyone. > I am not entirely sure that the existing policy consensus will > actually do these things well (and while I can conjecture with > the best, until we get deeper into runout/transfers, my crystal ball > is still cloudy). > > However, that all said, I think it is important that if the intent > of the consensus is not being implemented (because of vague > or inconsistent language), we should try to *just fix that* now > (and let another policy proposal open all the discussion on > what is the "right"/"best"/"different" policy). The problem is that what was added to the NRPM probably wasn't consensus *and* staff interpreted NRPM differently than some folks expected. So we can't "just fix that". > So, I support this proposal moving forward to correct the > implementation to match consensus. > Which consensus? The one from before the actual language was added? What people *thought* 8.3 meant? What we realize we want now? > > (*) However I also struggle here with the case that why should a supplier > have any additional restrictions to dis-aggregate than would ARIN, if > the same numbers were available to ARIN. I know I have multiple > minds regarding this issue. I think the point here is to try to put some known upper bounds on how fast the table might grow post-runout... noting of course that the BGP table might fragment faster than the actual whois registrations for a variety of reasons. Matthew Kaufman From owen at delong.com Sun May 29 23:46:57 2011 From: owen at delong.com (Owen DeLong) Date: Sun, 29 May 2011 20:46:57 -0700 Subject: [arin-ppml] ARIN-prop-153 Correct erroneous syntax in NRPM 8.3 In-Reply-To: <4DE302B5.4070703@matthew.at> References: <4DDFA7A6.105@arin.net> <20110529191506.GA28505@panix.com> <4DE2C27A.2080701@matthew.at> <3C290767-8470-4E72-B7D4-7F96EBA5E8EE@delong.com> <4DE302B5.4070703@matthew.at> Message-ID: On May 29, 2011, at 7:36 PM, Matthew Kaufman wrote: > On 5/29/2011 4:46 PM, Owen DeLong wrote: >> >> No... The intent is that an org that needed a /14 could only get it as a /14 from one supplier or if they choose to take a /15, they wait some period >> of time (possibly a year) before they could get a /15 from another. > > Ok, then it is confirmed that I am opposed to your proposal. > > If the *only* way to fulfill a /14 is to get two /15s, one from each of two suppliers, that should be allowed as long as there is demonstrated need for the /14. > > Matthew Kaufman We can agree to disagree. Owen From owen at delong.com Sun May 29 23:46:28 2011 From: owen at delong.com (Owen DeLong) Date: Sun, 29 May 2011 20:46:28 -0700 Subject: [arin-ppml] ARIN-prop-153 Correct erroneous syntax in NRPM 8.3 In-Reply-To: <20110530021405.GA22407@panix.com> References: <4DDFA7A6.105@arin.net> <20110529191506.GA28505@panix.com> <20110530021405.GA22407@panix.com> Message-ID: On May 29, 2011, at 7:14 PM, Brett Frankenberger wrote: > On Sun, May 29, 2011 at 02:43:11PM -0700, Owen DeLong wrote: >> >> On May 29, 2011, at 12:15 PM, Brett Frankenberger wrote: >> >>> On Sun, May 29, 2011 at 10:39:23AM -0700, Owen DeLong wrote: >>>> I actually do think that Bill's language might be closer to community intent. >>>> I was trying to do the minimal surgical language change, but, I would like >>>> to get feedback from the community as to which language they think is >>>> preferable. >>> >>> So an organization with a largely unused legacy /8 would be limited to >>> one transfer per year? (Even though, after transferring one /16, they >>> would be able to, for example, transfer another /16 (i.e. the /16 >>> adjacent to the one they first transferred) without causing any further >>> deaggregation?) >>> >> No... They would not be limited. The limitation being expressed would >> be on the recipients, not the supplier. So, for example, an organization >> that needed a /14 and wanted to get it from the organization with a >> largely unused legacy /8 would need to get a /14 from them, or take >> 4 years to transfer it in /16 sized chunks that were not contiguous. What >> would not be allowed would be to satisfy their need for a /14 by carving >> up the /18 into 4 separate /16 sized chunks (or an even larger number >> of even smaller chunks). > > Now I'm confused . The language below says "No organization shall > offer ... more than one address block per year where said address block > is smaller than its original registered size". > You are correct. I missed that in the original and would probably remove it from what I actually would include in the policy. > So Organization A with a lightly used /8 offers a /16 to Organization B > (which has justified it's need for a /16) and the transfer is > completed. The transferred /16 is smaller than the original registered > size (the /8), of course. > > Now Organization A wants to transfer another /16 from the same /8 to > Organization C (which has justified need for a /16). That /16, of > course, is smaller than the originally registered /8 from which it > came. How is that transfer going to be allowed (assuming less than one > year has elapsed) -- they're offering a second address block that is > smaller than its originally registered size? > What I would think makes more sense as policy would be: Organizations may transfer multiple address blocks but no organization shall receive more than one address block per year where said address block is smaller than its original registered size. I believe that accomplishes the intent without undue restrictions on the suppliers. > Moreover, in subsequent posts, Matthew Kaufman asked: > Org A getting the even-numbered /24 from a /8 and Org B getting the > odd-numbered /24 from a /8 is just as bad as Org 1 - Org 65536 each > getting one /24 from a /8. > and you replied: > Which would not be allowed by the proposed policy in either case. > Either case meant Bill's or my original language. > So assuming "the proposed policy" means Bill's language (which I've > left below), you seem to now be saying that an Org with a legacy /8 > can't carve it up into numerous blocks and transfer one block each to > each of several different organizations. > No, the point is that you can carve up to numerous different organizations (see modification above), but, cannot carve up into numerous different chunks to the same recipient. > Right after stating, in response to me (see above) that it would not be > limited. > > What am I missing? > You didn't miss anything. I misread Bill's language the first time through and your diligence caused me to re-examine it and propose a corrected version above. Does that seem to do what you think is right? Owen >> >>>> On May 29, 2011, at 6:53 AM, William Herrin wrote: >>>> >>>>> If you want to get close to the original intent, try something along >>>>> the lines of, "Organizations may transfer multiple address blocks but >>>>> no organization shall offer nor shall any organization receive more >>>>> than one address block per year where said address block is smaller >>>>> than its original registered size." > > -- Brett -------------- next part -------------- An HTML attachment was scrubbed... URL: From owen at delong.com Sun May 29 23:55:15 2011 From: owen at delong.com (Owen DeLong) Date: Sun, 29 May 2011 20:55:15 -0700 Subject: [arin-ppml] ARIN-prop-153 Correct erroneous syntax in NRPM 8.3 In-Reply-To: <4DE305C0.9010103@matthew.at> References: <4DDFA7A6.105@arin.net> <20110529191506.GA28505@panix.com> <4DE2C27A.2080701@matthew.at> <4DE305C0.9010103@matthew.at> Message-ID: <0E2A4718-3CF8-4983-94E0-D97C86C3D5A4@delong.com> On May 29, 2011, at 7:49 PM, Matthew Kaufman wrote: > On 5/29/2011 3:54 PM, Gary Buhrmaster wrote: >> On Sun, May 29, 2011 at 22:02, Matthew Kaufman wrote: >> .... >>> I'm not sure what you're trying to do here. If the problem is >>> dis-aggregation of blocks, why don't we propose a change that limits the >>> dis-aggregation on the supply side? >> I think this is one of the problems I continue to struggle with >> regarding the entire transfer policy. It attempts to try to >> accomplish many things. Among those I would include: >> >> * Ensure that any/all such transactions are properly recorded. > > Definitely required. > Again, I think that this requirement should not be held above the need for rational policies for address distribution. >> * Allow underused numbers to be better used. > > Good, but not absolutely mandatory. > I'd actually argue that this is more important than recording every transfer and I think that greater use of section 12 is a better way to address unauthorized or out-of-policy attempts to transfer. >> * Minimize dis-aggregation > > Agreed. Somewhere on the spectrum between "no transfers that are smaller than /24" and "no transfers that are smaller than the size of the block as originally allocated by ARIN" makes sense. The former could cause a lot of table bloat, the latter makes it very hard for the /8 holders to help anyone in need. > Yes. I think that the latest modification of Bill's language (which I just posted a few moments ago) addresses this nicely. > I think there's probably a good policy proposal here around "carving limits"... like "a supplier may divide their block into as many as 4 pieces on bit-aligned boundaries once per year"... perhaps adding something like like "a block originally allocated as bigger than /16 may be broken into pieces no smaller than a /16, and thence per the above" to get the /8s in circulation sooner. And then make sure that the limits follow the block so that the buyer is on the same timer. > The initial proposal set out to be the smallest surgical alteration necessary to bring staff behavior in line with the original intent of the policy that was already adopted. The discussion has led me to reconsider that approach. > >> * Allow $DESPERATE_CORP$ to move to the head of the number >> queue via the directed transfer policy by paying for that privilege >> (to the supplier). > > That's the whole point of transfer, yes. > Funny, I thought the whole point of transfer was to allow $ANY_CORP to get addresses from $OTHER_CORP when there was no more free pool. The ability to use excessive capital to jump to the front of the line strikes me not as a desirable outcome so much as an unfortunate and inevitable side effect. >> * Prevent $MEGA_CORP$ from buying all available numbers (perhaps >> one /24 at a time, infinitum). > > Not sure this can be prevented if they have enough money. For all we know, someone has already purchased the right of first refusal on nearly all of the space and the holders just haven't mentioned that to anyone. > I'm pretty sure that it can be prevented and that it is less likely to occur if we have policy that makes it clear that preventing it is the desired outcome which has community consensus. >> I am not entirely sure that the existing policy consensus will >> actually do these things well (and while I can conjecture with >> the best, until we get deeper into runout/transfers, my crystal ball >> is still cloudy). >> >> However, that all said, I think it is important that if the intent >> of the consensus is not being implemented (because of vague >> or inconsistent language), we should try to *just fix that* now >> (and let another policy proposal open all the discussion on >> what is the "right"/"best"/"different" policy). > > The problem is that what was added to the NRPM probably wasn't consensus *and* staff interpreted NRPM differently than some folks expected. > I'm not sure how you figure that what was added to the NRPM wasn't consensus. Yes, staff interpreted it differently than almost everyone expected. Additionally, yes, the make up of the active community has changed since that policy was adopted. However, it absolutely did have consensus in 2009. > So we can't "just fix that". > We can, but, I understand that doing so may not be the most desirable outcome. >> So, I support this proposal moving forward to correct the >> implementation to match consensus. >> > > Which consensus? The one from before the actual language was added? What people *thought* 8.3 meant? What we realize we want now? > The consensus was for the actual language, but, I am convinced that among that consensus group, the expectation of what the language meant was not the way staff interpreted it. The consensus intent was that the single aggregate would bind with the amount received, not the amount justified. > >> >> (*) However I also struggle here with the case that why should a supplier >> have any additional restrictions to dis-aggregate than would ARIN, if >> the same numbers were available to ARIN. I know I have multiple >> minds regarding this issue. > > I think the point here is to try to put some known upper bounds on how fast the table might grow post-runout... noting of course that the BGP table might fragment faster than the actual whois registrations for a variety of reasons. > Yep. Owen From matthew at matthew.at Mon May 30 00:11:28 2011 From: matthew at matthew.at (Matthew Kaufman) Date: Sun, 29 May 2011 21:11:28 -0700 Subject: [arin-ppml] ARIN-prop-153 Correct erroneous syntax in NRPM 8.3 In-Reply-To: References: <4DDFA7A6.105@arin.net> <20110529191506.GA28505@panix.com> <4DE2C27A.2080701@matthew.at> <3C290767-8470-4E72-B7D4-7F96EBA5E8EE@delong.com> <4DE302B5.4070703@matthew.at> Message-ID: <4DE318F0.8080204@matthew.at> On 5/29/2011 8:46 PM, Owen DeLong wrote: > On May 29, 2011, at 7:36 PM, Matthew Kaufman wrote: > >> On 5/29/2011 4:46 PM, Owen DeLong wrote: >>> No... The intent is that an org that needed a /14 could only get it as a /14 from one supplier or if they choose to take a /15, they wait some period >>> of time (possibly a year) before they could get a /15 from another. >> Ok, then it is confirmed that I am opposed to your proposal. >> >> If the *only* way to fulfill a /14 is to get two /15s, one from each of two suppliers, that should be allowed as long as there is demonstrated need for the /14. >> >> Matthew Kaufman > We can agree to disagree. How about instead you explain what possible benefit could accrue from disallowing an organization with demonstrated need for a /14 of space from fulfilling that from the only available supply, per my above example. Matthew Kaufman From frnkblk at iname.com Mon May 30 00:34:33 2011 From: frnkblk at iname.com (Frank Bulk) Date: Sun, 29 May 2011 23:34:33 -0500 Subject: [arin-ppml] ARIN-prop-153 Correct erroneous syntax in NRPM 8.3 In-Reply-To: References: <4DDFA7A6.105@arin.net> <20110529191506.GA28505@panix.com> <20110530021405.GA22407@panix.com> Message-ID: <013401cc1e82$dfddd260$9f997720$@iname.com> I'm confused. If an organization can demonstrate need for a /14 and they can only find a /15 in the market today, why should they have to wait a whole year if they can find another /15 just a few months later? Why should we penalize them for the fact that the supply at the time of need is low? Is it because you want someone else with demonstrable need to get that second /15? If that's the case, won't that be based on who's willing to pay top dollar for that /15? Frank From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Owen DeLong Sent: Sunday, May 29, 2011 10:46 PM To: Brett Frankenberger Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] ARIN-prop-153 Correct erroneous syntax in NRPM 8.3 What I would think makes more sense as policy would be: Organizations may transfer multiple address blocks but no organization shall receive more than one address block per year where said address block is smaller than its original registered size. -------------- next part -------------- An HTML attachment was scrubbed... URL: From frnkblk at iname.com Mon May 30 00:43:51 2011 From: frnkblk at iname.com (Frank Bulk) Date: Sun, 29 May 2011 23:43:51 -0500 Subject: [arin-ppml] Draft Policy 2011-7 Compliance Requirement In-Reply-To: <9C430E41-4973-4BA8-A360-2F72A48DF669@delong.com> References: <4DDC0293.4020104@arin.net> <011001cc1d04$53248a00$f96d9e00$@iname.com> <4DE15F27.3020301@sprunk.org> <9C430E41-4973-4BA8-A360-2F72A48DF669@delong.com> Message-ID: <013901cc1e84$2ca4dca0$85ee95e0$@iname.com> Then we just need to cognizant that we're leaving it to ARIN staff's discretion as to what is interpreted to be "materially out of compliance" and that this introduces a gray area which is much more disputable than applying the standard ARIN uses with applications. Frank -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Owen DeLong Sent: Sunday, May 29, 2011 12:26 AM To: Stephen Sprunk Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] Draft Policy 2011-7 Compliance Requirement On May 28, 2011, at 1:46 PM, Stephen Sprunk wrote: > On 28-May-11 01:56, Frank Bulk wrote: >> In regard to ARIN counsel's discussion about "lack of compliance" -- ARIN staff make that determination on new requests each and every day (i.e. the request meets the policies or they don't). It's not clear to me how reviewing a current resource holder's compliancy requires "black and white", or only to look at a subset of policies. To be sure, a review does not include the applicant's documentation, but that could be requested if what's readily available is insufficient to verify compliancy. > > NRPM 12.4 and the original version of this proposal use the expression > "materially out of compliance". It is fairly easy to determine if > someone is out of compliance, but how does staff (or a court, if ARIN is > sued) determine whether the non-compliance is material? That was the > point of 12.4(a), which this proposal would rename to 12.4.1. The > authors' intent was to leave that to staff's discretion, which is known > to be rather liberal. > The intent of requiring an organization to be materially out of compliance was so that an organization that was out of compliance, but, by a reasonably small amount and/or likely to grow into compliance in a relatively short period of time wouldn't have to undergo renumbering/reclamation and then submit another request in short order. > To strike the word "materially" from this policy, as the most recent > revision of this proposal does, will radically alter its effect by > forcing ARIN staff to do evil and/or stupid things. If the current > wording is legally challenging, I would suggest that it is a better > course of action to find a more defensible wording rather than to > abandon the idea of letting smart people do smart things. > Yes, this is a very bad change, IMHO. I don't believe that the word materially is a problem and Steve Ryan didn't have a problem with it in the original section 12. >> I agree that words "fraud" and "materially" are loaded words and that by itself requires that this proposal be re-written. > > Those words are in the current text, so they are not defects in this > proposal per se, and editorial changes should be separate from > deliberate policy changes. > Correct. I don't see them as particularly loaded in the way they were implemented in the original section 12 and I see no reason to shy away from them here. 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 rbf+arin-ppml at panix.com Mon May 30 11:42:08 2011 From: rbf+arin-ppml at panix.com (Brett Frankenberger) Date: Mon, 30 May 2011 10:42:08 -0500 Subject: [arin-ppml] ARIN-prop-153 Correct erroneous syntax in NRPM 8.3 In-Reply-To: References: <4DDFA7A6.105@arin.net> <20110529191506.GA28505@panix.com> <20110530021405.GA22407@panix.com> Message-ID: <20110530154208.GA6241@panix.com> On Sun, May 29, 2011 at 08:46:28PM -0700, Owen DeLong wrote: > > On May 29, 2011, at 7:14 PM, Brett Frankenberger wrote: > > > > Now I'm confused . The language below says "No organization shall > > offer ... more than one address block per year where said address block > > is smaller than its original registered size". > > > > You are correct. I missed that in the original and would probably remove > it from what I actually would include in the policy. > > What I would think makes more sense as policy would be: > > Organizations may transfer multiple address blocks but > no organization shall receive more than one address block > per year where said address block is smaller > than its original registered size. > > I believe that accomplishes the intent without undue restrictions on the > suppliers. So, looking at the other side, if Organization A justified a /15, they would be allowed to transfer a /16 from Org B and a /16 from Org C to get their /15, provided that at least one of the /16s had originally been assigned to Org B or Org C as a /16 (so they would be receiving only zero or one "smaller than its original registered size" blocks)? Matthew Kaufman wrote: If the *only* way to fulfill a /14 is to get two /15s, one from each of two suppliers, that should be allowed as long as there is demonstrated need for the /14. and you (Owne) responded: We can agree to disagree. Based on your proposed language above, I assume that the disagreement is only over the case where both of the /15s are deaggregates of a larger original assignment. If one of the /15s is what was originally allocated by ARIN, then it would be allowed? > You didn't miss anything. I misread Bill's language the first time through > and your diligence caused me to re-examine it and propose a corrected > version above. Does that seem to do what you think is right? See my question above. Also, if we have the above restriction (can only receive one deaggregate per year), then perhaps we don't need the existing one transfer per three months limit. John has indicated that ARIN will interpret the NRPM provision restricting a provider to one allocation from ARIN every three months (except in exceptional cases) as also restricting a provider to one receipt of address space via transfer every three months. So if we have the single aggregate clause, the three month rule, and the proposed "one deaggregation per year" clause, then we have a situation where an organization that needs a /15 and finds two /16s available, can transfer one of them immediately, and can transfer the second one (a) three months later, if one or both of the /16s are blocks that were originally allocated as /16s, or (b) 12 months later, if both the /16s are part of larger allocations. I don't think there would be any reason to not allow, if one or both of the /16s were originally allocated as /16s, both transfers to complete initially. (Or, if one is located and transferred, and the second one is then located one months later, to allow that transfer to occur immediately -- so we don't need the three month rule with transfers, either.) The point of a "single aggregate" clause and/or a one transfer per three months clause would seem to be to prevent deaggregation. If we instead attain that goal more directly, with a "one deaggregation per recipient year" policy, then the other requirements are no longer needed. Going forward, there may also be a need to think more about the definition of "original registered block size". Today, we are in the early stages of this game, and second order transfers (i.e. 8.3 transfers of space that has already been transferred under 8.3) are rare or nonexistant. But a few years down the road, that might not be the case. Under the "original registered size" rule above, three years from now, an organization needing a /15 would be able to tranfer two /16s from two different holders of blocks originally assigned by ARIN as /16s. But such an organization wuld not be able to transfer two /16s from two different holders of /16s where those /16s were transferred to those holders as /16s, but which /16s were originally part of a larger allocation from ARIN. I'm not sure that's a meaningful distinction. Once space is deaggregated, it's not likely to ever be reaggregated. So it doesn't make a lot of sense to distinguish between a /16 originally provided as a /16, and a /16 originally provided as part of a /14, but which /16 was deaggregated and transferred years prior. Either way, it's a /16 that isn't likely to ever be reaggregated, so there's no deaggregation resulting from moving it around. Of course, if we seek to fix that, we need to do it in a way that doesn't encourage two-step transfers just to get around the rule. Perhaps allow a deaggregate to count as an "originally registered block" one year (or some other period) after it's transferred as a deaggregate. All this seems complicated, but necessarily so, I think, due to the competing objectives and the strong incentive to seek loopholes that will exist once ARIN runs out of space. As far as doing what I think is right, I have previosuly commented that a limit on transfers per unit time was the only realistic way to prevent massive deaggregation, but I now think a limit on deaggregations (such as you propose above) to a single entity per unit time might be a better approach to that goal. But I'm not certain. (One clear effect of the policy is to place a higher value on blocks offered for transfer that were originally registered in the size being transferred. An organization would pay more for a block that wouldn't use up their one deaggregate for this year than for a block that would use up their one deaggregate for the year and restrict them to transferring onyl whole blocks for the next year. That's probably good, but it's not clear ...) -- Brett From frnkblk at iname.com Mon May 30 12:30:46 2011 From: frnkblk at iname.com (Frank Bulk) Date: Mon, 30 May 2011 11:30:46 -0500 Subject: [arin-ppml] ARIN-prop-153 Correct erroneous syntax in NRPM 8.3 In-Reply-To: <20110530154208.GA6241@panix.com> References: <4DDFA7A6.105@arin.net> <20110529191506.GA28505@panix.com> <20110530021405.GA22407@panix.com> <20110530154208.GA6241@panix.com> Message-ID: <014901cc1ee6$edf79980$c9e6cc80$@iname.com> Brett: You've have captured an approach that I think will serve all parties quite well. It doesn't make the IPv4 transfer market as liquid as some might like it to be, but disaggregation needs to be kept in mind. By limiting it to so many units over time, the expansion of the routing table will occur more slowly, giving time for operators to upgrade and replace their gear or optimize their routing tables as necessary. As some others have commented on NANOG some time ago, as IPv4 becomes less important it's possible that there will be higher levels of route summarization and greater use of default routes. If we had had a monetize the expansion of the routing table then disaggregation would be taken care of automatically, but that hasn't happened, so RIR policies need to take that into consideration. Frank -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Brett Frankenberger Sent: Monday, May 30, 2011 10:42 AM To: Owen DeLong Cc: Brett Frankenberger; arin-ppml at arin.net Subject: Re: [arin-ppml] ARIN-prop-153 Correct erroneous syntax in NRPM 8.3 On Sun, May 29, 2011 at 08:46:28PM -0700, Owen DeLong wrote: > > On May 29, 2011, at 7:14 PM, Brett Frankenberger wrote: > > > > Now I'm confused . The language below says "No organization shall > > offer ... more than one address block per year where said address block > > is smaller than its original registered size". > > > > You are correct. I missed that in the original and would probably remove > it from what I actually would include in the policy. > > What I would think makes more sense as policy would be: > > Organizations may transfer multiple address blocks but > no organization shall receive more than one address block > per year where said address block is smaller > than its original registered size. > > I believe that accomplishes the intent without undue restrictions on the > suppliers. So, looking at the other side, if Organization A justified a /15, they would be allowed to transfer a /16 from Org B and a /16 from Org C to get their /15, provided that at least one of the /16s had originally been assigned to Org B or Org C as a /16 (so they would be receiving only zero or one "smaller than its original registered size" blocks)? Matthew Kaufman wrote: If the *only* way to fulfill a /14 is to get two /15s, one from each of two suppliers, that should be allowed as long as there is demonstrated need for the /14. and you (Owne) responded: We can agree to disagree. Based on your proposed language above, I assume that the disagreement is only over the case where both of the /15s are deaggregates of a larger original assignment. If one of the /15s is what was originally allocated by ARIN, then it would be allowed? > You didn't miss anything. I misread Bill's language the first time through > and your diligence caused me to re-examine it and propose a corrected > version above. Does that seem to do what you think is right? See my question above. Also, if we have the above restriction (can only receive one deaggregate per year), then perhaps we don't need the existing one transfer per three months limit. John has indicated that ARIN will interpret the NRPM provision restricting a provider to one allocation from ARIN every three months (except in exceptional cases) as also restricting a provider to one receipt of address space via transfer every three months. So if we have the single aggregate clause, the three month rule, and the proposed "one deaggregation per year" clause, then we have a situation where an organization that needs a /15 and finds two /16s available, can transfer one of them immediately, and can transfer the second one (a) three months later, if one or both of the /16s are blocks that were originally allocated as /16s, or (b) 12 months later, if both the /16s are part of larger allocations. I don't think there would be any reason to not allow, if one or both of the /16s were originally allocated as /16s, both transfers to complete initially. (Or, if one is located and transferred, and the second one is then located one months later, to allow that transfer to occur immediately -- so we don't need the three month rule with transfers, either.) The point of a "single aggregate" clause and/or a one transfer per three months clause would seem to be to prevent deaggregation. If we instead attain that goal more directly, with a "one deaggregation per recipient year" policy, then the other requirements are no longer needed. Going forward, there may also be a need to think more about the definition of "original registered block size". Today, we are in the early stages of this game, and second order transfers (i.e. 8.3 transfers of space that has already been transferred under 8.3) are rare or nonexistant. But a few years down the road, that might not be the case. Under the "original registered size" rule above, three years from now, an organization needing a /15 would be able to tranfer two /16s from two different holders of blocks originally assigned by ARIN as /16s. But such an organization wuld not be able to transfer two /16s from two different holders of /16s where those /16s were transferred to those holders as /16s, but which /16s were originally part of a larger allocation from ARIN. I'm not sure that's a meaningful distinction. Once space is deaggregated, it's not likely to ever be reaggregated. So it doesn't make a lot of sense to distinguish between a /16 originally provided as a /16, and a /16 originally provided as part of a /14, but which /16 was deaggregated and transferred years prior. Either way, it's a /16 that isn't likely to ever be reaggregated, so there's no deaggregation resulting from moving it around. Of course, if we seek to fix that, we need to do it in a way that doesn't encourage two-step transfers just to get around the rule. Perhaps allow a deaggregate to count as an "originally registered block" one year (or some other period) after it's transferred as a deaggregate. All this seems complicated, but necessarily so, I think, due to the competing objectives and the strong incentive to seek loopholes that will exist once ARIN runs out of space. As far as doing what I think is right, I have previosuly commented that a limit on transfers per unit time was the only realistic way to prevent massive deaggregation, but I now think a limit on deaggregations (such as you propose above) to a single entity per unit time might be a better approach to that goal. But I'm not certain. (One clear effect of the policy is to place a higher value on blocks offered for transfer that were originally registered in the size being transferred. An organization would pay more for a block that wouldn't use up their one deaggregate for this year than for a block that would use up their one deaggregate for the year and restrict them to transferring onyl whole blocks for the next year. That's probably good, but it's not clear ...) -- Brett _______________________________________________ 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 30 12:28:11 2011 From: owen at delong.com (Owen DeLong) Date: Mon, 30 May 2011 09:28:11 -0700 Subject: [arin-ppml] ARIN-prop-153 Correct erroneous syntax in NRPM 8.3 In-Reply-To: <013401cc1e82$dfddd260$9f997720$@iname.com> References: <4DDFA7A6.105@arin.net> <20110529191506.GA28505@panix.com> <20110530021405.GA22407@panix.com> <013401cc1e82$dfddd260$9f997720$@iname.com> Message-ID: <8F6F6B58-2A61-480A-B5FC-B3B97EA11809@delong.com> If they can find two /15s that started out as /15s, then there's no problem. The issue comes if they, for example, find someone with a /8 and want to get two disparate /15s from within that /8. The intent here is to require the /8 holder to renumber enough to make a contiguous /14 available rather than transferring two disparate /15s and disaggregating them. Owen On May 29, 2011, at 9:34 PM, Frank Bulk wrote: > I?m confused. If an organization can demonstrate need for a /14 and they can only find a /15 in the market today, why should they have to wait a whole year if they can find another /15 just a few months later? Why should we penalize them for the fact that the supply at the time of need is low? Is it because you want someone else with demonstrable need to get that second /15? If that?s the case, won?t that be based on who?s willing to pay top dollar for that /15? > > Frank > > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Owen DeLong > Sent: Sunday, May 29, 2011 10:46 PM > To: Brett Frankenberger > Cc: arin-ppml at arin.net > Subject: Re: [arin-ppml] ARIN-prop-153 Correct erroneous syntax in NRPM 8.3 > > > > What I would think makes more sense as policy would be: > > Organizations may transfer multiple address blocks but > no organization shall receive more than one address block > per year where said address block is smaller > than its original registered size. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From owen at delong.com Mon May 30 12:46:29 2011 From: owen at delong.com (Owen DeLong) Date: Mon, 30 May 2011 09:46:29 -0700 Subject: [arin-ppml] ARIN-prop-153 Correct erroneous syntax in NRPM 8.3 In-Reply-To: <20110530154208.GA6241@panix.com> References: <4DDFA7A6.105@arin.net> <20110529191506.GA28505@panix.com> <20110530021405.GA22407@panix.com> <20110530154208.GA6241@panix.com> Message-ID: <538C4066-EDEE-4D8F-A560-46616F61292A@delong.com> On May 30, 2011, at 8:42 AM, Brett Frankenberger wrote: > On Sun, May 29, 2011 at 08:46:28PM -0700, Owen DeLong wrote: >> >> On May 29, 2011, at 7:14 PM, Brett Frankenberger wrote: >>> >>> Now I'm confused . The language below says "No organization shall >>> offer ... more than one address block per year where said address block >>> is smaller than its original registered size". >>> >> >> You are correct. I missed that in the original and would probably remove >> it from what I actually would include in the policy. >> >> What I would think makes more sense as policy would be: >> >> Organizations may transfer multiple address blocks but >> no organization shall receive more than one address block >> per year where said address block is smaller >> than its original registered size. >> >> I believe that accomplishes the intent without undue restrictions on the >> suppliers. > > So, looking at the other side, if Organization A justified a /15, they > would be allowed to transfer a /16 from Org B and a /16 from Org C to > get their /15, provided that at least one of the /16s had originally > been assigned to Org B or Org C as a /16 (so they would be receiving > only zero or one "smaller than its original registered size" blocks)? > Correct. > Matthew Kaufman wrote: > If the *only* way to fulfill a /14 is to get two /15s, one from each > of two suppliers, that should be allowed as long as there is > demonstrated need for the /14. > and you (Owne) responded: > We can agree to disagree. > > Based on your proposed language above, I assume that the disagreement > is only over the case where both of the /15s are deaggregates of a > larger original assignment. If one of the /15s is what was originally > allocated by ARIN, then it would be allowed? > Correct. >> You didn't miss anything. I misread Bill's language the first time through >> and your diligence caused me to re-examine it and propose a corrected >> version above. Does that seem to do what you think is right? > > See my question above. > > Also, if we have the above restriction (can only receive one > deaggregate per year), then perhaps we don't need the existing one > transfer per three months limit. John has indicated that ARIN will > interpret the NRPM provision restricting a provider to one allocation > from ARIN every three months (except in exceptional cases) as also > restricting a provider to one receipt of address space via transfer > every three months. So if we have the single aggregate clause, the > three month rule, and the proposed "one deaggregation per year" clause, > then we have a situation where an organization that needs a /15 and > finds two /16s available, can transfer one of them immediately, and can > transfer the second one (a) three months later, if one or both of the > /16s are blocks that were originally allocated as /16s, or (b) 12 > months later, if both the /16s are part of larger allocations. > The one deaggregation per year clause would be in lieu of the single aggregate clause. I believe that the proposed language would allow both transfers to be treated as a single request under 4.1.8 since the single aggregate clause would be removed. > I don't think there would be any reason to not allow, if one or both of > the /16s were originally allocated as /16s, both transfers to complete > initially. (Or, if one is located and transferred, and the second one > is then located one months later, to allow that transfer to occur > immediately -- so we don't need the three month rule with transfers, > either.) The point of a "single aggregate" clause and/or a one transfer > per three months clause would seem to be to prevent deaggregation. If > we instead attain that goal more directly, with a "one deaggregation > per recipient year" policy, then the other requirements are no longer > needed. > Agreed. Hence the removal of the single aggregate clause. > Going forward, there may also be a need to think more about the > definition of "original registered block size". Today, we are in the > early stages of this game, and second order transfers (i.e. 8.3 > transfers of space that has already been transferred under 8.3) are > rare or nonexistant. But a few years down the road, that might not be > the case. I think this is less of an issue and I don't expect transfers to be a long- lasting or permanent solution. The transition to IPv6 will most likely prevent this from becoming significant. If that's not the case, there is certainly time to address it through future policy. > > Under the "original registered size" rule above, three years from now, > an organization needing a /15 would be able to tranfer two /16s from > two different holders of blocks originally assigned by ARIN as /16s. > But such an organization wuld not be able to transfer two /16s from > two different holders of /16s where those /16s were transferred to > those holders as /16s, but which /16s were originally part of a larger > allocation from ARIN. I'm not sure that's a meaningful distinction. > Once space is deaggregated, it's not likely to ever be reaggregated. > So it doesn't make a lot of sense to distinguish between a /16 > originally provided as a /16, and a /16 originally provided as part of > a /14, but which /16 was deaggregated and transferred years prior. > Either way, it's a /16 that isn't likely to ever be reaggregated, so > there's no deaggregation resulting from moving it around. > > Of course, if we seek to fix that, we need to do it in a way that > doesn't encourage two-step transfers just to get around the rule. > Perhaps allow a deaggregate to count as an "originally registered > block" one year (or some other period) after it's transferred as a > deaggregate. > I think we can skip this complication for now and address it later if it becomes a factor. Owen From stephen at sprunk.org Mon May 30 14:13:25 2011 From: stephen at sprunk.org (Stephen Sprunk) Date: Mon, 30 May 2011 13:13:25 -0500 Subject: [arin-ppml] Draft Policy 2011-7 Compliance Requirement In-Reply-To: References: <4DDC0293.4020104@arin.net> <011001cc1d04$53248a00$f96d9e00$@iname.com> <4DE15F27.3020301@sprunk.org> <9C430E41-4973-4BA8-A360-2F72A48DF669@delong.com> Message-ID: <4DE3DE45.60101@sprunk.org> On 29-May-11 06:15, John Curran wrote: > On May 29, 2011, at 1:26 AM, Owen DeLong wrote: >>> To strike the word "materially" from this policy, as the most recent revision of this proposal does, will radically alter its effect by forcing ARIN staff to do evil and/or stupid things. If the current wording is legally challenging, I would suggest that it is a better course of action to find a more defensible wording rather than to abandon the idea of letting smart people do smart things. >> Yes, this is a very bad change, IMHO. >> >> I don't believe that the word materially is a problem and Steve Ryan didn't have a problem with it in the original section 12. > Agreed. There is no problem with having the word "materially" in the policy, and maintaining it in the section provides clearer guidance to ARIN staff and hence is much preferred. Counsel's assessment of the original version of 2011-7 said this: "For example, the first line of the policy at 12.4 uses ?materiality? as a standard. I strongly recommend against such a standard, as anyone who is treated adversely will argue their ?noncompliance? is ?not material.? If lack of compliance is the issue, it must be ?black or white? as a review matter to protect against such drafting problems." That leads me to think there is indeed a problem with the word "materially", which I assume is what led to the word being struck from the latest revision of 2011-7. S -- Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3646 bytes Desc: S/MIME Cryptographic Signature URL: From jcurran at arin.net Mon May 30 17:15:57 2011 From: jcurran at arin.net (John Curran) Date: Mon, 30 May 2011 21:15:57 +0000 Subject: [arin-ppml] Draft Policy 2011-7 Compliance Requirement In-Reply-To: <4DE3DE45.60101@sprunk.org> References: <4DDC0293.4020104@arin.net> <011001cc1d04$53248a00$f96d9e00$@iname.com> <4DE15F27.3020301@sprunk.org> <9C430E41-4973-4BA8-A360-2F72A48DF669@delong.com> <4DE3DE45.60101@sprunk.org> Message-ID: On May 30, 2011, at 2:13 PM, Stephen Sprunk wrote: > On 29-May-11 06:15, John Curran wrote: >> On May 29, 2011, at 1:26 AM, Owen DeLong wrote: >>>> To strike the word "materially" from this policy, as the most recent revision of this proposal does, will radically alter its effect by forcing ARIN staff to do evil and/or stupid things. If the current wording is legally challenging, I would suggest that it is a better course of action to find a more defensible wording rather than to abandon the idea of letting smart people do smart things. >>> Yes, this is a very bad change, IMHO. >>> >>> I don't believe that the word materially is a problem and Steve Ryan didn't have a problem with it in the original section 12. >> Agreed. There is no problem with having the word "materially" in the policy, and maintaining it in the section provides clearer guidance to ARIN staff and hence is much preferred. > > Counsel's assessment of the original version of 2011-7 said this: > > "For example, the first line of the policy at 12.4 uses ?materiality? as > a standard. I strongly recommend against such a standard, as anyone who > is treated adversely will argue their ?noncompliance? is ?not material.? > If lack of compliance is the issue, it must be ?black or white? as a > review matter to protect against such drafting problems." > > That leads me to think there is indeed a problem with the word > "materially", which I assume is what led to the word being struck from > the latest revision of 2011-7. Excellent point. I will review with Counsel and produce a definitive overall recommendation regarding use of this term in the proposal. Thanks! /John John Curran President and CEO ARIN From frnkblk at iname.com Mon May 30 22:16:11 2011 From: frnkblk at iname.com (Frank Bulk) Date: Mon, 30 May 2011 21:16:11 -0500 Subject: [arin-ppml] ARIN-prop-153 Correct erroneous syntax in NRPM 8.3 In-Reply-To: <8F6F6B58-2A61-480A-B5FC-B3B97EA11809@delong.com> References: <4DDFA7A6.105@arin.net> <20110529191506.GA28505@panix.com> <20110530021405.GA22407@panix.com> <013401cc1e82$dfddd260$9f997720$@iname.com> <8F6F6B58-2A61-480A-B5FC-B3B97EA11809@delong.com> Message-ID: <014c01cc1f38$b5a28b60$20e7a220$@iname.com> That's a good goal, but how does this policy manage disaggregation where a larger block owner has the opportunity to sell to different buyers? For example, the owner of a /8 that has an unused /10 could sell /12's to four different buyers. On one hand there's a desire to minimize disaggregation, on the other hand if there's unused space that others with a validated need could use, why not. Frank From: Owen DeLong [mailto:owen at delong.com] Sent: Monday, May 30, 2011 11:28 AM To: frnkblk at iname.com Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] ARIN-prop-153 Correct erroneous syntax in NRPM 8.3 If they can find two /15s that started out as /15s, then there's no problem. The issue comes if they, for example, find someone with a /8 and want to get two disparate /15s from within that /8. The intent here is to require the /8 holder to renumber enough to make a contiguous /14 available rather than transferring two disparate /15s and disaggregating them. Owen On May 29, 2011, at 9:34 PM, Frank Bulk wrote: I'm confused. If an organization can demonstrate need for a /14 and they can only find a /15 in the market today, why should they have to wait a whole year if they can find another /15 just a few months later? Why should we penalize them for the fact that the supply at the time of need is low? Is it because you want someone else with demonstrable need to get that second /15? If that's the case, won't that be based on who's willing to pay top dollar for that /15? Frank From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Owen DeLong Sent: Sunday, May 29, 2011 10:46 PM To: Brett Frankenberger Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] ARIN-prop-153 Correct erroneous syntax in NRPM 8.3 What I would think makes more sense as policy would be: Organizations may transfer multiple address blocks but no organization shall receive more than one address block per year where said address block is smaller than its original registered size. -------------- next part -------------- An HTML attachment was scrubbed... URL: From scottleibrand at gmail.com Tue May 31 01:26:47 2011 From: scottleibrand at gmail.com (Scott Leibrand) Date: Mon, 30 May 2011 22:26:47 -0700 Subject: [arin-ppml] ARIN-prop-153 Correct erroneous syntax in NRPM 8.3 In-Reply-To: <014c01cc1f38$b5a28b60$20e7a220$@iname.com> References: <4DDFA7A6.105@arin.net> <20110529191506.GA28505@panix.com> <20110530021405.GA22407@panix.com> <013401cc1e82$dfddd260$9f997720$@iname.com> <8F6F6B58-2A61-480A-B5FC-B3B97EA11809@delong.com> <014c01cc1f38$b5a28b60$20e7a220$@iname.com> Message-ID: <-4833767692051125933@unknownmsgid> ARIN deaggregates /8s into /22s and /20s today, so that's not really much different. It seems that any restriction needs to be on the recipient getting a bunch of deaggregates, not on a large block holder transferring to lots of smaller recipients. Scott On May 30, 2011, at 7:16 PM, "Frank Bulk" wrote: That?s a good goal, but how does this policy manage disaggregation where a larger block owner has the opportunity to sell to different buyers? For example, the owner of a /8 that has an unused /10 could sell /12?s to four different buyers. On one hand there?s a desire to minimize disaggregation, on the other hand if there?s unused space that others with a validated need could use, why not. Frank *From:* Owen DeLong [mailto:owen at delong.com] *Sent:* Monday, May 30, 2011 11:28 AM *To:* frnkblk at iname.com *Cc:* arin-ppml at arin.net *Subject:* Re: [arin-ppml] ARIN-prop-153 Correct erroneous syntax in NRPM 8.3 If they can find two /15s that started out as /15s, then there's no problem. The issue comes if they, for example, find someone with a /8 and want to get two disparate /15s from within that /8. The intent here is to require the /8 holder to renumber enough to make a contiguous /14 available rather than transferring two disparate /15s and disaggregating them. Owen On May 29, 2011, at 9:34 PM, Frank Bulk wrote: I?m confused. If an organization can demonstrate need for a /14 and they can only find a /15 in the market today, why should they have to wait a whole year if they can find another /15 just a few months later? Why should we penalize them for the fact that the supply at the time of need is low? Is it because you want someone else with demonstrable need to get that second /15? If that?s the case, won?t that be based on who?s willing to pay top dollar for that /15? Frank *From:* arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] *On Behalf Of *Owen DeLong *Sent:* Sunday, May 29, 2011 10:46 PM *To:* Brett Frankenberger *Cc:* arin-ppml at arin.net *Subject:* Re: [arin-ppml] ARIN-prop-153 Correct erroneous syntax in NRPM 8.3 What I would think makes more sense as policy would be: Organizations may transfer multiple address blocks but no organization shall receive more than one address block per year where said address block is smaller than its original registered size. _______________________________________________ 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 Tue May 31 03:11:07 2011 From: owen at delong.com (Owen DeLong) Date: Tue, 31 May 2011 00:11:07 -0700 Subject: [arin-ppml] ARIN-prop-153 Correct erroneous syntax in NRPM 8.3 In-Reply-To: <014c01cc1f38$b5a28b60$20e7a220$@iname.com> References: <4DDFA7A6.105@arin.net> <20110529191506.GA28505@panix.com> <20110530021405.GA22407@panix.com> <013401cc1e82$dfddd260$9f997720$@iname.com> <8F6F6B58-2A61-480A-B5FC-B3B97EA11809@delong.com> <014c01cc1f38$b5a28b60$20e7a220$@iname.com> Message-ID: I think we kind of have to accept that circumstance because it has little differentiation from when ARIN subdivides address space the same way. Owen On May 30, 2011, at 7:16 PM, Frank Bulk wrote: > That?s a good goal, but how does this policy manage disaggregation where a larger block owner has the opportunity to sell to different buyers? For example, the owner of a /8 that has an unused /10 could sell /12?s to four different buyers. On one hand there?s a desire to minimize disaggregation, on the other hand if there?s unused space that others with a validated need could use, why not. > > Frank > > From: Owen DeLong [mailto:owen at delong.com] > Sent: Monday, May 30, 2011 11:28 AM > To: frnkblk at iname.com > Cc: arin-ppml at arin.net > Subject: Re: [arin-ppml] ARIN-prop-153 Correct erroneous syntax in NRPM 8.3 > > If they can find two /15s that started out as /15s, then there's no problem. The issue comes if they, for example, > find someone with a /8 and want to get two disparate /15s from within that /8. The intent here is to require > the /8 holder to renumber enough to make a contiguous /14 available rather than transferring two disparate > /15s and disaggregating them. > > Owen > > On May 29, 2011, at 9:34 PM, Frank Bulk wrote: > > > I?m confused. If an organization can demonstrate need for a /14 and they can only find a /15 in the market today, why should they have to wait a whole year if they can find another /15 just a few months later? Why should we penalize them for the fact that the supply at the time of need is low? Is it because you want someone else with demonstrable need to get that second /15? If that?s the case, won?t that be based on who?s willing to pay top dollar for that /15? > > Frank > > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Owen DeLong > Sent: Sunday, May 29, 2011 10:46 PM > To: Brett Frankenberger > Cc: arin-ppml at arin.net > Subject: Re: [arin-ppml] ARIN-prop-153 Correct erroneous syntax in NRPM 8.3 > > > > What I would think makes more sense as policy would be: > > Organizations may transfer multiple address blocks but > no organization shall receive more than one address block > per year where said address block is smaller > than its original registered size. > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From frnkblk at iname.com Tue May 31 08:10:34 2011 From: frnkblk at iname.com (Frank Bulk) Date: Tue, 31 May 2011 07:10:34 -0500 Subject: [arin-ppml] ARIN-prop-153 Correct erroneous syntax in NRPM 8.3 In-Reply-To: <-4833767692051125933@unknownmsgid> References: <4DDFA7A6.105@arin.net> <20110529191506.GA28505@panix.com> <20110530021405.GA22407@panix.com> <013401cc1e82$dfddd260$9f997720$@iname.com> <8F6F6B58-2A61-480A-B5FC-B3B97EA11809@delong.com> <014c01cc1f38$b5a28b60$20e7a220$@iname.com> <-4833767692051125933@unknownmsgid> Message-ID: <015101cc1f8b$beae7040$3c0b50c0$@iname.com> As long as everyone works within the ARIN transfer policy, attaching the limits on the recipients would seem sufficient. Echoing previous posters' concerns, those who fall under the "3 month" needs demonstration may create more disaggregation if they have to get small chunks every time rather than a chunk two or three times larger. Ideally they're buying the chunks contiguously. I don't know if we can/should incent them to do that, or if having a contiguous block and not having to find a new seller each time is incentive enough. I mean, if they really think they're going to grow, they'll likely want to create a contract from the same seller to buy more chunks. Frank From: Scott Leibrand [mailto:scottleibrand at gmail.com] Sent: Tuesday, May 31, 2011 12:27 AM To: frnkblk at iname.com Cc: Owen DeLong; arin-ppml at arin.net Subject: Re: [arin-ppml] ARIN-prop-153 Correct erroneous syntax in NRPM 8.3 ARIN deaggregates /8s into /22s and /20s today, so that's not really much different. It seems that any restriction needs to be on the recipient getting a bunch of deaggregates, not on a large block holder transferring to lots of smaller recipients. Scott On May 30, 2011, at 7:16 PM, "Frank Bulk" wrote: That's a good goal, but how does this policy manage disaggregation where a larger block owner has the opportunity to sell to different buyers? For example, the owner of a /8 that has an unused /10 could sell /12's to four different buyers. On one hand there's a desire to minimize disaggregation, on the other hand if there's unused space that others with a validated need could use, why not. Frank From: Owen DeLong [mailto:owen at delong.com] Sent: Monday, May 30, 2011 11:28 AM To: frnkblk at iname.com Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] ARIN-prop-153 Correct erroneous syntax in NRPM 8.3 If they can find two /15s that started out as /15s, then there's no problem. The issue comes if they, for example, find someone with a /8 and want to get two disparate /15s from within that /8. The intent here is to require the /8 holder to renumber enough to make a contiguous /14 available rather than transferring two disparate /15s and disaggregating them. Owen On May 29, 2011, at 9:34 PM, Frank Bulk wrote: I'm confused. If an organization can demonstrate need for a /14 and they can only find a /15 in the market today, why should they have to wait a whole year if they can find another /15 just a few months later? Why should we penalize them for the fact that the supply at the time of need is low? Is it because you want someone else with demonstrable need to get that second /15? If that's the case, won't that be based on who's willing to pay top dollar for that /15? Frank From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Owen DeLong Sent: Sunday, May 29, 2011 10:46 PM To: Brett Frankenberger Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] ARIN-prop-153 Correct erroneous syntax in NRPM 8.3 What I would think makes more sense as policy would be: Organizations may transfer multiple address blocks but no organization shall receive more than one address block per year where said address block is smaller than its original registered size. _______________________________________________ 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 mike at nationwideinc.com Tue May 31 11:49:46 2011 From: mike at nationwideinc.com (Mike Burns) Date: Tue, 31 May 2011 11:49:46 -0400 Subject: [arin-ppml] ARIN-prop-153 Correct erroneous syntax in NRPM 8.3 References: <4DDFA7A6.105@arin.net><20110529191506.GA28505@panix.com><20110530021405.GA22407@panix.com><013401cc1e82$dfddd260$9f997720$@iname.com><8F6F6B58-2A61-480A-B5FC-B3B97EA11809@ delong.com><014c01cc1f38$b5a28b60$20e7a220$@iname.com><-4833767692051125933@unknownmsgid> <015101cc1f8b$beae7040$3c0b50c0$@iname.com> Message-ID: This is all an unnecessary and needlessly confusing set of rules whose only purpose is to attempt to impose some restriction on the downwards slide towards disaggregation which will happen whatever policies we prescribe. In a fluid transfer market, nobody will purposely select to fill their needs with a smattering of smaller netblocks, they will by nature attempt to acquire the largest block to suit their purchase requirements, if only to relieve them of configuration complexity. In fact, my guess is that people will tend to round up, to allow for a little more room to grow within a contiguous block, bounded of course by the cost of holding unused inventory of addresses. Larger netblocks are more likely to be routed everywhere than smaller ones, and this alone will drive consumers towards aggregation. Creating a new and confusing set of rules related to timeframes for allowed purchases, tracking original registration sizes through potentially multiple transactions, restricting sellers from selling off chunks of their holdings, these things are exactly what would be wrong in putting the steward's lightest touch on things. Because they would inevitably lead to buyers with a real need not getting addresses in a timely fashion, additional listing requirements (like original allocation size), and of course, lots more transactions happening off the books and leading to a decay in Whois accuracy and representing a failure of our primary stewardship role. And where is the evidence that this will serve as an actual check on disaggregation, and where is the evidence that we are BGP-table bound, in any real sense? The check on the growth of the table will not come from the RIR's, in a post-exhaust world, it will come from the decisions of the network operator group about what the minimum routable block size is. I oppose the policy. Regards, Mike ----- Original Message ----- From: Frank Bulk To: 'Scott Leibrand' Cc: arin-ppml at arin.net Sent: Tuesday, May 31, 2011 8:10 AM Subject: Re: [arin-ppml] ARIN-prop-153 Correct erroneous syntax in NRPM 8.3 As long as everyone works within the ARIN transfer policy, attaching the limits on the recipients would seem sufficient. Echoing previous posters' concerns, those who fall under the "3 month" needs demonstration may create more disaggregation if they have to get small chunks every time rather than a chunk two or three times larger. Ideally they're buying the chunks contiguously. I don't know if we can/should incent them to do that, or if having a contiguous block and not having to find a new seller each time is incentive enough. I mean, if they really think they're going to grow, they'll likely want to create a contract from the same seller to buy more chunks. Frank From: Scott Leibrand [mailto:scottleibrand at gmail.com] Sent: Tuesday, May 31, 2011 12:27 AM To: frnkblk at iname.com Cc: Owen DeLong; arin-ppml at arin.net Subject: Re: [arin-ppml] ARIN-prop-153 Correct erroneous syntax in NRPM 8.3 ARIN deaggregates /8s into /22s and /20s today, so that's not really much different. It seems that any restriction needs to be on the recipient getting a bunch of deaggregates, not on a large block holder transferring to lots of smaller recipients. Scott On May 30, 2011, at 7:16 PM, "Frank Bulk" wrote: That's a good goal, but how does this policy manage disaggregation where a larger block owner has the opportunity to sell to different buyers? For example, the owner of a /8 that has an unused /10 could sell /12's to four different buyers. On one hand there's a desire to minimize disaggregation, on the other hand if there's unused space that others with a validated need could use, why not. Frank From: Owen DeLong [mailto:owen at delong.com] Sent: Monday, May 30, 2011 11:28 AM To: frnkblk at iname.com Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] ARIN-prop-153 Correct erroneous syntax in NRPM 8.3 If they can find two /15s that started out as /15s, then there's no problem. The issue comes if they, for example, find someone with a /8 and want to get two disparate /15s from within that /8. The intent here is to require the /8 holder to renumber enough to make a contiguous /14 available rather than transferring two disparate /15s and disaggregating them. Owen On May 29, 2011, at 9:34 PM, Frank Bulk wrote: I'm confused. If an organization can demonstrate need for a /14 and they can only find a /15 in the market today, why should they have to wait a whole year if they can find another /15 just a few months later? Why should we penalize them for the fact that the supply at the time of need is low? Is it because you want someone else with demonstrable need to get that second /15? If that's the case, won't that be based on who's willing to pay top dollar for that /15? Frank From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Owen DeLong Sent: Sunday, May 29, 2011 10:46 PM To: Brett Frankenberger Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] ARIN-prop-153 Correct erroneous syntax in NRPM 8.3 What I would think makes more sense as policy would be: Organizations may transfer multiple address blocks but no organization shall receive more than one address block per year where said address block is smaller than its original registered size. _______________________________________________ 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 frnkblk at iname.com Tue May 31 11:57:20 2011 From: frnkblk at iname.com (Frank Bulk - iName.com) Date: Tue, 31 May 2011 10:57:20 -0500 Subject: [arin-ppml] ARIN-prop-153 Correct erroneous syntax in NRPM 8.3 In-Reply-To: References: <4DDFA7A6.105@arin.net><20110529191506.GA28505@panix.com><20110530021405.GA22407@panix.com><013401cc1e82$dfddd260$9f997720$@iname.com><8F6F6B58-2A61-480A-B5FC-B3B97EA11809@ delong.com><014c01cc1f38$b5a28b60$20e7a220$@iname.com><-4833767692051125933@unknownmsgid> <015101cc1f8b$beae7040$3c0b50c0$@iname.com> Message-ID: Rather than let my transit and peering providers summarize routes for me, I prefer to have the IPv4 tables be as slim as possible. Those who request blocks are not those who maintain and purchase routers. If we find out that disaggregation is not an issue we can always eliminate those policies. Frank From: Mike Burns [mailto:mike at nationwideinc.com] Sent: Tuesday, May 31, 2011 10:50 AM To: frnkblk at iname.com; 'Scott Leibrand' Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] ARIN-prop-153 Correct erroneous syntax in NRPM 8.3 This is all an unnecessary and needlessly confusing set of rules whose only purpose is to attempt to impose some restriction on the downwards slide towards disaggregation which will happen whatever policies we prescribe. In a fluid transfer market, nobody will purposely select to fill their needs with a smattering of smaller netblocks, they will by nature attempt to acquire the largest block to suit their purchase requirements, if only to relieve them of configuration complexity. In fact, my guess is that people will tend to round up, to allow for a little more room to grow within a contiguous block, bounded of course by the cost of holding unused inventory of addresses. Larger netblocks are more likely to be routed everywhere than smaller ones, and this alone will drive consumers towards aggregation. Creating a new and confusing set of rules related to timeframes for allowed purchases, tracking original registration sizes through potentially multiple transactions, restricting sellers from selling off chunks of their holdings, these things are exactly what would be wrong in putting the steward's lightest touch on things. Because they would inevitably lead to buyers with a real need not getting addresses in a timely fashion, additional listing requirements (like original allocation size), and of course, lots more transactions happening off the books and leading to a decay in Whois accuracy and representing a failure of our primary stewardship role. And where is the evidence that this will serve as an actual check on disaggregation, and where is the evidence that we are BGP-table bound, in any real sense? The check on the growth of the table will not come from the RIR's, in a post-exhaust world, it will come from the decisions of the network operator group about what the minimum routable block size is. I oppose the policy. Regards, Mike ----- Original Message ----- From: Frank Bulk To: 'Scott Leibrand' Cc: arin-ppml at arin.net Sent: Tuesday, May 31, 2011 8:10 AM Subject: Re: [arin-ppml] ARIN-prop-153 Correct erroneous syntax in NRPM 8.3 As long as everyone works within the ARIN transfer policy, attaching the limits on the recipients would seem sufficient. Echoing previous posters' concerns, those who fall under the "3 month" needs demonstration may create more disaggregation if they have to get small chunks every time rather than a chunk two or three times larger. Ideally they're buying the chunks contiguously. I don't know if we can/should incent them to do that, or if having a contiguous block and not having to find a new seller each time is incentive enough. I mean, if they really think they're going to grow, they'll likely want to create a contract from the same seller to buy more chunks. Frank From: Scott Leibrand [mailto:scottleibrand at gmail.com] Sent: Tuesday, May 31, 2011 12:27 AM To: frnkblk at iname.com Cc: Owen DeLong; arin-ppml at arin.net Subject: Re: [arin-ppml] ARIN-prop-153 Correct erroneous syntax in NRPM 8.3 ARIN deaggregates /8s into /22s and /20s today, so that's not really much different. It seems that any restriction needs to be on the recipient getting a bunch of deaggregates, not on a large block holder transferring to lots of smaller recipients. Scott On May 30, 2011, at 7:16 PM, "Frank Bulk" wrote: That's a good goal, but how does this policy manage disaggregation where a larger block owner has the opportunity to sell to different buyers? For example, the owner of a /8 that has an unused /10 could sell /12's to four different buyers. On one hand there's a desire to minimize disaggregation, on the other hand if there's unused space that others with a validated need could use, why not. Frank From: Owen DeLong [mailto:owen at delong.com] Sent: Monday, May 30, 2011 11:28 AM To: frnkblk at iname.com Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] ARIN-prop-153 Correct erroneous syntax in NRPM 8.3 If they can find two /15s that started out as /15s, then there's no problem. The issue comes if they, for example, find someone with a /8 and want to get two disparate /15s from within that /8. The intent here is to require the /8 holder to renumber enough to make a contiguous /14 available rather than transferring two disparate /15s and disaggregating them. Owen On May 29, 2011, at 9:34 PM, Frank Bulk wrote: I'm confused. If an organization can demonstrate need for a /14 and they can only find a /15 in the market today, why should they have to wait a whole year if they can find another /15 just a few months later? Why should we penalize them for the fact that the supply at the time of need is low? Is it because you want someone else with demonstrable need to get that second /15? If that's the case, won't that be based on who's willing to pay top dollar for that /15? Frank From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Owen DeLong Sent: Sunday, May 29, 2011 10:46 PM To: Brett Frankenberger Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] ARIN-prop-153 Correct erroneous syntax in NRPM 8.3 What I would think makes more sense as policy would be: Organizations may transfer multiple address blocks but no organization shall receive more than one address block per year where said address block is smaller than its original registered size. _______________________________________________ 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 mike at nationwideinc.com Tue May 31 12:08:09 2011 From: mike at nationwideinc.com (Mike Burns) Date: Tue, 31 May 2011 12:08:09 -0400 Subject: [arin-ppml] ARIN-prop-153 Correct erroneous syntax in NRPM 8.3 References: <4DDFA7A6.105@arin.net><20110529191506.GA28505@panix.com><20110530021405.GA22407@panix.com><013401cc1e82$dfddd260$9f997720$@iname.com><8F6F6B58-2A61-480A-B5FC-B3B97EA11809@ delong.com><014c01cc1f38$b5a28b60$20e7a220$@iname.com><-4833767692051125933@unknownmsgid> <015101cc1f8b$beae7040$3c0b50c0$@iname.com> Message-ID: Hi Frank, Don't you think that every purchaser will have the same impetus towards aggregation (slimmer table)? And the network operator community has the same desire (slimmer table). (The network community which maintains routers also does request blocks, I think that they will probably be among the most active buyers and sellers.) So why create policy whose effect in this area is unproven, despite evidence that it does not work well in certain scenarios? By that I mean some who need now will have to wait, some who want to sell will keep addresses on the sideline, etc. My argument is that our primary responsibilty is maintaining an accurate Whois registry, and these increasing complex mechanisms work against that responsibility by incentivizing off-the-books transfers. Regards, Mike ----- Original Message ----- From: Frank Bulk - iName.com To: 'Mike Burns' Cc: arin-ppml at arin.net ; 'Scott Leibrand' Sent: Tuesday, May 31, 2011 11:57 AM Subject: RE: [arin-ppml] ARIN-prop-153 Correct erroneous syntax in NRPM 8.3 Rather than let my transit and peering providers summarize routes for me, I prefer to have the IPv4 tables be as slim as possible. Those who request blocks are not those who maintain and purchase routers. If we find out that disaggregation is not an issue we can always eliminate those policies. Frank From: Mike Burns [mailto:mike at nationwideinc.com] Sent: Tuesday, May 31, 2011 10:50 AM To: frnkblk at iname.com; 'Scott Leibrand' Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] ARIN-prop-153 Correct erroneous syntax in NRPM 8.3 This is all an unnecessary and needlessly confusing set of rules whose only purpose is to attempt to impose some restriction on the downwards slide towards disaggregation which will happen whatever policies we prescribe. In a fluid transfer market, nobody will purposely select to fill their needs with a smattering of smaller netblocks, they will by nature attempt to acquire the largest block to suit their purchase requirements, if only to relieve them of configuration complexity. In fact, my guess is that people will tend to round up, to allow for a little more room to grow within a contiguous block, bounded of course by the cost of holding unused inventory of addresses. Larger netblocks are more likely to be routed everywhere than smaller ones, and this alone will drive consumers towards aggregation. Creating a new and confusing set of rules related to timeframes for allowed purchases, tracking original registration sizes through potentially multiple transactions, restricting sellers from selling off chunks of their holdings, these things are exactly what would be wrong in putting the steward's lightest touch on things. Because they would inevitably lead to buyers with a real need not getting addresses in a timely fashion, additional listing requirements (like original allocation size), and of course, lots more transactions happening off the books and leading to a decay in Whois accuracy and representing a failure of our primary stewardship role. And where is the evidence that this will serve as an actual check on disaggregation, and where is the evidence that we are BGP-table bound, in any real sense? The check on the growth of the table will not come from the RIR's, in a post-exhaust world, it will come from the decisions of the network operator group about what the minimum routable block size is. I oppose the policy. Regards, Mike ----- Original Message ----- From: Frank Bulk To: 'Scott Leibrand' Cc: arin-ppml at arin.net Sent: Tuesday, May 31, 2011 8:10 AM Subject: Re: [arin-ppml] ARIN-prop-153 Correct erroneous syntax in NRPM 8.3 As long as everyone works within the ARIN transfer policy, attaching the limits on the recipients would seem sufficient. Echoing previous posters' concerns, those who fall under the "3 month" needs demonstration may create more disaggregation if they have to get small chunks every time rather than a chunk two or three times larger. Ideally they're buying the chunks contiguously. I don't know if we can/should incent them to do that, or if having a contiguous block and not having to find a new seller each time is incentive enough. I mean, if they really think they're going to grow, they'll likely want to create a contract from the same seller to buy more chunks. Frank From: Scott Leibrand [mailto:scottleibrand at gmail.com] Sent: Tuesday, May 31, 2011 12:27 AM To: frnkblk at iname.com Cc: Owen DeLong; arin-ppml at arin.net Subject: Re: [arin-ppml] ARIN-prop-153 Correct erroneous syntax in NRPM 8.3 ARIN deaggregates /8s into /22s and /20s today, so that's not really much different. It seems that any restriction needs to be on the recipient getting a bunch of deaggregates, not on a large block holder transferring to lots of smaller recipients. Scott On May 30, 2011, at 7:16 PM, "Frank Bulk" wrote: That's a good goal, but how does this policy manage disaggregation where a larger block owner has the opportunity to sell to different buyers? For example, the owner of a /8 that has an unused /10 could sell /12's to four different buyers. On one hand there's a desire to minimize disaggregation, on the other hand if there's unused space that others with a validated need could use, why not. Frank From: Owen DeLong [mailto:owen at delong.com] Sent: Monday, May 30, 2011 11:28 AM To: frnkblk at iname.com Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] ARIN-prop-153 Correct erroneous syntax in NRPM 8.3 If they can find two /15s that started out as /15s, then there's no problem. The issue comes if they, for example, find someone with a /8 and want to get two disparate /15s from within that /8. The intent here is to require the /8 holder to renumber enough to make a contiguous /14 available rather than transferring two disparate /15s and disaggregating them. Owen On May 29, 2011, at 9:34 PM, Frank Bulk wrote: I'm confused. If an organization can demonstrate need for a /14 and they can only find a /15 in the market today, why should they have to wait a whole year if they can find another /15 just a few months later? Why should we penalize them for the fact that the supply at the time of need is low? Is it because you want someone else with demonstrable need to get that second /15? If that's the case, won't that be based on who's willing to pay top dollar for that /15? Frank From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Owen DeLong Sent: Sunday, May 29, 2011 10:46 PM To: Brett Frankenberger Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] ARIN-prop-153 Correct erroneous syntax in NRPM 8.3 What I would think makes more sense as policy would be: Organizations may transfer multiple address blocks but no organization shall receive more than one address block per year where said address block is smaller than its original registered size. _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. ---------------------------------------------------------------------------- _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthew at matthew.at Tue May 31 12:17:37 2011 From: matthew at matthew.at (Matthew Kaufman) Date: Tue, 31 May 2011 09:17:37 -0700 Subject: [arin-ppml] ARIN-prop-153 Correct erroneous syntax in NRPM 8.3 In-Reply-To: <8F6F6B58-2A61-480A-B5FC-B3B97EA11809@delong.com> References: <4DDFA7A6.105@arin.net> <20110529191506.GA28505@panix.com> <20110530021405.GA22407@panix.com> <013401cc1e82$dfddd260$9f997720$@iname.com> <8F6F6B58-2A61-480A-B5FC-B3B97EA11809@delong.com> Message-ID: <4DE514A1.3020506@matthew.at> On 5/30/2011 9:28 AM, Owen DeLong wrote: > If they can find two /15s that started out as /15s, then there's no > problem. The issue comes if they, for example, > find someone with a /8 and want to get two disparate /15s from within > that /8. The intent here is to require > the /8 holder to renumber enough to make a contiguous /14 available > rather than transferring two disparate > /15s and disaggregating them. So write the policy so that the /8 holder can't break up their /8 more than you think is acceptable. I can see all sorts of complications with trying to do it any other way... if Org A splits their /8 into a bunch of /24s and Org B gets one of them and Org C gets one of them (not contiguous /24s), what happens when Org B and Org C merge? What about when Org C goes bankrupt and Org B is one of the bidders for their space? Matthew Kaufman From matthew at matthew.at Tue May 31 12:22:32 2011 From: matthew at matthew.at (Matthew Kaufman) Date: Tue, 31 May 2011 09:22:32 -0700 Subject: [arin-ppml] ARIN-prop-153 Correct erroneous syntax in NRPM 8.3 In-Reply-To: <015101cc1f8b$beae7040$3c0b50c0$@iname.com> References: <4DDFA7A6.105@arin.net> <20110529191506.GA28505@panix.com> <20110530021405.GA22407@panix.com> <013401cc1e82$dfddd260$9f997720$@iname.com> <8F6F6B58-2A61-480A-B5FC-B3B97EA11809@delong.com> <014c01cc1f38$b5a28b60$20e7a220$@iname.com> <-4833767692051125933@unknownmsgid> <015101cc1f8b$beae7040$3c0b50c0$@iname.com> Message-ID: <4DE515C8.3060300@matthew.at> On 5/31/2011 5:10 AM, Frank Bulk wrote: > > As long as everyone works within the ARIN transfer policy, attaching > the limits on the recipients would seem sufficient. > > I disagree... putting limits on the holder of space that prevents them from breaking it up too rapidly (and thus creating BGP table growth) is fairly easy. Putting limits on the buyer makes the transfer market incredibly complex and confusing. For instance, a buyer who needs a /23 of space might see that there's no /23s available but that there are two /24s available. Can they acquire those /24s? Under existing policy the answer is "yes, if they can demonstrate need for the /23 of space". Under the various proposed policies the answer is "it depends". In some cases it might depend on whether or not ARIN had originally allocated either or both of those as /24s. In other cases it might depend on whether the two /24s come from the same original block that ARIN had allocated. But in no case is the answer simple. Matthew Kaufman -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthew at matthew.at Tue May 31 12:26:30 2011 From: matthew at matthew.at (Matthew Kaufman) Date: Tue, 31 May 2011 09:26:30 -0700 Subject: [arin-ppml] ARIN-prop-153 Correct erroneous syntax in NRPM 8.3 In-Reply-To: References: <4DDFA7A6.105@arin.net> <20110529191506.GA28505@panix.com> <20110530021405.GA22407@panix.com> <013401cc1e82$dfddd260$9f997720$@iname.com> <8F6F6B58-2A61-480A-B5FC-B3B97EA11809@delong.com> <014c01cc1f38$b5a28b60$20e7a220$@iname.com> Message-ID: <4DE516B6.6080609@matthew.at> On 5/31/2011 12:11 AM, Owen DeLong wrote: > I think we kind of have to accept that circumstance because it has > little differentiation from > when ARIN subdivides address space the same way. > But ARIN was previously able to subdivide space in a way that allows for growth without increasing table size, and at a fairly known rate, and with a finite limit imposed by the free pool size. If the goal is to prevent the BGP table size from growing too quickly, or causing it to grow in a predictable way, then we should come up with policies that reduce disaggregation at the source, no matter who the recipients are. If breaking up every block into /24-sized pieces is acceptable if the recipients are all different, then the table size is no different than if the recipients are all the same... and so there's no real win on table size, instead we simply make things overly complicated for the buyer for no benefit. Matthew Kaufman From lucas at cs.ucla.edu Tue May 31 12:39:58 2011 From: lucas at cs.ucla.edu (Lucas Wang) Date: Tue, 31 May 2011 09:39:58 -0700 Subject: [arin-ppml] An IP address block visualization tool Message-ID: <91D063EE-DCA8-4EA9-A475-09FE92D9D415@cs.ucla.edu> Hi, We built a visualization tool, dubbed EyeP, to show allocation status of the IPv4 address space. It also provides information about how address blocks are announced in BGP. Check it out at http://eyep.cs.ucla.edu, and the FAQ page can help you get started. Let us know your feedback. Thank you. Lucas -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 487 bytes Desc: This is a digitally signed message part URL: From owen at delong.com Tue May 31 12:55:24 2011 From: owen at delong.com (Owen DeLong) Date: Tue, 31 May 2011 09:55:24 -0700 Subject: [arin-ppml] ARIN-prop-153 Correct erroneous syntax in NRPM 8.3 In-Reply-To: References: <4DDFA7A6.105@arin.net><20110529191506.GA28505@panix.com><20110530021405.GA22407@panix.com><013401cc1e82$dfddd260$9f997720$@iname.com><8F6F6B58-2A61-480A-B5FC-B3B97EA11809@ delong.com><014c01cc1f38$b5a28b60$20e7a220$@iname.com><-4833767692051125933@unknownmsgid> <015101cc1f8b$beae7040$3c0b50c0$@iname.com> Message-ID: <7E0BCA1A-8F99-4BE8-8F25-2F03C66D2CA1@delong.com> On May 31, 2011, at 8:49 AM, Mike Burns wrote: > This is all an unnecessary and needlessly confusing set of rules whose only purpose is to attempt to impose some restriction on the downwards slide towards disaggregation which will happen whatever policies we prescribe. I believe the question here is a matter of degree and that with good policy we can reduce the degree significantly. > > In a fluid transfer market, nobody will purposely select to fill their needs with a smattering of smaller netblocks, they will by nature attempt to acquire the largest block to suit their purchase requirements, if only to relieve them of configuration complexity. > Unless price pressures encourage them to do otherwise. I think it's very likely they will. > In fact, my guess is that people will tend to round up, to allow for a little more room to grow within a contiguous block, bounded of course by the cost of holding unused inventory of addresses. > Some will, some won't. As you mentioned, I think that pricing could become a significant motivator here and that it might well serve to motivate people in the opposite direction of the desired result. > Larger netblocks are more likely to be routed everywhere than smaller ones, and this alone will drive consumers towards aggregation. Only for relatively small definitions of the term "smaller". Filtration at less than /20 is virtually impossible. Filtration at the point of /18s would be beyond dysfunctional. From a filtration perspective, I doubt anyone would think much about the difference between a /12 and 64 /18s. > > Creating a new and confusing set of rules related to timeframes for allowed purchases, tracking original registration sizes through potentially multiple transactions, restricting sellers from selling off chunks of their holdings, these things are exactly what would be wrong in putting the steward's lightest touch on things. > Again, I disagree. To prevent a transfer market from becoming a completely disruptive process to the stability and function of the internet, there need to be some limitations. The question is what is the minimal set of functional regulations. I believe that some restrictions on disaggregation are vital. > Because they would inevitably lead to buyers with a real need not getting addresses in a timely fashion, additional listing requirements (like original allocation size), and of course, lots more transactions happening off the books and leading to a decay in Whois accuracy and representing a failure of our primary stewardship role. You keep insisting that any attempt to regulate the market will increase transactions off the books, yet, you have no proof of this and you continue to ignore the significant risks that would be taken by organizations attempting to engage in off-the-books transfers. It's a great bogey-man, but, I am not convinced that it is a real threat or that a significant volume of these transactions would, in fact, occur. > > And where is the evidence that this will serve as an actual check on disaggregation, and where is the evidence that we are BGP-table bound, in any real sense? There are currently almost 400,000 routes in the global table. There are many large AS's that are carrying more than 75,000 interior routes not visible in the global table. There are not very many routers out there that can sustain a FIB with more than 500,000 unique destinations. We are most definitely BGP-table bound in a very real sense. Additionally, we are on the ragged edge of churn-bound in a very real sense in some cases. There is significant documentation to indicate that more prefixes increases churn, though, not in a directly proportional manner. As to whether this would serve as an actual check on disaggregation, it at least serves nearly as well as current policy without transfers does, so, it at least preserves most of the functionality of current RIR policy which is about the best I think we can actually do. If you have an idea for a more effective mechanism, I think that would be great. If you don't, then I think it is better to at least make some attempt to limit disaggregation than simply open the flood gates and watch the internet collapse under the weight of its routing table. > > The check on the growth of the table will not come from the RIR's, in a post-exhaust world, it will come from the decisions of the network operator group about what the minimum routable block size is. At what cost. Escalating the minimum routable block size will likely lead to disruption and instability for existing users of smaller blocks. I consider that an undesirable consequence of a failure of stewardship. I think it is far better to attempt to manage the transfer process so as to reduce this probability, even if we cannot eliminate it altogether. Owen -------------- next part -------------- An HTML attachment was scrubbed... URL: From owen at delong.com Tue May 31 13:03:50 2011 From: owen at delong.com (Owen DeLong) Date: Tue, 31 May 2011 10:03:50 -0700 Subject: [arin-ppml] ARIN-prop-153 Correct erroneous syntax in NRPM 8.3 In-Reply-To: <4DE514A1.3020506@matthew.at> References: <4DDFA7A6.105@arin.net> <20110529191506.GA28505@panix.com> <20110530021405.GA22407@panix.com> <013401cc1e82$dfddd260$9f997720$@iname.com> <8F6F6B58-2A61-480A-B5FC-B3B97EA11809@delong.com> <4DE514A1.3020506@matthew.at> Message-ID: <72E82B9E-5CA4-4A09-B7E0-C115A9B847B9@delong.com> On May 31, 2011, at 9:17 AM, Matthew Kaufman wrote: > On 5/30/2011 9:28 AM, Owen DeLong wrote: >> If they can find two /15s that started out as /15s, then there's no problem. The issue comes if they, for example, >> find someone with a /8 and want to get two disparate /15s from within that /8. The intent here is to require >> the /8 holder to renumber enough to make a contiguous /14 available rather than transferring two disparate >> /15s and disaggregating them. > > So write the policy so that the /8 holder can't break up their /8 more than you think is acceptable. > The definition of what is acceptable is context-sensitive. If the holder of the /8 finds 16 organizations that each need a /24, I don't have a problem with that. What I don't want is for a holder of a /8 that finds an organization that needs a /20 selling them 16 disjoint /24s to meet that need. > I can see all sorts of complications with trying to do it any other way... if Org A splits their /8 into a bunch of /24s and Org B gets one of them and Org C gets one of them (not contiguous /24s), what happens when Org B and Org C merge? What about when Org C goes bankrupt and Org B is one of the bidders for their space? > Merger: The same thing that happens now with RIR-issued /24s. the combined Org B+C continues to advertise both /24s. Bankruptcy: Depends on the timing. If it is within 1 year of Org B having received some other sub-block, then, Org B is an ineligible bidder. Owen From owen at delong.com Tue May 31 13:09:21 2011 From: owen at delong.com (Owen DeLong) Date: Tue, 31 May 2011 10:09:21 -0700 Subject: [arin-ppml] ARIN-prop-153 Correct erroneous syntax in NRPM 8.3 In-Reply-To: <4DE516B6.6080609@matthew.at> References: <4DDFA7A6.105@arin.net> <20110529191506.GA28505@panix.com> <20110530021405.GA22407@panix.com> <013401cc1e82$dfddd260$9f997720$@iname.com> <8F6F6B58-2A61-480A-B5FC-B3B97EA11809@delong.com> <014c01cc1f38$b5a28b60$20e7a220$@iname.com> <4DE516B6.6080609@matthew.at> Message-ID: <82A34E79-64E9-4AAC-BDB2-0CEE598A88F7@delong.com> On May 31, 2011, at 9:26 AM, Matthew Kaufman wrote: > On 5/31/2011 12:11 AM, Owen DeLong wrote: >> I think we kind of have to accept that circumstance because it has little differentiation from >> when ARIN subdivides address space the same way. >> > > But ARIN was previously able to subdivide space in a way that allows for growth without increasing table size, and at a fairly known rate, and with a finite limit imposed by the free pool size. > This required having the ability to do somewhat sparse allocations. A transfer market has no such ability. There is no possibility of reserving adjacent free blocks in a transfer market. > If the goal is to prevent the BGP table size from growing too quickly, or causing it to grow in a predictable way, then we should come up with policies that reduce disaggregation at the source, no matter who the recipients are. > The recipients are the source of the disaggregation. The source of the addresses are not the actual source of the disaggregation. > If breaking up every block into /24-sized pieces is acceptable if the recipients are all different, then the table size is no different than if the recipients are all the same... and so there's no real win on table size, instead we simply make things overly complicated for the buyer for no benefit. > While this is true, there is no possibility to serve the 65,536 disparate organizations (which is also an unlikely corner case to begin with) with a single aggregate, while a single organization which needs a /8 can be served with a /8 and does not need to occupy 65,536 slots in the routing table. While it is possible to create theoretical scenarios where there is no effect on table size, in the real world, the effect is actually significant and there is a real win on table size. As such, yes, things get a little bit more complex (not much, frankly), but there is significant benefit. Owen From bill at herrin.us Tue May 31 13:18:09 2011 From: bill at herrin.us (William Herrin) Date: Tue, 31 May 2011 13:18:09 -0400 Subject: [arin-ppml] ARIN-prop-153 Correct erroneous syntax in NRPM 8.3 In-Reply-To: References: <4DDFA7A6.105@arin.net> <20110529191506.GA28505@panix.com> <20110530021405.GA22407@panix.com> <013401cc1e82$dfddd260$9f997720$@iname.com> <8F6F6B58-2A61-480A-B5FC-B3B97EA11809@delong.com> <014c01cc1f38$b5a28b60$20e7a220$@iname.com> Message-ID: On Tue, May 31, 2011 at 3:11 AM, Owen DeLong wrote: > I think we kind of have to accept that circumstance because it has little > differentiation from > when ARIN subdivides address space the same way. Hi Owen, If that's the consensus goal then put together some verbiage for 8.3 that hits these five points: a. Any registrant may offer an entire ARIN IPv4 address block registration for transfer without restriction. b. Any registrant may offer part of an ARIN IPv4 address block registration with a prefix no longer than /24 for transfer. /8 through /24 allowed, /25 through /32 prohibited. c. Transfers under 8.3 are only received as fulfillment of an ordinary section 4 request following all ordinary policies and procedures under section 4. To the extent that turns out to obstruct reasonable behavior, we'll fix it in section 4. d. Any registrant may receive any number of address blocks from (a) as needed to fulfill their ARIN-approved section 4 request. e. Any registrant may receive no more than $N discontiguous address blocks per $UNIT_TIME from (b) as needed to fulfill their approved section 4 request. So if you buy a partial fill, shop wisely. On Tue, May 31, 2011 at 12:08 PM, Mike Burns wrote: > Don't you think that every purchaser will have the same impetus towards > aggregation (slimmer table)? I use a set of $1500 Cisco 2811's. The size of the table is not a major economic concern for my employer. What's more, as a leaf node I'm able to employ a default route and do some filtering if I need to prolong the life of my router. So no, I don't think that every purchaser has the same impetus towards aggregation. Frank has it right when he says: On Tue, May 31, 2011 at 11:57 AM, Frank Bulk - iName.com wrote: > If we find out that disaggregation is not an issue we can always eliminate > those policies. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From matthew at matthew.at Tue May 31 13:30:25 2011 From: matthew at matthew.at (Matthew Kaufman) Date: Tue, 31 May 2011 10:30:25 -0700 Subject: [arin-ppml] ARIN-prop-153 Correct erroneous syntax in NRPM 8.3 In-Reply-To: <82A34E79-64E9-4AAC-BDB2-0CEE598A88F7@delong.com> References: <4DDFA7A6.105@arin.net> <20110529191506.GA28505@panix.com> <20110530021405.GA22407@panix.com> <013401cc1e82$dfddd260$9f997720$@iname.com> <8F6F6B58-2A61-480A-B5FC-B3B97EA11809@delong.com> <014c01cc1f38$b5a28b60$20e7a220$@iname.com> <4DE516B6.6080609@matthew.at> <82A34E79-64E9-4AAC-BDB2-0CEE598A88F7@delong.com> Message-ID: <4DE525B1.8030704@matthew.at> On 5/31/2011 10:09 AM, Owen DeLong wrote: > On May 31, 2011, at 9:26 AM, Matthew Kaufman wrote: > >> On 5/31/2011 12:11 AM, Owen DeLong wrote: >>> I think we kind of have to accept that circumstance because it has little differentiation from >>> when ARIN subdivides address space the same way. >>> >> But ARIN was previously able to subdivide space in a way that allows for growth without increasing table size, and at a fairly known rate, and with a finite limit imposed by the free pool size. >> > This required having the ability to do somewhat sparse allocations. A transfer market has no > such ability. There is no possibility of reserving adjacent free blocks in a transfer market. > Exactly. So it is entirely different than when ARIN subdivides address space. >> If the goal is to prevent the BGP table size from growing too quickly, or causing it to grow in a predictable way, then we should come up with policies that reduce disaggregation at the source, no matter who the recipients are. >> > The recipients are the source of the disaggregation. The source of the addresses are not > the actual source of the disaggregation. > The recipients are the source of deaggregated routing table announcement. The source of the addresses being allowed to disaggregate their assignments is the original source of them problem you're seeking to fix. >> If breaking up every block into /24-sized pieces is acceptable if the recipients are all different, then the table size is no different than if the recipients are all the same... and so there's no real win on table size, instead we simply make things overly complicated for the buyer for no benefit. >> > While this is true, there is no possibility to serve the 65,536 disparate organizations > (which is also an unlikely corner case to begin with) with a single aggregate But there's also no need to do so. Perhaps this space is simply unusable for a time. ALL restrictions that prevent what you seek to prevent (Org A fulfilling Org B's need for a /22 by giving them 4 disjoint /24s from the same block) *also* prevent maximal utilization of unused space. Back to my original point, the right answer is somewhere between "all blocks may be broken up into /24-sized pieces" and "all blocks must not be broken up any further than the original ARIN allocation size"... and that's the *only* way to prevent table growth, as *who* gets the blocks is completely irrelevant for that point. Org A fulfilling Org B's need for a /22 by giving them 4 disjoint /24s is *exactly* as bad for the router memory as Org A fulfilling org B, C, D, and Es needs for /24s with 4 disjoint /24s and so if the goal is to keep the table smaller, the policy *should not* differentiate between these cases. Matthew Kaufman From frnkblk at iname.com Tue May 31 16:09:40 2011 From: frnkblk at iname.com (Frank Bulk) Date: Tue, 31 May 2011 15:09:40 -0500 Subject: [arin-ppml] ARIN-prop-153 Correct erroneous syntax in NRPM 8.3 In-Reply-To: <4DE525B1.8030704@matthew.at> References: <4DDFA7A6.105@arin.net> <20110529191506.GA28505@panix.com> <20110530021405.GA22407@panix.com> <013401cc1e82$dfddd260$9f997720$@iname.com> <8F6F6B58-2A61-480A-B5FC-B3B97EA11809@delong.com> <014c01cc1f38$b5a28b60$20e7a220$@iname.com> <4DE516B6.6080609@matthew.at> <82A34E79-64E9-4AAC-BDB2-0CEE598A88F7@delong.com> <4DE525B1.8030704@matthew.at> Message-ID: <000501cc1fce$ac8a98b0$059fca10$@iname.com> Because the end result is the same I share your concern, but the difference is that in the first case it was done sub-optimally for no good reason other than poor planning and in the second it met the goal of the IPv4 transfer process. So limiting the first has value. Frank -----Original Message----- From: Matthew Kaufman [mailto:matthew at matthew.at] Sent: Tuesday, May 31, 2011 12:30 PM To: Owen DeLong Cc: frnkblk at iname.com; arin-ppml at arin.net Subject: Re: [arin-ppml] ARIN-prop-153 Correct erroneous syntax in NRPM 8.3 Back to my original point, the right answer is somewhere between "all blocks may be broken up into /24-sized pieces" and "all blocks must not be broken up any further than the original ARIN allocation size"... and that's the *only* way to prevent table growth, as *who* gets the blocks is completely irrelevant for that point. Org A fulfilling Org B's need for a /22 by giving them 4 disjoint /24s is *exactly* as bad for the router memory as Org A fulfilling org B, C, D, and Es needs for /24s with 4 disjoint /24s and so if the goal is to keep the table smaller, the policy *should not* differentiate between these cases. Matthew Kaufman From owen at delong.com Tue May 31 17:10:48 2011 From: owen at delong.com (Owen DeLong) Date: Tue, 31 May 2011 14:10:48 -0700 Subject: [arin-ppml] ARIN-prop-153 Correct erroneous syntax in NRPM 8.3 In-Reply-To: <4DE525B1.8030704@matthew.at> References: <4DDFA7A6.105@arin.net> <20110529191506.GA28505@panix.com> <20110530021405.GA22407@panix.com> <013401cc1e82$dfddd260$9f997720$@iname.com> <8F6F6B58-2A61-480A-B5FC-B3B97EA11809@delong.com> <014c01cc1f38$b5a28b60$20e7a220$@iname.com> <4DE516B6.6080609@matthew.at> <82A34E79-64E9-4AAC-BDB2-0CEE598A88F7@delong.com> <4DE525B1.8030704@matthew.at> Message-ID: <29986C0D-0F99-4F95-AB2E-A4228F778FFC@delong.com> On May 31, 2011, at 10:30 AM, Matthew Kaufman wrote: > On 5/31/2011 10:09 AM, Owen DeLong wrote: >> On May 31, 2011, at 9:26 AM, Matthew Kaufman wrote: >> >>> On 5/31/2011 12:11 AM, Owen DeLong wrote: >>>> I think we kind of have to accept that circumstance because it has little differentiation from >>>> when ARIN subdivides address space the same way. >>>> >>> But ARIN was previously able to subdivide space in a way that allows for growth without increasing table size, and at a fairly known rate, and with a finite limit imposed by the free pool size. >>> >> This required having the ability to do somewhat sparse allocations. A transfer market has no >> such ability. There is no possibility of reserving adjacent free blocks in a transfer market. >> > > Exactly. So it is entirely different than when ARIN subdivides address space. > No, it is somewhat different because the available space limitations create additional constraints. >>> If the goal is to prevent the BGP table size from growing too quickly, or causing it to grow in a predictable way, then we should come up with policies that reduce disaggregation at the source, no matter who the recipients are. >>> >> The recipients are the source of the disaggregation. The source of the addresses are not >> the actual source of the disaggregation. >> > > The recipients are the source of deaggregated routing table announcement. The source of the addresses being allowed to disaggregate their assignments is the original source of them problem you're seeking to fix. > This can be argued either way. In fact, both sides have a contributory role and responsibility. >>> If breaking up every block into /24-sized pieces is acceptable if the recipients are all different, then the table size is no different than if the recipients are all the same... and so there's no real win on table size, instead we simply make things overly complicated for the buyer for no benefit. >>> >> While this is true, there is no possibility to serve the 65,536 disparate organizations >> (which is also an unlikely corner case to begin with) with a single aggregate > > But there's also no need to do so. Perhaps this space is simply unusable for a time. > > ALL restrictions that prevent what you seek to prevent (Org A fulfilling Org B's need for a /22 by giving them 4 disjoint /24s from the same block) *also* prevent maximal utilization of unused space. > I disagree. I believe that maximal use of address space can still be achieved under the proposed changes to 8.3. However, I agree that it might make some changes as to which parties are performing that utilization. Overall, I don't see this as a significant problem. > Back to my original point, the right answer is somewhere between "all blocks may be broken up into /24-sized pieces" and "all blocks must not be broken up any further than the original ARIN allocation size"... and that's the *only* way to prevent table growth, as *who* gets the blocks is completely irrelevant for that point. > Yes and no. The right answer is to allow transfers that disaggregate only to the extent absolutely necessary to meet a given recipient's need. If they need a /20, then, transferring a /20 is vastly preferable to transferring 16 disjoint /24s. On the other hand, 16 organizations, each of whom need a /24 have no better solution than to transfer 16 /24s, whether they come from the same source or not. > Org A fulfilling Org B's need for a /22 by giving them 4 disjoint /24s is *exactly* as bad for the router memory as Org A fulfilling org B, C, D, and Es needs for /24s with 4 disjoint /24s and so if the goal is to keep the table smaller, the policy *should not* differentiate between these cases. > While it is equally bad for router memory, the latter case is inevitable if the /24 needs of {B,C,D,E} are to be met, while meeting the /22 need of B can be accomplished without this impact. As such, allowing Org B to transfer 4 disjoint /24s rather than seek a /22, even if it costs them more per address or takes them longer has a negative impact on the rest of the community. Owen From matthew at matthew.at Tue May 31 19:00:51 2011 From: matthew at matthew.at (Matthew Kaufman) Date: Tue, 31 May 2011 16:00:51 -0700 Subject: [arin-ppml] ARIN-prop-153 Correct erroneous syntax in NRPM 8.3 In-Reply-To: <29986C0D-0F99-4F95-AB2E-A4228F778FFC@delong.com> References: <4DDFA7A6.105@arin.net> <20110529191506.GA28505@panix.com> <20110530021405.GA22407@panix.com> <013401cc1e82$dfddd260$9f997720$@iname.com> <8F6F6B58-2A61-480A-B5FC-B3B97EA11809@delong.com> <014c01cc1f38$b5a28b60$20e7a220$@iname.com> <4DE516B6.6080609@matthew.at> <82A34E79-64E9-4AAC-BDB2-0CEE598A88F7@delong.com> <4DE525B1.8030704@matthew.at> <29986C0D-0F99-4F95-AB2E-A4228F778FFC@delong.com> Message-ID: <4DE57323.7030705@matthew.at> On 5/31/2011 2:10 PM, Owen DeLong wrote: > > While it is equally bad for router memory, the latter case is inevitable if the /24 needs of {B,C,D,E} are to be met, while meeting the /22 need of B can be accomplished without this impact. As such, allowing Org B to transfer 4 disjoint /24s rather than seek a /22, even if it costs them more per address or takes them longer has a negative impact on the rest of the community. How about instead we create a group of people whose job it is to review transfer requests before they are granted and let them use their own common sense? Matthew Kaufman From owen at delong.com Tue May 31 19:25:57 2011 From: owen at delong.com (Owen DeLong) Date: Tue, 31 May 2011 16:25:57 -0700 Subject: [arin-ppml] ARIN-prop-153 Correct erroneous syntax in NRPM 8.3 In-Reply-To: <4DE57323.7030705@matthew.at> References: <4DDFA7A6.105@arin.net> <20110529191506.GA28505@panix.com> <20110530021405.GA22407@panix.com> <013401cc1e82$dfddd260$9f997720$@iname.com> <8F6F6B58-2A61-480A-B5FC-B3B97EA11809@delong.com> <014c01cc1f38$b5a28b60$20e7a220$@iname.com> <4DE516B6.6080609@matthew.at> <82A34E79-64E9-4AAC-BDB2-0CEE598A88F7@delong.com> <4DE525B1.8030704@matthew.at> <29986C0D-0F99-4F95-AB2E-A4228F778FFC@delong.com> <4DE57323.7030705@matthew.at> Message-ID: On May 31, 2011, at 4:00 PM, Matthew Kaufman wrote: > On 5/31/2011 2:10 PM, Owen DeLong wrote: >> >> While it is equally bad for router memory, the latter case is inevitable if the /24 needs of {B,C,D,E} are to be met, while meeting the /22 need of B can be accomplished without this impact. As such, allowing Org B to transfer 4 disjoint /24s rather than seek a /22, even if it costs them more per address or takes them longer has a negative impact on the rest of the community. > > How about instead we create a group of people whose job it is to review transfer requests before they are granted and let them use their own common sense? > > Matthew Kaufman We have such a group. It's called "Registration Services". They have requested that the community use policy to express our intent as to how common sense should be applied. I believe that we owe it to them to honor that request. Owen From tedm at ipinc.net Tue May 31 19:51:48 2011 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Tue, 31 May 2011 16:51:48 -0700 Subject: [arin-ppml] An IP address block visualization tool In-Reply-To: <91D063EE-DCA8-4EA9-A475-09FE92D9D415@cs.ucla.edu> References: <91D063EE-DCA8-4EA9-A475-09FE92D9D415@cs.ucla.edu> Message-ID: <4DE57F14.7000709@ipinc.net> The "Legends" link does nothing.... Ted On 5/31/2011 9:39 AM, Lucas Wang wrote: > Hi, > > We built a visualization tool, dubbed EyeP, to show allocation status > of the IPv4 address space. It also provides information about how > address blocks are announced in BGP. Check it out at > http://eyep.cs.ucla.edu, and the FAQ page can help you get started. > Let us know your feedback. Thank you. > > Lucas > > > > _______________________________________________ > 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 Tue May 31 20:17:59 2011 From: farmer at umn.edu (David Farmer) Date: Tue, 31 May 2011 19:17:59 -0500 Subject: [arin-ppml] An IP address block visualization tool In-Reply-To: <4DE57F14.7000709@ipinc.net> References: <91D063EE-DCA8-4EA9-A475-09FE92D9D415@cs.ucla.edu> <4DE57F14.7000709@ipinc.net> Message-ID: <4DE58537.6080405@umn.edu> On 5/31/11 18:51 CDT, Ted Mittelstaedt wrote: > The "Legends" link does nothing.... > > Ted Ted, Legends works as a scroll over for me, in Firefox and Chrome. Lucas, You seem to be using "UN" as the country Code for "United States" the standard two letter country code is "US". > On 5/31/2011 9:39 AM, Lucas Wang wrote: >> Hi, >> >> We built a visualization tool, dubbed EyeP, to show allocation status >> of the IPv4 address space. It also provides information about how >> address blocks are announced in BGP. Check it out at >> http://eyep.cs.ucla.edu, and the FAQ page can help you get started. >> Let us know your feedback. Thank you. >> >> Lucas -- =============================================== 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 lucas at cs.ucla.edu Tue May 31 20:39:36 2011 From: lucas at cs.ucla.edu (Lucas Wang) Date: Tue, 31 May 2011 17:39:36 -0700 Subject: [arin-ppml] An IP address block visualization tool In-Reply-To: <4DE58537.6080405@umn.edu> References: <91D063EE-DCA8-4EA9-A475-09FE92D9D415@cs.ucla.edu> <4DE57F14.7000709@ipinc.net> <4DE58537.6080405@umn.edu> Message-ID: <1ABB1381-A0D3-4F04-9150-FAB89CA8F351@cs.ucla.edu> On May 31, 2011, at 5:17 PM, David Farmer wrote: > On 5/31/11 18:51 CDT, Ted Mittelstaedt wrote: >> The "Legends" link does nothing.... >> >> Ted > > Ted, > > Legends works as a scroll over for me, in Firefox and Chrome. > > Lucas, > > You seem to be using "UN" as the country Code for "United States" the standard two letter country code is "US". David, Yes, that is a mistake, and it'll be fixed soon. Thank you for pointing it out. Lucas > >> On 5/31/2011 9:39 AM, Lucas Wang wrote: >>> Hi, >>> >>> We built a visualization tool, dubbed EyeP, to show allocation status >>> of the IPv4 address space. It also provides information about how >>> address blocks are announced in BGP. Check it out at >>> http://eyep.cs.ucla.edu, and the FAQ page can help you get started. >>> Let us know your feedback. Thank you. >>> >>> Lucas > > > -- > =============================================== > 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. -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 487 bytes Desc: This is a digitally signed message part URL: