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

Re: address-policy-wg digest, Vol 1 #892 - 8 msgs
by Arun Kaushik 11 Dec '08

11 Dec '08

2008/12/11 <address-policy-wg-request(a)ripe.net> > Send address-policy-wg mailing list submissions to > address-policy-wg(a)ripe.net > > To subscribe or unsubscribe via the World Wide Web, visit > http://www.ripe.net/mailman/listinfo/address-policy-wg > or, via email, send a message with subject or body 'help' to > address-policy-wg-request(a)ripe.net > > You can reach the person managing the list at > address-policy-wg-admin(a)ripe.net > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of address-policy-wg digest..." > > > Today's Topics: > > 1. Re: IPv6 assignment for the RIPE meetingnetwork (John L. Crain) > 2. 2008-05 Revised/New Discussion Phase set (Anycasting Assignments for > TLD's and Tier 0/1 ENUM) (Antoin Verschuren) > 3. Re: 2008-05 Revised/New Discussion Phase set > (Anycasting Assignments for TLD's and Tier 0/1 ENUM) (Leo Vegoda) > 4. New paper on RIRs by Internet Governance Project (Milton L Mueller) > 5. DRAFT: allocating resources to the RIPE NCC (Remco van Mook) > 6. Re: 2008-05 Revised/New Discussion Phase set > (Anycasting Assignments for TLD's and Tier 0/1 ENUM) (Jeffrey A. > Williams) > > --__--__-- > > Message: 1 > From: "John L. Crain" <john.crain(a)icann.org> > To: Sander Steffann <sander(a)steffann.nl>, Shane Kerr > <shane(a)time-travellers.org> > CC: "address-policy-wg(a)ripe.net" <address-policy-wg(a)ripe.net> > Date: Tue, 9 Dec 2008 09:58:16 -0800 > Subject: Re: [address-policy-wg] IPv6 assignment for the RIPE > meetingnetwork > > Hi folks, > > One other way that this could be handled is to ask one of the other RIRs to > assess the resource request. I'm trying to remember how we did this in the > past with IPv4, am sure Daniel remembers, but I think we asked IANA to > chec= > k > the assignment. Any of the other RIRs will have Hostmasters or Resource > Analysts that are highly familiar with the RIPE area policies. > > I would advise against making anything more cumbersome than it needs to be. > Am sure the other RIRs have the same issue and a simple policy of review by > another RIR would solve the issue for all. > > John > > On 08/12/2008 05:21, "Sander Steffann" <sander(a)steffann.nl> wrote: > > > Hello Shane, > >> I'd just like to mention as a tiny historical note, that the RIPE NCC > >> was founded in part to organise RIPE meetings. > >> > >> Look at 3.3 of the first RIPE NCC Activity Plan: > >> > >> ftp://ftp.ripe.net/ripe/docs/ripe-035.txt > >> > > Thank you for the reference. > >> The conflict of interest having the RIPE NCC evaluate it's own request > f= > or > >> resources is real, but I think we must all admit totally symbolic. We're > >> talking about very small blocks here, so seriously considering the idea > = > of > >> incorporating a new company to fill out some paperwork makes me wonder > i= > f I'm > >> about to see a rabbit with a stopwatch running past > >> declaring "I'm late, I'm late!". (*) > > :-) > > > > All the paperwork needs to be correct though, so we need an official way > > to give the NCC resources. Remco van Mook suggested a solution > > ( > http://www.ripe.net/ripe/maillists/archives/address-policy-wg/2008/msg00= > 745.h > > tml) > > and offered to try to write a formal policy proposal > > ( > http://www.ripe.net/ripe/maillists/archives/address-policy-wg/2008/msg00= > 823.h > > tml). > > > > I think this is the best way forward and we should give Remco some time > > to work on that policy proposal. > > Sander > > > > > --__--__-- > > Message: 2 > Subject: [address-policy-wg] 2008-05 Revised/New Discussion Phase set > (Anycasting Assignments for TLD's and Tier 0/1 ENUM) > Date: Wed, 10 Dec 2008 12:21:40 +0100 > From: "Antoin Verschuren" <Antoin.Verschuren(a)sidn.nl> > To: <address-policy-wg(a)ripe.net> > > PDP Number: 2008-05 > Anycasting Assignments for TLD's and Tier 0/1 ENUM > > While I strongly support the proposal for more than 1 anycast assignment > per TLD/ENUM tier1 operator, I do have some problems with the definition > of the ENUM tier1 operators. > > Where it says: > > "ENUM operators as defined by the ITU" > > I think it should say: > > "ENUM tier0/1 operators as defined by RIPE NCC" > > I wouldn't want the ITU to determine who should get address space, and > the counterpart for IANA in the ENUM space is RIPE NCC. > I see the ITU more in the role ICANN has with regards to TLD's, or > perhaps even the US DOC. > > Antoin Verschuren > > Technical Policy Advisor > SIDN > Utrechtseweg 310 > PO Box 5022 > 6802 EA Arnhem > The Netherlands > > T +31 26 3525500 > F +31 26 3525505 > M +31 6 23368970 > E antoin.verschuren(a)sidn.nl > W http://www.sidn.nl/ > > > > --__--__-- > > Message: 3 > From: Leo Vegoda <leo.vegoda(a)icann.org> > To: "address-policy-wg(a)ripe.net" <address-policy-wg(a)ripe.net> > Date: Wed, 10 Dec 2008 06:08:42 -0800 > Subject: Re: [address-policy-wg] 2008-05 Revised/New Discussion Phase set > (Anycasting Assignments for TLD's and Tier 0/1 ENUM) > > Hi, > > I'm happy to see the removal of an external reference in this policy > proposal. The current policy refers to the 'IANA Administrative Procedure > for Root Zone Name Server Delegation and Glue Data'. It's possible that a > change to that document could have a knock-on effect on RIPE policy. As > such, I'm glad to see a change to self-contained policy. > > Regards, > > Leo Vegoda > > > --__--__-- > > Message: 4 > Date: Wed, 10 Dec 2008 10:13:18 -0500 > From: Milton L Mueller <mueller(a)syr.edu> > To: <address-policy-wg(a)ripe.net> > Subject: [address-policy-wg] New paper on RIRs by Internet Governance > Project > > ------_=_NextPart_001_01C95AD9.D45EE8D6 > Content-Type: text/plain; charset="US-ASCII" > Content-Transfer-Encoding: quoted-printable > > Regional Address Registries, Governance and Internet Freedom > > =20 > > Abstract: Regional Internet Address Registries (RIRs) are private, > nonprofit and transnational governance entities that evolved organically > with the growth of the Internet to manage and coordinate Internet > Protocol addresses. The RIR's management of Internet address resources > is becoming more contentious and more central to global debates over > Internet governance. This is happening because of two transformational > problems: 1) the depletion of the IPv4 address space; and 2) the attempt > to introduce more security into the Internet routing system. We call > these problems "transformational" because they raise the stakes of the > RIR's policy decisions, make RIR processes more formal and > institutionalized, and have the potential to create new, more > centralized control mechanisms over Internet service providers and > users. A danger in this transition is that the higher stakes and > centralized control mechanisms become magnets for political contention, > just as ICANN's control of the DNS root did. In order to avoid a repeat > of the problems of ICANN, we need to think carefully about the > relationship between RIRs, governments, and Internet freedom. In > particular, we need to shield RIRs from interference by national > governments, and strengthen and institutionalize their status as neutral > technical coordinators with limited influence over other areas of > Internet governance. > > =20 > > Download: http://internetgovernance.org/pdf/RIRs-IGP-hyderabad.pdf=20 > > =20 > > > ------_=_NextPart_001_01C95AD9.D45EE8D6 > Content-Type: text/html; charset="US-ASCII" > Content-Transfer-Encoding: quoted-printable > > <html xmlns:o=3D"urn:schemas-microsoft-com:office:office" = > xmlns:w=3D"urn:schemas-microsoft-com:office:word" = > xmlns=3D"http://www.w3.org/TR/REC-html40"> > > <head> > <META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; = > charset=3Dus-ascii"> > <meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)"> > <style> >  > </style> > > </head> > > <body lang=3DEN-US link=3Dblue vlink=3Dpurple> > > <div class=3DSection1> > > face=3D"Times New Roman">Regional = > Address > Registries, Governance and Internet Freedom<o:p></o:p> > > style=3D'font-size: > 10.0pt'><o:p> </o:p> > > face=3D"Times New Roman"> style=3D'font-size:11.0pt;font-weight:bold; > font-style:italic'>Abstract: size=3D2> style=3D'font-size:11.0pt;font-style:italic'>Regional Internet Address = > Registries > (RIRs) are private, nonprofit and transnational governance entities that > evolved organically with the growth of the Internet to manage and = > coordinate > Internet Protocol addresses. The RIR’s management of Internet = > address > resources is becoming more contentious and more central to global = > debates over > Internet governance. This is happening because of two transformational > problems: 1) the depletion of the IPv4 address space; and 2) the attempt = > to > introduce more security into the Internet routing system. We call these > problems “transformational” because they raise the stakes of = > the > RIR’s policy decisions, make RIR processes more formal and > institutionalized, and have the potential to create new, more = > centralized > control mechanisms over Internet service providers and users. A danger = > in this > transition is that the higher stakes and centralized control mechanisms = > become > magnets for political contention, just as ICANN’s control of the = > DNS root > did. In order to avoid a repeat of the problems of ICANN, we need to = > think > carefully about the relationship between RIRs, governments, and Internet > freedom. In particular, we need to shield RIRs from interference by = > national > governments, and strengthen and institutionalize their status as neutral > technical coordinators with limited influence over other areas of = > Internet > governance.<o:p></o:p> > > face=3D"Times New Roman"> style=3D'font-size:11.0pt;font-style:italic'><o:p> </o:p></fo= > nt> > > face=3D"Times New Roman">Download: <a > href=3D"http://internetgovernance.org/pdf/RIRs-IGP-hyderabad.pdf">http://= > internetgovernance.org/pdf/RIRs-IGP-hyderabad.pdf</a> > <o:p></o:p> > > face=3D"Times New Roman"> style=3D'font-size:10.0pt'><o:p> </o:p> > > </div> > > </body> > > </html> > > ------_=_NextPart_001_01C95AD9.D45EE8D6-- > > > --__--__-- > > Message: 5 > Date: Wed, 10 Dec 2008 21:05:43 +0100 > From: "Remco van Mook" <Remco.vanMook(a)eu.equinix.com> > To: <address-policy-wg(a)ripe.net> > Subject: [address-policy-wg] DRAFT: allocating resources to the RIPE NCC > > Dear all, > > Please find below my first attempt at a policy for allocating resources > to the NCC. I think it should be a separate ripe document. Please let me > know what you think and where it needs some more polishing. I want to > publish the formal proposal soon, so the policy can potentially be > adopted well in time for the next RIPE meeting.=20 > > Best, > > Remco > > > Number: (assigned by the RIPE NCC) > Policy Proposal Name: Allocating resources to the RIPE NCC=09=20 > Author:=20 > name: Remco van Mook > email: remco(a)eu.equinix.com > organisation: Equinix > > Proposal Version: 1.0 > > Submission Date: TBD > =09=20 > Suggested RIPE WG for discussion and publication: address policy > =09=20 > Proposal Type: new > > Policy Term: permanent > =09 > Summary of proposal:=20 > This proposal sets the way in which the RIPE NCC can get resources > allocated to itself.=09=20 > > Policy text:=20=09 > Current (if modify): > none > > New: > > Abstract: > This document describes how the RIPE NCC can get resources allocated to > itself. > > 1.0 Introduction > The RIPE NCC is an independent association and serves as one of five > Regional Internet Registries (RIRs). Its service region incorporates > Europe, the Middle East, and Central Asia. The RIPE NCC is responsible > for the allocation and assignment of Internet Protocol (IP) address > space, Autonomous System Numbers (ASNs) and the management of reverse > domain names within this region.=20 > > 1.1 Scope > This document describes the policy for allocating resources to the RIPE > NCC. This policy applies to all resources, current and future, allocated > to the RIPE NCC, its subsidiaries or affiliates. This document does not > describe any specific resource or a policy restricted to a specific > resource; it does however impact how the resource-specific policies > should be interpreted when applied to the RIPE NCC as the entity > requesting resources. This document does not describe or impact any > policy where it is applied to regular LIRs. > > 2.0 RIPE NCC as a resource-holder > Any resources allocated to the RIPE NCC will be registered in the RIPE > database under the LIR identity of 'eu.ripencc'. All policies set for > allocating resources to LIRs apply equally to the RIPE NCC. RIPE NCC as > a resource holder should fulfill the same basic requirements that are > also expected of normal LIRs, such as returning unused resources. Since > the RIPE NCC cannot sign a contract with itself, the requirement for an > explicit contract as set by various policies does not apply for this > particular case. While the RIPE NCC will still handle the administrative > tasks involved with allocating resources itself, it will not evaluate > the validity of their own requests.=20 > > 3.0 Pool of Arbiters > Defined in ripe-174, the pool of Arbiters has been appointed by the RIPE > NCC Executive Committee (and approved by the AGM). The arbiters function > is to mediate in a conflict between the RIPE NCC and one of its members. > In addition to executing the RIPE NCC Conflict Arbitration Procedure, > the pool of arbiters will also evaluate the validity of all requests for > resources made by the RIPE NCC.=20 > > 4.0 Evaluating a request > The evaluation of an allocation request made by the RIPE NCC will be > done by a team of at least 3 of the arbiters. The arbiters will respond > to any new request within one month. For the purpose of evaluating, the > request will be treated as if it was filed by a normal LIR. If the > request is approved, the resources will then be allocated by the RIPE > NCC and registered in the RIPE database. > > 5.0 Conflict resolution > Should the pool of arbiters reject a request, or if the request cannot > be granted by applying the standard LIR policies, the RIPE NCC can file > a request to the RIPE plenary meeting to have its case heard. It is then > up to the RIPE plenary to decide whether the request should be granted > or not. At no point can the RIPE NCC allocate resources to itself > without prior consent of either the pool of arbiters or the RIPE > plenary. > > > > Rationale: > All resource-holders in the RIPE NCC service area are now being required > to have a contractual relationship with the RIPE NCC, directly or > indirectly. There is however one entity that cannot sign a contract with > the RIPE NCC - the NCC itself. This policy cleans up the current variety > in which the NCC has allocated resources to itself and sets a standard > way for the RIPE NCC to get further resources allocated. For all means > and purposes the RIPE NCC will be treated as a LIR and will follow the > same policies as a LIR; however the role the RIPE NCC has in analysing > and evaluating any request by an LIR is instead done by members of the > pool of arbiters. > > Arguments supporting the proposal > Currently there is no standard way for the RIPE NCC to get resources > allocated. This has so far led to an inconsistent picture between the > various resource types; a lot of ad hoc policies and exemptions. This > needs to be cleaned up. One way to look at it is that every single > resource allocated to the RIPE NCC is a conflict of interest between the > RIPE NCC and ALL of its members. Therefore it makes sense that the same > people who arbitrate conflicts between RIPE NCC and its members evaluate > the requests for resources as filed by the RIPE NCC. > > > Arguments opposing the proposal=20 > None. > > > This email is from Equinix Europe Limited or one of its > associated/subsidia= > ry companies. This email, and any files transmitted with it, contains > infor= > mation which is confidential, may be legally privileged and is solely for > t= > he use of the intended recipient. If you have received this email in > error,= > please notify the sender and delete this email immediately. Equinix > Europ= > e Limited. Registered Office: Quadrant House, Floor 6, 17 Thomas More > Stree= > t, Thomas More Square, London E1W 1YW. Registered in England and Wales No. > = > 6293383. > > > --__--__-- > > Message: 6 > Date: Tue, 09 Dec 2008 20:10:11 -0800 > From: "Jeffrey A. Williams" <jwkckid1(a)ix.netcom.com> > Organization: IDNS and Spokesman for INEGroup > To: Antoin Verschuren <Antoin.Verschuren(a)sidn.nl> > CC: address-policy-wg(a)ripe.net > Subject: Re: [address-policy-wg] 2008-05 Revised/New Discussion Phase set > (Anycasting Assignments for TLD's and Tier 0/1 ENUM) > > Antoin and all, > > Good point. I certainly wouldn't want the ITU doing so either. > But you know that there are some that are yet again pushing > the ITU as having some sort of authority, however defined, to > make such determinations... > > Antoin Verschuren wrote: > > > PDP Number: 2008-05 > > Anycasting Assignments for TLD's and Tier 0/1 ENUM > > > > While I strongly support the proposal for more than 1 anycast assignment > > per TLD/ENUM tier1 operator, I do have some problems with the definition > > of the ENUM tier1 operators. > > > > Where it says: > > > > "ENUM operators as defined by the ITU" > > > > I think it should say: > > > > "ENUM tier0/1 operators as defined by RIPE NCC" > > > > I wouldn't want the ITU to determine who should get address space, and > > the counterpart for IANA in the ENUM space is RIPE NCC. > > I see the ITU more in the role ICANN has with regards to TLD's, or > > perhaps even the US DOC. > > > > Antoin Verschuren > > > > Technical Policy Advisor > > SIDN > > Utrechtseweg 310 > > PO Box 5022 > > 6802 EA Arnhem > > The Netherlands > > > > T +31 26 3525500 > > F +31 26 3525505 > > M +31 6 23368970 > > E antoin.verschuren(a)sidn.nl > > W http://www.sidn.nl/ > > Regards, > > Spokesman for INEGroup LLA. - (Over 284k members/stakeholders strong!) > "Obedience of the law is the greatest freedom" - > Abraham Lincoln > "YES WE CAN!" Barack ( Berry ) Obama > > "Credit should go with the performance of duty and not with what is > very often the accident of glory" - Theodore Roosevelt > > "If the probability be called P; the injury, L; and the burden, B; > liability depends upon whether B is less than L multiplied by > P: i.e., whether B is less than PL." > United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] > =============================================================== > Updated 1/26/04 > CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. > div. of Information Network Eng. INEG. INC. > ABA member in good standing member ID 01257402 E-Mail > jwkckid1(a)ix.netcom.com > My Phone: 214-244-4827 > > > > > End of address-policy-wg Digest > -- Thanks & Regards, Arun Kaushik.

1 0

New paper on RIRs by Internet Governance Project
by Milton L Mueller 10 Dec '08

10 Dec '08

Regional Address Registries, Governance and Internet Freedom Abstract: Regional Internet Address Registries (RIRs) are private, nonprofit and transnational governance entities that evolved organically with the growth of the Internet to manage and coordinate Internet Protocol addresses. The RIR's management of Internet address resources is becoming more contentious and more central to global debates over Internet governance. This is happening because of two transformational problems: 1) the depletion of the IPv4 address space; and 2) the attempt to introduce more security into the Internet routing system. We call these problems "transformational" because they raise the stakes of the RIR's policy decisions, make RIR processes more formal and institutionalized, and have the potential to create new, more centralized control mechanisms over Internet service providers and users. A danger in this transition is that the higher stakes and centralized control mechanisms become magnets for political contention, just as ICANN's control of the DNS root did. In order to avoid a repeat of the problems of ICANN, we need to think carefully about the relationship between RIRs, governments, and Internet freedom. In particular, we need to shield RIRs from interference by national governments, and strengthen and institutionalize their status as neutral technical coordinators with limited influence over other areas of Internet governance. Download: http://internetgovernance.org/pdf/RIRs-IGP-hyderabad.pdf

1 0

2008-05 Revised/New Discussion Phase set (Anycasting Assignments for TLD's and Tier 0/1 ENUM)
by Ana Matic 10 Dec '08

10 Dec '08

PDP Number: 2008-05 Anycasting Assignments for TLD's and Tier 0/1 ENUM Dear Colleagues, The text of the policy proposal 2008-05 has been revised based on the community feedback received on the mailing list and during RIPE 57. We have published the new version (version 2) today. As a result a new Discussion Phase is set for the proposal. You can find the full proposal at: http://ripe.net/ripe/policies/proposals/2008-05.html We encourage you to review this policy proposal and send your comments to <address-policy-wg(a)ripe.net> before 5 January 2009. Regards, Ana Matic RIPE NCC Asst. Policy Development Officer

3 2

Re: [address-policy-wg] IPv6 assignment for the RIPE meetingnetwork
by Elisa Jasinska 09 Dec '08

09 Dec '08

I can only second Niels here. While organizing conferences and events with network infrastructure myself, I can tell that it is a hassle to re-arrange temporary PI every time... so I do see the incentive. But why should the NCC be a special case and no one else? Cheers, Elisa -- Elisa Jasinska - AMS-IX NOC http://www.ams-ix.net/

25 49

IPv6 assignment for the RIPE meeting network
by Andrei Robachevsky 06 Dec '08

06 Dec '08

Dear Colleagues, This is an informal submission of the proposal that was presented at RIPE 57 in Dubai (http://www.ripe.net/ripe/meetings/ripe-57/presentations/Robachevsky-IPv6_as…), as was suggested by the community. Your feedback is appreciated as well as your opinion whether a formal submission should follow. Regards, Andrei Robachevsky RIPE NCC IPv6 address space assignment for RIPE Meetings --------------------------------------- A dedicated IPv6 prefix is assigned to the organisation that organises the RIPE Meetings. The size of this prefix is a /48 and the assignment will be valid as long as the organisation is responsible for organising the RIPE Meetings and the usage of the prefix is limited to RIPE Meeting networks. The status of this assignment will be 'ASSIGNED MEETING’ in the RIPE Database and must be returned to the RIPE NCC if not in use for RIPE Meeting networks. Rationale: -------- a. Arguments supporting the proposal RIPE NCC has been organising RIPE Meetings for over a decade now and it is still responsible for the setup of the meeting network. As IPv6 deployment has became more of a necessity, the RIPE NCC has been providing IPv6 network during RIPE Meetings too. Although first couple of setups were more at an experimental level, currently we offer this as a production-grade service to the attendees. The IPv6 space for these networks so far has been provided by some other organisations and so the assignments were in temporary nature. We appreciate the support these organisations have provided so far. Today a permanent IPv6 prefix is a necessity to be able to provide a stable and high quality service during RIPE Meetings. Having such a permanent and dedicated prefix, the RIPE Meeting Team of the RIPE NCC will be able to design and test the RIPE meeting network beforehand, which will ensure stable operation of the IPv6 network during the RIPE Meetings. This will also allow the team to have complete control over the network to effectively address issues related to security, redundancy and setting efficient routing policies with third parties. The proposal is worded in a way that the IPv6 prefix will be provided to the RIPE Meeting organiser. This is to ensure that the prefix will stay with the meeting organiser for the sole usage in RIPE meetings. This means if the RIPE NCC ceases being the RIPE Meeting organiser in the future, the prefix will be returned to the free pool. The reason for the size being set to a /48 is about routing reasons. Because this is the minimum excepted routable assignment size that is common among all regions, we think a prefix in this size will guarantee connectivity during RIPE Meetings. b. Arguments opposing the proposal Some may argue that this will cause waste of address space because the prefix will be only in use effectively during RIPE meeting

12 14

Re: [address-policy-wg] Revisiting RIPE Policy Proposal 2007-01
by Sander Steffann 05 Dec '08

05 Dec '08

Hello Clive, >> Note that I'm not a lawyer - but as far as I understand, this is how the >> articles of the NCC are set up. The majority of the LIRs (+proxy votes) >> that attend the AGM vote for the board members and decide on the charging >> scheme (and possible changes to the articles). > > But what is the quorum for the meeting? Is it really as small as under 1%? > If the meeting isn't quorate, its decisions are invalid. If you want to discuss RIPE NCC member related issues, I think you should start a discussion on members-discuss(a)ripe.net. Discussing the RIPE NCC AGM on this list is not really appropriate. We should focus on address policy development here. I understand that this touches both RIPE policy and RIPE NCC membership/fee issues. Let's discuss each issue on the appropriate list. Thanks, Sander Steffann APWG co-chair

1 0

Clarification on End User Assignments Identity Verification
by Flor Paredes 04 Dec '08

04 Dec '08

Dear Colleagues, We wish to clarify the RIPE NCC Registration Services Department procedures with regards to direct End User assignments and the requirement for company registration documents. The RIPE NCC requires some form of registration documents to be submitted with all direct End User assignments, such as ASN, PI, Anycast and IXP assignments. The rationale behind this is to ensure that the End User's proper name is registered in the RIPE Database and in our internal records. Due to the wide variety of entities requiring resources in the RIPE NCC service region, we accept a variety of documents, as long as those documents correctly verify the name of the End User. In a situation where a direct assignment is requested for an organisation that is also an LIR, we waive this requirement because a signed contract and registration documents are already on file. Occasionally, an IPRA may still ask for registration documents during the evaluation of such requests because it may not be immediately obvious from the request form that the assignment is intended for the LIR itself. Once it becomes clear that the assignment is for the LIR itself, we no longer require these documents to be submitted. Best regards, Flor de Maria Paredes Mattos Registration Services Manager RIPE NCC

1 0

RE: [address-policy-wg] Revisiting RIPE Policy Proposal 2007-01
by poty＠iiat.ru 04 Dec '08

04 Dec '08

-----Original Message----- From: address-policy-wg-admin(a)ripe.net [mailto:address-policy-wg-admin@ripe.net] On Behalf Of Garry Glendown Sent: Thursday, December 04, 2008 1:59 PM To: address-policy-wg(a)ripe.net Subject: Re: [address-policy-wg] Revisiting RIPE Policy Proposal 2007-01 ... Speaking of customers - what about customers who aren't an LIR's customers anymore? Can those PI assignments be "redirected" towards either RIPE or the new provider? Or the Enduser himself? Might be hard to come up out of the blue and send a bill over x€ in such a case ... -garry -------------------------- That is the point! There is no way of controlling PIs which have been already issued. Some of them are already routed through other companies and have no relation to the issuer LIR. And there is no mechanism of "returning" these PI assignments and avoid the unfair burdens. Vladislav Potapov Ru.iiat

1 0

Revised 2006-01 set back to Discussion Phase (Provider Independent (PI) IPv6 Assignments for End User Organisations)
by Ana Matic 03 Dec '08

03 Dec '08

PDP Number: 2006-01 Provider Independent (PI) IPv6 Assignments for End User Organisations Dear Colleagues, The text of the policy proposal 2006-01 has been revised based on the community feedback received on the mailing list and during RIPE 56 and 57. We have published the new version (version 4) today. As a result a new Discussion Phase is set for the proposal. You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2006-01.html We encourage you to review this policy proposal and send your comments to <address-policy-wg(a)ripe.net> before 23 December 2008. Regards, Ana Matic RIPE NCC Policy Development Officer

18 20

Re: [address-policy-wg] Revised 2006-01 set back to Discussion Phase (Provider Independent (PI) IPv6 Assignments for End User Organisations)
by Remco van Mook 25 Nov '08

25 Nov '08

With the comments of Nick in mind I support this proposal. Best, Remco ----- Original Message ----- From: address-policy-wg-admin(a)ripe.net <address-policy-wg-admin(a)ripe.net> To: address-policy-wg(a)ripe.net <address-policy-wg(a)ripe.net> Cc: Jordi Palet Martinez <jordi.palet(a)consulintel.es> Sent: Tue Nov 25 18:20:47 2008 Subject: Re: [address-policy-wg] Revised 2006-01 set back to Discussion Phase (Provider Independent (PI) IPv6 Assignments for End User Organisations) Ana Matic wrote: > We encourage you to review this policy proposal and send your comments > to <address-policy-wg(a)ripe.net> before 23 December 2008. This proposal has improved substantially since v3.0, and it is long overdue. While I support it as-is, I have two comments. - the "temporary" status of the proposal has been changed to permanent. This is a good move, and merely recognition that reclaiming address space is an enormously difficult challenge, even if assigned on a temporary basis. - while a requirement for multihoming is useful, it should be made clear during implementation that this is not necessarily a requirement for multihoming using ASNs and BGP on the public Internet (however we care to define that term). Private interconnection to third parties is also a fully legitimate justification for assignment of provider independent number resources. Nick 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.

1 0