<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Aug 5, 2021, at 04:44 , Sylvain Baya <<a href="mailto:abscoco@gmail.com" class="">abscoco@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class="">Dear AfriNIC's Community, <div class=""><br class=""></div><div class="">Please see my comments below, inline...<br class=""><br class="">Le mardi 3 août 2021, Owen DeLong <<a href="mailto:owen@delong.com" target="_blank" class="">owen@delong.com</a>> a écrit :<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space" class=""><br class=""><div class=""><br class=""><blockquote type="cite" class=""><div class="">On Aug 2, 2021, at 00:03 , Sylvain Baya <<a href="mailto:abscoco@gmail.com" target="_blank" class="">abscoco@gmail.com</a>> wrote:</div><br class=""><div class="">Dear AfriNIC's Community,<div class=""><br class="">Please see my comments below, inline...<br class=""><br class="">Le samedi 31 juillet 2021, Owen DeLong <<a href="mailto:owen@delong.com" target="_blank" class="">owen@delong.com</a>> a écrit :<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space" class=""><div class=""><br class=""><blockquote type="cite" class=""><div class="">On Jul 30, 2021, at 15:14 , Sylvain Baya <<a href="mailto:abscoco@gmail.com" target="_blank" class="">abscoco@gmail.com</a>> wrote:</div><br class=""><div class="">Dear AfriNIC's Community,<br class=""><br class="">Le mercredi 28 juillet 2021, Owen DeLong via Community-Discuss <<a href="mailto:community-discuss@afrinic.net" target="_blank" class="">community-discuss@afrinic.net</a><wbr class="">> a écrit :<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space" class=""><div class=""><br class=""><blockquote type="cite" class=""><div class=""><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class=""><div dir="ltr" class=""><br class=""></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class=""><br class=""></div>[...]</blockquote><div class=""><br class=""></div></div></div></blockquote></div></div></blockquote><div class=""><br class=""></div>You’re not answering the question I asked…</div><div class=""><br class=""></div></div></blockquote><div class=""><br class=""></div><div class="">Hi Owen,</div><div class="">Thanks for your email, brother!</div><div class=""><br class=""></div><div class=""> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space" class=""><div class="">What is your basis in policy for claiming that a VM is OK, but leasing addresses without providing connectivity</div><div class="">services is not?</div><div class=""><br class=""></div></div></blockquote><div class=""><br class=""></div><div class="">...you might have forgotten about a simple notion, </div><div class="">called: conservation. You shall recognize it as it has</div><div class=""> been refered out there as *Reservations*.</div></div></blockquote><div class=""><br class=""></div>I have not forgotten, but we are not talking about reservation. </div><div class=""><br class=""></div></div></blockquote><div class=""><br class=""></div><div class="">Hi Owen,</div><div class="">Thanks to take time to reply to my email, brother.</div><div class=""><br class=""></div><div class="">...so, *we*! i assume the same *we* you usually </div><div class="">use to call your team to support your personal interpretation of the facts?</div></div></div></blockquote><div class=""><br class=""></div>No, we is you and I, the people engaged in this particular conversational</div><div class="">thread.</div><div class=""> </div><div class=""> </div></div></blockquote><div class=""><br class=""></div><div class="">Hi Owen,</div><div class="">Thanks for your clarification, brother.</div><div class=""><br class=""></div><div class="">...so, you try to impose to all others a particular </div><div class="">theme?</div></div></div></blockquote><div><br class=""></div>??? I don’t try to impose anything. I simply made a statement about</div><div>the nature of the items you and I were discussing. They are not reservations</div><div>by the meaning contained any AFRINIC governing document.</div><div><br class=""></div><div><blockquote type="cite" class=""><div class=""><div class=""><div class="">Please, sir, how can i be removed from your pool?</div></div></div></blockquote><div><br class=""></div><div>I am very confused here. What pool do you speak of?</div><div><br class=""></div><div>You made a statement claiming that cloud innovations leases</div><div>were reservations and then based other conclusions on this</div><div>purported fact. I merely pointed out that the subject matter</div><div>that you and I (we) were discussing was not, in fact, a case</div><div>of “reservations”.</div><div><br class=""></div><div>You then went down a very bizarre tangent related to how I was</div><div>defining we, making an invalid assumption about it and then turning</div><div>my response clarifying same into some sort of accusation that</div><div>I was somehow being coercive.</div><div><br class=""></div><div>I really cannot understand your reasoning here.</div><div><br class=""></div><blockquote type="cite" class=""><div class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space" class=""><div class=""><blockquote type="cite" class=""><div class=""><div class=""><div class="">Btw, you are entitled to your own opinion.</div><div class=""><br class=""></div><div class="">...let's, at least, agree to disagree :-/ </div><div class=""> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space" class=""><div class=""><br class=""></div><div class="">We are talking about deployment on an actual</div><div class="">host connected to the internet for legitimate use. </div><div class=""> </div></div></blockquote><div class=""><br class=""></div><div class="">...again, *we*:=you+your_supporting_team<wbr class="">, brother?</div><div class=""><br class=""></div><div class="">For what it's worth, in order to lease community's </div><div class="">ressources such as INRs, one shall *reserve* it first;</div></div></div></blockquote><div class=""><br class=""></div>Um, that’s true whether one is leasing the INRs with or</div></div></blockquote><div class=""> </div><div class=""><br class=""></div><div class="">Thanks to finally getting my point: you practice </div><div class="">leasing on INRs, then you violate the RSA+CPM.</div></div></blockquote><div><br class=""></div>Not sure how you figure that…</div><div><br class=""></div><div>ALL LIRs lease INRs. Many do it in relation to also providing</div><div>connectivity services. Cloud Innovation also does it in relation</div><div>to providing connectivity services in some (but not all) cases.</div><div><br class=""><blockquote type="cite" class=""><div class=""><div class="">...because you have to *reserve*, given that you don't have any network to address hosts on or </div><div class="">to define any administrative boundaries for or; </div><div class="">so any distinctive routing policy to document...</div></div></blockquote><div><br class=""></div>Not true. We (Cloud Innovation) have customers just like any other LIR.</div><div>We (Cloud Innovation) assign addresses to them for use on internet</div><div>connected hosts, just like any other LIR. The only distinction between</div><div>us (Cloud Innovation) and most other LIRs is that we will do so regardless</div><div>of whether we are the provider of that connectivity or not.</div><div><br class=""></div><div>This is not a reservation. We do not hold the addresses in reserve</div><div>for them during a period of time when they are not deployed on actual</div><div>hosts (which is what a reservation would be).</div><div> <br class=""><blockquote type="cite" class=""><div class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space" class=""><div class="">without connnectivity services attached, so you have</div><div class="">either pointed out how we are identical to every other</div><div class="">LIR, or, you have both pointed this out _AND_ called</div><div class="">into question the standard practice of every LIR.</div><div class=""><br class=""></div></div></blockquote><div class=""><br class=""></div><div class=""><br class=""></div><div class="">...straw man fallacy?</div></div></blockquote><div><br class=""></div>Not to the best of my knowledge.</div><div> <br class=""><blockquote type="cite" class=""><div class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space" class=""><div class="">I’m not sure which is intended.</div><div class=""><br class=""><blockquote type="cite" class=""><div class=""><div class=""><div class="">otherwise, any of the end-users/clients shall come <br class=""></div><div class="">to the Registration Service to request the needed <br class=""></div><div class="">INRs; sure to find some there...and you know it: </div></div></div></blockquote><div class=""><br class=""></div>We don’t do anything to interfere with or prevent end-users</div><div class="">or clients from seeking internet number resources from any</div><div class="">other source.</div><div class=""><br class=""></div></div></blockquote><div class=""><br class=""></div><div class="">...please, sir, could you share your stats on the number of orgs, you have helped to become LIR </div><div class="">since the time your org shipted from LIR to INRs </div><div class="">seller? mini-RIR? or Global LIR? </div></div></blockquote><div><br class=""></div><div>No. Doing so would violate the confidentiality of my clients and is not material to any</div><div>legitimate discussion here.</div><div><br class=""></div></div><div><blockquote type="cite" class=""><div class=""><div class="">RFC7020 states:</div><div class=""><br class=""></div><div class="">~°~</div><div class="">[...]</div><div class=""><pre class="newpage" style="font-size:10.6667px;margin-top:0px;margin-bottom:0px;break-before:page">In
cases where LIRs span multiple regions, those LIRs have
established relationships with multiple RIRs.</pre></div><div class="">[...]</div><div class="">~°~</div><div class=""><br class=""></div><div class="">...full part:</div><div class=""><br class=""></div><div class="">~°~</div><div class=""><pre class="newpage" style="font-size:10.6667px;margin-top:0px;margin-bottom:0px;break-before:page">Local IRs
Local Internet Registries (LIRs) are established through a
relationship with the body from which they received their
addresses, typically the RIR that serves the region in which they
operate, a parent LIR, or other number-allocating entity. In
cases where LIRs span multiple regions, those LIRs have
established relationships with multiple RIRs. LIRs perform IP
address allocation services for their customers, typically ISPs,
end users, or child LIRs (also known as "sub-LIRs").</pre></div><div class="">~°~</div><div class=""><<a href="https://tools.ietf.org/html/rfc7020" class="">https://tools.ietf.org/html/rfc7020</a>></div></div></blockquote><div><br class=""></div>First, you seem to have missed this:</div><div><br class=""></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div><div class="">Abstract</div></div><div><div class=""><br class=""></div></div><div><div class=""> This document provides information about the current Internet Numbers</div></div><div><div class=""> Registry System used in the distribution of globally unique Internet</div></div><div><div class=""> Protocol (IP) address space and autonomous system (AS) numbers.</div></div><div><div class=""><br class=""></div></div><div><div class=""> This document also provides information about the processes for</div></div><div><div class=""> further evolution of the Internet Numbers Registry System.</div></div><div><div class=""><br class=""></div></div><div><div class=""> This document replaces </div></div><div>RFC 2050</div><div><div class="">.</div></div><div><div class=""><br class=""></div></div><div><div class=""> This document does not propose any changes to the current Internet</div></div><div><div class=""> Numbers Registry System. Rather, it documents the Internet Numbers</div></div><div><div class=""> Registry System as it works today.</div></div></blockquote><div><br class="Apple-interchange-newline">Then as you have pointed out, it states “typically”. By definition, this means that there</div><div>are likely to exist atypical situations as well.</div><div><br class=""></div><div>There are, in fact, multiple entities operating in multiple regions, but only having</div><div>relationships with a single RIR and there is nothing (outside of one LACNIC policy)</div><div>that serves to hamper or restrict this behavior.</div><div><br class=""></div><div>Owen</div><div><br class=""></div><br class=""></body></html>