[Community-Discuss] Share About Cloud Innovation Ltd and their business

[Owen DeLong]

> On Aug 5, 2021, at 04:44 , Sylvain Baya <abscoco at gmail.com> wrote:

> 

> Dear AfriNIC's Community, 

> 

> Please see my comments below, inline...

> 

> Le mardi 3 août 2021, Owen DeLong <owen at delong.com <mailto:owen at delong.com>> a écrit :

> 

> 

>> On Aug 2, 2021, at 00:03 , Sylvain Baya <abscoco at gmail.com <mailto:abscoco at gmail.com>> wrote:

>> 

>> Dear AfriNIC's Community,

>> 

>> Please see my comments below, inline...

>> 

>> Le samedi 31 juillet 2021, Owen DeLong <owen at delong.com <mailto:owen at delong.com>> a écrit :

>> 

>>> On Jul 30, 2021, at 15:14 , Sylvain Baya <abscoco at gmail.com <mailto:abscoco at gmail.com>> wrote:

>>> 

>>> Dear AfriNIC's Community,

>>> 

>>> Le mercredi 28 juillet 2021, Owen DeLong via Community-Discuss <community-discuss at afrinic.net <mailto:community-discuss at afrinic.net>> 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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.afrinic.net/pipermail/community-discuss/attachments/20210805/c33439a0/attachment.html>