From andy at nosignal.org Tue Dec 2 11:02:20 2008 From: andy at nosignal.org (Andy Davidson) Date: Tue, 2 Dec 2008 10:02:20 +0000 Subject: [address-policy-wg] Revised 2006-01 set back to Discussion Phase (Provider Independent (PI) IPv6 Assignments for End User Organisations) In-Reply-To: <492C41FF.5040202@inex.ie> References: <20081125105622.618F22F592@herring.ripe.net> <492C41FF.5040202@inex.ie> Message-ID: On 25 Nov 2008, at 18:20, Nick Hilliard wrote: > Ana Matic wrote: >> We encourage you to review this policy proposal and send your >> comments >> to before 23 December 2008. I support this proposal. > - 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 I agree with Nick. Andy From elisa.jasinska at ams-ix.net Tue Dec 2 17:18:16 2008 From: elisa.jasinska at ams-ix.net (Elisa Jasinska) Date: Tue, 02 Dec 2008 17:18:16 +0100 Subject: [address-policy-wg] IPv6 assignment for the RIPE meetingnetwork Message-ID: <49355FC8.5040500@ams-ix.net> 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/ From michael.dillon at bt.com Tue Dec 2 21:33:27 2008 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Tue, 2 Dec 2008 20:33:27 -0000 Subject: [address-policy-wg] IPv6 assignment for the RIPE meetingnetwork In-Reply-To: <49355FC8.5040500@ams-ix.net> Message-ID: > 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? I agree that it would be fairer to change the policy so that any conference organizer can apply for a PI IPv6 address block. They fill the role of a network operator for the attendees of a conference and this should be sufficient justification. IPv6 address space is NOT in short supply and we should not treat it as a scarce resource at this time. --Michael Dillon From trejrco at gmail.com Tue Dec 2 22:39:28 2008 From: trejrco at gmail.com (TJ) Date: Tue, 2 Dec 2008 16:39:28 -0500 Subject: [address-policy-wg] IPv6 assignment for the RIPE meetingnetwork In-Reply-To: <49355FC8.5040500@ams-ix.net> References: <49355FC8.5040500@ams-ix.net> Message-ID: <001001c954c6$754dcaa0$5fe95fe0$@com> Perhaps an even better, even more IPv6'ish solution would be something like Network Mobility (NEMO)? And, not to cross threads (reference BEHAVE WG) or start fires, but another option would be to use ULA addresses internally and translate (NAT66) them to PA space onsite as needed ... (Not saying either option is ideal / great ... but if the others options are to be treated as super-special or to do lots of extra work, the alternatives above sound more palatable) /TJ ... just an uninvolved observer :) >-----Original Message----- >From: address-policy-wg-admin at ripe.net [mailto:address-policy-wg- >admin at ripe.net] On Behalf Of Elisa Jasinska >Sent: Tuesday, December 02, 2008 11:18 AM >To: address-policy-wg at ripe.net >Subject: Re: [address-policy-wg] IPv6 assignment for the RIPE meetingnetwork > >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/ From randy at psg.com Tue Dec 2 23:48:15 2008 From: randy at psg.com (Randy Bush) Date: Wed, 03 Dec 2008 07:48:15 +0900 Subject: [address-policy-wg] IPv6 assignment for the RIPE meetingnetwork In-Reply-To: <49355FC8.5040500@ams-ix.net> References: <49355FC8.5040500@ams-ix.net> Message-ID: <4935BB2F.3010609@psg.com> Elisa Jasinska wrote: > 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? perhaps someone could phrase the general case? randy From leo.vegoda at icann.org Wed Dec 3 07:45:27 2008 From: leo.vegoda at icann.org (Leo Vegoda) Date: Tue, 2 Dec 2008 22:45:27 -0800 Subject: [address-policy-wg] IPv6 assignment for the RIPE meetingnetwork In-Reply-To: <4935BB2F.3010609@psg.com> Message-ID: On 02/12/2008 11:48, "Randy Bush" wrote: > Elisa Jasinska wrote: >> 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? > > perhaps someone could phrase the general case? I thought 2006-01 is the general case. If it's not, I'd appreciate an explanation of why it cannot be. Regards, Leo Vegoda From randy at psg.com Wed Dec 3 07:59:55 2008 From: randy at psg.com (Randy Bush) Date: Wed, 03 Dec 2008 15:59:55 +0900 Subject: [address-policy-wg] IPv6 assignment for the RIPE meetingnetwork In-Reply-To: References: Message-ID: <49362E6B.8000703@psg.com> Leo Vegoda wrote: > On 02/12/2008 11:48, "Randy Bush" wrote: > >> Elisa Jasinska wrote: >>> 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? >> perhaps someone could phrase the general case? > > I thought 2006-01 is the general case. If it's not, I'd appreciate an > explanation of why it cannot be. i suspect that the ncc, perhaps andrei, would be the one to answer this, not i. but i can see having a meeting net address (4 and 6) and asn set lying around for folk to use, with some way to grab/schedule the token for two weeks (one setup and one show). randy From andrei at ripe.net Wed Dec 3 11:48:09 2008 From: andrei at ripe.net (Andrei Robachevsky) Date: Wed, 03 Dec 2008 11:48:09 +0100 Subject: [address-policy-wg] IPv6 assignment for the RIPE meetingnetwork In-Reply-To: <49362E6B.8000703@psg.com> References: <49362E6B.8000703@psg.com> Message-ID: <493663E9.4060304@ripe.net> Randy Bush wrote on 03-12-2008 07:59: > Leo Vegoda wrote: >> On 02/12/2008 11:48, "Randy Bush" wrote: >> >>> Elisa Jasinska wrote: >>>> 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? >>> perhaps someone could phrase the general case? >> I thought 2006-01 is the general case. If it's not, I'd appreciate an >> explanation of why it cannot be. > > i suspect that the ncc, perhaps andrei, would be the one to answer this, > not i. > I think the RIPE meeting network meets the requirement for multihoming, since it is multihomed, both topologically and in time. But meeting the "Contractual requirements" is more difficult, since in a way that will require the RIPE NCC to have a contract with ourselves and to evaluate our own request. Perhaps a more elegant solution here would be the one proposed by Remco back in November (to establish a policy that lets the NCC file a request in the ordinary way). > but i can see having a meeting net address (4 and 6) and asn set lying > around for folk to use, with some way to grab/schedule the token for two > weeks (one setup and one show). > > randy > Andrei From leo.vegoda at icann.org Wed Dec 3 12:19:25 2008 From: leo.vegoda at icann.org (Leo Vegoda) Date: Wed, 3 Dec 2008 03:19:25 -0800 Subject: [address-policy-wg] IPv6 assignment for the RIPE meetingnetwork In-Reply-To: <493663E9.4060304@ripe.net> Message-ID: Hi Andrei, On 03/12/2008 11:48, "Andrei Robachevsky" wrote: [...] >>>> perhaps someone could phrase the general case? >>> I thought 2006-01 is the general case. If it's not, I'd appreciate an >>> explanation of why it cannot be. >> >> i suspect that the ncc, perhaps andrei, would be the one to answer this, >> not i. > > I think the RIPE meeting network meets the requirement for multihoming, > since it is multihomed, both topologically and in time. Sounds reasonable. > But meeting the "Contractual requirements" is more difficult, since in a > way that will require the RIPE NCC to have a contract with ourselves and > to evaluate our own request. I don't know whether there is a legal problem with the RIPE NCC signing a contract with itself and paying itself fees. If not, the only problem is the evaluation of this request. But as your proposal is for the minimum size, a /48, it doesn't seem controversial as the only option for a smaller portion of the resource pool is none at all. Regards, Leo From jeroen at unfix.org Wed Dec 3 12:52:20 2008 From: jeroen at unfix.org (Jeroen Massar) Date: Wed, 03 Dec 2008 12:52:20 +0100 Subject: [address-policy-wg] IPv6 assignment for the RIPE meetingnetwork In-Reply-To: <49362E6B.8000703@psg.com> References: <49362E6B.8000703@psg.com> Message-ID: <493672F4.1050809@spaghetti.zurich.ibm.com> Randy Bush wrote: > Leo Vegoda wrote: >> On 02/12/2008 11:48, "Randy Bush" wrote: >> >>> Elisa Jasinska wrote: >>>> 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? >>> perhaps someone could phrase the general case? >> I thought 2006-01 is the general case. If it's not, I'd appreciate an >> explanation of why it cannot be. > > i suspect that the ncc, perhaps andrei, would be the one to answer this, > not i. > > but i can see having a meeting net address (4 and 6) and asn set lying > around for folk to use, with some way to grab/schedule the token for two > weeks (one setup and one show). That could work, generally the meetings are all aligned on the calendar anyway so that they don't collide. Only thing then, just like temporary space, is that you will have to get route filters updated (as your transit will be different, but with a moving network those things change anyway) etc etc etc. But all those problems should be doable. The question then still is, what is the difference between this special /48 or a /48 that one can get from the upstream provider? (Except for the first effectively being PI) As the RIPE NCC/"Meeting Organizer" is so intent on having this special prefix, I think it is up to them to properly define first what all the reasoning they have what and why, then we can discuss everything further. Greets, Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 187 bytes Desc: OpenPGP digital signature URL: From gert at space.net Wed Dec 3 13:09:06 2008 From: gert at space.net (Gert Doering) Date: Wed, 3 Dec 2008 13:09:06 +0100 Subject: [address-policy-wg] IPv6 assignment for the RIPE meetingnetwork In-Reply-To: <493672F4.1050809@spaghetti.zurich.ibm.com> References: <49362E6B.8000703@psg.com> <493672F4.1050809@spaghetti.zurich.ibm.com> Message-ID: <20081203120906.GY44476@Space.Net> Hi, On Wed, Dec 03, 2008 at 12:52:20PM +0100, Jeroen Massar wrote: > The question then still is, what is the difference between this special > /48 or a /48 that one can get from the upstream provider? (Except for > the first effectively being PI) > > As the RIPE NCC/"Meeting Organizer" is so intent on having this special > prefix, I think it is up to them to properly define first what all the > reasoning they have what and why, then we can discuss everything further. Jeroen, please calm down a bit. Right now, there is no PI. If 2006-01 goes through (which I see pretty good chances for, given that there are mainly textual details left, not unsolvable fundamental issues), PI can be used for the meeting network. Which leaves the problem of "an entity assigning to itself, and doing a contract with itself" - which can be seen as a problem with neutrality. Remco has made a suggestion how to tackle *this*, and I see this as the way forward. Gert Doering -- NetMaster -- 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 From info at streamservice.nl Wed Dec 3 13:51:09 2008 From: info at streamservice.nl (Stream Service) Date: Wed, 3 Dec 2008 13:51:09 +0100 Subject: [address-policy-wg] IPv6 assignment for the RIPE meetingnetwork In-Reply-To: References: <493663E9.4060304@ripe.net> Message-ID: <000b01c95545$d0a41b50$71ec51f0$@nl> Hello, Wouldn't it be an good option if the RIPE meetings becomes organized by another entity (for example a new organization (could be a "vereniging" or "stichting", I cannot remember the correct translations for both words)) that only works on creating the meetings with support from RIPE NCC (where needed). This would solve this issue and it would be easier I guess to offer options to talk if you want things to be changed within the RIPE NCC. However we need IPv6 asap (as IPv4 will not be available for new assignments within a few months/years). I know multiple networks that wait till they can get IPv6 PI space before offering IPv6 to their customers. And some companies need PI space just for the case they need to change from network (changing IPs is a lot of work that is not good for the competition between networks if you ask me). With kind regards, Mark Scholten Stream Service www.streamservice.nl -----Original Message----- From: address-policy-wg-admin at ripe.net [mailto:address-policy-wg-admin at ripe.net] On Behalf Of Leo Vegoda Sent: woensdag 3 december 2008 12:19 To: Andrei Robachevsky; Randy Bush Cc: Elisa Jasinska; address-policy-wg at ripe.net Subject: Re: [address-policy-wg] IPv6 assignment for the RIPE meetingnetwork Hi Andrei, On 03/12/2008 11:48, "Andrei Robachevsky" wrote: [...] >>>> perhaps someone could phrase the general case? >>> I thought 2006-01 is the general case. If it's not, I'd appreciate an >>> explanation of why it cannot be. >> >> i suspect that the ncc, perhaps andrei, would be the one to answer this, >> not i. > > I think the RIPE meeting network meets the requirement for multihoming, > since it is multihomed, both topologically and in time. Sounds reasonable. > But meeting the "Contractual requirements" is more difficult, since in a > way that will require the RIPE NCC to have a contract with ourselves and > to evaluate our own request. I don't know whether there is a legal problem with the RIPE NCC signing a contract with itself and paying itself fees. If not, the only problem is the evaluation of this request. But as your proposal is for the minimum size, a /48, it doesn't seem controversial as the only option for a smaller portion of the resource pool is none at all. Regards, Leo From sander at steffann.nl Wed Dec 3 15:26:11 2008 From: sander at steffann.nl (Sander Steffann) Date: Wed, 03 Dec 2008 15:26:11 +0100 Subject: [address-policy-wg] IPv6 assignment for the RIPE meetingnetwork In-Reply-To: <000b01c95545$d0a41b50$71ec51f0$@nl> References: <493663E9.4060304@ripe.net> <000b01c95545$d0a41b50$71ec51f0$@nl> Message-ID: <49369703.2030704@steffann.nl> Hello Mark, > Wouldn't it be an good option if the RIPE meetings becomes organized by another entity (for example a new organization (could be a "vereniging" or "stichting", I cannot remember the correct translations for both words)) that only works on creating the meetings with support from RIPE NCC (where needed). This would solve this issue and it would be easier I guess to offer options to talk if you want things to be changed within the RIPE NCC. > The address policy working group is not the place where we should discuss how to organise RIPE meetings... > However we need IPv6 asap (as IPv4 will not be available for new assignments within a few months/years). I know multiple networks that wait till they can get IPv6 PI space before offering IPv6 to their customers. If they need IPv6 address space for their customers they need PA space anyway, which they can get right now. > And some companies need PI space just for the case they need to change from network (changing IPs is a lot of work that is not good for the competition between networks if you ask me). > Those organisations do indeed 'need' IPv6 PI space. The policy proposal for IPv6 PI space is 2006-01. Once we get consensus on that proposal a lot of these problems will be solved. Then we only need a way for the NCC to assign resources to itself (like Remco proposed) to make everything work :) - Sander From gert at space.net Wed Dec 3 16:13:58 2008 From: gert at space.net (Gert Doering) Date: Wed, 3 Dec 2008 16:13:58 +0100 Subject: [address-policy-wg] IPv6 assignment for the RIPE meetingnetwork In-Reply-To: <000b01c95545$d0a41b50$71ec51f0$@nl> References: <493663E9.4060304@ripe.net> <000b01c95545$d0a41b50$71ec51f0$@nl> Message-ID: <20081203151358.GC44476@Space.Net> Hi, On Wed, Dec 03, 2008 at 01:51:09PM +0100, Stream Service wrote: > However we need IPv6 asap (as IPv4 will not be available for new assignments > within a few months/years). I know multiple networks that wait till they can > get IPv6 PI space before offering IPv6 to their customers. We are working on general IPv6 PI, but that's a different discussion thread. (Proposal 2006-01) Gert Doering -- AWPG 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 From michael.dillon at bt.com Wed Dec 3 16:58:13 2008 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Wed, 3 Dec 2008 15:58:13 -0000 Subject: [address-policy-wg] IPv6 assignment for the RIPE meetingnetwork In-Reply-To: <20081203120906.GY44476@Space.Net> Message-ID: > Which leaves the problem of "an entity assigning to itself, > and doing a contract with itself" - which can be seen as a > problem with neutrality. We aren't lawyers. Why are you asking us to solve legal problems. Any lawyer will tell you that this is simple. Incorporate an entity separate from the NCC that will organize meetings. It can have the same board of directors as the NCC, or some other arrangement if you wish. This organization can then sign contracts with the RIPE NCC. The RIPE NCC no longer has to worry about RIPE meetings because RIPE now deals with a separate organization to hold the meetings. --Michael Dillon From marcoh at marcoh.net Wed Dec 3 17:03:40 2008 From: marcoh at marcoh.net (Marco Hogewoning) Date: Wed, 3 Dec 2008 17:03:40 +0100 Subject: [address-policy-wg] IPv6 assignment for the RIPE meetingnetwork In-Reply-To: <000b01c95545$d0a41b50$71ec51f0$@nl> References: <493663E9.4060304@ripe.net> <000b01c95545$d0a41b50$71ec51f0$@nl> Message-ID: On Dec 3, 2008, at 1:51 PM, Stream Service wrote: > Hello, > > Wouldn't it be an good option if the RIPE meetings becomes organized > by > another entity (for example a new organization (could be a > "vereniging" or > "stichting", I cannot remember the correct translations for both > words)) > that only works on creating the meetings with support from RIPE NCC > (where > needed). This would solve this issue and it would be easier I guess > to offer > options to talk if you want things to be changed within the RIPE NCC. Yeah and make sure the entity is registered outside of the NCC service region so any conflict of interest can be avoided :) No really, don't you think this goes a bit too far ? Like Gert already posted, Remco made a suggestion which seems to be far and straightforward and if we get stuck in the 'NCC can't sign with themselves' I'm perfectly happy to have a chat with our sponsoring dept and run the request via our LIR so there is no need for the NCC to sign a direct enduser agreement. MarcoH From andreas at schachtner.eu Wed Dec 3 17:18:16 2008 From: andreas at schachtner.eu (Andreas Schachtner) Date: Wed, 03 Dec 2008 17:18:16 +0100 Subject: [address-policy-wg] IPv6 assignment for the RIPE meetingnetwork In-Reply-To: References: <493663E9.4060304@ripe.net> <000b01c95545$d0a41b50$71ec51f0$@nl> Message-ID: <20081203161816.62E0848388@footsu.site> ... > Yeah and make sure the entity is registered outside of the NCC service > region so any conflict of interest can be avoided :) > > No really, don't you think this goes a bit too far ? Like Gert already > posted, Remco made a suggestion which seems to be far and > straightforward and if we get stuck in the 'NCC can't sign with > themselves' I'm perfectly happy to have a chat with our sponsoring > dept and run the request via our LIR so there is no need for the NCC > to sign a direct enduser agreement. I support such a pragmatic approach instead of forming new entities. You never get rid of those, you know :-) Andreas -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 233 bytes Desc: not available URL: From ondrej.sury at nic.cz Wed Dec 3 17:40:02 2008 From: ondrej.sury at nic.cz (=?UTF-8?Q?Ond=C5=99ej_Sur=C3=BD?=) Date: Wed, 3 Dec 2008 17:40:02 +0100 Subject: [address-policy-wg] Revised 2006-01 set back to Discussion Phase (Provider Independent (PI) IPv6 Assignments for End User Organisations) In-Reply-To: <20081125105622.618F22F592@herring.ripe.net> References: <20081125105622.618F22F592@herring.ripe.net> Message-ID: I support this proposal. 2008/11/25 Ana Matic : > 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 before 23 December 2008. > > Regards, > > Ana Matic > RIPE NCC > Policy Development Officer > > > -- Ondrej Sury technicky reditel/Chief Technical Officer ----------------------------------------- CZ.NIC, z.s.p.o. -- .cz domain registry Americka 23,120 00 Praha 2,Czech Republic mailto:ondrej.sury at nic.cz http://nic.cz/ sip:ondrej.sury at nic.cz tel:+420.222745110 mob:+420.739013699 fax:+420.222745112 ----------------------------------------- From hank at efes.iucc.ac.il Thu Dec 4 07:25:07 2008 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Thu, 04 Dec 2008 08:25:07 +0200 Subject: [address-policy-wg] Revisiting RIPE Policy Proposal 2007-01 In-Reply-To: <20081203151358.GC44476@Space.Net> References: <000b01c95545$d0a41b50$71ec51f0$@nl> <493663E9.4060304@ripe.net> <000b01c95545$d0a41b50$71ec51f0$@nl> Message-ID: <5.1.0.14.2.20081204080417.00b18e48@efes.iucc.ac.il> Recently, RIPE Policy Proposal 2007-01 titled "Direct Internet Resource Assignments to End Users from the RIPE NCC" was passed: http://www.ripe.net/ripe/policies/proposals/2007-01.html Unfortunately, I believe not all aspects of its impact were made clear to the members. For example, in the section marked "Policy Documents to be Affected" there are 4 RIPE documents listed, but *not* listed is the RIPE NCC Charging Scheme 2008: http://www.ripe.net/ripe/docs/ripe-420.html which was changed for 2009 via: http://www.ripe.net/ripe/docs/charging.html The crucial change here is that AS numbers, IPv4 Provider Independent (PI) assignments and IPv6 PI assignments have been changed from a one-time score to a recurring score. Max, jokingly stated in April: http://www.ripe.net/ripe/maillists/archives/address-policy-wg/2008/msg00244.html "May be we should return back old charging scheme when PI is billed yearly to LIRs? This will enforce return unused space, make contracts between LIRs and end-users, and so on just *automagically* ;)" Little did I know that this is what would come to pass - retroactively! Gert stated in Sept: http://www.ripe.net/ripe/maillists/archives/address-policy-wg/2008/msg00537.html "PI is currently scored in the year of assignment, and then never again, so it's not "fully free", but after the initial cost, it is - so the term "basically free" is appropriate. ... As has been mentioned before: the address policy WG does not have the power to actually decide on the final charging scheme. We give input to the AGM (= annual general meeting of all NCC members), and the AGM decides on the final charging scheme to be implemented. So, regarding the *charging* component of 2007-01: the AGM can do this without 2007-01, or they can decide to not do anything about it, even with 2007-01 reaching consensus." Maybe I missed the discussion in regards to 2007-01 where it was stated that the charging algorithm would change. For example, one LIR I consult to was extra small in 2008 (1300Euro) and now is medium (2550Euro). They assigned 54 ASNs between 1997-2005 and no IPv4 or IPv6 address space at all. So since the charging algorithm is now a retroactive recurring score, their bill doubled suddenly. Was this totally understood by us? Thanks, Hank From michael.dillon at bt.com Thu Dec 4 11:27:36 2008 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Thu, 4 Dec 2008 10:27:36 -0000 Subject: [address-policy-wg] Revisiting RIPE Policy Proposal 2007-01 In-Reply-To: <5.1.0.14.2.20081204080417.00b18e48@efes.iucc.ac.il> Message-ID: > Unfortunately, I believe not all aspects of its impact were > made clear to the members. For example, in the section > marked "Policy Documents to be Affected" there are 4 RIPE > documents listed, but *not* listed is the RIPE NCC Charging > Scheme 2008: This is not the only sloppiness in RIPE recently. The process for applying for an AS number was recently changed to require every applicant to submit corporate registration papers, even if they are a long-time RIPE LIR. But the current ASN assignment policy here doesn't mention this. Nor does RIPE-406 --Michael Dillon From andy at nosignal.org Thu Dec 4 11:38:33 2008 From: andy at nosignal.org (Andy Davidson) Date: Thu, 4 Dec 2008 10:38:33 +0000 Subject: [address-policy-wg] IPv6 assignment for the RIPE meetingnetwork In-Reply-To: <493663E9.4060304@ripe.net> References: <49362E6B.8000703@psg.com> <493663E9.4060304@ripe.net> Message-ID: On 3 Dec 2008, at 10:48, Andrei Robachevsky wrote: > But meeting the "Contractual requirements" is more difficult, since > in a way that will require the RIPE NCC to have a contract with > ourselves and to evaluate our own request. Perhaps a more elegant > solution here would be the one proposed by Remco back in November > (to establish a policy that lets the NCC file a request in the > ordinary way). Does "The RIPE Community" exist as a legal entity ? Can the community hold the meeting resources and agree to hold a contract with the NCC ? Andy From garry at nethinks.com Thu Dec 4 11:59:20 2008 From: garry at nethinks.com (Garry Glendown) Date: Thu, 04 Dec 2008 11:59:20 +0100 Subject: [address-policy-wg] Revisiting RIPE Policy Proposal 2007-01 In-Reply-To: <5.1.0.14.2.20081204080417.00b18e48@efes.iucc.ac.il> References: <000b01c95545$d0a41b50$71ec51f0$@nl> <493663E9.4060304@ripe.net> <000b01c95545$d0a41b50$71ec51f0$@nl> <5.1.0.14.2.20081204080417.00b18e48@efes.iucc.ac.il> Message-ID: <4937B808.7020802@nethinks.com> > Maybe I missed the discussion in regards to 2007-01 where it was > stated that the charging algorithm would change. For example, one LIR > I consult to was extra small in 2008 (1300Euro) and now is medium > (2550Euro). They assigned 54 ASNs between 1997-2005 and no IPv4 or > IPv6 address space at all. So since the charging algorithm is now a > retroactive recurring score, their bill doubled suddenly. I guess that's the risks involved with a pricing scheme change - they will just need to compensate by actually billing their customers for services they deliver ... I can still remember a time when ISPs in Germany would charge for any IPs they'd assign, even when they were from their (LIR) PA range ... and that was recurring fees, too ... for us, the pricing scheme change luckily doesn't result in additional cost, as we're pretty far down in the Medium range ... (though, from a percentage view, we did move up some from last year). Still, we are now preparing a letter to our customers informing them of a change in pricing, or rather, the new recurring pricing for usage of ASNs and IP-PI. The cost, when distributed evenly among all customers, is very resonable ... therefore I do not forsee too much of a fuss over it ... 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 From tomas.hlavacek at ignum.cz Wed Dec 3 23:53:05 2008 From: tomas.hlavacek at ignum.cz (Tomas Hlavacek) Date: Wed, 03 Dec 2008 23:53:05 +0100 Subject: [address-policy-wg] Revised 2006-01 set back to Discussion Phase In-Reply-To: <20081125105622.618F22F592@herring.ripe.net> References: <20081125105622.618F22F592@herring.ripe.net> Message-ID: <49370DD1.6060200@ignum.cz> Greetings! I support this proposal. Best regards, Tomas Hlavacek Ana Matic wrote: > 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 before 23 December 2008. > > Regards, > > Ana Matic > RIPE NCC > Policy Development Officer > > From tomas.hlavacek at ignum.cz Wed Dec 3 23:39:39 2008 From: tomas.hlavacek at ignum.cz (Tomas Hlavacek) Date: Wed, 03 Dec 2008 23:39:39 +0100 Subject: [address-policy-wg] IPv6 assignment for the RIPE meeting network In-Reply-To: <49241045.5060707@ripe.net> References: <49241045.5060707@ripe.net> Message-ID: <49370AAB.30506@ignum.cz> Greetings! I am against this. I do not like making a special case out of RIPE meetings. But I support the basic idea that a conference organizer should be able to get an IPv6 PI assignment (as 2006-1 is turned into policy). I do not like newly proposed status 'ASSIGNED MEETING' also. I would support any prospective policy proposal which makes NCC able to set a contractual realtionship with itself, if needed to use 2006-1 in this or in any similar case. Best regards, Tomas Hlavacek Andrei Robachevsky wrote: > 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_assignment_for_RIPE_meeting_network.pdf), > 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 > From nick at inex.ie Thu Dec 4 12:05:08 2008 From: nick at inex.ie (Nick Hilliard) Date: Thu, 04 Dec 2008 11:05:08 +0000 Subject: [address-policy-wg] Revisiting RIPE Policy Proposal 2007-01 In-Reply-To: <5.1.0.14.2.20081204080417.00b18e48@efes.iucc.ac.il> References: <000b01c95545$d0a41b50$71ec51f0$@nl> <493663E9.4060304@ripe.net> <000b01c95545$d0a41b50$71ec51f0$@nl> <5.1.0.14.2.20081204080417.00b18e48@efes.iucc.ac.il> Message-ID: <4937B964.4040507@inex.ie> Hank Nussbacher wrote: > Recently, RIPE Policy Proposal 2007-01 titled "Direct Internet Resource > Assignments to End Users from the RIPE NCC" was passed: > http://www.ripe.net/ripe/policies/proposals/2007-01.html Hank, This was discussed many times at RIPE meetings. Not at just one, but several. The final decision to put this into the charging scheme was made at the General Meeting in Dubai, but it was talked about at a couple of others. > As has been mentioned before: the address policy WG does not have the > power to actually decide on the final charging scheme. We give input > to the AGM (= annual general meeting of all NCC members), and the AGM > decides on the final charging scheme to be implemented. > So, regarding the *charging* component of 2007-01: the AGM can do this > without 2007-01, or they can decide to not do anything about it, even with > 2007-01 reaching consensus." I think the RIPE board wanted to ensure that there was a comprehensive solution in place to deal with the whole issue of provider independent number resources before trying to just change just the LIR billing component. You're possibly right - they may have been able to change the billing scheme without 2007-01, but that would have ended the board up with only a partial solution to a difficult problem. > Maybe I missed the discussion in regards to 2007-01 where it was stated > that the charging algorithm would change. Yes, you missed the discussion. It took place at RIPE meetings, not on the mailing list, and for the reasons you specify: billing is outside the scope of apwg. > For example, one LIR I > consult to was extra small in 2008 (1300Euro) and now is medium > (2550Euro). They assigned 54 ASNs between 1997-2005 and no IPv4 or IPv6 > address space at all. So since the charging algorithm is now a > retroactive recurring score, their bill doubled suddenly. Please see: http://www.ripe.net/ripe/draft-documents/ripe-new-draft2007-01-v4.html The LIR should pass on the cost to the end-users. I calculate the cost increase to be ?23 per annum per ASN. Is that an unreasonable burden? Nick From hank at efes.iucc.ac.il Thu Dec 4 12:15:48 2008 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Thu, 04 Dec 2008 13:15:48 +0200 Subject: [address-policy-wg] Revisiting RIPE Policy Proposal 2007-01 In-Reply-To: <4937B964.4040507@inex.ie> References: <5.1.0.14.2.20081204080417.00b18e48@efes.iucc.ac.il> <000b01c95545$d0a41b50$71ec51f0$@nl> <493663E9.4060304@ripe.net> <000b01c95545$d0a41b50$71ec51f0$@nl> <5.1.0.14.2.20081204080417.00b18e48@efes.iucc.ac.il> Message-ID: <5.1.0.14.2.20081204130931.00b22e88@efes.iucc.ac.il> At 11:05 AM 04-12-08 +0000, Nick Hilliard wrote: >Content-Transfer-Encoding: 8bit > >Hank Nussbacher wrote: > > Recently, RIPE Policy Proposal 2007-01 titled "Direct Internet Resource > > Assignments to End Users from the RIPE NCC" was passed: > > http://www.ripe.net/ripe/policies/proposals/2007-01.html > >Hank, > >This was discussed many times at RIPE meetings. Not at just one, but >several. The final decision to put this into the charging scheme was made >at the General Meeting in Dubai, but it was talked about at a couple of >others. ... > > Maybe I missed the discussion in regards to 2007-01 where it was stated > > that the charging algorithm would change. > >Yes, you missed the discussion. It took place at RIPE meetings, not on the >mailing list, and for the reasons you specify: billing is outside the scope >of apwg. And we both know that not all 5000 RIPE members attend all the meetings. That is what protocols of meetings are for. Can you point me at the protocol of a meeting that mentions this will happen? > > For example, one LIR I > > consult to was extra small in 2008 (1300Euro) and now is medium > > (2550Euro). They assigned 54 ASNs between 1997-2005 and no IPv4 or IPv6 > > address space at all. So since the charging algorithm is now a > > retroactive recurring score, their bill doubled suddenly. > >Please see: > >http://www.ripe.net/ripe/draft-documents/ripe-new-draft2007-01-v4.html > >The LIR should pass on the cost to the end-users. I calculate the cost >increase to be ?23 per annum per ASN. Is that an unreasonable burden? Not at all - for new allocations. For ASNs allocated in 1997-2005 this particular LIR charged a one time fee to the customers since it knew the rules then as they had been for the past decade and didn't think they would change retroactively in 2008. So the LIR can't now go back to these 50 customers and tell them they need to pay 23Euro/yr. -Hank From randy at psg.com Thu Dec 4 12:21:53 2008 From: randy at psg.com (Randy Bush) Date: Thu, 04 Dec 2008 20:21:53 +0900 Subject: [address-policy-wg] Revisiting RIPE Policy Proposal 2007-01 In-Reply-To: <4937B964.4040507@inex.ie> References: <000b01c95545$d0a41b50$71ec51f0$@nl> <493663E9.4060304@ripe.net> <000b01c95545$d0a41b50$71ec51f0$@nl> <5.1.0.14.2.20081204080417.00b18e48@efes.iucc.ac.il> <4937B964.4040507@inex.ie> Message-ID: <4937BD51.1030703@psg.com> > This was discussed many times at RIPE meetings. Not at just one, but > several. The final decision to put this into the charging scheme was made > at the General Meeting in Dubai, but it was talked about at a couple of others. excuse? i thought decisions are made on list, not at meetings. randy From nick at inex.ie Thu Dec 4 12:28:50 2008 From: nick at inex.ie (Nick Hilliard) Date: Thu, 04 Dec 2008 11:28:50 +0000 Subject: [address-policy-wg] Revisiting RIPE Policy Proposal 2007-01 In-Reply-To: <4937BD51.1030703@psg.com> References: <000b01c95545$d0a41b50$71ec51f0$@nl> <493663E9.4060304@ripe.net> <000b01c95545$d0a41b50$71ec51f0$@nl> <5.1.0.14.2.20081204080417.00b18e48@efes.iucc.ac.il> <4937B964.4040507@inex.ie> <4937BD51.1030703@psg.com> Message-ID: <4937BEF2.4070107@inex.ie> Randy Bush wrote: > excuse? i thought decisions are made on list, not at meetings. I was always under the impression it was a combination of both. When was the last RIPE board election or charging scheme that was approved by mailing list? Nick From gert at space.net Thu Dec 4 12:37:37 2008 From: gert at space.net (Gert Doering) Date: Thu, 4 Dec 2008 12:37:37 +0100 Subject: [address-policy-wg] Revisiting RIPE Policy Proposal 2007-01 In-Reply-To: <4937BD51.1030703@psg.com> References: <000b01c95545$d0a41b50$71ec51f0$@nl> <493663E9.4060304@ripe.net> <000b01c95545$d0a41b50$71ec51f0$@nl> <5.1.0.14.2.20081204080417.00b18e48@efes.iucc.ac.il> <4937B964.4040507@inex.ie> <4937BD51.1030703@psg.com> Message-ID: <20081204113737.GY44476@Space.Net> Hi, On Thu, Dec 04, 2008 at 08:21:53PM +0900, Randy Bush wrote: > > This was discussed many times at RIPE meetings. Not at just one, but > > several. The final decision to put this into the charging scheme was made > > at the General Meeting in Dubai, but it was talked about at a couple of others. > > excuse? i thought decisions are made on list, not at meetings. This was one of the core problems of 2007-01 - the APWG can not decide on the charging scheme. We can discuss things (which we did, here and in the meetings), but in the end, the charging scheme is decided by the RIPE members AGM - and it's one of the few things where we actually decide by *vote* in RIPE land. Every RIPE member receives the invitations to the AGM, and the invitation contained the draft of the to-be-installed charging scheme. It was sent out well in advance, and there is an option to give proxy votes to other LIRs if you can't attend yourself. The majority of the LIRs that attended the meeting (or sent proxy votes) voted for the acceptance of the new charging scheme. 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 From randy at psg.com Thu Dec 4 12:47:55 2008 From: randy at psg.com (Randy Bush) Date: Thu, 04 Dec 2008 20:47:55 +0900 Subject: [address-policy-wg] Revisiting RIPE Policy Proposal 2007-01 In-Reply-To: <20081204113737.GY44476@Space.Net> References: <000b01c95545$d0a41b50$71ec51f0$@nl> <493663E9.4060304@ripe.net> <000b01c95545$d0a41b50$71ec51f0$@nl> <5.1.0.14.2.20081204080417.00b18e48@efes.iucc.ac.il> <4937B964.4040507@inex.ie> <4937BD51.1030703@psg.com> <20081204113737.GY44476@Space.Net> Message-ID: <4937C36B.9080400@psg.com> >> excuse? i thought decisions are made on list, not at meetings. > > This was one of the core problems of 2007-01 - the APWG can not decide > on the charging scheme. We can discuss things (which we did, here and > in the meetings), but in the end, the charging scheme is decided by the > RIPE members AGM - and it's one of the few things where we actually > decide by *vote* in RIPE land. i stand, well sit, corrected. thanks. randy From gert at space.net Thu Dec 4 12:56:00 2008 From: gert at space.net (Gert Doering) Date: Thu, 4 Dec 2008 12:56:00 +0100 Subject: [address-policy-wg] Revisiting RIPE Policy Proposal 2007-01 In-Reply-To: <20081204113737.GY44476@Space.Net> References: <000b01c95545$d0a41b50$71ec51f0$@nl> <493663E9.4060304@ripe.net> <000b01c95545$d0a41b50$71ec51f0$@nl> <5.1.0.14.2.20081204080417.00b18e48@efes.iucc.ac.il> <4937B964.4040507@inex.ie> <4937BD51.1030703@psg.com> <20081204113737.GY44476@Space.Net> Message-ID: <20081204115600.GA66056@Space.Net> Hi, On Thu, Dec 04, 2008 at 12:37:37PM +0100, Gert Doering wrote: > Every RIPE member receives the invitations to the AGM, and the invitation > contained the draft of the to-be-installed charging scheme. It was sent > out well in advance, and there is an option to give proxy votes to other > LIRs if you can't attend yourself. Actually, this paragraph has to start with "every RIPE *NCC* member", aka "LIR". "RIPE" is "the community", and "everybody is free to participate". "RIPE NCC" is the organization in Amsterdam, and there is contracts, voting rights, and yearly fees to be paid. This is the formal part, with voting, and money transferred. I'm sorry for not being more precise there. The distinction is important. 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 From nick at inex.ie Thu Dec 4 12:59:50 2008 From: nick at inex.ie (Nick Hilliard) Date: Thu, 04 Dec 2008 11:59:50 +0000 Subject: [address-policy-wg] IPv6 assignment for the RIPE meetingnetwork In-Reply-To: <493663E9.4060304@ripe.net> References: <49362E6B.8000703@psg.com> <493663E9.4060304@ripe.net> Message-ID: <4937C636.3050900@inex.ie> Andrei Robachevsky wrote: > I think the RIPE meeting network meets the requirement for multihoming, > since it is multihomed, both topologically and in time. > > But meeting the "Contractual requirements" is more difficult, since in a > way that will require the RIPE NCC to have a contract with ourselves and > to evaluate our own request. Perhaps a more elegant solution here would > be the one proposed by Remco back in November (to establish a policy > that lets the NCC file a request in the ordinary way). Andrei, Maybe you could explain what sort of problems you're having with address space requests? Is it that: 1. the ripe ncc seems to have no official means of assigning address space to itself, 1a. due to political neutrality requirements, the ripe ncc cannot engage the services of a third party LIR, 2. engaging in a contract with itself under the terms of 2007-01 will cause a bureaucratic singularity to occur, and therefore it should not be attempted, 3. the registration department at ripe applies the same rules to the rest of the ncc that they apply to everyone else, and because 2006-01 isn't policy yet, the meeting organisation department cannot get ipv6 pi, or 4. something else. >From your email of yesterday, it seems like #2 is definitely a candidate problem. I'd suspect #1a too, although not so much #1. #3 will be solved with 2006-01. #1 and #2 can only be solved with a policy change. #1a could be solved by a policy change to create a pseudo LIR (eu.ripencc), if there is a requirement to push the ripe ncc's numbering requirements through a LIR. Please explain more. There's a lot of discussion going on about this topic, but it's just not clear what problem you're trying to solve, other than the immediate technical requirement to get ipv6 PI space for ripe meetings. Nick From k13 at nikhef.nl Thu Dec 4 12:17:39 2008 From: k13 at nikhef.nl (Rob Blokzijl) Date: Thu, 4 Dec 2008 12:17:39 +0100 (MET) Subject: [address-policy-wg] IPv6 assignment for the RIPE meetingnetwork In-Reply-To: References: <49362E6B.8000703@psg.com> <493663E9.4060304@ripe.net> Message-ID: On Thu, 4 Dec 2008, Andy Davidson wrote: > > On 3 Dec 2008, at 10:48, Andrei Robachevsky wrote: > >> But meeting the "Contractual requirements" is more difficult, since in a >> way that will require the RIPE NCC to have a contract with ourselves and to >> evaluate our own request. Perhaps a more elegant solution here would be the >> one proposed by Remco back in November (to establish a policy that lets the >> NCC file a request in the ordinary way). > > Does "The RIPE Community" exist as a legal entity ? Can the community hold > the meeting resources and agree to hold a contract with the NCC ? No, and No. That is one of the reasons that back in 1992 the 'RIPE Community' decided to create the RIPE NCC. > > Andy Rob From hank at efes.iucc.ac.il Thu Dec 4 13:29:40 2008 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Thu, 04 Dec 2008 14:29:40 +0200 Subject: [address-policy-wg] Revisiting RIPE Policy Proposal 2007-01 In-Reply-To: <20081204113737.GY44476@Space.Net> References: <4937BD51.1030703@psg.com> <000b01c95545$d0a41b50$71ec51f0$@nl> <493663E9.4060304@ripe.net> <000b01c95545$d0a41b50$71ec51f0$@nl> <5.1.0.14.2.20081204080417.00b18e48@efes.iucc.ac.il> <4937B964.4040507@inex.ie> <4937BD51.1030703@psg.com> Message-ID: <5.1.0.14.2.20081204142836.0576fae0@efes.iucc.ac.il> At 12:37 PM 04-12-08 +0100, you wrote: >Every RIPE member receives the invitations to the AGM, and the invitation >contained the draft of the to-be-installed charging scheme. It was sent >out well in advance, and there is an option to give proxy votes to other >LIRs if you can't attend yourself. I am also a LIR contact for il.iucc and il.isoc and both did not receive an invitation and I did not see any drafts as discussed. Can you find out to which email address they sent those docs for il.iucc and il.isoc? -Hank >The majority of the LIRs that attended the meeting (or sent proxy votes) >voted for the acceptance of the new charging scheme. > >Gert Doering > -- APWG chair From gert at space.net Thu Dec 4 13:52:32 2008 From: gert at space.net (Gert Doering) Date: Thu, 4 Dec 2008 13:52:32 +0100 Subject: [address-policy-wg] Revisiting RIPE Policy Proposal 2007-01 In-Reply-To: <5.1.0.14.2.20081204142836.0576fae0@efes.iucc.ac.il> References: <4937BD51.1030703@psg.com> <000b01c95545$d0a41b50$71ec51f0$@nl> <493663E9.4060304@ripe.net> <000b01c95545$d0a41b50$71ec51f0$@nl> <5.1.0.14.2.20081204080417.00b18e48@efes.iucc.ac.il> <4937B964.4040507@inex.ie> <4937BD51.1030703@psg.com> <5.1.0.14.2.20081204142836.0576fae0@efes.iucc.ac.il> Message-ID: <20081204125232.GA44476@Space.Net> Hi, On Thu, Dec 04, 2008 at 02:29:40PM +0200, Hank Nussbacher wrote: > At 12:37 PM 04-12-08 +0100, you wrote: > >Every RIPE member receives the invitations to the AGM, and the invitation > >contained the draft of the to-be-installed charging scheme. It was sent > >out well in advance, and there is an option to give proxy votes to other > >LIRs if you can't attend yourself. > > I am also a LIR contact for il.iucc and il.isoc and both did not receive an > invitation and I did not see any drafts as discussed. Can you find out to > which email address they sent those docs for il.iucc and il.isoc? The invitation goes to the ripe announcement list. One of them had the following headers...: Message-ID: <48E2639D.2040404 at ripe.net> From: Axel Pawlik Reply-To: agm at ripe.net To: ncc-announce at ripe.net Date: Tue, 30 Sep 2008 19:36:29 +0200 Subject: [ncc-announce] RIPE NCC General Meeting October 2008: Draft Agenda and Supporting I'm not exactly sure how that list is maintained, and what contacts are on there - but I would guess that the formal contacts for a LIR are put on that list. Maybe it's visible in the LIR portal? This is a bit out of the scope of my daily work - but there's always lir-help at ripe.net to help with such questions. Gert Doering -- NetMaster -- 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 305 bytes Desc: not available URL: From poty at iiat.ru Thu Dec 4 14:16:16 2008 From: poty at iiat.ru (poty at iiat.ru) Date: Thu, 4 Dec 2008 16:16:16 +0300 Subject: [address-policy-wg] Revisiting RIPE Policy Proposal 2007-01 Message-ID: -----Original Message----- From: address-policy-wg-admin at ripe.net [mailto:address-policy-wg-admin at ripe.net] On Behalf Of Garry Glendown Sent: Thursday, December 04, 2008 1:59 PM To: address-policy-wg at 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 From peter.galbavy at knowtion.net Thu Dec 4 14:01:57 2008 From: peter.galbavy at knowtion.net (Peter Galbavy) Date: Thu, 04 Dec 2008 13:01:57 +0000 Subject: [address-policy-wg] Revisiting RIPE Policy Proposal 2007-01 In-Reply-To: <5.1.0.14.2.20081204142836.0576fae0@efes.iucc.ac.il> References: <4937BD51.1030703@psg.com> <000b01c95545$d0a41b50$71ec51f0$@nl> <493663E9.4060304@ripe.net> <000b01c95545$d0a41b50$71ec51f0$@nl> <5.1.0.14.2.20081204080417.00b18e48@efes.iucc.ac.il> <4937B964.4040507@inex.ie> <4937BD51.1030703@psg.com> <5.1.0.14.2.20081204142836.0576fae0@efes.iucc.ac.il> Message-ID: <4937D4C5.9000402@knowtion.net> Hank Nussbacher wrote: > I am also a LIR contact for il.iucc and il.isoc and both did not receive > an invitation and I did not see any drafts as discussed. Can you find > out to which email address they sent those docs for il.iucc and il.isoc? Surely you are not saying that RIPE buries plans in a locked filing cabinet labeled "Beware of the Leopard" in a disused toilet in a basement with no stairs ? No, never. Many of us do not have personal experience of this, do we ? Peter From michael.dillon at bt.com Thu Dec 4 15:35:20 2008 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Thu, 4 Dec 2008 14:35:20 -0000 Subject: [address-policy-wg] Revisiting RIPE Policy Proposal 2007-01 In-Reply-To: <20081204125232.GA44476@Space.Net> Message-ID: > The invitation goes to the ripe announcement list. One of > them had the following headers...: This message illustrates a disturbing trend with RIPE. People associated with RIPE, either the NCC or otherwise, seem to always assume that RIPE is right, and the LIR is wrong. Then they write an email that demonstrates to a careful reader, that RIPE is wrong or confused or too lazy to take the time to read the original email. --Michael Dillon From andrei at ripe.net Thu Dec 4 15:43:49 2008 From: andrei at ripe.net (Andrei Robachevsky) Date: Thu, 04 Dec 2008 15:43:49 +0100 Subject: [address-policy-wg] IPv6 assignment for the RIPE meetingnetwork In-Reply-To: <4937C636.3050900@inex.ie> References: <49362E6B.8000703@psg.com> <493663E9.4060304@ripe.net> <4937C636.3050900@inex.ie> Message-ID: <4937ECA5.3090007@ripe.net> Nick, Nick Hilliard wrote on 04-12-2008 12:59: [...] > Please explain more. There's a lot of discussion going on about this > topic, but it's just not clear what problem you're trying to solve, other > than the immediate technical requirement to get ipv6 PI space for ripe > meetings. > That is exactly the problem we are trying to solve. To do that it appears we need #1, 2 and 3 sorted out as you rightly noted. > Nick Andrei From gert at space.net Thu Dec 4 16:19:09 2008 From: gert at space.net (Gert Doering) Date: Thu, 4 Dec 2008 16:19:09 +0100 Subject: [address-policy-wg] Revisiting RIPE Policy Proposal 2007-01 In-Reply-To: References: <20081204125232.GA44476@Space.Net> Message-ID: <20081204151909.GF44476@Space.Net> Hi, On Thu, Dec 04, 2008 at 02:35:20PM -0000, michael.dillon at bt.com wrote: > > The invitation goes to the ripe announcement list. One of > > them had the following headers...: > > This message illustrates a disturbing trend with RIPE. > People associated with RIPE, either the NCC or otherwise, > seem to always assume that RIPE is right, and the LIR is > wrong. Then they write an email that demonstrates to > a careful reader, that RIPE is wrong or confused or > too lazy to take the time to read the original email. I have the feeling that you're unhappy with my e-mail. The intent of showing these headers was "that's the date, the message-ID and the subject of the mail, so maybe it's easier to track what had happened with this information". Not working for the RIPE NCC I can't say for sure how this mailing list is maintained - and from a LIR perspective, all I can say is that I've been on that list since we became a LIR, some 10 years ago. At that time I didn't know anything about RIPE, so I assume that the listed contacts get/got added automatically. (Oh, btw, maybe I should point out that you are also "part of RIPE", and thus the statement "... that RIPE is wrong and confused" could encompass your mail as well. And RIPE-as-the-whole-community is certainly too lazy to read e-mails. So what is your point?) Gert Doering -- NetMaster -- 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 From nick at inex.ie Thu Dec 4 16:37:42 2008 From: nick at inex.ie (Nick Hilliard) Date: Thu, 04 Dec 2008 15:37:42 +0000 Subject: [address-policy-wg] IPv6 assignment for the RIPE meetingnetwork In-Reply-To: <4937ECA5.3090007@ripe.net> References: <49362E6B.8000703@psg.com> <493663E9.4060304@ripe.net> <4937C636.3050900@inex.ie> <4937ECA5.3090007@ripe.net> Message-ID: <4937F946.8090208@inex.ie> Andrei Robachevsky wrote: > That is exactly the problem we are trying to solve. To do that it > appears we need #1, 2 and 3 sorted out as you rightly noted. Ok, good, so let's say for the sake of argument that 2006-01 is passed as policy and PI IPv6 space becomes available, and that the RIPE NCC applies for and is assigned a /48 for internal infrastructural needs - i.e. replacing the PA /48 currently assigned for the purpose by SARA. If the meetings organisation people within the RIPE NCC then apply for a separate /48 PI for use for RIPE meetings, will the registration services department then be in a position to assign a separate /48 PI block for meetings under existing assignment guidelines? More generally, if Organisation X already holds IPv6 space, whether PA or PI, and where: 1. they are not using the entire address block for their infrastructural needs, 2. they intend to organise an event which requires a separate IPv6 address block for routing purposes, 3. the total number of /64s required for both their normal infrastructural needs and their event requirements does not exceed their existing ipv6 assignment 4. that assignment is either for a once-off or a periodically recurring meeting then in this situation, would the RIPE NCC registration department be happy to assign an ipv6 address block for that purpose? My take on this is probably not. But it would be helpful to get a formal opinion from this from the RIPE NCC. two notes: - I've excluded ipv4 and asns from this position, because I think that they can probably be assigned under existing guidelines: ASNs because of the multihoming requirements if the organisation does not already hold an ASN, and IPv4 because end-users are assigned on the basis of numerical requirement for day-to-day needs, and if they organise a temporary event, then that numerical requirement will be exceeded. - I can see no good reason that RIPE should receive special treatment in terms of any address assignment requirements and lots of reasons that they shouldn't. If there is a requirement for RIPE to receive a /48 pi block for meetings, then that option should be considered for all end-users in the RIPE service region. Nick From michael.dillon at bt.com Thu Dec 4 16:39:41 2008 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Thu, 4 Dec 2008 15:39:41 -0000 Subject: [address-policy-wg] Revisiting RIPE Policy Proposal 2007-01 In-Reply-To: <20081204151909.GF44476@Space.Net> Message-ID: > (Oh, btw, maybe I should point out that you are also "part of > RIPE", I don't chair any WGs. > So what is your point?) Hank said that he did not get any formal notice that the fee changes would be voted on at the meeting. Hank did not complain about any mailing lists. Hank did not complain about any working groups. Hank did complain that the people in the RIPE NCC, who are responsible for organizing the members meeting, made some mistakes. Mistakes happen, but in order to fix them we need to understand exactly what it was that did happen and why it happened that way. The notices to the RIPE announcement list are irrelevant in this case. --Michael Dillon From gert at space.net Thu Dec 4 16:51:49 2008 From: gert at space.net (Gert Doering) Date: Thu, 4 Dec 2008 16:51:49 +0100 Subject: [address-policy-wg] Revisiting RIPE Policy Proposal 2007-01 In-Reply-To: References: <20081204151909.GF44476@Space.Net> Message-ID: <20081204155148.GG44476@Space.Net> hi, On Thu, Dec 04, 2008 at 03:39:41PM -0000, michael.dillon at bt.com wrote: > > (Oh, btw, maybe I should point out that you are also "part of > > RIPE", > > I don't chair any WGs. "RIPE" is "all of us" - the *community*. The WG chairing thing means I get more work to do, and I'm entitled to wear a coloured badge at RIPE meetings -- but it doesn't make me any more (or less) "part of RIPE" than you are. > > So what is your point?) > > Hank said that he did not get any formal notice that the fee > changes would be voted on at the meeting. Hank did not complain > about any mailing lists. Hank did not complain about any working > groups. > > Hank did complain that the people in the RIPE NCC, who are > responsible for organizing the members meeting, made some > mistakes. Hank complained that he did not receive the announcement mail. This does not necessarily mean that "the people in the RIPE NCC made some mistakes". > Mistakes happen, but in order to fix them we need to understand > exactly what it was that did happen and why it happened that way. I agree with this part... > The notices to the RIPE announcement list are irrelevant in this > case. To the contrary. Mail gets lost due to SPAM filtering or other reasons all day. Having Message-IDs enables people to figure out whether their mailserver has indeed seen the e-mail (and delivered it somewhere or dropped it), or not. Your assumption seems to be "the RIPE NCC is responsible for all evil in the world". You might want to reconsider this position. Gert Doering -- NetMaster -- 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 From michael.dillon at bt.com Thu Dec 4 16:59:51 2008 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Thu, 4 Dec 2008 15:59:51 -0000 Subject: [address-policy-wg] Revisiting RIPE Policy Proposal 2007-01 In-Reply-To: <20081204155148.GG44476@Space.Net> Message-ID: > Your assumption seems to be "the RIPE NCC is responsible for > all evil in the world". You might want to reconsider this position. No that is NOT my assumption. But I do see a certain arrogance on the part of RIPE WG chairs, and RIPE NCC staff. We're all human and make mistakes once in a while, but when you take responsibility for doing a particular job that serves other people, you have to be seen to be helpful. In any case, I did make some wrong assumptions from your first email because you did not explain that it could be a SPAM filter issue, and that looking for the announcement email would be a good check to see if filtering was taking place. Your idea was a good one although I would hope that the RIPE NCC staff do check to see whether they sent out the LIR emails that Hank claims he did not receieve. --Michael Dillon From hank at efes.iucc.ac.il Thu Dec 4 17:37:04 2008 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Thu, 04 Dec 2008 18:37:04 +0200 Subject: [address-policy-wg] Revisiting RIPE Policy Proposal 2007-01 In-Reply-To: <20081204155148.GG44476@Space.Net> References: <20081204151909.GF44476@Space.Net> Message-ID: <5.1.0.14.2.20081204183550.00b0f1f0@efes.iucc.ac.il> At 04:51 PM 04-12-08 +0100, Gert Doering wrote: >Hank complained that he did not receive the announcement mail. This does >not necessarily mean that "the people in the RIPE NCC made some mistakes". > > > Mistakes happen, but in order to fix them we need to understand > > exactly what it was that did happen and why it happened that way. > >I agree with this part... > > > The notices to the RIPE announcement list are irrelevant in this > > case. > >To the contrary. Mail gets lost due to SPAM filtering or other reasons >all day. Having Message-IDs enables people to figure out whether their >mailserver has indeed seen the e-mail (and delivered it somewhere or >dropped it), or not. Can someone from RIPE NCC make a test posting to the ncc-announcements list to see if I get it? Thanks, Hank From flor at ripe.net Thu Dec 4 17:47:00 2008 From: flor at ripe.net (Flor Paredes) Date: Thu, 04 Dec 2008 17:47:00 +0100 Subject: [address-policy-wg] Clarification on End User Assignments Identity Verification Message-ID: <49380984.2040006@ripe.net> 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 From oppermann at networx.ch Thu Dec 4 14:01:11 2008 From: oppermann at networx.ch (Andre Oppermann) Date: Thu, 04 Dec 2008 14:01:11 +0100 Subject: [address-policy-wg] Revisiting RIPE Policy Proposal 2007-01 In-Reply-To: <20081204113737.GY44476@Space.Net> References: <000b01c95545$d0a41b50$71ec51f0$@nl> <493663E9.4060304@ripe.net> <000b01c95545$d0a41b50$71ec51f0$@nl> <5.1.0.14.2.20081204080417.00b18e48@efes.iucc.ac.il> <4937B964.4040507@inex.ie> <4937BD51.1030703@psg.com> <20081204113737.GY44476@Space.Net> Message-ID: <4937D497.1070003@networx.ch> Gert Doering wrote: > Hi, > > On Thu, Dec 04, 2008 at 08:21:53PM +0900, Randy Bush wrote: >>> This was discussed many times at RIPE meetings. Not at just one, but >>> several. The final decision to put this into the charging scheme was made >>> at the General Meeting in Dubai, but it was talked about at a couple of others. >> excuse? i thought decisions are made on list, not at meetings. > > This was one of the core problems of 2007-01 - the APWG can not decide > on the charging scheme. We can discuss things (which we did, here and > in the meetings), but in the end, the charging scheme is decided by the > RIPE members AGM - and it's one of the few things where we actually > decide by *vote* in RIPE land. > > Every RIPE member receives the invitations to the AGM, and the invitation > contained the draft of the to-be-installed charging scheme. It was sent > out well in advance, and there is an option to give proxy votes to other > LIRs if you can't attend yourself. > > The majority of the LIRs that attended the meeting (or sent proxy votes) > voted for the acceptance of the new charging scheme. The problem is that RIPE NCC can't legally retroactively charge feed for something that was, at the time of assignment, covered by a one-time fee. It also raises serious (EU) anti-trust questions. And no, having a "democratic" AGM vote does not make it OK to retroactively disadvantage the members who voted against it or did not vote. -- Andre Oppermann Internet Business Solutions AG Z?rich, Switzerland From bmanning at vacation.karoshi.com Thu Dec 4 14:13:34 2008 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Thu, 4 Dec 2008 13:13:34 +0000 Subject: [address-policy-wg] IPv6 assignment for the RIPE meeting network In-Reply-To: <49370AAB.30506@ignum.cz> References: <49241045.5060707@ripe.net> <49370AAB.30506@ignum.cz> Message-ID: <20081204131334.GA16928@vacation.karoshi.com.> what makes a RIPE meeting any different than say, a GEANT meeting, a IEEE or IETF conference, or any other technical conference of short duration (say 2 weeks long)? there is a precident (and its not all that good) ... back in the day, the IETF was three times a year, the fourth meeting was an Interoperability slam... which became the "Interop" conferences. They argued for the need for a special network block just for them ... and they have a /8 of IPv4 space to this day. --bill On Wed, Dec 03, 2008 at 11:39:39PM +0100, Tomas Hlavacek wrote: > Greetings! > > I am against this. I do not like making a special case out of RIPE > meetings. But I support the basic idea that a conference organizer > should be able to get an IPv6 PI assignment (as 2006-1 is turned into > policy). > > I do not like newly proposed status 'ASSIGNED MEETING' also. > > I would support any prospective policy proposal which makes NCC able to > set a contractual realtionship with itself, if needed to use 2006-1 in > this or in any similar case. > > Best regards, > Tomas Hlavacek > > Andrei Robachevsky wrote: > >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_assignment_for_RIPE_meeting_network.pdf), > > 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 > > From ondrej.sury at nic.cz Thu Dec 4 18:55:07 2008 From: ondrej.sury at nic.cz (=?UTF-8?Q?Ond=C5=99ej_Sur=C3=BD?=) Date: Thu, 4 Dec 2008 18:55:07 +0100 Subject: [address-policy-wg] IPv6 assignment for the RIPE meeting network In-Reply-To: <20081204131334.GA16928@vacation.karoshi.com.> References: <49241045.5060707@ripe.net> <49370AAB.30506@ignum.cz> <20081204131334.GA16928@vacation.karoshi.com.> Message-ID: 2008/12/4 : > > what makes a RIPE meeting any different than say, a GEANT meeting, > a IEEE or IETF conference, or any other technical conference of short duration > (say 2 weeks long)? RIPE region? RIRs can get microallocation in ARIN and APNIC region (maybe LATNIC and AfriNIC). Ondrej. -- Ondrej Sury technicky reditel/Chief Technical Officer ----------------------------------------- CZ.NIC, z.s.p.o. -- .cz domain registry Americka 23,120 00 Praha 2,Czech Republic mailto:ondrej.sury at nic.cz http://nic.cz/ sip:ondrej.sury at nic.cz tel:+420.222745110 mob:+420.739013699 fax:+420.222745112 ----------------------------------------- From gert at space.net Thu Dec 4 19:10:17 2008 From: gert at space.net (Gert Doering) Date: Thu, 4 Dec 2008 19:10:17 +0100 Subject: [address-policy-wg] Revisiting RIPE Policy Proposal 2007-01 In-Reply-To: <5.1.0.14.2.20081204193708.00afc1e8@efes.iucc.ac.il> References: <4937BD51.1030703@psg.com> <000b01c95545$d0a41b50$71ec51f0$@nl> <493663E9.4060304@ripe.net> <000b01c95545$d0a41b50$71ec51f0$@nl> <5.1.0.14.2.20081204080417.00b18e48@efes.iucc.ac.il> <4937B964.4040507@inex.ie> <4937BD51.1030703@psg.com> <5.1.0.14.2.20081204193708.00afc1e8@efes.iucc.ac.il> Message-ID: <20081204181017.GI44476@Space.Net> Hi Hank, On Thu, Dec 04, 2008 at 07:46:17PM +0200, Hank Nussbacher wrote: > >This was one of the core problems of 2007-01 - the APWG can not decide > >on the charging scheme. We can discuss things (which we did, here and > >in the meetings), but in the end, the charging scheme is decided by the > >RIPE members AGM - and it's one of the few things where we actually > >decide by *vote* in RIPE land. > > I reviewed the draft agenda: > http://www.ripe.net/ripe/maillists/archives/address-policy-wg/2008/msg00671.html > but I have as yet to see any protocol from the address-policy-wg or from > the AGM. 2007-01 was only briefly covered on the last RIPE meeting's APWG time - it had already passed last call. So all I did was summarize the results, and tell people that they should attend the AGM because there was a new charging scheme to be decided upon. The minutes for this meeting are not yet done. Need to check with the minute taker where they got stuck (but since the meeting was quite packed, it is a *lot* work to write these, even with audio recording available). > I did find this: > http://www.ripe.net/news/gm-october-2008.html > Interesting that 52 attendees out of 6000 RIPE members are able to make > such a change. 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). I could now argue "the remaining LIRs could have sent proxy votes" and then you can answer "we haven't been invited" - we're turning in a circle, and this is not a good situation and needs to be sorted out. > >Every RIPE member receives the invitations to the AGM, and the invitation > >contained the draft of the to-be-installed charging scheme. It was sent > >out well in advance, and there is an option to give proxy votes to other > >LIRs if you can't attend yourself. > > I am looking into why neither il.isoc and il.iucc did not receive the > announcement. I'm sorry if I came across as "arrogant" here. That wasn't my intention - I really thought that all LIRs would receive these invitations, and I think the best way to sort this out might be to ask lir-help at ripe.net to look into their records - and depending on the outcome, it might be a good idea to make sure that AGM invitations are definitely distributed to the listed admin-c and tech-c contacts for a LIR. Gert Doering -- NetMaster -- 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 305 bytes Desc: not available URL: From Woeber at CC.UniVie.ac.at Thu Dec 4 19:24:07 2008 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Thu, 04 Dec 2008 18:24:07 +0000 Subject: [address-policy-wg] IPv6 assignment for the RIPE meetingnetwork In-Reply-To: <20081203120906.GY44476@Space.Net> References: <49362E6B.8000703@psg.com> <493672F4.1050809@spaghetti.zurich.ibm.com> <20081203120906.GY44476@Space.Net> Message-ID: <49382047.2060205@CC.UniVie.ac.at> Gert Doering wrote: [...] > Which leaves the problem of "an entity assigning to itself, and doing a > contract with itself" - which can be seen as a problem with neutrality. > > Remco has made a suggestion how to tackle *this*, and I see this as the > way forward. This is at least *one* (very good!) suggestion. I can think about another equally simple (and maybe more efficient) one: Submit the request to a different RIR for review and approval :-) > Gert Doering > -- NetMaster Wilfried From Remco.vanMook at eu.equinix.com Thu Dec 4 19:50:14 2008 From: Remco.vanMook at eu.equinix.com (Remco van Mook) Date: Thu, 4 Dec 2008 19:50:14 +0100 Subject: [address-policy-wg] IPv6 assignment for the RIPE meetingnetwork References: <49362E6B.8000703@psg.com> <493672F4.1050809@spaghetti.zurich.ibm.com> <20081203120906.GY44476@Space.Net> <49382047.2060205@CC.UniVie.ac.at> Message-ID: <2E61C47A190CA44ABFCF23147E57E4BC9BFAF6@NLEN1EX1.eu.win.equinix.com> Hi Wilfried, That thought also crossed my mind, and while it sounds more elegant and efficient it would also require a policy change in another RIR :-) I'll try to do a formal policy proposal somewhere in the following weeks. Best, Remco (and it'll give that hat we both have something to do) -----Original Message----- From: address-policy-wg-admin at ripe.net [mailto:address-policy-wg-admin at ripe.net] On Behalf Of Wilfried Woeber, UniVie/ACOnet Sent: donderdag 4 december 2008 19:24 To: address-policy-wg at ripe.net Subject: Re: [address-policy-wg] IPv6 assignment for the RIPE meetingnetwork Gert Doering wrote: [...] > Which leaves the problem of "an entity assigning to itself, and doing a > contract with itself" - which can be seen as a problem with neutrality. > > Remco has made a suggestion how to tackle *this*, and I see this as the > way forward. This is at least *one* (very good!) suggestion. I can think about another equally simple (and maybe more efficient) one: Submit the request to a different RIR for review and approval :-) > Gert Doering > -- NetMaster Wilfried 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. From hank at efes.iucc.ac.il Thu Dec 4 18:46:17 2008 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Thu, 04 Dec 2008 19:46:17 +0200 Subject: [address-policy-wg] Revisiting RIPE Policy Proposal 2007-01 In-Reply-To: <20081204113737.GY44476@Space.Net> References: <4937BD51.1030703@psg.com> <000b01c95545$d0a41b50$71ec51f0$@nl> <493663E9.4060304@ripe.net> <000b01c95545$d0a41b50$71ec51f0$@nl> <5.1.0.14.2.20081204080417.00b18e48@efes.iucc.ac.il> <4937B964.4040507@inex.ie> <4937BD51.1030703@psg.com> Message-ID: <5.1.0.14.2.20081204193708.00afc1e8@efes.iucc.ac.il> At 12:37 PM 04-12-08 +0100, Gert Doering wrote: >Hi, > >On Thu, Dec 04, 2008 at 08:21:53PM +0900, Randy Bush wrote: > > > This was discussed many times at RIPE meetings. Not at just one, but > > > several. The final decision to put this into the charging scheme was > made > > > at the General Meeting in Dubai, but it was talked about at a couple > of others. > > > > excuse? i thought decisions are made on list, not at meetings. > >This was one of the core problems of 2007-01 - the APWG can not decide >on the charging scheme. We can discuss things (which we did, here and >in the meetings), but in the end, the charging scheme is decided by the >RIPE members AGM - and it's one of the few things where we actually >decide by *vote* in RIPE land. I reviewed the draft agenda: http://www.ripe.net/ripe/maillists/archives/address-policy-wg/2008/msg00671.html but I have as yet to see any protocol from the address-policy-wg or from the AGM. I did find this: http://www.ripe.net/news/gm-october-2008.html Interesting that 52 attendees out of 6000 RIPE members are able to make such a change. >Every RIPE member receives the invitations to the AGM, and the invitation >contained the draft of the to-be-installed charging scheme. It was sent >out well in advance, and there is an option to give proxy votes to other >LIRs if you can't attend yourself. I am looking into why neither il.isoc and il.iucc did not receive the announcement. >The majority of the LIRs that attended the meeting (or sent proxy votes) >voted for the acceptance of the new charging scheme. I wouldn't call 52 out of 6000 LIRs a substantial majority. -Hank From hank at efes.iucc.ac.il Thu Dec 4 20:09:01 2008 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Thu, 4 Dec 2008 21:09:01 +0200 (IST) Subject: [address-policy-wg] Revisiting RIPE Policy Proposal 2007-01 In-Reply-To: <20081204181017.GI44476@Space.Net> References: <4937BD51.1030703@psg.com> <000b01c95545$d0a41b50$71ec51f0$@nl> <493663E9.4060304@ripe.net> <000b01c95545$d0a41b50$71ec51f0$@nl> <5.1.0.14.2.20081204080417.00b18e48@efes.iucc.ac.il> <4937B964.4040507@inex.ie> <4937BD51.1030703@psg.com> <5.1.0.14.2.20081204193708.00afc1e8@efes.iucc.ac.il> <20081204181017.GI44476@Space.Net> Message-ID: On Thu, 4 Dec 2008, Gert Doering wrote: >> I did find this: >> http://www.ripe.net/news/gm-october-2008.html >> Interesting that 52 attendees out of 6000 RIPE members are able to make >> such a change. > > 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). > > I could now argue "the remaining LIRs could have sent proxy votes" and > then you can answer "we haven't been invited" - we're turning in a circle, > and this is not a good situation and needs to be sorted out. This troubles me. Imagine RBN setting up 40-50 extra-small LIRs all for under 200-300KEuro and then manipulating the RIPE voting to favor almost any agenda they may have. Having such a criticial infrastructure such as RIPE being "adjusted" by just 52 votes (less than 1% of its members) is sheer madness IMHO. I would have hoped that the RIPE NCC would address this issue and encourage members to come and vote - give a free 8GB DOK if that is what is needed. :-) > I'm sorry if I came across as "arrogant" here. That wasn't my intention > - I really thought that all LIRs would receive these invitations, and I > think the best way to sort this out might be to ask lir-help at ripe.net to > look into their records - and depending on the outcome, it might be a > good idea to make sure that AGM invitations are definitely distributed > to the listed admin-c and tech-c contacts for a LIR. Gert, I don't think you came across arrogant at all. But in addition to distributing the AGM invites to not just ncc-announce but to admin-c and tech-c as you suggest, I would suggest we somehow get a larger pool of LIRs involved to vote - otherwise we may wake up in the near future to some very strange new policies. -Hank > > Gert Doering > -- NetMaster > -- > 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 > From bmanning at vacation.karoshi.com Thu Dec 4 19:53:52 2008 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Thu, 4 Dec 2008 18:53:52 +0000 Subject: [address-policy-wg] IPv6 assignment for the RIPE meeting network In-Reply-To: References: <49241045.5060707@ripe.net> <49370AAB.30506@ignum.cz> <20081204131334.GA16928@vacation.karoshi.com.> Message-ID: <20081204185352.GA19212@vacation.karoshi.com.> On Thu, Dec 04, 2008 at 06:55:07PM +0100, OndEej SurC= wrote: > 2008/12/4 : > > > > what makes a RIPE meeting any different than say, a GEANT meeting, > > a IEEE or IETF conference, or any other technical conference of short duration > > (say 2 weeks long)? > > RIPE region? RIRs can get microallocation in ARIN and APNIC region > (maybe LATNIC and AfriNIC). sure... any of these types of conferences -IN THE RIPE REGION- are going to need address space. they can all go get their own and pummel the routing system w/ adds/deletes as the come/go... or... one prefix could be carved out and handed to whomever needs it this week/month. > > Ondrej. > -- > Ondrej Sury > technicky reditel/Chief Technical Officer > ----------------------------------------- > CZ.NIC, z.s.p.o. -- .cz domain registry > Americka 23,120 00 Praha 2,Czech Republic > mailto:ondrej.sury at nic.cz http://nic.cz/ > sip:ondrej.sury at nic.cz tel:+420.222745110 > mob:+420.739013699 fax:+420.222745112 > ----------------------------------------- From clive at demon.net Fri Dec 5 09:34:08 2008 From: clive at demon.net (Clive D.W. Feather) Date: Fri, 5 Dec 2008 08:34:08 +0000 Subject: [address-policy-wg] Revisiting RIPE Policy Proposal 2007-01 In-Reply-To: <20081204181017.GI44476@Space.Net> References: <4937BD51.1030703@psg.com> <000b01c95545$d0a41b50$71ec51f0$@nl> <493663E9.4060304@ripe.net> <000b01c95545$d0a41b50$71ec51f0$@nl> <5.1.0.14.2.20081204080417.00b18e48@efes.iucc.ac.il> <4937B964.4040507@inex.ie> <4937BD51.1030703@psg.com> <5.1.0.14.2.20081204193708.00afc1e8@efes.iucc.ac.il> <20081204181017.GI44476@Space.Net> Message-ID: <20081205083408.GA34056@finch-staff-1.thus.net> Gert Doering said: > > Interesting that 52 attendees out of 6000 RIPE members are able to make > > such a change. > > 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. -- Clive D.W. Feather | Work: | Tel: +44 20 8495 6138 Internet Expert | Home: | Fax: +44 870 051 9937 Demon Internet | WWW: http://www.davros.org | Mobile: +44 7973 377646 THUS - a Cable and Wireless business From alexlh at ripe.net Fri Dec 5 15:18:05 2008 From: alexlh at ripe.net (Alex Le Heux) Date: Fri, 5 Dec 2008 15:18:05 +0100 Subject: [address-policy-wg] IPv6 assignment for the RIPE meetingnetwork In-Reply-To: <4937F946.8090208@inex.ie> References: <49362E6B.8000703@psg.com> <493663E9.4060304@ripe.net> <4937C636.3050900@inex.ie> <4937ECA5.3090007@ripe.net> <4937F946.8090208@inex.ie> Message-ID: Dear Nick, Please see RIPE NCC Registration Services' answer to your questions ragarding proposal 2006-01 below: > More generally, if Organisation X already holds IPv6 space, whether > PA or > PI, and where: > > 1. they are not using the entire address block for their > infrastructural needs, > 2. they intend to organise an event which requires a separate IPv6 > address > block for routing purposes, > 3. the total number of /64s required for both their normal > infrastructural > needs and their event requirements does not exceed their existing ipv6 > assignment > 4. that assignment is either for a once-off or a periodically > recurring meeting > > then in this situation, would the RIPE NCC registration department > be happy > to assign an ipv6 address block for that purpose? My take on this is > probably not. But it would be helpful to get a formal opinion from > this > from the RIPE NCC. The current version of proposal 2006-01 contains the provisions for assigning more than a single /48 to an organisation: > Additional assignments may also be made when there is a technical > need demanding > this or usage justified. When possible, these further assignments > will be made > from an adjacent address block. Only very large networks would qualify for multiple /48 subnets under the "usage justified" provision. However, networks that have multiple unconnected end-sites and intend to originate the prefixes from different ASNs could qualify under the "technical need" criterion. So an organisation that has received a prefix for its infrastructure could still qualify for an additional assignment for organising a meeting, although this would depend on the details of their network setup. In the specific case of the RIPE NCC organising the RIPE meeting, the issue of the contractual relationship would have to be resolved first. Best regards, Alex Le Heux RIPE NCC Policy Implementation Co-ordinator From sander at steffann.nl Fri Dec 5 16:31:46 2008 From: sander at steffann.nl (Sander Steffann) Date: Fri, 5 Dec 2008 16:31:46 +0100 Subject: [address-policy-wg] Revisiting RIPE Policy Proposal 2007-01 Message-ID: <2CC5908E-7BF1-4489-BBEA-13A5C8C2BC31@steffann.nl> 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 at 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 From drc at virtualized.org Fri Dec 5 18:20:28 2008 From: drc at virtualized.org (David Conrad) Date: Fri, 5 Dec 2008 09:20:28 -0800 Subject: [address-policy-wg] IPv6 assignment for the RIPE meeting network In-Reply-To: <20081204185352.GA19212@vacation.karoshi.com.> References: <49241045.5060707@ripe.net> <49370AAB.30506@ignum.cz> <20081204131334.GA16928@vacation.karoshi.com.> <20081204185352.GA19212@vacation.karoshi.com.> Message-ID: On Dec 4, 2008, at 10:53 AM, bmanning at vacation.karoshi.com wrote: > On Thu, Dec 04, 2008 at 06:55:07PM +0100, OndEej SurC= wrote: >> 2008/12/4 : >>> what makes a RIPE meeting any different than say, a GEANT meeting, >>> a IEEE or IETF conference, or any other technical conference of >>> short duration >>> (say 2 weeks long)? >> >> RIPE region? RIRs can get microallocation in ARIN and APNIC region >> (maybe LATNIC and AfriNIC). > > > sure... any of these types of conferences -IN THE RIPE REGION- are > going > to need address space. they can all go get their own and pummel > the routing > system w/ adds/deletes as the come/go... You're aware, of course, that this would be so far down in the noise in the routing flux that only the terminally pedantic would notice, right? > or... one prefix could be carved out and handed to whomever needs it > this week/month. Long ago, APNIC dedicated a block of /16s to show networks. Don't know if that's still the use of that block. One interesting side note: it turned out that connectivity contracts for shows had significantly longer duration than the shows themselves. On several occasions the ISP for the old show refused to stop announcing the prefix APNIC allocated for the show because they had a contract that required them to announce the address space. The fact that the prefix was no longer registered to the show operator in the APNIC was irrelevant. Much entertainment ensued. But that was long ago. I'm sure things are much better now. Regards, -drc From andreas at schachtner.eu Sat Dec 6 09:36:33 2008 From: andreas at schachtner.eu (Andreas Schachtner) Date: Sat, 06 Dec 2008 09:36:33 +0100 Subject: [address-policy-wg] IPv6 assignment for the RIPE meeting network In-Reply-To: References: <49241045.5060707@ripe.net> <49370AAB.30506@ignum.cz> <20081204131334.GA16928@vacation.karoshi.com.> <20081204185352.GA19212@vacation.karoshi.com.> Message-ID: <20081206083633.564544F0C7@footsu.site> > On Dec 4, 2008, at 10:53 AM, bmanning at vacation.karoshi.com wrote: ... > > > > > > sure... any of these types of conferences -IN THE RIPE REGION- are > > going > > to need address space. they can all go get their own and pummel > > the routing > > system w/ adds/deletes as the come/go... > > You're aware, of course, that this would be so far down in the noise > in the routing flux that only the terminally pedantic would notice, > right? And, of course, announcing the same prefix from different origins causes just the same ... Regards, Andreas -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 233 bytes Desc: not available URL: From jwkckid1 at ix.netcom.com Sat Dec 6 05:20:27 2008 From: jwkckid1 at ix.netcom.com (Jeffrey A. Williams) Date: Fri, 05 Dec 2008 20:20:27 -0800 Subject: [address-policy-wg] Revisiting RIPE Policy Proposal 2007-01 References: Message-ID: <4939FD8B.B83D1B74@ix.netcom.com> Michael and all, Is this suppose to be surprising? After all isn't this the attitude of what "Authoritative" is supposed to be? Aren't all RIR's always right, and therefore omnipotent? How could anyone DARE question even in the slightest way, on any issue, or response to a question, unless they were irreverent, irresponsible, disrespectful, disruptive, or even insane? >:) michael.dillon at bt.com wrote: > > The invitation goes to the ripe announcement list. One of > > them had the following headers...: > > This message illustrates a disturbing trend with RIPE. > People associated with RIPE, either the NCC or otherwise, > seem to always assume that RIPE is right, and the LIR is > wrong. Then they write an email that demonstrates to > a careful reader, that RIPE is wrong or confused or > too lazy to take the time to read the original email. > > --Michael Dillon 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 at ix.netcom.com My Phone: 214-244-4827 From hank at efes.iucc.ac.il Sun Dec 7 12:05:39 2008 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Sun, 07 Dec 2008 13:05:39 +0200 Subject: [address-policy-wg] Revisiting RIPE Policy Proposal 2007-01 In-Reply-To: <5.1.0.14.2.20081204142836.0576fae0@efes.iucc.ac.il> References: <20081204113737.GY44476@Space.Net> <4937BD51.1030703@psg.com> <000b01c95545$d0a41b50$71ec51f0$@nl> <493663E9.4060304@ripe.net> <000b01c95545$d0a41b50$71ec51f0$@nl> <5.1.0.14.2.20081204080417.00b18e48@efes.iucc.ac.il> <4937B964.4040507@inex.ie> <4937BD51.1030703@psg.com> Message-ID: <5.1.0.14.2.20081207130419.0584ae40@efes.iucc.ac.il> At 02:29 PM 04-12-08 +0200, Hank Nussbacher wrote: >At 12:37 PM 04-12-08 +0100, you wrote: >>Every RIPE member receives the invitations to the AGM, and the invitation >>contained the draft of the to-be-installed charging scheme. It was sent >>out well in advance, and there is an option to give proxy votes to other >>LIRs if you can't attend yourself. > >I am also a LIR contact for il.iucc and il.isoc and both did not receive >an invitation and I did not see any drafts as discussed. Can you find out >to which email address they sent those docs for il.iucc and il.isoc? Just to let everyone know that checking mail logs shows that the AGM email did indeed arrive at my mailbox for il.iucc and at the LIR rep for il.isoc. -Hank From shane at time-travellers.org Mon Dec 8 11:26:20 2008 From: shane at time-travellers.org (Shane Kerr) Date: Mon, 08 Dec 2008 11:26:20 +0100 Subject: [address-policy-wg] IPv6 assignment for the RIPE meetingnetwork In-Reply-To: References: Message-ID: <1228731980.21250.237.camel@shane-macbook-pro> On Wed, 2008-12-03 at 15:58 +0000, michael.dillon at bt.com wrote: > > Which leaves the problem of "an entity assigning to itself, > > and doing a contract with itself" - which can be seen as a > > problem with neutrality. > > We aren't lawyers. Why are you asking us to solve legal problems. > Any lawyer will tell you that this is simple. Incorporate an > entity separate from the NCC that will organize meetings. It can > have the same board of directors as the NCC, or some other arrangement > if you wish. This organization can then sign contracts with the > RIPE NCC. The RIPE NCC no longer has to worry about RIPE meetings > because RIPE now deals with a separate organization to hold the > meetings. 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 The conflict of interest having the RIPE NCC evaluate it's own request for 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 if I'm about to see a rabbit with a stopwatch running past declaring "I'm late, I'm late!". (*) -- Shane (*) Perhaps the rabbit is talking about the state of his IPv6 deployments though... From sander at steffann.nl Mon Dec 8 14:21:01 2008 From: sander at steffann.nl (Sander Steffann) Date: Mon, 08 Dec 2008 14:21:01 +0100 Subject: [address-policy-wg] IPv6 assignment for the RIPE meetingnetwork In-Reply-To: <1228731980.21250.237.camel@shane-macbook-pro> References: <1228731980.21250.237.camel@shane-macbook-pro> Message-ID: <493D1F3D.3010300@steffann.nl> 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 for 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 if 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/msg00745.html) and offered to try to write a formal policy proposal (http://www.ripe.net/ripe/maillists/archives/address-policy-wg/2008/msg00823.html). I think this is the best way forward and we should give Remco some time to work on that policy proposal. Sander From anamatic at ripe.net Mon Dec 8 16:48:59 2008 From: anamatic at ripe.net (Ana Matic) Date: Mon, 08 Dec 2008 16:48:59 +0100 Subject: [address-policy-wg] 2008-05 Revised/New Discussion Phase set (Anycasting Assignments for TLD's and Tier 0/1 ENUM) Message-ID: <20081208154859.869BA2F592@herring.ripe.net> 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 before 5 January 2009. Regards, Ana Matic RIPE NCC Asst. Policy Development Officer From tomas.hlavacek at elfove.cz Tue Dec 9 01:57:14 2008 From: tomas.hlavacek at elfove.cz (Tomas Hlavacek) Date: Tue, 09 Dec 2008 01:57:14 +0100 Subject: [address-policy-wg] 2008-05 Revised/New Discussion Phase set (Anycasting Assignments for TLD's and Tier 0/1 ENUM) In-Reply-To: <20081208154859.869BA2F592@herring.ripe.net> References: <20081208154859.869BA2F592@herring.ripe.net> Message-ID: <493DC26A.8010102@elfove.cz> Greetings! I support this proposal. Usually I do not like making special cases and introducing any inequality. But I understand that gTLD, ccTLD and ENUM tier 0/1 deserves some kind of special treatment. And I think we would be against ourselves blocking TLD and ENUM tier 0/1 operators from making their service more resilient and secure. Best regards, Tomas Hlavacek Ana Matic wrote: > 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 before 5 January 2009. > > Regards, > > Ana Matic > RIPE NCC > Asst. Policy Development Officer > > > -- Tomas Hlavacek From john.crain at icann.org Tue Dec 9 18:58:16 2008 From: john.crain at icann.org (John L. Crain) Date: Tue, 9 Dec 2008 09:58:16 -0800 Subject: [address-policy-wg] IPv6 assignment for the RIPE meetingnetwork In-Reply-To: <493D1F3D.3010300@steffann.nl> Message-ID: 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 check 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" 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 for >> 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 if 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/msg00745.h > tml) > and offered to try to write a formal policy proposal > (http://www.ripe.net/ripe/maillists/archives/address-policy-wg/2008/msg00823.h > tml). > > I think this is the best way forward and we should give Remco some time > to work on that policy proposal. > Sander > From Antoin.Verschuren at sidn.nl Wed Dec 10 12:21:40 2008 From: Antoin.Verschuren at sidn.nl (Antoin Verschuren) Date: Wed, 10 Dec 2008 12:21:40 +0100 Subject: [address-policy-wg] 2008-05 Revised/New Discussion Phase set (Anycasting Assignments for TLD's and Tier 0/1 ENUM) Message-ID: <850A39016FA57A4887C0AA3C8085F949642AB3@KAEVS1.SIDN.local> 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 at sidn.nl W http://www.sidn.nl/ From leo.vegoda at icann.org Wed Dec 10 15:08:42 2008 From: leo.vegoda at icann.org (Leo Vegoda) Date: Wed, 10 Dec 2008 06:08:42 -0800 Subject: [address-policy-wg] 2008-05 Revised/New Discussion Phase set (Anycasting Assignments for TLD's and Tier 0/1 ENUM) In-Reply-To: <20081208154859.869BA2F592@herring.ripe.net> Message-ID: 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 From mueller at syr.edu Wed Dec 10 16:13:18 2008 From: mueller at syr.edu (Milton L Mueller) Date: Wed, 10 Dec 2008 10:13:18 -0500 Subject: [address-policy-wg] New paper on RIRs by Internet Governance Project Message-ID: <7663C7E01D8E094989CA62F0B0D21CD9023CA56E@SUEXCL-02.ad.syr.edu> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From Remco.vanMook at eu.equinix.com Wed Dec 10 21:05:43 2008 From: Remco.vanMook at eu.equinix.com (Remco van Mook) Date: Wed, 10 Dec 2008 21:05:43 +0100 Subject: [address-policy-wg] DRAFT: allocating resources to the RIPE NCC Message-ID: <2E61C47A190CA44ABFCF23147E57E4BC9BFF68@NLEN1EX1.eu.win.equinix.com> 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. Best, Remco Number: (assigned by the RIPE NCC) Policy Proposal Name: Allocating resources to the RIPE NCC Author: name: Remco van Mook email: remco at eu.equinix.com organisation: Equinix Proposal Version: 1.0 Submission Date: TBD Suggested RIPE WG for discussion and publication: address policy Proposal Type: new Policy Term: permanent Summary of proposal: This proposal sets the way in which the RIPE NCC can get resources allocated to itself. Policy text: 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. 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. 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. 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 None. 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. From jwkckid1 at ix.netcom.com Wed Dec 10 05:10:11 2008 From: jwkckid1 at ix.netcom.com (Jeffrey A. Williams) Date: Tue, 09 Dec 2008 20:10:11 -0800 Subject: [address-policy-wg] 2008-05 Revised/New Discussion Phase set (Anycasting Assignments for TLD's and Tier 0/1 ENUM) References: <850A39016FA57A4887C0AA3C8085F949642AB3@KAEVS1.SIDN.local> Message-ID: <493F4123.A013F324@ix.netcom.com> 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 at 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 at ix.netcom.com My Phone: 214-244-4827 From arunrkaushik at gmail.com Thu Dec 11 13:15:32 2008 From: arunrkaushik at gmail.com (Arun Kaushik) Date: Thu, 11 Dec 2008 17:45:32 +0530 Subject: [address-policy-wg] Re: address-policy-wg digest, Vol 1 #892 - 8 msgs In-Reply-To: <20081211110003.23920.76940.Mailman@postboy.ripe.net> References: <20081211110003.23920.76940.Mailman@postboy.ripe.net> Message-ID: <12ff90df0812110415p11285141o89f06a778f4ce830@mail.gmail.com> 2008/12/11 > Send address-policy-wg mailing list submissions to > address-policy-wg at 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 at ripe.net > > You can reach the person managing the list at > address-policy-wg-admin at 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" > To: Sander Steffann , Shane Kerr > > CC: "address-policy-wg at 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" 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" > To: > > 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 at sidn.nl > W http://www.sidn.nl/ > > > > --__--__-- > > Message: 3 > From: Leo Vegoda > To: "address-policy-wg at 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 > To: > 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 > > xmlns:w=3D"urn:schemas-microsoft-com:office:word" = > xmlns=3D"http://www.w3.org/TR/REC-html40"> > > > charset=3Dus-ascii"> > > > > > > > >
> >

face=3D"Times New Roman">Regional = > Address > Registries, Governance and Internet Freedom

> >

style=3D'font-size: > 10.0pt'> 

> >

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.

> >

face=3D"Times New Roman"> style=3D'font-size:11.0pt;font-style:italic'>  nt>

> >

face=3D"Times New Roman">Download: href=3D"http://internetgovernance.org/pdf/RIRs-IGP-hyderabad.pdf">http://= > internetgovernance.org/pdf/RIRs-IGP-hyderabad.pdf >

> >

face=3D"Times New Roman"> style=3D'font-size:10.0pt'> 

> >
> > > > > > ------_=_NextPart_001_01C95AD9.D45EE8D6-- > > > --__--__-- > > Message: 5 > Date: Wed, 10 Dec 2008 21:05:43 +0100 > From: "Remco van Mook" > To: > 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 at 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" > Organization: IDNS and Spokesman for INEGroup > To: Antoin Verschuren > CC: address-policy-wg at 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 at 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 at ix.netcom.com > My Phone: 214-244-4827 > > > > > End of address-policy-wg Digest > -- Thanks & Regards, Arun Kaushik. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pk at DENIC.DE Thu Dec 11 13:26:24 2008 From: pk at DENIC.DE (Peter Koch) Date: Thu, 11 Dec 2008 13:26:24 +0100 Subject: [address-policy-wg] 2008-05 Revised/New Discussion Phase set (Anycasting Assignments for TLD's and Tier 0/1 ENUM) In-Reply-To: <850A39016FA57A4887C0AA3C8085F949642AB3@KAEVS1.SIDN.local> References: <850A39016FA57A4887C0AA3C8085F949642AB3@KAEVS1.SIDN.local> Message-ID: <20081211122624.GG30676@unknown.office.denic.de> On Wed, Dec 10, 2008 at 12:21:40PM +0100, Antoin Verschuren wrote: > PDP Number: 2008-05 > Anycasting Assignments for TLD's and Tier 0/1 ENUM I'm a little less happy than Leo to see the external reference vanish, but I'm happy to no longer see it being extended to ENUM, because it wouldn't have been applicable there. Not only are ENUM Tier1 delegations not subject to IANA's tests, also the 512 octet boundary doesn't make much sense in the ENUM context. That said, it is an honest appreciation of operational practice to see the 512 boundary disappear, since it is no longer the only reason to deploy DNS anycast. Therefore, the pro argument # If deployment of anycast is increased it could keep (or decrease) the number # of NS records per TLD/ENUM, in turn this would enable operators to keep DNS # reply size low even with DNSSEC. appears a bit misleading to me. It could go without harm. # Critical DNS infrastructure is defined as infrastructure providing # Authoritative TLD or ENUM Tier 0/1 DNS lookup services. Critical [DNS] infrastructure is a loaded term, and I don't see the necessity to make that definition here, given that it's used only twice in the following text. However, we can take the terminology debate to the DNS (and ENUM) WGs. > 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" # "The organisation(s) applicable under this policy are TLDs operators as defined # by IANA and ENUM operators as defined by the ITU." I don't think it should say "defined" here at all, neither ITU nor the NCC nor IANA (in the case of TLDs). The point is to assign in accordance with the records kept by IANA and the Tier0 registry, respectively. Speaking of definition, though, any reference for the terms "Tier0" and "Tier1" in this context anyone? When the policy refers to operators, I'm sure that aims at the registry in charge, not the actual DNS operators, in cases where these entities differ. # "These prefixes must be used for the sole purpose of anycasting authoratitve # DNS servers for the stated TLD/ENUM, as described in RFC 3258." Understood this is mostly original text, I'd like to suggest the reference be adjusted to cover RFC 4786/BCP 126. Also, while DNS is and should remain the driving factor, "the sole purpose" is a bit restrictive, since one might want to co-locate other services, e.g. DCHK/IRIS, with the name service, which would not be allowed under the current text. -Peter From jim at rfc1035.com Thu Dec 11 14:12:30 2008 From: jim at rfc1035.com (Jim Reid) Date: Thu, 11 Dec 2008 13:12:30 +0000 Subject: [address-policy-wg] 2008-05 Revised/New Discussion Phase set (Anycasting Assignments for TLD's and Tier 0/1 ENUM) In-Reply-To: <850A39016FA57A4887C0AA3C8085F949642AB3@KAEVS1.SIDN.local> References: <850A39016FA57A4887C0AA3C8085F949642AB3@KAEVS1.SIDN.local> Message-ID: <291FFBC5-198F-4325-B471-A6FE99941216@rfc1035.com> On Dec 10, 2008, at 11:21, Antoin Verschuren wrote: > I think it should say: > > "ENUM tier0/1 operators as defined by RIPE NCC" I don't think it should say this either Antoin. :-( The NCC does not define the ENUM operators: its role in ENUM is strictly neutral. Strictly speaking, IAB chose the NCC as the ENUM Tier-0 registry and the National Administrations select their corresponding Tier-1 registry. I suggest the following language/definition: Critical Infrastructure Domain: a TLD listed in the IANA database (insert URL here), e164.arpa or any delegation of e164.arpa made according to the arrangements in place between RIPE NCC, IAB and ITU-T (insert url here). Then in the modified 6.9 for RIPE424 say something like The organisation(s) applicable under this policy are operators of Critical Infrastructure Domains. I'm uneasy about explicitly listing e164.arpa since this means the NCC would in principle be able to allocate resources to itself. This might not be wise. Another concern here is ICANN's plans for lots of new TLDs. Though I expect we'll be out of IPv4 space before those TLDs come on-line. And here's a wider question: do these allocations of /24s for infrastructure anycasting go to the registry operator or should they be linked to the domain name? ie If the registry for .nl or 1.3.e163.arpa moves from SIDN, do any anycast allocations for these domains stay with SIDN or would they go back to the NCC or get transferred to the new registry operator? From filiz at ripe.net Tue Dec 16 16:06:42 2008 From: filiz at ripe.net (Filiz Yilmaz) Date: Tue, 16 Dec 2008 16:06:42 +0100 Subject: [address-policy-wg] 2007-08 Proposal Accepted (Enabling Methods for Reallocation of IPv4 Resources) Message-ID: <20081216150642.3680F2F583@herring.ripe.net> PDP Number: 2007-08 Enabling Methods for Reallocation of IPv4 Resources Dear Colleagues, Consensus has been reached, and the proposal described in 2007-08, "Enabling Methods for Reallocation of IPv4 Resources" has been accepted by the RIPE community. The related RIPE policy document is now updated, published and can be found at: http://www.ripe.net/ripe/docs/ripe-441.html or http://www.ripe.net/ripe/docs/ipv4-policies.html Further implementation details of this policy will follow soon. The proposal is now archived and can be found at: http://www.ripe.net/ripe/policies/proposals/2007-08.html Thank you for your input. Regards Filiz Yilmaz Policy Development Officer RIPE NCC From brettlists at gmail.com Tue Dec 16 16:20:30 2008 From: brettlists at gmail.com (B C) Date: Tue, 16 Dec 2008 15:20:30 +0000 Subject: [address-policy-wg] 2008-05 Revised/New Discussion Phase set (Anycasting Assignments for TLD's and Tier 0/1 ENUM) In-Reply-To: <5c494b510812110225qdcd60f6x5342070c8344a7ac@mail.gmail.com> References: <850A39016FA57A4887C0AA3C8085F949642AB3@KAEVS1.SIDN.local> <5c494b510812110225qdcd60f6x5342070c8344a7ac@mail.gmail.com> Message-ID: <5c494b510812160720l397d3530w59265e221f0ea9bf@mail.gmail.com> I just realised that I responded directly to Antoin and missed cc to the group, so here was my response, apologies for the confusion. On Thu, Dec 11, 2008 at 10:25 AM, B C wrote: > On Wed, Dec 10, 2008 at 11:21 AM, 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. >> However the reason this was put there is that as I undertstand this area, it's not the RIPE NCC's responsibility who gets an ENUM Country Code, those are I believe approved by the ITU and then administred by the RIPE NCC. So I think "ENUM tier0/1 operators as defined by RIPE NCC" would be factually incorrect. Regards Brett From brettlists at gmail.com Tue Dec 16 16:38:37 2008 From: brettlists at gmail.com (B C) Date: Tue, 16 Dec 2008 15:38:37 +0000 Subject: [address-policy-wg] 2008-05 Revised/New Discussion Phase set (Anycasting Assignments for TLD's and Tier 0/1 ENUM) In-Reply-To: <291FFBC5-198F-4325-B471-A6FE99941216@rfc1035.com> References: <850A39016FA57A4887C0AA3C8085F949642AB3@KAEVS1.SIDN.local> <291FFBC5-198F-4325-B471-A6FE99941216@rfc1035.com> Message-ID: <5c494b510812160738m3f92e57bx73555e6ebb80aea6@mail.gmail.com> Jim, On Thu, Dec 11, 2008 at 1:12 PM, Jim Reid wrote: > On Dec 10, 2008, at 11:21, Antoin Verschuren wrote: > >> I think it should say: >> >> "ENUM tier0/1 operators as defined by RIPE NCC" > > I don't think it should say this either Antoin. :-( The NCC does not define > the ENUM operators: its role in ENUM is strictly neutral. Strictly speaking, > IAB chose the NCC as the ENUM Tier-0 registry and the National > Administrations select their corresponding Tier-1 registry. > > I suggest the following language/definition: > > Critical Infrastructure Domain: a TLD listed in the IANA database (insert > URL here), e164.arpa or any delegation of e164.arpa made according to the > arrangements in place between RIPE NCC, IAB and ITU-T (insert url here). > When we were ediiting this document we had something very similar to this on the table but it was decided having the explicit url's in the document was a bad thing because if/when they changed it would break the policy. We figured the hostmasters at the NCC would know where to find the relevant definitive list and therefore it didn't need to be explicitly reffered to with a direct url in the document. > Then in the modified 6.9 for RIPE424 say something like > > The organisation(s) applicable under this policy are operators of Critical > Infrastructure Domains. > > > I'm uneasy about explicitly listing e164.arpa since this means the NCC would > in principle be able to allocate resources to itself. This might not be > wise. Another concern here is ICANN's plans for lots of new TLDs. Though I > expect we'll be out of IPv4 space before those TLDs come on-line. > Well the intention of the policy is to allow Tier0 and Tier1 ENUM operators to receive the allocations so by definition yes this does mean the NCC can make an allocation to itself, but is this really a bad thing as long as there is a reaonable hard limit (in this case 4 /24's) after all there are other areas where the NCC has allocated address space to itself and I don't believe this has caused a problem. > And here's a wider question: do these allocations of /24s for infrastructure > anycasting go to the registry operator or should they be linked to the > domain name? ie If the registry for .nl or 1.3.e163.arpa moves from SIDN, do > any anycast allocations for these domains stay with SIDN or would they go > back to the NCC or get transferred to the new registry operator? > The intention of the policy is that they are allocated to the national operator of ENUM, so for example in the UK, UKEC would be given the allocations for ENUM who would then (hopefully) allow Nominet to use those allocations while they were the registry/dns operator, If/when UKEC decide to move the registry/dns operator to another entity they can then ask Nominet to stop announcing the prefixes so the new registry/dns operator can use them. If this isn't clear in the wording I would welcome an edit. Thanks Brett Carr Nominet From brettlists at gmail.com Wed Dec 17 21:41:29 2008 From: brettlists at gmail.com (B C) Date: Wed, 17 Dec 2008 20:41:29 +0000 Subject: [address-policy-wg] DRAFT: allocating resources to the RIPE NCC In-Reply-To: <2E61C47A190CA44ABFCF23147E57E4BC9BFF68@NLEN1EX1.eu.win.equinix.com> References: <2E61C47A190CA44ABFCF23147E57E4BC9BFF68@NLEN1EX1.eu.win.equinix.com> Message-ID: <5c494b510812171241p27018e21v3b4f88c729cbd50a@mail.gmail.com> Remco, One question springs to mind initially: >This policy applies to all resources, current and future, allocated >to the RIPE NCC, its subsidiaries or affiliates. So presumably this means all current allocations that have been made to the NCC will be subject to external approval, what happens where the arbiter does not approve those current allocations? Presumably the NCC will need to return them and if so under what timescale? I think we need to be careful that we don't cause operational difficulties here. Brett On Wed, Dec 10, 2008 at 8:05 PM, Remco van Mook wrote: > 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. > > Best, > > Remco > > > Number: (assigned by the RIPE NCC) > Policy Proposal Name: Allocating resources to the RIPE NCC > Author: > name: Remco van Mook > email: remco at eu.equinix.com > organisation: Equinix > > Proposal Version: 1.0 > > Submission Date: TBD > > Suggested RIPE WG for discussion and publication: address policy > > Proposal Type: new > > Policy Term: permanent > > Summary of proposal: > This proposal sets the way in which the RIPE NCC can get resources > allocated to itself. > > Policy text: > 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. > > 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. > > 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. > > 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 > None. > > > 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. > > From Remco.vanMook at eu.equinix.com Wed Dec 17 22:31:41 2008 From: Remco.vanMook at eu.equinix.com (Remco van Mook) Date: Wed, 17 Dec 2008 22:31:41 +0100 Subject: [address-policy-wg] DRAFT: allocating resources to the RIPE NCC References: <2E61C47A190CA44ABFCF23147E57E4BC9BFF68@NLEN1EX1.eu.win.equinix.com> <5c494b510812171241p27018e21v3b4f88c729cbd50a@mail.gmail.com> Message-ID: <2E61C47A190CA44ABFCF23147E57E4BC9C051F@NLEN1EX1.eu.win.equinix.com> Hi Brett, I only intended the policy to be retroactive in the sense that all resources allocated to the NCC should be (re)registered under the eu.ripencc handle. I have no intention whatsoever to have a look again at all resources that have been previously allocated - if they are unnecessary surely the NCC would have already returned them, right ? :-) I'll think about a change in the text to clarify this. Thanks for your feedback! Best, Remco -----Original Message----- From: B C [mailto:brettlists at gmail.com] Sent: woensdag 17 december 2008 21:41 To: Remco van Mook; address-policy-wg at ripe.net Subject: Re: [address-policy-wg] DRAFT: allocating resources to the RIPE NCC Remco, One question springs to mind initially: >This policy applies to all resources, current and future, allocated >to the RIPE NCC, its subsidiaries or affiliates. So presumably this means all current allocations that have been made to the NCC will be subject to external approval, what happens where the arbiter does not approve those current allocations? Presumably the NCC will need to return them and if so under what timescale? I think we need to be careful that we don't cause operational difficulties here. Brett On Wed, Dec 10, 2008 at 8:05 PM, Remco van Mook wrote: > 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. > > Best, > > Remco > > > Number: (assigned by the RIPE NCC) > Policy Proposal Name: Allocating resources to the RIPE NCC > Author: > name: Remco van Mook > email: remco at eu.equinix.com > organisation: Equinix > > Proposal Version: 1.0 > > Submission Date: TBD > > Suggested RIPE WG for discussion and publication: address policy > > Proposal Type: new > > Policy Term: permanent > > Summary of proposal: > This proposal sets the way in which the RIPE NCC can get resources > allocated to itself. > > Policy text: > 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. > > 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. > > 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. > > 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 > None. > > > 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. > > From alradhi2000 at yahoo.ca Mon Dec 29 12:53:00 2008 From: alradhi2000 at yahoo.ca (Alaa Al-Din Al-Radhi) Date: Mon, 29 Dec 2008 03:53:00 -0800 (PST) Subject: [address-policy-wg] =?utf-8?B?UmVjZW50IFByZWRlc3RpbmF0aW9ucyDigJMgRW5kIE5vdiAyMDA4LCBUdW5p?= =?utf-8?B?c2lh?= Message-ID: <563761.76941.qm@web35308.mail.mud.yahoo.com> Dear Colleagues / Friends ? Kind respects and happy New Year ? Allow me to seize this moment to share with you the attached recent PPTs that I have presented (as being hired as an ITU regional consultant) in Tunisia lately. Feel free to disseminate these PPTs to related interested parties. I believe firmly in knowledge share. ? Your comments and notes are kindly appreciated. ? If I can be of any future help to your mission, that would be my pleasure and honor. ? All Blessings and respects ? Alaa Al-Din (Aladdin) Passionate / Advocate of: Internet, Science, technology, innovations and new frontiers. + 962 796347600 alradhi2000 at yahoo.ca, alaalradhi at hotmail.com ? http://www.linkedin.com/in/alaaaldinalradhi? ? http://aso.icann.org/elections/radhi.html ? http://www.pir.org/index.php?db=content/Website&tbl=About_Us&id=7#aalradhi? ? http://akms.org/site_content.aspx?page_key=board_of_trustees&lang=en? ? http://www.isoc.org/pubpolpillar/governance/igf-hyderabad_ambassadors.shtml ? Excellence is never an accident; it?s always the result of high intention, sincere effort, intelligent direction, skilful execution and the vision to see obstacles as opportunities __________________________________________________________________ Connect with friends from any web browser - no download required. Try the new Yahoo! Canada Messenger for the Web BETA at http://ca.messenger.yahoo.com/webmessengerpromo.php -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Alaa Al-Din (Aladdin ) Jawad Kadhem Al-Radhi - Recent PPTs - ITU -End Nov 2008.zip Type: application/x-zip-compressed Size: 2908530 bytes Desc: not available URL: