From h.lu at anytimechinese.com Thu Dec 3 12:26:59 2015 From: h.lu at anytimechinese.com (Lu Heng) Date: Thu, 3 Dec 2015 12:26:59 +0100 Subject: [address-policy-wg] An interesting policy question Message-ID: Hi I have an policy question regarding Ripe policy before adoption of "no need" policy. We all know that before the no need policy, when Ripe makes an assignment, while the "need" has changed, the assignment become invalid. The question come to what the definition of need. Below I have few examples, please provide your view: First one: Company A provides 100 customer dedicated server service at location A, Ripe makes an assignment for 100 IP for his infrastructure, if, under condition that no other factor was changed, Company A moved his infrastructure to location B, but still providing same service to same customer, does the company's action need to be notified to RIR? And does this action considered invalid the original assignment? Second one: Company A provides web hosting service, but any casted in 3 location, and has provided the evidence of 3 location to the RIR during the time the company getting valid assignment, then A decided to cut 3 location to 2 location, does this invalid original assignment and need to be notified to RIR? So the bottom line is, what is the definition of need, is it defined as the service you are providing or defined as whole package of any of original justification material was provided, if was the later, then does it imply that anything, including location of the infrastructure, upstream providers etc has changed due to operational need, it will be considered as change of purpose of use and need to be notified to RIR? What should be the right interpretation of the policy by then? -- -- Kind regards. Lu -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrea at ripe.net Thu Dec 3 17:19:03 2015 From: andrea at ripe.net (Andrea Cima) Date: Thu, 3 Dec 2015 17:19:03 +0100 Subject: [address-policy-wg] An interesting policy question In-Reply-To: References: Message-ID: <56606B77.8080506@ripe.net> Hi Lu, Thank you for the question. Regarding what we would do under the old policies ? it?s very difficult for us to speculate how hypothetical examples would have been evaluated under outdated processes that we no longer follow. For this reason, we are unable to indicate how we would have handled these requests before the current policies were adopted. On a more general note, it is important to be aware that the current "IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region" states: "Only allocations and assignments registered in the RIPE Database are considered valid. [...] Registration data (range, contact information, status etc.) must be correct at all times (i.e. they have to be maintained)." https://www.ripe.net/publications/docs/ripe-649#4 This means that any change to the registration data must be reflected in the RIPE Database, and it is the LIR that is responsible for maintaining this. The RIPE NCC regularly confirms the correctness of the registration data with audits (ARC reviews), during additional allocation requests, or on request by a member. Best regards, Andrea Cima RIPE NCC On 03/12/2015 12:26, Lu Heng wrote: > Hi > > I have an policy question regarding Ripe policy before adoption of "no > need" policy. > > We all know that before the no need policy, when Ripe makes an > assignment, while the "need" has changed, the assignment become invalid. > > The question come to what the definition of need. Below I have few > examples, please provide your view: > > First one: > > Company A provides 100 customer dedicated server service at location > A, Ripe makes an assignment for 100 IP for his infrastructure, if, > under condition that no other factor was changed, Company A moved his > infrastructure to location B, but still providing same service to same > customer, does the company's action need to be notified to RIR? And > does this action considered invalid the original assignment? > > Second one: > > Company A provides web hosting service, but any casted in 3 location, > and has provided the evidence of 3 location to the RIR during the time > the company getting valid assignment, then A decided to cut 3 location > to 2 location, does this invalid original assignment and need to be > notified to RIR? > > So the bottom line is, what is the definition of need, is it defined > as the service you are providing or defined as whole package of any of > original justification material was provided, if was the later, then > does it imply that anything, including location of the infrastructure, > upstream providers etc has changed due to operational need, it will be > considered as change of purpose of use and need to be notified to RIR? > > What should be the right interpretation of the policy by then? > > -- > -- > Kind regards. > Lu > -------------- next part -------------- An HTML attachment was scrubbed... URL: From h.lu at anytimechinese.com Thu Dec 3 18:21:27 2015 From: h.lu at anytimechinese.com (h.lu at anytimechinese.com) Date: Thu, 3 Dec 2015 18:21:27 +0100 Subject: [address-policy-wg] An interesting policy question In-Reply-To: <56606B77.8080506@ripe.net> References: <56606B77.8080506@ripe.net> Message-ID: <94E60F4B-C5AD-4D1C-8443-4947ECEBC0B4@anytimechinese.com> Hi Andrea: Thank you for responds. Although this question posted here was asking community opinion to help future understand an important element in our policy history. "Need based IP distribution". Since current policy does not have it anymore, an official responds from NCC was not expected. And if my fellow colleague here has an opinion on this interpretation of "need" as well as the two examples I was given, enlighten me your thought, would really appreciated. On 3 Dec 2015, at 5:19 PM, Andrea Cima wrote: > > Hi Lu, > > Thank you for the question. > > Regarding what we would do under the old policies ? it?s very difficult for us to speculate how hypothetical examples would have been evaluated under outdated processes that we no longer follow. For this reason, we are unable to indicate how we would have handled these requests before the current policies were adopted. > > On a more general note, it is important to be aware that the current "IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region" states: > > "Only allocations and assignments registered in the RIPE Database are considered valid. [...] Registration data (range, contact information, status etc.) must be correct at all times (i.e. they have to be maintained)." > https://www.ripe.net/publications/docs/ripe-649#4 > > This means that any change to the registration data must be reflected in the RIPE Database, and it is the LIR that is responsible for maintaining this. The RIPE NCC regularly confirms the correctness of the registration data with audits (ARC reviews), during additional allocation requests, or on request by a member. > > Best regards, > > Andrea Cima > RIPE NCC > > > >> On 03/12/2015 12:26, Lu Heng wrote: >> Hi >> >> I have an policy question regarding Ripe policy before adoption of "no need" policy. >> >> We all know that before the no need policy, when Ripe makes an assignment, while the "need" has changed, the assignment become invalid. >> >> The question come to what the definition of need. Below I have few examples, please provide your view: >> >> First one: >> >> Company A provides 100 customer dedicated server service at location A, Ripe makes an assignment for 100 IP for his infrastructure, if, under condition that no other factor was changed, Company A moved his infrastructure to location B, but still providing same service to same customer, does the company's action need to be notified to RIR? And does this action considered invalid the original assignment? >> >> Second one: >> >> Company A provides web hosting service, but any casted in 3 location, and has provided the evidence of 3 location to the RIR during the time the company getting valid assignment, then A decided to cut 3 location to 2 location, does this invalid original assignment and need to be notified to RIR? >> >> So the bottom line is, what is the definition of need, is it defined as the service you are providing or defined as whole package of any of original justification material was provided, if was the later, then does it imply that anything, including location of the infrastructure, upstream providers etc has changed due to operational need, it will be considered as change of purpose of use and need to be notified to RIR? >> >> What should be the right interpretation of the policy by then? >> >> -- >> -- >> Kind regards. >> Lu > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gert at space.net Thu Dec 3 19:23:38 2015 From: gert at space.net (Gert Doering) Date: Thu, 3 Dec 2015 19:23:38 +0100 Subject: [address-policy-wg] An interesting policy question In-Reply-To: <94E60F4B-C5AD-4D1C-8443-4947ECEBC0B4@anytimechinese.com> References: <56606B77.8080506@ripe.net> <94E60F4B-C5AD-4D1C-8443-4947ECEBC0B4@anytimechinese.com> Message-ID: <20151203182338.GD89490@Space.Net> Hi, On Thu, Dec 03, 2015 at 06:21:27PM +0100, h.lu at anytimechinese.com wrote: > And if my fellow colleague here has an opinion on this interpretation of "need" as well as the two examples I was given, enlighten me your thought, would really appreciated. If the customer just moves the same amount of stuff from A to B without anything changing hands or a reduction in the number of machines/services, *need* will still be satisfied. But Andrea has raised a significant point here: if *documentation* is not updated, the assignment is no longer valid, as that is a strict requirement (both for direct PI assignments and for PA-through-LIR assignments, it was not clear from your e-mail which sort you are referring to). Assuming PI, and assuming you are talking about the RIPE NCC making assignments ("Ripe" can not make assignments, as that's the policy-making community, read: all of us), I'm fairly sure the e-mail that contains the actual network that has been assigned clearly contains that requirement, to always keep the documentation up to date. Now, answerung to your second example: if you documented need for 3 locations, and part of that documentation contained something like "we need to upgrade the assignment size to a /24 to handle routing requirements, but we really only have 3 hosts on each site" - and then you move everything to one location, the original criteria would *not* apply any longer, as a single /24 would perfectly well serve to number these combined 9 hosts plus the routing requirements. So, individual cases are different (and I fully trust the NCC to understand the fine nuances, and to apply pain where necessary). 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: 811 bytes Desc: not available URL: From h.lu at anytimechinese.com Thu Dec 3 20:02:55 2015 From: h.lu at anytimechinese.com (Lu Heng) Date: Thu, 3 Dec 2015 20:02:55 +0100 Subject: [address-policy-wg] An interesting policy question In-Reply-To: <20151203182338.GD89490@Space.Net> References: <56606B77.8080506@ripe.net> <94E60F4B-C5AD-4D1C-8443-4947ECEBC0B4@anytimechinese.com> <20151203182338.GD89490@Space.Net> Message-ID: Hi Gert: Thank you for insight and detailed reply. (All the discussion below are about an latency policy element *need*, does not imply current Ripe policy in anyway) On Thu, Dec 3, 2015 at 7:23 PM, Gert Doering wrote: > Hi, > > On Thu, Dec 03, 2015 at 06:21:27PM +0100, h.lu at anytimechinese.com wrote: > > And if my fellow colleague here has an opinion on this interpretation of > "need" as well as the two examples I was given, enlighten me your thought, > would really appreciated. > > If the customer just moves the same amount of stuff from A to B without > anything changing hands or a reduction in the number of machines/services, > *need* will still be satisfied. > > But Andrea has raised a significant point here: if *documentation* is not > updated, the assignment is no longer valid, as that is a strict requirement > (both for direct PI assignments and for PA-through-LIR assignments, it > was not clear from your e-mail which sort you are referring to). > To best of my understanding, "documentation" here means whois database, as long as whois database has been updated with relevant update, no second proof was needed from Ripe NCC for the same assignment, correct me if I was wrong. > > Assuming PI, and assuming you are talking about the RIPE NCC making > assignments ("Ripe" can not make assignments, as that's the policy-making > community, read: all of us), I'm fairly sure the e-mail that contains > the actual network that has been assigned clearly contains that > requirement, > to always keep the documentation up to date. > I fully understand the difference between the NCC and the community, sorry for the confusion here. > > Now, answerung to your second example: if you documented need for 3 > locations, > and part of that documentation contained something like "we need to upgrade > the assignment size to a /24 to handle routing requirements, but we really > only have 3 hosts on each site" - and then you move everything to one > location, the original criteria would *not* apply any longer, as a single > /24 would perfectly well serve to number these combined 9 hosts plus the > routing requirements. > Sorry for misunderstanding, my intended example was, to be more detail, a /24 was proofed for any cast in 3 locations for DNS(so one /24 was proofed), during the evaluation process, evidence of existence of infrastructure of 3 locations are all provided, later after approval, management decided that 2 location would be enough for its need to reach customers, so it decided to shinrk amount of location to 2, while the service provided and the customer served was not changed, so the need of a /24 is not changed as well, my questions is, does such action considered "change of purpose of use" and invalid the assignment therefore need approval from NCC for the action before process? So the bottom line is, what does *need* mean? Does it means the whole package of justification material(so including everything submitted during the evaluation process for the assignment, including but not limit to the upstream's contract, location of the server, etc), or does it means the *service* was provided, LIR can free justify it's own infrastructure(e.g. move server from DC A to DC B to improve speed) to provide same service to the same customer group? Because if *need* includes whole package of justification material, then by definition, change any thing in that package(for example, location of the server, upstream provider), would request NCC approval for the assignment again therefore effectively requested NCC to manage all the infrastructure adjustment by it's members(assure the LIR do not have assignment window), because the need has changed. I recently had this policy discussion with some RIR personnels and getting really confused, so that's the reason I come to the community to seek clarification for the understanding this very important piece of history. And I do believe documented clarification and discussion in the list for this important historical element will help future generation understand the policy better(me included). And thanks again Gert for the time and explanation. > > So, individual cases are different (and I fully trust the NCC to understand > the fine nuances, and to apply pain where necessary). > > 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 > -- -- Kind regards. Lu -------------- next part -------------- An HTML attachment was scrubbed... URL: From sander at steffann.nl Thu Dec 3 20:12:50 2015 From: sander at steffann.nl (Sander Steffann) Date: Thu, 3 Dec 2015 20:12:50 +0100 Subject: [address-policy-wg] An interesting policy question In-Reply-To: References: Message-ID: Hi Lu, > I have an policy question regarding Ripe policy before adoption of "no need" policy. I don't see the usefulness of second-guessing how obsolete policy would have been applied. Can you explain the relevance to current policy development? > We all know that before the no need policy, when Ripe makes an assignment, while the "need" has changed, the assignment become invalid. RIPE NCC only would assign provider independent resources. To LIRs RIPE NCC would allocate resources and then verify policy requirements, such as need, when the LIR makes assignments from the allocation. > The question come to what the definition of need. Below I have few examples, please provide your view: I am not going into the details of your examples as they are no longer relevant to current policy development. In general: assignments are quite specific. As an LIR you assign resources to your own infrastructure or a specific customer. Whenever any of that changes (i.e. customers changing, expansion of networks etc) it would be considered a new assignment which would require new justification (need etc). So the correct thing to do in the database (to keep things a bit relevant) would be to delete the old assignments and create new ones. That would keep the history nice and clean (old object would be for the old assignment, new object with new creation date would be for the new assignment). Cheers, Sander From sander at steffann.nl Thu Dec 3 20:25:29 2015 From: sander at steffann.nl (Sander Steffann) Date: Thu, 3 Dec 2015 20:25:29 +0100 Subject: [address-policy-wg] An interesting policy question In-Reply-To: References: <56606B77.8080506@ripe.net> <94E60F4B-C5AD-4D1C-8443-4947ECEBC0B4@anytimechinese.com> <20151203182338.GD89490@Space.Net> Message-ID: Hi Lu, > Because if *need* includes whole package of justification material, then by definition, change any thing in that package(for example, location of the server, upstream provider), would request NCC approval for the assignment again It depends what the conditions were for getting the assignment in the first place. If you were allowed to make an assignment for reason X then you can't just change X. You can change Y and Z, as long as they weren't part of the condition. What those fictional X, Y and Z might be are completely dependent on the actual policy, and for addresses we don't have any needs criteria anymore so this is all hypothetical. > therefore effectively requested NCC to manage all the infrastructure adjustment by it's members(assure the LIR do not have assignment window), because the need has changed. Are you still talking about RIPE NCC here? You are talking about situations and concepts that seem to have nothing to do with our region... Let's stop this discussion on hypothetical impact of hypothetical policy. Cheers, Sander From h.lu at anytimechinese.com Thu Dec 3 20:33:22 2015 From: h.lu at anytimechinese.com (Lu Heng) Date: Thu, 3 Dec 2015 20:33:22 +0100 Subject: [address-policy-wg] An interesting policy question In-Reply-To: References: Message-ID: Hi On Thu, Dec 3, 2015 at 8:12 PM, Sander Steffann wrote: > Hi Lu, > > > I have an policy question regarding Ripe policy before adoption of "no > need" policy. > > I don't see the usefulness of second-guessing how obsolete policy would > have been applied. Can you explain the relevance to current policy > development? > Yes, for old folks here, things seems obvious, but I believe we still need to have next generation people here to participate the discussion, if we do not understand where we ware coming from, how we understand the way to develop future? As I have explained in my last Email, understanding of some key element in our past policy will help us going future with our current policy development. If this list is patient enough, we won't have people coming back over and over again with asking NCC to be police force, reclamation of resources. Also in the Ripe meeting with the younger people I've talked to, many of them do not understand how the policy being developed today because there is no start point, we ware not there since it started, not there for over two decades like many friends here. One day someone interested about policy development searching for future understanding of the *need*, will see it has been blocked to discuss here. I hope it does not happen. > > > We all know that before the no need policy, when Ripe makes an > assignment, while the "need" has changed, the assignment become invalid. > > RIPE NCC only would assign provider independent resources. To LIRs RIPE > NCC would allocate resources and then verify policy requirements, such as > need, when the LIR makes assignments from the allocation. > > > The question come to what the definition of need. Below I have few > examples, please provide your view: > > I am not going into the details of your examples as they are no longer > relevant to current policy development. In general: assignments are quite > specific. As an LIR you assign resources to your own infrastructure or a > specific customer. Whenever any of that changes (i.e. customers changing, > expansion of networks etc) it would be considered a new assignment which > would require new justification (need etc). > I believe it is relevant as I have explained above. > > So the correct thing to do in the database (to keep things a bit relevant) > would be to delete the old assignments and create new ones. That would keep > the history nice and clean (old object would be for the old assignment, new > object with new creation date would be for the new assignment). > > Cheers, > Sander > > "Are you still talking about RIPE NCC here? You are talking about situations and concepts that seem to have nothing to do with our region... Let's stop this discussion on hypothetical impact of hypothetical policy." This is a pure policy discussion and not relevant to the region really, need exists or existed in every region. "It depends what the conditions were for getting the assignment in the first place. If you were allowed to make an assignment for reason X then you can't just change X. You can change Y and Z, as long as they weren't part of the condition. What those fictional X, Y and Z might be are completely dependent on the actual policy, and for addresses we don't have any needs criteria anymore so this is all hypothetical." all the assignment for an "service", in which what confuse me is "does RIR also manage the infrastructure detail for the service"? No offense here in anyway, as I repeated said, I just trying to understand *need*. that's it. -- -- Kind regards. Lu -------------- next part -------------- An HTML attachment was scrubbed... URL: From gert at space.net Thu Dec 3 20:51:11 2015 From: gert at space.net (Gert Doering) Date: Thu, 3 Dec 2015 20:51:11 +0100 Subject: [address-policy-wg] An interesting policy question In-Reply-To: References: Message-ID: <20151203195111.GH89490@Space.Net> Hi, On Thu, Dec 03, 2015 at 08:33:22PM +0100, Lu Heng wrote: > Yes, for old folks here, things seems obvious, but I believe we still need > to have next generation people here to participate the discussion, if we do > not understand where we ware coming from, how we understand the way to > develop future? I do not think that this is particularily relevant here. The status "we have plenty of IPv4 but need to ensure fairness between different ISPs' customers" will not come back - and IPv6 is significantly different that not much can be learned by IPv4's restrictive policies. If you have a specific question, you're welcome to ask. But generic "what if... and can you remember the good old times?" stuff are just noise to most of the participants of the list - so, discuss this at a beer with others who are interested, but not here. > As I have explained in my last Email, understanding of some key element in > our past policy will help us going future with our current policy > development. Not in this vagueness. 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: 811 bytes Desc: not available URL: From h.lu at anytimechinese.com Thu Dec 3 20:56:04 2015 From: h.lu at anytimechinese.com (Lu Heng) Date: Thu, 3 Dec 2015 20:56:04 +0100 Subject: [address-policy-wg] An interesting policy question In-Reply-To: <20151203195111.GH89490@Space.Net> References: <20151203195111.GH89490@Space.Net> Message-ID: Hi Gert: I am asking a very specific question to an very specific service example here, the only way to be more specific would be naming people. If you read my last Email, I have tried my best to ask that very specific question. *So the bottom line is, what does *need* mean? Does it means the whole package of justification material(so including everything submitted during the evaluation process for the assignment, including but not limit to the upstream's contract, location of the server, etc), or does it means the *service* was provided, LIR can free justify it's own infrastructure(e.g. move server from DC A to DC B to improve speed) to provide same service to the same customer group?* *Because if *need* includes whole package of justification material, then by definition, change any thing in that package(for example, location of the server, upstream provider), would request NCC approval for the assignment again therefore effectively requested NCC to manage all the infrastructure adjustment by it's members(assure the LIR do not have assignment window), because the need has changed.* Sorry about my English that I can not put it in one sentence, and needed example to help explain, but my question are very very specific and not for the beer time. On Thu, Dec 3, 2015 at 8:51 PM, Gert Doering wrote: > Hi, > > On Thu, Dec 03, 2015 at 08:33:22PM +0100, Lu Heng wrote: > > Yes, for old folks here, things seems obvious, but I believe we still > need > > to have next generation people here to participate the discussion, if we > do > > not understand where we ware coming from, how we understand the way to > > develop future? > > I do not think that this is particularily relevant here. The status > "we have plenty of IPv4 but need to ensure fairness between different > ISPs' customers" will not come back - and IPv6 is significantly different > that not much can be learned by IPv4's restrictive policies. > > If you have a specific question, you're welcome to ask. > > But generic "what if... and can you remember the good old times?" stuff > are just noise to most of the participants of the list - so, discuss this > at a beer with others who are interested, but not here. > > > As I have explained in my last Email, understanding of some key element > in > > our past policy will help us going future with our current policy > > development. > > Not in this vagueness. > > 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 > -- -- Kind regards. Lu -------------- next part -------------- An HTML attachment was scrubbed... URL: From valentin.panait at ch-center.com Thu Dec 3 21:04:24 2015 From: valentin.panait at ch-center.com (Valentin Panait) Date: Thu, 3 Dec 2015 22:04:24 +0200 Subject: [address-policy-wg] LIRs with good / bad behavior In-Reply-To: <564E37CC.2050301@ch-center.com> References: <564E2DB5.1090308@ch-center.com> <564E3274.5030600@netskin.com> <564E37CC.2050301@ch-center.com> Message-ID: <5660A048.60201@ch-center.com> Hello there, I think this subject is not in anyone interest. I just really don`t know why , but... Is old enough with no reply from anyone. Can i ask an administrator to delete this to make a cleanup on this archive? Best Regards, Valentin Panait -------------- next part -------------- An HTML attachment was scrubbed... URL: From h.lu at anytimechinese.com Thu Dec 3 21:12:44 2015 From: h.lu at anytimechinese.com (Lu Heng) Date: Thu, 3 Dec 2015 21:12:44 +0100 Subject: [address-policy-wg] LIRs with good / bad behavior In-Reply-To: <5660A048.60201@ch-center.com> References: <564E2DB5.1090308@ch-center.com> <564E3274.5030600@netskin.com> <564E37CC.2050301@ch-center.com> <5660A048.60201@ch-center.com> Message-ID: Hi Guys: I don't want to be a*** here, but this is just like the example I have just given... And Valentin: No, you can can not delete or cleanup archive in anyway, the only way is to have legitimate reason(illegal content for example), and send an lawyer letter to RIPE NCC to request take down under EU or Dutch law. On Thu, Dec 3, 2015 at 9:04 PM, Valentin Panait < valentin.panait at ch-center.com> wrote: > Hello there, > > I think this subject is not in anyone interest. > I just really don`t know why , but... > Is old enough with no reply from anyone. > Can i ask an administrator to delete this to make a cleanup on this > archive? > > Best Regards, > Valentin Panait > > -- -- Kind regards. Lu -------------- next part -------------- An HTML attachment was scrubbed... URL: From nick at inex.ie Thu Dec 3 21:16:11 2015 From: nick at inex.ie (Nick Hilliard) Date: Thu, 3 Dec 2015 20:16:11 +0000 Subject: [address-policy-wg] An interesting policy question In-Reply-To: References: <20151203195111.GH89490@Space.Net> Message-ID: <5660A30B.1060806@inex.ie> On 03/12/2015 19:56, Lu Heng wrote: > I am asking a very specific question to an very specific service example > here, the only way to be more specific would be naming people. you're asking a vague question with very few details and expecting a very specific answer. > the only way to be more specific would be naming people. which makes this sound like your email is the subject of an open issue with the RIPE NCC. If this is the case, it would probably be inappropriate to discuss the matter on AP-WG because this mailing list doesn't have the full facts available, nor does it have any mandate to discuss issues which are being handled by the RIPE NCC. In other words, this is the RIPE NCC's business. If you feel that there is a problem with how the RIPE NCC is handling an case, there is a Conflict Arbitration Procedure which allows an independent Arbiters Panel to review any decision that the RIPE NCC has made. Nick From h.lu at anytimechinese.com Thu Dec 3 21:21:55 2015 From: h.lu at anytimechinese.com (Lu Heng) Date: Thu, 3 Dec 2015 21:21:55 +0100 Subject: [address-policy-wg] An interesting policy question In-Reply-To: <5660A30B.1060806@inex.ie> References: <20151203195111.GH89490@Space.Net> <5660A30B.1060806@inex.ie> Message-ID: Hi On Thu, Dec 3, 2015 at 9:16 PM, Nick Hilliard wrote: > On 03/12/2015 19:56, Lu Heng wrote: > > I am asking a very specific question to an very specific service example > > here, the only way to be more specific would be naming people. > > you're asking a vague question with very few details and expecting a very > specific answer. > I've tried to provide more details, and tried my best to ask the specific question, if there is an understanding/language issue, I apologize, but only pointing at me saying I am asking a vague question without future exploring the detail in which I will try my best to explain, does not help any thing really. If a new guy came to ask an dum question, I think the best way is try to understand what he really trying to ask and help to answer it. but not" you are vague we don't understand go away). if that is the case, it really would take genius to join this community because all new guy's question will be dum at some point. > > > the only way to be more specific would be naming people. > > which makes this sound like your email is the subject of an open issue with > the RIPE NCC. > > If this is the case, it would probably be inappropriate to discuss the > matter on AP-WG because this mailing list doesn't have the full facts > available, nor does it have any mandate to discuss issues which are being > handled by the RIPE NCC. In other words, this is the RIPE NCC's business. > > If you feel that there is a problem with how the RIPE NCC is handling an > case, there is a Conflict Arbitration Procedure which allows an independent > Arbiters Panel to review any decision that the RIPE NCC has made. > Simply not true here. > > Nick > -- -- Kind regards. Lu -------------- next part -------------- An HTML attachment was scrubbed... URL: From valentin.panait at ch-center.com Thu Dec 3 21:39:13 2015 From: valentin.panait at ch-center.com (Valentin Panait) Date: Thu, 3 Dec 2015 22:39:13 +0200 Subject: [address-policy-wg] LIRs with good / bad behavior In-Reply-To: References: <564E2DB5.1090308@ch-center.com> <564E3274.5030600@netskin.com> <564E37CC.2050301@ch-center.com> <5660A048.60201@ch-center.com> Message-ID: <5660A871.5090200@ch-center.com> Hello Lu I just talking about another subject "LIRs with good / bad behavior" that i opened some time ago and no one reply to that, not about your subject "An interesting policy question". Best Regards, Valentin Panait On 12/03/2015 10:12 PM, Lu Heng wrote: > Hi Guys: > > I don't want to be a*** here, but this is just like the example I have > just given... > > And Valentin: > > No, you can can not delete or cleanup archive in anyway, the only way > is to have legitimate reason(illegal content for example), and send an > lawyer letter to RIPE NCC to request take down under EU or Dutch law. > > On Thu, Dec 3, 2015 at 9:04 PM, Valentin Panait > > > wrote: > > Hello there, > > I think this subject is not in anyone interest. > I just really don`t know why , but... > Is old enough with no reply from anyone. > Can i ask an administrator to delete this to make a cleanup on > this archive? > > Best Regards, > Valentin Panait > > > > > -- > -- > Kind regards. > Lu > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gert at space.net Thu Dec 3 21:45:54 2015 From: gert at space.net (Gert Doering) Date: Thu, 3 Dec 2015 21:45:54 +0100 Subject: [address-policy-wg] LIRs with good / bad behavior In-Reply-To: <5660A048.60201@ch-center.com> References: <564E2DB5.1090308@ch-center.com> <564E3274.5030600@netskin.com> <564E37CC.2050301@ch-center.com> <5660A048.60201@ch-center.com> Message-ID: <20151203204554.GI89490@Space.Net> Hi, On Thu, Dec 03, 2015 at 10:04:24PM +0200, Valentin Panait wrote: > Can i ask an administrator to delete this to make a cleanup on this > archive? No. The integrity of this is list can not be compromised by removing arbitrary articles from the archives (unless a judge requires the NCC to do so for violation of laws). 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: 811 bytes Desc: not available URL: From h.lu at anytimechinese.com Thu Dec 3 21:47:57 2015 From: h.lu at anytimechinese.com (Lu Heng) Date: Thu, 3 Dec 2015 21:47:57 +0100 Subject: [address-policy-wg] LIRs with good / bad behavior In-Reply-To: <5660A871.5090200@ch-center.com> References: <564E2DB5.1090308@ch-center.com> <564E3274.5030600@netskin.com> <564E37CC.2050301@ch-center.com> <5660A048.60201@ch-center.com> <5660A871.5090200@ch-center.com> Message-ID: Hi Read second part of my email, I was answering your question. On Thursday, 3 December 2015, Valentin Panait wrote: > Hello Lu > > I just talking about another subject "LIRs with good / bad behavior" that > i opened some time ago and no one reply to that, not about your subject "An > interesting policy question". > > Best Regards, > Valentin Panait > > On 12/03/2015 10:12 PM, Lu Heng wrote: > > Hi Guys: > > I don't want to be a*** here, but this is just like the example I have > just given... > > And Valentin: > > No, you can can not delete or cleanup archive in anyway, the only way is > to have legitimate reason(illegal content for example), and send an lawyer > letter to RIPE NCC to request take down under EU or Dutch law. > > > On Thu, Dec 3, 2015 at 9:04 PM, Valentin Panait < > valentin.panait at ch-center.com > > wrote: > >> Hello there, >> >> I think this subject is not in anyone interest. >> I just really don`t know why , but... >> Is old enough with no reply from anyone. >> Can i ask an administrator to delete this to make a cleanup on this >> archive? >> >> Best Regards, >> Valentin Panait >> >> > > > -- > -- > Kind regards. > Lu > > > -- -- Kind regards. Lu -------------- next part -------------- An HTML attachment was scrubbed... URL: From valentin.panait at ch-center.com Thu Dec 3 21:54:27 2015 From: valentin.panait at ch-center.com (Valentin Panait) Date: Thu, 3 Dec 2015 22:54:27 +0200 Subject: [address-policy-wg] LIRs with good / bad behavior In-Reply-To: <20151203204554.GI89490@Space.Net> References: <564E2DB5.1090308@ch-center.com> <564E3274.5030600@netskin.com> <564E37CC.2050301@ch-center.com> <5660A048.60201@ch-center.com> <20151203204554.GI89490@Space.Net> Message-ID: <5660AC03.2020402@ch-center.com> I understand. No probem Best Regards, Valentin Panait On 12/03/2015 10:45 PM, Gert Doering wrote: > Hi, > > On Thu, Dec 03, 2015 at 10:04:24PM +0200, Valentin Panait wrote: >> Can i ask an administrator to delete this to make a cleanup on this >> archive? > No. The integrity of this is list can not be compromised by removing > arbitrary articles from the archives (unless a judge requires the NCC > to do so for violation of laws). > > Gert Doering > -- APWG chair -------------- next part -------------- An HTML attachment was scrubbed... URL: From poty at iiat.ru Fri Dec 4 10:10:41 2015 From: poty at iiat.ru (poty at iiat.ru) Date: Fri, 4 Dec 2015 09:10:41 +0000 Subject: [address-policy-wg] An interesting policy question In-Reply-To: References: Message-ID: <38A326B32984534586F211FB04239BF8561DF49D@Win2008R2.office.iiat> Hello, To answer your question you can look at the obsoleted forms used for ?registering? an assignment. There was no particular points to geographic locations of a network, so relocation the untouched set of assets to another place (or even changing them in the margins of the initial request) did not require a new request/notification. It was the answer to the first question. The second question is more complex. But it seems removing one of the locations did not change the need for the assigned /24, so the answer to the question should be the same as the previous one. Regards, Vladislav Potapov Ru.iiat From: address-policy-wg [mailto:address-policy-wg-bounces at ripe.net] On Behalf Of Lu Heng Sent: Thursday, December 3, 2015 2:27 PM To: address-policy-wg at ripe.net Subject: [address-policy-wg] An interesting policy question Hi I have an policy question regarding Ripe policy before adoption of "no need" policy. We all know that before the no need policy, when Ripe makes an assignment, while the "need" has changed, the assignment become invalid. The question come to what the definition of need. Below I have few examples, please provide your view: First one: Company A provides 100 customer dedicated server service at location A, Ripe makes an assignment for 100 IP for his infrastructure, if, under condition that no other factor was changed, Company A moved his infrastructure to location B, but still providing same service to same customer, does the company's action need to be notified to RIR? And does this action considered invalid the original assignment? Second one: Company A provides web hosting service, but any casted in 3 location, and has provided the evidence of 3 location to the RIR during the time the company getting valid assignment, then A decided to cut 3 location to 2 location, does this invalid original assignment and need to be notified to RIR? So the bottom line is, what is the definition of need, is it defined as the service you are providing or defined as whole package of any of original justification material was provided, if was the later, then does it imply that anything, including location of the infrastructure, upstream providers etc has changed due to operational need, it will be considered as change of purpose of use and need to be notified to RIR? What should be the right interpretation of the policy by then? -- -- Kind regards. Lu -------------- next part -------------- An HTML attachment was scrubbed... URL: From h.lu at anytimechinese.com Fri Dec 4 10:15:09 2015 From: h.lu at anytimechinese.com (Lu Heng) Date: Fri, 4 Dec 2015 10:15:09 +0100 Subject: [address-policy-wg] An interesting policy question In-Reply-To: <38A326B32984534586F211FB04239BF8561DF49D@Win2008R2.office.iiat> References: <38A326B32984534586F211FB04239BF8561DF49D@Win2008R2.office.iiat> Message-ID: Hi Thanks Vladislav for the clear answer. And for the list, this is an answer I would like to receive, clear and easy. The example was very simple so I was expecting an simple answer as well. (I got an feeling that anything I say in the list was wrong, I hope it does not become personal again, I am asking a policy question in a policy discussion mailing list and nothing more than that). On Fri, Dec 4, 2015 at 10:10 AM, wrote: > Hello, > > > > To answer your question you can look at the obsoleted forms used for > ?registering? an assignment. There was no particular points to geographic > locations of a network, so relocation the untouched set of assets to > another place (or even changing them in the margins of the initial request) > did not require a new request/notification. It was the answer to the first > question. > > The second question is more complex. But it seems removing one of the > locations did not change *the need* for the assigned /24, so the answer > to the question should be the same as the previous one. > > > > Regards, > > Vladislav Potapov > > Ru.iiat > > > > *From:* address-policy-wg [mailto:address-policy-wg-bounces at ripe.net] *On > Behalf Of *Lu Heng > *Sent:* Thursday, December 3, 2015 2:27 PM > *To:* address-policy-wg at ripe.net > *Subject:* [address-policy-wg] An interesting policy question > > > > Hi > > > > I have an policy question regarding Ripe policy before adoption of "no > need" policy. > > > > We all know that before the no need policy, when Ripe makes an assignment, > while the "need" has changed, the assignment become invalid. > > > > The question come to what the definition of need. Below I have few > examples, please provide your view: > > > > First one: > > > > Company A provides 100 customer dedicated server service at location A, > Ripe makes an assignment for 100 IP for his infrastructure, if, under > condition that no other factor was changed, Company A moved his > infrastructure to location B, but still providing same service to same > customer, does the company's action need to be notified to RIR? And does > this action considered invalid the original assignment? > > > > Second one: > > > > Company A provides web hosting service, but any casted in 3 location, and > has provided the evidence of 3 location to the RIR during the time the > company getting valid assignment, then A decided to cut 3 location to 2 > location, does this invalid original assignment and need to be notified to > RIR? > > > > So the bottom line is, what is the definition of need, is it defined as > the service you are providing or defined as whole package of any of > original justification material was provided, if was the later, then does > it imply that anything, including location of the infrastructure, upstream > providers etc has changed due to operational need, it will be considered as > change of purpose of use and need to be notified to RIR? > > > > What should be the right interpretation of the policy by then? > > > > -- > > -- > Kind regards. > Lu > -- -- Kind regards. Lu -------------- next part -------------- An HTML attachment was scrubbed... URL: From remco.vanmook at gmail.com Fri Dec 4 10:37:40 2015 From: remco.vanmook at gmail.com (Remco van Mook) Date: Fri, 4 Dec 2015 10:37:40 +0100 Subject: [address-policy-wg] An interesting policy question In-Reply-To: References: <38A326B32984534586F211FB04239BF8561DF49D@Win2008R2.office.iiat> Message-ID: Hi Lu, just to be clear on this - since your question was a hypothetical one about something that might have been policy at some point (but certainly not current policy), your question wasn't strictly a policy question, and could be very well seen as speculative. Given the subject of your question, I can fully understand why people have reservations about this discussion. Kind regards Remco > On 04 Dec 2015, at 10:15 , Lu Heng wrote: > > Hi > > Thanks Vladislav for the clear answer. > > And for the list, this is an answer I would like to receive, clear and easy. > > The example was very simple so I was expecting an simple answer as well. > > (I got an feeling that anything I say in the list was wrong, I hope it does not become personal again, I am asking a policy question in a policy discussion mailing list and nothing more than that). > > On Fri, Dec 4, 2015 at 10:10 AM, > wrote: > Hello, > > > > To answer your question you can look at the obsoleted forms used for ?registering? an assignment. There was no particular points to geographic locations of a network, so relocation the untouched set of assets to another place (or even changing them in the margins of the initial request) did not require a new request/notification. It was the answer to the first question. > > The second question is more complex. But it seems removing one of the locations did not change the need for the assigned /24, so the answer to the question should be the same as the previous one. > > > > Regards, > > Vladislav Potapov > > Ru.iiat > > > > From: address-policy-wg [mailto:address-policy-wg-bounces at ripe.net ] On Behalf Of Lu Heng > Sent: Thursday, December 3, 2015 2:27 PM > To: address-policy-wg at ripe.net > Subject: [address-policy-wg] An interesting policy question > > > > Hi > > > > I have an policy question regarding Ripe policy before adoption of "no need" policy. > > > > We all know that before the no need policy, when Ripe makes an assignment, while the "need" has changed, the assignment become invalid. > > > > The question come to what the definition of need. Below I have few examples, please provide your view: > > > > First one: > > > > Company A provides 100 customer dedicated server service at location A, Ripe makes an assignment for 100 IP for his infrastructure, if, under condition that no other factor was changed, Company A moved his infrastructure to location B, but still providing same service to same customer, does the company's action need to be notified to RIR? And does this action considered invalid the original assignment? > > > > Second one: > > > > Company A provides web hosting service, but any casted in 3 location, and has provided the evidence of 3 location to the RIR during the time the company getting valid assignment, then A decided to cut 3 location to 2 location, does this invalid original assignment and need to be notified to RIR? > > > > So the bottom line is, what is the definition of need, is it defined as the service you are providing or defined as whole package of any of original justification material was provided, if was the later, then does it imply that anything, including location of the infrastructure, upstream providers etc has changed due to operational need, it will be considered as change of purpose of use and need to be notified to RIR? > > > > What should be the right interpretation of the policy by then? > > > > -- > > -- > Kind regards. > Lu > > > > > -- > -- > Kind regards. > Lu > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 842 bytes Desc: Message signed with OpenPGP using GPGMail URL: From h.lu at anytimechinese.com Fri Dec 4 10:42:18 2015 From: h.lu at anytimechinese.com (Lu Heng) Date: Fri, 4 Dec 2015 10:42:18 +0100 Subject: [address-policy-wg] An interesting policy question In-Reply-To: References: <38A326B32984534586F211FB04239BF8561DF49D@Win2008R2.office.iiat> Message-ID: Hi Remco: I can assure you it is not speculative(and I apologise if I give this feeling in any way), it was an pure "academic" discussion about the definition of the *need*. And btw I do believe people are allowed to ask dum question here and the community should help people understand how things work, not everybody can afford to go to RIPE meeting and not everybody can go to training, mailing list remain the cheapest and most effective way still today to help people learning. On Fri, Dec 4, 2015 at 10:37 AM, Remco van Mook wrote: > > > Hi Lu, > > just to be clear on this - since your question was a hypothetical one > about something that might have been policy at some point (but certainly > not current policy), your question wasn't strictly a policy question, and > could be very well seen as speculative. Given the subject of your question, > I can fully understand why people have reservations about this discussion. > > Kind regards > > Remco > > > > On 04 Dec 2015, at 10:15 , Lu Heng wrote: > > Hi > > Thanks Vladislav for the clear answer. > > And for the list, this is an answer I would like to receive, clear and > easy. > > The example was very simple so I was expecting an simple answer as well. > > (I got an feeling that anything I say in the list was wrong, I hope it > does not become personal again, I am asking a policy question in a policy > discussion mailing list and nothing more than that). > > On Fri, Dec 4, 2015 at 10:10 AM, wrote: > >> Hello, >> >> >> >> To answer your question you can look at the obsoleted forms used for >> ?registering? an assignment. There was no particular points to geographic >> locations of a network, so relocation the untouched set of assets to >> another place (or even changing them in the margins of the initial request) >> did not require a new request/notification. It was the answer to the first >> question. >> >> The second question is more complex. But it seems removing one of the >> locations did not change *the need* for the assigned /24, so the answer >> to the question should be the same as the previous one. >> >> >> >> Regards, >> >> Vladislav Potapov >> >> Ru.iiat >> >> >> >> *From:* address-policy-wg [mailto:address-policy-wg-bounces at ripe.net] *On >> Behalf Of *Lu Heng >> *Sent:* Thursday, December 3, 2015 2:27 PM >> *To:* address-policy-wg at ripe.net >> *Subject:* [address-policy-wg] An interesting policy question >> >> >> >> Hi >> >> >> >> I have an policy question regarding Ripe policy before adoption of "no >> need" policy. >> >> >> >> We all know that before the no need policy, when Ripe makes an >> assignment, while the "need" has changed, the assignment become invalid. >> >> >> >> The question come to what the definition of need. Below I have few >> examples, please provide your view: >> >> >> >> First one: >> >> >> >> Company A provides 100 customer dedicated server service at location A, >> Ripe makes an assignment for 100 IP for his infrastructure, if, under >> condition that no other factor was changed, Company A moved his >> infrastructure to location B, but still providing same service to same >> customer, does the company's action need to be notified to RIR? And does >> this action considered invalid the original assignment? >> >> >> >> Second one: >> >> >> >> Company A provides web hosting service, but any casted in 3 location, and >> has provided the evidence of 3 location to the RIR during the time the >> company getting valid assignment, then A decided to cut 3 location to 2 >> location, does this invalid original assignment and need to be notified to >> RIR? >> >> >> >> So the bottom line is, what is the definition of need, is it defined as >> the service you are providing or defined as whole package of any of >> original justification material was provided, if was the later, then does >> it imply that anything, including location of the infrastructure, upstream >> providers etc has changed due to operational need, it will be considered as >> change of purpose of use and need to be notified to RIR? >> >> >> >> What should be the right interpretation of the policy by then? >> >> >> >> -- >> >> -- >> Kind regards. >> Lu >> > > > > -- > -- > Kind regards. > Lu > > > -- -- Kind regards. Lu -------------- next part -------------- An HTML attachment was scrubbed... URL: From sander at steffann.nl Fri Dec 4 10:43:52 2015 From: sander at steffann.nl (Sander Steffann) Date: Fri, 4 Dec 2015 10:43:52 +0100 Subject: [address-policy-wg] An interesting policy question In-Reply-To: References: <38A326B32984534586F211FB04239BF8561DF49D@Win2008R2.office.iiat> Message-ID: Hi Lu, > Thanks Vladislav for the clear answer. > > And for the list, this is an answer I would like to receive, clear and easy. > > The example was very simple so I was expecting an simple answer as well. Glad you are happy with that answer. I just want to state for the record that any answer on this topic given on this mailing list does not represent any official interpretation of the policy and is as such non-authoritative :) Official interpretations are only given in the Impact Analysis of a policy proposal. > (I got an feeling that anything I say in the list was wrong, I hope it does not become personal again, I am asking a policy question in a policy discussion mailing list and nothing more than that). Nothing personal, and both Gert and I have answered your question as well as we could. Things are more complex than this answer shows though. For example changing the geographical location by itself might not make the 'need' invalid, but any changes in who/what the addresses are connected to might etc. These things are determined on a case-by-case basis by the hostmasters/IPRAs. That is why we don't discuss specific cases on the mailing list. A mailing list never has the full data, and speculating what hostmasters would decide would undermine their work. We have an arbitration system for cases where people disagree. Cheers, Sander From h.lu at anytimechinese.com Fri Dec 4 10:50:19 2015 From: h.lu at anytimechinese.com (Lu Heng) Date: Fri, 4 Dec 2015 10:50:19 +0100 Subject: [address-policy-wg] An interesting policy question In-Reply-To: References: <38A326B32984534586F211FB04239BF8561DF49D@Win2008R2.office.iiat> Message-ID: Hi Sander: Thanks for the reply and the discussion was started in one of the RIR meetings, and I am just asking community view(not official in any way of course) of this as part of globe view on the *need*, as it is an shared concept for every RIR. I think I have the answer I wanted here now and I appreciate everyone's input, if any future contribution or disagreement I still welcome of course, if you afraid generate noise in the list you are welcome to email me personally. But one thing I do hope is, don't let people afraid generate noise here in the list, let people ask dum question here, I come across quite few young people that really afraid to say anything in this list, just because they afraid to make mistake...this really isn't the case I hope. On Fri, Dec 4, 2015 at 10:43 AM, Sander Steffann wrote: > Hi Lu, > > > Thanks Vladislav for the clear answer. > > > > And for the list, this is an answer I would like to receive, clear and > easy. > > > > The example was very simple so I was expecting an simple answer as well. > > Glad you are happy with that answer. I just want to state for the record > that any answer on this topic given on this mailing list does not represent > any official interpretation of the policy and is as such non-authoritative > :) Official interpretations are only given in the Impact Analysis of a > policy proposal. > > > (I got an feeling that anything I say in the list was wrong, I hope it > does not become personal again, I am asking a policy question in a policy > discussion mailing list and nothing more than that). > > Nothing personal, and both Gert and I have answered your question as well > as we could. Things are more complex than this answer shows though. For > example changing the geographical location by itself might not make the > 'need' invalid, but any changes in who/what the addresses are connected to > might etc. These things are determined on a case-by-case basis by the > hostmasters/IPRAs. > > That is why we don't discuss specific cases on the mailing list. A mailing > list never has the full data, and speculating what hostmasters would decide > would undermine their work. We have an arbitration system for cases where > people disagree. > > Cheers, > Sander > > -- -- Kind regards. Lu -------------- next part -------------- An HTML attachment was scrubbed... URL: From gert at space.net Fri Dec 4 10:54:06 2015 From: gert at space.net (Gert Doering) Date: Fri, 4 Dec 2015 10:54:06 +0100 Subject: [address-policy-wg] An interesting policy question In-Reply-To: References: <38A326B32984534586F211FB04239BF8561DF49D@Win2008R2.office.iiat> Message-ID: <20151204095406.GL89490@Space.Net> Hi, On Fri, Dec 04, 2015 at 10:42:18AM +0100, Lu Heng wrote: > I can assure you it is not speculative(and I apologise if I give this > feeling in any way), it was an pure "academic" discussion about the > definition of the *need*. > > And btw I do believe people are allowed to ask dum question here and the > community should help people understand how things work, not everybody can > afford to go to RIPE meeting and not everybody can go to training, mailing > list remain the cheapest and most effective way still today to help people > learning. This mailing list has a very specific focus: forming of new policies, and discussion and answering questions about *existing* policies. Historic excursions are *not* on-topic, unless it's relevant for an ongoing policy discussion (which this is not, we'll never return to that state of IPv4 plentiness - which I already told you). 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: 811 bytes Desc: not available URL: From h.lu at anytimechinese.com Fri Dec 4 11:10:51 2015 From: h.lu at anytimechinese.com (Lu Heng) Date: Fri, 4 Dec 2015 11:10:51 +0100 Subject: [address-policy-wg] An interesting policy question In-Reply-To: <20151204095406.GL89490@Space.Net> References: <38A326B32984534586F211FB04239BF8561DF49D@Win2008R2.office.iiat> <20151204095406.GL89490@Space.Net> Message-ID: Hi (This will be my last post in the list about this topic) On Fri, Dec 4, 2015 at 10:54 AM, Gert Doering wrote: > Hi, > > On Fri, Dec 04, 2015 at 10:42:18AM +0100, Lu Heng wrote: > > I can assure you it is not speculative(and I apologise if I give this > > feeling in any way), it was an pure "academic" discussion about the > > definition of the *need*. > > > > And btw I do believe people are allowed to ask dum question here and the > > community should help people understand how things work, not everybody > can > > afford to go to RIPE meeting and not everybody can go to training, > mailing > > list remain the cheapest and most effective way still today to help > people > > learning. > > This mailing list has a very specific focus: forming of new policies, > and discussion and answering questions about *existing* policies. > > Historic excursions are *not* on-topic, unless it's relevant for an > ongoing policy discussion (which this is not, we'll never return to > that state of IPv4 plentiness - which I already told you). > I think I know we won't return to the state of IPv4 plentiness fairly well, really not needed anyone tell me that. But the question was about understanding a long existed concept. If such question, in which I believe I do have certain amount of clue about the policy already, was not even allowed to posted in this list. where else on this planet you can discuss and learn RIPE policy(understand past policy are equally important as understand the current one for one to really understand the policy development process)? Are we really only open doors to the person can afford to go to RIPE meeting every time? I find it is almost impossible to learn RIPE policy and discuss it in the real life, no one knows RIPE, my current amount of knowledge are from my 10 plus Ripe meetings and going to training at my company's cost, in which I believe it will be very hard to apply to every one at my age. we already discuss about aging of the RIPE community, we really really need to allow people to ask dum question here but not kicking off anything the list that you think it is no use(and I appreciate your answer of course). This subject can concluded by one or few answers on the simple matter, it does not need to be that long. The time you spend on arguing with me about relevance, the question is already concluded. And moreover such argument are beyond my question and I am very disappointed I need to spend more time to discuss "can I discuss policy here" rather than to my real question. > 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 > -- -- Kind regards. Lu -------------- next part -------------- An HTML attachment was scrubbed... URL: From leo.vegoda at icann.org Fri Dec 4 16:30:33 2015 From: leo.vegoda at icann.org (Leo Vegoda) Date: Fri, 4 Dec 2015 15:30:33 +0000 Subject: [address-policy-wg] An interesting policy question In-Reply-To: References: <38A326B32984534586F211FB04239BF8561DF49D@Win2008R2.office.iiat> <20151204095406.GL89490@Space.Net> Message-ID: Lu Heng wrote: [...] > If such question, in which I believe I do have certain amount of clue > about the policy already, was not even allowed to posted in this list. > where else on this planet you can discuss and learn RIPE policy > (understand past policy are equally important as understand the current > one for one to really understand the policy development process)? The list you probably wanted was ripe-list at ripe.net: "This mailing list is intended for RIPE-related general announcements and discussions." History and speculation probably fit better on that list than this one. https://www.ripe.net/participate/mail/ripe-mailing-lists/ripe-list Regards, Leo From florz at florz.de Mon Dec 7 03:48:54 2015 From: florz at florz.de (Florian Zumbiehl) Date: Mon, 7 Dec 2015 03:48:54 +0100 Subject: [address-policy-wg] insufficient availability of IPv6 address space for end customers Message-ID: <20151207024854.GJ4819@florz.florz.de> Hi everyone, well ... I don't really know where to start, and my best guess is that this sortof must be an FAQ that has been discussed to death before, but then again, maybe my perspective really is something people aren't quite aware of, so here goes my hypothesis: Providers are psychologically incapable of managing IPv6 address space on their own, and RIPE should do something about it before their inability damages IPv6 beyond repair. Yes, I know what you are thinking ... please, bear with me and let me explain. I recently found myself in the market (in .de) for some tunnel with static addresses for my mail and jabber servers and stuff that I run at home, or some small virtual server that I could use to setup the tunnel myself, with one of the requirements being an IPv6 prefix, /56 at least. And guess what? Of all requirements, the biggest problem is the /56. Of course, there is quite a number of providers that still don't offer IPv6 at all ... well, OK, those are hopeless, I guess. But then, there is a large segment of providers which are either incapable of assigning a /56 or larger, or they offer it at prices that make IPv4 addresses seem like an abundant resource in comparison. Now, there might be real technical limitations in some cases that prevent some providers from assigning (or at least from routing) a large(ish) prefix--but my overall impression is that in most cases, this inability to assign non-minimal prefixes does not have its basis in any real technical causes, and not even in business reasons, but rather in some kind of psychological need to not waste address space, a sort of value judgement that is not to be questioned, and that is very difficult to attack with rational arguments. One provider not only told me essentially that I was crazy for wanting to waste so much address space (a notion that I heard more than once), but even went so far as to tell me that /56 assignments were for providers only as per RIPE policy and the most an end customer could get would be a /64 ... not even providing them with the URI of the RIPE allocation and assignment policy helped, they simply couldn't accept that "wasting so much address space" could be anything but morally repugnant, or at least a completely idiotic idea not worth any further consideration (who knows what they really thought, obviously ...). But even the ones that offered a /56 (or larger) prefix for a monthly or one-time fee mostly seemed like they didn't intentionally design their products with smaller prefixes to then be able to sell the "professional version" at a higher price, but rather simply seem to want to cover their increased costs for dealing with this "special requirement", not realizing that they themselves created this situation where my requirement is not met by the standard product, even though they could have done so at no additonal cost to them by simply always assigning a /56 or /48--or in other words, that they themselves created the overhead that the RIPE policy even warns against, and as a side effect presumably also create incentives for customers who aren't that knowledgable to use broken networking setups because of a lack of addresses or the difficulty of obtaining additional addresses. Yes, not all of those providers are RIPE members, but being a RIPE member with a /32 allocation does not seem to prevent you from "saving address space" by making sure you'll never allocate most of it to customers ever. I guess the problem of ensuring availability of addresses has been discussed before, and I guess possible solutions have been rejected for good reasons, I am not really familiar with the history of this at RIPE, and any pointers to FAQs or canonical ML posts or whatever else might bring insight are welcome ... but what I am wondering about specifically is whether it has been considered so far that providers might be incompetent, possibly to the point of not being able to learn unless forced to, at making sensible IPv6 assignments? Should providers be required to always assign at least a /56 unless they can show good technical reasons why that would cause harm? Well, I can see a ton of problems with that approach (How do you enforce that? Does it hurt competent providers? Does it hinder valid business models?), but my impression is that the policy so far assumes that providers make competent decisions, only providing non-binding recommendations regarding minimum allocation sizes, which obviously is completely ignored by providers that are caught up in the address saving mindset of IPv4, leading them to make bad decisions both for themselves and for the long term development of the IPv6 internet (and yes, I found one provider that admitted just that, they told me they were currently overhauling their product offerings and intended to change the standard assignment size in the future, as they had recognized /64 assignments to be a mistake that had happened because they felt they needed to save addresses). How about applying the HD ratio based on the smallest end-site allocation that exists within a provider's prefix (as in: if you assign /64, you only get a /40 unless you can show you have more than ~ 200k /64 assigned)? Maybe even punish small prefixes? If a provider assigns a /64, apply a higher HD ratio? Somehow make it expensive for providers to hoard addresses ... just making it cheap to assign sufficient address space doesn't seem to provide sufficient motivation, so maybe making it expensive to do the wrong thing is what's required? Well, any suggestions welcome (or any arguments why I am an idiot, or maybe just mistaken), also with regards to processes and mechanisms available at RIPE that might help with fixing this problem ... I'll stop here for now ;-) (Oh, and if you feel like you can offer what I am (still) looking for, feel free to drop me an email--but be warned that I don't really intend to spend much money on it, though I'd think it should be easily earned if you have the infrastructure in place, I don't need much traffic and I know to help myself as long as you keep your end of things running ... but that's not really a topic for further discussion on this list, I guess ...) Regards, Florian From David.Huberman at microsoft.com Mon Dec 7 04:14:58 2015 From: David.Huberman at microsoft.com (David Huberman) Date: Mon, 7 Dec 2015 03:14:58 +0000 Subject: [address-policy-wg] insufficient availability of IPv6 address space for end customers In-Reply-To: <20151207024854.GJ4819@florz.florz.de> References: <20151207024854.GJ4819@florz.florz.de> Message-ID: Hi Florian, I understand you feel the IPv6 addressing architecture of a few ISPs you are dealing with is so poor that you cannot stand by silently. I'll assume you have made attempts to meaningfully (and without emotion) exchange ideas with them. You've now come to this list to paint them with a broad brush. So in this case, I think you should name names. What are the names of the ISPs you are dealing with who are managing their IPv6 product so poorly that you think ALL of RIPE's providers should be subject to more regulation from the NCC? By naming them, perhaps representatives here will see your plea, and perhaps members of the Address Policy WG can intercede on your behalf or have engineer-to-engineer discussions with them. Even now in late 2015, I believe IPv6 is still very greenfield. Network operators are still figuring out how to best do things; how to best architect IPv6 offerings in a way that balances their needs with their customers' needs. More regulation from the NCC is, in my opinion, many years premature. David R Huberman Principal, Global IP Addressing Microsoft Corporation > -----Original Message----- > From: address-policy-wg [mailto:address-policy-wg-bounces at ripe.net] On > Behalf Of Florian Zumbiehl > Sent: Sunday, December 6, 2015 6:49 PM > To: address-policy-wg at ripe.net > Subject: [address-policy-wg] insufficient availability of IPv6 address space for > end customers > > Hi everyone, > > well ... I don't really know where to start, and my best guess is that this sortof > must be an FAQ that has been discussed to death before, but then again, > maybe my perspective really is something people aren't quite aware of, so > here goes my hypothesis: > > Providers are psychologically incapable of managing IPv6 address space on > their own, and RIPE should do something about it before their inability > damages IPv6 beyond repair. > > Yes, I know what you are thinking ... please, bear with me and let me explain. > > I recently found myself in the market (in .de) for some tunnel with static > addresses for my mail and jabber servers and stuff that I run at home, or > some small virtual server that I could use to setup the tunnel myself, with > one of the requirements being an IPv6 prefix, /56 at least. > > And guess what? Of all requirements, the biggest problem is the /56. Of > course, there is quite a number of providers that still don't offer IPv6 at all ... > well, OK, those are hopeless, I guess. > > But then, there is a large segment of providers which are either incapable of > assigning a /56 or larger, or they offer it at prices that make IPv4 addresses > seem like an abundant resource in comparison. Now, there might be real > technical limitations in some cases that prevent some providers from > assigning (or at least from routing) a large(ish) prefix--but my overall > impression is that in most cases, this inability to assign non-minimal prefixes > does not have its basis in any real technical causes, and not even in business > reasons, but rather in some kind of psychological need to not waste address > space, a sort of value judgement that is not to be questioned, and that is > very difficult to attack with rational arguments. > > One provider not only told me essentially that I was crazy for wanting to > waste so much address space (a notion that I heard more than once), but > even went so far as to tell me that /56 assignments were for providers only > as per RIPE policy and the most an end customer could get would be a /64 ... > not even providing them with the URI of the RIPE allocation and assignment > policy helped, they simply couldn't accept that "wasting so much address > space" could be anything but morally repugnant, or at least a completely > idiotic idea not worth any further consideration (who knows what they really > thought, obviously ...). > > But even the ones that offered a /56 (or larger) prefix for a monthly or one- > time fee mostly seemed like they didn't intentionally design their products > with smaller prefixes to then be able to sell the "professional version" at a > higher price, but rather simply seem to want to cover their increased costs > for dealing with this "special requirement", not realizing that they > themselves created this situation where my requirement is not met by the > standard product, even though they could have done so at no additonal cost > to them by simply always assigning a /56 or /48--or in other words, that they > themselves created the overhead that the RIPE policy even warns against, > and as a side effect presumably also create incentives for customers who > aren't that knowledgable to use broken networking setups because of a lack > of addresses or the difficulty of obtaining additional addresses. > > Yes, not all of those providers are RIPE members, but being a RIPE member > with a /32 allocation does not seem to prevent you from "saving address > space" by making sure you'll never allocate most of it to customers ever. > > I guess the problem of ensuring availability of addresses has been discussed > before, and I guess possible solutions have been rejected for good reasons, I > am not really familiar with the history of this at RIPE, and any pointers to > FAQs or canonical ML posts or whatever else might bring insight are welcome > ... but what I am wondering about specifically is whether it has been > considered so far that providers might be incompetent, possibly to the point > of not being able to learn unless forced to, at making sensible IPv6 > assignments? > > Should providers be required to always assign at least a /56 unless they can > show good technical reasons why that would cause harm? Well, I can see a > ton of problems with that approach (How do you enforce that? Does it hurt > competent providers? Does it hinder valid business models?), but my > impression is that the policy so far assumes that providers make competent > decisions, only providing non-binding recommendations regarding minimum > allocation sizes, which obviously is completely ignored by providers that are > caught up in the address saving mindset of IPv4, leading them to make bad > decisions both for themselves and for the long term development of the > IPv6 internet (and yes, I found one provider that admitted just that, they told > me they were currently overhauling their product offerings and intended to > change the standard assignment size in the future, as they had recognized > /64 assignments to be a mistake that had happened because they felt they > needed to save addresses). > > How about applying the HD ratio based on the smallest end-site allocation > that exists within a provider's prefix (as in: if you assign /64, you only get a > /40 unless you can show you have more than ~ 200k /64 assigned)? > Maybe even punish small prefixes? If a provider assigns a /64, apply a higher > HD ratio? Somehow make it expensive for providers to hoard addresses ... > just making it cheap to assign sufficient address space doesn't seem to > provide sufficient motivation, so maybe making it expensive to do the wrong > thing is what's required? > > Well, any suggestions welcome (or any arguments why I am an idiot, or > maybe just mistaken), also with regards to processes and mechanisms > available at RIPE that might help with fixing this problem ... I'll stop here for > now > ;-) > > (Oh, and if you feel like you can offer what I am (still) looking for, feel free to > drop me an email--but be warned that I don't really intend to spend much > money on it, though I'd think it should be easily earned if you have the > infrastructure in place, I don't need much traffic and I know to help myself as > long as you keep your end of things running ... but that's not really a topic for > further discussion on this list, I guess ...) > > Regards, Florian From florz at florz.de Mon Dec 7 05:35:20 2015 From: florz at florz.de (Florian Zumbiehl) Date: Mon, 7 Dec 2015 05:35:20 +0100 Subject: [address-policy-wg] insufficient availability of IPv6 address space for end customers In-Reply-To: References: <20151207024854.GJ4819@florz.florz.de> Message-ID: <20151207043520.GA12620@florz.florz.de> Hi, > I understand you feel the IPv6 addressing architecture of a few ISPs you are dealing with is so poor that you cannot stand by silently. I'll assume you have made attempts to meaningfully (and without emotion) exchange ideas with them. You've now come to this list to paint them with a broad brush. So in this case, I think you should name names. What are the names of the ISPs you are dealing with who are managing their IPv6 product so poorly that you think ALL of RIPE's providers should be subject to more regulation from the NCC? By naming them, perhaps representatives here will see your plea, and perhaps members of the Address Policy WG can intercede on your behalf or have engineer-to-engineer discussions with them. Well ... for one, if it had been one or two providers, I probably wouldn't have felt the need to do anything about it, there always are some bad products on the market, and the best way to deal with them is to simply not buy them. It seems to me like this is a systemic problem, given how many providers seem to be affected by it. Now, no, I didn't try to "exchange ideas" with all of them, that would simply have been too much work, but I did with quite a few, and my impressions come from what they said plus the content of the offers (or non-offers) from the others. Also, maybe I should stress that when I wrote that many providers seem "incompetent" or "psychologically incapable", that is not meant as an insult, but as a rather neutral description of the problem: They don't understand the tradeoffs in address allocation, but instead only react on an emotional level to the idea of assigning "so many addresses!", or at least that is my interpretation of the behaviour I observed--while RIPE documents seem to assume that people try to rationally understand address allocation/assignment. However, I do not necessarily think that more regulation is the way to go (really, IMO that should be the last resort if nothing else helps), and if more regulation is the way to go, I guess it should be put together in such a way that the impact on competent providers is as close to zero as possible ... Things are further complicated by the fact that many of the providers probably aren't RIPE members themselves (I don't really know, not all RIPE members do advertise it prominently ...). > Even now in late 2015, I believe IPv6 is still very greenfield. Network operators are still figuring out how to best do things; how to best architect IPv6 offerings in a way that balances their needs with their customers' needs. More regulation from the NCC is, in my opinion, many years premature. Well ... I am not sure whether that is funny or just sad, given that I've had native IPv6 connectivity for the last 10 years, with a /48 prefix, from a competent provider (yes, they do exist, obviously!), which now needs replacement (for reasons unrelated to the provider or their competence). Regards, Florian From garry at nethinks.com Mon Dec 7 09:02:34 2015 From: garry at nethinks.com (Garry Glendown) Date: Mon, 7 Dec 2015 09:02:34 +0100 Subject: [address-policy-wg] insufficient availability of IPv6 address space for end customers In-Reply-To: <20151207024854.GJ4819@florz.florz.de> References: <20151207024854.GJ4819@florz.florz.de> Message-ID: <56653D1A.2030705@nethinks.com> Florian, I believe the problem is twofold - the usual hen-and-egg-problem. On the one hand, many (especially larger) providers have been slow to adopt v6 in their networks. Partly due to the technical requirements (which, if you want to do it right, will cost them more man-power and real money (tm) than for a small ISP that only has a hand full of routers to take care of), but also due to business case - barely anybody actually wants or needs v6 at the moment. Which is "the other hand". With barely anybody requesting v6 - even if it is available - there is no pressure. e.g., we've had v6 since the 6bone-days, applied for and received and activated our /32 when it became available at RIPE, and to this day had 3 (!) actual requests for v6 throughout our customer base. And that even though we actively promoted v6 use through our newsletter, explained how easy it is to use, etc. Apart from those 3 users, we also have a couple more that have active v6 "by accident", because their DSL CE routers just request and receive their addresses (btw, for dynamic dialup without fixed configuration, we use a /64 ... which IMHO is sufficient for the "everyday" user who only cares about having reliant Internet access) - which is, btw, another 7 connections at the moment. None of our leased line customers could be convinced to set up their v6 connectivity, though at least one reserved his PI network once RIPE made PIv6 available. Not active, though. In essence, then, where do we stand? Sure, more and more providers in the net set up their v6. For probably 95% (or more) of the customers, v6 isn't an issue. And they couldn't care less. They want internet. If it's transported via v4 or v6 isn't their concern. They just want their Facebook, WhatsApp, etc. to work. On the provider side, the lack of actual interest in v6 makes the business-side of the decision easy - v6 won't make them a single buck more, rather it will cost them money in the short run. For ISPs smart (or stupid?) enough to invest time and money now, it is somewhat depressing - knowing you have all those shiny, new, untainted v6 addresses, and nobody wants them. And you can't even recuperate the cost for the additional service. At least not in a market where most customers just want to pay as little as they can for the service they want. Which gets me to my final point: > free to drop me an email--but be warned that I don't really intend to spend > much money on it, though I'd think it should be easily earned if you have > the infrastructure in place, I don't need much traffic and I know to help Service costs money. In our case, we're a (mostly/almost exclusively) business provider, setting up business networks utilizing all sorts of lines (apart from Voice services and network monitoring consulting). We don't have the numbers to cover all of Telekom's OVSt's with our equipment in order to get the end customers' lines at some (perceived) low prices, we have to get the service indirectly from Telekom. Which means we will never be able to compete with the dumping price wars that large providers like Telekom or the cable companies have. Instead, we provide SERVICE to our customer. You can reach a tech person usually relatively quickly (and not some first level drone at a call center without any real technical knowledge and ability), we allow for custom setups for all our lines, and we try to keep up to date with technical development. In turn, all of this does one thing: it costs us money. Not v6 specifically (which I see as part of doing business without the danger of being pushed out of business some time down the road), but the whole package. Most of the additional cost is earned with the high-end products and services for leased lines, but we still need to make some of it from our "low-end" DSL services, which means we will be more expensive than your 1&1, Congstar or whoever the dumping-ISP of your choice may be (* just in case - no, we are even . So just as in "physical" life, where a cheap Fiat may (well, rather "will") not include all of the amenities of a Beamer or Merc, you will need to put your money where your mouth (and your requirements) are. (Side note: and no, even with our service we're by far not as expensive as the "premium" product of your current provider, but we can't compete with his "flex" product ... so if the latter is your desired rate, don't even look at our page - but don't complain that you don't receive the professional services you would like to get) -garry From florz at florz.de Mon Dec 7 18:55:55 2015 From: florz at florz.de (Florian Zumbiehl) Date: Mon, 7 Dec 2015 18:55:55 +0100 Subject: [address-policy-wg] insufficient availability of IPv6 address space for end customers In-Reply-To: <56653D1A.2030705@nethinks.com> References: <20151207024854.GJ4819@florz.florz.de> <56653D1A.2030705@nethinks.com> Message-ID: <20151207175555.GA5017@florz.florz.de> Hi, > I believe the problem is twofold - the usual hen-and-egg-problem. On the > one hand, many (especially larger) providers have been slow to adopt v6 > in their networks. Partly due to the technical requirements (which, if > you want to do it right, will cost them more man-power and real money > (tm) than for a small ISP that only has a hand full of routers to take > care of), but also due to business case - barely anybody actually wants > or needs v6 at the moment. Which is "the other hand". With barely I'd tend to disagree: Everyone _needs_ IPv6, people just don't realize it. I mean, just look at how much overhead the lack of IPv4 addresses generates every day (both in the form of management overhead due to having to deal with getting addresses assigned from RIPE/ISPs, but even more due to the grotesque workarounds that are deployed everywhere to make due with IPv4, like private address ranges, which tend to collide all the time if you try to connect previously separate networks, and NAT, and all the easy solutions to problems that NAT prevents from working, ...)--all of that cost would simply vanish once everyone has switched to IPv6, but people simply aren't aware, because they think that private addresses inside your network plus NAT just is how the internet works, they have no idea what costs sticking with IPv4 is causing, so they don't want it, even though they very much need it. > anybody requesting v6 - even if it is available - there is no pressure. > e.g., we've had v6 since the 6bone-days, applied for and received and > activated our /32 when it became available at RIPE, and to this day had > 3 (!) actual requests for v6 throughout our customer base. And that even > though we actively promoted v6 use through our newsletter, explained how > easy it is to use, etc. Apart from those 3 users, we also have a couple > more that have active v6 "by accident", because their DSL CE routers Given that IPv6 should in the end be easier for ISPs as well: Have you considered offering IPv6 only connectivity at a lower price? > just request and receive their addresses (btw, for dynamic dialup > without fixed configuration, we use a /64 ... which IMHO is sufficient > for the "everyday" user who only cares about having reliant Internet > access) - which is, btw, another 7 connections at the moment. I think you are wrong here, I think you are making exactly the mistake that I am trying to point out providers tend to make. Your mistake is that you think that "it's sufficient" is a good reason. It's not. It's a really, really bad reason. It was a good reason with IPv4, but with IPv6 this approach to justifying assignment sizes is counterproductive. You are (correct me if I am wrong) not looking at the full tradeoff. What would the cost increase be for you if you assigned /56 prefixes by default? Zero, right? You have to make an initial assignment anyway, and /64 or /56 makes no difference in the effort required, and you still would have space for ~ 16 million customers, so no real risk of running out of addresses either, and even if you did, as per RIPE policy you could obtain a /29 without even providing any documentation, and once you have connected a further ~ 120 million customers, it still should be relatively easy to obtain space for another ~ 134 million customers, with no additional fees to pay (yes, I know that you cannot really fit 134 million customers into a /29 with a reasonable wide-area routing setup, but the RIPE policy does use an HD ratio < 1, obviously). What would the (negative) externalities be if you assigned a /56 by default? Also zero--the only potential externality would be that others might end up without addresses when they need them because you assigned too much, but there is no risk of running out of addresses even with /48 prefixes per customer, not even if earth's population increases ten-fold and every single person got assigned /48 prefixes from 10 different providers, even then only about a quarter of one percent of the available address space would be assigned, and think about how realistic that scenario is, and then divide the risk by another 256 if you use /56 prefixes instead. So, we do agree that there would be no cost, no negative consequences to assigning /56 prefixes by default, right? Now, let's look at the other side of the equation: You can be pretty sure one in a million customers (once they use IPv6) might want to use more than one LAN. Now, what are their options? Well, they could not use SLAAC. Great! Or they could just forget about the idea. Or they could request assignment of additional addresses. Either way, you have just created costs, be it in the form of lowered convenience or the need to request addresses, the need for you to process that request, the added complexity of managing this special case, probably the need to renumber the customer's network, the delay until the addresses have been assigned ... all of which also acts as an incentive to choose technically inferior solutions to avoid this overhead. Or imagine a CPE manufacturer that considers the idea of creating a product that would need multiple subnets to achieve some functionality ... if selling the product means convincing potential customers that they would have to negotiate address assignment with their providers, they'll probably simple scrap the idea. All of that for what? There is no upside to it, only downsides. And I mean _NO_ upside, not even minimal, marginal, potential upside, none. Why do you still think that it's a good idea to assign a /64? Do you have any actual reason _against_ assigning at least a /56 by default? I would really be interested to hear if you have--my guess is that you don't and that it's an unconcious bias in favour of saving addresses no matter what because that is the right thing to do with IPv4, and that's what I suspect is at work at all those providers that assign /64 prefixes (or even smaller) by default. People have to be taught now that saving addresses is actively _BAD_, that it's causing harm, that it is to be avoided if possible, just as assigning an IPv4 /24 to every dialup customer is to be avoided, just for entirely different reasons. > In essence, then, where do we stand? Sure, more and more providers in > the net set up their v6. For probably 95% (or more) of the customers, v6 > isn't an issue. And they couldn't care less. They want internet. If it's > transported via v4 or v6 isn't their concern. They just want their > Facebook, WhatsApp, etc. to work. Well, yeah, that is a problem, but I don't think it's in any way an argument for a bad address assignment policy. > On the provider side, the lack of actual interest in v6 makes the > business-side of the decision easy - v6 won't make them a single buck > more, rather it will cost them money in the short run. Well, yeah, the advantages are only to be had in the long run, obviously - however, how long that "long run" is away and how much you spend on maintaining a harder and harder to maintain ipv4 network very much depends on when you (and everyone else, unfortunately) make these investments. > For ISPs smart (or stupid?) enough to invest time and money now, it is > somewhat depressing - knowing you have all those shiny, new, untainted > v6 addresses, and nobody wants them. And you can't even recuperate the > cost for the additional service. At least not in a market where most > customers just want to pay as little as they can for the service they > want. Which gets me to my final point: Well, I am looking for a provider that will also provide IPv6 precisely because I want to support those who have made the effort instead of paying one that hasn't and then getting a free v6 tunnel, but that has turned out to be far more difficult than expected. > Service costs money. In our case, we're a (mostly/almost exclusively) Which I totally understand, but ... I don't need any service? I don't need anything that should be special. I don't need anything that should cause any costs beyond the cost for a standard product that should be possible to run at a large scale, and I don't need any help with setting up my side of things. > business provider, setting up business networks utilizing all sorts of > lines (apart from Voice services and network monitoring consulting). We > don't have the numbers to cover all of Telekom's OVSt's with our > equipment in order to get the end customers' lines at some (perceived) > low prices, we have to get the service indirectly from Telekom. Which > means we will never be able to compete with the dumping price wars that > large providers like Telekom or the cable companies have. Instead, we Which is part of why I am looking for a tunnel or virtual server to set up the tunnel myself (and no, I don't care about DTAG peering, in case you are wondering, that's DTAG's problem). > provide SERVICE to our customer. You can reach a tech person usually > relatively quickly (and not some first level drone at a call center > without any real technical knowledge and ability), we allow for custom > setups for all our lines, and we try to keep up to date with technical > development. In turn, all of this does one thing: it costs us money. Not > v6 specifically (which I see as part of doing business without the > danger of being pushed out of business some time down the road), but the > whole package. Most of the additional cost is earned with the high-end > products and services for leased lines, but we still need to make some > of it from our "low-end" DSL services, which means we will be more > expensive than your 1&1, Congstar or whoever the dumping-ISP of your > choice may be (* just in case - no, we are even . So just as in > "physical" life, where a cheap Fiat may (well, rather "will") not > include all of the amenities of a Beamer or Merc, you will need to put > your money where your mouth (and your requirements) are. I can see all of that, but I really don't need service nor do I need a custom setup. Yes, I need that you fix things when they break on your side (and if you have installed call center drones who can't handle a competent caller, thus preventing you from fixing your problems, that's a cost factor for you, not for me, as it's wasting your resources, not mine (if I call, it's probably because you are at fault, and you won't be able to avoid fixing your problem other than by getting rid of me as a customer), and more than likely will make you lose me as a customer), and I also don't mind paying extra for additional effort - but assigning a /56 by default shouldn't be any additional effort. > (Side note: and no, even with our service we're by far not as expensive > as the "premium" product of your current provider, but we can't compete > with his "flex" product ... so if the latter is your desired rate, don't > even look at our page - but don't complain that you don't receive the > professional services you would like to get) Well, you might have overlooked that no traffic price is specified in that table ;-) But no, I don't have any of the products currently listed on their website (it's access over T-DSL, which I had running with multiple PPPoE sessions until DTAG recently decided that that's a feature that they should switch off without warning, and haven't been able to re-activate (see call center drones above, and that despite the not quite dumping price of that line), which is also why I am looking to replace it now). Regards, Florian From richih.mailinglist at gmail.com Mon Dec 7 20:06:36 2015 From: richih.mailinglist at gmail.com (Richard Hartmann) Date: Mon, 7 Dec 2015 20:06:36 +0100 Subject: [address-policy-wg] insufficient availability of IPv6 address space for end customers In-Reply-To: <20151207024854.GJ4819@florz.florz.de> References: <20151207024854.GJ4819@florz.florz.de> Message-ID: To answer your question: No, I do not see a need for stronger regulations in this area. Richard Sent by mobile; excuse my brevity. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ebais at a2b-internet.com Tue Dec 8 10:14:45 2015 From: ebais at a2b-internet.com (Erik Bais) Date: Tue, 8 Dec 2015 10:14:45 +0100 Subject: [address-policy-wg] Update on the policy proposal : Message-ID: <005901d13198$e7209fc0$b561df40$@a2b-internet.com> Hi, As discussed in the AP-WG meeting in Bucharest, we needed to make some changes in the policy text. https://www.ripe.net/participate/policies/proposals/2015-04 The new proposal version will have the following text: 2.0 Transfers within the RIPE NCC Service Region Any legitimate resource holder is allowed to transfer complete or partial blocks of address space or number resources (IPv4, IPv6 and AS Numbers) that were previously allocated or assigned to them by the RIPE NCC or otherwise through the Regional Internet Registry (RIR) system. Resources are excluded from transfers when RIPE Policies mandate their return to the RIPE NCC. Allocated resources may only be transferred to another RIPE NCC member. Provider independent resources may be transferred to: * A RIPE NCC member; or * An entity that has a contractual relationship with a RIPE NCC member in accordance with the RIPE Policy, ?Contractual Requirements for Provider Independent Resource Holders in the RIPE NCC Service Region?. I would like to ask the community to review the text and provide feedback on it. We will upload the new version soon. Regards, Erik Bais -------------- next part -------------- An HTML attachment was scrubbed... URL: