From elvis at velea.eu Tue Oct 1 00:06:58 2013 From: elvis at velea.eu (Elvis Velea) Date: Tue, 01 Oct 2013 00:06:58 +0200 Subject: [address-policy-wg] 2013-06 New Policy Proposal (PA/PI Unification IPv6 Address Space) In-Reply-To: <5249CABD.4030603@fud.no> References: <1380206290.2739@mobil.space.net> <20130926171155.GD65295@Space.Net> <52449DAC.2030700@inex.ie> <52452A96.9060405@fud.no> <66810E018CDF3344A676D4025D2350700F7B64@office-exbe-01.office.nbl.fi> <5249974C.8050904@velea.eu> <5249A9AA.8080308@fud.no> <20130930173141.GF65295@Space.Net> <5249CABD.4030603@fud.no> Message-ID: <5249F602.8040406@velea.eu> Hi Tore, On 9/30/13 9:02 PM, Tore Anderson wrote: > * Gert Doering >> On Mon, Sep 30, 2013 at 06:41:14PM +0200, Tore Anderson wrote: >>> Q: How would that work? >>> A: We could end up with two levels of RIPE NCC membership, e.g. "full" >>> like we have today, and "associate". Both would be fully-blown LIRs, but >>> to keep the operational overhead in NCC billing/finance low, the >>> membership fee for these "associate" members would be charged by the NCC >>> to the full members who are sponsoring them (just like with PI). >> >> I'm not exactly sure what the difference between an "associate member" >> and today's "consumer of resources provided by a sponsoring LIR" would >> then be, except for the title on the contract. On the contrary, some >> enterprises just don't want to deal with the RIPE NCC if they can make >> a contract with their friendly neighbouring LIR instead... > > The difference would be that an "associate member" (which is just an > idea, and outside the scope of APWG anyway) would be an LIR, and would > therefore be able to assign address space to its customer in turn. again, assignments are removed from the proposed text. they will be able to sub-allocate. I agree that we may need to give this 'sort of IR' a name, associate member doesn't sound right though. Keep firing suggestions ;) > > PI holders currently cannot assign address space to their customers, and > that's what I understand this proposal to be all about changing, but it > does it in a way that defines a new "breed" of End User who a) does not > at all fit the original definition of an End User, while b) does > completely fit the definition of an Internet Registry. Put it another > way, the new (1st level) type of End User created by the proposal > appears to me to be an LIR in all but name. It will probably be some kind of IR, just not an LIR nor an End User. > > So what I'm thinking is that it's better to call a spade a spade as far > as address policy go, and instead have the NCC/AGM/Board decide exactly > how they want to go about charging for the different flavours of spades. It's not really a spade, that organisation will be able to use the address space or sub-allocate (parts of) it to other organisations. However, these will have the same right (use or sub-allocate). What do we do then? call everyone an 'associate' ? > > But that's just my ?0.02. Like I said earlier, this should not be > mistaken for opposition to the current proposal, just a suggestion. > >> So I'm not sure it's worth abandoning the established concept of sponsoring >> LIR right away (especially since doing away with it would affect IPv4 PI >> as well...). It wouldn't make a difference anyway :-) - if we want to >> give people the option to take a /48 because it's big enough for them, >> we'd then still have "two standard sizes"... > > Or we could simply tell the requesters to pick their favourite number > between 28 and 49... as long as policy says it's should be possible to > extend up to and including /29 it doesn't really matter what they start > out with as far as keeping delegations aggregated go (and routing is > another matter entirely). It's up to /29 for LIRs. How did you get to the numbers 28 or 49? It's either /48 if the organisation is sure that they will not need more; or a /32 if they do plan to sub-allocate to other customers. Adding intermediary numbers does not make any sense, allowing intermediary numbers may cause all kinds of problems: - billing issues, if at some time the AGM will decide to bill based on the size (as it used to do with IPv4 in the past) - filtering issues - aggregation issues >> So, yes, another avenue could be "abandon /48 assignments/allocations", >> but *that* brings up another can of worms (what about an enterprise that >> has 5 locations that all have local ISP upstreams and want to do BGP >> multihoming? 5x /48 suits them well today, 1x /32 with someone blocking >> more-specifics from that because no site is announcing the /32 aggregate >> would not be that good). > > But that's the route6 object, not the inet6num. If someone is filtering > on the inet6num without accepting more specifics they're already asking > for trouble (their users would surely complain about lack of > connectivity to the more-specifics inside 2a02:26f0::/32, for starters). I already answered in my previous message. See 5.2.1 from the proposed text. > > Tore > Elvis From elvis at velea.eu Tue Oct 1 00:13:05 2013 From: elvis at velea.eu (Elvis Velea) Date: Tue, 01 Oct 2013 00:13:05 +0200 Subject: [address-policy-wg] 2013-06 New Policy Proposal (PA/PI Unification IPv6 Address Space) In-Reply-To: <20130930192720.GA70419@cilantro.c4inet.net> References: <1380206290.2739@mobil.space.net> <20130926171155.GD65295@Space.Net> <52449DAC.2030700@inex.ie> <52452A96.9060405@fud.no> <66810E018CDF3344A676D4025D2350700F7B64@office-exbe-01.office.nbl.fi> <5249974C.8050904@velea.eu> <20130930192720.GA70419@cilantro.c4inet.net> Message-ID: <5249F771.7030700@velea.eu> Hi Sacha, On 9/30/13 9:27 PM, Sascha Luck wrote: > On Mon, Sep 30, 2013 at 05:22:52PM +0200, Elvis Velea wrote: >> There are only two paths, from the RIPE NCC to LIR and from the RIPE >> NCC to End user (we may decide to change the name) via the Sponsoring >> LIR. > > I would be in favour of converting all resources into "independent > resources" and the path going, in all cases: hum, that will open a lot of can of worms, what do we do if every current LIR decides to become a customer of a Sponsoring LIR? > > RIR -> Sponsoring LIR -> End User. > Advantages: > - End Users can transfer "their" resources to a different Sponsoring LIR ok... > > - Specialist LIRs can be established that have the necessary skills to > manage resources properly, End Users wouldn't have to worry about > resource management and it may result in reducing the work-load on the > RIR.. we already have those entities in a few countries. I know at least of a few entities that mostly do IR management in various countries in the region.. Nobody is stopping the Specialists to just open a registry and start offering services. We are already doing that and we have just registered a few weeks ago :-) > > Disadvantages: > > - This opens the door to the establishment of "N(ational)IRs", something > which some states have expressed an interest in. I would not see this a disadvantage. > > - There is a probability of de-aggregation of resources as they move > between Sponsoring LIRs - could possibly be mitigated by making the > minimum assignments big enough. this would probably be a big disadvantage. > > - RIR membership will likely decline - this could also be an advantage. > Not really, we will have less LIRs paying a lot more. > rgds, > Sascha Luck cheers, elvis > > PS: in such a scenario I would even consider supporting 2012-08 ;) PS: me too :-) but this scenario is out of scope of this policy proposal as the policy proposal does not cover IPv4 :-) From elvis at velea.eu Tue Oct 1 00:20:15 2013 From: elvis at velea.eu (Elvis Velea) Date: Tue, 01 Oct 2013 00:20:15 +0200 Subject: [address-policy-wg] 2013-06 New Policy Proposal (PA/PI Unification IPv6 Address Space) In-Reply-To: <20130930201246.GI65295@Space.Net> References: <1380206290.2739@mobil.space.net> <20130926171155.GD65295@Space.Net> <52449DAC.2030700@inex.ie> <52452A96.9060405@fud.no> <66810E018CDF3344A676D4025D2350700F7B64@office-exbe-01.office.nbl.fi> <5249974C.8050904@velea.eu> <5249A9AA.8080308@fud.no> <20130930173141.GF65295@Space.Net> <5249CABD.4030603@fud.no> <20130930201246.GI65295@Space.Net> Message-ID: <5249F91F.2020706@velea.eu> Hi Gert, do not leave all this discussion on my shoulders. I appreciate your steering. On 9/30/13 10:12 PM, Gert Doering wrote: > Hi, > > without actually wanting to drive the direction anywhere, just adding > something that you might have missed :-) > > On Mon, Sep 30, 2013 at 09:02:21PM +0200, Tore Anderson wrote: >> PI holders currently cannot assign address space to their customers, and >> that's what I understand this proposal to be all about changing, but it >> does it in a way that defines a new "breed" of End User who a) does not >> at all fit the original definition of an End User, while b) does >> completely fit the definition of an Internet Registry. Put it another >> way, the new (1st level) type of End User created by the proposal >> appears to me to be an LIR in all but name. > > Well, there are still "just plain" end users of "PI space" out there, > that do not do "LIR things", but just run a (multihomed) network - we > have a couple of these under our sponsoring LIR, and they are quite > happy not having to deal with the RIPE NCC (because they are smaller > german enterprises, not willing to deal with international contracts, > etc.). > > The whole thing that started this PA/PI unification project is that the > distinction between "ISP" (=LIR, PA) and "end user" (=not LIR, PI) has > become less and less clear over time, and as such, it became mostly > confusing to "people out there" not regularily dealing in RIPE policy. right. > > > So - based on "some people will want to operate more like an ISP" and > "other people will be happy to number primarily their own network, and > maybe a server of their neighbour next door", it seemed to make sense > to keep the distinction of "full LIR" and "address space flowing via a > sponsoring LIR to folks not really doing LIR things" - and those might > not be interested at all in having to deal more with the RIPE NCC. Correct, and that is why we (the proposers) came up with the definition of End User in the current proposal. After seeing the page [1] on the RIPE website and the suggestions in the past few days I realise that we may need to define a new entity that is not an LIR but does sub-allocate address space to a customer. An entity that receives an allocation from the RIPE NCC. > > > OTOH, I really should stay out of this discussion now, as it's not my > role to push this any specific way - while I *did* get this started, > now Elvis is the one driving it, and the community has to decide what > they (you!) want, while I focus on the chairing thing - guiding the > discussion and such. Please do help with the steering, I will keep responding to the questions/comments/suggestions but I welcome your steering capabilities :-) > > Gert Doering > -- some hats > elvis ~1 AM and I still need to respond to 3 e-mails PS: Daniel, Olaf.. help! :-) [1] http://www.ripe.net/ripe/internet-coordination/internet-governance/internet-technical-community/the-rir-system From elvis at velea.eu Tue Oct 1 00:58:16 2013 From: elvis at velea.eu (Elvis Velea) Date: Tue, 01 Oct 2013 00:58:16 +0200 Subject: [address-policy-wg] 2013-06 New Policy Proposal (PA/PI Unification IPv6 Address Space) In-Reply-To: <5249E180.2000602@inex.ie> References: <1380206290.2739@mobil.space.net> <20130926171155.GD65295@Space.Net> <52449DAC.2030700@inex.ie> <52452A96.9060405@fud.no> <66810E018CDF3344A676D4025D2350700F7B64@office-exbe-01.office.nbl.fi> <5249974C.8050904@velea.eu> <5249A9AA.8080308@fud.no> <5249AB3F.2080808@inex.ie> <5249AE1A.6050609@fud.no> <5249E180.2000602@inex.ie> Message-ID: <524A0208.6070006@velea.eu> Hi Nick, On 9/30/13 10:39 PM, Nick Hilliard wrote: [...] > So how could you convince the existing ipv6 PI holders that the cost > increase from ?50/year to LIR membership fees would be worth it? > Actually, the PI holders can not decide anything regarding the charging scheme. The LIRs are the ones voting :-) > IOW, there are two problems here: an addressing flavour issue, which > relates to the RIPE community, and a billing issue which is the > responsibility of the RIPE NCC. the billing issue is the responsibility of the RIPE NCC _members_ :-) > > For sure, you couldn't do this to just the ipv6 PI assignments - it would > have to be to all address space, but then you get into the thorny issue of > billing. > well, that is one thing that I haven't yet thought of. Raising the cost for IPv4 PI due to this policy proposal may cause a lot of undesired consequences. > Let me pull out a paper napkin for a moment and hand-wave the possibility > that all PI holders became LIRs and all LIRs paid the same fees. ok, let's try this excercise. > The 2014 budget is ?21.7m (practical). All LIRs pay the same (ncc member policy). Correct. > There are about 9500 members and 33000 assigned pi resources (reality), based on the latest delegated-extended: 28356 IPv4 assignments and 49652 IPv4 assignments+allocations. Considering that we have 9575 LIRs that means that we have about 2.22 allocations/LIR. Taking into consideration the same ratio for IPv4 PI, it means that we would probably have in total about 20-22.000 organisations contributing to the budget. > probably with lots of overlap (reasonable speculation). Let's pluck a > figure out of thin air and say that there are 35000 distinct end users + > lirs (wild speculation), who need to pay an equal share of a budget of > ?21.7 million. That is just a speculation, I think there are less than 25.000 in total. We can actually ask the RIPE NCC to provide us with the the exact numbers, but let's just speculate now. > This means you have maybe 25000-30000 organisations around > the ripe ncc service region who are going to see their fees increase from > (wholesale) ?50 to ?650 per annum. I actually think that we will have somewhere around 50/50. 50% of the organisations will see a decrease from 1800 to 8-900?, the rest of the 50% will see a drastic increase from 50? to 8-900? (if we were to level it out and each organisation would pay the same amount no matter how many resources they would use/request) > > This won't fly. We need to be practical about a workable policy proposal > here. Whether we like it or not, there is a strong history of cost > differentiation in terms of how ip addresess are handled, and I don't see a > practical way of levelling the field within the constraints of what's > workable and what we'd ultimately like. Well, first of all, the ones that get to vote are the LIRs. The LIRs may be happy to hear that they will need to pay 800? (or maybe up to 1000) instead of 1800. Secondly, why wouldn't it fly? We would see an increase in the amount of money some organisations (that can not vote) are paying and a decrease of money paid by the other organisations - LIRs (that do get to vote). I think that leveling the price/allocation would be the fairest.. I would also advocate for a different scheme as well. LIRs to pay around 900-1000E (instead of 1800) and the non-LIRs to pay around 400-500E for receiving the service of registration (only). This way, LIRs would still pay a bit more but receive a few extra services. just an idea. cheers, elvis From elvis at velea.eu Tue Oct 1 01:20:21 2013 From: elvis at velea.eu (Elvis Velea) Date: Tue, 01 Oct 2013 01:20:21 +0200 Subject: [address-policy-wg] 2013-06 New Policy Proposal (PA/PI Unification IPv6 Address Space) In-Reply-To: <5249E555.7090205@fud.no> References: <1380206290.2739@mobil.space.net> <20130926171155.GD65295@Space.Net> <52449DAC.2030700@inex.ie> <52452A96.9060405@fud.no> <66810E018CDF3344A676D4025D2350700F7B64@office-exbe-01.office.nbl.fi> <5249974C.8050904@velea.eu> <5249A9AA.8080308@fud.no> <20130930173141.GF65295@Space.Net> <5249CABD.4030603@fud.no> <20130930201246.GI65295@Space.Net> <5249E555.7090205@fud.no> Message-ID: <524A0735.9070007@velea.eu> Hi Tore, On 9/30/13 10:55 PM, Tore Anderson wrote: > * Gert Doering > >> On Mon, Sep 30, 2013 at 09:02:21PM +0200, Tore Anderson wrote: >>> PI holders currently cannot assign address space to their customers, and >>> that's what I understand this proposal to be all about changing, but it >>> does it in a way that defines a new "breed" of End User who a) does not >>> at all fit the original definition of an End User, while b) does >>> completely fit the definition of an Internet Registry. Put it another >>> way, the new (1st level) type of End User created by the proposal >>> appears to me to be an LIR in all but name. >> >> Well, there are still "just plain" end users of "PI space" out there, >> that do not do "LIR things", but just run a (multihomed) network - we >> have a couple of these under our sponsoring LIR, and they are quite >> happy not having to deal with the RIPE NCC (because they are smaller >> german enterprises, not willing to deal with international contracts, >> etc.). > > I didn't miss these, but maybe I wasn't clear enough. Perhaps I should > have called them "non-member LIRs" rather than "associate members". So > the process would be that your LIR (which is a member of the RIPE NCC) > would sponsor your customers to also become LIRs. Contracts are between > you and them, no direct RIPE NCC dealings there, while the NCC charges > you a fee for each LIR you sponsor in such a way. Just like with PI > today. Address blocks would be delegated straight from the RIPE NCC to > your customers, also just like with PI today. > there is no big difference between our proposal and what you are talking about. It's just that you want to call everyone an LIR - I don't think this will fly. Either we force everyone to become a member or we keep the Sponsoring LIR concept, I'm for the latter. > Assuming these customers of yours only wants to run a multihomed > network, they'd just make an assignment to themselves (or you'd help > them with that, or the NCC could do it based on their request forms when > registering the delegation), and that's that. > You can still do that, it's just that we need to define the name of these customers, LIRs will not work, End Users clearly doesn't work as these would have some of the attributions of an IR. >> The whole thing that started this PA/PI unification project is that the >> distinction between "ISP" (=LIR, PA) and "end user" (=not LIR, PI) has >> become less and less clear over time, and as such, it became mostly >> confusing to "people out there" not regularily dealing in RIPE policy. >> >> So - based on "some people will want to operate more like an ISP" and >> "other people will be happy to number primarily their own network, and >> maybe a server of their neighbour next door", it seemed to make sense >> to keep the distinction of "full LIR" and "address space flowing via a >> sponsoring LIR to folks not really doing LIR things" - and those might >> not be interested at all in having to deal more with the RIPE NCC. > > But...the address space isn't flowing via a sponsoring LIR with PI. The > role of the sponsoring LIR is merely a contractual one. AIUI, PI is > direct assignments from the RIPE NCC to the End Users, just like PA is > direct allocations from the RIPE NCC to the LIRs. > I disagree, the Sponsoring LIR should make sure that the resources are maintained and not just pass contracts between the RIPE NCC and the customer. The contract model on the RIPE website is called "Independent Assignment Request and _Maintenance_ Agreement". Additionally, you may want to see article 4 of the model agreement [1] cheers, elvis [1] https://www.ripe.net/lir-services/resource-management/independent-resources/independent-assignment-request-and-maintenance-agreement From elvis at velea.eu Tue Oct 1 01:32:22 2013 From: elvis at velea.eu (Elvis Velea) Date: Tue, 01 Oct 2013 01:32:22 +0200 Subject: [address-policy-wg] 2013-06 New Policy Proposal (PA/PI Unification IPv6 Address Space) In-Reply-To: <5249EB53.6060703@fud.no> References: <1380206290.2739@mobil.space.net> <20130926171155.GD65295@Space.Net> <52449DAC.2030700@inex.ie> <52452A96.9060405@fud.no> <66810E018CDF3344A676D4025D2350700F7B64@office-exbe-01.office.nbl.fi> <5249974C.8050904@velea.eu> <5249A9AA.8080308@fud.no> <5249AB3F.2080808@inex.ie> <5249AE1A.6050609@fud.no> <5249E180.2000602@inex.ie> <5249EB53.6060703@fud.no> Message-ID: <524A0A06.3040907@velea.eu> Hi Tore, On 9/30/13 11:21 PM, Tore Anderson wrote: [...] > Q: They wouldn't want to pay the full membership price for being LIRs! > A: We don't have to make them. It could be possible to be a RIPE region > LIR even though you're not a direct/full member of the RIPE NCC. RIPE > NCC members could be seen as "sponsors of LIR status" instead of > "sponsors for PI blocks". It could even cost the same ?50 as before. > > This proposal, the way I see it, creates a new class of End Users who > are for all practical purposes LIRs. Quoting the definition from the > policy document: > > 2.1 Internet Registry (IR) > > An Internet Registry is an organisation that is responsible for > distributing IP address space to its members or customers and for > registering those distributions. IRs are classified according to their > primary function and territorial scope within the hierarchical structure > depicted in the figure above. > > [...] > > 2.3 Local Internet Registry (LIR) > > A Local Internet Registry (LIR) is an IR that primarily sub-allocates > address space to the users of the network services that it provides. > > > If you look at the figure in section 2.0, the "End User" box on the > right adjacent to the "Sponsoring LIR" one ... that End User is an LIR. > It exactly matches the definition, at least - the only difference > appears to be in the name. If it walks like an LIR, talks like an LIR... > > So let's try replacing the "End User" label on that box with "LIR". Now > the two trees below the RIPE NCC are identical, except for the presence > of the "Sponsoring LIR" box on the right. But that's a > contractual/billing-related mechanism that doesn't really have anything > to do with the internet registry system per se. So I think we can just > as well remove it from the address policy?, and we are left with two > completely identical hierarchies. > > [1] Not saying it should be removed as a contractual/billing-related > mechanism as currently used, but I don't think it is necessary to > specify it in the policy document just like we don't specify the RIPE > NCC fees in there either. LIR is already a well defined term and making everyone an LIR (while they are not an actual LIR) would confuse more than fix things. I agree that we may want to rename the End User to something else as it is some sort of IR, but making it an LIR (with less service and power) is a bad idea. Would you also give everyone the right to vote at the AGM? Let's not go there. We have LIRs and we all know what these are. Let's find a better name/definition of the entity currently called End User. > >> This won't fly. We need to be practical about a workable policy proposal >> here. Whether we like it or not, there is a strong history of cost >> differentiation in terms of how ip addresess are handled, and I don't see a >> practical way of levelling the field within the constraints of what's >> workable and what we'd ultimately like. > > I'm not saying we should start charging the traditional PI holders more > than we do today. Just that if we're going to grant them "LIR powers", > which this proposal does (and I don't disagree with that), we might as > well start calling them "LIRs" as well. A spade is a spade. No, I do not agree to call them LIR, the LIR is well defined. You are right, we maybe should not call them End Users either, let's work on redefining the End User to something else. Regarding the payment fees, we can not decide anything in this WG anyway, I'd like to ask everyone to either hold on to this discussion for the GM in Athens or open the discussion on the members-discuss at ripe.net mailing list. thanks, elvis From info at leadertelecom.ru Tue Oct 1 01:38:12 2013 From: info at leadertelecom.ru (LeaderTelecom Ltd.) Date: Tue, 1 Oct 2013 03:38:12 +0400 Subject: [address-policy-wg] [Ticket#2013100101008115] 2013-06 New Policy Proposal (PA/PI Unification IPv6 Address Space) In-Reply-To: <5249E180.2000602@inex.ie> References: <5249E180.2000602@inex.ie><1380206290.2739@mobil.space.net> <20130926171155.GD65295@Space.Net> <52449DAC.2030700@inex.ie> <52452A96.9060405@fud.no> <66810E018CDF3344A676D4025D2350700F7B64@office-exbe-01.office.nbl.fi> <5249974C.8050904@velea.eu> <5249A9AA.8080308@fud.no> <5249AB3F.2080808@inex.ie> <5249AE1A.6050609@fud.no> Message-ID: <1380584291.320703.25736069.348260.2@otrs.hostingconsult.ru> Dear Nike, > This means you have maybe 25000-30000 organisations around > the ripe ncc service region who are going to see their fees increase from > (wholesale) ?50 to ?650 per annum. I think that it is logical. -- Alexey Ivanov LeaderTelecom 01.10.2013 00:39 - Nick Hilliard ???????(?): On 30/09/2013 18:00, Tore Anderson wrote: > All existing PI holders would become simultaneously both the LIR *and* > the End User in the above chain, so I'm not sure where this confusion > would come from? So how could you convince the existing ipv6 PI holders that the cost increase from ?50/year to LIR membership fees would be worth it? IOW, there are two problems here: an addressing flavour issue, which relates to the RIPE community, and a billing issue which is the responsibility of the RIPE NCC. For sure, you couldn't do this to just the ipv6 PI assignments - it would have to be to all address space, but then you get into the thorny issue of billing. Let me pull out a paper napkin for a moment and hand-wave the possibility that all PI holders became LIRs and all LIRs paid the same fees.??The 2014 budget is ?21.7m (practical).??All LIRs pay the same (ncc member policy). There are about 9500 members and 33000 assigned pi resources (reality), probably with lots of overlap (reasonable speculation).??Let's pluck a figure out of thin air and say that there are 35000 distinct end users + lirs (wild speculation), who need to pay an equal share of a budget of ?21.7 million.??This means you have maybe 25000-30000 organisations around the ripe ncc service region who are going to see their fees increase from (wholesale) ?50 to ?650 per annum. This won't fly.??We need to be practical about a workable policy proposal here.??Whether we like it or not, there is a strong history of cost differentiation in terms of how ip addresess are handled, and I don't see a practical way of levelling the field within the constraints of what's workable and what we'd ultimately like. Nick -------------- next part -------------- An HTML attachment was scrubbed... URL: From tore at fud.no Tue Oct 1 09:08:45 2013 From: tore at fud.no (Tore Anderson) Date: Tue, 01 Oct 2013 09:08:45 +0200 Subject: [address-policy-wg] 2013-06 New Policy Proposal (PA/PI Unification IPv6 Address Space) In-Reply-To: <524A0A06.3040907@velea.eu> References: <1380206290.2739@mobil.space.net> <20130926171155.GD65295@Space.Net> <52449DAC.2030700@inex.ie> <52452A96.9060405@fud.no> <66810E018CDF3344A676D4025D2350700F7B64@office-exbe-01.office.nbl.fi> <5249974C.8050904@velea.eu> <5249A9AA.8080308@fud.no> <5249AB3F.2080808@inex.ie> <5249AE1A.6050609@fud.no> <5249E180.2000602@inex.ie> <5249EB53.6060703@fud.no> <524A0A06.3040907@velea.eu> Message-ID: <524A74FD.5090401@fud.no> * Elvis Velea > No, I do not agree to call them LIR, the LIR is well defined. You are > right, we maybe should not call them End Users either, let's work on > redefining the End User to something else. The terms LIR (and IR) is indeed well defined, and that's indeed my point - these new "super End Users" actually fit that definition. :-) (I'm only talking about the role of the LIR in the Internet Registry System here, so to be clear I'm *not* equating "LIR" to "direct member of the RIPE NCC who pays the full membership fee and has voting rights at the AGM", nor am I saying that everyone who holds PI space should be forced become such direct members of the RIPE NCC.) Anyway, I think I've made my point, so I'll leave it at that and let this be my last message on the subject. Like I've said before, this is not intended to be a "my way or the highway" statement of opposition, just a (hopefully) constructive piece of feedback you and your co-authors may do with as you wish. Tore From frettled at gmail.com Tue Oct 1 09:35:16 2013 From: frettled at gmail.com (Jan Ingvoldstad) Date: Tue, 1 Oct 2013 09:35:16 +0200 Subject: [address-policy-wg] 2013-06 New Policy Proposal (PA/PI Unification IPv6 Address Space) In-Reply-To: <52497DC6.3050103@velea.eu> References: <1380206290.2739@mobil.space.net> <20130926171155.GD65295@Space.Net> <52449DAC.2030700@inex.ie> <52452A96.9060405@fud.no> <52497DC6.3050103@velea.eu> Message-ID: On Mon, Sep 30, 2013 at 3:33 PM, Elvis Velea wrote: > Hi again Jan, :-) Hi again, Elvis, and thanks for your responses. ? The scope of the policy has not been changed. In the current policy > assignments lower than a /64 are not permitted. Therefore, nothing is > changed. > > > >> Section 1, 1.1 Overview has this current sentence that is removed in the >> proposal: >> >> "All bits to the left of /64 are in scope." >> >> In one of the previous posts, making things easier for e.g. using >> separate IP addresses for SSL is an argument for this proposal, but as I >> read it right now, I would have to sub-allocate a /64 for each SSL >> certificate, rather than say a /128. >> >> I feel reasonably sure that this is not the intention of the authors. >> > > You are right, it was not our intention to remove that line from section > 1.1. However, even with the old policy, my understanding was that you > should have assigned a /64 for the SSL certificate and not a /128. > Uhm, no, that would be ? and sorry for the strong word use here ? insane. What you're essentially saying is that for any case where one would create a reverse pointer, there would have to be a /64. This does not scale at all. In terms of routing, it currently makes sense to ensure that address space smaller than a /64 is not announced globally via BGP. But preventing actual _use_ of smaller address space is a very bad idea. One of the HUGE gains of IPv6 is that you can easily encode more information in the IP address itself than you could with IPv4. There is an enormous amount of flexibility thanks to the 128-bit size of the address space. Also, if the rightmost /64 cannot ever be used, then IPv6 should've been a 64-bit address space, and I don't think policing this here is relevant. > > I am not sure that removing that line makes any difference, let's see what > the others think and we could add it back if it really changes the policy > scope. > >From a n00b's point of view, the old policy reads something like this, in brief: "This policy does not apply to address space smaller than /64" And the old policy reads: "This policy applies to address space regardless of its size" To me, this is the difference between letting me use e.g. 2a01:5b40::80:88:dead:beef:cafe as the IPv6 address for www.oyet.no, and having to use e.g. 2a01:5b40:88:cafe::1/64. -- Jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From rogerj at gmail.com Tue Oct 1 09:43:12 2013 From: rogerj at gmail.com (=?ISO-8859-1?Q?Roger_J=F8rgensen?=) Date: Tue, 1 Oct 2013 09:43:12 +0200 Subject: [address-policy-wg] 2013-06 New Policy Proposal (PA/PI Unification IPv6 Address Space) In-Reply-To: <20130930192720.GA70419@cilantro.c4inet.net> References: <1380206290.2739@mobil.space.net> <20130926171155.GD65295@Space.Net> <52449DAC.2030700@inex.ie> <52452A96.9060405@fud.no> <66810E018CDF3344A676D4025D2350700F7B64@office-exbe-01.office.nbl.fi> <5249974C.8050904@velea.eu> <20130930192720.GA70419@cilantro.c4inet.net> Message-ID: On Mon, Sep 30, 2013 at 9:27 PM, Sascha Luck wrote: > On Mon, Sep 30, 2013 at 05:22:52PM +0200, Elvis Velea wrote: >> >> There are only two paths, from the RIPE NCC to LIR and from the RIPE NCC >> to End user (we may decide to change the name) via the Sponsoring LIR. > > > I would be in favour of converting all resources into "independent > resources" and the path going, in all cases: > > RIR -> Sponsoring LIR -> End User. > Advantages: > - End Users can transfer "their" resources to a different Sponsoring LIR > > - Specialist LIRs can be established that have the necessary skills to > manage resources properly, End Users wouldn't have to worry about > resource management and it may result in reducing the work-load on the > RIR.. > > Disadvantages: > > - This opens the door to the establishment of "N(ational)IRs", something > which some states have expressed an interest in. > > - There is a probability of de-aggregation of resources as they move > between Sponsoring LIRs - could possibly be mitigated by making the > minimum assignments big enough. > > - RIR membership will likely decline - this could also be an advantage. You're talking about a quite radical changes to how we think of IP space. What you're hinting at are not that difficult from something we're discussing on IETF level, and in the concept of LISP. Get a new block of address space that will be distributed directly to end-users. It's just IP space. It do include a tons of pitfalls and difficult consideration, alot. On the other hand, what is the real difference from what you're suggestion and what current reality are? The LIR "concept"? -- Roger Jorgensen | ROJO9-RIPE rogerj at gmail.com | - IPv6 is The Key! http://www.jorgensen.no | roger at jorgensen.no From gert at space.net Tue Oct 1 10:19:35 2013 From: gert at space.net (Gert Doering) Date: Tue, 1 Oct 2013 10:19:35 +0200 Subject: [address-policy-wg] 2013-06 New Policy Proposal (PA/PI Unification IPv6 Address Space) In-Reply-To: <524A0A06.3040907@velea.eu> References: <52449DAC.2030700@inex.ie> <52452A96.9060405@fud.no> <66810E018CDF3344A676D4025D2350700F7B64@office-exbe-01.office.nbl.fi> <5249974C.8050904@velea.eu> <5249A9AA.8080308@fud.no> <5249AB3F.2080808@inex.ie> <5249AE1A.6050609@fud.no> <5249E180.2000602@inex.ie> <5249EB53.6060703@fud.no> <524A0A06.3040907@velea.eu> Message-ID: <20131001081935.GK65295@Space.Net> Hi, On Tue, Oct 01, 2013 at 01:32:22AM +0200, Elvis Velea wrote: > Regarding the payment fees, we can not decide anything in this WG > anyway, I'd like to ask everyone to either hold on to this discussion > for the GM in Athens or open the discussion on the > members-discuss at ripe.net mailing list. Well. APWG can not *decide* on the charging scheme, but we can make reasonable proposals to the AGM - and if the addressing community agrees that something makes sense, the NCC board usually listens closely and works that into the next proposed charging scheme. We did that with 2007-01, and while it wasn't easy, it got done in the end. Now all sides have a bit more experience in listening to each other, so it might be easier this time :-) Anyway - what we need to be careful about is - do not make the price for "what used to be called PI holders" dramatically higher - technically, we might do this ("we vote, they pay"), but the signal this sends to the world is "we're a cartel and we've just decided that we all pay less and everyone else pays more", which is very likely to get us into deep shit with regulators, tax authorities, etc. - have the right incenctives here (e.g.: "a /32 costs 10000 EUR/year, a /48 costs 50 EUR/year" would send the message to ISPs "if you can number your network with a /48, you can save serious money!" and that will lead to "assigning customers a /64 or even less", which we don't want) So I think something like - every LIR pays a base fee ("one size fits all") which includes their initial /29.../32 ("as today") - every extra "small allocation" (smaller than /32) costs 50 EUR/year (+ 50 EUR/year per IPv4 PI) - every extra "big allocation" (/32 or shorter) costs 500 EUR/year would get us somewhere, without causing extra turmoil - for today's address holders, nothing much would change, and for future allocations, the financial incentives to go one way or other ("do not become LIR, get your /32 from a sponsoring LIR" and "run your whole ISP on a /48") are not significant enough to outweigh other reasons. Elvis, I think this is something which deserves it's own slide and 10 minutes of discussion at the APWG meeting :-) (and possibly other models for charging scheme and incentives), so we can then have input to the AGM for consideration... Gert Doering -- APWG chair -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 306 bytes Desc: not available URL: From elvis at velea.eu Tue Oct 1 10:55:43 2013 From: elvis at velea.eu (Elvis Velea) Date: Tue, 01 Oct 2013 10:55:43 +0200 Subject: [address-policy-wg] 2013-06 New Policy Proposal (PA/PI Unification IPv6 Address Space) In-Reply-To: <524A74FD.5090401@fud.no> References: <1380206290.2739@mobil.space.net> <20130926171155.GD65295@Space.Net> <52449DAC.2030700@inex.ie> <52452A96.9060405@fud.no> <66810E018CDF3344A676D4025D2350700F7B64@office-exbe-01.office.nbl.fi> <5249974C.8050904@velea.eu> <5249A9AA.8080308@fud.no> <5249AB3F.2080808@inex.ie> <5249AE1A.6050609@fud.no> <5249E180.2000602@inex.ie> <5249EB53.6060703@fud.no> <524A0A06.3040907@velea.eu> <524A74FD.5090401@fud.no> Message-ID: <524A8E0F.9010709@velea.eu> Hi Tore, On 10/1/13 9:08 AM, Tore Anderson wrote: > * Elvis Velea > >> No, I do not agree to call them LIR, the LIR is well defined. You are >> right, we maybe should not call them End Users either, let's work on >> redefining the End User to something else. > > The terms LIR (and IR) is indeed well defined, and that's indeed my > point - these new "super End Users" actually fit that definition. :-) Okay, got the point and somehow agree with it. > > (I'm only talking about the role of the LIR in the Internet Registry > System here, so to be clear I'm *not* equating "LIR" to "direct member > of the RIPE NCC who pays the full membership fee and has voting rights > at the AGM", nor am I saying that everyone who holds PI space should be > forced become such direct members of the RIPE NCC.) > Well, since the assignments will be removed, anyone receiving a sub-allocation from the friendly provider can further sub-allocate (as long as they receive more than a /64) and become some sort of IR. But, would you consider yourself an IR if you receive a sub-allocation from your ISP and sub-allocate a /64 to your brother for his web server? > Anyway, I think I've made my point, so I'll leave it at that and let > this be my last message on the subject. Like I've said before, this is > not intended to be a "my way or the highway" statement of opposition, > just a (hopefully) constructive piece of feedback you and your > co-authors may do with as you wish. One of the slides at the RIPE Meeting (and I hope you will be in Athens) will be related to this subject and I hope we can have a constructive discussion and reach a good decision. thanks for all the feedback, please continue to bring it on ;) cheers, elvis From nick at inex.ie Tue Oct 1 10:56:56 2013 From: nick at inex.ie (Nick Hilliard) Date: Tue, 01 Oct 2013 09:56:56 +0100 Subject: [address-policy-wg] 2013-06 New Policy Proposal (PA/PI Unification IPv6 Address Space) In-Reply-To: <524A0208.6070006@velea.eu> References: <1380206290.2739@mobil.space.net> <20130926171155.GD65295@Space.Net> <52449DAC.2030700@inex.ie> <52452A96.9060405@fud.no> <66810E018CDF3344A676D4025D2350700F7B64@office-exbe-01.office.nbl.fi> <5249974C.8050904@velea.eu> <5249A9AA.8080308@fud.no> <5249AB3F.2080808@inex.ie> <5249AE1A.6050609@fud.no> <5249E180.2000602@inex.ie> <524A0208.6070006@velea.eu> Message-ID: <524A8E58.2090903@inex.ie> On 30/09/2013 23:58, Elvis Velea wrote: > the billing issue is the responsibility of the RIPE NCC _members_ :-) you can't sweep this under the carpet. Billing is the only thing that matters to the vast majority of resource holders. Nick From elvis at velea.eu Tue Oct 1 11:11:05 2013 From: elvis at velea.eu (Elvis Velea) Date: Tue, 01 Oct 2013 11:11:05 +0200 Subject: [address-policy-wg] 2013-06 New Policy Proposal (PA/PI Unification IPv6 Address Space) In-Reply-To: References: <1380206290.2739@mobil.space.net> <20130926171155.GD65295@Space.Net> <52449DAC.2030700@inex.ie> <52452A96.9060405@fud.no> <52497DC6.3050103@velea.eu> Message-ID: <524A91A9.7000604@velea.eu> Hi Jan, On 10/1/13 9:35 AM, Jan Ingvoldstad wrote: [...] > You are right, it was not our intention to remove that line from > section 1.1. However, even with the old policy, my understanding was > that you should have assigned a /64 for the SSL certificate and not > a /128. > > > Uhm, no, that would be ? and sorry for the strong word use here ? insane. > > What you're essentially saying is that for any case where one would > create a reverse pointer, there would have to be a /64. > I'm not talking about how much you would use on your router or reverse dns. I'm talking about how much to 'reserve' as minimum for a point-to-point link or for a service. > This does not scale at all. > > In terms of routing, it currently makes sense to ensure that address > space smaller than a /64 is not announced globally via BGP. > > But preventing actual _use_ of smaller address space is a very bad idea. It's not preventing use of a smaller prefix, it's preventing assigning/sub-allocating less than a /64 for anything. > > One of the HUGE gains of IPv6 is that you can easily encode more > information in the IP address itself than you could with IPv4. There is > an enormous amount of flexibility thanks to the 128-bit size of the > address space. > > Also, if the rightmost /64 cannot ever be used, then IPv6 should've been > a 64-bit address space, and I don't think policing this here is relevant. > Well, I used to work as an IPRA at the RIPE NCC and my understanding of the policy then (and now) was that assignments and/or sub-allocations of anything below a /64 is out of scope and even if one IPv6 address is used within a /64, the whole subnet is considered to be used. > > I am not sure that removing that line makes any difference, let's > see what the others think and we could add it back if it really > changes the policy scope. > > > >From a n00b's point of view, the old policy reads something like this, > in brief: > > "This policy does not apply to address space smaller than /64" > > And the old policy reads: > > "This policy applies to address space regardless of its size" I see, you may be right, this will be a second slide on the presentation made in Athens and we'll discuss it there. > > To me, this is the difference between letting me use e.g. > 2a01:5b40::80:88:dead:beef:cafe as the IPv6 address for www.oyet.no > , and having to use e.g. 2a01:5b40:88:cafe::1/64. I don't actually see it like that. You can still use the whole IPv6 address to number a device, it's just that you can not split a /64 for different services. For example, you can use a /64 to number, let's say, 100 devices that are in the same vlan doing the same thing and providing the same service but you can not number 100 different customers within a /64. cheers, elvis From elvis at velea.eu Tue Oct 1 11:17:38 2013 From: elvis at velea.eu (Elvis Velea) Date: Tue, 01 Oct 2013 11:17:38 +0200 Subject: [address-policy-wg] 2013-06 New Policy Proposal (PA/PI Unification IPv6 Address Space) In-Reply-To: References: <1380206290.2739@mobil.space.net> <20130926171155.GD65295@Space.Net> <52449DAC.2030700@inex.ie> <52452A96.9060405@fud.no> <66810E018CDF3344A676D4025D2350700F7B64@office-exbe-01.office.nbl.fi> <5249974C.8050904@velea.eu> <20130930192720.GA70419@cilantro.c4inet.net> Message-ID: <524A9332.1020908@velea.eu> Hi Roger, On 10/1/13 9:43 AM, Roger J?rgensen wrote: > On Mon, Sep 30, 2013 at 9:27 PM, Sascha Luck wrote: >> On Mon, Sep 30, 2013 at 05:22:52PM +0200, Elvis Velea wrote: >>> >>> There are only two paths, from the RIPE NCC to LIR and from the RIPE NCC >>> to End user (we may decide to change the name) via the Sponsoring LIR. >> >> >> I would be in favour of converting all resources into "independent >> resources" and the path going, in all cases: >> >> RIR -> Sponsoring LIR -> End User. [...] > You're talking about a quite radical changes to how we think of IP space. Correct, current proposal is quite a radical change. However, it does not change much the reality today. Companies do request /48 PI assignments saying that they will use it only for their infrastructure and then start giving bits of it to customers without actually registering the assignment/sub-allocation and basically violating the policy. > What you're hinting at are not that difficult from something we're discussing > on IETF level, and in the concept of LISP. Get a new block of address space > that will be distributed directly to end-users. It's just IP space. > LISP is a totally different story. Let's not mix them up, please :-) > It do include a tons of pitfalls and difficult consideration, alot. > > > On the other hand, what is the real difference from what you're suggestion > and what current reality are? The LIR "concept"? The LIR concept is a well defined concept. Based on the discussions on this list in the past few days I do realise that we need to define the previously known PI user and I see that the term 'End User' does not match with the role. cheers, elvis From frettled at gmail.com Tue Oct 1 11:44:27 2013 From: frettled at gmail.com (Jan Ingvoldstad) Date: Tue, 1 Oct 2013 11:44:27 +0200 Subject: [address-policy-wg] 2013-06 New Policy Proposal (PA/PI Unification IPv6 Address Space) In-Reply-To: <524A91A9.7000604@velea.eu> References: <1380206290.2739@mobil.space.net> <20130926171155.GD65295@Space.Net> <52449DAC.2030700@inex.ie> <52452A96.9060405@fud.no> <52497DC6.3050103@velea.eu> <524A91A9.7000604@velea.eu> Message-ID: On Tue, Oct 1, 2013 at 11:11 AM, Elvis Velea wrote: > Hi Jan, > Hello again, Elvis. :) > I'm not talking about how much you would use on your router or reverse dns. > > I'm talking about how much to 'reserve' as minimum for a point-to-point > link or for a service. > > ? > > It's not preventing use of a smaller prefix, it's preventing > assigning/sub-allocating less than a /64 for anything. ? > Well, I used to work as an IPRA at the RIPE NCC and my understanding of > the policy then (and now) was that assignments and/or sub-allocations of > anything below a /64 is out of scope and even if one IPv6 address is used > within a /64, the whole subnet is considered to be used. While this particular paragraph is fine, the others are less than, uhm, clear. > >> To me, this is the difference between letting me use e.g. >> 2a01:5b40::80:88:dead:beef:**cafe as the IPv6 address for www.oyet.no >> , and having to use e.g. 2a01:5b40:88:cafe::1/64. >> > > I don't actually see it like that. You can still use the whole IPv6 > address to number a device, it's just that you can not split a /64 for > different services. > > For example, you can use a /64 to number, let's say, 100 devices that are > in the same vlan doing the same thing and providing the same service but > you can not number 100 different customers within a /64. > ? because of this. This doesn't make sense. Why can I not number 100 (or indeed, hundreds of thousands of) addresses for different websites within a /64? I think, perhaps, that the words "customer", "service" etc. are poorly defined and lead to significant misunderstanding, and that I have not made myself clear. Whatever a hosting provider chooses to do with their IPv6 space to perform comparatively fine-grained routing and other network organization, should be pretty much irrelevant, as long as what's exposed to peers is sane. The example I came with is not randomly chosen, I know there has been similar issues with the understanding of semantics in IPv4 policy, which according to some NCC members seemed to imply that it would be impossible to use a separate IPv4 address per SSL site without comparatively major bureaucracy, since (the argument went) these addresses should be assigned and registered. Now you seem to be telling me that I cannot have a single webserver serving two different websites with two different IPv6 addresses, if they are both within the same /64. If this is really the case, IPv6 is, within RIPE, a 64-bit address space, not a 128-bit address space, and depletion is guaranteed to become a problem with the proposed policy, as well as the current policy, considering that every hosting provider would need _many_ /32 allocations, as I understand the policy and the argument you make. If, however, we consider IPv6 an 128-bit address space, and the rightmost /64 as simply not governed by RIPE policy, then a /48 is a _humongous_ address space, providing a LIR with 65k networks which may be redelegated to lower-level customers, such as e.g. web hosting providers, as long as these are routed as a /64 block. -- Jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From elvis at velea.eu Tue Oct 1 11:46:24 2013 From: elvis at velea.eu (Elvis Velea) Date: Tue, 01 Oct 2013 11:46:24 +0200 Subject: [address-policy-wg] 2013-06 New Policy Proposal (PA/PI Unification IPv6 Address Space) In-Reply-To: <20131001081935.GK65295@Space.Net> References: <52449DAC.2030700@inex.ie> <52452A96.9060405@fud.no> <66810E018CDF3344A676D4025D2350700F7B64@office-exbe-01.office.nbl.fi> <5249974C.8050904@velea.eu> <5249A9AA.8080308@fud.no> <5249AB3F.2080808@inex.ie> <5249AE1A.6050609@fud.no> <5249E180.2000602@inex.ie> <5249EB53.6060703@fud.no> <524A0A06.3040907@velea.eu> <20131001081935.GK65295@Space.Net> Message-ID: <524A99F0.4060809@velea.eu> Hi Gert, On 10/1/13 10:19 AM, Gert Doering wrote: > Hi, > > On Tue, Oct 01, 2013 at 01:32:22AM +0200, Elvis Velea wrote: >> Regarding the payment fees, we can not decide anything in this WG >> anyway, I'd like to ask everyone to either hold on to this discussion >> for the GM in Athens or open the discussion on the >> members-discuss at ripe.net mailing list. > > Well. APWG can not *decide* on the charging scheme, but we can make > reasonable proposals to the AGM - and if the addressing community agrees > that something makes sense, the NCC board usually listens closely and > works that into the next proposed charging scheme. right :) > > We did that with 2007-01, and while it wasn't easy, it got done in the > end. Now all sides have a bit more experience in listening to each other, > so it might be easier this time :-) I hope that it won't take us two years to get consensus to this proposal (as it happened with 2007-01) :) > > Anyway - what we need to be careful about is > > - do not make the price for "what used to be called PI holders" > dramatically higher - technically, we might do this ("we vote, they > pay"), but the signal this sends to the world is "we're a cartel > and we've just decided that we all pay less and everyone else pays > more", which is very likely to get us into deep shit with regulators, > tax authorities, etc. I see, well.. I think it's time we ask the RIPE NCC for some statistics [1] before we can actually see how this could be modeled. > > - have the right incenctives here (e.g.: "a /32 costs 10000 EUR/year, > a /48 costs 50 EUR/year" would send the message to ISPs "if you can > number your network with a /48, you can save serious money!" and that > will lead to "assigning customers a /64 or even less", which we don't > want) > correct, I would not want to see ISPs/hosting companies sub-allocating a /96 or a /112 to fit everything within a /48. > > So I think something like > > - every LIR pays a base fee ("one size fits all") which includes their > initial /29.../32 ("as today") I agree. > > - every extra "small allocation" (smaller than /32) costs 50 EUR/year > (+ 50 EUR/year per IPv4 PI) I don't really agree with this bit, but it may be one way to go. > > - every extra "big allocation" (/32 or shorter) costs 500 EUR/year > Here is why I do not agree with the 50? for the /48 and 500? for the /32 or more.. If we recommend the AGM to do it this way and they actually agree and vote next year to have this charging scheme, I am afraid that ISPs and hosting companies will immediately say: - wait a second, so if I number everything within a /48 I can save 450?/year? - what would cost me to use a /112 to connect a customer? nothing. - What are the technical disadvantages? None. - Why would I use a /64 or more and be forced to pay 500?? > would get us somewhere, without causing extra turmoil - for today's > address holders, nothing much would change, and for future allocations, > the financial incentives to go one way or other ("do not become LIR, > get your /32 from a sponsoring LIR" and "run your whole ISP on a /48") > are not significant enough to outweigh other reasons. > Your idea may work but we may also see that everyone will request a /48 and try to fit all their operations within that /48. > > Elvis, I think this is something which deserves it's own slide and 10 > minutes of discussion at the APWG meeting :-) (and possibly other > models for charging scheme and incentives), so we can then have input > to the AGM for consideration... I agree. > > Gert Doering > -- APWG chair > [1] to the RIPE NCC: Can you please give us some aggregate data regarding the following numbers: (We do not need exact numbers, as these will change 5 minutes later once you make a new registry change - assignment/allocation/etc) 1. Is my number correct ? There are approximately 28355 PI assignments 2. How many organisations are using these 28355 PIs? 3. Is my number correct? There are approximately 1538 IPv6 PI assignments 4. How many organisations are using these 1538 IPv6 PIs? 5. How many LIRs have an IPv6 allocation but not an IPv4 one? thank you, elvis From elvis at velea.eu Tue Oct 1 11:54:31 2013 From: elvis at velea.eu (Elvis Velea) Date: Tue, 01 Oct 2013 11:54:31 +0200 Subject: [address-policy-wg] 2013-06 New Policy Proposal (PA/PI Unification IPv6 Address Space) In-Reply-To: <524A8E58.2090903@inex.ie> References: <1380206290.2739@mobil.space.net> <20130926171155.GD65295@Space.Net> <52449DAC.2030700@inex.ie> <52452A96.9060405@fud.no> <66810E018CDF3344A676D4025D2350700F7B64@office-exbe-01.office.nbl.fi> <5249974C.8050904@velea.eu> <5249A9AA.8080308@fud.no> <5249AB3F.2080808@inex.ie> <5249AE1A.6050609@fud.no> <5249E180.2000602@inex.ie> <524A0208.6070006@velea.eu> <524A8E58.2090903@inex.ie> Message-ID: <524A9BD7.8050003@velea.eu> Hi Nick, On 10/1/13 10:56 AM, Nick Hilliard wrote: > On 30/09/2013 23:58, Elvis Velea wrote: >> the billing issue is the responsibility of the RIPE NCC _members_ :-) > > you can't sweep this under the carpet. Billing is the only thing that > matters to the vast majority of resource holders. I'm not, I'm just trying to have the discussion in the mailing list that can actually take that decision. So, we can propose to the AGM to possibly change the charging scheme, it's just that we first need to come up with real numbers and 2-3 options from which to choose. And I think that the policy proposal should move forward regardless of the billing matters. I also think that the discussion about billing related to this policy proposal to take place in the members-discuss, the only place where suggestions can be made and discussed by the ones that will vote. > > Nick > my .02? cheers, elvis From gert at space.net Tue Oct 1 12:04:32 2013 From: gert at space.net (Gert Doering) Date: Tue, 1 Oct 2013 12:04:32 +0200 Subject: [address-policy-wg] 2013-06 New Policy Proposal (PA/PI Unification IPv6 Address Space) In-Reply-To: <524A9BD7.8050003@velea.eu> References: <52452A96.9060405@fud.no> <66810E018CDF3344A676D4025D2350700F7B64@office-exbe-01.office.nbl.fi> <5249974C.8050904@velea.eu> <5249A9AA.8080308@fud.no> <5249AB3F.2080808@inex.ie> <5249AE1A.6050609@fud.no> <5249E180.2000602@inex.ie> <524A0208.6070006@velea.eu> <524A8E58.2090903@inex.ie> <524A9BD7.8050003@velea.eu> Message-ID: <20131001100432.GM65295@Space.Net> Hi, On Tue, Oct 01, 2013 at 11:54:31AM +0200, Elvis Velea wrote: > I also think that the discussion about billing related to this policy > proposal to take place in the members-discuss, the only place where > suggestions can be made and discussed by the ones that will vote. I actually disagree - it's an inseparable part of the proposal to work out how the effects on membership and charging scheme can look like, and what to propose. When the address policy community agrees on a) the proposal, and b) how a new charging scheme that takes this into account, we pass the ball to members-discuss / the AGM to take our input and decide on the final charging scheme - but without solid agreement from here, the end result will be "disconnection". So the discussion needs to stay here, until this community is in agreement. (Of course we give a HEADS UP to the members and the NCC board - for example by giving a short summary in the NCC services working group, at the RIPE meeting...) Gert Doering -- APWG chair -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 306 bytes Desc: not available URL: From nick at inex.ie Tue Oct 1 12:06:41 2013 From: nick at inex.ie (Nick Hilliard) Date: Tue, 01 Oct 2013 11:06:41 +0100 Subject: [address-policy-wg] 2013-06 New Policy Proposal (PA/PI Unification IPv6 Address Space) In-Reply-To: <20131001100432.GM65295@Space.Net> References: <52452A96.9060405@fud.no> <66810E018CDF3344A676D4025D2350700F7B64@office-exbe-01.office.nbl.fi> <5249974C.8050904@velea.eu> <5249A9AA.8080308@fud.no> <5249AB3F.2080808@inex.ie> <5249AE1A.6050609@fud.no> <5249E180.2000602@inex.ie> <524A0208.6070006@velea.eu> <524A8E58.2090903@inex.ie> <524A9BD7.8050003@velea.eu> <20131001100432.GM65295@Space.Net> Message-ID: <524A9EB1.8040505@inex.ie> On 01/10/2013 11:04, Gert Doering wrote: > So the discussion needs to stay here, until this community is in > agreement. +1. Otherwise the discussion will become unworkable. Nick From rogerj at gmail.com Tue Oct 1 12:20:40 2013 From: rogerj at gmail.com (=?ISO-8859-1?Q?Roger_J=F8rgensen?=) Date: Tue, 1 Oct 2013 12:20:40 +0200 Subject: [address-policy-wg] 2013-06 New Policy Proposal (PA/PI Unification IPv6 Address Space) In-Reply-To: <524A9332.1020908@velea.eu> References: <1380206290.2739@mobil.space.net> <20130926171155.GD65295@Space.Net> <52449DAC.2030700@inex.ie> <52452A96.9060405@fud.no> <66810E018CDF3344A676D4025D2350700F7B64@office-exbe-01.office.nbl.fi> <5249974C.8050904@velea.eu> <20130930192720.GA70419@cilantro.c4inet.net> <524A9332.1020908@velea.eu> Message-ID: On Tue, Oct 1, 2013 at 11:17 AM, Elvis Velea wrote: > Hi Roger, > > On 10/1/13 9:43 AM, Roger J?rgensen wrote: >> >> On Mon, Sep 30, 2013 at 9:27 PM, Sascha Luck >> wrote: >>> >>> On Mon, Sep 30, 2013 at 05:22:52PM +0200, Elvis Velea wrote: >>>> >>>> >>>> There are only two paths, from the RIPE NCC to LIR and from the RIPE NCC >>>> to End user (we may decide to change the name) via the Sponsoring LIR. >>> >>> >>> >>> I would be in favour of converting all resources into "independent >>> resources" and the path going, in all cases: >>> >>> RIR -> Sponsoring LIR -> End User. > > [...] > >> You're talking about a quite radical changes to how we think of IP space. > > > Correct, current proposal is quite a radical change. However, it does not > change much the reality today. > > Companies do request /48 PI assignments saying that they will use it only > for their infrastructure and then start giving bits of it to customers > without actually registering the assignment/sub-allocation and basically > violating the policy. > > >> What you're hinting at are not that difficult from something we're >> discussing >> on IETF level, and in the concept of LISP. Get a new block of address >> space >> that will be distributed directly to end-users. It's just IP space. >> > > LISP is a totally different story. Let's not mix them up, please :-) Think you missed that my reply was to Sasha's mail, not the propasal as a whole:) -- Roger Jorgensen | ROJO9-RIPE rogerj at gmail.com | - IPv6 is The Key! http://www.jorgensen.no | roger at jorgensen.no From elvis at velea.eu Tue Oct 1 12:33:12 2013 From: elvis at velea.eu (Elvis Velea) Date: Tue, 01 Oct 2013 12:33:12 +0200 Subject: [address-policy-wg] 2013-06 New Policy Proposal (PA/PI Unification IPv6 Address Space) In-Reply-To: References: <1380206290.2739@mobil.space.net> <20130926171155.GD65295@Space.Net> <52449DAC.2030700@inex.ie> <52452A96.9060405@fud.no> <52497DC6.3050103@velea.eu> <524A91A9.7000604@velea.eu> Message-ID: <524AA4E8.4020104@velea.eu> Hi Jan, thank you for your reply and sorry for the top posting. I got your point and I will ask the RIPE NCC hostmaster to add back the sentence that we removed by mistake. For the next version we also need to decide whether: - we should be strict and restrict what you can do within a /64 - we should not care what happens within the /64, it's the decision of the address space user. This is an other point for a slide at the RIPE Meeting :-) cheers, elvis On 10/1/13 11:44 AM, Jan Ingvoldstad wrote: > On Tue, Oct 1, 2013 at 11:11 AM, Elvis Velea > wrote: > > Hi Jan, > > > Hello again, Elvis. :) > > I'm not talking about how much you would use on your router or > reverse dns. > > I'm talking about how much to 'reserve' as minimum for a > point-to-point link or for a service. > > > ? > > > It's not preventing use of a smaller prefix, it's preventing > assigning/sub-allocating less than a /64 for anything. > > > ? > > Well, I used to work as an IPRA at the RIPE NCC and my understanding > of the policy then (and now) was that assignments and/or > sub-allocations of anything below a /64 is out of scope and even if > one IPv6 address is used within a /64, the whole subnet is > considered to be used. > > > While this particular paragraph is fine, the others are less than, uhm, > clear. > > > To me, this is the difference between letting me use e.g. > 2a01:5b40::80:88:dead:beef:__cafe as the IPv6 address for > www.oyet.no > , and having to use e.g. > 2a01:5b40:88:cafe::1/64. > > > I don't actually see it like that. You can still use the whole IPv6 > address to number a device, it's just that you can not split a /64 > for different services. > > For example, you can use a /64 to number, let's say, 100 devices > that are in the same vlan doing the same thing and providing the > same service but you can not number 100 different customers within a > /64. > > > ? because of this. > > This doesn't make sense. > > Why can I not number 100 (or indeed, hundreds of thousands of) addresses > for different websites within a /64? > > I think, perhaps, that the words "customer", "service" etc. are poorly > defined and lead to significant misunderstanding, and that I have not > made myself clear. > > Whatever a hosting provider chooses to do with their IPv6 space to > perform comparatively fine-grained routing and other network > organization, should be pretty much irrelevant, as long as what's > exposed to peers is sane. > > The example I came with is not randomly chosen, I know there has been > similar issues with the understanding of semantics in IPv4 policy, which > according to some NCC members seemed to imply that it would be > impossible to use a separate IPv4 address per SSL site without > comparatively major bureaucracy, since (the argument went) these > addresses should be assigned and registered. > > Now you seem to be telling me that I cannot have a single webserver > serving two different websites with two different IPv6 addresses, if > they are both within the same /64. > > If this is really the case, IPv6 is, within RIPE, a 64-bit address > space, not a 128-bit address space, and depletion is guaranteed to > become a problem with the proposed policy, as well as the current > policy, considering that every hosting provider would need _many_ /32 > allocations, as I understand the policy and the argument you make. > > If, however, we consider IPv6 an 128-bit address space, and the > rightmost /64 as simply not governed by RIPE policy, then a /48 is a > _humongous_ address space, providing a LIR with 65k networks which may > be redelegated to lower-level customers, such as e.g. web hosting > providers, as long as these are routed as a /64 block. > > -- > Jan From dcunningham at airspeed.ie Tue Oct 1 14:55:26 2013 From: dcunningham at airspeed.ie (Donal Cunningham) Date: Tue, 1 Oct 2013 12:55:26 +0000 Subject: [address-policy-wg] 2013-05 New Draft Document and Impact Analysis Published (No Restrictions on End User Assignments in Intra-RIR Transfers) In-Reply-To: References: Message-ID: > The draft document for the proposal described in 2013-05, > "No Restrictions on End User Assignments in Intra-RIR Transfers" > has been published. The impact analysis that was conducted for this > proposal has also been published. +1. D. Airspeed Telecom From frettled at gmail.com Tue Oct 1 15:16:55 2013 From: frettled at gmail.com (Jan Ingvoldstad) Date: Tue, 1 Oct 2013 15:16:55 +0200 Subject: [address-policy-wg] 2013-05 New Draft Document and Impact Analysis Published (No Restrictions on End User Assignments in Intra-RIR Transfers) In-Reply-To: <52497b8c.87dc0e0a.029d.ffff9be6SMTPIN_ADDED_MISSING@mx.google.com> References: <52497b8c.87dc0e0a.029d.ffff9be6SMTPIN_ADDED_MISSING@mx.google.com> Message-ID: On Mon, Sep 30, 2013 at 3:22 PM, Marco Schmidt wrote: > > Dear colleagues, > > The draft document for the proposal described in 2013-05, > "No Restrictions on End User Assignments in Intra-RIR Transfers" > has been published. The impact analysis that was conducted for this > proposal has also been published. > > > You can find the full proposal and the impact analysis at: > > https://www.ripe.net/ripe/policies/proposals/2013-05 > Ah, excellent. This changed turned out just as well-formulated as I hoped, and the impact analysis matched my expectations. What's not to like? :) +1 -- Jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike at iptrading.com Tue Oct 1 16:50:44 2013 From: mike at iptrading.com (Mike Burns) Date: Tue, 1 Oct 2013 10:50:44 -0400 Subject: [address-policy-wg] 2013-05 New Draft Document and Impact Analysis Published (No Restrictions on End User Assignments in Intra-RIR Transfers) In-Reply-To: <524981F2.2010002@fud.no> References: <524981F2.2010002@fud.no> Message-ID: <1F9E43A29FE84916AF77397317539C53@MPC> +1 Mike Burns -----Original Message----- From: Tore Anderson Sent: Monday, September 30, 2013 9:51 AM To: address-policy-wg at ripe.net Subject: Re: [address-policy-wg] 2013-05 New Draft Document and Impact Analysis Published (No Restrictions on End User Assignments in Intra-RIR Transfers) +1 Tore From sandrabrown at ipv4marketgroup.com Tue Oct 1 16:52:03 2013 From: sandrabrown at ipv4marketgroup.com (sandrabrown at ipv4marketgroup.com) Date: Tue, 01 Oct 2013 07:52:03 -0700 Subject: [address-policy-wg] 2013-05 New Draft Document and Impact Analysis Published (No Restrictions on End User Assignments in Intra-RIR Transfers) Message-ID: <20131001075202.ec289651d84890fcbef5f195936e1217.7e640f6839.wbe@email17.secureserver.net> > The draft document for the proposal described in 2013-05, > "No Restrictions on End User Assignments in Intra-RIR Transfers" > has been published. The impact analysis that was conducted for this > proposal has also been published. +1. Sandra Brown From richih.mailinglist at gmail.com Wed Oct 2 08:16:23 2013 From: richih.mailinglist at gmail.com (Richard Hartmann) Date: Wed, 2 Oct 2013 08:16:23 +0200 Subject: [address-policy-wg] 2013-05 New Draft Document and Impact Analysis Published (No Restrictions on End User Assignments in Intra-RIR Transfers) In-Reply-To: <52497b8c.44630e0a.7f0a.ffff9eafSMTPIN_ADDED_MISSING@mx.google.com> References: <52497b8c.44630e0a.7f0a.ffff9eafSMTPIN_ADDED_MISSING@mx.google.com> Message-ID: +1 Sent by mobile; excuse my brevity. -------------- next part -------------- An HTML attachment was scrubbed... URL: From hph at oslo.net Wed Oct 2 14:58:44 2013 From: hph at oslo.net (Hans Petter Holen) Date: Wed, 02 Oct 2013 14:58:44 +0200 Subject: [address-policy-wg] RFC7020: The Internet Numbers Registry System Message-ID: <524C1884.2070801@oslo.net> In August the IETF published RFC7020 "" The Internet Numbers Registry System" as a replacement for RFC2050. http://tools.ietf.org/html/rfc7020 A question came up at today's Address Council call today: - "Does any of the global or regional policies need review following this?" I assume not - but it could be good to have the wg participants thoughts on this too. -- Hans Petter Holen Mobile +47 45 06 60 54 | hph at oslo.net | http://hph.oslo.net From gert at space.net Wed Oct 2 15:11:27 2013 From: gert at space.net (Gert Doering) Date: Wed, 2 Oct 2013 15:11:27 +0200 Subject: [address-policy-wg] RFC7020: The Internet Numbers Registry System In-Reply-To: <524C1884.2070801@oslo.net> References: <524C1884.2070801@oslo.net> Message-ID: <20131002131127.GX65295@Space.Net> Hi, On Wed, Oct 02, 2013 at 02:58:44PM +0200, Hans Petter Holen wrote: > In August the IETF published RFC7020 "" The Internet Numbers Registry > System" > as a replacement for RFC2050. http://tools.ietf.org/html/rfc7020 > > A question came up at today's Address Council call today: > - "Does any of the global or regional policies need review following this?" > > I assume not - but it could be good to have the wg participants thoughts > on this too. I find the question a bit strange, given that the IETF doesn't make local or global policies, and the RIRs' local communities' bottom-up processes are not really affected by documents published elsewhere... OTOH, there might be useful definitions in there ("IXP", "end site", etc.) where it might be useful to refer there instead of maintaing our own local definitions. OTOH, again, having fully self-contained and self-consistent local policy documents isn't bad either... Gert Doering -- APWG chair -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 306 bytes Desc: not available URL: From nick at inex.ie Wed Oct 2 15:19:20 2013 From: nick at inex.ie (Nick Hilliard) Date: Wed, 02 Oct 2013 14:19:20 +0100 Subject: [address-policy-wg] RFC7020: The Internet Numbers Registry System In-Reply-To: <20131002131127.GX65295@Space.Net> References: <524C1884.2070801@oslo.net> <20131002131127.GX65295@Space.Net> Message-ID: <524C1D58.4030106@inex.ie> On 02/10/2013 14:11, Gert Doering wrote: > OTOH, there might be useful definitions in there ("IXP", "end site", etc.) > where it might be useful to refer there instead of maintaing our own > local definitions. OTOH, again, having fully self-contained and > self-consistent local policy documents isn't bad either... RFC7020 looks ok to me - the evil level seems very low indeed. I'd be happy to suggest a vote of thanks to the IETF + the document authors for the work they put into the document, and for the RIPE community to welcome its publication. Nick From frettled at gmail.com Wed Oct 2 16:38:57 2013 From: frettled at gmail.com (Jan Ingvoldstad) Date: Wed, 2 Oct 2013 16:38:57 +0200 Subject: [address-policy-wg] RFC7020: The Internet Numbers Registry System In-Reply-To: <524C1884.2070801@oslo.net> References: <524C1884.2070801@oslo.net> Message-ID: On Wed, Oct 2, 2013 at 2:58 PM, Hans Petter Holen wrote: > In August the IETF published RFC7020 "" The Internet Numbers Registry > System" > as a replacement for RFC2050. http://tools.ietf.org/html/**rfc7020 > > A question came up at today's Address Council call today: > - "Does any of the global or regional policies need review following this?" > > I assume not - but it could be good to have the wg participants thoughts > on this too. > I don't see how an informational RFC like this should affect policy. It specifically states that it proposes no changes, and that it is not in the standards track. -- Jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew.dul at quark.net Wed Oct 2 17:14:51 2013 From: andrew.dul at quark.net (Andrew Dul) Date: Wed, 02 Oct 2013 08:14:51 -0700 Subject: [address-policy-wg] RFC7020: The Internet Numbers Registry System In-Reply-To: <524C1884.2070801@oslo.net> References: <524C1884.2070801@oslo.net> Message-ID: <524C386B.1030806@quark.net> On 10/2/2013 5:58 AM, Hans Petter Holen wrote: > In August the IETF published RFC7020 "" The Internet Numbers Registry > System" > as a replacement for RFC2050. http://tools.ietf.org/html/rfc7020 > > A question came up at today's Address Council call today: > - "Does any of the global or regional policies need review following > this?" > > I assume not - but it could be good to have the wg participants > thoughts on this too. > FYI, The ARIN region is currently working on draft policy 2013-4 as a result of RFC 2050 being moved to historical status. https://www.arin.net/policy/proposals/2013_4.html Andrew From hph at oslo.net Wed Oct 2 18:15:23 2013 From: hph at oslo.net (Hans Petter Holen) Date: Wed, 02 Oct 2013 18:15:23 +0200 Subject: [address-policy-wg] RFC7020: The Internet Numbers Registry System In-Reply-To: <524C386B.1030806@quark.net> References: <524C1884.2070801@oslo.net> <524C386B.1030806@quark.net> Message-ID: <524C469B.3000807@oslo.net> On 02.10.13 17:14, Andrew Dul wrote: > On 10/2/2013 5:58 AM, Hans Petter Holen wrote: >> In August the IETF published RFC7020 "" The Internet Numbers Registry >> System" >> as a replacement for RFC2050. http://tools.ietf.org/html/rfc7020 >> >> A question came up at today's Address Council call today: >> - "Does any of the global or regional policies need review following >> this?" >> >> I assume not - but it could be good to have the wg participants >> thoughts on this too. >> > FYI, The ARIN region is currently working on draft policy 2013-4 as a > result of RFC 2050 being moved to historical status. > > https://www.arin.net/policy/proposals/2013_4.html Interesting. Is the proposed Arin policy a regional policy or a proposed global policy? The name - RIR principles suggest the latter - otherwise it should have been ARIN Principles IMHO. > > Andrew Hans Petter -- Hans Petter Holen Mobile +47 45 06 60 54 | hph at oslo.net | http://hph.oslo.net From hph at oslo.net Wed Oct 2 18:51:10 2013 From: hph at oslo.net (Hans Petter Holen) Date: Wed, 02 Oct 2013 18:51:10 +0200 Subject: [address-policy-wg] RFC7020: The Internet Numbers Registry System In-Reply-To: <524C386B.1030806@quark.net> References: <524C1884.2070801@oslo.net> <524C386B.1030806@quark.net> Message-ID: <524C4EFE.6090802@oslo.net> On 02.10.13 17:14, Andrew Dul wrote: > On 10/2/2013 5:58 AM, Hans Petter Holen wrote: >> In August the IETF published RFC7020 "" The Internet Numbers Registry >> System" >> as a replacement for RFC2050. http://tools.ietf.org/html/rfc7020 >> >> A question came up at today's Address Council call today: >> - "Does any of the global or regional policies need review following >> this?" >> >> I assume not - but it could be good to have the wg participants >> thoughts on this too. >> > FYI, The ARIN region is currently working on draft policy 2013-4 as a > result of RFC 2050 being moved to historical status. > > https://www.arin.net/policy/proposals/2013_4.html and LACNIC-2013-02 http://www.lacnic.net/en/web/lacnic/politicas (The idea behind this specific proposal is not to be a global, but regional - I have been told) In our policies I was pointed to ripe-592 which spells out the registry system goals in section 3.0 and RIPE policy has included similar text since the publication of ripe-136 in May 1996. -- Hans Petter Holen Mobile +47 45 06 60 54 | hph at oslo.net | http://hph.oslo.net From andrew.dul at quark.net Wed Oct 2 18:28:52 2013 From: andrew.dul at quark.net (Andrew Dul) Date: Wed, 02 Oct 2013 09:28:52 -0700 Subject: [address-policy-wg] RFC7020: The Internet Numbers Registry System In-Reply-To: <524C469B.3000807@oslo.net> References: <524C1884.2070801@oslo.net> <524C386B.1030806@quark.net> <524C469B.3000807@oslo.net> Message-ID: <524C49C4.1020006@quark.net> On 10/2/2013 9:15 AM, Hans Petter Holen wrote: > On 02.10.13 17:14, Andrew Dul wrote: >> On 10/2/2013 5:58 AM, Hans Petter Holen wrote: >>> In August the IETF published RFC7020 "" The Internet Numbers Registry >>> System" >>> as a replacement for RFC2050. http://tools.ietf.org/html/rfc7020 >>> >>> A question came up at today's Address Council call today: >>> - "Does any of the global or regional policies need review following >>> this?" >>> >>> I assume not - but it could be good to have the wg participants >>> thoughts on this too. >>> >> FYI, The ARIN region is currently working on draft policy 2013-4 as a >> result of RFC 2050 being moved to historical status. >> >> https://www.arin.net/policy/proposals/2013_4.html > > Interesting. > Is the proposed Arin policy a regional policy or a proposed global > policy? > > The name - RIR principles suggest the latter - otherwise it should > have been ARIN Principles IMHO. > The draft policy only applies to the ARIN region at this point as that is the only place it is being discussed. Not speaking for the authors of the policy but as a contributor, I believe it would be valuable for other RIRs to consider if their policies would benefit from adding principles to their regional policies. There has also been some talk on the ARIN list if a different version of the policy should be created as a global policy which would eventually be passed by the ICANN board via the NRO to apply to the IANA registry. Andrew From leo.vegoda at icann.org Wed Oct 2 19:06:26 2013 From: leo.vegoda at icann.org (Leo Vegoda) Date: Wed, 2 Oct 2013 10:06:26 -0700 Subject: [address-policy-wg] RFC7020: The Internet Numbers Registry System In-Reply-To: <524C49C4.1020006@quark.net> References: <524C1884.2070801@oslo.net> <524C386B.1030806@quark.net> <524C469B.3000807@oslo.net> <524C49C4.1020006@quark.net> Message-ID: <5648A8908CCB564EBF46E2BC904A75B19680B6C602@EXVPMBX100-1.exc.icann.org> Andrew, Andrew Dul wrote: [...] > Not speaking for the authors of the policy but as a contributor, I > believe it would be valuable for other RIRs to consider if their > policies would benefit from adding principles to their regional > policies. There has also been some talk on the ARIN list if a different > version of the policy should be created as a global policy which would > eventually be passed by the ICANN board via the NRO to apply to the IANA > registry. Keep up at the back :-) That is indeed what is in section 3.0 of ripe-592: http://www.ripe.net/ripe/docs/ripe-592#Goals-Internet-Registry-System In fact, if you go back to ripe-136, from mid-1996, you'll find similar language there in section 2.2. Regards, Leo Vegoda -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5475 bytes Desc: not available URL: From hph at oslo.net Wed Oct 2 18:11:56 2013 From: hph at oslo.net (Hans Petter Holen) Date: Wed, 02 Oct 2013 18:11:56 +0200 Subject: [address-policy-wg] RFC7020: The Internet Numbers Registry System In-Reply-To: <20131002131127.GX65295@Space.Net> References: <524C1884.2070801@oslo.net> <20131002131127.GX65295@Space.Net> Message-ID: <524C45CC.3060607@oslo.net> On 02.10.13 15:11, Gert Doering wrote: > I find the question a bit strange, given that the IETF doesn't make > local or global policies, and the RIRs' local communities' bottom-up > processes are not really affected by documents published elsewhere... It could be if local or global policies refer to RFC2050 - it should be replaced - carefully. (a search on ripe.net for RFC 2050 gives 213 hits - Advanced search returns 21 hits in Policy and Draft and Current 9 in best common practice 2 in help documents. So I think at least some housekeeping is needed...) -- Hans Petter Holen Mobile +47 45 06 60 54 | hph at oslo.net | http://hph.oslo.net From gert at space.net Wed Oct 2 19:41:38 2013 From: gert at space.net (Gert Doering) Date: Wed, 2 Oct 2013 19:41:38 +0200 Subject: [address-policy-wg] RFC7020: The Internet Numbers Registry System In-Reply-To: <524C49C4.1020006@quark.net> References: <524C1884.2070801@oslo.net> <524C386B.1030806@quark.net> <524C469B.3000807@oslo.net> <524C49C4.1020006@quark.net> Message-ID: <20131002174138.GA65295@Space.Net> Hi, On Wed, Oct 02, 2013 at 09:28:52AM -0700, Andrew Dul wrote: > There has also been some talk on the ARIN list if a different > version of the policy should be created as a global policy which would > eventually be passed by the ICANN board via the NRO to apply to the IANA > registry. After the... interesting... experience of the last global policy proposal, which was nicely destroyed by a single registry's lawyer brigade, it would be quite interesting to see the outcome of this. It's *so* easy to void an immense amount of work in other regions by changing a few words here and there... "For a global policy, all *5* regions have to agree on the very same text" Gert Doering -- "no hats, but that won't help me hide" -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 306 bytes Desc: not available URL: From dburk at burkov.aha.ru Wed Oct 2 21:00:11 2013 From: dburk at burkov.aha.ru (Dmitry Burkov) Date: Wed, 2 Oct 2013 23:00:11 +0400 Subject: [address-policy-wg] RFC7020: The Internet Numbers Registry System In-Reply-To: <524C1884.2070801@oslo.net> References: <524C1884.2070801@oslo.net> Message-ID: <1F4F2F68-2CDB-4E1D-A2A6-6E17436205FA@burkov.aha.ru> It is a strange question as "This document provides information about the current Internet Numbers Registry System used in the distribution of globally unique Internet Protocol (IP) address space and autonomous system (AS) numbers. It also describes the processes used for further evolution of the Internet Numbers Registry System. This document does not propose any changes to the current operation of this system. " Dima On Oct 2, 2013, at 4:58 PM, Hans Petter Holen wrote: > In August the IETF published RFC7020 "" The Internet Numbers Registry System" > as a replacement for RFC2050. http://tools.ietf.org/html/rfc7020 > > A question came up at today's Address Council call today: > - "Does any of the global or regional policies need review following this?" > > I assume not - but it could be good to have the wg participants thoughts on this too. > > > -- > Hans Petter Holen > Mobile +47 45 06 60 54 | hph at oslo.net | http://hph.oslo.net > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Ragnar.Anfinsen at altibox.no Thu Oct 3 16:12:36 2013 From: Ragnar.Anfinsen at altibox.no (Anfinsen, Ragnar) Date: Thu, 3 Oct 2013 14:12:36 +0000 Subject: [address-policy-wg] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Cleanup) In-Reply-To: References: Message-ID: Apologies for a very late +1 MVH/Best Regards Ragnar > -----Original Message----- > From: address-policy-wg-bounces at ripe.net [mailto:address-policy-wg- > bounces at ripe.net] On Behalf Of Marco Schmidt > Sent: 19. september 2013 16:45 > To: policy-announce at ripe.net > Cc: address-policy-wg at ripe.net > Subject: [address-policy-wg] 2013-03 New Draft Document and Impact > Analysis Published (No Need - Post-Depletion Reality Adjustment and > Cleanup) > > > Dear Colleagues, > > Following the feedback received, the draft documents for the proposal > described in 2013-03 (No Need - Post-Depletion Reality Adjustment and > Cleanup) > are edited and published. > > The amendments are: > > - Retain "Fairness" goal > > - Retain "Need" for final /22 allocations > > - Clarify criteria for IXP assignment expansions > > > The impact analysis that was conducted for this proposal has also been > published. > > > You can find the full proposal and the impact analysis at: > > https://www.ripe.net/ripe/policies/proposals/2013-03 > > and the draft document at: > > https://www.ripe.net/ripe/policies/proposals/2013-03/draft > > We encourage you to read the draft document text and send any comments > to address-policy-wg at ripe.net before 18 October 2013. > > Regards, > > Marco Schmidt > Policy Development Office > RIPE NCC > > From elvis at v4escrow.net Thu Oct 3 16:28:23 2013 From: elvis at v4escrow.net (Elvis Daniel Velea) Date: Thu, 03 Oct 2013 16:28:23 +0200 Subject: [address-policy-wg] 2013-05 New Draft Document and Impact Analysis Published (No Restrictions on End User Assignments in Intra-RIR Transfers) Message-ID: <524D7F07.8000808@v4escrow.net> Hello, I agree with this policy change proposal. Regards, Elvis On 9/30/13 3:22 PM, Marco Schmidt wrote: > Dear colleagues, > > The draft document for the proposal described in 2013-05, > "No Restrictions on End User Assignments in Intra-RIR Transfers" > has been published. The impact analysis that was conducted for this > proposal has also been published. > > > You can find the full proposal and the impact analysis at: > > https://www.ripe.net/ripe/policies/proposals/2013-05 > > and the draft document at: > > https://www.ripe.net/ripe/policies/proposals/2013-05/draft > > We encourage you to read the draft document text and send any comments > to address-policy-wg at ripe.net before 29 October 2013. > > Regards > > Marco Schmidt > Policy Development Office > RIPE NCC > > -- V4Escrow, LLC -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: elvis.jpg Type: image/jpeg Size: 104713 bytes Desc: not available URL: From mueller at syr.edu Thu Oct 3 19:32:21 2013 From: mueller at syr.edu (Milton L Mueller) Date: Thu, 3 Oct 2013 17:32:21 +0000 Subject: [address-policy-wg] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Cleanup) In-Reply-To: <201309191445.r8JEjkuc006414@mx1.syr.edu> References: <201309191445.r8JEjkuc006414@mx1.syr.edu> Message-ID: <855077AC3D7A7147A7570370CA01ECD24FDEB8@SUEX10-mbx-10.ad.syr.edu> I believe that the revisions address the only valid objections that were aired in discussions and am willing to support the revised policy 2013-3 (No need: Post Depletion Reality Adjustment and Cleanup) -----Original Message----- From: address-policy-wg-bounces at ripe.net [mailto:address-policy-wg-bounces at ripe.net] On Behalf Of Marco Schmidt Sent: Thursday, September 19, 2013 10:45 AM To: policy-announce at ripe.net Cc: address-policy-wg at ripe.net Subject: [address-policy-wg] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Cleanup) Dear Colleagues, Following the feedback received, the draft documents for the proposal described in 2013-03 (No Need - Post-Depletion Reality Adjustment and Cleanup) are edited and published. The amendments are: - Retain "Fairness" goal - Retain "Need" for final /22 allocations - Clarify criteria for IXP assignment expansions The impact analysis that was conducted for this proposal has also been published. You can find the full proposal and the impact analysis at: https://www.ripe.net/ripe/policies/proposals/2013-03 and the draft document at: https://www.ripe.net/ripe/policies/proposals/2013-03/draft We encourage you to read the draft document text and send any comments to address-policy-wg at ripe.net before 18 October 2013. Regards, Marco Schmidt Policy Development Office RIPE NCC From andrea at ripe.net Fri Oct 4 15:12:42 2013 From: andrea at ripe.net (Andrea Cima) Date: Fri, 04 Oct 2013 15:12:42 +0200 Subject: [address-policy-wg] 2013-06 New Policy Proposal (PA/PI Unification IPv6 Address Space) In-Reply-To: <524A99F0.4060809@velea.eu> References: <52449DAC.2030700@inex.ie> <52452A96.9060405@fud.no> <66810E018CDF3344A676D4025D2350700F7B64@office-exbe-01.office.nbl.fi> <5249974C.8050904@velea.eu> <5249A9AA.8080308@fud.no> <5249AB3F.2080808@inex.ie> <5249AE1A.6050609@fud.no> <5249E180.2000602@inex.ie> <5249EB53.6060703@fud.no> <524A0A06.3040907@velea.eu> <20131001081935.GK65295@Space.Net> <524A99F0.4060809@velea.eu> Message-ID: <524EBECA.4050908@ripe.net> Hi Elvis, Please find the numbers below. On 10/1/13 11:46 AM, Elvis Velea wrote: > [1] to the RIPE NCC: Can you please give us some aggregate data > regarding the following numbers: > (We do not need exact numbers, as these will change 5 minutes later > once you make a new registry change - assignment/allocation/etc) > > 1. Is my number correct ? There are approximately 28355 PI assignments There are approximately 25.000 IPv4 PI assignments issued by the RIPE NCC. > 2. How many organisations are using these 28355 PIs? > Approximately 20.500 organisations. > 3. Is my number correct? There are approximately 1538 IPv6 PI assignments Correct. > 4. How many organisations are using these 1538 IPv6 PIs? > Approximately 1.450 organisations. > 5. How many LIRs have an IPv6 allocation but not an IPv4 one? Approximately 240. Regards, Andrea Cima RIPE NCC From gert at space.net Fri Oct 4 15:19:52 2013 From: gert at space.net (Gert Doering) Date: Fri, 4 Oct 2013 15:19:52 +0200 Subject: [address-policy-wg] 2013-06 New Policy Proposal (PA/PI Unification IPv6 Address Space) In-Reply-To: <524A91A9.7000604@velea.eu> References: <1380206290.2739@mobil.space.net> <20130926171155.GD65295@Space.Net> <52449DAC.2030700@inex.ie> <52452A96.9060405@fud.no> <52497DC6.3050103@velea.eu> <524A91A9.7000604@velea.eu> Message-ID: <20131004131952.GW65295@Space.Net> Hi, On Tue, Oct 01, 2013 at 11:11:05AM +0200, Elvis Velea wrote: > For example, you can use a /64 to number, let's say, 100 devices that > are in the same vlan doing the same thing and providing the same service > but you can not number 100 different customers within a /64. But do we want to state that? In web hosting environments, it's not uncommon to have 100 different customers on the very same hardware, each of them using a different IP(v6) address - and with vserver/jail type setups, each of them is typically only using a single address (unlike VM style setups where you might want to use "more"). Do we mandate (or even "encourage") using 100 different /64s for that purpose? I'd say "no" :-) - let the ISP do that if they *want*, but do not *mandate* it. Gert Doering -- speaking as someone who also runs a network -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 306 bytes Desc: not available URL: From frettled at gmail.com Fri Oct 4 15:49:28 2013 From: frettled at gmail.com (Jan Ingvoldstad) Date: Fri, 4 Oct 2013 15:49:28 +0200 Subject: [address-policy-wg] 2013-06 New Policy Proposal (PA/PI Unification IPv6 Address Space) In-Reply-To: <20131004131952.GW65295@Space.Net> References: <1380206290.2739@mobil.space.net> <20130926171155.GD65295@Space.Net> <52449DAC.2030700@inex.ie> <52452A96.9060405@fud.no> <52497DC6.3050103@velea.eu> <524A91A9.7000604@velea.eu> <20131004131952.GW65295@Space.Net> Message-ID: On Fri, Oct 4, 2013 at 3:19 PM, Gert Doering wrote: > Hi, > > On Tue, Oct 01, 2013 at 11:11:05AM +0200, Elvis Velea wrote: > > For example, you can use a /64 to number, let's say, 100 devices that > > are in the same vlan doing the same thing and providing the same service > > but you can not number 100 different customers within a /64. > > But do we want to state that? In web hosting environments, it's not > uncommon to have 100 different customers on the very same hardware, each > of them using a different IP(v6) address - and with vserver/jail type > setups, each of them is typically only using a single address (unlike VM > style setups where you might want to use "more"). > > Do we mandate (or even "encourage") using 100 different /64s for that > purpose? I'd say "no" :-) - let the ISP do that if they *want*, but > do not *mandate* it. > I think that was a nice way of rephrasing part of my point, thanks Gert! Another point is that these kinds of "customers" are far more ephemeral than what I believe RIPE policy is meant to regulate. The relationship between web site (or web virtualhost, if you like) and IP address is a many-to-many relationship: www.oyet.no has one IPv4 and one IPv6 address, but could've had several. www.ipv6.oyet.no could have a different IPv6 address, but still be the same "customer". But the IPv6 address used by www.ipv6.oyet.no could also be serving www.ipv6.onepocket.no, a different "customer". And in either case, the IPv6 address used for this purpose may not really be _assigned_ as such, but rather used temporarily, until the website(s) in question is moved to a different server or virtual server with different routing, or merely different address space segmentation. I imagine that e.g. Amazon or similar large-scale operations would be unhappy having to segment their space in the manner I understood the proposal at first. If the horse ain't dead yet, I'm happy to flog it a bit more by going into practical, human-readable IPv6 address segmentation for keeping address manageable. ;) -- Jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From maildanrl at gmail.com Sun Oct 6 13:17:02 2013 From: maildanrl at gmail.com (Dan Luedtke) Date: Sun, 6 Oct 2013 13:17:02 +0200 Subject: [address-policy-wg] 2013-06 New Policy Proposal (PA/PI Unification IPv6 Address Space) In-Reply-To: References: <1380206290.2739@mobil.space.net> <20130926171155.GD65295@Space.Net> <52449DAC.2030700@inex.ie> <52452A96.9060405@fud.no> <52497DC6.3050103@velea.eu> <524A91A9.7000604@velea.eu> <20131004131952.GW65295@Space.Net> Message-ID: Hi APWG, > 5.1.2 Initial Allocation Size > Allocations made by the RIPE NCC to the LIR have a minimum allocation size of a /32 and may be up to a /29 with no additional documentation required. > Allocations made by the RIPE NCC to the End User have a minimum allocation size of a /32. RIPE NCC reserves a /29 for every /32 allocation, right? So even End Users would "occupy" a /29 even if many of them would forever be satisfied with a /48? This is god news for the routing table as only prefixes size are going to change if End Users grow their networks. (Unlike in IPv4, were grows often implied new routes popping up). Elvis Velea wrote: > Creating different levels/limits will complicate the policy again and our aim was to make it as simple as possible. I like the proposals simplicity and I support the proposal from what I have read so far. Tore Anderson wrote: > Then you would have only one path and no confusion: > RIR[RIPE NCC] -> LIR -> End User I would support this if there is a way to eliminate the distinction of PI/PA in IPv4 too. In fact, with the initial proposal End Users are becoming IR in the moment they hand out their first address to a customer. The question is: How can we back off from those who *love* their Sponsoring LIR for doing all the "international RIPE stuff" and those who are eager to share some of their address space with friends/neighbors/customers? There should not arise any new requirement from a change like this for those who just want their network numbered without having to deal with international contracts but there should be new options for those who like to do IR things. RPKI, for example, is something the more tech-savy End Users are missing today. Nick Hilliard wrote: > So how could you convince the existing ipv6 PI holders that the cost > increase from ?50/year to LIR membership fees would be worth it? Speaking for me, not possible. Other small enterprises probably think the same. I think we should provide some strong incentive to become a LIR eventually. If the price jumps from 50EUR/yr to 1800EUR/yr business will ask what it gets for the extra money. BTW, I suggest renaming End User to SIR (Sponsored Internet Registry). A SIR could re-allocate its address space and/or just number their enterprise network with it. Cheers Dan -- Dan Luedtke http://www.danrl.de From elvis at velea.eu Sun Oct 6 14:39:24 2013 From: elvis at velea.eu (Elvis Velea) Date: Sun, 06 Oct 2013 14:39:24 +0200 Subject: [address-policy-wg] 2013-06 New Policy Proposal (PA/PI Unification IPv6 Address Space) In-Reply-To: References: <1380206290.2739@mobil.space.net> <20130926171155.GD65295@Space.Net> <52449DAC.2030700@inex.ie> <52452A96.9060405@fud.no> <52497DC6.3050103@velea.eu> <524A91A9.7000604@velea.eu> <20131004131952.GW65295@Space.Net> Message-ID: <525159FC.4050409@velea.eu> Hi Dan, thank you for the great feedback. Please see some of my comments inline. On 10/6/13 1:17 PM, Dan Luedtke wrote: > Hi APWG, > >> 5.1.2 Initial Allocation Size >> Allocations made by the RIPE NCC to the LIR have a minimum allocation size of a /32 and may be up to a /29 with no additional documentation required. >> Allocations made by the RIPE NCC to the End User have a minimum allocation size of a /32. > RIPE NCC reserves a /29 for every /32 allocation, right? > So even End Users would "occupy" a /29 even if many of them would > forever be satisfied with a /48? > This is god news for the routing table as only prefixes size are going > to change if End Users grow their networks. (Unlike in IPv4, were > grows often implied new routes popping up). Well, the RIPE NCC reserves two or three extra bits. So, if you get a /48, they will reserve a /45, if you get a /32, they reserve a /29, if you get a /29, they will reserve a /26. And indeed, the growth of the routing table will be kept low if every time someone will need an additional allocation, the RIPE NCC will just extend the current one with 1-3 bits. Additionally, if someone will specifically ask for a /48, the RIPE NCC will continue making the small allocation and the 2-3 bits reservation, it's not like.. whenever you ask for a /48 the RIPE NCC will reserve a /32 or /29. > > > Elvis Velea wrote: >> Creating different levels/limits will complicate the policy again and our aim was to make it as simple as possible. > I like the proposals simplicity and I support the proposal from what I > have read so far. I am glad, I see that the general feeling is that everyone likes it for being simple and there are just a few comments, mostly on the same topics. We have worked through a few iterations to get this proposal to be this simple. Some things may still be fixed for the second version of this proposal which I think will be published after we compile all the feedback from this list and the RIPE Meeting. > > Tore Anderson wrote: >> Then you would have only one path and no confusion: >> RIR[RIPE NCC] -> LIR -> End User > I would support this if there is a way to eliminate the distinction of > PI/PA in IPv4 too. In fact, with the initial proposal End Users are > becoming IR in the moment they hand out their first address to a > customer. The question is: How can we back off from those who *love* > their Sponsoring LIR for doing all the "international RIPE stuff" and > those who are eager to share some of their address space with > friends/neighbors/customers? There should not arise any new > requirement from a change like this for those who just want their > network numbered without having to deal with international contracts > but there should be new options for those who like to do IR things. > RPKI, for example, is something the more tech-savy End Users are > missing today. > It would be difficult, some End users still want to be independent from a particular LIR, by having only one path, and after looking at my crystal ball, I would see the following problems: a. RIPE NCC would allocate only to the LIR and the LIR could keep the end user captive - stay in a contract with me or renumber your network b. LIRs may start to de-aggregate their allocations up to a level that the global routing table may explode and we will really have nothing to do against it c. we may see anti-competitive laws or such, because only LIRs will be able to get addresses from the RIPE NCC and therefore, LIRs will be able to make their own rules on who gets what. You may be forced to become an LIR if you need addresses. > Nick Hilliard wrote: >> So how could you convince the existing ipv6 PI holders that the cost >> increase from ?50/year to LIR membership fees would be worth it? > Speaking for me, not possible. Other small enterprises probably think the same. > I think we should provide some strong incentive to become a LIR > eventually. If the price jumps from 50EUR/yr to 1800EUR/yr business > will ask what it gets for the extra money. Forcing everyone to become an LIR is going to be difficult. We have received some numbers from Andrea (thanks A.) and will propose some different discussion points during the RIPE Meeting. > > > BTW, I suggest renaming End User to SIR (Sponsored Internet Registry). > A SIR could re-allocate its address space and/or just number their > enterprise network with it. During one of the iterations of this policy proposal I had the idea of PIR (Portable Internet Registry). However, the idea was not very well received by the co-authors. It's definition was supposed to be: "A Portable Internet Registry is an IR which can request (via a Sponsoring LIR) an allocation from the RIR. The PIR sub-allocates address space to the users of the network services that it provides. " Considering the current feedback, I think we do need to define the additional layer we add to the chain. The PIR or SIR may not be good enough. If we do define the SIR/PIR, what do we do with the entity receiving a sub-allocation from an LIR, this entity will also be allowed to sub-allocate based on the proposed policy. What would we call that entity then? cheers, elvis From elvis at velea.eu Sun Oct 6 16:04:28 2013 From: elvis at velea.eu (Elvis Velea) Date: Sun, 06 Oct 2013 16:04:28 +0200 Subject: [address-policy-wg] 2013-06 New Policy Proposal (PA/PI Unification IPv6 Address Space) In-Reply-To: <524EBECA.4050908@ripe.net> References: <52449DAC.2030700@inex.ie> <52452A96.9060405@fud.no> <66810E018CDF3344A676D4025D2350700F7B64@office-exbe-01.office.nbl.fi> <5249974C.8050904@velea.eu> <5249A9AA.8080308@fud.no> <5249AB3F.2080808@inex.ie> <5249AE1A.6050609@fud.no> <5249E180.2000602@inex.ie> <5249EB53.6060703@fud.no> <524A0A06.3040907@velea.eu> <20131001081935.GK65295@Space.Net> <524A99F0.4060809@velea.eu> <524EBECA.4050908@ripe.net> Message-ID: <52516DEC.1010800@velea.eu> Hi Andrea, thank you for the numbers :-) On 10/4/13 3:12 PM, Andrea Cima wrote: > > Hi Elvis, > > Please find the numbers below. > > On 10/1/13 11:46 AM, Elvis Velea wrote: > >> [1] to the RIPE NCC: Can you please give us some aggregate data >> regarding the following numbers: >> (We do not need exact numbers, as these will change 5 minutes later >> once you make a new registry change - assignment/allocation/etc) >> >> 1. Is my number correct ? There are approximately 28355 PI assignments > > There are approximately 25.000 IPv4 PI assignments issued by the RIPE NCC. > >> 2. How many organisations are using these 28355 PIs? >> > > Approximately 20.500 organisations. > [...] So, we have about ~20.000 Non-LIRs and ~10.000 LIRs (round numbers) I'll ignore for now the rest of the numbers as these are too low to make a difference. I asked for these numbers to make a few estimations on how could the budget look like in the next years. What I was thinking to propose is the following: Let's consider, for the ease of calculation, that the RIPE NCC budget for 2015 will be ~?22M and we will have 10.000 LIRs and 20.000 non-LIRs using PIv4 or IPv6 allocations. The exact numbers could be provided by the RIPE NCC, however.. again, for the sake of conversation, let's consider the following scenarios based on rough numbers: 1. The simple way - the RIPE NCC budget could be divided in two parts, 50% paid by LIRs; 50% paid by Non-LIRs. ?11M would be paid by 10.000 LIRs and ?11M would be paid by the rest of 20.000 non-LIRs That means that the LIRs would see a decrease of 700? in their fees, they would pay 1100?/year. It also means that they users of PIv4 or IPv6 'direct' allocations would see an increase from 50? to 550?. I think this would be the easiest way, however, the RIPE NCC board may not agree to risk the budget. In that case, we could come up with the next calculus: 2. The complicated way - the RIPE NCC budget would be paid using the scheme 80/20% This means LIRs would pay 80% of the budget and would only see a decrease of 40? in the anual fee (from 1800? to 1760?) and the non-LIR would have to pay 220? (no matter how many resources they would use). This simple mathematical exercise has been made only considering that the whole budget would be constructed only from the fees. Additionally, current price / assignment is 50?. Considering that ~20.500 organisations are using ~25.000 assignments, some organisations already pay more than 50?, some even up to ?500 (if they use - for example - 10 assignments). 3. The fair way With 30.000 organisations and a 22M? budget, if we were to divide the price equally, every organisation would need to pay around 700?/year, no matter how many resources they use. That means a decrease of 1100? for each LIR and an increase of 650? (or less for the organisations using more than one assignment). I expect to see that organisations currently using IPv4 PI to start using IPv6 as well. That means that the increase would actually be from min 100? (50? for v4 and 50? for v6) to 700?. 4. Would you think of any other option? cheers, elvis From sander at steffann.nl Mon Oct 7 01:18:15 2013 From: sander at steffann.nl (Sander Steffann) Date: Mon, 7 Oct 2013 01:18:15 +0200 Subject: [address-policy-wg] 2013-06 New Policy Proposal (PA/PI Unification IPv6 Address Space) In-Reply-To: References: <1380206290.2739@mobil.space.net> <20130926171155.GD65295@Space.Net> <52449DAC.2030700@inex.ie> <52452A96.9060405@fud.no> <52497DC6.3050103@velea.eu> <524A91A9.7000604@velea.eu> <20131004131952.GW65295@Space.Net> Message-ID: Hi, > RIPE NCC reserves a /29 for every /32 allocation, right? No, they don't. It used to be like that a long time ago, but these days it is just sparse allocation. The change was announced at RIPE-61 (http://ripe61.ripe.net/presentations/331-Update_RIPE_NCC_R61.pdf) which was in November 2010. However: the current policy for IPv6 PI assignments specifies "Assignments will be made from a separate 'designated block' to facilitate filtering practices.". Is that worth keeping? Cheers, Sander From gert at space.net Mon Oct 7 09:47:45 2013 From: gert at space.net (Gert Doering) Date: Mon, 7 Oct 2013 09:47:45 +0200 Subject: [address-policy-wg] 2013-06 New Policy Proposal (PA/PI Unification IPv6 Address Space) In-Reply-To: References: <52449DAC.2030700@inex.ie> <52452A96.9060405@fud.no> <52497DC6.3050103@velea.eu> <524A91A9.7000604@velea.eu> <20131004131952.GW65295@Space.Net> Message-ID: <20131007074745.GD65295@Space.Net> Hi, On Mon, Oct 07, 2013 at 01:18:15AM +0200, Sander Steffann wrote: > However: the current policy for IPv6 PI assignments specifies > "Assignments will be made from a separate 'designated block' to > facilitate filtering practices.". Is that worth keeping? I find it useful. If only to help my scripts in building my routing table pictures (http://www.space.net/~gert/RIPE/weekly/) to find "outliers" - I tag address space blocks as "PI" or "IXP" or "DNS root", and then I normally do not need to do anything for new prefixes showing up, as opposed to "oh, a new /48, let's go to the RIPE DB and see what flavour it is". (Now, the "PI" category would not be named as such anymore, but it would still be "the small type of prefix" and as such worth to keep track on a separate line) Gert Doering -- speaking as IPv6 statistics geek -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 306 bytes Desc: not available URL: From elvis at velea.eu Mon Oct 7 11:25:11 2013 From: elvis at velea.eu (Elvis Velea) Date: Mon, 07 Oct 2013 11:25:11 +0200 Subject: [address-policy-wg] 2013-06 New Policy Proposal (PA/PI Unification IPv6 Address Space) In-Reply-To: References: <1380206290.2739@mobil.space.net> <20130926171155.GD65295@Space.Net> <52449DAC.2030700@inex.ie> <52452A96.9060405@fud.no> <52497DC6.3050103@velea.eu> <524A91A9.7000604@velea.eu> <20131004131952.GW65295@Space.Net> Message-ID: <52527DF7.1060206@velea.eu> Hi Sander, On 10/7/13 1:18 AM, Sander Steffann wrote: > Hi, > >> RIPE NCC reserves a /29 for every /32 allocation, right? > > No, they don't. It used to be like that a long time ago, but these days it is just sparse allocation. The change was announced at RIPE-61 (http://ripe61.ripe.net/presentations/331-Update_RIPE_NCC_R61.pdf) which was in November 2010. > I think they still reserve 3 bits, even with the sparse allocation algorithm. > However: the current policy for IPv6 PI assignments specifies "Assignments will be made from a separate 'designated block' to facilitate filtering practices.". Is that worth keeping? > As Gert also mentioned, I think that all 'special cases' allocations should still be made from a designated block. I am not sure if we should also request the RIPE NCC to make the /32s to the organisations (previously known as PI users) from a designated block. I do not see what the advantage would be. The organisations chosing to request a /48 allocation (instead of the /32) would not be any different than the ones actually getting the /32. So, I do not think these /48s should be made from different blocks either. I do agree that the allocations made for special purposes should still be made from a separate 'designated block'. And the current proposal states that. cheers, elvis From tore at fud.no Mon Oct 7 11:40:57 2013 From: tore at fud.no (Tore Anderson) Date: Mon, 07 Oct 2013 11:40:57 +0200 Subject: [address-policy-wg] 2013-06 New Policy Proposal (PA/PI Unification IPv6 Address Space) In-Reply-To: <52527DF7.1060206@velea.eu> References: <1380206290.2739@mobil.space.net> <20130926171155.GD65295@Space.Net> <52449DAC.2030700@inex.ie> <52452A96.9060405@fud.no> <52497DC6.3050103@velea.eu> <524A91A9.7000604@velea.eu> <20131004131952.GW65295@Space.Net> <52527DF7.1060206@velea.eu> Message-ID: <525281A9.5010907@fud.no> * Elvis Velea > On 10/7/13 1:18 AM, Sander Steffann wrote: >> Hi, >> >>> RIPE NCC reserves a /29 for every /32 allocation, right? >> >> No, they don't. It used to be like that a long time ago, but these >> days it is just sparse allocation. The change was announced at RIPE-61 >> (http://ripe61.ripe.net/presentations/331-Update_RIPE_NCC_R61.pdf) >> which was in November 2010. > > I think they still reserve 3 bits, even with the sparse allocation > algorithm. This is easy to find out, since delegations are public data. AFAICT: - Allocations (at least up to and including /29s): reserve a /26 (for some reason the allocated /32 isn't the first one in the /26) - Assignments (at least /48s): reserve a /46 $ grep 'ipv6.*201310' delegated-ripencc-extended-latest ripencc|AT|ipv6|2a00:f020::|32|20131001|allocated ripencc|SE|ipv6|2a00:f060::|32|20131001|allocated ripencc|NO|ipv6|2a00:f0a0::|32|20131001|allocated ripencc|QA|ipv6|2a00:f0e0::|32|20131001|allocated ripencc|AT|ipv6|2a00:f120::|32|20131002|allocated ripencc|RU|ipv6|2a00:f160::|32|20131002|allocated ripencc|BE|ipv6|2a00:f1a0::|32|20131002|allocated ripencc|SE|ipv6|2a00:f1e0::|32|20131002|allocated ripencc|ME|ipv6|2a00:f220::|32|20131002|allocated ripencc|AZ|ipv6|2a00:f260::|32|20131003|allocated ripencc|RU|ipv6|2a00:f2a0::|32|20131003|allocated ripencc|GE|ipv6|2a00:f2e0::|32|20131003|allocated ripencc|NL|ipv6|2a00:f320::|32|20131003|allocated ripencc|NL|ipv6|2a00:f360::|32|20131003|allocated ripencc|IT|ipv6|2a00:f3a0::|32|20131004|allocated ripencc|RU|ipv6|2a00:f3e0::|32|20131004|allocated ripencc|DE|ipv6|2a00:f420::|32|20131004|allocated ripencc|RU|ipv6|2a00:f460::|32|20131004|allocated ripencc|GG|ipv6|2a04:6b40::|29|20131001|allocated ripencc|NO|ipv6|2a04:6b80::|29|20131001|allocated ripencc|NL|ipv6|2a04:6bc0::|29|20131002|allocated ripencc|ES|ipv6|2a04:6c00::|29|20131002|allocated ripencc|BE|ipv6|2a04:6c40::|29|20131003|allocated ripencc|RO|ipv6|2a04:6c80::|29|20131003|allocated ripencc|SE|ipv6|2a04:6cc0::|29|20131003|allocated ripencc|SE|ipv6|2a04:6d00::|29|20131003|allocated ripencc|CH|ipv6|2a04:6d40::|29|20131004|allocated ripencc|PT|ipv6|2a04:6d80::|29|20131004|allocated ripencc|NL|ipv6|2a04:6dc0::|29|20131004|allocated ripencc|RU|ipv6|2001:67c:2be0::|48|20131001|assigned ripencc|PL|ipv6|2001:67c:2be4::|48|20131003|assigned ripencc|NL|ipv6|2001:67c:2be8::|48|20131004|assigned ripencc|PL|ipv6|2001:67c:2bec::|48|20131004|assigned Tore From andrea at ripe.net Mon Oct 7 12:21:18 2013 From: andrea at ripe.net (Andrea Cima) Date: Mon, 07 Oct 2013 12:21:18 +0200 Subject: [address-policy-wg] 2013-06 New Policy Proposal (PA/PI Unification IPv6 Address Space) In-Reply-To: <525159FC.4050409@velea.eu> References: <1380206290.2739@mobil.space.net> <20130926171155.GD65295@Space.Net> <52449DAC.2030700@inex.ie> <52452A96.9060405@fud.no> <52497DC6.3050103@velea.eu> <524A91A9.7000604@velea.eu> <20131004131952.GW65295@Space.Net> <525159FC.4050409@velea.eu> Message-ID: <52528B1E.6070804@ripe.net> Hi All, On 10/6/13 2:39 PM, Elvis Velea wrote: >>> 5.1.2 Initial Allocation Size >>> Allocations made by the RIPE NCC to the LIR have a minimum >>> allocation size of a /32 and may be up to a /29 with no additional >>> documentation required. >>> Allocations made by the RIPE NCC to the End User have a minimum >>> allocation size of a /32. >> RIPE NCC reserves a /29 for every /32 allocation, right? The RIPE NCC reserves three bits for each allocation. This is due to historical reasons as, according to policy, the RIPE NCC had to reserve a /29 for each LIR. /32s (and their reservations) are made using the sparse allocation method. >> So even End Users would "occupy" a /29 even if many of them would >> forever be satisfied with a /48? >> This is god news for the routing table as only prefixes size are going >> to change if End Users grow their networks. (Unlike in IPv4, were >> grows often implied new routes popping up). > > Well, the RIPE NCC reserves two or three extra bits. So, if you get a > /48, they will reserve a /45, We currently reserve two bits for IPv6 assignments, which is done on the basis of availability. According to the policy: "When possible, these further assignments will be made from an adjacent address block." http://www.ripe.net/ripe/docs/ripe-589#IPv6_PI_Assignments Best regards, Andrea Cima RIPE NCC > if you get a /32, they reserve a /29, if you get a /29, they will > reserve a /26. > > And indeed, the growth of the routing table will be kept low if every > time someone will need an additional allocation, the RIPE NCC will > just extend the current one with 1-3 bits. > > Additionally, if someone will specifically ask for a /48, the RIPE NCC > will continue making the small allocation and the 2-3 bits > reservation, it's not like.. whenever you ask for a /48 the RIPE NCC > will reserve a /32 or /29. > >> >> >> Elvis Velea wrote: >>> Creating different levels/limits will complicate the policy again >>> and our aim was to make it as simple as possible. >> I like the proposals simplicity and I support the proposal from what I >> have read so far. > > I am glad, I see that the general feeling is that everyone likes it > for being simple and there are just a few comments, mostly on the same > topics. > > We have worked through a few iterations to get this proposal to be > this simple. Some things may still be fixed for the second version of > this proposal which I think will be published after we compile all the > feedback from this list and the RIPE Meeting. > >> >> Tore Anderson wrote: >>> Then you would have only one path and no confusion: >>> RIR[RIPE NCC] -> LIR -> End User >> I would support this if there is a way to eliminate the distinction of >> PI/PA in IPv4 too. In fact, with the initial proposal End Users are >> becoming IR in the moment they hand out their first address to a >> customer. The question is: How can we back off from those who *love* >> their Sponsoring LIR for doing all the "international RIPE stuff" and >> those who are eager to share some of their address space with >> friends/neighbors/customers? There should not arise any new >> requirement from a change like this for those who just want their >> network numbered without having to deal with international contracts >> but there should be new options for those who like to do IR things. >> RPKI, for example, is something the more tech-savy End Users are >> missing today. >> > > It would be difficult, some End users still want to be independent > from a particular LIR, by having only one path, and after looking at > my crystal ball, I would see the following problems: > > a. RIPE NCC would allocate only to the LIR and the LIR could keep the > end user captive - stay in a contract with me or renumber your network > b. LIRs may start to de-aggregate their allocations up to a level that > the global routing table may explode and we will really have nothing > to do against it > c. we may see anti-competitive laws or such, because only LIRs will be > able to get addresses from the RIPE NCC and therefore, LIRs will be > able to make their own rules on who gets what. You may be forced to > become an LIR if you need addresses. > >> Nick Hilliard wrote: >>> So how could you convince the existing ipv6 PI holders that the cost >>> increase from ?50/year to LIR membership fees would be worth it? >> Speaking for me, not possible. Other small enterprises probably think >> the same. >> I think we should provide some strong incentive to become a LIR >> eventually. If the price jumps from 50EUR/yr to 1800EUR/yr business >> will ask what it gets for the extra money. > > Forcing everyone to become an LIR is going to be difficult. We have > received some numbers from Andrea (thanks A.) and will propose some > different discussion points during the RIPE Meeting. > >> >> >> BTW, I suggest renaming End User to SIR (Sponsored Internet Registry). >> A SIR could re-allocate its address space and/or just number their >> enterprise network with it. > > During one of the iterations of this policy proposal I had the idea of > PIR (Portable Internet Registry). However, the idea was not very well > received by the co-authors. > > It's definition was supposed to be: > > "A Portable Internet Registry is an IR which can request (via a > Sponsoring LIR) an allocation from the RIR. The PIR sub-allocates > address space to the users of the network services that it provides. " > > Considering the current feedback, I think we do need to define the > additional layer we add to the chain. > > The PIR or SIR may not be good enough. If we do define the SIR/PIR, > what do we do with the entity receiving a sub-allocation from an LIR, > this entity will also be allowed to sub-allocate based on the proposed > policy. What would we call that entity then? > > cheers, > elvis > > From elvis at velea.eu Mon Oct 7 12:24:10 2013 From: elvis at velea.eu (Elvis Velea) Date: Mon, 07 Oct 2013 12:24:10 +0200 Subject: [address-policy-wg] 2013-06 New Policy Proposal (PA/PI Unification IPv6 Address Space) In-Reply-To: <52528B1E.6070804@ripe.net> References: <1380206290.2739@mobil.space.net> <20130926171155.GD65295@Space.Net> <52449DAC.2030700@inex.ie> <52452A96.9060405@fud.no> <52497DC6.3050103@velea.eu> <524A91A9.7000604@velea.eu> <20131004131952.GW65295@Space.Net> <525159FC.4050409@velea.eu> <52528B1E.6070804@ripe.net> Message-ID: <52528BCA.3080605@velea.eu> Hi Andrea, On 10/7/13 12:21 PM, Andrea Cima wrote: [...] > The RIPE NCC reserves three bits for each allocation. This is due to > historical reasons as, according to policy, the RIPE NCC had to reserve > a /29 for each LIR. /32s (and their reservations) are made using the > sparse allocation method. [...] > > We currently reserve two bits for IPv6 assignments, which is done on the > basis of availability. According to the policy: "When possible, these > further assignments will be made from an adjacent address block." > > http://www.ripe.net/ripe/docs/ripe-589#IPv6_PI_Assignments Thanks for clarifying these procedures. > > Best regards, > Andrea Cima > RIPE NCC > Regards, Elvis From nigel at titley.com Mon Oct 7 18:25:56 2013 From: nigel at titley.com (Nigel Titley) Date: Mon, 07 Oct 2013 17:25:56 +0100 Subject: [address-policy-wg] 2013-06 New Policy Proposal (PA/PI Unification IPv6 Address Space) In-Reply-To: <20131001100432.GM65295@Space.Net> References: <52452A96.9060405@fud.no> <66810E018CDF3344A676D4025D2350700F7B64@office-exbe-01.office.nbl.fi> <5249974C.8050904@velea.eu> <5249A9AA.8080308@fud.no> <5249AB3F.2080808@inex.ie> <5249AE1A.6050609@fud.no> <5249E180.2000602@inex.ie> <524A0208.6070006@velea.eu> <524A8E58.2090903@inex.ie> <524A9BD7.8050003@velea.eu> <20131001100432.GM65295@Space.Net> Message-ID: <5252E094.5050406@titley.com> On 01/10/2013 11:04, Gert Doering wrote: > So the discussion needs to stay here, until this community is in > agreement. +1 > (Of course we give a HEADS UP to the members and the NCC board - for > example by giving a short summary in the NCC services working group, > at the RIPE meeting...) > At least one board member watches the discussions here ;-) Nigel From dburk at burkov.aha.ru Mon Oct 7 20:53:23 2013 From: dburk at burkov.aha.ru (Dmitry Burkov) Date: Mon, 7 Oct 2013 22:53:23 +0400 Subject: [address-policy-wg] 2013-06 New Policy Proposal (PA/PI Unification IPv6 Address Space) In-Reply-To: <5252E094.5050406@titley.com> References: <52452A96.9060405@fud.no> <66810E018CDF3344A676D4025D2350700F7B64@office-exbe-01.office.nbl.fi> <5249974C.8050904@velea.eu> <5249A9AA.8080308@fud.no> <5249AB3F.2080808@inex.ie> <5249AE1A.6050609@fud.no> <5249E180.2000602@inex.ie> <524A0208.6070006@velea.eu> <524A8E58.2090903@inex.ie> <524A9BD7.8050003@velea.eu> <20131001100432.GM65295@Space.Net> <5252E094.5050406@titley.com> Message-ID: On Oct 7, 2013, at 8:25 PM, Nigel Titley wrote: > On 01/10/2013 11:04, Gert Doering wrote: >> So the discussion needs to stay here, until this community is in >> agreement. > +1 >> (Of course we give a HEADS UP to the members and the NCC board - for >> example by giving a short summary in the NCC services working group, >> at the RIPE meeting...) >> > At least one board member watches the discussions here ;-) You are not alone :) Dmitry > > Nigel > From elvis at v4escrow.net Mon Oct 7 22:16:43 2013 From: elvis at v4escrow.net (Elvis Daniel Velea) Date: Mon, 07 Oct 2013 22:16:43 +0200 Subject: [address-policy-wg] 2013-06 New Policy Proposal (PA/PI Unification IPv6 Address Space) In-Reply-To: References: <52452A96.9060405@fud.no> <66810E018CDF3344A676D4025D2350700F7B64@office-exbe-01.office.nbl.fi> <5249974C.8050904@velea.eu> <5249A9AA.8080308@fud.no> <5249AB3F.2080808@inex.ie> <5249AE1A.6050609@fud.no> <5249E180.2000602@inex.ie> <524A0208.6070006@velea.eu> <524A8E58.2090903@inex.ie> <524A9BD7.8050003@velea.eu> <20131001100432.GM65295@Space.Net> <5252E094.5050406@titley.com> Message-ID: <525316AB.4020701@v4escrow.net> On 10/7/13 8:53 PM, Dmitry Burkov wrote: > On Oct 7, 2013, at 8:25 PM, Nigel Titley wrote: > >> On 01/10/2013 11:04, Gert Doering wrote: >>> So the discussion needs to stay here, until this community is in >>> agreement. >> +1 >>> (Of course we give a HEADS UP to the members and the NCC board - for >>> example by giving a short summary in the NCC services working group, >>> at the RIPE meeting...) >>> >> At least one board member watches the discussions here ;-) > You are not alone :) > > Dmitry >> Nigel >> > glad to know that you both are watching this with interest :-) regards, elvis -- V4Escrow, LLC -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: elvis.jpg Type: image/jpeg Size: 100106 bytes Desc: not available URL: From nigel at titley.com Tue Oct 8 15:37:40 2013 From: nigel at titley.com (Nigel Titley) Date: Tue, 08 Oct 2013 14:37:40 +0100 Subject: [address-policy-wg] 2013-06 New Policy Proposal (PA/PI Unification IPv6 Address Space) In-Reply-To: <525316AB.4020701@v4escrow.net> References: <52452A96.9060405@fud.no> <66810E018CDF3344A676D4025D2350700F7B64@office-exbe-01.office.nbl.fi> <5249974C.8050904@velea.eu> <5249A9AA.8080308@fud.no> <5249AB3F.2080808@inex.ie> <5249AE1A.6050609@fud.no> <5249E180.2000602@inex.ie> <524A0208.6070006@velea.eu> <524A8E58.2090903@inex.ie> <524A9BD7.8050003@velea.eu> <20131001100432.GM65295@Space.Net> <5252E094.5050406@titley.com> <525316AB.4020701@v4escrow.net> Message-ID: <52540AA4.3080006@titley.com> On 07/10/2013 21:16, Elvis Daniel Velea wrote: > On 10/7/13 8:53 PM, Dmitry Burkov wrote: >> On Oct 7, 2013, at 8:25 PM, Nigel Titley wrote: >> >>> At least one board member watches the discussions here ;-) >> You are not alone :) >> >> Dmitry >>> Nigel >>> > glad to know that you both are watching this with interest :-) Big Brother is indeed watching you... Nigel -------------- next part -------------- An HTML attachment was scrubbed... URL: From gm at iphh.net Tue Oct 8 17:42:38 2013 From: gm at iphh.net (Gregor Moeller) Date: Tue, 08 Oct 2013 17:42:38 +0200 Subject: [address-policy-wg] 2013-05 New Draft Document and Impact Analysis Published (No Restrictions on End User Assignments in Intra-RIR Transfers) In-Reply-To: <524D7F07.8000808@v4escrow.net> References: <524D7F07.8000808@v4escrow.net> Message-ID: <525427EE.9050207@iphh.net> clear and concise +1 -- Gregor Moeller E-Mail: support at iphh.net Technical Staff Tel: +49 (0)40 374919-10 IPHH Internet Port Hamburg GmbH Fax: +49 (0)40 374919-29 Wendenstrasse 408 AG Hamburg, HRB 76071 D-20537 Hamburg CEO: Axel G. Kroeger From ksyu at netassist.ua Wed Oct 9 01:34:57 2013 From: ksyu at netassist.ua (ksyu at netassist.ua) Date: Wed, 09 Oct 2013 02:34:57 +0300 Subject: [address-policy-wg] New Policy Proposal (PI - PA Transfer) Message-ID: <525496A1.9000209@netassist.ua> Hello everybody I would like to draw attention of the public to the next moment . According to the RIPE policy, a PI network should be used only as it was assigned. However, the time comes, the amount of clients increases, the number of services is growing up, and v4 addresses are not assigned any more. What should provider do in this case? The network was assigned for the particular service and can't be used for other services? Just returned back . But no one in their right mind will do this ) . It may be a topical solution for this situation - to return the opportunity to transfer PI blocks into the PA? This will give the opportunity to breathe more freely, not to violate the rules of RIPE policy . I suggest to discuse the question of transference of PI blocks to PA, and invite all caring to speak on the matter. Best regards, Kseniya Sokol -------------- next part -------------- An HTML attachment was scrubbed... URL: From info at leadertelecom.ru Wed Oct 9 05:14:55 2013 From: info at leadertelecom.ru (LeaderTelecom Ltd.) Date: Wed, 9 Oct 2013 07:14:55 +0400 Subject: [address-policy-wg] [Ticket#2013100901000742] New Policy Proposal (PI - PA Transfer) In-Reply-To: <525496A1.9000209@netassist.ua> References: <525496A1.9000209@netassist.ua> Message-ID: <1381288494.171338.022752706.354161.2@otrs.hostingconsult.ru> ? >?I suggest to discuse the question of transference of PI blocks to PA, and invite all caring to speak on the matter. I support. I think that we need this posibility. -- Alexey Ivanov LeaderTelecom 09.10.2013 03:57 - ksyu at netassist.ua ???????(?): Hello everybody I would like to draw attention of the public to the next moment . According to the RIPE policy, a PI network should be used only as it was assigned. However, the time comes, the amount of clients increases, the number of services is growing up, and v4 addresses are not assigned any more. What should provider do in this case? The network was assigned for the particular service and can't be used for other services? Just returned back . But no one in their right mind will do this ) . It may be a topical solution for this situation - to return the opportunity to transfer PI blocks into the PA? This will give the opportunity to breathe more freely, not to violate the rules of RIPE policy . I suggest to discuse the question of transference of PI blocks to PA, and invite all caring to speak on the matter. Best regards, Kseniya Sokol -------------- next part -------------- An HTML attachment was scrubbed... URL: From tomasz.slaski at gmail.com Wed Oct 9 08:22:55 2013 From: tomasz.slaski at gmail.com (=?UTF-8?B?VG9tYXN6IMWabMSFc2tpIEdNQUlM?=) Date: Wed, 09 Oct 2013 08:22:55 +0200 Subject: [address-policy-wg] New Policy Proposal (PI - PA Transfer) In-Reply-To: <525496A1.9000209@netassist.ua> References: <525496A1.9000209@netassist.ua> Message-ID: <5254F63F.20401@gmail.com> W dniu 2013-10-09 01:34, ksyu at netassist.ua pisze: > Hello everybody > > I would like to draw attention of the public to the next moment . > According to the RIPE policy, a PI network should be used only as it was > assigned. However, the time comes, the amount of clients increases, the > number of services is growing up, and v4 addresses are not assigned any > more. > What should provider do in this case? The network was assigned for the > particular service and can't be used for other services? Just returned > back . But no one in their right mind will do this ) . > It may be a topical solution for this situation - to return the > opportunity to transfer PI blocks into the PA? > This will give the opportunity to breathe more freely, not to violate > the rules of RIPE policy . > I suggest to discuse the question of transference of PI blocks to PA, > and invite all caring to speak on the matter. > > > Best regards, Kseniya Sokol Full support to convert PI to PA. Many people use PI breaking policy, because they have no other way. Conversion PI to PA solves many problems. Regards Tomasz From A.Hardy at e-quest.nl Wed Oct 9 09:17:12 2013 From: A.Hardy at e-quest.nl (Adrian Hardy) Date: Wed, 9 Oct 2013 07:17:12 +0000 Subject: [address-policy-wg] New Policy Proposal (PI - PA Transfer) In-Reply-To: <525496A1.9000209@netassist.ua> References: <525496A1.9000209@netassist.ua> Message-ID: <3A7FBF6B4989DE48BDE6E5D91A4EE1358BB39853@mail01.e-quest.local> Hi all, I think this subject was covered on this list earlier this year in the thread named; ?Guidance Requested: Changing the Status of PI Address Space?. I?m just not sure what the status is right now? Do we really need to restart the discussion? Regards, Adrian [cid:image113dcb.PNG at f7d5beb6.4a8a3d8c] e-Quest | Adrian Hardy Technical Consultant T: +31 492 392626 | Support: +31 492 780780 Schootense Dreef 26 | 5708 HZ | Helmond KVK:17121883 | BTW:8009998348B01 | http://www.e-quest.nl Van: address-policy-wg-bounces at ripe.net [mailto:address-policy-wg-bounces at ripe.net] Namens ksyu at netassist.ua Verzonden: woensdag 9 oktober 2013 01:35 Aan: address-policy-wg at ripe.net Onderwerp: [address-policy-wg] New Policy Proposal (PI - PA Transfer) Hello everybody I would like to draw attention of the public to the next moment . According to the RIPE policy, a PI network should be used only as it was assigned. However, the time comes, the amount of clients increases, the number of services is growing up, and v4 addresses are not assigned any more. What should provider do in this case? The network was assigned for the particular service and can't be used for other services? Just returned back . But no one in their right mind will do this ) . It may be a topical solution for this situation - to return the opportunity to transfer PI blocks into the PA? This will give the opportunity to breathe more freely, not to violate the rules of RIPE policy . I suggest to discuse the question of transference of PI blocks to PA, and invite all caring to speak on the matter. Best regards, Kseniya Sokol -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image113dcb.PNG Type: image/png Size: 34020 bytes Desc: image113dcb.PNG URL: From info at leadertelecom.ru Wed Oct 9 09:24:47 2013 From: info at leadertelecom.ru (LeaderTelecom Ltd.) Date: Wed, 9 Oct 2013 11:24:47 +0400 Subject: [address-policy-wg] [Ticket#2013100901002562] New Policy Proposal (PI - PA Transfer) In-Reply-To: <3A7FBF6B4989DE48BDE6E5D91A4EE1358BB39853@mail01.e-quest.local> References: <3A7FBF6B4989DE48BDE6E5D91A4EE1358BB39853@mail01.e-quest.local><525496A1.9000209@netassist.ua> Message-ID: <1381303485.627167.707476536.354343.2@otrs.hostingconsult.ru> Dear?Adrian, I think this subject was covered on this list earlier this year in the thread named; ?Guidance Requested: Changing the Status of PI Address Space?. I?m just not sure what the status is right now?? I not sure too about status, but ready to work in working group if it already exist.? Could someone update about current status? -- Alexey Ivanov 09.10.2013 11:19 - Adrian Hardy ???????(?): Hi all, ? I think this subject was covered on this list earlier this year in the thread named; ?Guidance Requested: Changing the Status of PI Address Space?. I?m just not sure what the status is right now? Do we really need to restart the discussion? ? Regards, ? Adrian ? e-Quest | Adrian Hardy Technical Consultant T: +31 492 392626?| Support: +31 492 780780 Schootense Dreef 26 | 5708 HZ | Helmond KVK:17121883 | BTW:8009998348B01 | [1]http://www.e-quest.nl Van: address-policy-wg-bounces at ripe.net [mailto:address-policy-wg-bounces at ripe.net] Namens ksyu at netassist.ua Verzonden: woensdag 9 oktober 2013 01:35 Aan: address-policy-wg at ripe.net Onderwerp: [address-policy-wg] New Policy Proposal (PI - PA Transfer) Hello everybody I would like to draw attention of the public to the next moment . According to the RIPE policy, a PI network should be used only as it was assigned. However, the time comes, the amount of clients increases, the number of services is growing up, and v4 addresses are not assigned any more. What should provider do in this case? The network was assigned for the particular service and can't be used for other services? Just returned back . But no one in their right mind will do this ) . It may be a topical solution for this situation - to return the opportunity to transfer PI blocks into the PA? This will give the opportunity to breathe more freely, not to violate the rules of RIPE policy . I suggest to discuse the question of transference of PI blocks to PA, and invite all caring to speak on the matter. Best regards, Kseniya Sokol [1] http://www.e-quest.nl -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image113dcb.PNG Type: image/png Size: 34020 bytes Desc: not available URL: From ripe at vkc.com.ua Wed Oct 9 11:57:20 2013 From: ripe at vkc.com.ua (ripe at vkc.com.ua) Date: Wed, 09 Oct 2013 12:57:20 +0300 Subject: [address-policy-wg] [Ticket#2013100901000742] New Policy Proposal (PI - PA Transfer) In-Reply-To: <1381288494.171338.022752706.354161.2@otrs.hostingconsult.ru> References: <525496A1.9000209@netassist.ua> <1381288494.171338.022752706.354161.2@otrs.hostingconsult.ru> Message-ID: <52552880.6040504@vkc.com.ua> > I suggest to discuse the question of transference of PI blocks to PA, and invite all caring to speak on the matter. I support. -- Oleksandr 09.10.2013 6:14, LeaderTelecom Ltd. ?????: > > I suggest to discuse the question of transference of PI blocks to > PA, and invite all caring to speak on the matter. > > I support. I think that we need this posibility. > > -- > Alexey Ivanov > LeaderTelecom From ipas.master at gmail.com Wed Oct 9 12:10:26 2013 From: ipas.master at gmail.com (Andrey Kushnireuski) Date: Wed, 9 Oct 2013 12:10:26 +0200 Subject: [address-policy-wg] [Ticket#2013100901000742] New Policy Proposal (PI - PA Transfer) In-Reply-To: <52552880.6040504@vkc.com.ua> References: <525496A1.9000209@netassist.ua> <1381288494.171338.022752706.354161.2@otrs.hostingconsult.ru> <52552880.6040504@vkc.com.ua> Message-ID: I think the best opportunity is to allow PI to PA transfer for LIR only... so If a resources holder is interesting to transfer their resources from PI to PA they need to be a LIR. On Oct 9, 2013, at 11:57 AM, ripe at vkc.com.ua wrote: > > I suggest to discuse the question of transference of PI blocks to PA, and invite all caring to speak on the matter. > > I support. > > -- > Oleksandr > > > > 09.10.2013 6:14, LeaderTelecom Ltd. ?????: >> > I suggest to discuse the question of transference of PI blocks to PA, and invite all caring to speak on the matter. >> >> I support. I think that we need this posibility. >> >> -- >> Alexey Ivanov >> LeaderTelecom > > - Andrei Kushnireuski AK1065-RIPE regID: cz.alfatelecom From ipas.master at gmail.com Wed Oct 9 12:22:23 2013 From: ipas.master at gmail.com (Andrey Kushnireuski) Date: Wed, 9 Oct 2013 12:22:23 +0200 Subject: [address-policy-wg] [Ticket#2013100901000742] New Policy Proposal (PI - PA Transfer) In-Reply-To: References: <525496A1.9000209@netassist.ua> <1381288494.171338.022752706.354161.2@otrs.hostingconsult.ru> <52552880.6040504@vkc.com.ua> Message-ID: <85DF69CF-5D3D-4E07-82CC-73789D6A396A@gmail.com> I think the best opportunity is to allow PI to PA transfer for LIR only... so If a resources holder is interesting to transfer their resources from PI to PA they need to be a LIR. On Oct 9, 2013, at 11:57 AM, ripe at vkc.com.ua wrote: >> I suggest to discuse the question of transference of PI blocks to PA, and invite all caring to speak on the matter. > > I support. > > -- > Oleksandr > > > > 09.10.2013 6:14, LeaderTelecom Ltd. ?????: >>> I suggest to discuse the question of transference of PI blocks to PA, and invite all caring to speak on the matter. >> >> I support. I think that we need this posibility. >> >> -- >> Alexey Ivanov >> LeaderTelecom > > - Andrei Kushnireuski From noable at gmail.com Wed Oct 9 12:24:32 2013 From: noable at gmail.com (Andrew Noable) Date: Wed, 9 Oct 2013 12:24:32 +0200 Subject: [address-policy-wg] [Ticket#2013100901000742] New Policy Proposal (PI - PA Transfer) In-Reply-To: <52552880.6040504@vkc.com.ua> References: <525496A1.9000209@netassist.ua> <1381288494.171338.022752706.354161.2@otrs.hostingconsult.ru> <52552880.6040504@vkc.com.ua> Message-ID: I think the best opportunity is to allow PI to PA transfer for LIR only... so If a resources holder is interesting to transfer their resources from PI to PA they need to be a LIR. - Andrei Kushnireuski From Robert.Sleigh at ee.co.uk Wed Oct 9 12:48:36 2013 From: Robert.Sleigh at ee.co.uk (Sleigh, Robert) Date: Wed, 9 Oct 2013 11:48:36 +0100 Subject: [address-policy-wg] 2013-06 New Policy Proposal (PA/PI Unification IPv6 Address Space) In-Reply-To: <52540AA4.3080006@titley.com> References: <52452A96.9060405@fud.no><66810E018CDF3344A676D4025D2350700F7B64@office-exbe-01.office.nbl.fi><5249974C.8050904@velea.eu> <5249A9AA.8080308@fud.no><5249AB3F.2080808@inex.ie> <5249AE1A.6050609@fud.no><5249E180.2000602@inex.ie> <524A0208.6070006@velea.eu><524A8E58.2090903@inex.ie> <524A9BD7.8050003@velea.eu><20131001100432.GM65295@Space.Net> <5252E094.5050406@titley.com><525316AB.4020701@v4escrow.net> <52540AA4.3080006@titley.com> Message-ID: <7589326DC369BE4EAACEB3A2EB92F8E3133BFA98@HATMSG025.TMOUSERSUK.AD.T-MOBILE.CO.UK> From: address-policy-wg-bounces at ripe.net [mailto:address-policy-wg-bounces at ripe.net] On Behalf Of Nigel Titley Sent: 08 October 2013 14:38 To: address-policy-wg at ripe.net Subject: Re: [address-policy-wg] 2013-06 New Policy Proposal (PA/PI Unification IPv6 Address Space) On 07/10/2013 21:16, Elvis Daniel Velea wrote: On 10/7/13 8:53 PM, Dmitry Burkov wrote: On Oct 7, 2013, at 8:25 PM, Nigel Titley wrote: At least one board member watches the discussions here ;-) You are not alone :) Dmitry Nigel glad to know that you both are watching this with interest :-) Big Brother is indeed watching you... Nigel I'd never noticed the family resemblance before... Regards Bob 07958 318592 Life's for sharing... and what I like to share the most is a smile NOTICE AND DISCLAIMER This e-mail (including any attachments) is intended for the above-named person(s). If you are not the intended recipient, notify the sender immediately, delete this email from your system and do not disclose or use for any purpose. We may monitor all incoming and outgoing emails in line with current legislation. We have taken steps to ensure that this email and attachments are free from any virus, but it remains your responsibility to ensure that viruses do not adversely affect you. EE Limited Registered in England and Wales Company Registered Number: 02382161 Registered Office Address: Trident Place, Mosquito Way, Hatfield, Hertfordshire, AL10 9BW -------------- next part -------------- An HTML attachment was scrubbed... URL: From tore at fud.no Wed Oct 9 13:02:02 2013 From: tore at fud.no (Tore Anderson) Date: Wed, 09 Oct 2013 13:02:02 +0200 Subject: [address-policy-wg] [Ticket#2013100901000742] New Policy Proposal (PI - PA Transfer) In-Reply-To: References: <525496A1.9000209@netassist.ua> <1381288494.171338.022752706.354161.2@otrs.hostingconsult.ru> <52552880.6040504@vkc.com.ua> Message-ID: <525537AA.6080200@fud.no> * Andrew Noable > I think the best opportunity is to allow PI to PA transfer for LIR > only... so If a resources holder is interesting to transfer their > resources from PI to PA they need to be a LIR. I believe only LIRs may hold PA space in any case. However we might consider whether it should be possible for (non-LIR) PI holders to transfer their blocks to LIRs under the provisions in section 5.5, converting them to PA in the process. (I wouldn't be opposed to that.) It would be good to get an update from the NCC on which conclusions they've drawn from the ?Guidance requested? thread and how they will change their procedures (if at all). To me the community's guidance seemed clear enough, but perhaps we need to run this through the PDP anyway? Tore From noable at gmail.com Wed Oct 9 13:45:27 2013 From: noable at gmail.com (Andrew Noable) Date: Wed, 9 Oct 2013 13:45:27 +0200 Subject: [address-policy-wg] [Ticket#2013100901000742] New Policy Proposal (PI - PA Transfer) In-Reply-To: <525537AA.6080200@fud.no> References: <525496A1.9000209@netassist.ua> <1381288494.171338.022752706.354161.2@otrs.hostingconsult.ru> <52552880.6040504@vkc.com.ua> <525537AA.6080200@fud.no> Message-ID: Sorry I was wrong with my procedure description =( Let me clarify: As you know currently there are a lot of assigned PI resources. Based on RIPE NCC policy as soon as resources are not in use they must be returned to RIPE NCC. Now I see a 'black market' of PI resources transfer from one company to another. So company B 'purchases' unused PI IPv4 assignment from company A based on fake buy/sell contract. my suggestion is to allow PI to PA transfer for original companies only. i.e. company A already has PI assignment from RIPE NCC, if they want to change status from PI to PA they need to became LIR. If the resources were transferred from one company to another they couldn't be changed to PA because this is a variant for 'legalization' i.e. company B 'purchases' PI resources and transfers them to PA... so RIPE NCC has no reasons to return resources which were not in use... because their status was changed and now they're Allocated PA. Or transfer with justification only. P.S.: I'm sure there are a lot of unused PI Ipv4 resources are on hold by the guys who want to monetirize them and PI to PA transfer without limits is a major variant for same legalized transfer. On Oct 9, 2013, at 1:02 PM, Tore Anderson wrote: > * Andrew Noable > >> I think the best opportunity is to allow PI to PA transfer for LIR >> only... so If a resources holder is interesting to transfer their >> resources from PI to PA they need to be a LIR. > > I believe only LIRs may hold PA space in any case. However we might > consider whether it should be possible for (non-LIR) PI holders to > transfer their blocks to LIRs under the provisions in section 5.5, > converting them to PA in the process. (I wouldn't be opposed to that.) > > It would be good to get an update from the NCC on which conclusions > they've drawn from the ?Guidance requested? thread and how they will > change their procedures (if at all). To me the community's guidance > seemed clear enough, but perhaps we need to run this through the PDP anyway? > > Tore > From rb at isppro.de Wed Oct 9 14:41:52 2013 From: rb at isppro.de (Ronny Boesger [ISPpro Internet KG]) Date: Wed, 09 Oct 2013 14:41:52 +0200 Subject: [address-policy-wg] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Cleanup) Message-ID: <52554F10.1040706@isppro.de> we support 2013-03 also +1 best regards, ronny -- Mit freundlichen Gruessen / kind regards, Ronny Boesger --- ISPpro Internet KG Lahnsteiner Strasse 7 07629 Hermsdorf Germany -------------- next part -------------- A non-text attachment was scrubbed... Name: rb.vcf Type: text/x-vcard Size: 285 bytes Desc: not available URL: From db at rrbone.net Wed Oct 9 14:53:01 2013 From: db at rrbone.net (Dominik Bay) Date: Wed, 9 Oct 2013 14:53:01 +0200 Subject: [address-policy-wg] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Cleanup) In-Reply-To: <52554F10.1040706@isppro.de> References: <52554F10.1040706@isppro.de> Message-ID: <525551AD.4080108@rrbone.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 We, de.rrbone, vote in favour of 2013-03 - -dominik - -- rrbone UG (haftungsbeschraenkt) - Leibnizstr. 8a - 44147 Dortmund HR B 23168 Amtsgericht Dortmund - Geschaeftsfuehrer: Dominik Bay -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAlJVUa0ACgkQZ04dCS8PSjsz6gCgjQeMVSncSiREnFcZDwm8K10K I34An3xKABgAUHImb8MuPSHLZpdz5Hfr =khqY -----END PGP SIGNATURE----- From denis at ripe.net Wed Oct 9 16:15:00 2013 From: denis at ripe.net (Denis Walker) Date: Wed, 09 Oct 2013 16:15:00 +0200 Subject: [address-policy-wg] Fwd: Clean up of old ASN references in the RIPE Database In-Reply-To: <52552C05.7020103@ripe.net> References: <52552C05.7020103@ripe.net> Message-ID: <525564E4.5050500@ripe.net> Dear colleagues, A first batch of emails has now been sent out for this project. Regards, Denis Walker Business Analyst RIPE NCC Database Team -------- Original Message -------- Subject: Clean up of old ASN references in the RIPE Database Date: Wed, 09 Oct 2013 12:12:21 +0200 From: Denis Walker Organization: RIPE NCC To: ncc-announce at ripe.net Dear colleagues, The RIPE NCC is starting to clean up references to returned AS Numbers in the RIPE Database, as discussed on the Address Policy Working Group Mailing List. The first batch of emails will be sent out today to the maintainers of the referencing objects. For details please see https://labs.ripe.net/Members/denis/making-more-16-bit-as-numbers-available Regards, Denis Walker Business Analyst RIPE NCC Database Team From gert at space.net Wed Oct 9 16:20:28 2013 From: gert at space.net (Gert Doering) Date: Wed, 9 Oct 2013 16:20:28 +0200 Subject: [address-policy-wg] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Cleanup) In-Reply-To: <525551AD.4080108@rrbone.net> References: <52554F10.1040706@isppro.de> <525551AD.4080108@rrbone.net> Message-ID: <20131009142028.GQ65295@Space.Net> Hi, On Wed, Oct 09, 2013 at 02:53:01PM +0200, Dominik Bay wrote: > We, de.rrbone, vote in favour of 2013-03 Just to be a nitpicking old chair... :-) - this is not actually a "vote", and it's not your LIR not-voting, but a personal voice of support. Nonetheless, thanks for that! (The issue with "vote" is that we'd need rules for "who can vote", and "who has how many votes", which might be tied to LIR membership, but then, RIPE policy making is open for anyone from the community and not only for members, and as such, voting could be extremely easily rigged... so we don't) Gert Doering -- APWG chair -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 306 bytes Desc: not available URL: From db at rrbone.net Wed Oct 9 16:32:58 2013 From: db at rrbone.net (Dominik Bay) Date: Wed, 9 Oct 2013 16:32:58 +0200 Subject: [address-policy-wg] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Cleanup) In-Reply-To: <20131009142028.GQ65295@Space.Net> References: <52554F10.1040706@isppro.de> <525551AD.4080108@rrbone.net> <20131009142028.GQ65295@Space.Net> Message-ID: <5255691A.9090204@rrbone.net> On 10/09/2013 04:20 PM, Gert Doering wrote: > On Wed, Oct 09, 2013 at 02:53:01PM +0200, Dominik Bay wrote: >> We, de.rrbone, vote in favour of 2013-03 > > Just to be a nitpicking old chair... :-) - this is not actually a "vote", > and it's not your LIR not-voting, but a personal voice of support. > > Nonetheless, thanks for that! > > (The issue with "vote" is that we'd need rules for "who can vote", and > "who has how many votes", which might be tied to LIR membership, but then, > RIPE policy making is open for anyone from the community and not only for > members, and as such, voting could be extremely easily rigged... so we > don't) To make that clear, I'm showing support for the particular document as an entity. This should not be confused with regular understanding of a vote but for support with the PDP as you mentioned. -- rrbone UG (haftungsbeschraenkt) - Leibnizstr. 8a - 44147 Dortmund HR B 23168 Amtsgericht Dortmund - Geschaeftsfuehrer: Dominik Bay From lutz at iks-jena.de Wed Oct 9 16:37:03 2013 From: lutz at iks-jena.de (Lutz Donnerhacke) Date: Wed, 9 Oct 2013 14:37:03 +0000 (UTC) Subject: [address-policy-wg] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Cleanup) References: <20131009142028.GQ65295@Space.Net> Message-ID: * Gert Doering wrote: > Just to be a nitpicking old chair... :-) - this is not actually a "vote", > and it's not your LIR not-voting, but a personal voice of support. So let me add a personal +1 for 2013-03. From andrea at ripe.net Thu Oct 10 12:57:35 2013 From: andrea at ripe.net (Andrea Cima) Date: Thu, 10 Oct 2013 12:57:35 +0200 Subject: [address-policy-wg] New Policy Proposal (PI - PA Transfer) In-Reply-To: <525496A1.9000209@netassist.ua> References: <525496A1.9000209@netassist.ua> Message-ID: <5256881F.5000208@ripe.net> Dear colleagues, Following the increasing number of requests from LIRs that want to convert their PI assignments into PA allocations, we proposed the following options at RIPE 66: 1) Allow LIRs to change the status of their PI assignments into PA allocations (if equal or larger than the minimum allocation size) 2) Do not allow LIRs to change the status of their PI assignments into PA allocations After RIPE 66, the discussion was continued on the Address Policy Working Group Mailing List. There seemed to be a lot of support for allowing LIRs to change the status of their resources, but people also wanted the minimum allocation size to be disregarded. This would allow for PA allocations smaller than the minimum allocation size. It is our understanding that this last point would require a policy change. We will be addressing this as part of our "Feedback From RIPE NCC Registration Services" presentation at RIPE 67. Based on the feedback we receive from here, we will work with the Working Group Chairs on a way forward. Kind regards, Andrea Cima RIPE NCC On 10/9/13 1:34 AM, ksyu at netassist.ua wrote: > Hello everybody > > I would like to draw attention of the public to the next moment . > According to the RIPE policy, a PI network should be used only as it > was assigned. However, the time comes, the amount of clients > increases, the number of services is growing up, and v4 addresses are > not assigned any more. > What should provider do in this case? The network was assigned for the > particular service and can't be used for other services? Just returned > back . But no one in their right mind will do this ) . > It may be a topical solution for this situation - to return the > opportunity to transfer PI blocks into the PA? > This will give the opportunity to breathe more freely, not to violate > the rules of RIPE policy . > I suggest to discuse the question of transference of PI blocks to PA, > and invite all caring to speak on the matter. > > > Best regards, Kseniya Sokol -------------- next part -------------- An HTML attachment was scrubbed... URL: From tore at fud.no Thu Oct 10 13:20:46 2013 From: tore at fud.no (Tore Anderson) Date: Thu, 10 Oct 2013 13:20:46 +0200 Subject: [address-policy-wg] New Policy Proposal (PI - PA Transfer) In-Reply-To: <5256881F.5000208@ripe.net> References: <525496A1.9000209@netassist.ua> <5256881F.5000208@ripe.net> Message-ID: <52568D8E.7080005@fud.no> Hi Andrea and thanks for the update! > This would allow for PA allocations smaller than the minimum > allocation size. It is our understanding that this last point would > require a policy change. Out of curiousity, how did these come about then? ripencc|SE|ipv4|193.108.42.0|512|20010406|allocated ripencc|DE|ipv4|193.218.220.0|512|19981110|allocated ripencc|PT|ipv4|194.117.48.0|512|19941206|allocated ripencc|IT|ipv4|194.153.212.0|512|20000509|allocated FWIW, I've always considered the minimum allocation size the minimum size *that the RIPE NCC may allocate* - not the minimum allocation size that may exist in the database at a given point in time. The existence of the above four allocations appears to preclude the latter interpretation in any case. With the former interpretation PI->PA conversions for blocks smaller than the minimum allocation size is quite OK by policy, as it isn't an allocation performed by the RIPE NCC from the free pool. Besides, I can't think of any reason for having a minimum allocation size in the first place except to prevent deaggregation, but these as those PI blocks are already deaggregated that's not applicable here either. IMHO, anyway... Tore From nick at inex.ie Thu Oct 10 14:36:54 2013 From: nick at inex.ie (Nick Hilliard) Date: Thu, 10 Oct 2013 13:36:54 +0100 Subject: [address-policy-wg] New Policy Proposal (PI - PA Transfer) In-Reply-To: <5256881F.5000208@ripe.net> References: <525496A1.9000209@netassist.ua> <5256881F.5000208@ripe.net> Message-ID: <52569F66.1090100@inex.ie> On 10/10/2013 11:57, Andrea Cima wrote: > 1) Allow LIRs to change the status of their PI assignments into PA > allocations (if equal or larger than the minimum allocation size) > 2) Do not allow LIRs to change the status of their PI assignments into PA allocations Andrea, On May 7 2009, Alex le Heux posted a breakdown of IPv4 PI assignment statistics: > http://www.ripe.net/ripe/mail/archives/address-policy-wg/2009-May/004212.html This indicated at at the time, only ~20% of all ipv4 PI assignments were /22 or larger. The two choices presented here mean that the 80% of people with PI assignments of /23 or less would be disenfranchised by this policy regardless of which way it might go. Also it's not compatible with the efforts under way to unify pi/pa ipv6. I.e. I don't think that either of these options is necessarily a good idea. Nick From mschmidt at ripe.net Thu Oct 10 16:10:37 2013 From: mschmidt at ripe.net (Marco Schmidt) Date: Thu, 10 Oct 2013 16:10:37 +0200 Subject: [address-policy-wg] RIPE Policy Proposal 2012-07 - Effect on ripe-592 Message-ID: <5256B55D.3050107@ripe.net> Dear colleagues, We just published a new version of RIPE Policy Proposal 2012-07, ?RIPE NCC Services to Legacy Internet Resource Holders? to the RIPE NCC Services Working Group mailing list. One aspect of this policy proposal is that it contains a small amendment to the existing policy document ripe-592, "IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region". Policy Proposal 2012-07 proposes to replace section 5.5 of ripe-592, currently: "Any LIR is allowed to re-allocate complete or partial blocks of IPv4 address space that were previously allocated to them by either the RIPE NCC or the IANA." with "Any LIR is allowed to re-allocate complete or partial blocks of IPv4 address space that were previously allocated to them by the RIPE NCC or otherwise through the Regional Internet Registry System." This change is proposed to ensure that RIPE Policy Proposal 2012-07 is in alignment with ripe-592. If RIPE Policy Proposal 2012-07 is accepted by the RIPE community, it would result in a new policy for legacy Internet resources and a small change to the the existing RIPE Policy ripe-592. As an existing policy would be impacted by this policy proposal, we would like to notify the Address Policy Working Group. You can find the full policy proposal at: https://www.ripe.net/ripe/policies/proposals/2012-07 If you wish to participate on the discussion, then we encourage you to review this proposal and send your comments to by 8 November 2013. Regards, Marco Schmidt Policy Development Office RIPE NCC From andrea at ripe.net Thu Oct 10 16:29:26 2013 From: andrea at ripe.net (Andrea Cima) Date: Thu, 10 Oct 2013 16:29:26 +0200 Subject: [address-policy-wg] New Policy Proposal (PI - PA Transfer) In-Reply-To: <52568D8E.7080005@fud.no> References: <525496A1.9000209@netassist.ua> <5256881F.5000208@ripe.net> <52568D8E.7080005@fud.no> Message-ID: <5256B9C6.6010100@ripe.net> Hi Tore, On 10/10/13 1:20 PM, Tore Anderson wrote: > Hi Andrea and thanks for the update! > >> This would allow for PA allocations smaller than the minimum >> allocation size. It is our understanding that this last point would >> require a policy change. > Out of curiousity, how did these come about then? These are 'historical' allocations, issued a long time ago. Please find the details below. > ripencc|SE|ipv4|193.108.42.0|512|20010406|allocated This block was issued according to ripe-211. At that time, users requesting an allocation smaller than the default allocation size were issued an allocation from the blocks reserved for PI assignments. > ripencc|DE|ipv4|193.218.220.0|512|19981110|allocated The actual entry in the RIPE Database is 193.218.208.0 - 193.218.221.255. > ripencc|PT|ipv4|194.117.48.0|512|19941206|allocated The actual entry in the RIPE Database is 194.117.0.0 - 194.117.49.255. > ripencc|IT|ipv4|194.153.212.0|512|20000509|allocated The actual entry in the RIPE Database is 194.153.192.0 - 194.153.213.255. The delegated stats show allocations only on bit boundaries, resulting in multiple entries for allocated PA ranges that are not on bit boundaries. For example, 194.153.192.0 - 194.153.213.255 would be aggregatable on the following bit boundaries: 194.153.192.0/20 194.153.192.0 - 194.153.207.255 [4096] 194.153.208.0/22 194.153.208.0 - 194.153.211.255 [1024] 194.153.212.0/23 194.153.212.0 - 194.153.213.255 [512] This results in having the IP range 194.153.192.0 - 194.153.213.255 as three separate entries in the delegated stats file. We can look into changing the format output of the delegated stats file if this is considered to be a problem. > > FWIW, I've always considered the minimum allocation size the minimum > size *that the RIPE NCC may allocate* - not the minimum allocation size > that may exist in the database at a given point in time. The Registration Services Department has always been clear that we interpret the policy as "the minimum size of allocated PA address space". This is true both when the address space is issued as well as after it has been issued. That this is the intended spirit of the policy can also be found in section 5.5 of ripe-592, according to which allocations cannot be broken into IP blocks smaller than the minimum allocation size for transfers: "The block that is to be re-allocated must not be smaller than the minimum allocation block size at the time of re-allocation". You can find the relevant section here: http://www.ripe.net/ripe/docs/ripe-592#Transfers-of-Allocations > The existence > of the above four allocations appears to preclude the latter > interpretation in any case. > > With the former interpretation PI->PA conversions for blocks smaller > than the minimum allocation size is quite OK by policy, as it isn't an > allocation performed by the RIPE NCC from the free pool. Besides, I > can't think of any reason for having a minimum allocation size in the > first place except to prevent deaggregation, but these as those PI > blocks are already deaggregated that's not applicable here either. Please understand that I am not disputing your reasoning or opinion. We base our procedures on policy text that is set by the RIPE community. If the RIPE community believes that a policy is no longer relevant and changes this through the PDP, the RIPE NCC will change its procedures accordingly. Best regards, Andrea Cima RIPE NCC > IMHO, anyway... > > Tore > From andrea at ripe.net Thu Oct 10 16:57:29 2013 From: andrea at ripe.net (Andrea Cima) Date: Thu, 10 Oct 2013 16:57:29 +0200 Subject: [address-policy-wg] New Policy Proposal (PI - PA Transfer) In-Reply-To: <52569F66.1090100@inex.ie> References: <525496A1.9000209@netassist.ua> <5256881F.5000208@ripe.net> <52569F66.1090100@inex.ie> Message-ID: <5256C059.8090606@ripe.net> Hi Nick, On 10/10/13 2:36 PM, Nick Hilliard wrote: > On 10/10/2013 11:57, Andrea Cima wrote: >> 1) Allow LIRs to change the status of their PI assignments into PA >> allocations (if equal or larger than the minimum allocation size) >> 2) Do not allow LIRs to change the status of their PI assignments into PA allocations > Andrea, > > On May 7 2009, Alex le Heux posted a breakdown of IPv4 PI assignment > statistics: > >> http://www.ripe.net/ripe/mail/archives/address-policy-wg/2009-May/004212.html > This indicated at at the time, only ~20% of all ipv4 PI assignments were > /22 or larger. > > The two choices presented here mean that the 80% of people with PI > assignments of /23 or less would be disenfranchised by this policy > regardless of which way it might go. I would like to clarify that, by definition, IP address space with the status "ALLOCATED PA" can only be allocated to an LIR. Around 2,800 PI blocks have been assigned to organisations that later became LIRs. Approximately 1,000 of these PI assignments are equal to, or larger than, a /22. Approximately 1,800 of these PI assignments are smaller than a /22. > Also it's not compatible with the > efforts under way to unify pi/pa ipv6. > > I.e. I don't think that either of these options is necessarily a good idea. We presented these two options at RIPE 66 based on feedback we had received from LIRs in our day-to-day work. After becoming LIRs, many of these organisations were asking us to change the status of their PI assignments. If the community feels there are different or better options than the ones we have suggested, we hope that these can be brought forward and discussed. Best regards, Andrea Cima RIPE NCC > Nick > > From dmitriy at deltahost.com.ua Thu Oct 10 17:20:20 2013 From: dmitriy at deltahost.com.ua (Dmitriy Zemlyanoy) Date: Thu, 10 Oct 2013 18:20:20 +0300 Subject: [address-policy-wg] New Policy Proposal (PI - PA Transfer) Message-ID: <71577xfatu1bh7i6vjllsysb.1381418420918@email.android.com> We also support PI to PA changing. ???????????? Andrea Cima ?????: > >Dear colleagues, Following the increasing number of requests from LIRs that want to convert their PI assignments into PA allocations, we proposed the following options at RIPE 66: 1) Allow LIRs to change the status of their PI assignments into PA allocations (if equal or larger than the minimum allocation size) 2) Do not allow LIRs to change the status of their PI assignments into PA allocations After RIPE 66, the discussion was continued on the Address Policy Working Group Mailing List. There seemed to be a lot of support for allowing LIRs to change the status of their resources, but people also wanted the minimum allocation size to be disregarded. This would allow for PA allocations smaller than the minimum allocation size. It is our understanding that this last point would require a policy change. We will be addressing this as part of our "Feedback From RIPE NCC Registration Services" presentation at RIPE 67. Based on the feedback we receive from here, we will work with the Working Group Chairs on a way forward. Kind regards, Andrea Cima RIPE NCC >On 10/9/13 1:34 AM, ksyu at netassist.ua wrote: > >Hello everybody > >I would like to draw attention of the public to the next moment . >According to the RIPE policy, a PI network should be used only as it was assigned. However, the time comes, the amount of clients increases, the number of services is growing up, and v4 addresses are not assigned any more. >What should provider do in this case? The network was assigned for the particular service and can't be used for other services? Just returned back . But no one in their right mind will do this ) . >It may be a topical solution for this situation - to return the opportunity to transfer PI blocks into the PA? >This will give the opportunity to breathe more freely, not to violate the rules of RIPE policy . >I suggest to discuse the question of transference of PI blocks to PA, and invite all caring to speak on the matter. > > > Best regards, Kseniya Sokol > -------------- next part -------------- An HTML attachment was scrubbed... URL: From malcolm at linx.net Mon Oct 14 13:18:46 2013 From: malcolm at linx.net (Malcolm Hutty) Date: Mon, 14 Oct 2013 12:18:46 +0100 Subject: [address-policy-wg] 2013-03: Good enough? In-Reply-To: <52416B2E.7020602@fud.no> References: <201309191448.r8JEm4oR009019@danton.fire-world.de> <20130923113236.GB20757@danton.fire-world.de> <52406426.8080405@linx.net> <52416B2E.7020602@fud.no> Message-ID: <525BD316.7000409@linx.net> On 24/09/2013 11:36, Tore Anderson wrote: >> 3. The accompanying notes, which are not part of the proposal itself but >> which are a part of the external messaging, should be re-written. >> The current version of these notes unhelpfully emphasises the removal of >> the requirement to demonstrate need, as if need were becoming >> irrelevant. They should describe the effect of 2013-03, which is to >> remove the *upfront documentation* of need (a form of ex ante >> regulation), while retaining the concept of fairness, as defined by the >> community, as a goal of allocation policy. It should be emphasised that >> the community retains the right to introduce new policies in the future, >> if deemed necessary, to ensure that this deregulatory initiative does >> not bring about unfairness. > > Same condition as for #1, as long as it doesn't require another IA, I > have problem with this. I've just had a quick word with Ingrid to ask whether this could be done without restarting the Phase. She said she'd want to see the changes and to consult the Chairs before giving a definitive view, but in principle it sounded reasonable. [...] > In any case, I'd need your help with this. You clearly have a pretty > good idea of what parts of the notes stand out as "offensive", and what > messages are missing. Are you coming to Athens? If so, maybe we could > book a meeting room and sit down with the Chairs, someone from the > External Relations team, and any other WG members who might be > interested in participating here - collaborate on an improved text right > there on the projector, and have a version 4 that could be published > when going into the final PDP phase. Great, let's do that. I'm in Athens. I've made a first stab at producing some text to act as a starting point. -- Malcolm Hutty | tel: +44 20 7645 3523 Head of Public Affairs | Read the LINX Public Affairs blog London Internet Exchange | http://publicaffairs.linx.net/ London Internet Exchange Ltd 21-27 St Thomas Street, London SE1 9RY Company Registered in England No. 3137929 Trinity Court, Trinity Street, Peterborough PE1 1DA From tore at fud.no Mon Oct 14 17:57:35 2013 From: tore at fud.no (Tore Anderson) Date: Mon, 14 Oct 2013 17:57:35 +0200 Subject: [address-policy-wg] 2013-06 New Policy Proposal (PA/PI Unification IPv6 Address Space) In-Reply-To: References: Message-ID: <525C146F.8000902@fud.no> So I spent my time in the air en route to Athens today reading through 2013-06 again, and have some more comments - one significant, the rest editorial. Significant first. Section 5.3.1: says ?When more than a /48 is to be sub-allocated to the same customer, the LIR or the End User (via the Sponsoring LIR) must request an approval from the RIPE NCC.? Before, NCC approval was only mandatory for assignments shorter than a /48 per *End Site*. So if I'm reading the proposed policy correct, a customer that has >1 sites would need NCC approval if he wanted a /48 for each of them. I don't think we should do that. Editorial improvements (please keep in mind though that I'm not a native English speaker so my ?gut feeling? about these may well be completely wrong and should be ignored): Section 5.6.2: ?These assignments have been transformed automatically by the RIPE NCC in IPv6 allocations.? - "transformed" -> "converted" - "in" -> "to" Section 5.6.2: ?End Users holding an allocation lower than a /32? - "an allocation" -> "allocations" - "lower" -> "smaller" Tore From achatz at forthnetgroup.gr Wed Oct 16 08:50:04 2013 From: achatz at forthnetgroup.gr (Tassos Chatzithomaoglou) Date: Wed, 16 Oct 2013 09:50:04 +0300 Subject: [address-policy-wg] 16-bit ASNs Message-ID: <525E371C.9060701@forthnetgroup.gr> Regarding the return of 16-bit ASNs to RIPE, do you think it would be possible to make it in an automated way? i.e. create a web page where ASN owners can declare their willingness to keep or return the ASN they own; then contact just the returners. Assuming a good percentage of owners gives an answer (whether positive or negative), then it'll be made more clear how many of these unknown-state 16-bit ASNs is actually unknown. I don't know if there is any estimation from previous communication, if there is actually any success on giving back ASNs. -- Tassos From ebais at a2b-internet.com Wed Oct 16 09:22:13 2013 From: ebais at a2b-internet.com (Erik Bais) Date: Wed, 16 Oct 2013 09:22:13 +0200 Subject: [address-policy-wg] [policy-announce] 2013-05 New Draft Document and Impact Analysis Published (No Restrictions on End User Assignments in Intra-RIR Transfers) In-Reply-To: <20130930132458.669A6ED46E5@klant.eznet.nl> References: <20130930132458.669A6ED46E5@klant.eznet.nl> Message-ID: <00a301ceca40$6fa1de80$4ee59b80$@a2b-internet.com> > https://www.ripe.net/ripe/policies/proposals/2013-05 +1 on the proposal. Erik Bais A2B Internet B.V. From nominations at ripe.net Thu Oct 17 13:13:43 2013 From: nominations at ripe.net (Axel Pawlik) Date: Thu, 17 Oct 2013 13:13:43 +0200 Subject: [address-policy-wg] Election for Seat on the NRO Number Council (NRO NC) Message-ID: <525FC667.3090308@ripe.net> Dear colleagues, Tomorrow, 18 October, an election will take place to fill one seat for the RIPE NCC service region on the Number Resource Organization Number Council (NRO NC). The winning candidate will begin a three-year term on the NRO NC from 1 January 2014. Voting is open to anyone in attendance at the RIPE 67 Meeting in Athens and it will take place from 08:45 ? 10:45 on Friday morning. There will be a voting station at the Meet and Greet desk, just outside Ballroom II + III. All attendees will be offered a voting slip and should give their completed voting slip to the election officer at the voting station. The three candidates standing for election are: - Alain Bidron - Sander Steffann - Filiz Yilmaz The candidates? biographies are available at: http://www.ripe.net/internet-coordination/internet-governance/internet-technical-community/nro/nro-nc/nominations-2013/confirmed-nominees Candidates will also make a brief statement in support of their candidacy at the NRO/RIR Reports session, which take place on Friday from 09:00 ? 10:30 (UTC +3). Kind regards, Axel Pawlik Managing Director RIPE NCC From dmitriy at deltahost.com.ua Mon Oct 21 13:42:22 2013 From: dmitriy at deltahost.com.ua (Dmitriy Zemlyanoy) Date: Mon, 21 Oct 2013 14:42:22 +0300 Subject: [address-policy-wg] New Policy Proposal (PI - PA Transfer) Message-ID: <4365f8f99e40b104ad3eeb440591ffb6@deltahost.com.ua> RIPE 67 is ended. Just wondering if you have any updates? > We will be addressing this as part of our "Feedback From RIPE NCC Registration Services" > presentation at RIPE 67. Based on the feedback we receive from here, we will work with > the Working Group Chairs on a way forward. > Kind regards, > Andrea Cima > RIPE NCC -------------- next part -------------- An HTML attachment was scrubbed... URL: From rogerj at gmail.com Mon Oct 21 14:05:14 2013 From: rogerj at gmail.com (=?ISO-8859-1?Q?Roger_J=F8rgensen?=) Date: Mon, 21 Oct 2013 14:05:14 +0200 Subject: [address-policy-wg] New Policy Proposal (PI - PA Transfer) In-Reply-To: <4365f8f99e40b104ad3eeb440591ffb6@deltahost.com.ua> References: <4365f8f99e40b104ad3eeb440591ffb6@deltahost.com.ua> Message-ID: Think I'll just "hijack" this discussion ;p I fully support the idea of uniting PI and PA into one policy, it's just numbers anyway. However, the presentation on the topic from the three (just two onsite) volunteers was very interesting, the consequences and how much it affected was amazing. How did we dig us into such a mess? With that background I don't think we can continue forward on the started track, the impact everywhere and amount of work are too big. I think we should take two step back and cleanup the mess inside the PI "domain", try to clean and polish it, link it toward reality, all the things that are connected and linked. Not so much about changing alot, just clean it up. Or we can fix what's obvious broken along the way of course. We should also do the same on the PA side, but probably not that much there to clean up. And this should be done both for v4 and v6 before we again in a year or two try to unite it into one great policy. anyhow, as long as we don't drag this mess over into v6 the future isn't all that bad:-) just my 0,02 NOK :-) --- Roger J --- On Mon, Oct 21, 2013 at 1:42 PM, Dmitriy Zemlyanoy wrote: > RIPE 67 is ended. > Just wondering if you have any updates? > > > >> We will be addressing this as part of our "Feedback From RIPE NCC >> Registration Services" >> presentation at RIPE 67. Based on the feedback we receive from here, we >> will work with >> the Working Group Chairs on a way forward. >> Kind regards, >> Andrea Cima >> RIPE NCC -- Roger Jorgensen | ROJO9-RIPE rogerj at gmail.com | - IPv6 is The Key! http://www.jorgensen.no | roger at jorgensen.no From gert at space.net Mon Oct 21 14:08:45 2013 From: gert at space.net (Gert Doering) Date: Mon, 21 Oct 2013 14:08:45 +0200 Subject: [address-policy-wg] New Policy Proposal (PI - PA Transfer) In-Reply-To: References: <4365f8f99e40b104ad3eeb440591ffb6@deltahost.com.ua> Message-ID: <20131021120845.GB65295@Space.Net> Hi, On Mon, Oct 21, 2013 at 02:05:14PM +0200, Roger J?rgensen wrote: > Think I'll just "hijack" this discussion ;p > > I fully support the idea of uniting PI and PA into one policy, it's > just numbers anyway. Uh, you're confusing two issues. *This* thread was about being able to turn IPv*4* PI into PA, while keeping the distinction. Andrea Cima presented at the RIPE meeting, and I expect to see a summary and "next steps" from him soon - especially for the bits that are missing policywise, and Erik Bais volunteered to work with us to fix those. > However, the presentation on the topic from the three (just two > onsite) volunteers was very interesting, the consequences and how much > it affected was amazing. How did we dig us into such a mess? *That* is actually about IPv6 land (PA/PI unification, only having a single "type of addresses" anymore), and I'll open a separate thread on that "soonish". Gert Doering -- APWG chair -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 306 bytes Desc: not available URL: From rogerj at gmail.com Mon Oct 21 14:14:28 2013 From: rogerj at gmail.com (=?ISO-8859-1?Q?Roger_J=F8rgensen?=) Date: Mon, 21 Oct 2013 14:14:28 +0200 Subject: [address-policy-wg] New Policy Proposal (PI - PA Transfer) In-Reply-To: <20131021120845.GB65295@Space.Net> References: <4365f8f99e40b104ad3eeb440591ffb6@deltahost.com.ua> <20131021120845.GB65295@Space.Net> Message-ID: On Mon, Oct 21, 2013 at 2:08 PM, Gert Doering wrote: > Hi, > > On Mon, Oct 21, 2013 at 02:05:14PM +0200, Roger J?rgensen wrote: >> Think I'll just "hijack" this discussion ;p >> >> I fully support the idea of uniting PI and PA into one policy, it's >> just numbers anyway. > > Uh, you're confusing two issues. *This* thread was about being able > to turn IPv*4* PI into PA, while keeping the distinction. > > Andrea Cima presented at the RIPE meeting, and I expect to see a summary > and "next steps" from him soon - especially for the bits that are missing > policywise, and Erik Bais volunteered to work with us to fix those. oh, see that now, sorry. >> However, the presentation on the topic from the three (just two >> onsite) volunteers was very interesting, the consequences and how much >> it affected was amazing. How did we dig us into such a mess? > > *That* is actually about IPv6 land (PA/PI unification, only having a > single "type of addresses" anymore), and I'll open a separate thread on > that "soonish". 'ki, we're waiting:-) -- Roger Jorgensen | ROJO9-RIPE rogerj at gmail.com | - IPv6 is The Key! http://www.jorgensen.no | roger at jorgensen.no From gert at space.net Mon Oct 21 14:35:23 2013 From: gert at space.net (Gert Doering) Date: Mon, 21 Oct 2013 14:35:23 +0200 Subject: [address-policy-wg] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Cleanup) Message-ID: <20131021123523.GC65295@Space.Net> Dear AP WG, On Thu, Sep 19, 2013 at 04:44:38PM +0200, Marco Schmidt wrote: > Following the feedback received, the draft documents for the proposal > described in 2013-03 (No Need - Post-Depletion Reality Adjustment and Cleanup) > are edited and published. [..] > We encourage you to read the draft document text and send any comments > to address-policy-wg at ripe.net before 18 October 2013. The review phase for 2013-03 ended last Friday, as announced by Marco. We have seen very strong support from the community, and some opposition. Without going into a full summary of who said what, this is one of the proposals that received most support of all that ever went into PDP, so even with the opposing voices left, we'd normally go on to declare (rough) consensus here and move to Last Call. Unfortunately, there is a bit more to this proposal than the pure textual changes to the policy text. It has been brought to the WG chairs' attention that the way the "outside world" looks at our policy processes and whether our self-regulation works or not is also influenced by the title of the policy proposal ("no need - ...") and the supporting notes, which are not signalling clearly enough that the RIPE community still wants fair distribution of addresses, as far as this can be achieved after runout, and is not going for a full open market. To avoid unneccessary troubles due to interpretation of text that is not part of the "core proposal", the proposer (Tore Anderson) has agreed to work together with Malcolm Hutty in rewriting the supporting text, and drop the "no need" string from the title. The policy text itself, that you expressed your support for, will remain unchanged(!). When that is done, the proposal will undergo another - hopefully short - impact analysis by the RIPE NCC, and come back to a new review phase here on the AP list. (I stated this as our intention at last week's APWG meeting already, but here's the formal statement from the chair on the list :-) ) Gert Doering -- APWG chair -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 306 bytes Desc: not available URL: From gert at space.net Mon Oct 21 14:54:51 2013 From: gert at space.net (Gert Doering) Date: Mon, 21 Oct 2013 14:54:51 +0200 Subject: [address-policy-wg] 16-bit ASNs In-Reply-To: <525E371C.9060701@forthnetgroup.gr> References: <525E371C.9060701@forthnetgroup.gr> Message-ID: <20131021125451.GC50205@Space.Net> Hi, On Wed, Oct 16, 2013 at 09:50:04AM +0300, Tassos Chatzithomaoglou wrote: > Regarding the return of 16-bit ASNs to RIPE, do you think it would be > possible to make it in an automated way? > i.e. create a web page where ASN owners can declare their willingness to > keep or return the ASN they own; then contact just the returners. If an ASN holder is actively willing to return an AS number, there is nothing stopping them from sending a mail to hostmaster at ripe.net and telling the IPRAs about it... that's about all it takes (plus cleanup of references). I can't see the benefit of having a web page where you could enter that you might be willing to return your AS number if asked (in which case, it is to be expected that the NCC would ask). Gert Doering -- APWG chair -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 826 bytes Desc: not available URL: From gert at space.net Mon Oct 21 20:40:30 2013 From: gert at space.net (Gert Doering) Date: Mon, 21 Oct 2013 20:40:30 +0200 Subject: [address-policy-wg] New Policy Proposal (PI - PA Transfer) In-Reply-To: <20131021120845.GB65295@Space.Net> References: <4365f8f99e40b104ad3eeb440591ffb6@deltahost.com.ua> <20131021120845.GB65295@Space.Net> Message-ID: <20131021184030.GA93776@Space.Net> Hi, small clarification... On Mon, Oct 21, 2013 at 02:08:45PM +0200, Gert Doering wrote: > On Mon, Oct 21, 2013 at 02:05:14PM +0200, Roger J?rgensen wrote: > > Think I'll just "hijack" this discussion ;p > > > > I fully support the idea of uniting PI and PA into one policy, it's > > just numbers anyway. > > Uh, you're confusing two issues. *This* thread was about being able > to turn IPv*4* PI into PA, while keeping the distinction. > > Andrea Cima presented at the RIPE meeting, and I expect to see a summary > and "next steps" from him soon - especially for the bits that are missing > policywise, and Erik Bais volunteered to work with us to fix those. This is where *I* was confused about things - Erik Bais volunteered, but not to fix this particular bit about IPv4 PI, but to work out something about IPv4 PI transfers. Sorted out by private mail in the meantime. But I think we have found another volunteer for the minimum allocation size obstacle regarding IPv4 PA->PI conversion. Also related to IPv4 PI, but differently... (And I can already hear Randy Bush tell me that our way of thinking is too complicated... maybe it is, but we're such orderly folks here... we can do this all by policy, without lawyers :-) ) Gert Doering -- APWG chair -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 826 bytes Desc: not available URL: From ripe-wgs.cs at schiefner.de Mon Oct 21 21:35:17 2013 From: ripe-wgs.cs at schiefner.de (Carsten Schiefner) Date: Mon, 21 Oct 2013 21:35:17 +0200 Subject: [address-policy-wg] New Policy Proposal (PI - PA Transfer) In-Reply-To: <20131021184030.GA93776@Space.Net> References: <4365f8f99e40b104ad3eeb440591ffb6@deltahost.com.ua> <20131021120845.GB65295@Space.Net> <20131021184030.GA93776@Space.Net> Message-ID: <526581F5.3000305@schiefner.de> Gert, you still seem to be a bit stressed out - no relaxing weekend?! ;-) On 21.10.2013 20:40, Gert Doering wrote: > But I think we have found another volunteer for the minimum allocation > size obstacle regarding IPv4 PA->PI conversion. Also related to IPv4 PI, > but differently... This should read "regarding IPv4 PI->PA conversion" - as it concerns converting "ASSINGED PI" IPv4 space of LIRs into "ALLOCATED PA" space for the respective LIR. The (main) question here is: what to do with PI space that is smaller than the minimum allocation size. Cheers, -C. From gert at space.net Mon Oct 21 21:49:46 2013 From: gert at space.net (Gert Doering) Date: Mon, 21 Oct 2013 21:49:46 +0200 Subject: [address-policy-wg] New Policy Proposal (PI - PA Transfer) In-Reply-To: <526581F5.3000305@schiefner.de> References: <4365f8f99e40b104ad3eeb440591ffb6@deltahost.com.ua> <20131021120845.GB65295@Space.Net> <20131021184030.GA93776@Space.Net> <526581F5.3000305@schiefner.de> Message-ID: <20131021194946.GL50205@Space.Net> Hi, On Mon, Oct 21, 2013 at 09:35:17PM +0200, Carsten Schiefner wrote: > you still seem to be a bit stressed out - no relaxing weekend?! ;-) Not that much... conflicting appointments on the weekend right after the RIPE meeting... I thought I had enough sleep, but seems not. > On 21.10.2013 20:40, Gert Doering wrote: > > But I think we have found another volunteer for the minimum allocation > > size obstacle regarding IPv4 PA->PI conversion. Also related to IPv4 PI, > > but differently... > > This should read "regarding IPv4 PI->PA conversion" - as it concerns > converting "ASSINGED PI" IPv4 space of LIRs into "ALLOCATED PA" space > for the respective LIR. Yeah, of course. Sorry. > The (main) question here is: what to do with PI space that is smaller > than the minimum allocation size. "Just permitting the conversion" ("in one piece, not to be fragmented further") would be one option :-) - no extra routing table impact, no extra address space consumption, and possibly improved documentation. But that's not for me to decide, it's for you to propose and for the WG to decide :-) (but it matches what I read here). Gert Doering -- APWG chair -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 826 bytes Desc: not available URL: From gert at space.net Fri Oct 25 20:03:41 2013 From: gert at space.net (Gert Doering) Date: Fri, 25 Oct 2013 20:03:41 +0200 Subject: [address-policy-wg] 2013-06 New Policy Proposal (PA/PI Unification IPv6 Address Space) In-Reply-To: <1380206290.2739@mobil.space.net> References: <1380206290.2739@mobil.space.net> Message-ID: <20131025180341.GA75737@Space.Net> Dear Address Policy WG, On Thu, Sep 26, 2013 at 04:36:24PM +0200, Marco Schmidt wrote: > A proposed change to RIPE Documents ripe-589, "IPv6 Address > Allocation and Assignment Policy", ripe-451, "IPv6 Address > Space Policy For Internet Exchange Points" and ripe-233, > "IPv6 Addresses for Internet Root Servers In The RIPE Region" > is now available for discussion. [..] > We encourage you to review this proposal and send your comments to > before 25 October 2013. The discussion phase for this proposal is now over, but after the feedback received at the RIPE meeting in Athens (and here on the list, even if in the wrong thread :) ) the chairs have deviced to take a step back, and re-state the fundamental "do we want to go there?" question (and extend the discussion phase by +4 weeks). The proposal aims to unify IPv6 PA and IPv6 PI space into one kind of address space, "IPv6 addresses". This is the goal. The idea to go there came from various people in the community, mostly for one reason - having two differently "coloured" addresses that do the same thing, routingwise, but follow different policies and have different strings attached, creates quite some confusion for the folks out there that can no longer be nicely separated into "ISPs" (->become RIPE members, use PA) and "end-users" (->use PI, if BGP-based multihoming and/or upstream independence is required). Most notably, "garage style hosting providers" seem to have issues with the requirement of the IPv6 PI policy that PI space MUST NOT be sub-assigned, which the NCC interprets most strictly (because the vast amount of "grey" between "ok" and "not ok" is hard to codify into hostmaster guidelines). OTOH, I have not heard that complaint from actual hosting providers for a while, so maybe the issue is not that big anymore. *If* we go to "there is only one type of addresses" anymore, we have two options - abandon IPv6 PI (as in "not so expensive, but independent space") completely, problem solved -> I do not think we can reasonably do that - find a way to solve the needs for both RIPE members and non-members, with maximum flexibility, with only one type of addresses, taking "real world" address distribution chains (LIR->network operator-> hosting provider->customer->hosted virtual machines, for example) and "real world" financial constraints into account. 2013-06 aims to achieve the latter, while proposing / finding specific solutions for all the small details that come up if such a radical change is implemented. I think the presentation at RIPE67 was a bit too fast for the WG - it could have spent a bit more time on the background and "do we want to go there" before overwhelming you with questions about details to be solved. For that, I apologize - I did review the presentation beforehand with the proposers, and assumed "yes, this should work out nicely"... Anyway. I think what we need to hear now from the community (*you*) is where we want to go: - do nothing, our policy for IPv6 PA and IPv6 PI "as of today" is fine - keep the distinction, work on the IPv6 PI policy (if the pain is large enough that someone actually volunteers to come with a proposal) - go the big step, unify IPv6 PA and IPv6 PI, and solve all the detail problems that need to be addressed if we go there. Going for one of the first options would mean abandoning 2013-06 - but if that's what the community wants, it's much better to do it *now* than to invest more time in text, impact analysis, a few rounds of review phase, and *then* give up the project. Gert Doering -- APWG chair -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 826 bytes Desc: not available URL: From frettled at gmail.com Fri Oct 25 21:20:40 2013 From: frettled at gmail.com (Jan Ingvoldstad) Date: Fri, 25 Oct 2013 21:20:40 +0200 Subject: [address-policy-wg] 2013-06 New Policy Proposal (PA/PI Unification IPv6 Address Space) In-Reply-To: <20131025180341.GA75737@Space.Net> References: <1380206290.2739@mobil.space.net> <20131025180341.GA75737@Space.Net> Message-ID: On Fri, Oct 25, 2013 at 8:03 PM, Gert Doering wrote: > Dear Address Policy WG, > > On Thu, Sep 26, 2013 at 04:36:24PM +0200, Marco Schmidt wrote: > > A proposed change to RIPE Documents ripe-589, "IPv6 Address > > Allocation and Assignment Policy", ripe-451, "IPv6 Address > > Space Policy For Internet Exchange Points" and ripe-233, > > "IPv6 Addresses for Internet Root Servers In The RIPE Region" > > is now available for discussion. > [..] > > We encourage you to review this proposal and send your comments to > > before 25 October 2013. > > The discussion phase for this proposal is now over, but after the > feedback received at the RIPE meeting in Athens (and here on the list, > even if in the wrong thread :) ) the chairs have deviced to take a step > back, and re-state the fundamental "do we want to go there?" question > (and extend the discussion phase by +4 weeks). > > The proposal aims to unify IPv6 PA and IPv6 PI space into one kind of > address space, "IPv6 addresses". This is the goal. > > The idea to go there came from various people in the community, mostly > for one reason - having two differently "coloured" addresses that do > the same thing, routingwise, but follow different policies and have > different strings attached, creates quite some confusion for the folks > out there that can no longer be nicely separated into "ISPs" (->become > RIPE members, use PA) and "end-users" (->use PI, if BGP-based multihoming > and/or upstream independence is required). > In my opinion, this distinction is not particularly useful in itself, and could very well be a floating definition. Coming from the DNS registrar side, I cannot help thinking that looking at the registry/registrar model might be beneficial for making things clearer for people out there. One way of seeing this, is that the LIRs are "registrars" for IP address space, and that their role could simply be about registering and brokering assignments and allocations for the RIR. An ISP or an "end user" then becomes an unnecessary distinction, as they would both have to go to a LIR to get their address space, and it's just a matter of placing a request for the correct size, at the discretion of the applicant and the LIR. Mind you, I think this is mostly about perspective, but if we could use the similarities with DNS registrations, then end customers (ISPs or whatever) might have less confusion. I could very well be wrong. > > Most notably, "garage style hosting providers" seem to have issues > with the requirement of the IPv6 PI policy that PI space MUST NOT be > sub-assigned, which the NCC interprets most strictly (because the vast > amount of "grey" between "ok" and "not ok" is hard to codify into > hostmaster guidelines). OTOH, I have not heard that complaint from > actual hosting providers for a while, so maybe the issue is not that > big anymore. > >From what I've seen ? and this is anecdata ? this is "solved" by subletting the address space without leaving other traces of it than a PTR record, if that. *If* we go to "there is only one type of addresses" anymore, we have two > options > > - abandon IPv6 PI (as in "not so expensive, but independent space") > completely, problem solved -> I do not think we can reasonably do that > > - find a way to solve the needs for both RIPE members and non-members, > with maximum flexibility, with only one type of addresses, taking > "real world" address distribution chains (LIR->network operator-> > hosting provider->customer->hosted virtual machines, for example) > and "real world" financial constraints into account. > 2013-06 aims to achieve the latter, while proposing / finding specific > solutions for all the small details that come up if such a radical change > is implemented. > I think the latter is how it should be done, and I think it would be easier to explain. > > > I think the presentation at RIPE67 was a bit too fast for the WG - it > could have spent a bit more time on the background and "do we want to > go there" before overwhelming you with questions about details to be > solved. For that, I apologize - I did review the presentation beforehand > with the proposers, and assumed "yes, this should work out nicely"... > > > Anyway. I think what we need to hear now from the community (*you*) is > where we want to go: > > - do nothing, our policy for IPv6 PA and IPv6 PI "as of today" is fine > > - keep the distinction, work on the IPv6 PI policy (if the pain is > large enough that someone actually volunteers to come with a proposal) > > - go the big step, unify IPv6 PA and IPv6 PI, and solve all the detail > problems that need to be addressed if we go there. > > > Going for one of the first options would mean abandoning 2013-06 - but > if that's what the community wants, it's much better to do it *now* than > to invest more time in text, impact analysis, a few rounds of review > phase, and *then* give up the project. > I think going the big step is where we need to go. But it's a nice extra workload. Keeping the current policy is less work, and I don't think it will hurt much of anything. But right now, I think the ideal should be the third option, especially considering that this will seem to be much harder to change at a later point in time. > > Gert Doering > -- APWG chair > -- > have you enabled IPv6 on something today...? > > (Yes!) -- Jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From ebais at a2b-internet.com Sat Oct 26 18:33:54 2013 From: ebais at a2b-internet.com (Erik Bais) Date: Sat, 26 Oct 2013 18:33:54 +0200 Subject: [address-policy-wg] 2013-06 New Policy Proposal (PA/PI Unification IPv6 Address Space) In-Reply-To: <20131025180341.GA75737@Space.Net> References: <1380206290.2739@mobil.space.net> <20131025180341.GA75737@Space.Net> Message-ID: <00bf01ced269$29a6a830$7cf3f890$@a2b-internet.com> Hi Gert, Thanks for the email and the discussion in Athens and let me start by saying thanks to the authors of the amount of effort and work they have put into this. > Anyway. I think what we need to hear now from the community (*you*) is > where we want to go: Having heard the discussion in Athens and seen the presentation, I personally think that we should abandon 2013-06. Having garage-style 'hosters' do assignments, just because they can while using PI IPv6 space, is against the policy, however removing that distinction between PI and PA for v6 and allowing sub-assignments from PI space will basically open the door in the near future for cheap resources, without being an LIR. That will have an impact on the number of members the NCC will have once we are beyond the v4 era ... And less members will result in a high fee per member. > - do nothing, our policy for IPv6 PA and IPv6 PI "as of today" is fine Having said that, maybe the currently policy isn't perfect, but it is better than the alternative imho. Not every End-User can legally become an LIR and they would still require the ability to be independent from their upstream provider. > - keep the distinction, work on the IPv6 PI policy (if the pain is > large enough that someone actually volunteers to come with a proposal) Been there, done that... Let's implement v6 first. The current policy provides options for people on what to do and how to get what you require. If the policy is limiting v6 deployments, we can always revisit a specific option again imho. The current policy allows a End-User to receive their own /48 (minimal assignment) or larger with demonstrated documentation and need. The limitation is that they are not allowed to sub-assign to other organizations. > - go the big step, unify IPv6 PA and IPv6 PI, and solve all the detail problems that need to be addressed if we go there. I would strongly not go there to remove the PI limitation of sub-assignments to others and increasing the assigned (or newly proposed allocate) size to a /32 or /29 similar as one would get by signing up for a LIR membership. Regards, Erik Bais From rogerj at gmail.com Sun Oct 27 15:37:49 2013 From: rogerj at gmail.com (=?ISO-8859-1?Q?Roger_J=F8rgensen?=) Date: Sun, 27 Oct 2013 15:37:49 +0100 Subject: [address-policy-wg] 2013-06 New Policy Proposal (PA/PI Unification IPv6 Address Space) In-Reply-To: <20131025180341.GA75737@Space.Net> References: <1380206290.2739@mobil.space.net> <20131025180341.GA75737@Space.Net> Message-ID: On Fri, Oct 25, 2013 at 8:03 PM, Gert Doering wrote: > Dear Address Policy WG, > > On Thu, Sep 26, 2013 at 04:36:24PM +0200, Marco Schmidt wrote: >> A proposed change to RIPE Documents ripe-589, "IPv6 Address >> Allocation and Assignment Policy", ripe-451, "IPv6 Address >> Space Policy For Internet Exchange Points" and ripe-233, >> "IPv6 Addresses for Internet Root Servers In The RIPE Region" >> is now available for discussion. > [..] >> We encourage you to review this proposal and send your comments to >> before 25 October 2013. > > The discussion phase for this proposal is now over, but after the > feedback received at the RIPE meeting in Athens (and here on the list, > even if in the wrong thread :) ) the chairs have deviced to take a step > back, and re-state the fundamental "do we want to go there?" question > (and extend the discussion phase by +4 weeks). sorry for helping out with that ;) > The idea to go there came from various people in the community, mostly > for one reason - having two differently "coloured" addresses that do > the same thing, routingwise, but follow different policies and have > different strings attached, creates quite some confusion for the folks > out there that can no longer be nicely separated into "ISPs" (->become > RIPE members, use PA) and "end-users" (->use PI, if BGP-based multihoming > and/or upstream independence is required). > > Most notably, "garage style hosting providers" seem to have issues > with the requirement of the IPv6 PI policy that PI space MUST NOT be > sub-assigned, which the NCC interprets most strictly (because the vast > amount of "grey" between "ok" and "not ok" is hard to codify into > hostmaster guidelines). OTOH, I have not heard that complaint from > actual hosting providers for a while, so maybe the issue is not that > big anymore. Erik Bais's mail touch what is probably the only real difference between PI and PA, and our core problem: >From Erik Bais's post on this thread: "Having garage-style 'hosters' do assignments, just because they can while using PI IPv6 space, is against the policy, however removing that distinction between PI and PA for v6 and allowing sub-assignments from PI space will basically open the door in the near future for cheap resources, without being an LIR. That will have an impact on the number of members the NCC will have once we are beyond the v4 era ... And less members will result in a high fee per member." Isn't this really about what is the difference between being a member and not? It would be nice to get ride of the PI and PA, and at the same time keeping the difference between member (LIR) and none member (no-LIR). > *If* we go to "there is only one type of addresses" anymore, we have two > options > > - abandon IPv6 PI (as in "not so expensive, but independent space") > completely, problem solved -> I do not think we can reasonably do that See above, wish we could, but it has this member/not-member side... > - find a way to solve the needs for both RIPE members and non-members, > with maximum flexibility, with only one type of addresses, taking > "real world" address distribution chains (LIR->network operator-> > hosting provider->customer->hosted virtual machines, for example) > and "real world" financial constraints into account. This is the way I think we should pursue and see if we can figure out. It is all just bits/numbers anyhow. Right now I don't see a way to get there, we probably have some other work to get done first. > 2013-06 aims to achieve the latter, while proposing / finding specific > solutions for all the small details that come up if such a radical change > is implemented. 2013-06 is dead in the water right now, it's too complex to get it done the way it was attempted. > I think the presentation at RIPE67 was a bit too fast for the WG - it > could have spent a bit more time on the background and "do we want to > go there" before overwhelming you with questions about details to be > solved. For that, I apologize - I did review the presentation beforehand > with the proposers, and assumed "yes, this should work out nicely"... I think the presentation were good in the way that it showed the complexity we are trying to address. It made it very clear to me that it is not a easy thing to change. The other good thing, it trigged a discussion which is almost always a good thing. It make people think. > Anyway. I think what we need to hear now from the community (*you*) is > where we want to go: > > - do nothing, our policy for IPv6 PA and IPv6 PI "as of today" is fine Not an option as I see it. > - keep the distinction, work on the IPv6 PI policy (if the pain is > large enough that someone actually volunteers to come with a proposal) > > - go the big step, unify IPv6 PA and IPv6 PI, and solve all the detail > problems that need to be addressed if we go there. I think we should remove the difference between PI and PA. However I don't see how to get there, but we can start with something else. What if we start with doing some housekeeping, make the different policies affecting the "PI-domain" clean and neat? Preferable in just one document. Later when that's concluded we might be able to move it one step further? Another side of this PI/PA space, should there be any way to transfer/change a PI allocation into PA? PI holders (not members) should have the options to become members and at that point they should have their addresses also made into PA... I think it's possible to have PI space while being member today? That should not exist, it should just be PA if you are a member... Then we have this concept of "independed resources"... is that PI or PI+ other things? -- Roger Jorgensen | ROJO9-RIPE rogerj at gmail.com | - IPv6 is The Key! http://www.jorgensen.no | roger at jorgensen.no From raymond.jetten at elisa.fi Mon Oct 28 08:56:53 2013 From: raymond.jetten at elisa.fi (Jetten Raymond) Date: Mon, 28 Oct 2013 09:56:53 +0200 Subject: [address-policy-wg] 2013-06 New Policy Proposal (PA/PI Unification IPv6 Address Space) In-Reply-To: <00bf01ced269$29a6a830$7cf3f890$@a2b-internet.com> References: <1380206290.2739@mobil.space.net> <20131025180341.GA75737@Space.Net> <00bf01ced269$29a6a830$7cf3f890$@a2b-internet.com> Message-ID: I fully agree with Erik, please do not continue with 2013-06. -----Original Message----- From: address-policy-wg-bounces at ripe.net [mailto:address-policy-wg-bounces at ripe.net] On Behalf Of Erik Bais Sent: 26. lokakuuta 2013 19:34 To: 'Gert Doering'; address-policy-wg at ripe.net Subject: Re: [address-policy-wg] 2013-06 New Policy Proposal (PA/PI Unification IPv6 Address Space) Hi Gert, Thanks for the email and the discussion in Athens and let me start by saying thanks to the authors of the amount of effort and work they have put into this. > Anyway. I think what we need to hear now from the community (*you*) is > where we want to go: Having heard the discussion in Athens and seen the presentation, I personally think that we should abandon 2013-06. Having garage-style 'hosters' do assignments, just because they can while using PI IPv6 space, is against the policy, however removing that distinction between PI and PA for v6 and allowing sub-assignments from PI space will basically open the door in the near future for cheap resources, without being an LIR. That will have an impact on the number of members the NCC will have once we are beyond the v4 era ... And less members will result in a high fee per member. > - do nothing, our policy for IPv6 PA and IPv6 PI "as of today" is fine Having said that, maybe the currently policy isn't perfect, but it is better than the alternative imho. Not every End-User can legally become an LIR and they would still require the ability to be independent from their upstream provider. > - keep the distinction, work on the IPv6 PI policy (if the pain is > large enough that someone actually volunteers to come with a proposal) Been there, done that... Let's implement v6 first. The current policy provides options for people on what to do and how to get what you require. If the policy is limiting v6 deployments, we can always revisit a specific option again imho. The current policy allows a End-User to receive their own /48 (minimal assignment) or larger with demonstrated documentation and need. The limitation is that they are not allowed to sub-assign to other organizations. > - go the big step, unify IPv6 PA and IPv6 PI, and solve all the detail problems that need to be addressed if we go there. I would strongly not go there to remove the PI limitation of sub-assignments to others and increasing the assigned (or newly proposed allocate) size to a /32 or /29 similar as one would get by signing up for a LIR membership. Regards, Erik Bais From mschmidt at ripe.net Mon Oct 28 14:43:48 2013 From: mschmidt at ripe.net (Marco Schmidt) Date: Mon, 28 Oct 2013 14:43:48 +0100 Subject: [address-policy-wg] 2013-06 Discussion Period extended until 26 November 2013 (PA/PI Unification IPv6 Address Space) Message-ID: Dear colleagues, The Discussion Period for the proposal 2013-06, "PA/PI Unification IPv6 Address Space", has been extended until 26 November 2013. You can find the full proposal at: https://www.ripe.net/ripe/policies/proposals/2013-06 We encourage you to review this policy proposal and send your comments to . Regards, Marco Schmidt Policy Development Office RIPE NCC From gert at space.net Tue Oct 29 11:10:03 2013 From: gert at space.net (Gert Doering) Date: Tue, 29 Oct 2013 11:10:03 +0100 Subject: [address-policy-wg] 2013-05 New Draft Document and Impact Analysis Published (No Restrictions on End User Assignments in Intra-RIR Transfers) In-Reply-To: <1380547464.9558@mobil.space.net> References: <1380547464.9558@mobil.space.net> Message-ID: <20131029101003.GA47974@Space.Net> Dear AP WG, On Mon, Sep 30, 2013 at 03:22:17PM +0200, Marco Schmidt wrote: > The draft document for the proposal described in 2013-05, > "No Restrictions on End User Assignments in Intra-RIR Transfers" > has been published. The impact analysis that was conducted for this > proposal has also been published. [..] > We encourage you to read the draft document text and send any comments > to address-policy-wg at ripe.net before 29 October 2013. The review phase for this proposal is now over. On the list, there have been 8 voices of support, and no opposition (it was also presented at the RIPE67 meeting in Athens, and did not see opposition there either). I take this as consensus, and we'll move the proposal to Last Call now. Gert Doering -- APWG chair -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 826 bytes Desc: not available URL: From tore at fud.no Tue Oct 29 15:33:18 2013 From: tore at fud.no (Tore Anderson) Date: Tue, 29 Oct 2013 15:33:18 +0100 Subject: [address-policy-wg] 2013-06 New Policy Proposal (PA/PI Unification IPv6 Address Space) In-Reply-To: <20131025180341.GA75737@Space.Net> References: <1380206290.2739@mobil.space.net> <20131025180341.GA75737@Space.Net> Message-ID: <526FC72E.7020802@fud.no> * Gert Doering > The proposal aims to unify IPv6 PA and IPv6 PI space into one kind of > address space, "IPv6 addresses". This is the goal. A goal which I support. However, the proposal does go a bit further than just this. For example, it: - unifies [PA] allocations and [PA] assignments - unifies the LIR and End User roles - allows an infinitely deep hierarchy of LIR+EU organisations - in doing so, significantly changes the structure of the Internet Registry System - dramatically increases the maximum undocumented delegation size from 1 /29 per LIR to $NUMSITES * /29. - codifies particular mercantile/contractual arrangements into internet number policy I think it would benefit the proposal's journey through the PDP if it tried to do fewer things at once, perhaps by splitting it into multiple proposals. > The idea to go there came from various people in the community, mostly > for one reason - having two differently "coloured" addresses that do > the same thing, routingwise, but follow different policies and have > different strings attached, creates quite some confusion for the folks > out there that can no longer be nicely separated into "ISPs" (->become > RIPE members, use PA) and "end-users" (->use PI, if BGP-based multihoming > and/or upstream independence is required). > > Most notably, "garage style hosting providers" seem to have issues > with the requirement of the IPv6 PI policy that PI space MUST NOT be > sub-assigned, which the NCC interprets most strictly (because the vast > amount of "grey" between "ok" and "not ok" is hard to codify into > hostmaster guidelines). OTOH, I have not heard that complaint from > actual hosting providers for a while, so maybe the issue is not that > big anymore. Is this concern really specific to PI? I'd say this is more a problematic property of IPv6 *assignments* - regardless of them being PI or PA. Being a data centre operator and LIR, I believe I cannot currently make an IPv6 PA assignment to a customer of mine who wants to run a cloud service where their customers can rent virtual servers in turn. (A customer of theirs may in turn run some sort of web hotel for another set of customers on those VMs, and so on and so on.) I do have such customers today. "Luckily" they've not yet taken an interest in IPv6. In IPv4, on the other hand, I may (ab)use the "single address loophole" to assign them the addresses they need. In any case, this particular concern could be resolved by relaxing the requirements on assignments somewhat. For example by allowing End Users to use the addresses for providing services to other entities (who may in turn do the same and so on), as long as the End User the assignment is registered to retains operational responsibility for the network in question. Of course, this wouldn't by itself yield PI/PA unification. However I think that too may be accomplished in a less intrusive way than 2013-06 currently proposes: Delete section 7, and add a new section to the appendix or even just the supporting notes saying that it should be possible to obtain become an LIR and hold PA space without being a direct member of the RIPE NCC, and that this should cost about the same as holding PI does today, and that all pre-existing PI holders and their blocks/inet6nums should be automatically converted to this new arrangement. Just my ?.02 Tore From stolpe at resilans.se Tue Oct 29 16:00:56 2013 From: stolpe at resilans.se (Daniel Stolpe) Date: Tue, 29 Oct 2013 16:00:56 +0100 (CET) Subject: [address-policy-wg] 2013-06 New Policy Proposal (PA/PI Unification IPv6 Address Space) In-Reply-To: References: <1380206290.2739@mobil.space.net> <20131025180341.GA75737@Space.Net> Message-ID: As one of the authors of this proposal, maybe I should just shut up now, but I would just like to say that the current version of the proposal is a first attempt trying to solve an identified problem. Apparently it became a bit too complex. Another comment below. On Fri, 25 Oct 2013, Jan Ingvoldstad wrote: > On Fri, Oct 25, 2013 at 8:03 PM, Gert Doering wrote: > Dear Address Policy WG, > > On Thu, Sep 26, 2013 at 04:36:24PM +0200, Marco Schmidt wrote: > > A proposed change to RIPE Documents ripe-589, "IPv6 Address > > Allocation and Assignment Policy", ripe-451, "IPv6 Address > > Space Policy For Internet Exchange Points" and ripe-233, > > "IPv6 Addresses for Internet Root Servers In The RIPE Region" > > is now available for discussion. > [..] > > We encourage you to review this proposal and send your comments to > > before 25 October 2013. > > The discussion phase for this proposal is now over, but after the > feedback received at the RIPE meeting in Athens (and here on the list, > even if in the wrong thread :) ) the chairs have deviced to take a step > back, and re-state the fundamental "do we want to go there?" question > (and extend the discussion phase by +4 weeks). > > The proposal aims to unify IPv6 PA and IPv6 PI space into one kind of > address space, "IPv6 addresses". ?This is the goal. > > The idea to go there came from various people in the community, mostly > for one reason - having two differently "coloured" addresses that do > the same thing, routingwise, but follow different policies and have > different strings attached, creates quite some confusion for the folks > out there that can no longer be nicely separated into "ISPs" (->become > RIPE members, use PA) and "end-users" (->use PI, if BGP-based multihoming > and/or upstream independence is required). > > > In my opinion, this distinction is not particularly useful in itself, > and could very well be a floating definition. > > Coming from the DNS registrar side, I cannot help thinking that looking > at the registry/registrar model might be beneficial for making things > clearer for people out there. > > One way of seeing this, is that the LIRs are "registrars" for IP address > space, and that their role could simply be about registering and > brokering assignments and allocations for the RIR. > > An ISP or an "end user" then becomes an unnecessary distinction, as they > would both have to go to a LIR to get their address space, and it's just > a matter of placing a request for the correct size, at the discretion of > the applicant and the LIR. > > Mind you, I think this is mostly about perspective, but if we could use > the similarities with DNS registrations, then end customers (ISPs or > whatever) might have less confusion. > > I could very well be wrong. I (personally) think you are right. You don't have so set up a domain name registrar if you just want to use a couple of domain names. We regularly see entities out there who just want some address space. Sometimes just a small space and sometimes a very space. I think if would be beneficial if they had an option to ask a registrar (LIR) to do the book keeping for them. Best Regards, Daniel Stolpe _________________________________________________________________________________ Daniel Stolpe Tel: 08 - 688 11 81 stolpe at resilans.se Resilans AB Fax: 08 - 55 00 21 63 http://www.resilans.se/ Box 13 054 556741-1193 103 02 Stockholm From stolpe at resilans.se Tue Oct 29 16:23:52 2013 From: stolpe at resilans.se (Daniel Stolpe) Date: Tue, 29 Oct 2013 16:23:52 +0100 (CET) Subject: [address-policy-wg] 2013-06 New Policy Proposal (PA/PI Unification IPv6 Address Space) In-Reply-To: References: <1380206290.2739@mobil.space.net> <20131025180341.GA75737@Space.Net> Message-ID: On Sun, 27 Oct 2013, Roger J?rgensen wrote: > Erik Bais's mail touch what is probably the only real difference > between PI and PA, and our core problem: > >> From Erik Bais's post on this thread: > "Having garage-style 'hosters' do assignments, just because they can while > using PI IPv6 space, is against the policy, however removing that > distinction between PI and PA for v6 and allowing sub-assignments from PI > space will basically open the door in the near future for cheap resources, > without being an LIR. That will have an impact on the number of members the > NCC will have once we are beyond the v4 era ... And less members will result > in a high fee per member." > > > Isn't this really about what is the difference between being a member and not? > It would be nice to get ride of the PI and PA, and at the same time > keeping the difference between member (LIR) and none member (no-LIR). Well, there has to be some benefits for the members, hasn't it? At the same time, what says RIPE has to have 10.000 members? Or 130 employees? And the current policy looks very much like a membership boosting construction: just sign up, pay the bill and get a /29 (compaired to ask a member to apply for a /48 with very restricted use and make life really hard if you ever want anything more). What makes us think that PA holders/members are always responsible while PI holders/non-members are completely not trustworthy? I would prefer policies to apply for addresses (let's say, thou shalt not assign less than a /xx to an yy) rather than the role play of today. Best Regards, Daniel Stolpe _________________________________________________________________________________ Daniel Stolpe Tel: 08 - 688 11 81 stolpe at resilans.se Resilans AB Fax: 08 - 55 00 21 63 http://www.resilans.se/ Box 13 054 556741-1193 103 02 Stockholm From ksyu at netassist.ua Tue Oct 29 19:47:54 2013 From: ksyu at netassist.ua (ksyu at netassist.ua) Date: Tue, 29 Oct 2013 20:47:54 +0200 Subject: [address-policy-wg] New Policy Proposal (PI - PA Transfer) In-Reply-To: <526581F5.3000305@schiefner.de> References: <4365f8f99e40b104ad3eeb440591ffb6@deltahost.com.ua> <20131021120845.GB65295@Space.Net> <20131021184030.GA93776@Space.Net> <526581F5.3000305@schiefner.de> Message-ID: <527002DA.9050004@netassist.ua> Hi to everybody I don't understand what is the problem to return the possibility to turn PI to PA? If it was somedays = that means that is possible. What troubles RIPE are expecting to see - if they are still oscillate with the solution? IPv6 unfortunately is not using as It was expecting to be in use. Good if 5% of providers are using IPv6. Now almost all are still using IPv4. The principles in this policy generates a lot of troubles. Some people are starting to steal or use somebodies networks illegally. Don't close your eyes. You know how they can do this. What should all other companies do if they can't get their own addresses? They will ask for rent. But the price now is too high. And will not go down if something will not changes. As I see the solution to soften the migration from v4 to v6 - this solution is a flexible POLICY. Let's return the possibility to transfer PI to PA and ease the life of a lot of small companies which need their own addresses. What to do with PI space that is smaller than the minimum allocation size? I see excellent way - Make a minimum /22 and just wait for a little bit - when addresses will end finally. Than every block can be turned into the PA. Best regards, Kseniya 21.10.2013 22:35, Carsten Schiefner ?????: > Gert, > > you still seem to be a bit stressed out - no relaxing weekend?! ;-) > > On 21.10.2013 20:40, Gert Doering wrote: >> But I think we have found another volunteer for the minimum allocation >> size obstacle regarding IPv4 PA->PI conversion. Also related to IPv4 PI, >> but differently... > > This should read "regarding IPv4 PI->PA conversion" - as it concerns > converting "ASSINGED PI" IPv4 space of LIRs into "ALLOCATED PA" space > for the respective LIR. > > The (main) question here is: what to do with PI space that is smaller > than the minimum allocation size. > > Cheers, > > -C. > -- ? ??. ?????? ????? From dmitriy at deltahost.com.ua Tue Oct 29 21:18:40 2013 From: dmitriy at deltahost.com.ua (Dmitriy Zemlyanoy) Date: Tue, 29 Oct 2013 22:18:40 +0200 Subject: [address-policy-wg] New Policy Proposal (PI - PA Transfer) In-Reply-To: <527002DA.9050004@netassist.ua> References: "<4365f8f99e40b104ad3eeb440591ffb6@deltahost.com.ua> <20131021120845.GB65295@Space.Net>" <20131021184030.GA93776@Space.Net> <526581F5.3000305@schiefner.de> <527002DA.9050004@netassist.ua> Message-ID: <05789f4f589012ad2559917e28ff68fc@deltahost.com.ua> Exactly. I also think that current (disallowing) transfer practice for block /22 (and larger) - is an artificial problem. I think there is no problem to allow transfer PI->PA for blocks /22 (and larger) right now. And after that we can continue discussing about blocks less then /22. It seems that question about transfering blocks less then /22 is not easy, but there is no question for blocks /22 (and large). Delaying this for discussing question about blocks less then /22 - we making situation more and more hard each day. Agiotage around IPv4 is growing each day. So, let's make some cool down of situation - let's allow transfer /22 (and larger) right now and leave the question of less then /22 for discussion. It will improve situation right now and give us some time to discuss about blocks less then /22 -- Dmitriy Zemlyanoy. DeltaHost. http://deltahost.com ksyu at netassist.ua ????? 2013-10-29 20:47: > Hi to everybody > > I don't understand what is the problem to return the possibility to > turn PI to PA? If it was somedays = that means that is possible. > What troubles RIPE are expecting to see - if they are still oscillate > with the solution? > > IPv6 unfortunately is not using as It was expecting to be in use. > Good if 5% of providers are using IPv6. > > Now almost all are still using IPv4. > > The principles in this policy generates a lot of troubles. Some people > are starting to steal or use somebodies networks illegally. Don't > close your eyes. You know how they can do this. > > What should all other companies do if they can't get their own > addresses? They will ask for rent. But the price now is too high. And > will not go down if something will not changes. > > As I see the solution to soften the migration from v4 to v6 - this > solution is a flexible POLICY. > > Let's return the possibility to transfer PI to PA and ease the life of > a lot of small companies which need their own addresses. > > What to do with PI space that is smaller than the minimum allocation > size? > I see excellent way - Make a minimum /22 and just wait for a little > bit - when addresses will end finally. Than every block can be turned > into the PA. > > Best regards, Kseniya > > > > 21.10.2013 22:35, Carsten Schiefner ?????: >> Gert, >> >> you still seem to be a bit stressed out - no relaxing weekend?! ;-) >> >> On 21.10.2013 20:40, Gert Doering wrote: >>> But I think we have found another volunteer for the minimum >>> allocation >>> size obstacle regarding IPv4 PA->PI conversion. Also related to IPv4 >>> PI, >>> but differently... >> >> This should read "regarding IPv4 PI->PA conversion" - as it concerns >> converting "ASSINGED PI" IPv4 space of LIRs into "ALLOCATED PA" space >> for the respective LIR. >> >> The (main) question here is: what to do with PI space that is smaller >> than the minimum allocation size. >> >> Cheers, >> >> -C. >> From frettled at gmail.com Wed Oct 30 09:31:00 2013 From: frettled at gmail.com (Jan Ingvoldstad) Date: Wed, 30 Oct 2013 09:31:00 +0100 Subject: [address-policy-wg] New Policy Proposal (PI - PA Transfer) In-Reply-To: <527002DA.9050004@netassist.ua> References: <4365f8f99e40b104ad3eeb440591ffb6@deltahost.com.ua> <20131021120845.GB65295@Space.Net> <20131021184030.GA93776@Space.Net> <526581F5.3000305@schiefner.de> <527002DA.9050004@netassist.ua> Message-ID: On Tue, Oct 29, 2013 at 7:47 PM, ksyu at netassist.ua wrote: > > IPv6 unfortunately is not using as It was expecting to be in use. > Good if 5% of providers are using IPv6. > > Now almost all are still using IPv4. > This is not unexpected. >From my point of view, IPv6 uptake is higher than what I expected. That has only just begun, and I honestly don't think low uptake of IPv6 (if it was true!) is a good argument for policy changes in IPv4. -- Jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From mschmidt at ripe.net Wed Oct 30 14:24:00 2013 From: mschmidt at ripe.net (mschmidt) Date: Wed, 30 Oct 2013 14:24:00 +0100 Subject: [address-policy-wg] 2013-05 Last Call for Comments (No Restrictions on End User Assignments in Intra-RIR Transfers) Message-ID: Dear colleagues, The proposal described in 2013-05, No Restrictions on End User Assignments in Intra-RIR Transfers, is now in its Concluding Phase. The Address Policy Working Group co-Chairs have declared that consensus for the proposal has been reached and it will now move to Last Call. As per the RIPE Policy Development Process (PDP), the purpose of these coming four weeks of Last Call is to give the community the opportunity to present well-justified objections in case anyone missed the previous two phases and want to oppose the proposal. Any objection must be made by 28 November and must be supported by an explanation. If no substantive objections are raised by the end of Last Call, the proposal will complete the PDP and will be evaluated by the co-Chairs of all RIPE Working Groups for consensus. You can find the full proposal at: https://www.ripe.net/ripe/policies/proposals/2013-05 [1] Please e-mail any final comments about this proposal to address-policy-wg at ripe.net before 28 November 2013. Regards Marco Schmidt Policy Development Office RIPE NCC Links: ------ [1] https://www.ripe.net/ripe/policies/proposals/2013-04 -------------- next part -------------- An HTML attachment was scrubbed... URL: