<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le dim. 10 nov. 2019 à 21:46, Daniel Yakmut <<a href="mailto:yakmutd@googlemail.com">yakmutd@googlemail.com</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto"><div dir="auto">In the whole of these mix, can't we have the transfer of the resource to be temporal.<div dir="auto"><br></div><div dir="auto"> For example I have a pool of ipv4 resources that I am not utilising at the moment, I should be able to lease it out for a period say 24months or more. And if I have a need for the resource later, I should be able to retrieve it back without going to the RIR for another allocation.</div></div></div></blockquote><div><br></div><div><br></div><div>Because the resources were give to you base on NEED. If you no longer need it, return it to AfriNIC and when you need it, go back for me.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto"><div dir="auto"><div dir="auto"><br></div><div dir="auto">Furthemore after the retrieval and.i am still short of my current needs i can approach the RIR for new allocation I believe.</div><div dir="auto"><br></div><div dir="auto">The point is, my earlier leased resource can be used anywhere in the world, then how does all the current Inter RIR policies under discussion takes care of this situation.</div><div dir="auto"><br></div><div dir="auto">Simply</div><div dir="auto">Daniel</div><div dir="auto"><br></div></div><br><div class="gmail_quote"><div dir="ltr">On Sun, Nov 10, 2019, 5:54 PM Chevalier du Borg <<a href="mailto:virtual.borg@gmail.com" rel="noreferrer" target="_blank">virtual.borg@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><br></div><div>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</div><div><br></div><div>"The AfriNIC Broker Support Policy"</div><div><br></div><div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le mer. 6 nov. 2019 à 23:42, Owen DeLong <<a href="mailto:owen@delong.com" rel="noreferrer noreferrer" target="_blank">owen@delong.com</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><br><div><br><blockquote type="cite"><div>On Nov 6, 2019, at 07:00 , Fernando Frediani <<a href="mailto:fhfrediani@gmail.com" rel="noreferrer noreferrer" target="_blank">fhfrediani@gmail.com</a>> wrote:</div><br><div>
<div><p>This proposal states in 5.7.3.2 that "the source entities are
eligible to receive further IPv4 allocations or assigments from
AFRINIC". What is the logic on that ?<br>
If a organization is transferring its resources it means it
doesn't need them anymore and therefore it doesn't make sense they
can receive any further space from AFRINIC.</p></div></div></blockquote>Transferring out should not result in a permanent ban on acquiring more resources, but there should definitely be some hold-down time to prevent address cycling and speculation.</div></div></blockquote><div><br></div><div><br></div><div>Why not? </div><div>Unless they can prove they retrieve the last block of address they 'transfer' (aka SELL), why should they get more from the community pool?</div><div>And again. I oppose this "The AfriNIC Broker Support Policy"</div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div><br></div><div>Suggest that sources of resources for transfer be prohibited from acquiring additional resources for at least 24 months.</div><div><br></div><div><blockquote type="cite"><div><div><p>It also proposes in 5.7.4.1 that "the transfer does not require
approval from AFRINIC". Of course there must be a mutual agreement
on both sides for a transfer to happen but the RIR must check
everything and 'approve' that everything is correct and can
happen. Furthermore the justification for coming 10 years it way
to long and I've never seen it in any other place which for me
doesn't make sense otherwise would clearly allow stockpiling which
is one of the key things to be avoided in IP assignment since the
very beginning.</p></div></div></blockquote>Agreed… Recipients of transfers should be subject to the same reviews as recipients of space from the free pool, IMHO. Further, local sources of resources for transfer should be validated by the RIR as the legitimate and uncontested registrant.</div><div><br></div><div>For inter-RIR transfers, I would suggest the following:</div><div><span style="white-space:pre-wrap"> </span>Source Entity should be verified by Source RIR according to that RIR’s policies and practices.</div><div><span style="white-space:pre-wrap"> </span>Recipient Entity should be verified by Destination RIR according to that RIR’s policies and practices.</div><div><br></div><div>This is the general approach taken in the existing inter-RIR transfer policies and will yield greatest compatibility with existing inter-RIR policies.</div><div><blockquote type="cite"><div><div><p>The proposal also removes something fundamental to fix a
historical mistake, with the removal o 5.7.4.3 which converts
legacy transferred resources to non-legacy.</p></div></div></blockquote><div>Agreed…</div><div><br></div>There should, in my opinion, be no such thing as legacy resources, only legacy registrations. An existing registration which existed before the RIR and has not been brought into contract with an existing RIR is a legacy registration. Any transfer or other transaction which involves a change in ownership of that registration should require that the recipient enter a contract with the RIR and that the new registration be non-legacy.</div><div><br></div><div>If the authors can adopt these recommendations, I could support the proposal. Without them, I must oppose the proposal as written.</div><div><br></div><div>Owen</div><div><br></div><br></div>_______________________________________________<br>
RPD mailing list<br>
<a href="mailto:RPD@afrinic.net" rel="noreferrer noreferrer" target="_blank">RPD@afrinic.net</a><br>
<a href="https://lists.afrinic.net/mailman/listinfo/rpd" rel="noreferrer noreferrer noreferrer" target="_blank">https://lists.afrinic.net/mailman/listinfo/rpd</a><br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr">Borg le Chevalier<br>___________________________________<br>"Common sense is what tells us the world is flat" </div></div>
_______________________________________________<br>
RPD mailing list<br>
<a href="mailto:RPD@afrinic.net" rel="noreferrer noreferrer" target="_blank">RPD@afrinic.net</a><br>
<a href="https://lists.afrinic.net/mailman/listinfo/rpd" rel="noreferrer noreferrer noreferrer" target="_blank">https://lists.afrinic.net/mailman/listinfo/rpd</a><br>
</blockquote></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Nov 10, 2019 5:54 PM, "Chevalier du Borg" <<a href="mailto:virtual.borg@gmail.com" target="_blank">virtual.borg@gmail.com</a>> wrote:<br type="attribution"><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><br></div><div>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</div><div><br></div><div>"The AfriNIC Broker Support Policy"</div><div><br></div><div><br></div><br><div class="gmail_quote"><div><div dir="ltr" class="gmail_attr">Le mer. 6 nov. 2019 à 23:42, Owen DeLong <<a href="mailto:owen@delong.com" rel="noreferrer" target="_blank">owen@delong.com</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><br><div><br><blockquote type="cite"><div>On Nov 6, 2019, at 07:00 , Fernando Frediani <<a href="mailto:fhfrediani@gmail.com" rel="noreferrer" target="_blank">fhfrediani@gmail.com</a>> wrote:</div><br><div>
<div><p>This proposal states in 5.7.3.2 that "the source entities are
eligible to receive further IPv4 allocations or assigments from
AFRINIC". What is the logic on that ?<br>
If a organization is transferring its resources it means it
doesn't need them anymore and therefore it doesn't make sense they
can receive any further space from AFRINIC.</p></div></div></blockquote>Transferring out should not result in a permanent ban on acquiring more resources, but there should definitely be some hold-down time to prevent address cycling and speculation.</div></div></blockquote><div><br></div><div><br></div></div><div>Why not? </div><div>Unless they can prove they retrieve the last block of address they 'transfer' (aka SELL), why should they get more from the community pool?</div><div>And again. I oppose this "The AfriNIC Broker Support Policy"</div><div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div><br></div><div>Suggest that sources of resources for transfer be prohibited from acquiring additional resources for at least 24 months.</div><div><br></div><div><blockquote type="cite"><div><div><p>It also proposes in 5.7.4.1 that "the transfer does not require
approval from AFRINIC". Of course there must be a mutual agreement
on both sides for a transfer to happen but the RIR must check
everything and 'approve' that everything is correct and can
happen. Furthermore the justification for coming 10 years it way
to long and I've never seen it in any other place which for me
doesn't make sense otherwise would clearly allow stockpiling which
is one of the key things to be avoided in IP assignment since the
very beginning.</p></div></div></blockquote>Agreed… Recipients of transfers should be subject to the same reviews as recipients of space from the free pool, IMHO. Further, local sources of resources for transfer should be validated by the RIR as the legitimate and uncontested registrant.</div><div><br></div><div>For inter-RIR transfers, I would suggest the following:</div><div><span style="white-space:pre-wrap"> </span>Source Entity should be verified by Source RIR according to that RIR’s policies and practices.</div><div><span style="white-space:pre-wrap"> </span>Recipient Entity should be verified by Destination RIR according to that RIR’s policies and practices.</div><div><br></div><div>This is the general approach taken in the existing inter-RIR transfer policies and will yield greatest compatibility with existing inter-RIR policies.</div><div><blockquote type="cite"><div><div><p>The proposal also removes something fundamental to fix a
historical mistake, with the removal o 5.7.4.3 which converts
legacy transferred resources to non-legacy.</p></div></div></blockquote><div>Agreed…</div><div><br></div>There should, in my opinion, be no such thing as legacy resources, only legacy registrations. An existing registration which existed before the RIR and has not been brought into contract with an existing RIR is a legacy registration. Any transfer or other transaction which involves a change in ownership of that registration should require that the recipient enter a contract with the RIR and that the new registration be non-legacy.</div><div><br></div><div>If the authors can adopt these recommendations, I could support the proposal. Without them, I must oppose the proposal as written.</div><div><br></div><div>Owen</div><div><br></div><br></div>_______________________________________________<br>
RPD mailing list<br>
<a href="mailto:RPD@afrinic.net" rel="noreferrer" target="_blank">RPD@afrinic.net</a><br>
<a href="https://lists.afrinic.net/mailman/listinfo/rpd" rel="noreferrer noreferrer" target="_blank">https://lists.afrinic.net/mailman/listinfo/rpd</a><br>
</blockquote></div></div><div><br clear="all"><div><br></div>-- <br><div dir="ltr">Borg le Chevalier<br>___________________________________<br>"Common sense is what tells us the world is flat" </div></div></div><div>
_______________________________________________<br>
RPD mailing list<br>
<a href="mailto:RPD@afrinic.net" rel="noreferrer" target="_blank">RPD@afrinic.net</a><br>
<a href="https://lists.afrinic.net/mailman/listinfo/rpd" rel="noreferrer noreferrer" target="_blank">https://lists.afrinic.net/mailman/listinfo/rpd</a><br>
</div></blockquote></div><br></div>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature">Borg le Chevalier<br>___________________________________<br>"Common sense is what tells us the world is flat" </div></div>