Re: [address-policy-wg] 2012-05 New Policy Proposal (Transparency in Address Block Transfers)
On Mon, Jun 4, 2012 at 7:24 AM, Emilio Madaio <emadaio@ripe.net> wrote:
Dear Colleagues,
A proposed change to RIPE Document ripe-553, "IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region", is now available for discussion.
Besides publishing a list of v4 resources that have been moved, what does this accomplish that sub-allocations don't already do? Is the recipient LIR charged according to the resources under their registry file? -- Cheers, McTim "A name indicates what we seek. An address indicates where it is. A route indicates how we get there." Jon Postel
-----Original Message-----
Besides publishing a list of v4 resources that have been moved,
That is the sum and substance of what 2012-05 is intended to do. It does what ARIN and APNIC already do: provide an accessible list of resources that have been moved according to the transfer policies in place.
what does this accomplish that sub-allocations don't already do? Is the recipient LIR charged according to the resources under their registry file?
Like the previous question that was raised, you seem to be asking questions about the transfer policy itself, not about this proposal. The transfer policy already exists and it is what it is. All this proposal does it let the community know who is using it, and to better assess and track its consequences. --MM
[this comment is made with my view as a LIR manager] Milton L Mueller wrote:
-----Original Message-----
Besides publishing a list of v4 resources that have been moved,
That is the sum and substance of what 2012-05 is intended to do. It does what ARIN and APNIC already do: provide an accessible list of resources that have been moved according to the transfer policies in place.
what does this accomplish that sub-allocations don't already do? Is the recipient LIR charged according to the resources under their registry file?
Like the previous question that was raised, you seem to be asking questions about the transfer policy itself, not about this proposal. The transfer policy already exists and it is what it is.
Each and every existing policy is subject to review, change and/or improvement. Thus, when there is a proposal to amend existing policy text, this might be a good point in time to have a look at the whole set of provisions. With that point of view I'd like to ask for clarification of the following provision: " LIRs that receive a re-allocation from another LIR cannot re-allocate complete or partial blocks of the same address space to another LIR within 24 months of receiving the re-allocation. " But the receiving LIR may do so with other parts from their IPv4 address pool? What is the motivation for that particular restriction and for that particular wording? And, I am wondering, whether the following restriction is (still) useful: " The block that is to be re-allocated must not be smaller than the minimum allocation block size at the time of re-allocation. " in particular at a point in time when Registration Services has distributed the following announcement (Sept. 4, 2012 [1] ): - Depending on the availability in the RIPE NCC’s free pool of IPv4 address space, you may receive multiple smaller prefixes that add up to the size of your request.
All this proposal does it let the community know who is using it, and to better assess and track its consequences.
--MM
Wwilfried [1] Subject: RIPE NCC has Approximately Four Million IPv4 Addresses Before Reaching Last /8
* Wilfried Woeber, UniVie/ACOnet
Each and every existing policy is subject to review, change and/or improvement. Thus, when there is a proposal to amend existing policy text, this might be a good point in time to have a look at the whole set of provisions.
I disagree.
" LIRs that receive a re-allocation from another LIR cannot re-allocate complete or partial blocks of the same address space to another LIR within 24 months of receiving the re-allocation. "
" The block that is to be re-allocated must not be smaller than the minimum allocation block size at the time of re-allocation. "
Your questions are off topic, as both of those sentences you quoated are not modified in any way by 2012-05. You are of course free to start a new discussion about them, submit a new proposal to change them, and so forth. But please, don't hijack the 2012-05 thread. -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com
Agree with Tore Anderson here. Much as I would love to discuss modification of other aspects of the transfer policy, and as important as the questions raised by Wilfried are, they are not germane to 2012-5 at all.
Thus, when there is a proposal to amend existing policy text, this might be a good point in time to have a look at the whole set of
-----Original Message----- From: Tore Anderson [mailto:tore.anderson@redpill-linpro.com] provisions.
I disagree.
" LIRs that receive a re-allocation from another LIR cannot re-allocate complete or partial blocks of the same address space to another LIR within 24 months of receiving the re-allocation. "
" The block that is to be re-allocated must not be smaller than the minimum allocation block size at the time of re-allocation. "
Your questions are off topic, as both of those sentences you quoated are not modified in any way by 2012-05.
You are of course free to start a new discussion about them, submit a new proposal to change them, and so forth. But please, don't hijack the 2012-05 thread.
-- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com
<provoking>I don't see how anyone can be against this proposal.</provoking> The whole address assignment process should be as open as possible as long as the privacy of individuals is not concerned. From what I understand, this proposal is good for the community, for the price of a rare but somehow "public" good and for the routing system in general. I support the proposal. Regards Dan
Hi, On Thu, Sep 06, 2012 at 02:23:51PM +0200, Dan Luedtke wrote:
<provoking>I don't see how anyone can be against this proposal.</provoking> The whole address assignment process should be as open as possible as long as the privacy of individuals is not concerned. From what I understand, this proposal is good for the community, for the price of a rare but somehow "public" good and for the routing system in general. I support the proposal.
"as is", or "with anonymizing rejected applications"? 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 (89) 32356-444 USt-IdNr.: DE813185279
Hi everyone, On Thu, Sep 6, 2012 at 2:50 PM, Gert Doering <gert@space.net> wrote:
I support the proposal.
"as is", or "with anonymizing rejected applications"?
I think I can live with both. Just count me in. Regards Dan
Hi, Now I’m seeking for at least /14 IPv4 space for inter-RIR transfer, if anybody know company that have This size (Or not less than /15) please inform me, this is critical request. -- I Hamed Shafaghi I I Managing Director I I Skydsl® Telecom I hamed@skydsl.ir I www.skydsl.ir I
On Thu, Sep 6, 2012 at 2:23 PM, Dan Luedtke <maildanrl@gmail.com> wrote:
<provoking>I don't see how anyone can be against this proposal.</provoking>
I don't see the real world benefit of the proposal, there are insufficient arguments for it, and I'm therefore with Tore on this one. (So now you perhaps see how anyone _can_ be against it.) -- Jan
Hi, On Thu, Sep 06, 2012 at 02:54:59PM +0200, Jan Ingvoldstad wrote:
On Thu, Sep 6, 2012 at 2:23 PM, Dan Luedtke <maildanrl@gmail.com> wrote:
<provoking>I don't see how anyone can be against this proposal.</provoking>
I don't see the real world benefit of the proposal, there are insufficient arguments for it, and I'm therefore with Tore on this one.
(So now you perhaps see how anyone _can_ be against it.)
Uh. Can you please be a bit more explicit, as not everybody might remember Tore's stance on this? I take it that you are opposing the proposal? Any variant of the proposal, or would you support the "publish, but anonymize rejected transfers" option? It's a bit hard for the chairs to figure out which way to go if opinions are not stated clearly... thanks, 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 Thu, Sep 6, 2012 at 3:08 PM, Gert Doering <gert@space.net> wrote:
Hi,
On Thu, Sep 6, 2012 at 2:23 PM, Dan Luedtke <maildanrl@gmail.com> wrote:
<provoking>I don't see how anyone can be against this
On Thu, Sep 06, 2012 at 02:54:59PM +0200, Jan Ingvoldstad wrote: proposal.</provoking>
I don't see the real world benefit of the proposal, there are
insufficient
arguments for it, and I'm therefore with Tore on this one.
(So now you perhaps see how anyone _can_ be against it.)
Uh. Can you please be a bit more explicit, as not everybody might remember Tore's stance on this?
Oh, I'm terribly sorry, that was extremely clumsy of me! Tore's stance is here: http://lists.ripe.net/pipermail/address-policy-wg/2012-September/007063.html
I take it that you are opposing the proposal? Any variant of the proposal, or would you support the "publish, but anonymize rejected transfers" option?
The stance that I'm agreeing with is regarding publication of rejected transfers and rejected pre-approvals, so "publish, but anonymize rejected transfers/pre-approvals" is good with me. And, for the record, I agree with the notion that the NCC may: - publish aggregates - historical versions of alloclist.txt without any change in policy.
It's a bit hard for the chairs to figure out which way to go if opinions are not stated clearly...
Yes, absolutely, and I apologize for being fuzzy. This is one of the times where a "me, too" is insufficient. :) -- Jan
The stance that I'm agreeing with is regarding publication of rejected transfers and rejected pre-approvals, so "publish, but anonymize rejected transfers/pre-approvals" is good with me. OK, then, you are not disagreeing with the policy proposal, only with one aspect of it which I have agreed to change. I take it you also agree with Tore that the aggregate data can be published by RIPE-NN via request rather than through policy change? Milton L. Mueller Professor, Syracuse University School of Information Studies Internet Governance Project http://blog.internetgovernance.org
On Thu, Sep 6, 2012 at 5:28 PM, Milton L Mueller <mueller@syr.edu> wrote:
OK, then, you are not disagreeing with the policy proposal, only with one aspect of it which I have agreed to change.
I'm sorry, I missed that.
I take it you also agree with Tore that the aggregate data can be published by RIPE-NN via request rather than through policy change?
Yes, I think that is the most sensible approach. -- Jan
Hi, On Wed, Sep 05, 2012 at 12:04:02PM +0200, Wilfried Woeber, UniVie/ACOnet wrote:
With that point of view I'd like to ask for clarification of the following provision:
" LIRs that receive a re-allocation from another LIR cannot re-allocate complete or partial blocks of the same address space to another LIR within 24 months of receiving the re-allocation. "
But the receiving LIR may do so with other parts from their IPv4 address pool? What is the motivation for that particular restriction and for that particular wording?
Getting a transfer policy in place "back in the days" was a very difficult process, and the net result is a compromise... that particular sentence was there because it was feared that people would stockpile address space, wait for the price to rise, and then sell it off at a higher price - so, you have to sit on it for 24 months. This is not talking about a normal LIR, which has some free space here and there, might need something extra for a while, and then sell it off again...
And, I am wondering, whether the following restriction is (still) useful:
" The block that is to be re-allocated must not be smaller than the minimum allocation block size at the time of re-allocation. "
Well, it's an attempt to avoid even further fragmentation of the IPv4 address space (and subsequent burdening of the routing system). We haven't seen that many transfers yet, so I, at least, don't know how "useful" or "harmful" that restriction is in practice. Shall we put these two topics on the agenda for the upcoming RIPE meeting (in "Y. Open Policy Hour")? Would you be willing to lead the discussion? 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 (8)
-
Dan Luedtke -
Gert Doering -
Hamed Shafaghi -
Jan Ingvoldstad -
McTim -
Milton L Mueller -
Tore Anderson -
Wilfried Woeber, UniVie/ACOnet