Fwd: Re: Update on ALLOCATED PI/UNSPECIFIED
Dear Sander, list, below is an e-mail sent on 8/29 which did not make it to the list. Dear RIPE NCC admins - please check and help me understand why the message forwarded below did not make it to the mailing list as the google mail server ( that is used to host my @velea.eu private e-mail address) shows it as delivered (in the Sent folder) and I did receive the (BCC'ed copy). - please note, I am hiding the IP address and the from host in the headers below with '*x*'. If you need these details, please send me a message privately and I will share the IP address and even the name of my workstation. Sander, please take this message into account as well. I hope/think that the message below could make a difference. I am sorry for reacting so late, I did not know that my message did not make it to the list until I saw Sander's message with the summary. Regards, Elvis -------- Forwarded Message -------- Return-Path: <elvis@velea.eu> Received: from *x* ([*x.x.x.x*]) by smtp.googlemail.com with ESMTPSA id i80sm14433191wmf.11.2016.08.29.10.09.38 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 29 Aug 2016 10:09:38 -0700 (PDT) Reply-To: elvis@velea.eu Subject: Re: [address-policy-wg] Update on ALLOCATED PI/UNSPECIFIED References: <c988893b-d73d-4879-07b8-53ba50f4cfb5@ripe.net> <0a0dcd8a-a685-ed25-6837-0d807c370c21@velder.li> <57A31AAE.6060305@ripn.net> <m21t24zt1j.wl%randy@psg.com> <20160804113710.GJ79185@Space.Net> <m2y44cycc4.wl%randy@psg.com> <20160804121033.GK79185@Space.Net> <b0218cfd-30fa-4c3e-5a2b-ebbd03cf9869@ripe.net> To: address-policy-wg@ripe.net From: Elvis Daniel Velea <elvis@velea.eu> Message-ID: <48d42760-80dc-2e37-a436-e5ff46de00a3@velea.eu> Date: Mon, 29 Aug 2016 20:09:37 +0300 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <b0218cfd-30fa-4c3e-5a2b-ebbd03cf9869@ripe.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Hi everyone, On 8/5/16 4:41 PM, Ingrid Wijte wrote:
Dear colleagues,
Also, it might lead to deaggs (Markus' case) where a /14 that was originally "in one LIR" would be "3x /16, plus some smaller fragments in the LIR" and "lots of /24 PI managed by the NCC" now - so the /14 won't get a ROA, and he'll have to announce more-specifics. lemme see if i get this. to have the owner registration correct, some address space will have to be broken up and owned by multiple IRs, thus fragmenting routing? i like correct registration, but the commons has become pretty polluted.
The main issue that we (the WG and the RIPE NCC) are trying to resolve is the lack of clarity around the status and rights of these assignments. It’s not necessarily the case that the End User registration is incorrect. In many cases LIRs have put a lot of effort into keeping this information up to date. I believe that since these were PI assignments - the holdership/ownership/call-it-whatever of the IP addresses stays with the company to which this IP block was registered - the PI holder.
If the holder of the PI assignment agrees with the change of the block from ASSIGNED PI to PA, that will mean they are giving up on their right to hold/transfer the PI block. I think the main issue here is: who owns the rights of these IP addresses? If it's the LIR (because it was an allocation) - then they could kick the end-user out at any time. If it's the end-user - well, they should sign maintenance agreements as every PI holder and get those PIs under the same rules as everyone else's. I know of at least a few cases where the end-users have requested a PI assignment and have received one. However, some of them have received the PI assignments (approved by the RIPE NCC) from an ALLOCATED PI block while others have received them directly from the RIPE NCC. In both cases, the only one communicating with the RIPE NCC was the LIR. The end-users had no idea of the difference between the two PI blocks. That is why I believe that the NCC should talk to every PI holder from those PI/unspecified allocations and see if they - the end-users - the holders of the IP addresses - want to have the PI sponsored by an LIR (and therefore sign a maintenance agreement) or if they may want the IP block to be transferred to the LIR holding the large allocation (and transformed into ASSIGNED PA). The first step - talking to the allocation holder (the LIR) - is logical. However, if you only talk to the LIR you will only see one side of the story. It should be, I believe, the end-user that should decide whether they give up on their right to those IPs which now have become assets and are worth money. Therefore, I think that the RIPE NCC should talk to every single company holding a PI assignment from an ALLOCATED PI/UNSPECIFIED block and give them the option to give up on the maintenance of the IPs (and the right to transfer/sell) and transform them into ASSIGNED PA, or become a PI user - like all the others in the world - and sign a maintenance agreement with a LIR (and have the €50/year associated cost). regards, elvis
Hello Elvis,
Therefore, I think that the RIPE NCC should talk to every single company holding a PI assignment from an ALLOCATED PI/UNSPECIFIED block and give them the option to give up on the maintenance of the IPs (and the right to transfer/sell) and transform them into ASSIGNED PA, or become a PI user - like all the others in the world - and sign a maintenance agreement with a LIR (and have the €50/year associated cost).
The message Ingrid sent on the 4th of August already stated: "The WG agreed that, where the LIR can document a mutual agreement that they administer the address space, a conversion from PI to PA should take place. In all other cases, assignments with the status ASSIGNED PI should be treated as being assigned by the RIPE NCC." So no need to talk to each and every resource holder. The responsibility is with the LIR to show documentation, and the default is to convert the assignment to normal PI. And that is as far as we need to go here. The rest are implementation details and should be left to the RIPE NCC. Let's not micro-manage who exactly they should talk to. So to summarise: I think what you want is already part of what the RIPE NCC proposed, modulo implementation details. So the previous message holds: RIPE NCC, please move ahead. Cheers, Sander
Hi Sander, I think I should've carefully looked at Ingrid's e-mail, maybe through some glasses :) Indeed, the message from Ingrid stated exactly what I was asking for. I am still hoping to receive a message (it can be in private) from one of the the NCC's ops to see if we can find out why my initial message did not make it to the list. Apologies for all the noise, at least this is not 'popcorn style' like yesterday's :) Regards, Elvis On 10/20/16 7:33 PM, Sander Steffann wrote:
Hello Elvis,
Therefore, I think that the RIPE NCC should talk to every single company holding a PI assignment from an ALLOCATED PI/UNSPECIFIED block and give them the option to give up on the maintenance of the IPs (and the right to transfer/sell) and transform them into ASSIGNED PA, or become a PI user - like all the others in the world - and sign a maintenance agreement with a LIR (and have the €50/year associated cost). The message Ingrid sent on the 4th of August already stated: "The WG agreed that, where the LIR can document a mutual agreement that they administer the address space, a conversion from PI to PA should take place. In all other cases, assignments with the status ASSIGNED PI should be treated as being assigned by the RIPE NCC."
So no need to talk to each and every resource holder. The responsibility is with the LIR to show documentation, and the default is to convert the assignment to normal PI. And that is as far as we need to go here. The rest are implementation details and should be left to the RIPE NCC. Let's not micro-manage who exactly they should talk to.
So to summarise: I think what you want is already part of what the RIPE NCC proposed, modulo implementation details. So the previous message holds: RIPE NCC, please move ahead.
Cheers, Sander
participants (2)
-
Elvis Daniel Velea -
Sander Steffann