- address-policy-wg - mailman.ripe.net

I wonder IP allocation of EU
by 황의종 18 Aug '09

18 Aug '09

Hi This is Bryan with KRNIC(Korea Network Information Center) I wonder IP allocation about RIPE-NCC. I found allocation of " EU" in RIPE-NCC statistics. As I know, EU is European Union and they have many countries(FR, UK, AU.....) But In statistics have "FR" , " UK", " AU" and so on. I want to know why was "EU" independent category in staticstics ? How many they have member ? If you have any idea and information about "EU" please send me e-mail. thanks Bryan Hwang

3 2

Minutes from RIPE 58 are now online
by Gert Doering 13 Aug '09

13 Aug '09

Hi APWG folks, the RIPE NCC has published the draft minutes from the RIPE 58 APWG meeting under the following URL: http://www.ripe.net/ripe/wg/address-policy/minutes.html http://www.ripe.net/ripe/wg/address-policy/r58-minutes.html If you have any additions, or anything that is reproduced incorrectly, please let us know so that it can be corrected. I apologize for the delay in getting these published - the NCC did a great job in creating a really impressive document quickly, and then it spent quite some time in my mailbox for review :-/ Gert Doering -- APWG chair -- Total number of prefixes smaller than registry allocations: 128645 SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279

1 0

Re: [ncc-services-wg] New RIPE NCC Procedural Document Available
by David Monosov 31 Jul '09

31 Jul '09

Dear ncc-services-wg, address-policy-wg, >From the document: [...] 4.2 Violation of RIPE Policy, Law or Contract The RIPE NCC will de-register the independent Internet number resources in case of a fundamental breach of contract by the End User, supported by a Dutch court order; or Violation of Law by the End User, supported by a Dutch court order; or violation of RIPE Policy by the End User. [...] IANAL, so please forgive me if this course of inquiry is completely misguided, but does this not explicitly put the validity of resource assignments in the hands of Dutch courts and Dutch prosecutors? RIPE NCC, as an organization domiciled in the Netherlands would at all times have to comply with valid court orders. However, prior to the existence of a direct contractual relationship with end users and this policy, RIPE NCC merely served as a custodian for a database. Challenging the contents of this database would have been a legal adventure. With the introduction of complete contractual chain through RIPE NCC, a LIR, and the end user, combined with this formal explicit policy to which the end user and the LIR must agree - isn't there a potential loophole being created for an enterprising litigant to impose Dutch legislation where it is might be favorable to their cause on foreign end users? Certainly, if this interpretation isn't overly naive, such a loophole was not the intention of policy 2007-01. Has the RIPE NCC received any legal counseling on this matter, and would it be willing to publish the opinion they were provided with? -- Respectfully yours, David Monosov Andrea Cima wrote: > [Apologies for duplicate emails] > > Dear Colleagues, > > The RIPE NCC has published a new RIPE NCC procedural document: > ripe-475, "Independent Internet Number Resources Contractual > Relationship Changes between sponsoring LIR and End User" > > This document describes the steps to be taken when there are changes in > the contractual relationship between the End User of independent > Internet number resources and the sponsoring Local Internet Registry > (LIR). It also describes the scenarios in which the RIPE NCC may > de-register independent Internet number resources and what happens to > those resources once they are de-registered. > > The new document is available at: > http://www.ripe.net/ripe/docs/ripe-475.html > > Kind regards, > > Andrea Cima > RIPE NCC

5 7

Re: [ncc-services-wg] New RIPE NCC Procedural Document Available
by Michiel Klaver 27 Jul '09

27 Jul '09

At 16-7-2009 16:53, Andrea Cima wrote: > [Apologies for duplicate emails] > > Dear Colleagues, > > The RIPE NCC has published a new RIPE NCC procedural document: > ripe-475, "Independent Internet Number Resources Contractual > Relationship Changes between sponsoring LIR and End User" > > This document describes the steps to be taken when there are changes in > the contractual relationship between the End User of independent > Internet number resources and the sponsoring Local Internet Registry > (LIR). It also describes the scenarios in which the RIPE NCC may > de-register independent Internet number resources and what happens to > those resources once they are de-registered. > > The new document is available at: > http://www.ripe.net/ripe/docs/ripe-475.html > > Kind regards, > > Andrea Cima > RIPE NCC >From the document: The End User contact email addresses listed in the RIPE Database object are notified by the RIPE NCC [...] I'm not a lawyer, but from what I understand on the matter of unilateral contract termination, e-mail notifications are not legally binding by Dutch law. You need certified registered postal mail with proof of delivery. In the case of a network that seized to exist and the resources become void and invalid, e-mail correspondention with that network might not be possible anymore. When applying for resources, one has to submit company registration documents and the corresponding organisation object created at the RIPE database should contain the same data. This data should be sufficient to track down and send out notifications to the correct holder by postal mail. Please consult your legal department on this matter and update the procedures described at the document. With kind regards, Michiel Klaver IT Professional

3 2

Re: [address-policy-wg] Spectrum and IP address reservations
by tvest＠eyeconomics.com 26 Jul '09

26 Jul '09

On Jul 20, 2009, at 4:38 AM, Milton L Mueller wrote: > I forward information about a study conducted by NERA on spectrum > auctions. > Not directly applicable to IP addresses, but has some relevance to > current discussions about attempts to reserve resources for new > entrants vs. incumbents. Bear in mind, of course, that the study was > produced by Telus, an incumbent operator, and discount for that; the > point is that we need to pay attention to the economic reasoning > underlying the finding; which is that policies designed to "help" > competitors can have unintended consequences that may encourage > conslidation and higher prices. Hi Milton, Clarifying question: what are you referring to exactly by "policies designed to 'help' competitors," and why are you choosing to reduce the question of routing and addressing system openness to this one narrow dimension? I (among others) have written a lot about the importances of keeping the door open for "new entrants," but not all new entrants are "competitors" -- nor is competition the only reason for incumbent service providers (and everybody else) to regard such openness as a critical institutional priority. To illustrate, I've never heard anyone claim that the *only* reason why it was a good idea to move from NCP addressing to classful IP was to enable competition. Ditto, the move from classful IP to CIDR; then as before, the prospect of continuous competition (including competition by emerging new entrants) was just one of many reasons to support the preservation of addressing and routing system openness. I'm assuming that whatever you find persuasive in this NERA document would not also implicate those past policy choices, because I don't think you'd find much sympathy for the idea that the "unintended consequences" of those decisions were/are so bad that they outweigh they *intended* consequences (i.e., a future with max. 256 independent addressing and routing system participants). Since most of the subscribers to these lists are not economists, it would be helpful if you could briefly summarize the "underlying economic reasoning" that you find particularly compelling in this study. If it was less onerous, I'd also request that you clarify what you regard to be the right way to balance intended vs. unintended policy choices, and "historically/experientially informed" vs. "idealized, theoretically informed" expectations about the future -- but perhaps a sentence or two of clarification on the NERA "reasoning" would suffice. Thanks, TV

17 31

Re: [address-policy-wg] RE: The price of address space
by trejrco＠gmail.com 25 Jul '09

25 Jul '09

That doesn't answer what you believe about all those deploying v6, for whatever reasons they are deploying it ... (Reasons that vary from environment to environment) If you want me to start listing the technical merits of IPv6 I would first point you to a plethora of sources - working groups, RFCs, whitepapers, new product lines and modes of communication, etc. - are you really asking for a single email to encompass 10+ years of work by hundreds+ people? ((I can (and do!) talk about IPv6 for a week at a time and am still time-constrained to present all of the how's, why's, and what's of IPv6 ... The majority of this time is presenting IPv6 things which are technically better than their IPv4 analogs)) FWIW, I would also include entire conversations about how NAT is not a panacea, and already breaks / limits application capabilities, carries 'costs' of it's own (both literal $, packet/forwarding overhead, security), etc. Again - not a single aspect that can readily be presented in a single email (feel free to ref. BEHAVE, for example) Again - I am not opposed to efforts to make NAT more transparent / functional ... PMP, ALD, UPnP, perhaps e2e, etc. - however I see none of these as a replacement for IPv6, nor any other aspect of IPv6 that is a deal-breaker. Imperfections that perhaps need to be mitigated (whether that is a protocol or an implementation 'fix' remains to be seen) - but nothing preventing me (or anyone else) from using v6 today (or, even more common - belated vendor support - ugh). /TJ ------Original Message------ From: Masataka Ohta To: TJ Evans Cc: address-policy-wg-admin(a)ripe.net Cc: address-policy-wg(a)ripe.net Subject: Re: [address-policy-wg] RE: The price of address space Sent: Jul 23, 2009 18:26 trejrco(a)gmail.com wrote: > I continue to be amazed at statements like: > "Today, it is not necessary to deploy IPv6 at all." > > So, you firmly believe that everyone deploying (or preparing to > deploy) IPv6 today is ... What, wasting time? Wrong? Stupid? As I said: > Technically speaking , so true. > Today, it is not neccesary to deploy IPv6 at all. valid counter arguments to me should have technical content. Masataka Ohta Sent from my Verizon Wireless BlackBerry

5 14

Re: [address-policy-wg] RE: The price of address space
by trejrco＠gmail.com 24 Jul '09

24 Jul '09

And obviously you are missing my point. I am hardly saying "This is the year"... I do not think there will a single year that will define / be defined by what boils down to the deployment of better plumbing. Was there ever a "year of www", "year of SMTP", etc.? I think you misunderstand - I do have a fairly long view here, but believe that circumstances have changed | are changing. I could say the same thing about denial, but that leads us down a very non-productive path. Probably best to agree to disagree at this point ... /TJ (Although I am still interested in your (or anyone else's, for that matter) opinion of those deploying / planning to deploy / etc. IPv6 ... ) ------Original Message------ From: Masataka Ohta To: TJ Evans Cc: address-policy-wg-admin(a)ripe.net Cc: address-policy-wg(a)ripe.net Subject: Re: [address-policy-wg] RE: The price of address space Sent: Jul 23, 2009 21:19 TJ wrote: > I do ... and have seen many "This is the year of IPv6" style statements, > which is not what I am saying. > Sorry, but I wholeheartedly disagree - I see that quite a bit has changed > WRT IPv6. > The protocol itself has been tweaked, the implementations of the protocol > have evolved, the deployment guidelines for both and the understanding of > all three of those things has been escalating rapidly over the last > ~couple-few years ... So obviously, you are saying "This is the year of IPv6". If you could have had a longer retrospective view, you could have noticed that your reasoning has been repeated so many times. Masataka Ohta Sent from my Verizon Wireless BlackBerry

1 0

2009-02 Proposal Accepted (Allocating/Assigning Resources to the RIPE NCC)
by Filiz Yilmaz 23 Jul '09

23 Jul '09

PDP Number: 2009-02 Allocating/Assigning Resources to the RIPE NCC Dear Colleagues, Consensus has been reached, and the proposal described in 2009-02 has been accepted by the RIPE community. A new RIPE policy document, "Allocating/Assigning Resources to the RIPE NCC", is now published and can be found at: http://www.ripe.net/ripe/docs/ripe-476.html The proposal is now archived and can be found at: http://www.ripe.net/ripe/policies/proposals/2009-02.html Thank you for your input. Regards, Filiz Yilmaz Policy Development Manager RIPE NCC

1 0

long term useful life expectancy for IPv4
by bmanning＠vacation.karoshi.com 23 Jul '09

23 Jul '09

would like to move the discussion to: http://www.longbets.org/about seems like a better place to hold this debate than policy fora. --bill

1 0

2009-06 New Draft Document Published (Removing Routing Requirements from the IPv6 Address Allocation Policy)
by Ingrid Wijte 23 Jul '09

23 Jul '09

PDP Number: 2009-06 Removing Routing Requirements from the IPv6 Address Allocation Policy Dear Colleagues The draft document for the proposal described in 2009-06 has been published. The impact analysis that was conducted for this proposal has also been published. You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2009-06.html and the draft document at: http://www.ripe.net/ripe/draft-documents/2009-06-draft.html We encourage you to read the draft document text and send any comments to address-policy-wg(a)ripe.net before 20 August 2009. Regards Ingrid Wijte Policy Development Officer

1 0

NRO NC Call for Nominations
by Axel Pawlik 22 Jul '09

22 Jul '09

[Apologies for duplicate emails] Dear Colleagues, This is a call for nominations from the RIPE NCC service region to fill one vacant seat on the Number Resource Organization (NRO) Number council (NC). The term of Dave Wilson, who was elected to the NRO NC in January 2007, ends on 31 December 2009. The election to the NRO NC seat will take place during a Plenary session at the RIPE 59 Meeting to be held in Lisbon, Portugal from 5-9 October 2009. All members of the Internet community who are present at the Plenary session may vote in the election. The deadline for nominations is 9 September 2009. Any individual residing within the RIPE NCC service region is eligible for nomination, except Regional Internet Registry (RIR) staff members. Self-nominations are permitted. Please send your nominations to <nominations(a)ripe.net> by 23:00 UTC on 9 September 2009. All confirmed nominations will be listed on the RIPE NCC website by 11 September 2009. All nominees may submit a written statement in support of their nomination for publication on the RIPE NCC website. Other individuals may express support for nominated individuals by sending an e-mail to <nominations(a)ripe.net>. Expressions of support will also be published on the RIPE NCC website. To find out more about the NRO NC and the election process, please see: http://www.ripe.net/info/resource-admin/nro2009/ Regards, Axel Pawlik Managing Director RIPE NCC

1 0

DRAFT: policy to allow smaller initial allocations (was: Re: [address-policy-wg] RE: Complaint: Overly complicated when requesting PI space)
by Remco van Mook 22 Jul '09

22 Jul '09

[resent after it got filtered] Dear all, So here goes. This is what I think that policy should look like. Any comments before I formally submit it? Best, Remco Number: (assigned by the RIPE NCC) Policy Proposal Name: Allow smaller initial allocations Author: name: Remco van Mook email: remco.vanmook(a)eu.equinix.com organisation: Equinix Proposal Version: 0.1 Submission Date: July 17, 2009 Suggested RIPE WG for discussion and publication: Address Policy Proposal Type: modify Policy Term: Permanent Summary of proposal: Allow new LIRs to get a smaller initial allocation than the standard at their specific request Policy text: Current (if modify): 5.1 First Allocation The RIPE NCC¹s minimum allocation size is /21. New: 5.1 First Allocation The RIPE NCC¹s minimum allocation size is /21. Consequently, the initial allocation size is /21. However, at the explicit request of the member, a smaller initial allocation up to a /24 can be made. In those cases, the RIPE NCC shall not make efforts to keep adjacent address space available for possible future allocation requests. Rationale: Arguments supporting the proposal Potential LIRs are currently forced to request PI space if they do not require a /21 of address space and want to contribute to the conservation of available global IPv4 resources. This policy change removes that obstacle and reduces the amount of requests for PI space for that purpose. The text looks a bit awkward because this is the only place where the minimum allocation size is specified and I wanted to keep that in - the minimum now being a general rule instead of a hard limit. Arguments opposing the proposal This policy change arguably increases fragmentation. On the other side, PI space assignments are made regardless of the minimum allocation size so the chances of actually increasing fragmentation are minimal. People do filtering based on minimum allocation sizes (I've not seen it in real life but that's the ever-returning argument) but that can be avoided using the ranges normally used for assigning PI for undersized allocations. On 17-07-09 14:02, "Sascha Lenz" <slz(a)baycix.de> wrote: > Hi, > > Remco van Mook schrieb: >> >> Hi Mark, >> >> It is heartening to see that your drive to conservation of IPv4 space >> alone is pushing you to put all this effort in to get PI space. I¹m sure >> we can suggest a policy change approved that would set the standard >> initial allocation to /21 but allow for smaller allocations up to /24 if >> specifically requested by the new LIR. > > [...] > > ... apart from the fact that i don't think the whole community agrees > that we need any form of IPv4 conservation anyways :-) ... i think this > would be the apropriate step here, yes. > > I would support a more "floating" (first) allocation policy, because > even that i think that we don't need to conserve IPv4 space too much, i > also don't think that we need to waste it either if there are other > simple options like what you suggest (smaller Allocation on request or so). > > > -- > ======================================================================== > = Sascha Lenz SLZ-RIPE slz(a)baycix.de = > = Network Design & Operations = > = BayCIX GmbH, Landshut * PGP public Key on demand * = > ======================================================================== > > ------ End of Forwarded Message This email is from Equinix Europe Limited or one of its associated/subsidiary companies. This email, and any files transmitted with it, contains information which is confidential, may be legally privileged and is solely for the use of the intended recipient. If you have received this email in error, please notify the sender and delete this email immediately. Equinix Europe Limited. Registered Office: Quadrant House, Floor 6, 17 Thomas More Street, Thomas More Square, London E1W 1YW. Registered in England and Wales No. 6293383.

7 10

Re: [address-policy-wg] Spectrum and IP address reservations
by tvest＠eyeconomics.com 22 Jul '09

22 Jul '09

On Jul 21, 2009, at 5:04 AM, Eliot Lear wrote: > Hi Tom, > >> Thanks for the response. I actually agree -- probably should have >> written that competition was never more than one of many reasons >> that someone (anyone) *might have* supported those earlier >> transitions. That said, if you look back at my original response >> you'll note that I was actually arguing *against* transition >> rationales based narrowly on "competition" questions. The >> alternative that I proposed was transition to preserve the >> "openness of the internet addressing and routing system," >> especially to new entrants. > > Sure! I particularly like the idea, for instance, of using LISP or > other similar technology to enable end systems to move within the > topology without having to pollute the global BGP table. But I do > feel a Hal Varien moment coming on: are incentives aligned for the > right things to happen? Hi Eliot, [note well: what follows represents personal opinion** only] Thanks for (re) injecting these questions. On the "Hal question," I interpret the current state of affairs as as a weak indicator that incentives are on balance (i.e., far from perfectly) aligned. That said, I would never have allowed myself to get stuck in this rather uncomfortable position if I believed that that balance of incentives were actually aligned toward a sustainable outcome. > If not, can they be so aligned? Our earlier work pointed out that > there is a limit to the efficacy of RIR policies. So what tools do > we really have? Incentive alignment might qualify as a "normal" engineering challenge under other circumstances. In this case the task is abnormally complicated by (a) the apparent absence of strong internal consensus** or other means of identifying the common goal, and also by (b) the absence of half of the engineering tool box (i.e., all carrots, no sticks -- and while our carrots may be very nutritious, no one has ever accused them of being irresistibly delicious). Ideally, our unique community decision making (aka consensus-seeking) mechanism would provide a means for overcoming these challenges, by providing a forum where contending views on both policy means and policy ends are exposed to cross-examination. However, in this case, I have a feeling** that only one side of the debate is actually being presented openly. If we were to take the decreasing frequency of open, public objections to IPv6 transition/integration as a de facto indication of support for such a move (which seems to be a common feature of the consensus-seeking process, at least toward the end stages of policy development), my guess is that we'd probably expect the transition to be much further long, and to be happening at a much faster, and at a more rapidly accelerating pace than available evidence would seem to suggest. So, am I just fundamentally wrong on some point of fact or interpretation, or it is possible that some unknown share of the apparently widespread non-objection (i.e., the proverbial "dogs that don't bark") actually reflect some (equally unknown) number of unannounced decisions in favor of non-transition? I don't even pretend to know the answer. But my doubts have prompted me to take what seems to be the most institutionally appropriate action -- to capitalize on the one good (and perhaps unique) "tool" that we do possess, i.e., to use our community deliberative mechanisms to try to present a positive case *for* a timely and orderly transition. Though I may be lacking in the skills required to wield them effectively, for now they remain the best (maybe only) tools that I have at my disposal. > Again, returning to the LISP example, it's a technology advance that > is a potential Over-The-Top play that could align interests (not > that I've done the analysis, but that's my off-the-cuff thought, > something to be wary about). I think that this possibility merits much more thorough and systematic consideration. My (quite possibly under-informed) impression is that widespread adoption of LISP might improve matters substantially in several ways, e.g., (1) by providing the majority of origin-only/self- service routing providers with an opportunity to economize by vacating the DFZ, (2) by reducing the likely ongoing demand for DFZ participation (and al that that implies in terms of RIB/FIB scalability) by permanently eliminating such participation as an involuntary requirement for self-service routing providers, and (3) by reducing the impediments to renumbering, which hypothetically might contribute to the absolute volume of transferable IPv4 resources available to aspiring new entrants in the post-IPv4 exhaustion era. If this is not too far off, then (assuming LISP succeeds on all of the above counts) I might still be curious about the (extent of the) dynamic aspects of LISP's scalability advantages (e.g., how much of the expected DFZ gains derive from the one-time payoff arising from the voluntarily exit of non-transit providers, and how much/ for how long would the remaining uncommitted DNZ capacity be likely to remain "open" to future new entrants?). Also, even if LISP ultimately succeeds in making 99% of current IPv4 assignments technically unnecessary, I would not expect that fact to automatically/inevitably or dramatically alter the "scarcity premium" that IPv4 will likely command in any future in which IPv4 remains non- substitutable for any critical industry functions or roles, and protocol resource numbers are (re)distributed exclusively through market mechanisms. Recall that back in the late 1990s, very few people actually new that 99+% of even the initial lit capacity across all of the segments of all of the recently deployed optical systems was completely idle. Prices didn't start to take their substantial (!) downward turn, and corresponding "productive capacity utilization" rates didn't start to really explode until the actual facts surrounding those supply condition were inadvertently revealed a few years later, in the course of a few unanticipated distressed asset sales, legal investigations, etc. In general I think that the assumption that there is any automatic or inevitable or guaranteed relationship of any meaningful and reliable kind between supply and demand has been largely discredited by history. Markets often work quite well, and (perhaps) well-designed and competently tended markets tend to work even more-better-more-often (?). But I think that the era when anyone can assume that the mere coincidence of some supply and some associated demand automatically guarantees the emergence of the best of possible worlds over any timeframe relevant to human beings has now passed into the history books. More specifically, in this context I think that the tendency to assume that market mechanisms would infallibly convert the fact/existence/ supply of additional loose (de-assignable, transferable, etc.) IPv4 into the enduring condition of greater openness to aspiring new entrants is based on the widespread (mis)perception of individual IPv4 addresses and prefixes as "things" (assets, commodities, etc.), when in fact they actually represent something more like discrete instances of a "generalized privilege" or "license" (as in "creative license" even more than "driver's license"). If/when future technology advances provide a /32 owner the same kind of "generalized privilege" that today is limited to those holding a /24 or more, then I would fully expect the "privilege adjusted" cost to remain constant, if not appreciate. As long as IPv4 remains non-substitutable for any critical and/or commercially attractive aspect of content or routing service provision, that "privilege adjusted" price is only likely to continue appreciating ad infinitum. >> I think that the majority of reasons for supporting the previous >> transitions (i.e., previous impositions of new technical >> requirements on incumbent network operators), as well as for >> supporting IPv6, would fit neatly under this rubric. And while your >> own description of the past circumstances didn't use those specific >> terms, I believe that the phenomena of "proliferation of class Cs >> being allocated" and "class Bs running out" that you referred to >> were both driven in part by demand from initial allocation seekers, >> a.k.a. "new entrants" -- i.e., we agree on this point. >> >> Of course, during any given duration the majority of newly >> allocated/assigned IP addresses are probably going to >> "incumbents" (subsequent allocation seekers), but that's consistent >> with patterns of growth in every other industry, i.e., it's >> basically a demographic of statistical artifact of cumulative >> growth processes (granted, one that can be influenced by various >> policies). The important distinction, at least until now, is that >> the growth/IP addressing demand of incumbents was not incompatible >> with the continued openness of the addressing and routing system to >> non-incumbents/new entrants. >> >> And of course, I wouldn't have expected these sorts of arguments to >> figure prominently in IETF et al. meetings and discussion back in >> the 1980s-1990s. In the main, we're not a bunch of economists and >> policy makers by profession -- and even those of us who are >> generally know better than to phrase our technology and policy >> advocacy in such alien and unsympathetic terms... most of us anyway. > > Well but as you know there were some discussions along these lines > in the CIDRD/BGPD working groups. However, there are limits as to > how far those discussions can reasonably go in that forum. Of course you are right. But as noted above, I know of no better options at the moment. > One thing I would draw your attention to was a paper in this year's > WEIS conference by Richard Clayton that contains an economic > analysis of SHIM6. His parting question from his presentation was > whether RFCs should contain Economics Considerations sections. This sounds very interesting, although I'm not sure that it would be easy (or even possible) to subject an Economics Considerations section to IETF-style quality and relevance-preserving mechanisms -- and I'm even more uncertain whether an Economics Considerations section that lacked such vetting processes would be likely to net out positive in terms of fog lifted, questions answered, etc. As the ongoing TV-MM dialogue should make abundantly clear, achieving consensus on economic fundamentals, or the validity of different methodologies, or the relative value of different knowledge bases or experiential inputs, etc. makes IETF or RIR decision making look like the ultimate paragons of both decorum and efficiency. That said, I do think it would be well worth exploring. >> However, even if "openness of the internet addressing and routing >> system" was never the most popular/resonant rallying cry for >> specific technology changes, that doesn't mean that this general >> idea wasn't an important motivator or an influential part of the >> unspoken context. And even if that sounds implausible too, it still >> doesn't mean that the *fact* that such openness was preserved, >> intentionally or otherwise, didn't play an important role in the >> success of the system to date. Although the verdict of history is >> never truly final, to me industry openness looks a lot like a >> universal correlate (i.e., a necessary if not sufficient cause) >> behind the durability of industry self-governance. If that turns >> out to be true, then there could be a lot more at stake in the >> current transition tussle than just the fate of the IP address >> registries. > > I don't think anyone can deny that openness was an important > motivator for Internet technologies. We merely need to look at all > of the OTHER protocols that have gone by the wayside to see that it > is so. But I think what we saw was that Opennness was something to > be capitalized upon by one group of vendors, to entice customers, > and to disrupt certain market players. It certainly was not > regulated. I agree entirely -- which is why I've been trying to articulate an *evolutionary* understanding of the relationship so far between industry self-governance and rapid Internet adoption, growth, and development. I have never claimed, nor do I subscribe to the view that an ongoing, conscious, active pursuit of openness as a top priority by industry direct stakeholders is responsible for the Internet's great success. Rather, I'm suggesting that the generally welcome but largely accidental/unintentional preservation of industry openness throughout previous system-wide technology transitions and continuous rapid growth probably represents a major (i.e., almost certainly necessary if not entirely sufficient) reason why this world-spanning critical infrastructure continues to be entrusted to (mostly civilian, mostly private sector) full-time technologists who occasionally take a few days off to serve as volunteer lay economists and policy makers. IMO**, those present at various critical moments accidentally succeeded -- perhaps with the occasional assistance of an unusual conjunction of "selective incentives and joint products" [[1]] -- in creating a very durable, relatively adaptable, effectively self- maintaining industry coordination mechanism. So far, those who came along thereafter seem to have done a reasonably good job of keeping it running, and headed in what seems to be a generally benign direction. (Needles to say, there's always room for improvement) I don't think that anyone has the power to recreate the kind of circumstances that give rise to this incredibly fortunate albeit accidental/unintentional evolutionary outcome. But one could argue that, for every system/organism or whatever that survives long enough, there inevitably comes a time when self-awareness coupled with the freedom to act replaces (or at least substantially complements) the blind mechanism of evolution in determining what happens next. Becoming aware (or being reminded) of the fact of evolution and its possible impacts will not relieve anyone of the important choices that will be made, one way or another, in the very near future. But I do believe that it might contribute (even if very marginally and indirectly) to better decisions. > And indeed if we look at security and authentication technology, the > desire to play King of the Mountain has IMHO long stalled > improvements in consumer authentication. Even though I'm not clear on the specific context, your frustration comes through loud and clear. I think that the quest to develop a perfectly open, self-encapsulated/externally unencumbered, and self- maintaining identification/reputation technology has been with us for a long time. Maybe when (if) we come up with one, it won't create any new complications that are equivalent to the current sources of frustration with external authority-based authentication systems (which have also been with us forever). I can already think of a couple of plausible candidates, but then that's my job -- even so, I always love surprises ;-) Regards, TV [personal opinion only] [[1]] The "joint products" model is an explanatory device that economists have used in some cases to describe how public goods like "industry openness" are sometimes produced more or less accidentally. It has been used, for example, to explain some historical episodes in which bankers in decentralized monetary systems -- basically countries where individual privately owned banks were at liberty to print their own currencies as they saw fit, which tended to be quite extremely volatile -- voluntarily adopted a standardized, national currency and "industry self-governance" model with some binding rules (e.g., capital reserve requirements, money printing restrictions) that implicitly limited their commercial freedom. The basic idea is that in some cases, the individual industry players themselves are confronted with some new opportunity to realize a substantial private benefit, but only if they cooperate in some specific way (e.g., in this case the adoption of a single national currency) that has the collateral effect producing some non-private "meta-good," like a national economy where individuals and businesses don't have to worry very much about whether their money will just stop working (i.e., their private/ nonstandard banknotes cease to be accepted by merchants), or their bank-deposited savings will suddenly disappear without warning.

1 0

Spectrum and IP address reservations
by Milton L Mueller 20 Jul '09

20 Jul '09

I forward information about a study conducted by NERA on spectrum auctions. Not directly applicable to IP addresses, but has some relevance to current discussions about attempts to reserve resources for new entrants vs. incumbents. Bear in mind, of course, that the study was produced by Telus, an incumbent operator, and discount for that; the point is that we need to pay attention to the economic reasoning underlying the finding; which is that policies designed to "help" competitors can have unintended consequences that may encourage conslidation and higher prices. ________________________________ Dear ITS Colleague, As you know, Industry Canada completed Canada’s advanced wireless services (AWS) spectrum auction in July 2008. A recent study that NERA conducted for the Canadian telecommunications company TELUS analyzed the auction, and found that it may have been distorted by the insertion of incompatible regulatory goals into the auction process. NERA’s analysis showed that while the auction generated higher revenues than expected, the most important reason for this was due to arbitrage opportunities in the auction design generated by the regulator’s decision to set-aside 44 percent of the available spectrum for “entrants” which, as defined, were as all qualified bidders except the three largest incumbent mobile operators. As evidenced in the UK 3G and other 3G auctions in the early 2000s, the resulting inflated spectrum prices can negatively affect competition as investors tend to sell their holdings when earnings decrease and/or debt ratings drop. In severe cases, it can lead to market exit or market consolidation, all of which has a direct effect on competition. Our report urges regulators to carefully balance the costs and benefits of regulatory intervention, and includes suggestions for avoiding the problems in future auctions that we identified in the Canadian case. The report is available for free upon request at: www.nera.com<http://www.nera.com> . [snip] _______________________________ Christian Dippon Vice President NERA Economic Consulting One Front Street, Suite 2600 San Francisco, CA 94111 Tel: 1-415-291-1044, Fax: 1-415-291-1020 Mobile: 415-810-9246 Christian.Dippon(a)NERA.com www.nera.com www.telecomeconomics.com _______________________________

1 0

The final /8 policy proposals, part 2
by Milton L Mueller 17 Jul '09

17 Jul '09

> -----Original Message----- > > I think it is important to think about new companies. They will very > probably require some IPv4 address space during the transition from > IPv4 to IPv6. I think the whole community will be in a lot of trouble > if we make a policy that makes it impossible for new entrants to > participate in a dual-stack world. > A legitimate concern. But: 1. address transfers might make it possible for them to acquire v4 addresses 2. by "new companies" do you mean "companies with no prior allocations" or literally just "new companies." The two categories overlap but are not the same. If you create a category of [new/no prior assignments] companies and the address shortage becomes severe, can you foresee ways of gaming that definition to acquire privileged access to addresses? e.g., can an incumbent ISP create a wholly-owned subsidiary (which might in fact be a legitimate "new entrant" into a market by some economically-relevant definitions) and qualify as a "new company"?

19 56

Complaint: Overly complicated when requesting PI space
by Jeroen Wunnink 17 Jul '09

17 Jul '09

Hello Members, I'd like to state a complaint toward overly complicated issues with requesting PI space as a LIR for a customer. Situation: I have a customer who's purchased a router and wants his own IP space+AS number to start multihoming. Since he's pretty new to routing and policies of RIPE and managing the database to keep things going, we as LIR offered him to do this for him at the startup phase. Currently he'll be hosting several services from within our PA ranges and will start growing his new resources in the PI space he wants. After filling in the request forms, his AS got approved pending the PI /24 range assignment. And that's been a process that's currently becoming something ridiculous. Initially I got some return questions on how the subnets would be sliced up, what would be used for management of the routers, if IP's are being assigned statically or dynamically, how much IP's a customer would use and if PA space is being returned. Questions (except for the 'how much IP's will a customer use') I can understand and all answered. Then in a follow-up I got asked what the montly growth is, who's administratively responsible for the IP's and how they're going to be used on the servers. Then in a next follow up I got pointed to using PA space either from us or a different provider or that the customer should become LIR himself since we as LIR cannot sub-allocate PI space. (something that's not intended in the first place at all, we just administer it on a contract base until he understands procedures) And then after explaining that we will only help the customer on contract base and not sub-allocate anything, another follow-up comes that no customer can use more then 1 or 2 IP's and once again a question on how many servers are involved here. And that's where I'm at now. I've been trying to request PI space for our customer since last friday, and in my opinion there's too much meddling into internal business by RIPE here and this is taking a ridiculous amount of time and communication. As a LIR we hand out IP space responsibly to our customers, for a good technical and administrative reason we have a customer who wants his own PI assignment and I'm asking him questions about his business that lean towards a company secret. In my opinion RIPE has absolutely no business in asking how many customers and/or servers someone has and stating that a customer can not use >2 IP's in that PI space (what if someone has *gasp* 3 SSL websites ?, I cannot imagine that happening.., ever). Also neither we or our customer has a crystal ball to see in the future, so sure I can tell the amount of customer growth I'll be expecting or HOPING to see, but come on. I know IPv4 space must be handed out responsibly, but this is seriously going too far, especially for a LIR. Supposedly I cannot give a routing-reason for requesting PI space, but part of that IS important on why I'm requesting it. It's really not desirable for us AND for my customer to chop out a part of my PA space and announce in smaller chunks from his own AS on the same exchange points we're on and this customer is NOT at the stage yet to become a full LIR himself. -- Met vriendelijke groet, Jeroen Wunnink, EasyHosting B.V. Systeembeheerder systeembeheer(a)easyhosting.nl telefoon:+31 (035) 6285455 Postbus 48 fax: +31 (035) 6838242 3755 ZG Eemnes http://www.easyhosting.nl http://www.easycolocate.nl

13 20

2009-07 Moved to Review Phase (Internet Assigned Numbers Authority (IANA) Policy for Allocation of ASN Blocks (ASNs) to Regional Internet Registries)
by Filiz Yilmaz 16 Jul '09

16 Jul '09

PDP Number: 2009-07 Internet Assigned Numbers Authority (IANA) Policy for Allocation of ASN Blocks (ASNs) to Regional Internet Registries Dear Colleagues, We have published a draft document for the proposal described in 2009-07 as well as the impact analysis that was conducted for this proposal. You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2009-07.html and the draft document at: http://www.ripe.net/ripe/draft-documents/ripe-416-draft-2009-07.html We encourage you to read the draft document text and send any comments to address-policy-wg(a)ripe.net before 13 August 2009. Regards, Filiz Yilmaz Policy Development Manager RIPE NCC

1 0

PA Assignment questions
by Nolan, Keith 16 Jul '09

16 Jul '09

Address Policy Working Group, I'm working for a company who decided to become a LIR as we have a requirement for Large amounts of IP Space. We are not assigning IP Space to our customers as all the IP Space is used for our own infrastructure. We have been provided with a PA Allocation, however we are having issues getting PA Assignments approved by RIPE NCC. We applied for PA Assignments in /24 blocks so that we could multi-home using BGP from all of our production sites and some of our more critical offices These sites don't have a shared Network connecting them (except for the Internet) We are using the "allowas-in" command so that we don't need an AS Number from each non-connected site. (As the RIPE NCC wouldn't approve our application for multiple AS Numbers) The request of PA Assignments is getting rejected because 1. We can't aggregate the IP Space (RIPE NCC wants us to advertise our entire PA Space and not break it into smaller networks as we require) 2. The IP Space required in some of the sites is less than a /24 (However we need /24 networks as our Transit providers filter IP Space smaller than /24) The suggestion from RIPE NCC was to apply for smaller Assignments from the PA Space and to take each of them from a separate /24 range, and to create a /24 route object for each separate /24 Space, or to apply for PI Space for each location as PI Space was more in-line with what we are trying to achieve. While this will work, I have an issue with RIPE NCC providing a work around, and I believe the policy should allow for a LIR to use the PA Allocation in the best manner to conserve IP Space and to not have "Available" networks in PA Space which can never be assigned and to not waste PI space by not allowing a LIR use the Allocated PA Space for its own Infrastructure. Thanks Keith Keith Nolan Director of Network and IT Operations, EMEA Premiere Global Services Tel: +353 (0) 23 88 32103 Mob: +353 (0) 86 919 8149 Fax: +353 (0) 23 88 36101

3 5

Anycasting Assignments for TLDs and Tier 0/1 ENUM Implemented
by Scott Donald 16 Jul '09

16 Jul '09

[Apologies for duplicates] Dear Colleagues, We are pleased to announce that the RIPE NCC has implemented the accepted policy proposal 2008-05, "Anycasting Assignments for TLDs and Tier 0/1 ENUM". This allows Tier 0/1 ENUM operators to receive IPv4 and IPv6 anycasting assignments and increases the number of anycasting prefixes that can be assigned to an operator from one to a maximum of four assignments. The request form and supporting notes are available from the RIPE Document Store at: http://www.ripe.net/ripe/docs/requestforms.html If you have any questions regarding this, please contact <ncc(a)ripe.net>. Regards, Scott Donald Registration Services, RIPE NCC

1 0

IPv6 Deployment Monitoring Survey Closed
by Paul Rendek 15 Jul '09

15 Jul '09

[Apologies for duplicates] Dear Colleagues, The IPv6 Deployment Monitoring Survey, conducted by TNO and GNKS Consult in cooperation with the RIPE NCC and sponsored by the European Commission, has now closed. More than 600 members of the RIPE community responded to the survey, which aims to collect data on the current and future use of IPv6 throughout the RIPE NCC service region. We wish to thank those from the community who took the time to complete the survey. The results of the IPv6 Deployment Monitoring Survey will be presented and discussed at RIPE 59 which takes place in Lisbon, Portugal from 5-9 October. More information and registration details are available at: http://ripe59.ripe.net/ The results of this survey will also be published on IPv6 Act Now website at: http://www.ipv6actnow.org If you have any questions about the survey or the results, please contact <ncc(a)ripe.net>. Regards, Paul Rendek Head of External Relations and Communications RIPE NCC

1 0

The final /8 policy proposals, part 2
by Sander Steffann 15 Jul '09

15 Jul '09

Hello WG, I want to continue the discussion about the Final /8 proposals (2008-06 and 2009-04). The responses to my last question ("Do we (this working group) want to put IPv6 related requirements in the policy?") were 100% negative: We don't want IPv6 related requirements in the Final /8 policy. The next question is about the amount of addresses someone can get from the Final /8. I think we have a number of options here: a) Everyone gets one (and only one) fixed size block, as described in 2008-06 b) All requests are downscaled by a certain factor, as described in 2009-04 c) We place a limit on the amount of addresses that can be requested per time slot (year?) I think it is important to think about new companies. They will very probably require some IPv4 address space during the transition from IPv4 to IPv6. I think the whole community will be in a lot of trouble if we make a policy that makes it impossible for new entrants to participate in a dual-stack world. Once we have discussed this basic issue I'll steer the discussion back to the other differences between the proposals. Please keep the discussion on this topic for now. Thank you, Sander Steffann APWG co-chair

20 37

IPv6 Deployment Monitoring Survey: Deadline Extended!
by Paul Rendek 06 Jul '09

06 Jul '09

[Apologies for duplicates] Dear Colleagues, The deadline for responding to the IPv6 Deployment Monitoring Survey has been extended to Friday, 10 July 2009. This survey is being conducted by TNO and GNKS Consult, working with the RIPE NCC and sponsored by the European Commission. The aim is to collect data on the current and future use of IPv6 throughout the RIPE NCC service region, and all members of the RIPE community are encouraged to participate. You can access the survey at: http://is-nri.com/take/?i=150597&h=1GwWe3dXXMcPrRrOw5s2yg The survey is composed of 16 questions and can be completed in 10-15 minutes. Results will be presented and discussed at RIPE 59 and published on IPv6 Act Now: http://ipv6actnow.org Please note that all data will be kept confidential at all times, and will only be disclosed on an aggregated level. For more information on the IPv6 Deployment Monitoring Survey, please see: http://www.ripe.net/news/ipv6-deployment-monitoring-survey.html We appreciate your time and interest in completing this survey. If you have any questions concerning the survey, please send an email to <info(a)gnksconsult.com>. Regards, Paul Rendek Head of External Relations and Communications RIPE NCC

1 0

[#KKA-100534]: Re: [address-policy-wg] The final /8 policy proposals, part 2
by Stream Service 06 Jul '09

06 Jul '09

Florian Weimer, Uw ticket is ontvangen en een medewerker zal het ticket bekijken en beantwoorden. Hieronder staan de details van dit ticket. Zorg er a.u.b. voor dat het Ticket ID altijd in het onderwerp van deze email blijft staan. Ticket ID: KKA-100534 Onderwerp:Re: [address-policy-wg] The final /8 policy proposals, part 2 Department: Stream Service (Algemeen) Priority: Low Status: Open U kunt hier klikken om de status van ons antwoord op het Ticket online te bekijken.http://support.streamservice.nl/index.php?_m=tickets&_a=viewticket&ticketid=17057 Wij horen het graag als we u nog ergens anders mee van dienst kunnen zijn, Stream Service (Algemeen) info(a)streamservice.nl Tel : +31 (0)53-7112711 Fax : +31 (0)53-7112716 Stream Service is een handelsnaam van SinnerG BV

1 0

[#MLT-583232]: RE: [address-policy-wg] The final /8 policy proposals, part 2
by Stream Service 05 Jul '09

05 Jul '09

David Freedman, Uw ticket is ontvangen en een medewerker zal het ticket bekijken en beantwoorden. Hieronder staan de details van dit ticket. Zorg er a.u.b. voor dat het Ticket ID altijd in het onderwerp van deze email blijft staan. Ticket ID: MLT-583232 Onderwerp:RE: [address-policy-wg] The final /8 policy proposals, part 2 Department: Stream Service (Algemeen) Priority: Low Status: Open U kunt hier klikken om de status van ons antwoord op het Ticket online te bekijken.http://support.streamservice.nl/index.php?_m=tickets&_a=viewticket&ticketid=17027 Wij horen het graag als we u nog ergens anders mee van dienst kunnen zijn, Stream Service (Algemeen) info(a)streamservice.nl Tel : +31 (0)53-7112711 Fax : +31 (0)53-7112716 Stream Service is een handelsnaam van SinnerG BV

1 0

IPv6 Deployment Monitoring Survey Reminder
by Paul Rendek 30 Jun '09

30 Jun '09

[Apologies for duplicates] Dear Colleagues, This is a reminder that the IPv6 Deployment Monitoring Survey is online, and we encourage all members of the RIPE community to participate. The final date for submitting a response is Friday, 3 July 2009. You can access the survey at: http://is-nri.com/take/?i=150597&h=1GwWe3dXXMcPrRrOw5s2yg The survey is being conducted by TNO and GNKS Consult, working with the RIPE NCC and sponsored by the European Commission. The aim of the survey is to collect data on the current and future use of IPv6 throughout the RIPE NCC service region. The survey is composed of 16 questions and can be completed in 10-15 minutes. Results will be presented and discussed at RIPE 59 and published on IPv6 Act Now: http://ipv6actnow.org For more information on the IPv6 Deployment Monitoring Survey, please see: http://www.ripe.net/news/ipv6-deployment-monitoring-survey.html We appreciate your time and interest in completing this survey. If you have any questions concerning the survey, please send an email to <info(a)gnksconsult.com >. Regards, Paul Rendek Head of External Relations and Communications RIPE NCC

1 0