<html><body>
<p><font size="2" face="sans-serif">Hi all,</font><br>
<font size="2" face="sans-serif">I support this proposal, too,</font><br>
<font size="2" face="sans-serif">Thanks John</font><br>
<font size="2" face="sans-serif"><br>
Mit freundlichen Gr��en / Best Regards<br>
<br>
Alexander Brinkmann<br>
Tel.: +49 7132 949665<br>
Fax: +49 7132 9479665<br>
EMail: alexander.brinkmann@kaufland.com<br>
KI 967850 IT International / IT Governance / Netzwerk Design und IT-Sicherheit<br>
Office:<br>
Haller Stra�e 60<br>
74189 Weinsberg</font><br>
<br>
<font size="2" face="Arial"><a href="http://www.kaufland.de">http://www.kaufland.de</a></font><font size="2" face="Arial"> </font><br>
<font size="2" face="Arial"><a href="http://www.spannende-it.de">http://www.spannende-it.de</a></font><br>
<br>
<img src="cid:1__=4EBBF4C2DFA73AD38f9e8a93df93@kaufland.de" width="255" height="182"><br>
<br>
<font size="2" face="Arial">Kaufland Informationssysteme GmbH & Co. KG</font><br>
<font size="2" face="Arial">Postfach 12 53 - 74149 Neckarsulm<br>
Kommanditgesellschaft<br>
Sitz: Neckarsulm<br>
Registergericht: Stuttgart HRA 104163</font><br>
<br>
<img src="cid:2__=4EBBF4C2DFA73AD38f9e8a93df93@kaufland.de" width="218" height="27"><br>
<font size="1" color="#800080" face="sans-serif">----- Weitergeleitet von Alexander Brinkmann/IS/KI/KAUFLAND</font><font size="1" color="#800080" face="sans-serif"> am 26.05.2015 11:36</font><font size="1" color="#800080" face="sans-serif"> -----</font><br>
<br>
<font size="1" color="#5F5F5F" face="sans-serif">Von:       </font><font size="1" face="sans-serif">Carlos G�mez Mu�oz <carlosf.gomez@seap.minhap.es></font><br>
<font size="1" color="#5F5F5F" face="sans-serif">An:        </font><font size="1" face="sans-serif">John.Collins@BIT.admin.ch, address-policy-wg@ripe.net</font><br>
<font size="1" color="#5F5F5F" face="sans-serif">Kopie:     </font><font size="1" face="sans-serif">mschmidt@ripe.net</font><br>
<font size="1" color="#5F5F5F" face="sans-serif">Datum:     </font><font size="1" face="sans-serif">26.05.2015 11:03</font><br>
<font size="1" color="#5F5F5F" face="sans-serif">Betreff:   </font><font size="1" face="sans-serif">Re: [address-policy-wg] 2015-03 New Policy Proposal (Assessment Criteria for IPv6 Initial Allocation Size)</font><br>
<font size="1" color="#5F5F5F" face="sans-serif">Gesendet von:      </font><font size="1" face="sans-serif">"address-policy-wg" <address-policy-wg-bounces@ripe.net></font><br>
<hr width="100%" size="2" align="left" noshade style="color:#8091A5; "><br>
<br>
<br>
<tt><font size="2">I support the proposal with the addition suggested by John.<br>
<br>
Best regards,<br>
<br>
Carlos G�mez<br>
<br>
es.seap Spanish government LIR<br>
<br>
El 22/05/2015 a las 11:45, John.Collins@BIT.admin.ch escribi�:<br>
> Dear Colleagues,<br>
><br>
> On Tue Apr 28 Marco Schmidt wrote:<br>
> -------------------------------------------------<br>
><br>
>> A proposed change to the RIPE Document "IPv6 Address Allocation and Assignment Policy" now is open for discussion.<br>
>><br>
>> The proposal aims to expand the criteria for evaluating initial IPv6 allocations larger than a /29. The RIPE NCC would consider additional aspects beyond only the number of existing users and extent of the organisation's infrastructure.<br>
>><br>
>> You can find the full proposal at:<br>
>><br>
>>                 </font></tt><tt><font size="2"><a href="https://www.ripe.net/participate/policies/proposals/2015-03">https://www.ripe.net/participate/policies/proposals/2015-03</a></font></tt><tt><font size="2"><br>
>><br>
><br>
> I supported this proposal is a previous post and I still do.  However as Marco said in his original message above "additional aspects beyond only the number of existing users and extent of the organisation's infrastructure" would be considered by the RIPE-NCC.  I want to make a suggestion for such "additional aspects".   It might make sense that some inclusive evaluation criteria are listed in the policy.  This would make the evaluation task of the RIPE-NCC easier and would also simplify allocation requests from LIRs.<br>
><br>
> I suggest that the following text replaces the existing text in the policy in section 5.1.2 (Initial allocation size)<br>
><br>
> -------------------- begin ------------------------------------------<br>
> "Organisations that meet the initial allocation criteria are eligible to receive an initial allocation of /32. For allocations up to /29 no additional documentation is necessary.<br>
><br>
> Organisations may qualify for an initial allocation greater than /29 by submitting documentation that reasonably justifies the request. If so, the allocation size will be based on the number of users, the extent of the organisation's infrastructure, the hierarchical and geographical structuring of the organisation, the segmentation of infrastructure for security and the planned longevity of allocation."<br>
> -------------------- end --------------------------------------------<br>
><br>
><br>
> Here are some remarks concerning the "additional aspects" (inclusive/positive criteria in the suggested text):<br>
><br>
> number of users, the extent of the organisation's infrastructure<br>
> ----------------------------------------------------------------------------------<br>
> This is like the status quo. It allows the RIPE-NCC to consider the number of existing and future (note the removal of the word "existing" in the suggested policy text) users and the organisation's infrastructure when evaluating address plans.   It seems logical that these criteria are included in the evaluation of requests as there is a relationship between the number users and infrastructure and the needed addresses.  The more users and the bigger the infrastructure, the more address are needed.<br>
><br>
> hierarchical and geographic structuring<br>
> ----------------------------------------------------<br>
> Allows the RIPE-NCC to consider requirements of (national or multi-national) commercial organisations, governments and military organisations like the UK-MOD concerning the reflection of hierarchy and geographical coverage in the address plan. Even autonomous (sub)organisations are catered for by the 'hierarchy' aspects.<br>
><br>
> the segmentation of infrastructure for security<br>
> ------------------------------------------------------------<br>
> Allows the RIPE-NCC to consider address plans which cater for the separation of infrastructures for security reasons which might include data protection, network and system protection and business continuity assurance for disaster recovery.<br>
><br>
> planned longevity of allocation<br>
> ----------------------------------------<br>
> Allows the RIPE-NCC to take future planning of organisations into account when they reserve enough address space for many years in an effort to avoid renumbering and (at the end of the day) to avoid undue de-aggregation.  I do not propose that a specific number of years is mentioned as the interpretation of longevity for one organisation will differ from that of another organisation.  As RIPE-NCC's Andrea Cima pointed out at RIPE70, some LIRs plan in terms of 20 years, others in terms of 10 years etc.<br>
><br>
><br>
> Finally, I would like to call on the many "Enterprise LIRs" out there to consider this suggestion and if it makes sense to support it on the mailing-list.   Also I ask the many "ISP LIRs" to lend their consideration and support.   Your feedback is important.  The success of IPv6 depends on both LIR categories gaining access to sufficient address space.<br>
><br>
> And thank you very much for reading this far!<br>
><br>
> Best Regards,<br>
> John<br>
><br>
><br>
><br>
<br>
<br>
</font></tt></body></html>