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