<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:"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.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.EstiloCorreo18
{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;}
--></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'>A side note that responds to these questions for all the Inter-RIR transfer proposals:<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'>When a proposal reach consensus, it needs a few weeks for the last call, then the ratification of the board, then starts the implementation.<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'>Staff has reported that they will need 6 months (I think this is too short, according to past experience in other RIRs).<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'>Anyway, all the process in total will take typically 9-12 months.<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'>By then, is easy to understand that the exhaustion phase 2 will be already in place.<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><p class=MsoNormal><span lang=EN-US style='font-size:12.0pt;color:black'>Regards,<o:p></o:p></span></p><p class=MsoNormal style='margin-bottom:12.0pt'><span lang=EN-US style='font-size:12.0pt;color:black;mso-fareast-language:EN-US'>Jordi<o:p></o:p></span></p><p class=MsoNormal style='margin-bottom:12.0pt'><span lang=EN-US style='font-size:12.0pt;color:black;mso-fareast-language:EN-US'>@jordipalet<o:p></o:p></span></p><p class=MsoNormal style='margin-bottom:12.0pt'><span lang=EN-US style='font-size:12.0pt;color:black;mso-fareast-language:EN-US'><o:p> </o:p></span></p></div><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 11/11/19 11:31, "Eucharia Maryann" <<a href="mailto:eucharianene@gmail.com">eucharianene@gmail.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><div><p class=MsoNormal style='margin-left:35.4pt'><span style='font-family:"Arial",sans-serif'>Hello Chevalier</span><o:p></o:p></p><div><p class=MsoNormal style='margin-left:35.4pt'><span style='font-family:"Arial",sans-serif'><o:p> </o:p></span></p></div><div><p class=MsoNormal style='margin-left:35.4pt'><span style='font-size:9.5pt;font-family:"Arial",sans-serif'><br>> I opposed this and any out of continent transfer policy at this time. I can revise my choice when ALL RIRs have finish their free pool. Otherwise, this policy can as well be call</span><span style='font-family:"Arial",sans-serif'><o:p></o:p></span></p></div><div><p class=MsoNormal style='margin-left:35.4pt'><span style='font-family:"Arial",sans-serif'><o:p> </o:p></span></p></div><div><p class=MsoNormal style='margin-left:35.4pt'><span style='font-size:9.5pt;font-family:"Arial",sans-serif'>>> Eucharia: Why Should we wait until the exhaustion phase of free pool? Why do we like to cure rather than to prevent (prevention they said, is better than cure)</span><span style='font-family:"Arial",sans-serif'><o:p></o:p></span></p></div><div><p class=MsoNormal style='margin-left:35.4pt'><span style='font-size:9.5pt;font-family:"Arial",sans-serif'>>>What will it cost Afrinic to embrace this proposal?</span><span style='font-family:"Arial",sans-serif'><o:p></o:p></span></p></div><div><p class=MsoNormal style='margin-left:35.4pt'><span style='font-size:9.5pt;font-family:"Arial",sans-serif'>>>Please outline the disadvantages/problems you think this policy will cause AFRINIC or you can also state clearly what you think is not explicitly explained so that the author of this policy can address them because all I know is that AFRINIC needs this policy.</span><span style='font-family:"Arial",sans-serif'><o:p></o:p></span></p></div><div><p class=MsoNormal style='margin-left:35.4pt'><span style='font-size:9.5pt;font-family:"Arial",sans-serif'>Thanks</span><span style='font-family:"Arial",sans-serif'><o:p></o:p></span></p></div><div><p class=MsoNormal style='margin-left:35.4pt'><span style='font-family:"Arial",sans-serif'><o:p> </o:p></span></p></div><div><p class=MsoNormal style='margin-left:35.4pt'><span style='font-size:9.5pt;font-family:"Arial",sans-serif'>Simply Eucharia.</span><span style='font-family:"Arial",sans-serif'><o:p></o:p></span></p></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><div><p class=MsoNormal style='margin-left:35.4pt'>On Sun, Nov 10, 2019, 19:51 <<a href="mailto:rpd-request@afrinic.net">rpd-request@afrinic.net</a>> wrote:<o:p></o:p></p></div><blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-right:0cm'><p class=MsoNormal style='margin-left:35.4pt'>Send RPD mailing list submissions to<br> <a href="mailto:rpd@afrinic.net" target="_blank">rpd@afrinic.net</a><br><br>To subscribe or unsubscribe via the World Wide Web, visit<br> <a href="https://lists.afrinic.net/mailman/listinfo/rpd" target="_blank">https://lists.afrinic.net/mailman/listinfo/rpd</a><br>or, via email, send a message with subject or body 'help' to<br> <a href="mailto:rpd-request@afrinic.net" target="_blank">rpd-request@afrinic.net</a><br><br>You can reach the person managing the list at<br> <a href="mailto:rpd-owner@afrinic.net" target="_blank">rpd-owner@afrinic.net</a><br><br>When replying, please edit your Subject line so it is more specific<br>than "Re: Contents of RPD digest..."<br><br><br>Today's Topics:<br><br> 1. Re: AFRINIC Number Resources Transfer Policy (Chevalier du Borg)<br> 2. Re: AFRINIC Number Resources Transfer Policy (Chevalier du Borg)<br><br><br>----------------------------------------------------------------------<br><br>Message: 1<br>Date: Sun, 10 Nov 2019 22:46:36 +0400<br>From: Chevalier du Borg <<a href="mailto:virtual.borg@gmail.com" target="_blank">virtual.borg@gmail.com</a>><br>To: Daniel Yakmut <<a href="mailto:yakmutd@googlemail.com" target="_blank">yakmutd@googlemail.com</a>><br>Cc: "rpd >> AfriNIC Resource Policy" <<a href="mailto:rpd@afrinic.net" target="_blank">rpd@afrinic.net</a>><br>Subject: Re: [rpd] AFRINIC Number Resources Transfer Policy<br>Message-ID:<br> <<a href="mailto:CAH5aO8csSQOtshzwhu3m4fvb8HxGkLirNYvzgtpz7yrHUrk5vA@mail.gmail.com" target="_blank">CAH5aO8csSQOtshzwhu3m4fvb8HxGkLirNYvzgtpz7yrHUrk5vA@mail.gmail.com</a>><br>Content-Type: text/plain; charset="utf-8"<br><br>Le dim. 10 nov. 2019 ? 21:46, Daniel Yakmut <<a href="mailto:yakmutd@googlemail.com" target="_blank">yakmutd@googlemail.com</a>> a<br>?crit :<br><br>> In the whole of these mix, can't we have the transfer of the resource to<br>> be temporal.<br>><br>> For example I have a pool of ipv4 resources that I am not utilising at<br>> the moment, I should be able to lease it out for a period say 24months or<br>> more. And if I have a need for the resource later, I should be able to<br>> retrieve it back without going to the RIR for another allocation.<br>><br><br><br>Because the resources were give to you base on NEED. If you no longer need<br>it, return it to AfriNIC and when you need it, go back for me.<br><br><br><br>><br>> Furthemore after the retrieval and.i am still short of my current needs i<br>> can approach the RIR for new allocation I believe.<br>><br>> The point is, my earlier leased resource can be used anywhere in the<br>> world, then how does all the current Inter RIR policies under discussion<br>> takes care of this situation.<br>><br>> Simply<br>> Daniel<br>><br>><br>> On Sun, Nov 10, 2019, 5:54 PM Chevalier du Borg <<a href="mailto:virtual.borg@gmail.com" target="_blank">virtual.borg@gmail.com</a>><br>> wrote:<br>><br>>><br>>> I opposed this and any out of continent transfer policy at this time. I<br>>> can revise my choice when ALL RIRs have finish their free pool. Otherwise,<br>>> this policy can as well be call<br>>><br>>> "The AfriNIC Broker Support Policy"<br>>><br>>><br>>><br>>> Le mer. 6 nov. 2019 ? 23:42, Owen DeLong <<a href="mailto:owen@delong.com" target="_blank">owen@delong.com</a>> a ?crit :<br>>><br>>>><br>>>><br>>>> On Nov 6, 2019, at 07:00 , Fernando Frediani <<a href="mailto:fhfrediani@gmail.com" target="_blank">fhfrediani@gmail.com</a>><br>>>> wrote:<br>>>><br>>>> This proposal states in 5.7.3.2 that "the source entities are eligible<br>>>> to receive further IPv4 allocations or assigments from AFRINIC". What is<br>>>> the logic on that ?<br>>>> If a organization is transferring its resources it means it doesn't need<br>>>> them anymore and therefore it doesn't make sense they can receive any<br>>>> further space from AFRINIC.<br>>>><br>>>> Transferring out should not result in a permanent ban on acquiring more<br>>>> resources, but there should definitely be some hold-down time to prevent<br>>>> address cycling and speculation.<br>>>><br>>><br>>><br>>> Why not?<br>>> Unless they can prove they retrieve the last block of address they<br>>> 'transfer' (aka SELL), why should they get more from the community pool?<br>>> And again. I oppose this "The AfriNIC Broker Support Policy"<br>>><br>>><br>>><br>>><br>>>><br>>>> Suggest that sources of resources for transfer be prohibited from<br>>>> acquiring additional resources for at least 24 months.<br>>>><br>>>> It also proposes in 5.7.4.1 that "the transfer does not require approval<br>>>> from AFRINIC". Of course there must be a mutual agreement on both sides for<br>>>> a transfer to happen but the RIR must check everything and 'approve' that<br>>>> everything is correct and can happen. Furthermore the justification for<br>>>> coming 10 years it way to long and I've never seen it in any other place<br>>>> which for me doesn't make sense otherwise would clearly allow stockpiling<br>>>> which is one of the key things to be avoided in IP assignment since the<br>>>> very beginning.<br>>>><br>>>> Agreed? Recipients of transfers should be subject to the same reviews as<br>>>> recipients of space from the free pool, IMHO. Further, local sources of<br>>>> resources for transfer should be validated by the RIR as the legitimate and<br>>>> uncontested registrant.<br>>>><br>>>> For inter-RIR transfers, I would suggest the following:<br>>>> Source Entity should be verified by Source RIR according to that RIR?s<br>>>> policies and practices.<br>>>> Recipient Entity should be verified by Destination RIR according to that<br>>>> RIR?s policies and practices.<br>>>><br>>>> This is the general approach taken in the existing inter-RIR transfer<br>>>> policies and will yield greatest compatibility with existing inter-RIR<br>>>> policies.<br>>>><br>>>> The proposal also removes something fundamental to fix a historical<br>>>> mistake, with the removal o 5.7.4.3 which converts legacy transferred<br>>>> resources to non-legacy.<br>>>><br>>>> Agreed?<br>>>><br>>>> There should, in my opinion, be no such thing as legacy resources, only<br>>>> legacy registrations. An existing registration which existed before the RIR<br>>>> and has not been brought into contract with an existing RIR is a legacy<br>>>> registration. Any transfer or other transaction which involves a change in<br>>>> ownership of that registration should require that the recipient enter a<br>>>> contract with the RIR and that the new registration be non-legacy.<br>>>><br>>>> If the authors can adopt these recommendations, I could support the<br>>>> proposal. Without them, I must oppose the proposal as written.<br>>>><br>>>> Owen<br>>>><br>>>><br>>>> _______________________________________________<br>>>> RPD mailing list<br>>>> <a href="mailto:RPD@afrinic.net" target="_blank">RPD@afrinic.net</a><br>>>> <a href="https://lists.afrinic.net/mailman/listinfo/rpd" target="_blank">https://lists.afrinic.net/mailman/listinfo/rpd</a><br>>>><br>>><br>>><br>>> --<br>>> Borg le Chevalier<br>>> ___________________________________<br>>> "Common sense is what tells us the world is flat"<br>>> _______________________________________________<br>>> RPD mailing list<br>>> <a href="mailto:RPD@afrinic.net" target="_blank">RPD@afrinic.net</a><br>>> <a href="https://lists.afrinic.net/mailman/listinfo/rpd" target="_blank">https://lists.afrinic.net/mailman/listinfo/rpd</a><br>>><br>><br>> On Nov 10, 2019 5:54 PM, "Chevalier du Borg" <<a href="mailto:virtual.borg@gmail.com" target="_blank">virtual.borg@gmail.com</a>><br>> wrote:<br>><br>><br>> I opposed this and any out of continent transfer policy at this time. I<br>> can revise my choice when ALL RIRs have finish their free pool. Otherwise,<br>> this policy can as well be call<br>><br>> "The AfriNIC Broker Support Policy"<br>><br>><br>><br>> Le mer. 6 nov. 2019 ? 23:42, Owen DeLong <<a href="mailto:owen@delong.com" target="_blank">owen@delong.com</a>> a ?crit :<br>><br>>><br>>><br>>> On Nov 6, 2019, at 07:00 , Fernando Frediani <<a href="mailto:fhfrediani@gmail.com" target="_blank">fhfrediani@gmail.com</a>><br>>> wrote:<br>>><br>>> This proposal states in 5.7.3.2 that "the source entities are eligible to<br>>> receive further IPv4 allocations or assigments from AFRINIC". What is the<br>>> logic on that ?<br>>> If a organization is transferring its resources it means it doesn't need<br>>> them anymore and therefore it doesn't make sense they can receive any<br>>> further space from AFRINIC.<br>>><br>>> Transferring out should not result in a permanent ban on acquiring more<br>>> resources, but there should definitely be some hold-down time to prevent<br>>> address cycling and speculation.<br>>><br>><br>><br>> Why not?<br>> Unless they can prove they retrieve the last block of address they<br>> 'transfer' (aka SELL), why should they get more from the community pool?<br>> And again. I oppose this "The AfriNIC Broker Support Policy"<br>><br>><br>><br>><br>>><br>>> Suggest that sources of resources for transfer be prohibited from<br>>> acquiring additional resources for at least 24 months.<br>>><br>>> It also proposes in 5.7.4.1 that "the transfer does not require approval<br>>> from AFRINIC". Of course there must be a mutual agreement on both sides for<br>>> a transfer to happen but the RIR must check everything and 'approve' that<br>>> everything is correct and can happen. Furthermore the justification for<br>>> coming 10 years it way to long and I've never seen it in any other place<br>>> which for me doesn't make sense otherwise would clearly allow stockpiling<br>>> which is one of the key things to be avoided in IP assignment since the<br>>> very beginning.<br>>><br>>> Agreed? Recipients of transfers should be subject to the same reviews as<br>>> recipients of space from the free pool, IMHO. Further, local sources of<br>>> resources for transfer should be validated by the RIR as the legitimate and<br>>> uncontested registrant.<br>>><br>>> For inter-RIR transfers, I would suggest the following:<br>>> Source Entity should be verified by Source RIR according to that RIR?s<br>>> policies and practices.<br>>> Recipient Entity should be verified by Destination RIR according to that<br>>> RIR?s policies and practices.<br>>><br>>> This is the general approach taken in the existing inter-RIR transfer<br>>> policies and will yield greatest compatibility with existing inter-RIR<br>>> policies.<br>>><br>>> The proposal also removes something fundamental to fix a historical<br>>> mistake, with the removal o 5.7.4.3 which converts legacy transferred<br>>> resources to non-legacy.<br>>><br>>> Agreed?<br>>><br>>> There should, in my opinion, be no such thing as legacy resources, only<br>>> legacy registrations. An existing registration which existed before the RIR<br>>> and has not been brought into contract with an existing RIR is a legacy<br>>> registration. Any transfer or other transaction which involves a change in<br>>> ownership of that registration should require that the recipient enter a<br>>> contract with the RIR and that the new registration be non-legacy.<br>>><br>>> If the authors can adopt these recommendations, I could support the<br>>> proposal. Without them, I must oppose the proposal as written.<br>>><br>>> Owen<br>>><br>>><br>>> _______________________________________________<br>>> RPD mailing list<br>>> <a href="mailto:RPD@afrinic.net" target="_blank">RPD@afrinic.net</a><br>>> <a href="https://lists.afrinic.net/mailman/listinfo/rpd" target="_blank">https://lists.afrinic.net/mailman/listinfo/rpd</a><br>>><br>><br>><br>> --<br>> Borg le Chevalier<br>> ___________________________________<br>> "Common sense is what tells us the world is flat"<br>> _______________________________________________<br>> RPD mailing list<br>> <a href="mailto:RPD@afrinic.net" target="_blank">RPD@afrinic.net</a><br>> <a href="https://lists.afrinic.net/mailman/listinfo/rpd" target="_blank">https://lists.afrinic.net/mailman/listinfo/rpd</a><br>><br>><br>><br><br>-- <br>Borg le Chevalier<br>___________________________________<br>"Common sense is what tells us the world is flat"<br>-------------- next part --------------<br>An HTML attachment was scrubbed...<br>URL: <<a href="https://lists.afrinic.net/pipermail/rpd/attachments/20191110/15f8579d/attachment-0001.html" target="_blank">https://lists.afrinic.net/pipermail/rpd/attachments/20191110/15f8579d/attachment-0001.html</a>><br><br>------------------------------<br><br>Message: 2<br>Date: Sun, 10 Nov 2019 22:51:04 +0400<br>From: Chevalier du Borg <<a href="mailto:virtual.borg@gmail.com" target="_blank">virtual.borg@gmail.com</a>><br>To: Jaco Kroon <<a href="mailto:jaco@uls.co.za" target="_blank">jaco@uls.co.za</a>><br>Cc: "AfriNIC RPD MList." <<a href="mailto:rpd@afrinic.net" target="_blank">rpd@afrinic.net</a>><br>Subject: Re: [rpd] AFRINIC Number Resources Transfer Policy<br>Message-ID:<br> <CAH5aO8dkVqTU0SmHR6Rkg8b92H1=4D_yZoh75APv=<a href="mailto:Q5gSvD2KQ@mail.gmail.com" target="_blank">Q5gSvD2KQ@mail.gmail.com</a>><br>Content-Type: text/plain; charset="utf-8"<br><br>Le dim. 10 nov. 2019 ? 21:58, Jaco Kroon <<a href="mailto:jaco@uls.co.za" target="_blank">jaco@uls.co.za</a>> a ?crit :<br><br>> Hi Chevalier.<br>><br>> Please allow me to be blunt. That's short sighted.<br>><br>> We cannot transfer IN from other regions unless we allow OUT.<br>><br><br>Agree 100%,<br>Then you have no problems with wait till all RIRs are equal run out before<br>we etablish full in and out transfer policy no?<br><br><br>> All the other RIRs require reciprocal *compatible* policies, which means<br>> bi-directional transfers.<br>><br><br><br>All RIRs don't all have equal amount of free space. Big difference<br><br><br><br>> Not allowing this means we can't get resources in either.<br>><br><br>While AfriNIC have free space, operators don't need it<br>When it run out, then we can allow transfer policy<br><br><br>Until that time, I oppose these "AfriNIC Broker Support Policy"<br><br><br><br>> Kind Regards,<br>> Jaco Kroon<br>> C.E.O.<br>><br>> *T:* +27 (0)12 021 0000 | *F:* +27 86 648 8561 | *E:* <a href="mailto:jaco@iewc.co.za" target="_blank">jaco@iewc.co.za</a><br>> *W:* <a href="http://iewc.co.za" target="_blank">iewc.co.za</a> <<a href="https://www.iewc.co.za/" target="_blank">https://www.iewc.co.za/</a>> | *A:* Unit 201, Building 2B,<br>> Sunwood Park, Queen's Crescent Lynnwood, Pretoria<br>><br>><br>><br>> [image: Facebook] <<a href="https://www.facebook.com/Interexcel/" target="_blank">https://www.facebook.com/Interexcel/</a>> [image: Twitter]<br>> <<a href="https://twitter.com/Interexcel/" target="_blank">https://twitter.com/Interexcel/</a>> [image: Google+]<br>> <<a href="https://plus.google.com/+InterexcelCoZaPTA/posts" target="_blank">https://plus.google.com/+InterexcelCoZaPTA/posts</a>> [image: LinkedIn]<br>> <<a href="https://www.linkedin.com/company/interexcel-world-connection/" target="_blank">https://www.linkedin.com/company/interexcel-world-connection/</a>><br>><br>> [image: IEWC] <<a href="https://www.iewc.co.za/" target="_blank">https://www.iewc.co.za/</a>> [image: ULS Group]<br>> <<a href="http://www.uls.co.za/" target="_blank">http://www.uls.co.za/</a>><br>> On 2019/11/10 18:50, Chevalier du Borg wrote:<br>><br>><br>> I opposed this and any out of continent transfer policy at this time. I<br>> can revise my choice when ALL RIRs have finish their free pool. Otherwise,<br>> this policy can as well be call<br>><br>> "The AfriNIC Broker Support Policy"<br>><br>><br>><br>> Le mer. 6 nov. 2019 ? 23:42, Owen DeLong <<a href="mailto:owen@delong.com" target="_blank">owen@delong.com</a>> a ?crit :<br>><br>>><br>>><br>>> On Nov 6, 2019, at 07:00 , Fernando Frediani <<a href="mailto:fhfrediani@gmail.com" target="_blank">fhfrediani@gmail.com</a>><br>>> wrote:<br>>><br>>> This proposal states in 5.7.3.2 that "the source entities are eligible to<br>>> receive further IPv4 allocations or assigments from AFRINIC". What is the<br>>> logic on that ?<br>>> If a organization is transferring its resources it means it doesn't need<br>>> them anymore and therefore it doesn't make sense they can receive any<br>>> further space from AFRINIC.<br>>><br>>> Transferring out should not result in a permanent ban on acquiring more<br>>> resources, but there should definitely be some hold-down time to prevent<br>>> address cycling and speculation.<br>>><br>><br>><br>> Why not?<br>> Unless they can prove they retrieve the last block of address they<br>> 'transfer' (aka SELL), why should they get more from the community pool?<br>> And again. I oppose this "The AfriNIC Broker Support Policy"<br>><br>><br>><br>><br>>><br>>> Suggest that sources of resources for transfer be prohibited from<br>>> acquiring additional resources for at least 24 months.<br>>><br>>> It also proposes in 5.7.4.1 that "the transfer does not require approval<br>>> from AFRINIC". Of course there must be a mutual agreement on both sides for<br>>> a transfer to happen but the RIR must check everything and 'approve' that<br>>> everything is correct and can happen. Furthermore the justification for<br>>> coming 10 years it way to long and I've never seen it in any other place<br>>> which for me doesn't make sense otherwise would clearly allow stockpiling<br>>> which is one of the key things to be avoided in IP assignment since the<br>>> very beginning.<br>>><br>>> Agreed? Recipients of transfers should be subject to the same reviews as<br>>> recipients of space from the free pool, IMHO. Further, local sources of<br>>> resources for transfer should be validated by the RIR as the legitimate and<br>>> uncontested registrant.<br>>><br>>> For inter-RIR transfers, I would suggest the following:<br>>> Source Entity should be verified by Source RIR according to that RIR?s<br>>> policies and practices.<br>>> Recipient Entity should be verified by Destination RIR according to that<br>>> RIR?s policies and practices.<br>>><br>>> This is the general approach taken in the existing inter-RIR transfer<br>>> policies and will yield greatest compatibility with existing inter-RIR<br>>> policies.<br>>><br>>> The proposal also removes something fundamental to fix a historical<br>>> mistake, with the removal o 5.7.4.3 which converts legacy transferred<br>>> resources to non-legacy.<br>>><br>>> Agreed?<br>>><br>>> There should, in my opinion, be no such thing as legacy resources, only<br>>> legacy registrations. An existing registration which existed before the RIR<br>>> and has not been brought into contract with an existing RIR is a legacy<br>>> registration. Any transfer or other transaction which involves a change in<br>>> ownership of that registration should require that the recipient enter a<br>>> contract with the RIR and that the new registration be non-legacy.<br>>><br>>> If the authors can adopt these recommendations, I could support the<br>>> proposal. Without them, I must oppose the proposal as written.<br>>><br>>> Owen<br>>><br>>><br>>> _______________________________________________<br>>> RPD mailing list<br>>> <a href="mailto:RPD@afrinic.net" target="_blank">RPD@afrinic.net</a><br>>> <a href="https://lists.afrinic.net/mailman/listinfo/rpd" target="_blank">https://lists.afrinic.net/mailman/listinfo/rpd</a><br>>><br>><br>><br>> --<br>> Borg le Chevalier<br>> ___________________________________<br>> "Common sense is what tells us the world is flat"<br>><br>> _______________________________________________<br>> RPD mailing listRPD@afrinic.nethttps://<a href="http://lists.afrinic.net/mailman/listinfo/rpd" target="_blank">lists.afrinic.net/mailman/listinfo/rpd</a><br>><br>><br><br>-- <br>Borg le Chevalier<br>___________________________________<br>"Common sense is what tells us the world is flat"<br>-------------- next part --------------<br>An HTML attachment was scrubbed...<br>URL: <<a href="https://lists.afrinic.net/pipermail/rpd/attachments/20191110/296f69c0/attachment.html" target="_blank">https://lists.afrinic.net/pipermail/rpd/attachments/20191110/296f69c0/attachment.html</a>><br>-------------- next part --------------<br>A non-text attachment was scrubbed...<br>Name: ico-facebook.jpg<br>Type: image/jpeg<br>Size: 1302 bytes<br>Desc: not available<br>URL: <<a href="https://lists.afrinic.net/pipermail/rpd/attachments/20191110/296f69c0/attachment.jpg" target="_blank">https://lists.afrinic.net/pipermail/rpd/attachments/20191110/296f69c0/attachment.jpg</a>><br>-------------- next part --------------<br>A non-text attachment was scrubbed...<br>Name: ico-twitter.jpg<br>Type: image/jpeg<br>Size: 1423 bytes<br>Desc: not available<br>URL: <<a href="https://lists.afrinic.net/pipermail/rpd/attachments/20191110/296f69c0/attachment-0001.jpg" target="_blank">https://lists.afrinic.net/pipermail/rpd/attachments/20191110/296f69c0/attachment-0001.jpg</a>><br>-------------- next part --------------<br>A non-text attachment was scrubbed...<br>Name: ico-linkedin.jpg<br>Type: image/jpeg<br>Size: 1444 bytes<br>Desc: not available<br>URL: <<a href="https://lists.afrinic.net/pipermail/rpd/attachments/20191110/296f69c0/attachment-0002.jpg" target="_blank">https://lists.afrinic.net/pipermail/rpd/attachments/20191110/296f69c0/attachment-0002.jpg</a>><br>-------------- next part --------------<br>A non-text attachment was scrubbed...<br>Name: ie.jpg<br>Type: image/jpeg<br>Size: 3906 bytes<br>Desc: not available<br>URL: <<a href="https://lists.afrinic.net/pipermail/rpd/attachments/20191110/296f69c0/attachment-0003.jpg" target="_blank">https://lists.afrinic.net/pipermail/rpd/attachments/20191110/296f69c0/attachment-0003.jpg</a>><br>-------------- next part --------------<br>A non-text attachment was scrubbed...<br>Name: ulsgroup.jpg<br>Type: image/jpeg<br>Size: 10458 bytes<br>Desc: not available<br>URL: <<a href="https://lists.afrinic.net/pipermail/rpd/attachments/20191110/296f69c0/attachment-0004.jpg" target="_blank">https://lists.afrinic.net/pipermail/rpd/attachments/20191110/296f69c0/attachment-0004.jpg</a>><br><br>------------------------------<br><br>Subject: Digest Footer<br><br>_______________________________________________<br>RPD mailing list<br><a href="mailto:RPD@afrinic.net" target="_blank">RPD@afrinic.net</a><br><a href="https://lists.afrinic.net/mailman/listinfo/rpd" target="_blank">https://lists.afrinic.net/mailman/listinfo/rpd</a><br><br><br>------------------------------<br><br>End of RPD Digest, Vol 158, Issue 48<br>************************************<o:p></o:p></p></blockquote></div><p class=MsoNormal style='margin-left:35.4pt'>_______________________________________________ RPD mailing list RPD@afrinic.net https://lists.afrinic.net/mailman/listinfo/rpd <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>