[address-policy-wg] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Cleanup)

On Tuesday, September 24, 2013, Randy Bush wrote:

> > IPv4 will, undoubtedly, eventually run out.
>
> ipv4 will be around after everyone on this list today is retired.


Very good point.
I can hate it - but I would not bet much on you beeing wrong - even if I am
going to retire a few years after you.
(...)


> we would like it if the registries acted as registries, i.e. recorded
> accurately who controls/owns what address space.  we thought that was
> their primary responsibility


Fully agree.


the registry system has a choice.  it can make it difficult for users
> to register, transfer, sauté, whatever address space, in which case
> they have some chance at a reasonable level of accuracy in their
> registries, or they can make it difficult.  in the latter case, they
> will become vestigial organs whose function we will soon not even be
> able to remember.  and we sure as heck won't be sending money to them.
>
> the choice is ours.  today, dealing with the registries' petty rules
> and bureaucracy is a major pita.  this policy proposal tries to make
> it easier.


Since the start of my first encounter with the RIR Ripe 20 years ago we
have gradualy
reduced the documentation to demonstrate the need for addressess (have had
to send receipts for equipment and such a couple times - we do not do that
anymore)  - thus there is more trust in the LIRs self assesment of need
than it used to be.

I think the important shift now  is that this proposal actualy transfers
the responsibility for conservation fully to the LIR - much in the same way
as the responsibility for aggregation has been with the LIR for years.

(in the end of 80s the central registry even tried to look after
aggregation by delivering a then class B - now /16 instead of 4 class C /24)

I would argue that we have a strong tradition to move in the direction of
deregulation ad more trust in the LIR in this region


> it really makes small difference what we choose.  the internet will
> route around whatever impediments we place.  it's a big river now.


Right.
It is probably fairly easy to transfer IP Addressess from company A to B in
most regions trough other means :

company -A forms subcidiary A-registry ltd. A-registry Ltd is sold to B and
then merged with B.

Just is slightly more expensive and keeps the lawyers busy.  Actualy - in
my country I think I could to the legal work myself - its not that
complicated.

(and i have a real life example for a /8 that has made its way from Norway
in the RIPE region to USA in arin Arin region this way -  in a slightly
more complicated manner with a few more steps).

A side effect of allowing addresses to be more or less freely tranfered is
that it could actualy bring more addresses to the market - when early
adopers figure out that they can run their entire corporate/governmet
network on private addresses between a NAT keeping only their servers
offering public services on public addresses - the same way as most
companies has had to do for years.

As soon as the market price is higher than the cost to redesign and
renumber this will start to happen.

We should probably take this further and split the policy in 3:

- a clear registration policy that applies to everybody and requires
addresses to be registered
- a transfer policy - focusing on proper identification and authorisation
of transfers
- an assignment policy for the last /8 from the RIR and whatever address
space was returned

I belive that  if we want to have _need_ included in the policies  it
should be in the last two - and we need to come up with a needs criteria
and documentation of such that can be audited by an independent party - if
we want theese to have some real world legitimacy.

I think.


> randy


- hph

PS: At the last ICANN meeting the US GAC representative read a long
prepared statement on freedom and as little regulation as possible.


-- 
Hans Petter Holen
Mobile +47 45 06 60 54 | hph at oslo.net | http://hph.oslo.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </ripe/mail/archives/address-policy-wg/attachments/20130924/a2dde2ea/attachment.html>