<div dir="ltr">Hello!<div><br></div><div>Perfect contribution Thomas! I could put my sign under each word here. Thanks for your work! </div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Feb 16, 2016 at 3:46 PM, Thomas Mangin <span dir="ltr"><<a href="mailto:thomas.mangin@exa-networks.co.uk" target="_blank">thomas.mangin@exa-networks.co.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>
<p dir="auto">Dear RIPE NCC Board,</p>

<p dir="auto">Thank you for opening this discussion/consultation.</p>

<blockquote>
<ol>
<li value="1">Is the activity of members opening additional LIR accounts a problem that must be prevented?</li>
</ol>
</blockquote>

<p dir="auto">It is. The RIPE NCC policies should be written in a way which is<br>
beneficial to its community.<br>
Having a number of organisations using them to profit (financially or by<br>
gaining more IP addresses) is not in our community’s interest.</p>

<p dir="auto">However, any response to a problem should be proportional to the issue<br>
and therefore the RIPE NCC’s answer to this problem should take<br>
in consideration the number of member abusing the system and the harm<br>
being done to the community.</p>

<p dir="auto">The last /8 policy was mostly written to make sure new entrants are not<br>
priced out of market and from the data there is no evidence this is yet<br>
the case. Therefore any solution should be careful to keep this goal.</p>

<ol>
<li value="2">If this activity is a problem that must be prevented, what action
should the RIPE NCC take to attempt its prevention?</li>
</ol>

<p dir="auto">This is a very broad topic, and a decision by consensus without some<br>
more research and a/some paper(s) to guide the discussion seems unwise<br>
here. That said …</p>

<p dir="auto">Like others, I can see two scenarios why an organisation may register<br>
several LIR:<br>
 (0) it is practical for their organisation - nothing to see<br>
 (1) to secure for itself several /22 when the last /8 policy comes in<br>
play<br>
 (2) to secure a number of /22 to resell<br>
 … If the board is aware of other case, I would welcome some<br>
enlightemement</p>

<p dir="auto">For case (1) The RIPE NCC could restrict the number of LIR an<br>
organisation wish to have (to a suitable low but practical number) as<br>
long as this does not impact genuine use of the RIPE NCC.</p>

<p dir="auto">For case (2), The most likely impact of forbidding this practice may be<br>
to increase the price of IPv4 at sales (passing on the cost of the<br>
business creation), which would affect people needing IP space - and<br>
required to purchase some - more than the people selling it and making<br>
the profit.</p>

<p dir="auto">Price changes should only be brought forward if the RIPE NCC is sure it<br>
can price ‘bad’ business models out. As this is something we have no<br>
data to make our mind on and and which may also have other side effects<br>
- I am unsure it would be wise.</p>

<p dir="auto">Also the membership should keep in mind that any new ‘policy’ will be<br>
immediately ‘played’ by people actively trying to game the system.<br>
Therefore careful thoughts should be placed on any new rule placed<br>
which will therefore inevitably have unintended consequences.</p>

<p dir="auto">Regarding enforcing some rules for the transfer of resources, I am<br>
concerned it could place the organisation in a position where it could<br>
be on the receiving hand of legal challenges. Therefore I would favour<br>
any solution which would not require any ‘human judgement’ by the<br>
RIPE NCC at transfer time.</p>

<blockquote>
<p dir="auto">The Board will monitor the discussion and will review it at the next<br>
Executive Board Meeting on 31 March 2016. Depending on the outcome of<br>
that meeting, the Board may propose a resolution for members to vote on at the RIPE NCC General Meeting in May 2016.</p>
</blockquote>

<p dir="auto">I would hope the RIPE NCC does put forwad some proposals for vote. As<br>
the board may not be in a position to ‘guess’ the option(s) most likely<br>
to gain consensus, a number of proposals could be presented to the<br>
membership so should a proposal succeed (or fail) others can be<br>
presented to complete / replace it. (This assumes the extra new LIRs are<br>
not already in a veto position with our usual voting engagement)</p>

<p dir="auto">Also the RIPE NCC may consider to add this information to the list of<br>
RIPE NCC’s LIR as:<br>
 - it would allow to spot who may oppose changes to the RIPE NCC<br>
policies due to personal gain<br>
 - it would the community to use other form of self-regulation to act<br>
on this matter should the RIPE NCC fail to reach consensus.</p>

<p dir="auto">Some of the options to remove the benefit of registering several LIR are<br>
(more than one could be considered for a solution):<br>
 - creating some more aggresive rules regarding the transfer of<br>
resources<br>
 - not allowing resources transfer for ‘young’ LIR<br>
 - changing the rules for the last /8<br>
    * having a concept of related LIR<br>
    * providing some space in relation to the existing allocation (at<br>
the cost of increasing the fragmentation of the /8).<br>
 - revoking the last /8 policy - treating it as normal<br>
 - revoking the last /8 policy - keeping the space until more<br>
visibility on how best use it can be gathered.<br>
 - .. surely some more ..</p>

<p dir="auto">Sincerely,</p>

<p dir="auto">Thomas Mangin<br>
Exa Networks Limited</p>

</div><br>----<br>
If you don't want to receive emails from the RIPE NCC members-discuss<br>
mailing list, please log in to your LIR Portal account and go to the general page:<br>
<a href="https://lirportal.ripe.net/general/" rel="noreferrer" target="_blank">https://lirportal.ripe.net/general/</a><br>
<br>
Click on "Edit my LIR details", under "Subscribed Mailing Lists". From here, you can add or remove addresses.<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature">Sincerely yours,  Pavel Odintsov<br>CTO, FastVPS Eesti OU</div>
</div>