<html xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=utf-8"><meta name=Generator content="Microsoft Word 15 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
{font-family:Helvetica;
panose-1:0 0 0 0 0 0 0 0 0 0;}
@font-face
{font-family:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:"Times New Roman \(Cuerpo en alfa";
panose-1:2 2 6 3 5 4 5 2 3 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0cm;
margin-right:0cm;
margin-bottom:0cm;
margin-left:36.0pt;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
p.msonormal0, li.msonormal0, div.msonormal0
{mso-style-name:msonormal;
mso-margin-top-alt:auto;
margin-right:0cm;
mso-margin-bottom-alt:auto;
margin-left:0cm;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
span.apple-tab-span
{mso-style-name:apple-tab-span;}
span.EstiloCorreo19
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:70.85pt 3.0cm 70.85pt 3.0cm;}
div.WordSection1
{page:WordSection1;}
/* List Definitions */
@list l0
{mso-list-id:1738281255;
mso-list-type:hybrid;
mso-list-template-ids:-925097450 1271433436 67764227 67764229 67764225 67764227 67764229 67764225 67764227 67764229;}
@list l0:level1
{mso-level-start-at:0;
mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:Wingdings;
mso-fareast-font-family:"Times New Roman";
mso-bidi-font-family:"Times New Roman \(Cuerpo en alfa";}
@list l0:level2
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:"Courier New";}
@list l0:level3
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:Wingdings;}
@list l0:level4
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:Symbol;}
@list l0:level5
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:"Courier New";}
@list l0:level6
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:Wingdings;}
@list l0:level7
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:Symbol;}
@list l0:level8
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:"Courier New";}
@list l0:level9
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:Wingdings;}
ol
{margin-bottom:0cm;}
ul
{margin-bottom:0cm;}
--></style></head><body lang=ES link=blue vlink=purple><div class=WordSection1><p class=MsoNormal><span lang=EN-US style='font-size:12.0pt;mso-fareast-language:EN-US'>Hi Owen,</span><span lang=EN-US style='font-size:12.0pt;color:black;mso-fareast-language:EN-US'> <o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-size:12.0pt;mso-fareast-language:EN-US'><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-size:12.0pt;mso-fareast-language:EN-US'><o:p> </o:p></span></p><div><div><p class=MsoNormal style='margin-left:35.4pt'>El 7/11/19 21:21, "Owen DeLong" <<a href="mailto:owen@delong.com">owen@delong.com</a>> escribió:<o:p></o:p></p></div></div><div><p class=MsoNormal style='margin-left:35.4pt'><o:p> </o:p></p></div><p class=MsoNormal style='margin-left:35.4pt'><o:p> </o:p></p><div><p class=MsoNormal style='margin-left:35.4pt'><br><br><o:p></o:p></p><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><div><p class=MsoNormal style='margin-left:35.4pt'>On Nov 7, 2019, at 11:41 , JORDI PALET MARTINEZ <<a href="mailto:jordi.palet@consulintel.es">jordi.palet@consulintel.es</a>> wrote:<o:p></o:p></p></div><p class=MsoNormal style='margin-left:35.4pt'><o:p> </o:p></p><div><p class=MsoNormal style='margin-left:35.4pt'><span style='font-size:9.0pt;font-family:Helvetica'>Hi Owen,<br><br>Thanks for the inputs, below in-line with ->.<br><br><br></span><span style='font-size:9.0pt;font-family:"Courier New"'></span><span style='font-size:9.0pt;font-family:Helvetica'>El 7/11/19 18:53, "Owen DeLong" <</span><a href="mailto:owen@delong.com"><span style='font-size:9.0pt;font-family:Helvetica'>owen@delong.com</span></a><span style='font-size:9.0pt;font-family:Helvetica'>> escribió:<br><br> Jordi,<br><br> Comments on specific sections:<br><br> 5.7<br> <span class=apple-tab-span> </span>First, this policy should apply to all organizations with justified needs. There’s no reason<br> <span class=apple-tab-span> </span>to exclude organizations who could get resources from AfriNIC from using the transfer<br> <span class=apple-tab-span> </span>policy if they so choose. Further, the application should be to both recipient organizations<br> <span class=apple-tab-span> </span>(as stated) and source organizations (excluded by present language).<br><br> <span class=apple-tab-span> </span>Recommended alternate language:<br><br> <span class=apple-tab-span> </span>This policy applies to organizations with a justified need for IPv4 resources<br> <span class=apple-tab-span> </span>(recipients) and organizations with IPv4 resources that are no longer needed by<br> <span class=apple-tab-span> </span>the organization (sources).<br><br>-> Good point, you're right on that, because it is clear that we are talking about AFRINIC, when enters in phase 2.<br><br> 5.7.2<br><br> <span class=apple-tab-span> </span>Policy should set source criteria only if the source is within the AfriNIC region. Source<br> <span class=apple-tab-span> </span>criteria for sources outside of AfriNIC should be set by the source RIR. Further, a<br> <span class=apple-tab-span> </span>source organization should not be permanently barred from acquiring additional<br> <span class=apple-tab-span> </span>resources, so I have added a suggestion to allow them to acquire resources via<br> <span class=apple-tab-span> </span>transfer 24 months after acting as a source.<br><br> <span class=apple-tab-span> </span>Recommended alternate language:<br><br> <span class=apple-tab-span> </span>5.7.2 — as is<br><br> <span class=apple-tab-span> </span>5.7.2.1 A source must be validated by the applicable source RIR according to their<br> <span class=apple-tab-span> </span>policies and procedures. A source within the AfriNIC region must be in good<br> <span class=apple-tab-span> </span>standing (all invoices paid) and must be the rightful registrant of the resources<br> <span class=apple-tab-span> </span>to be transferred and there must be no dispute as to the status of said resources.<br><br>-> I'm fine with this<br><br> <span class=apple-tab-span> </span>5.7.2.2 Source entities will not be eligible to receive any further IPv4 address allocations<br> <span class=apple-tab-span> </span>or assignments from AfriNIC. Source entities may, if they can show justified<br> <span class=apple-tab-span> </span>need receive resources via transfer after a period of not less than 24 months<br> <span class=apple-tab-span> </span>has elapsed from their last outbound transfer.<br><br><br>-> We have a long discussion about this a about 3 months ago. I'm happy with your proposed text (previously we had 12 months) but I think it was clear that "if you have transferred resources, and need more, use the profit from that transfer to buy more", otherwise, even if 24 months is a long period, is prone to speculation, or even more ... you are using reserves that are better serving people that never transferred resources. Anyway, I will love to hear other voices on this before doing any change here.</span><o:p></o:p></p></div></blockquote><div><p class=MsoNormal style='margin-left:35.4pt'><o:p> </o:p></p></div><p class=MsoNormal style='margin-left:35.4pt'>Note that my wording does not allow them to receive resources by any mechanism other than transfer<o:p></o:p></p></div><div><p class=MsoNormal style='margin-left:35.4pt'>once they have made an outbound transfer.<o:p></o:p></p></div><div><p class=MsoNormal style='margin-left:35.4pt'><o:p> </o:p></p></div><div><p class=MsoNormal style='margin-left:35.4pt'>But it doesn’t allow speculation by repeated transfers because it introduces a 24 month lag sale and<o:p></o:p></p></div><div><p class=MsoNormal style='margin-left:35.4pt'>future acquisition by transfer.<o:p></o:p></p></div><div><p class=MsoNormal style='margin-left:35.4pt'><o:p> </o:p></p></div><div><p class=MsoNormal style='margin-left:35.4pt'>As such, I think this achieves your intended result.<o:p></o:p></p></div><div><p class=MsoNormal style='margin-left:35.4pt'><o:p> </o:p></p><p class=MsoNormal><span style='font-size:12.0pt;font-family:Wingdings'>à</span><span lang=EN-US style='font-size:12.0pt'> You’re right I misinterpreted your point before. I buy it.<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-size:12.0pt'><o:p> </o:p></span></p></div><div><p class=MsoNormal style='margin-left:35.4pt'>While that’s also true of the language in the PDF, I think the intent is not as clear since no mention of<o:p></o:p></p></div><div><p class=MsoNormal style='margin-left:35.4pt'>permission of inbound transfers is made, only the prohibition of Allocation or Assignment.<o:p></o:p></p></div><div><p class=MsoNormal style='margin-left:35.4pt'>I believe my proposed language has the advantage of both preventing flipping transfers and also<o:p></o:p></p></div><div><p class=MsoNormal style='margin-left:35.4pt'>making it clear that inbound future transfers can be achieved if needed.<o:p></o:p></p></div><div><p class=MsoNormal style='margin-left:35.4pt'><o:p> </o:p></p></div><div><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><div><p class=MsoNormal style='margin-left:35.4pt'><span style='font-size:9.0pt;font-family:Helvetica'> <span class=apple-tab-span> </span>5.7.2.3 An organization which has received resources in the AfriNIC registry within the<br> <span class=apple-tab-span> </span>preceding twelve months will not be approved as a transfer source.<br><br>-> Same meaning, shorter and more clarity. I like it. Small modification:<br><br>5.7.2.3 An organization which has received IPv4 resources from AFRINIC within preceding 12 months will not be approved as a transfer source.</span><o:p></o:p></p></div></blockquote><div><p class=MsoNormal style='margin-left:35.4pt'><o:p> </o:p></p></div><p class=MsoNormal style='margin-left:35.4pt'>Agreed… An unfortunate omission on my part.<o:p></o:p></p></div><div><p class=MsoNormal style='margin-left:35.4pt'><br><br><o:p></o:p></p><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><div><p class=MsoNormal style='margin-left:35.4pt'><span style='font-size:9.0pt;font-family:Helvetica'> 5.7.3.1 is a bit vaguely worded. Suggest:<br><br> <span class=apple-tab-span> </span>5.7.3.1 Recipient organizations within the AfriNIC service region must be approved<br> <span class=apple-tab-span> </span>by AfriNIC staff using the same policies and procedures as if the request<br> <span class=apple-tab-span> </span>were being satisfied from the AfriNIC free pool.<br><br><br>-> fine for me as well, a bit shorter:<br><br>Recipient organizations within the AFRINIC service region must be approved with the same policies and procedures as if the request were being satisfied from the AFRINIC pool.</span><o:p></o:p></p></div></blockquote><div><p class=MsoNormal style='margin-left:35.4pt'><o:p> </o:p></p></div><p class=MsoNormal style='margin-left:35.4pt'>This is also workable.<o:p></o:p></p></div><div><p class=MsoNormal style='margin-left:35.4pt'><br><br><o:p></o:p></p><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><div><p class=MsoNormal style='margin-left:35.4pt'><span style='font-size:9.0pt;font-family:Helvetica'> 5.7.3.2 is also a bit convoluted. Suggest:<br><br> <span class=apple-tab-span> </span>5.7.3.2 Recipients in other RIRs must be approved by the staff in that RIR according<br> <span class=apple-tab-span> </span>to that RIR’s policies and procedures.<br><br>-> again agree and shorter:<br>Recipients in other RIRs must be approved according to that RIR policies and procedures.</span><o:p></o:p></p></div></blockquote><div><p class=MsoNormal style='margin-left:35.4pt'><o:p> </o:p></p></div><p class=MsoNormal style='margin-left:35.4pt'>Almost…<o:p></o:p></p></div><div><p class=MsoNormal style='margin-left:35.4pt'><o:p> </o:p></p></div><div><p class=MsoNormal style='margin-left:35.4pt'>Recipients in other RIRs must be approved according to that RIR’s policies and procedures.<o:p></o:p></p></div><div><p class=MsoNormal style='margin-left:35.4pt'><o:p> </o:p></p></div><div><p class=MsoNormal style='margin-left:35.4pt'>(The ’s to make a possessive relationship to the policies and procedures is needed in English syntax).<o:p></o:p></p></div><div><p class=MsoNormal style='margin-left:35.4pt'><br><br><o:p></o:p></p><p class=MsoNormal><span style='font-size:12.0pt;font-family:Wingdings'>à</span><span style='font-size:12.0pt'> <span lang=EN-US>This is why native speakers are needed. Thanks!<o:p></o:p></span></span></p><p class=MsoNormal><span lang=EN-US style='font-size:12.0pt'><o:p> </o:p></span></p><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><div><p class=MsoNormal style='margin-left:35.4pt'><span lang=EN-US style='font-size:9.0pt;font-family:Helvetica'> 5.7.3.3 is unnecessary and incorrect in some cases. </span><span style='font-size:9.0pt;font-family:Helvetica'>Many organizations that receive<br> resources in the ARIN region are not members, for example. Any intended effect<br> in 5.7.3.3 is a subset of the requirements already expressed in 5.7.3.2 and I presume<br> that the unintended effects do not need to be preserved. Suggest striking 5.7.3.3<br> completely.<br><br>-> You're right with the new wording we don't need to say what to do if in AFRINIC or other regions, is already implicit now.<br><br><br> 5.7.4 — I think there is a better way to express the actual intent here… Suggest:<br><br> <span class=apple-tab-span> </span>5.7.4 Transfer of ASN with resources<br><br> <span class=apple-tab-span> </span>In the case where the majority of an operating network, including the<br> <span class=apple-tab-span> </span>addresses and the physical infrastructure are being transferred, any<br> <span class=apple-tab-span> </span>applicable ASN(s) may also be transferred at the same time in order<br> <span class=apple-tab-span> </span>to preserve operational integrity and expedience.<br><br>-> I don't think we should mention "and the physical infrastructure" as it may not be the case. I suggest a this:<br><br>5.7.4 Transfer or ASN with IPv4 Resources<br><br>In the case where the majority of the IPv4 resources are being transferred, any relevant ASN(s) may also be transferred at the same time, if the relevant policies are fulfilled.</span><o:p></o:p></p></div></blockquote><div><p class=MsoNormal style='margin-left:35.4pt'><o:p> </o:p></p></div><p class=MsoNormal style='margin-left:35.4pt'>I don’t think that the ASN transfer should be allowed if the physical infrastructure isn’t moving. In such a case, renumbering the peering sessions is trivial compared to migrating the functionality.<o:p></o:p></p></div><div><p class=MsoListParagraph><span lang=EN-US style='font-size:12.0pt'><o:p> </o:p></span></p></div><div><p class=MsoNormal style='margin-left:35.4pt'><span lang=EN-US>The migration of an ASN is only useful/necessary in a case where the ownership of the “service” for lack of a better term is being transferred in place and there is a desire for continuity of operations without disruption.<o:p></o:p></span></p></div><div><p class=MsoNormal style='margin-left:35.4pt'><span lang=EN-US><o:p> </o:p></span></p></div><div><p class=MsoNormal style='margin-left:35.4pt'>If moving to new hardware, then the disruption of new peering sessions with a different ASN is the least of the difficulties and there is no need to transfer the ASN.<o:p></o:p></p></div><div><p class=MsoNormal style='margin-left:35.4pt'><o:p> </o:p></p><p class=MsoNormal style='margin-left:35.4pt'><o:p> </o:p></p><p class=MsoListParagraph style='margin-left:0cm;text-indent:0cm;mso-list:l0 level1 lfo1'><![if !supportLists]><span lang=EN-US style='font-size:12.0pt;font-family:Wingdings'><span style='mso-list:Ignore'>è<span style='font:7.0pt "Times New Roman"'> </span></span></span><![endif]><span lang=EN-US style='font-size:12.0pt'>While I fully agree with you, this has been requested by the community, and expressed both by the staff in the implementation reports (in several meetings) and in the impact analysis. So again, I’m happy to heard about other opinions on this.<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-size:12.0pt'><o:p> </o:p></span></p><p class=MsoNormal style='margin-left:35.4pt'><span lang=EN-US><br><br><o:p></o:p></span></p><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><div><p class=MsoNormal style='margin-left:35.4pt'><span lang=EN-US style='font-size:9.0pt;font-family:Helvetica'> </span><span style='font-size:9.0pt;font-family:Helvetica'>5.7.5 — This doesn’t belong in the policy text and should be provided instead as<br> <span class=apple-tab-span> </span>guidance to the board and staff for scheduled implementation of the policy.<br><br> <span class=apple-tab-span> </span>Leaving this in the policy text results in a policy manual which contains an<br> <span class=apple-tab-span> </span>ever growing set of anachronisms.<br><br>-> The community asked for something explicit in the policy text. If the staff can confirm that we don't need that as part of the policy text and the community accepts that, I'm fine as well. However, if you look at the exhaustion phase, etc., there is timing there. Note that I'm also convinced that it is very difficult to get this proposal, if it reach consensus in December, to be implemented before moving to phase 2, but the staff don't think so (they said it can be implemented in 6 months), and expressed it in the analysis impact (requesting timing as part of the policy, if I got it correctly).</span><o:p></o:p></p></div></blockquote><div><p class=MsoNormal style='margin-left:35.4pt'><o:p> </o:p></p></div><p class=MsoNormal style='margin-left:35.4pt'>Policies which define when we enter certain phases of exhaustion cannot be avoided. Naturally, they will need to be cleaned up later as they become anachronistic as well.<o:p></o:p></p></div><div><p class=MsoNormal style='margin-left:35.4pt'><o:p> </o:p></p></div><div><p class=MsoNormal style='margin-left:35.4pt'>However, I see no reason to increase that need unnecessarily. The community can include instructions to board and staff about implementation in the problem statement, or<o:p></o:p></p></div><div><p class=MsoNormal style='margin-left:35.4pt'>summary sections of the proposal without needing them enshrined in the policy text, IMHO.<o:p></o:p></p></div><div><p class=MsoNormal style='margin-left:35.4pt'><o:p> </o:p></p><p class=MsoListParagraph style='margin-left:0cm;text-indent:0cm;mso-list:l0 level1 lfo1'><![if !supportLists]><span lang=EN-US style='font-size:12.0pt;font-family:Wingdings'><span style='mso-list:Ignore'>è<span style='font:7.0pt "Times New Roman"'> </span></span></span><![endif]><span lang=EN-US style='font-size:12.0pt'>Can we hear the opinion of staff on this? I prefer to avoid to remove that from the policy text, and then have the same observation in the next impact analysis!<o:p></o:p></span></p><p class=MsoNormal style='margin-left:35.4pt'><span lang=EN-US> <o:p></o:p></span></p></div><div><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><div><p class=MsoNormal style='margin-left:35.4pt'><span lang=EN-US style='font-size:9.0pt;font-family:Helvetica'> </span><span style='font-size:9.0pt;font-family:Helvetica'>5.7.6<span class=apple-tab-span> </span>Who determines what information is or is not confidential? Policy should<br> <span class=apple-tab-span> </span>specify exactly what is required to be disclosed and if it wishes to make<br> <span class=apple-tab-span> </span>additional disclosures optional, it should state what those are and that<br> <span class=apple-tab-span> </span>they should be published if disclosed. The list in the existing proposal<br> <span class=apple-tab-span> </span>is a good start on the minimum mandatory information. If we want that<br> <span class=apple-tab-span> </span>as the extent of the policy, suggested rewording:<br><br> <span class=apple-tab-span> </span>5.7.6 Required Disclosures for Transfers<br> <span class=apple-tab-span> </span>Parties shall be required to disclose and AfriNIC shall publish<br> <span class=apple-tab-span> </span>in a specific location, a history of all completed transfers including<br> <span class=apple-tab-span> </span>at least the following information about each transfer:<br><br> <span class=apple-tab-span> </span>+<span class=apple-tab-span> </span>Date of the Transfer<br> <span class=apple-tab-span> </span>+<span class=apple-tab-span> </span>Identification/description of the Resources Transferred (e.g. 192.168.48.0/20, AS3223959)<br> <span class=apple-tab-span> </span>+<span class=apple-tab-span> </span>Source RIR<br> <span class=apple-tab-span> </span>+<span class=apple-tab-span> </span>Source ORG-ID<br> <span class=apple-tab-span> </span>+<span class=apple-tab-span> </span>Recipient RIR<br> <span class=apple-tab-span> </span>+<span class=apple-tab-span> </span>Recipient ORG-ID<br><br>-> Agree with your confidentiality point. I think a shorter version may be:<br><br>5.7.6 Required Disclosure for Transfers<br><br>AFRINIC shall publish in a specific location, a history of all completed transfers, including at least: Date of each transfer, identification/description of resources transferred, source RIR and organization, recipient RIR and organization.</span><o:p></o:p></p></div></blockquote><div><p class=MsoNormal style='margin-left:35.4pt'><o:p> </o:p></p></div><p class=MsoNormal style='margin-left:35.4pt'>Also workable. My intent in making it a bit more explicit and using bullet points was to make future revision to the requirements a simpler matter should the community desire to add or remove required information.<o:p></o:p></p></div><div><p class=MsoNormal style='margin-left:35.4pt'><o:p> </o:p></p></div><div><p class=MsoNormal style='margin-left:35.4pt'>Owen<o:p></o:p></p></div><div><p class=MsoNormal style='margin-left:35.4pt'><br><br><o:p></o:p></p><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><div><p class=MsoNormal style='margin-left:35.4pt'><span style='font-size:9.0pt;font-family:Helvetica'><br> Owen<br><br style='caret-color: rgb(0, 0, 0);font-variant-caps: normal;text-align:start;-webkit-text-stroke-width: 0px;word-spacing:0px'><br></span><o:p></o:p></p><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><p class=MsoNormal style='margin-left:35.4pt'><span style='font-size:9.0pt;font-family:Helvetica'>On Nov 7, 2019, at 07:50 , JORDI PALET MARTINEZ via RPD <<a href="mailto:rpd@afrinic.net">rpd@afrinic.net</a>> wrote:<br><br>Hi all,<br><br>As I've indicated last Monday, during the weekend I've updated the policy proposal AFPUB-2019-IPv4-002-DRAFT02 "IPv4 Inter-RIR Resource Transfers (Comprehensive Scope)" and I'm attaching it here in PDF, so all can read even if not yet published in the website.<br><br>This update tries to address:<br>1) All the issues and inputs from the RPD List and the previous meeting.<br>2) The staff impact analysis.<br><br>At the same time, as it was clear that the community is not interested in a "legacy" only policy proposal (I also expressed myself my concern about that during the meeting, but I wanted to offer "both" choices, just in case), I'm formally withdrawing the proposal AFPUB-2019-IPv4-001-DRAFT01 "IPv4 Inter-RIR Legacy Resource Transfers".<br><br>Thanks in advance for reading and contributing!<br><br>Regards,<br>Jordi<br>@jordipalet<br><br><br><br><br><br>**********************************************<br>IPv4 is over<br>Are you ready for the new Internet ?<br><a href="http://www.theipv6company.com">http://www.theipv6company.com</a><br>The IPv6 Company<br><br>This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.<br><br><AFPUB-2019-IPv4-002-DRAFT02.pdf>_______________________________________________<br>RPD mailing list<br>RPD@afrinic.net<br>https://lists.afrinic.net/mailman/listinfo/rpd<o:p></o:p></span></p></blockquote><p class=MsoNormal style='margin-left:35.4pt'><span style='font-size:9.0pt;font-family:Helvetica'><br><br><br><br><br>**********************************************<br>IPv4 is over<br>Are you ready for the new Internet ?<br></span><a href="http://www.theipv6company.com/"><span style='font-size:9.0pt;font-family:Helvetica'>http://www.theipv6company.com</span></a><span style='font-size:9.0pt;font-family:Helvetica'><br>The IPv6 Company<br><br>This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.</span><o:p></o:p></p></div></blockquote></div><p class=MsoNormal style='margin-left:35.4pt'><br><br><o:p></o:p></p></div><br>**********************************************<br>
IPv4 is over<br>
Are you ready for the new Internet ?<br>
http://www.theipv6company.com<br>
The IPv6 Company<br>
<br>
This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.<br>
<br>
</body></html>