This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/[email protected]/
[address-policy-wg] 2016-03: trading the last /22?
- Previous message (by thread): [address-policy-wg] 2016-03: trading the last /22?
- Next message (by thread): [address-policy-wg] 2016-03: trading the last /22?
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Sebastian Wiesinger
sebastian at karotte.org
Mon Jun 20 13:17:48 CEST 2016
* Elvis Daniel Velea <elvis at velea.eu> [2016-06-20 12:57]: > 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 <gert at space.net> > [...] > > (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? legally = there is no offical way to transfer the /22. You're violating the policy. > > 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. ARIN is a completely different situation. There is no needs based criteria in the RIPE region. It is really simple to transfer address space. This was done exactly to avoid these constructs and false database entries. > 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. It will complicate things for whom? It does not touch anything except the prefixes allocated under the last /8 policy. > 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. That would mean we run out of space tomorrow. This is not what this whole policy is about. It was about preserving space for newcomers. Still most people arguing here seem to have just their short term gain in view. > 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. Then we will tackle this issue if and when it arises. > 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. You always reference "the game". What game exactly do you think this game is? Can you name the rules and goals of the game? Because I find it really difficult to argue this as a game. Because it seems everybody is playing a different game. For the second part, as was stated repeatedly it will only change transfers from the date it is implemented. Sebastian -- GPG Key: 0x93A0B9CE (F4F6 B1A3 866B 26E9 450A 9D82 58A2 D94A 93A0 B9CE) 'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE SCYTHE. -- Terry Pratchett, The Fifth Elephant -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 581 bytes Desc: Digital signature URL: </ripe/mail/archives/address-policy-wg/attachments/20160620/4660b760/attachment.sig>
- Previous message (by thread): [address-policy-wg] 2016-03: trading the last /22?
- Next message (by thread): [address-policy-wg] 2016-03: trading the last /22?
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]