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@ripe.net [mailto:address-policy-wg-admin@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@ripe.net Subject: Re: [address-policy-wg] IPv6 assignment for the RIPE meetingnetwork Hi Andrei, On 03/12/2008 11:48, "Andrei Robachevsky" <andrei@ripe.net> 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