<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Dears,<br>
<br>
I oppose to the current policy proposal as written. It does not mean
that a second version would not be acceptable but this one has a few
major problems:<br>
<br>
<div class="moz-cite-prefix">On 5/17/16 3:08 PM, Remco van Mook
wrote:<br>
</div>
<blockquote
cite="mid:B8BBB672-5A4C-4B0B-A87A-555DDA1339C0@gmail.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<div class=""><br class="">
</div>
<div class="">
<div style="font-family:'Helvetica Neue';font-size:14px;"
class="">Thank you Marco. </div>
<div style="font-family:'Helvetica Neue';font-size:14px;"
class=""><br class="">
</div>
<div style="font-family:'Helvetica Neue';font-size:14px;"
class="">Dear colleagues,</div>
<div style="font-family:'Helvetica Neue';font-size:14px;"
class=""><br class="">
</div>
<div style="font-family:'Helvetica Neue';font-size:14px;"
class="">Yes, this is another policy proposal about IPv4. It's
even about the current allocation policy (confusingly known as
'last /8'). I'm sorry it's come to this.</div>
<div style="font-family:'Helvetica Neue';font-size:14px;"
class=""><br class="">
</div>
<div style="font-family:'Helvetica Neue';font-size:14px;"
class="">The proposal doesn't aim to change a lot about the
*intended* goals of the last /8 policy - instead, it tries to
clarify the current policy and lock it down against creative
interpretations.</div>
</div>
</blockquote>
This is true. However, it creates several problems and fixes only
one. The fix - allocations from 'last /8' can not be transferred any
longer (once this proposal is accepted and becomes policy).<br>
<blockquote
cite="mid:B8BBB672-5A4C-4B0B-A87A-555DDA1339C0@gmail.com"
type="cite">
<div class="">
<div style="font-family:'Helvetica Neue';font-size:14px;"
class=""><br class="">
</div>
<div style="font-family:'Helvetica Neue';font-size:14px;"
class="">We're in the IPv4 afterlife, and have been for about
3.5 years. The last scrap of IPv4 space that any LIR can get
is meant for a specific purpose - to facilitate migration to
IPv6. The age of the 32 bit integers is over. The other
purpose of the 'last /8' policy is to be able to hand out IPv4
space to new entrants for as long as feasible. These specific
purposes are currently not reflected anywhere once a block has
been allocated, and this proposal means to change that. To
summarise the proposed changes:</div>
<div style="font-family:'Helvetica Neue';font-size:14px;"
class=""><br class="">
</div>
<div style="font-family:'Helvetica Neue';font-size:14px;"
class="">- All allocations handed out under the 'last /8
policy' will be (re-)registered as 'ALLOCATED FINAL';</div>
</div>
</blockquote>
All allocations (as in all those that were allocated since 2012?) or
only the ones that are going to be allocated once this proposal
becomes policy?<br>
<blockquote
cite="mid:B8BBB672-5A4C-4B0B-A87A-555DDA1339C0@gmail.com"
type="cite">
<div class="">
<div style="font-family:'Helvetica Neue';font-size:14px;"
class="">- Allocations marked as 'ALLOCATED FINAL' can not be
transferred or sub-allocated;</div>
</div>
</blockquote>
I would agree with the 'no transfer' ban but do not agree with the
no sub-allocation. If someone wants to 'sub-allocate', they can
easily create assignments. This can not be enforced except if we
forbid the creation of sub-allocated PA objects using business
rules. But even if we use business rules, that will only block the
creation of sub-allocation blocks to the LIRs that really want to
follow every word of the policy, the abusers will continue to abuse.<br>
<blockquote
cite="mid:B8BBB672-5A4C-4B0B-A87A-555DDA1339C0@gmail.com"
type="cite">
<div class="">
<div style="font-family:'Helvetica Neue';font-size:14px;"
class="">- Any LIR can hold up to a /22 of 'ALLOCATED FINAL'
address space, regardless of how they got it;</div>
</div>
</blockquote>
What if an LIR has already received a transfer of a 'last-/8' block.
They have paid for it and the RIPE NCC has approved the transfer.
Requesting those back would lead to the NCC being sued over and over
again.<br>
<br>
As we have discussed privately, you do not intend for this policy
proposal to apply retroactively. If that is the case, then you need
to figure out a solution for those that will have 2 or more
'last-/8' blocks before this proposal becomes policy. That is why I
believe a second version is needed as this one is not clear.<br>
<blockquote
cite="mid:B8BBB672-5A4C-4B0B-A87A-555DDA1339C0@gmail.com"
type="cite">
<div class="">
<div style="font-family:'Helvetica Neue';font-size:14px;"
class="">- Any excess space will have to be returned to the
RIEP NCC within 180 days (however I don't intend that this is
applied retroactively); <br>
</div>
</div>
</blockquote>
If you want this not to be applied retroactively, it must be very
clear in the policy proposal. It looks like it would not apply
retroactively the way this proposal is worded but it's not very
clear. <br>
<blockquote
cite="mid:B8BBB672-5A4C-4B0B-A87A-555DDA1339C0@gmail.com"
type="cite">
<div class="">
<div style="font-family:'Helvetica Neue';font-size:14px;"
class="">- DNS reverse delegation will be limited to the LIR
itself, and is limited to a total of a /22 in space.</div>
</div>
</blockquote>
How can the NCC enforce this? Why should 'ALLOCATED FINAL' IPv4
blocks have specific rules regarding reverse delegation but not the
rest? Will this not be confusing? <br>
<blockquote
cite="mid:B8BBB672-5A4C-4B0B-A87A-555DDA1339C0@gmail.com"
type="cite">
<div class="">
<div style="font-family:'Helvetica Neue';font-size:14px;"
class=""><br class="">
</div>
<div style="font-family:'Helvetica Neue';font-size:14px;"
class="">And, outside of policy but enforceable as business
rules following from this policy proposal:</div>
<div style="font-family:'Helvetica Neue';font-size:14px;"
class="">- No RPKI for any 'ALLOCATED FINAL' blocks over a
single /22</div>
<div style="font-family:'Helvetica Neue';font-size:14px;"
class="">- No routing registry entries for any 'ALLOCATED
FINAL' blocks over a single /22</div>
</div>
</blockquote>
Just like with reverse delegation, I oppose to having 'special'
rules for the routing of 'ALLOCATED FINAL' blocks. <br>
<br>
Additionally, and this is the reason I mainly oppose, if this
proposal would become policy it would force every single small
company that needs IPv4 addresses for its operations to hire someone
to handle the communication with the RIPE NCC, the routing and the
reverse delegation for their 'last-/8 allocation'.<br>
<br>
Currently most customers of LIRs are redirected to the RIPE NCC (to
become LIRs and get a /22) if they need (a few) IP addresses. This
policy proposal forbids the LIR to manage the address space of the
small - newly created - LIR (their customer).<br>
<br>
We currently manage and maintain the address space of several
customers of ours (LIRs). This policy proposal aims to request each
of our customers to hire their own IT team because an other entity
can not manage their 'last-/8' allocation (but it's ok for the other
allocations they hold). <br>
Forbidding routing/reverse dns to be managed by the large ISP or a
consultant is one of the big problems of this proposal. Also, this
can be easily worked around and I doubt the NCC can even enforce
this rule.<br>
<blockquote
cite="mid:B8BBB672-5A4C-4B0B-A87A-555DDA1339C0@gmail.com"
type="cite">
<div class="">
<div style="font-family:'Helvetica Neue';font-size:14px;"
class=""><br class="">
</div>
<div style="font-family:'Helvetica Neue';font-size:14px;"
class="">Basically, every LIR gets 1 allocation, and if you no
longer need it or you end up having more, you have to return
the excess. All the extra limitations should be workable if
you're using the space the way it was intended, but make it
unattractive to collect allocations for other purposes.</div>
<div style="font-family:'Helvetica Neue';font-size:14px;"
class=""><br class="">
</div>
<div style="font-family:'Helvetica Neue';font-size:14px;"
class="">Let's hear your thoughts. I'll be at the RIPE meeting
next week where I'll be talking about this proposal during the
first APWG session.</div>
</div>
</blockquote>
<br>
NEWTEXT: 5.1.5: An allocation marked "ALLOCATED FINAL" is valid as
long as it remains with the LIR it was allocated to. If an LIR, due
to mergers, acquisitions or other means gains additional allocations
marked "ALLOCATED FINAL", all but the equivalent of a single /22
will be de-registered by the RIPE NCC within 180 days.<br>
<br>
Let's take the following example:<br>
<br>
LIR A receives their 'last-/8' allocation in 2014.<br>
In 2015 it transfers (transfer or merger) an other 'last-/8'
allocation. <br>
In 2016Q2 this policy proposal is approved and the RIPE NCC updates
the RIPE Database objects. Now they have two 'ALLOCATED FINAL'
blocks.<br>
In 2016Q4 they want to transfer a non-last-/8 allocation, will they
be forced to return one of the two ALLOCATED FINAL blocks? <br>
<br>
If not, why?<br>
If yes, how long do you think it will take until the NCC is taken to
court?<br>
<br>
<br>
NEWTEXT: 5.4: [...] Sub-allocations cannot be made from allocations
with a status of "ALLOCATED FINAL". The meanings of the various
"status:" attribute values are described in Section 7.0.<br>
<br>
Why? What would be the difference between a Sub-allocation and an
Assignment in this case?<br>
Are we really adding stuff in the policy that works against the
registration goal? <br>
<br>
<br>
NEWTEXT 3.0: [...] For "ALLOCATED FINAL" IPv4 address space,
authority may not be delegated to another party, and the reverse
delegation will be limited to a total of a /22 of IPv4 address
space.<br>
<br>
How can this be enforced? Since when is the community or the NCC
getting involved in how someone manages their network and/or reverse
delegation?<br>
Again, how long do you think it will take before the RIPE NCC is
taken to court for implementing a policy proposal that forces new
(small) LIRs (or even older, bigger ones) to cancel their contracts
with their ISP or consultants for the management of their
resources/LIR?<br>
<blockquote
cite="mid:B8BBB672-5A4C-4B0B-A87A-555DDA1339C0@gmail.com"
type="cite">
<div class="">
<div style="font-family:'Helvetica Neue';font-size:14px;"
class=""><br class="">
</div>
<div style="font-family:'Helvetica Neue';font-size:14px;"
class="">Kind regards,</div>
<div style="font-family:'Helvetica Neue';font-size:14px;"
class=""><br class="">
</div>
<div style="font-family:'Helvetica Neue';font-size:14px;"
class="">Remco van Mook</div>
<div style="font-family:'Helvetica Neue';font-size:14px;"
class="">(no hats)</div>
</div>
<div class=""><br class="">
</div>
</blockquote>
Regards,<br>
Elvis<br>
(wearing a fedora while writing this reply)<br>
<blockquote
cite="mid:B8BBB672-5A4C-4B0B-A87A-555DDA1339C0@gmail.com"
type="cite"><br class="">
<div>
<blockquote type="cite" class="">
<div class="">On 17 May 2016, at 14:05 , Marco Schmidt <<a
moz-do-not-send="true" href="mailto:mschmidt@ripe.net"
class=""><a class="moz-txt-link-abbreviated" href="mailto:mschmidt@ripe.net">mschmidt@ripe.net</a></a>> wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<div class="">Dear colleagues,<br class="">
<br class="">
A new RIPE Policy proposal 2016-03, "Locking Down the
Final /8 Policy"<br class="">
is now available for discussion.<br class="">
<br class="">
The goal of this proposal is to limit IPv4 from the
remaining address pool<br class="">
to one /22 per LIR (regardless of how it was received).<br
class="">
These “final /22” allocations will receive a separate
status with several restrictions:<br class="">
<br class="">
- These allocation are not transferrable<br class="">
- LIRs may only retain one final /22 following a merger
or acquisition<br class="">
- Sub-allocations are not possible<br class="">
- Reverse delegation authority can not delegated to
another party<br class="">
<br class="">
You can find the full proposal at:<br class="">
<br class="">
<a moz-do-not-send="true"
href="https://www.ripe.net/participate/policies/proposals/2016-03"
class="">https://www.ripe.net/participate/policies/proposals/2016-03</a><br
class="">
<br class="">
We encourage you to review this proposal and send your
comments to<br class="">
<<a moz-do-not-send="true"
href="mailto:address-policy-wg@ripe.net" class="">address-policy-wg@ripe.net</a>>
before 15 June 2016.<br class="">
<br class="">
Regards<br class="">
<br class="">
Marco Schmidt<br class="">
Policy Development Officer<br class="">
RIPE NCC<br class="">
<br class="">
</div>
</div>
</blockquote>
</div>
<br class="">
</blockquote>
<br>
</body>
</html>