2013-05 New Policy Proposal (No Restrictions on End User Assignments in Intra-RIR Transfers)
Dear Colleagues, A proposed change to RIPE Policy Document ripe-592, "IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region", is now available for discussion. You can find the full proposal at: https://www.ripe.net/ripe/policies/proposals/2013-05/ We encourage you to review this proposal and send your comments to <address-policy-wg@ripe.net> before 19 August 2013. Regards Emilio Madaio Policy Development Officer RIPE NCC
Dear AP WG, in the heated discussion about 2013-03 ("no need"), I think this proposal might have escaped your attention. On Mon, Jul 22, 2013 at 03:08:26PM +0200, Emilio Madaio wrote:
A proposed change to RIPE Policy Document ripe-592, "IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region", is now available for discussion.
You can find the full proposal at:
This is an amendment to the transfer policy which solves real-world problems for real-world LIRs - namely: abandon the requirement that a transferred block of addresses must be empty, because that conflicts with real-world scenarios, like a customer of a given LIR opening his own LIR later on, both parties agree to transfer the addresses the customer uses to the new LIR (= the customer's LIR of the customer using the addresses already), and the NCC then tells them "no, you can't do that". The proposal is in *discussion* phase, so if you want to discuss, now is the time. (If you just "+1" it, that's also a clear signal :-) ). regards, 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 (89) 32356-444 USt-IdNr.: DE813185279
On 16/08/2013 15:14, Gert Doering wrote:
Dear AP WG,
in the heated discussion about 2013-03 ("no need"), I think this proposal might have escaped your attention.
On Mon, Jul 22, 2013 at 03:08:26PM +0200, Emilio Madaio wrote:
A proposed change to RIPE Policy Document ripe-592, "IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region", is now available for discussion.
You can find the full proposal at:
This is an amendment to the transfer policy which solves real-world problems for real-world LIRs - namely: abandon the requirement that a transferred block of addresses must be empty, because that conflicts with real-world scenarios, like a customer of a given LIR opening his own LIR later on, both parties agree to transfer the addresses the customer uses to the new LIR (= the customer's LIR of the customer using the addresses already), and the NCC then tells them "no, you can't do that".
The proposal is in *discussion* phase, so if you want to discuss, now is the time. (If you just "+1" it, that's also a clear signal :-) ).
I think this is actually quite sensible, so +1 Nigel
On 16 Aug 2013, at 15:18, Nigel Titley wrote:
On 16/08/2013 15:14, Gert Doering wrote:
This is an amendment to the transfer policy which solves real-world problems for real-world LIRs - namely: abandon the requirement that a transferred block of addresses must be empty, because that conflicts with real-world scenarios, like a customer of a given LIR opening his own LIR later on, both parties agree to transfer the addresses the customer uses to the new LIR (= the customer's LIR of the customer using the addresses already), and the NCC then tells them "no, you can't do that".
The proposal is in *discussion* phase, so if you want to discuss, now is the time. (If you just "+1" it, that's also a clear signal :-) ).
I think this is actually quite sensible, so +1
+1 from me too /Niall
On 16.08.2013 4:18 PM, Nigel Titley wrote:
The proposal is in *discussion* phase, so if you want to discuss, now is the time. (If you just "+1" it, that's also a clear signal :-) ).
I think this is actually quite sensible, so +1
+1 -tim
On 8/16/13 09:14 , Gert Doering wrote:
Dear AP WG,
in the heated discussion about 2013-03 ("no need"), I think this proposal might have escaped your attention.
On Mon, Jul 22, 2013 at 03:08:26PM +0200, Emilio Madaio wrote:
A proposed change to RIPE Policy Document ripe-592, "IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region", is now available for discussion.
You can find the full proposal at:
This is an amendment to the transfer policy which solves real-world problems for real-world LIRs - namely: abandon the requirement that a transferred block of addresses must be empty, because that conflicts with real-world scenarios, like a customer of a given LIR opening his own LIR later on, both parties agree to transfer the addresses the customer uses to the new LIR (= the customer's LIR of the customer using the addresses already), and the NCC then tells them "no, you can't do that".
The proposal is in *discussion* phase, so if you want to discuss, now is the time. (If you just "+1" it, that's also a clear signal :-) ).
regards,
Gert Doering, APWG chair
I support the intent of the proposal, there are situations where it seems reasonable to allow transfers of blocks with end users in them, and the current blanket exclusion prevents this. However, I also support the original intent of the language that would be removed. I believe the intent of the original language was to prevent an LIR selling off a block that has active End Users in it, at least without notice or consent, etc... For the example case given in the proposal, it seems that consent should be readily obtainable. So, would a better solution be to add "without consent of the End User(s)" to the current text. This provides flexibility without abandoning the protection the current text provides to End Users. Thanks. -- ================================================ David Farmer Email: farmer@umn.edu Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 1-612-626-0815 Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 ================================================
David, thanks for your comments. On Fri, 16 Aug 2013, David Farmer wrote:
in the heated discussion about 2013-03 ("no need"), I think this proposal might have escaped your attention.
On Mon, Jul 22, 2013 at 03:08:26PM +0200, Emilio Madaio wrote:
A proposed change to RIPE Policy Document ripe-592, "IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region", is now available for discussion.
You can find the full proposal at:
This is an amendment to the transfer policy which solves real-world problems for real-world LIRs - namely: abandon the requirement that a transferred block of addresses must be empty, because that conflicts with real-world scenarios, like a customer of a given LIR opening his own LIR later on, both parties agree to transfer the addresses the customer uses to the new LIR (= the customer's LIR of the customer using the addresses already), and the NCC then tells them "no, you can't do that".
The proposal is in *discussion* phase, so if you want to discuss, now is the time. (If you just "+1" it, that's also a clear signal :-) ).
regards,
Gert Doering, APWG chair
I support the intent of the proposal, there are situations where it seems reasonable to allow transfers of blocks with end users in them, and the current blanket exclusion prevents this.
However, I also support the original intent of the language that would be removed. I believe the intent of the original language was to prevent an LIR selling off a block that has active End Users in it, at least without notice or consent, etc...
For the example case given in the proposal, it seems that consent should be readily obtainable. So, would a better solution be to add "without consent of the End User(s)" to the current text. This provides flexibility without abandoning the protection the current text provides to End Users.
In the rationale I used this expressions: "... it should be possible to transfer a continuous block from one LIR into an allocation and correct assignments of the new LIR while preserving the assignments." - I wanted to make clear that the new LIR would of course inherit End-User assignments and also the responsibilities for them. You think the End-Users should get involved into a planned transfer of an allocation to a new LIR? It might not be realistic to ask hundreds of End-Users for permission to transfer an allocation. Is that what you were suggesting? Thanks Sascha -- Sascha E. Pollok E-Mail: sp@iphh.net Manager Network Design and Operations Tel: +49 (0)40 374919-10 IPHH Internet Port Hamburg GmbH Fax: +49 (0)40 374919-29 Wendenstrasse 408 AG Hamburg, HRB 76071 20537 Hamburg, Germany CEO: Axel G. Kroeger
On 8/16/13 16:13 , Sascha E. Pollok wrote:
David, thanks for your comments.
On Fri, 16 Aug 2013, David Farmer wrote:
I support the intent of the proposal, there are situations where it seems reasonable to allow transfers of blocks with end users in them, and the current blanket exclusion prevents this.
However, I also support the original intent of the language that would be removed. I believe the intent of the original language was to prevent an LIR selling off a block that has active End Users in it, at least without notice or consent, etc...
For the example case given in the proposal, it seems that consent should be readily obtainable. So, would a better solution be to add "without consent of the End User(s)" to the current text. This provides flexibility without abandoning the protection the current text provides to End Users.
In the rationale I used this expressions:
"... it should be possible to transfer a continuous block from one LIR into an allocation and correct assignments of the new LIR while preserving the assignments." - I wanted to make clear that the new LIR would of course inherit End-User assignments and also the responsibilities for them.
The whole sentence in the rationale was; In case a new LIR is created by a company that is currently using PA space from an existing LIR, it should be possible to transfer a continuous block from one LIR into an allocation and correct assignments of the new LIR while preserving the assignments. I think the first part adds significant context. I interpreted the transfer in question was to an organization that was previously assigned the block as an end user and is now the new LIR in question. I was simply saying in the use case presented "consent should be readily obtainable." In my opinion this use case provides clear justification for a transfer with the assignments in tact, but doesn't necessarily justify abandoning the original intent of the language, it can be accommodated without such a radical change.
You think the End-Users should get involved into a planned transfer of an allocation to a new LIR? It might not be realistic to ask hundreds of End-Users for permission to transfer an allocation. Is that what you were suggesting?
The specific use case provided in the rationale, as I interpret it, doesn't involve hundreds of End Users. Maybe I misunderstand or misinterpreted the use case. If there are other cases you want to cover maybe include some of the other use cases in the rationale as well. Maybe these other use cases would justify abandoning the original intent of the current language. Thanks. -- ================================================ David Farmer Email: farmer@umn.edu Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 1-612-626-0815 Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 ================================================
* David Farmer
I support the intent of the proposal, there are situations where it seems reasonable to allow transfers of blocks with end users in them, and the current blanket exclusion prevents this.
+1
However, I also support the original intent of the language that would be removed. I believe the intent of the original language was to prevent an LIR selling off a block that has active End Users in it, at least without notice or consent, etc...
For the example case given in the proposal, it seems that consent should be readily obtainable. So, would a better solution be to add "without consent of the End User(s)" to the current text. This provides flexibility without abandoning the protection the current text provides to End Users.
I don't see how this "protection" works in practise? If an LIR wants to get out of the internet registry business and sell off its allocations, it can always just purge them of assignments first (even with your requirement in place). The End Users probably won't be very pleased about being kicked out on the street so to speak, but c'est la vie... Tore
On 8/16/13 17:32 , Tore Anderson wrote:
* David Farmer
I support the intent of the proposal, there are situations where it seems reasonable to allow transfers of blocks with end users in them, and the current blanket exclusion prevents this.
+1
However, I also support the original intent of the language that would be removed. I believe the intent of the original language was to prevent an LIR selling off a block that has active End Users in it, at least without notice or consent, etc...
For the example case given in the proposal, it seems that consent should be readily obtainable. So, would a better solution be to add "without consent of the End User(s)" to the current text. This provides flexibility without abandoning the protection the current text provides to End Users.
I don't see how this "protection" works in practise?
If an LIR wants to get out of the internet registry business and sell off its allocations, it can always just purge them of assignments first (even with your requirement in place). The End Users probably won't be very pleased about being kicked out on the street so to speak, but c'est la vie...
If you really think it is OK for an LIR to drop an End User's assignments when every they want to, then why isn't it OK for RIPE to drop an LIR's allocations and auction them off to the highest bidders? C'est la vie and what's sauce for the goose is sauce for the gander too. Societal rules of conduct don't usually prevent anyone from breaking them, and many times people aren't directly punished for breaking these rules, but that doesn't mean society is a better place without such rules. Thank you, -- ================================================ David Farmer Email: farmer@umn.edu Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 1-612-626-0815 Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 ================================================
* David Farmer
On 8/16/13 17:32 , Tore Anderson wrote:
If an LIR wants to get out of the internet registry business and sell off its allocations, it can always just purge them of assignments first (even with your requirement in place). The End Users probably won't be very pleased about being kicked out on the street so to speak, but c'est la vie...
If you really think it is OK
The direction *my* moral compass is pointing is irrelevant (and for the record not stated either).
for an LIR to drop an End User's assignments when every they want to,
Our current IPv4 policy doesn't prohibit this, so it is indeed "OK" and sanctioned by our current IPv4 policy. It actually takes care to point out that PA assignments are *not* irrevocable: «End Users requesting PA space should be given this or a similar warning: Assignment of this IP space is valid as long as the criteria for the original assignment are met and only for the duration of the service agreement between yourself and us. We have the right to reassign the address space to another user upon termination of this agreement or an agreed period thereafter. This means that you will have to re-configure the addresses of all equipment using this IP space if you continue to require global uniqueness of those addresses.» As I think Sylvain was saying too, the only true protection afforded an End User against having his assignments being revoked for whatever reason, is the contractual terms he has negotiated in the service agreement with his LIR.
then why isn't it OK for RIPE to drop an LIR's allocations and auction them off to the highest bidders?
Because that is not sanctioned by the RIPE Community's policies.
Societal rules of conduct don't usually prevent anyone from breaking them, and many times people aren't directly punished for breaking these rules, but that doesn't mean society is a better place without such rules.
The proposal does not remove any social rules of conduct as far as I can tell. I think the proposal is fine as it is, and that tacking on a "the End Users must agree" condition isn't likely to accomplish anything that's actually helpful to the End Users. I think it would be more likely to either result in an ultimatum: "agree or be kicked out" (and if they do agree they'll probably end up being kicked out by the new allocation holder a few days later instead); or that the transferring LIR simply doesn't want the bother and instead just purges all assignments before the transfer is registered. In a nutshell: If the new holder's plans for the allocation doesn't include the old End Users, they're screwed anyway (regardless of 2013-05 being in place or not). However if the new holder does want to keep the old End Users and their assignments around, then this proposal is actually beneficial for all involved parties. Tore
If the new holder's plans for the allocation doesn't include the old End Users, they're screwed anyway (regardless of 2013-05 being in place or not). However if the new holder does want to keep the old End Users and their assignments around, then this proposal is actually beneficial for all involved parties.
that's my read can we keep the nit-picking paranoia over in arin, please, where i don't read it. randy
On 17/08/2013 09:45, Tore Anderson wrote:
The proposal does not remove any social rules of conduct as far as I can tell.
Social rules are bullshit when commercial contracts prevail on everything else. This is certainly not something I appreciate but it is the reality, and if on one hand we cannot do much about it, maybe on the other hand we could propose something more explicitely transparent and obvious for end users. Didn't Ripe "IPv4 alloc & assign" policy, for example, insist on making it super-clear for PI requesters, about the risks they are taking when requesting such ressources (and even ask for LIRs to confirm they made it clear in the request form) ? Is the risk smaller if End Users can be kicked from assigned IPs and they are not correctly informed about their (quite often really mistaken, as far as I can see) "owning" of the adresses they have base they business on ? So was it just a disclaimer or was it a warning to End Users saying "hey guys, watch it carefully". This is a point where I'm very glad to David for his remark, because maybe whe have a lack (but a responsability) in making things more transparent to End Users, beyond just delegating Ripes' workload on LIRs (which are not non-for-profit nor democratic structures). However, despite 2013-05 could look like an occasion to restore a bit of the missing protection, by allowing not empty allocs to be transferred *if* and *only if* some protection conditions are met, I am still not convinced this is dangerous in the general case (do operators want to sell their clients when they have another choice ?) Simply, sometimes suppleness is best for survival. So, still supporting 2013-05. Which doesn't mean we would'nt amend it another time with a more End User protecting general proposal. Definitely need more input for this, if someone has ideas about this (in another thread probably). Best regards, Sylvain
Hi, On 17/08/2013 00:32, Tore Anderson wrote:
If an LIR wants to get out of the internet registry business and sell off its allocations, it can always just purge them of assignments first (even with your requirement in place).
It looks to me that to break contracts with End-Users could be much more difficult for a LIR than just reselling these contracts to another LIR which would be forced to continue executing these contracts (maybe this is not true everywhere in the Ripe regions however). So this probably actually makes a difference, and good point for David, kind of a "protection" to the end users. Now, the question is, did the End Users conclude a contract with their LIR, that forbids him to resell this contract to another provider ? If yes, then the protections stands in the contrat. If not, should the Ripe policy (that does not require the End Users to agree) take care of such aspects of the relation between LIR and End User ? I don't think so, because this matter really seems (to me) to out exceed a Ripes' policy scope, for many reasons. The first of these reasons may be that End Users may have very different relations to their LIRs, and that the Ripe policy is not tying End Users, but only LIRs and Ripe. Another reason may be that we are not really sure that it would be a real protection for End Users to stop theyr LIR from transfering to another LIR. This could avoid them to have to renumber, by example. On the other hand it could be a company buying the IP space to stifle another concurrent company. But shouldn't courts be handling this actually ? So is such a limitation a real protection for End Users, or a dangerous rigidity that could avoid End Users to continue their activity ? Probably this is a too much complicated subject for Ripe policies to take part in a relation that is out of scope and involves a third party.
the internet will come to an end if this is adopted !!!! oops! wrong proposal. +1 randy
On Mon, Jul 22, 2013 at 3:08 PM, Emilio Madaio <emadaio@ripe.net> wrote:
Dear Colleagues,
A proposed change to RIPE Policy Document ripe-592, "IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region", is now available for discussion.
You can find the full proposal at:
The proposal is very clear and easily read, and eminently sensible. I support it. -- Jan
On 16 August 2013 15:41, Jan Ingvoldstad <frettled@gmail.com> wrote:
On Mon, Jul 22, 2013 at 3:08 PM, Emilio Madaio <emadaio@ripe.net> wrote:
The proposal is very clear and easily read, and eminently sensible.
I support it.
+1 -- James Blessing 07989 039 476
The proposal is very clear and easily read, and eminently sensible. I support it.
+1. D. -- Donal Cunningham IP Network Engineer, AirSpeed Telecom dcunningham@airspeed.ie | +353 1 428 7531 Airspeed Telecom
Dear AP WG, On Mon, Jul 22, 2013 at 03:08:26PM +0200, Emilio Madaio wrote:
A proposed change to RIPE Policy Document ripe-592, "IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region", is now available for discussion. [..] We encourage you to review this proposal and send your comments to <address-policy-wg@ripe.net> before 19 August 2013.
The discussion phase has ended. Based on your feedback, we have decided to move the proposal forward to review phase - there was sufficiently positive feedback, and only one request for changes. The rationale in the proposal text will be extended to talk about the different real-world cases that have been seen, both by the proposer and by the RIPE NCC registration service, to help decide whether this is "good as it is" or changes are indeed necessary. The proposal is now at Impact Analysis at the RIPE NCC. When that is finished, Emilio will announce the new phase (review phase) here. regards, 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 (89) 32356-444 USt-IdNr.: DE813185279
participants (13)
-
boggits -
David Farmer -
Donal Cunningham -
Emilio Madaio -
Gert Doering -
Jan Ingvoldstad -
Niall O'Reilly -
Nigel Titley -
Randy Bush -
Sascha E. Pollok -
Sylvain Vallerot -
Tim Kleefass -
Tore Anderson