[address-policy-wg] 2011-03 New Policy Proposal (Post-depletion IPv4 address recycling)

Hi Martin,

I'll try to answer the points you raised below:

1. This proposal does not impact transfer at all. Addresses that get
transferred are at no point in that process 'returned to the RIPE NCC'.

2. It's not explicitly defined because it all depends on the address space
returned. As I already indicated in another email, the long term effect of
this is likely to be that all /8s managed by the RIPE NCC will have a
minimum allocation size of a /22; and if we then run out of /22s or larger
and need to hand out multiple smaller blocks (moving to clause 4) a few
additional /8s might get *really* unlucky. But that will only happen when
we're scraping the RIPE NCC barrel.

Best regards,

Remco

On 24-05-11 01:44, "Martin Millnert" <millnert at gmail.com> wrote:

>Hi!
>
>On Fri, May 20, 2011 at 6:11 AM, Emilio Madaio <emadaio at ripe.net> wrote:
>>    http://www.ripe.net/ripe/policies/proposals/2011-03/
>
>I support this proposal, provided I see satisfactory clarifications
>according to the below. :)
>
>1)  I note that the proposal specifically does not address transfers
>between entities under contract with the RIPE NCC.
>Am I correct in concluding the above and following?  That this
>proposal does not affect or impede the transfer of an IPv4 resource
>from entity X to Y, while keeping the RIPE registry accurate, in any
>way? This is a strong and vital function of RIPE NCC's registry
>function as we go into the darkness IMO. I.e.., that this only
>addresses resource holders who specifically chooses to return
>resources to the RIPE NCC without any other party involved?  While I
>cannot support a policy proposal which would damage the RIPE NCC
>registry in such a way, I don't think this is the intention, but I'd
>like to make it dead certain!
>
>2) I'd also like a clarification regarding clause 3b:
>"b. Minimum allocation sizes for the relevant /8 blocks will be
>updated if necessary."
>
>Updated to what?  It is not explicitly defined.  Is this intentional or
>not?
>
>I see two ways to read this:
>a) The policy proposal intends to declare that address blocks returned
>to RIPE that are to be handed out according to LIR's without such an
>assignment according to clause 1 (in other words, assignments by way
>of clause 3a), shall have the same fixed assignment size as those in
>clause 1, i.e. that of a /22.
>b) The policy proposal intends to declare that the fixed assignment
>size, /22, in clause 1 can "be updated if necessary", i.e be changed
>to something else, likely/presumably longer?
>
>Either is fine with me, but I think it's a bit too ambiguous right now.
>
>Thank you,
>Regards,
>Martin
>



This email is from Equinix Europe Limited or one of its associated/subsidiary companies. This email, and any files transmitted with it, contains information which is confidential, may be legally privileged and is solely for the use of the intended recipient. If you have received this email in error, please notify the sender and delete this email immediately.  Equinix Europe Limited.  Registered Office: Quadrant House, 4 Thomas More Square, London E1W 1YW.  Registered in England and Wales, No. 6293383.