<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=windows-1252">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Dear Sander, list,<br>
<br>
below is an e-mail sent on 8/29 which did not make it to the list.<br>
<br>
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). <br>
- please note, I am hiding the IP address and the from host in the
headers below with '<b>x</b>'. 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.<br>
<br>
Sander, please take this message into account as well. I hope/think
that the message below could make a difference.<br>
<br>
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.<br>
<br>
Regards,<br>
Elvis<br>
<br>
<br>
<div class="moz-forward-container"><br>
<br>
-------- Forwarded Message --------
<table class="moz-email-headers-table" border="0" cellpadding="0"
cellspacing="0">
<tbody>
<tr>
<th align="RIGHT" nowrap="nowrap" valign="BASELINE">Return-Path:
</th>
<td><a class="moz-txt-link-rfc2396E" href="mailto:elvis@velea.eu"><elvis@velea.eu></a></td>
</tr>
<tr>
<th align="RIGHT" nowrap="nowrap" valign="BASELINE">Received:
</th>
<td>from <b>x</b> ([<b>x.x.x.x</b>]) 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)</td>
</tr>
<tr>
<th align="RIGHT" nowrap="nowrap" valign="BASELINE">Reply-To:
</th>
<td><a class="moz-txt-link-abbreviated" href="mailto:elvis@velea.eu">elvis@velea.eu</a></td>
</tr>
<tr>
<th align="RIGHT" nowrap="nowrap" valign="BASELINE">Subject:
</th>
<td>Re: [address-policy-wg] Update on ALLOCATED
PI/UNSPECIFIED</td>
</tr>
<tr>
<th align="RIGHT" nowrap="nowrap" valign="BASELINE">References:
</th>
<td><a class="moz-txt-link-rfc2396E" href="mailto:c988893b-d73d-4879-07b8-53ba50f4cfb5@ripe.net"><c988893b-d73d-4879-07b8-53ba50f4cfb5@ripe.net></a>
<a class="moz-txt-link-rfc2396E" href="mailto:0a0dcd8a-a685-ed25-6837-0d807c370c21@velder.li"><0a0dcd8a-a685-ed25-6837-0d807c370c21@velder.li></a>
<a class="moz-txt-link-rfc2396E" href="mailto:57A31AAE.6060305@ripn.net"><57A31AAE.6060305@ripn.net></a>
<a class="moz-txt-link-rfc2396E" href="mailto:m21t24zt1j.wl%randy@psg.com"><m21t24zt1j.wl%randy@psg.com></a>
<a class="moz-txt-link-rfc2396E" href="mailto:20160804113710.GJ79185@Space.Net"><20160804113710.GJ79185@Space.Net></a>
<a class="moz-txt-link-rfc2396E" href="mailto:m2y44cycc4.wl%randy@psg.com"><m2y44cycc4.wl%randy@psg.com></a>
<a class="moz-txt-link-rfc2396E" href="mailto:20160804121033.GK79185@Space.Net"><20160804121033.GK79185@Space.Net></a>
<a class="moz-txt-link-rfc2396E" href="mailto:b0218cfd-30fa-4c3e-5a2b-ebbd03cf9869@ripe.net"><b0218cfd-30fa-4c3e-5a2b-ebbd03cf9869@ripe.net></a></td>
</tr>
<tr>
<th align="RIGHT" nowrap="nowrap" valign="BASELINE">To: </th>
<td><a class="moz-txt-link-abbreviated" href="mailto:address-policy-wg@ripe.net">address-policy-wg@ripe.net</a></td>
</tr>
<tr>
<th align="RIGHT" nowrap="nowrap" valign="BASELINE">From: </th>
<td>Elvis Daniel Velea <a class="moz-txt-link-rfc2396E" href="mailto:elvis@velea.eu"><elvis@velea.eu></a></td>
</tr>
<tr>
<th align="RIGHT" nowrap="nowrap" valign="BASELINE">Message-ID:
</th>
<td><a class="moz-txt-link-rfc2396E" href="mailto:48d42760-80dc-2e37-a436-e5ff46de00a3@velea.eu"><48d42760-80dc-2e37-a436-e5ff46de00a3@velea.eu></a></td>
</tr>
<tr>
<th align="RIGHT" nowrap="nowrap" valign="BASELINE">Date: </th>
<td>Mon, 29 Aug 2016 20:09:37 +0300</td>
</tr>
<tr>
<th align="RIGHT" nowrap="nowrap" valign="BASELINE">User-Agent:
</th>
<td>Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0)
Gecko/20100101 Thunderbird/45.2.0</td>
</tr>
<tr>
<th align="RIGHT" nowrap="nowrap" valign="BASELINE">MIME-Version:
</th>
<td>1.0</td>
</tr>
<tr>
<th align="RIGHT" nowrap="nowrap" valign="BASELINE">In-Reply-To:
</th>
<td><a class="moz-txt-link-rfc2396E" href="mailto:b0218cfd-30fa-4c3e-5a2b-ebbd03cf9869@ripe.net"><b0218cfd-30fa-4c3e-5a2b-ebbd03cf9869@ripe.net></a></td>
</tr>
<tr>
<th align="RIGHT" nowrap="nowrap" valign="BASELINE">Content-Type:
</th>
<td>text/plain; charset=windows-1252; format=flowed</td>
</tr>
<tr>
<th align="RIGHT" nowrap="nowrap" valign="BASELINE">Content-Transfer-Encoding:
</th>
<td>8bit</td>
</tr>
</tbody>
</table>
<br>
<br>
<pre>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
</pre>
</div>
</body>
</html>