"Sander Steffann mentioned you in an e-mail":

On Sun, 2015-02-22 at 12:10 +0100, Sander Steffann wrote:
> A new LIR can only get a /22 from RIPE NCC so while this is indeed
> possible the impact of that is limited. Whether this opening up new
> LIRs just to sell the /22 is something that needs to be
> prevented/discouraged (the policy proposal under discussion) or
> whether this is a good thing (see Martin Millnert's messages) is for
> this working group to discuss.

Yeah, it's not as much "starting lots of LIRs" that I think in itself is
valuable (for the community). It's a pretty bad means to an end.

The real issue I have is rather - "how much space per LIR", and whether
the internet community is best served by the RIPE NCC having an
available pool for low-utilization projects/business for some time
forward (subject to abuse), or if its best served by depleting fully the
free pool sooner rather than later to accelerate the development into
the future IP addressing functions.

I'm not sure what I think is correct myself - I think we're right now
doing the equivalent of slowly tearing a patch off the skin. My
presupposition is that we should just let the market fix it because it
is much wiser than us.  But the infrastructure for that needs to be
functionally in place (policies etc), on the other hand, some of the
issues may not reveal themselves until the new situation arrives.

I do think this merits further discussion. (Hence change of topic).

There are many concepts that I think needs to go out the window today.
One of them, I believe strongly, is all the bureaucracy of the RIPE NCC
to judge "need" for allocations/assignment.
  The ripe-623 ch 3.0 #3 "Fairness" is also deprecated once RIPE NCC has
no more addresses to distribute, which is the case already today!  It is
not fair that some end users have /8 and others have /22 or /24.

The market resolves need. The registry registers. The unnecessary
bureaucracy is nothing but a waste of natural resources (energy, time,
resources).

/M

Attachment: signature.asc
Description: This is a digitally signed message part

Reply via email to