Re: [policy-announce] [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
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 (5)
-
Gert Doering
-
McTim
-
Milton L Mueller
-
Tore Anderson
-
Wilfried Woeber, UniVie/ACOnet