Hi Gert,

I am surprised to see that you are defending this proposal more than
the proposer :)

> On Jun 20, 2016, at 12:33, Gert Doering <[email protected]>
[...]
> (Regarding the DB accuracy, I think Sander has answered this upthread
> in a way I find convincing: if trading for these /22s is limited, of
> course someone who trades "under the desk" will not be able to update
> the registry, so potentially someone else uses the /22 and can not document
> that.  Would I buy a /22 that I can not legally transfer into my LIR?

legally?

> No, because I'm all at the mercy of the seller - if he closes his LIR,
> "my" /22 is gone.  So I'd go and find a unencumbed /22 on the market - and
> in my book, this would mean "mission accomplished, trading discouraged")

If things would be so simple...

Look at what's happening in ARIN. Lots of transfers (some very large
ones as well) are done by means of financial/contractual artifices
(furures contracts and such) avoiding the needs based criteria from
the policy. Millions of IPs seem to change hands but the transfer are
not recorded in the registry.

While *you* would not trade a 'last allocated' block, it does not mean
that these will not trade.

I have been extremely happy with the very simple (non-restrictive)
transfer policy that we have had for years and I think this proposal
will only complicate things.

Yet an other colour of the IPv4 space is something we should avoid.
Numbers are numbers and giving them colours - legacy, anycast, PA, PI
-, and now non-transferable is something we as a community should
avoid. And if it were to still work on the IPv4 policy, I would do my
best to clean all these colours away and keep only one.

The M&As have been an issue for years and these will become the next
issue if this proposal gets accepted. I also await the response from
the NCC before commenting further on this issue.

I also do not think it's ok to have a policy change the status of a
resource 'in the middle of the game' and think that even if accepted,
this proposal should cause a change of status only from the moment it
is implemented.

>
> Gert Doering
>        -- APWG chair

/elvis

Reply via email to