Re: [address-policy-wg] R: making progress with 2015-05

[Nick Hilliard]

Jim Reid wrote:
> Third, I think it’s unwise to have a firm rule on transfers. Though I
> understand why you’ve suggested this: it’s meant to stop LIRs selling
> off these extra addresses. For one thing, there can be valid reasons
> for transferring space that don’t involve selling IPv4 addresses - a
> business reorganisation for instance. Next, if an LIR wants extra
> /22s in order to sell the addresses, they’d still do that
> irrespective of what the transfer restrictions were in place.

fourth: this suggestion proposes to revert to a "needs" based allocation
policy.  This policy was removed a couple of years ago for good reasons
which are still valid now and it is not realistic to expect that the
clock is going to be turned back on this.

Nick

Re: [address-policy-wg] R: making progress with 2015-05

[Jim Reid]

> On 11 May 2016, at 09:29, Enrico Diacci  wrote:
> 
> When an LIR can claim to have reached 4 (or 5) stars of RIPEness for IPv6
> may require an additional /22 (if you do not already have space equivalent
> to a /20) stating its reasons for the new allocation with a project and
> proving to have it completed within one year.
> 
> This new /22 will in no way be transferred before 3-5 years.
> 
> I tried to remove the term of 18 months: what do you think about?

Not a lot. But thanks for the suggestions and for trying to move things forward.

First off, I am adamantly opposed to any policy proposal which will speed up 
depletion of the NCC’s IPv4 pool. Though if someone can come up with a 
convincing case for wiping it out, I would reconsider. Until then, the current 
policy is the least worst option IMO and we should keep it.

Second, coupling any policy to RIPEness metrics is a very bad idea. Those 
metrics may change or even go away. [Who decides about that BTW.] They can be 
easily gamed too. Just do whatever needs to be done with IPv6 to get the extra 
IPv4 space and then take it down. Repeat.

Third, I think it’s unwise to have a firm rule on transfers. Though I 
understand why you’ve suggested this: it’s meant to stop LIRs selling off these 
extra addresses. For one thing, there can be valid reasons for transferring 
space that don’t involve selling IPv4 addresses - a business reorganisation for 
instance. Next, if an LIR wants extra /22s in order to sell the addresses, 
they’d still do that irrespective of what the transfer restrictions were in 
place.

[address-policy-wg] R: making progress with 2015-05

[Enrico Diacci]

I try to go beyond the 2015-05: 

When an LIR can claim to have reached 4 (or 5) stars of RIPEness for IPv6
may require an additional /22 (if you do not already have space equivalent
to a /20) stating its reasons for the new allocation with a project and
proving to have it completed within one year.

This new /22 will in no way be transferred before 3-5 years.

I tried to remove the term of 18 months: what do you think about?

Regards, Enrico Diacci.
it.tsnet


-Messaggio originale-
Da: address-policy-wg [mailto:address-policy-wg-boun...@ripe.net] Per conto
di Jim Reid
Inviato: mercoledì 11 maggio 2016 10:05
A: Riccardo Gori
Cc: RIPE Address Policy WG
Oggetto: [address-policy-wg] making progress with 2015-05


> On 11 May 2016, at 08:53, Riccardo Gori  wrote:
> 
> Sander noticed there are people here that are confirming that a change 
> is accepted and someone else noticed that 2015-05 can be re-written or 
> re-invented to meet better the tasks You as a chair should accept this 
> and should help the community to understand how to follow up with a 
> reasonable solution

The WG’s co-chairs have not expressed an opinion on this proposal. This is
to be expected since they have to make the consensus determination if
2015-05 reaches that point.

Others have pointed out flaws and raised substantial objections. These
issues have not been answered, let alone resolved.

Supporters of 2015-05 should accept this and should help the community to
understand how to follow up with a reasonable solution.

We’re waiting.


PS: Apologies for a relevant and meaningful Subject: header.




smime.p7s
Description: S/MIME cryptographic signature