Re: [address-policy-wg] 2014-05 New Policy Proposal (Policy for Inter-RIR Transfers of Internet Resources)
On Tue, Jun 3, 2014 at 3:13 PM, Marco Schmidt <mschmidt@ripe.net> wrote:
I like this proposed policy, it is very reasonable, and seems to have addressed the overlying concerns with inter-RIR transfers. I have a comment regarding the second argument against the policy, "*The proposal will re-introduce operational needs justification, if any RIR insists on this, in order to effect certain transfers*." I don't think this is an argument against the policy itself, but it is a concern that RIPE NCC needs to address when guiding LIRs in the transfer process. In other words: yes, operational needs justification under any other RIR's "jurisdiction" is a concern, but it is not within RIPE's powers to do anything about it, other than help RIPE's LIRs make the best of it when transferring resources. -- Jan
Hi, I also like the new proposed text. It addresses all of the concerns I had with the previous one and this time it is very clean and simple. +1 from me. cheers, elvis On 05/06/14 10:28, Jan Ingvoldstad wrote:
On Tue, Jun 3, 2014 at 3:13 PM, Marco Schmidt <mschmidt@ripe.net <mailto:mschmidt@ripe.net>> wrote:
I like this proposed policy, it is very reasonable, and seems to have addressed the overlying concerns with inter-RIR transfers.
I have a comment regarding the second argument against the policy, "/The proposal will re-introduce operational needs justification, if any RIR insists on this, in order to effect certain transfers/."
I don't think this is an argument against the policy itself, but it is a concern that RIPE NCC needs to address when guiding LIRs in the transfer process.
In other words: yes, operational needs justification under any other RIR's "jurisdiction" is a concern, but it is not within RIPE's powers to do anything about it, other than help RIPE's LIRs make the best of it when transferring resources. -- Jan
-- <http://v4escrow.net> Elvis Daniel Velea Chief Business Analyst Email: elvis@V4Escrow.net <mailto:elvis@v4escrow.net> US Phone: +1 (702) 475 5914 EU Phone: +3 (161) 458 1914 Recognised IPv4 Broker/Facilitator in: This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received this email in error, please notify the sender immediately and delete the original.Any other use of this email is strictly prohibited.
Overall, this policy looks good to me. However, I believe there is one problem with the text. The language regarding recipients in other regions requires that the recipient be an LIR. However, the transfer policies of the other regions do not make any such distinction. Therefore, I believe it would be more appropriate to use the word organization instead of LIR when referring to recipients in other regions. Scott (speaking only for myself)
On Jun 5, 2014, at 3:36 AM, Elvis Daniel Velea <elvis@v4escrow.net> wrote:
Hi,
I also like the new proposed text. It addresses all of the concerns I had with the previous one and this time it is very clean and simple.
+1 from me.
cheers, elvis
On 05/06/14 10:28, Jan Ingvoldstad wrote: On Tue, Jun 3, 2014 at 3:13 PM, Marco Schmidt <mschmidt@ripe.net> wrote:
I like this proposed policy, it is very reasonable, and seems to have addressed the overlying concerns with inter-RIR transfers.
I have a comment regarding the second argument against the policy, "The proposal will re-introduce operational needs justification, if any RIR insists on this, in order to effect certain transfers."
I don't think this is an argument against the policy itself, but it is a concern that RIPE NCC needs to address when guiding LIRs in the transfer process.
In other words: yes, operational needs justification under any other RIR's "jurisdiction" is a concern, but it is not within RIPE's powers to do anything about it, other than help RIPE's LIRs make the best of it when transferring resources. -- Jan
-- <logo.png> Elvis Daniel Velea
Chief Business Analyst
Email: elvis@V4Escrow.net US Phone: +1 (702) 475 5914 EU Phone: +3 (161) 458 1914 Recognised IPv4 Broker/Facilitator in:
<1.png> This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received this email in error, please notify the sender immediately and delete the original.Any other use of this email is strictly prohibited.
On Thu, Jun 5, 2014 at 7:30 PM, Scott Leibrand <scottleibrand@gmail.com> wrote:
Overall, this policy looks good to me. However, I believe there is one problem with the text. The language regarding recipients in other regions requires that the recipient be an LIR. However, the transfer policies of the other regions do not make any such distinction. Therefore, I believe it would be more appropriate to use the word organization instead of LIR when referring to recipients in other regions.
That's a fair point. -When Internet number resources are transferred to another RIR, the RIPE NCC will work with the destination RIR to allow the transfer to the receiving LIR. +When Internet number resources are transferred to another RIR, the RIPE NCC will work with the destination RIR to allow the transfer to the receiving organization. Like that? -- Jan
On Thu, Jun 5, 2014 at 2:25 PM, Jan Ingvoldstad <frettled@gmail.com> wrote:
On Thu, Jun 5, 2014 at 7:30 PM, Scott Leibrand <scottleibrand@gmail.com> wrote:
Overall, this policy looks good to me. However, I believe there is one problem with the text. The language regarding recipients in other regions requires that the recipient be an LIR. However, the transfer policies of the other regions do not make any such distinction. Therefore, I believe it would be more appropriate to use the word organization instead of LIR when referring to recipients in other regions.
That's a fair point.
-When Internet number resources are transferred to another RIR, the RIPE NCC will work with the destination RIR to allow the transfer to the receiving LIR. +When Internet number resources are transferred to another RIR, the RIPE NCC will work with the destination RIR to allow the transfer to the receiving organization.
Like that?
Yes. Also: -Address space may only be re-allocated to another LIR that is a member of an RIR that allows transfers. The block that is to be re-allocated must not be smaller than the minimum allocation block size at the time of re-allocation. +Address space may only be re-allocated to another organization that is a member of an RIR that allows transfers. The block that is to be re-allocated must not be smaller than the minimum allocation block size at the time of re-allocation. However, that may have implications for intra-RIR transfers, so you might need to separate out the two cases if you don't want to imply that non-LIR organizations can receive transfers in the RIPE region. Maybe something like "to another LIR in the RIPE region, or an organization that is a member of an RIR that allows transfers." -Scott
Hi, On Thu, Jun 05, 2014 at 03:58:11PM -0700, Scott Leibrand wrote:
However, that may have implications for intra-RIR transfers, so you might need to separate out the two cases if you don't want to imply that non-LIR organizations can receive transfers in the RIPE region. Maybe something like "to another LIR in the RIPE region, or an organization that is a member of an RIR that allows transfers."
All RIPE members are LIRs. Gert Doering -- NetMaster -- 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
On Jun 6, 2014, at 2:44 AM, Gert Doering <gert@space.net> wrote:
Hi,
On Thu, Jun 05, 2014 at 03:58:11PM -0700, Scott Leibrand wrote: However, that may have implications for intra-RIR transfers, so you might need to separate out the two cases if you don't want to imply that non-LIR organizations can receive transfers in the RIPE region. Maybe something like "to another LIR in the RIPE region, or an organization that is a member of an RIR that allows transfers."
All RIPE members are LIRs.
Oh, good point. We actually end up with the same problem with the word "member" that occurs with the word "LIR". End user organizations in other regions can receive address space via transfer without being members. This text would exclude them from inter-RIR transfers from the RIPE region. Maybe "to another LIR in the RIPE region, or an organization in the service region of another RIR that allows transfers"? -Scott
Hi, On Fri, Jun 06, 2014 at 11:44:23AM +0200, Gert Doering wrote:
All RIPE members are LIRs.
RIPE *NCC* members, to be precise. "RIPE" is "the community", and all of us are members of the RIPE community :-) - so while it was clear from the context what I was trying to say, it was still technically wrong. Sorry for that. Gert Doering -- NetMaster -- 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
"RIPE" is "the community", and all of us are members of the RIPE community :-)
we have always been at war with eastasia
Just as a heads-up: On 06.06.2014 00:58, Scott Leibrand wrote:
[...] Also:
-Address space may only be re-allocated to another LIR that is a member of an RIR that allows transfers. The block that is to be re-allocated must not be smaller than the minimum allocation block size at the time of re-allocation. +Address space may only be re-allocated to another organization that is a member of an RIR that allows transfers. The block that is to be re-allocated must not be smaller than the minimum allocation block size at the time of re-allocation.
Given the support that 2014-01 has seen so far, you may want to think this paragraph without its second sentence; cf. items e) & f) of https://www.ripe.net/ripe/policies/proposals/2014-01 - and see whether it still makes sense to you. Cheers, -C.
participants (6)
-
Carsten Schiefner -
Elvis Daniel Velea -
Gert Doering -
Jan Ingvoldstad -
Randy Bush -
Scott Leibrand