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

[Owen DeLong]

Arnaud,

I assure you that I write each and every message I post by myself.

The so called evidence others have produced is not evidence of anything other than their own misapplication of the text in question.

I have refuted each and every piece of so-called evidence in a clear and consistent manner. Even you agree that there is consistency
to my arguments.

You claim that they are my errors of understanding, I believe them to be yours.

There are people who agree with me and people who appear to somehow agree with you about this.

I have broken down the context, meaning, and structure of each and every so-called element in an effort to aid in the plain text understanding of the slices of the various governing documents.

Interestingly, people on your side just keep citing the same provisions, without making any effort to explain how it is they come to the conclusion that their meaning is so different from their wording. I have at least shown how I come to the conclusion that their wording and meaning are aligned in the manner I have expressed.

I have long doubted the value in replying to you, yet I do my best to respect you enough to attempt to provide a cogent rebuttal to each of your arguments. To the best of my knowledge, I have never engaged in ad hominem against you or any of your colleagues, despite your repeated use of ad hominem in an effort to imply that I am somehow incorrect or untrustworthy.

Please, let us proceed as gentlemen with mutual respect. I don’t agree with you. I think you are badly misguided in your interpretation of the policy documents. Nonetheless, i have at all times treated you with respect and I have not once questioned your legitimate allegiance to the community. Even if you believe that my opinion is not correct, I think you are hard pressed to make any valid claim that I am not legitimately representing what I believe to be the true interests of the community and the internet as a whole.

Owen



> On Aug 3, 2021, at 00:02 , Arnaud AMELINA <amelnaud at gmail.com> wrote:

> 

> Chers membres d la communauté

> Ne voyez-vous pas que Owen se paie notre tête (expression francophone j'ignore si ça existe en anglais). Il répète le même refrain tout le temps comme Fernando l'a fait remarquer. Malgré toutes les preuves à lui fourni par tous les autres contributeurs il répète les même choses, maintenant je viens à douter que même lui n'est pas auteur de ses différents textes qu'il postes, parce que sans aucune cohérence avec les autres contributions qui lui ont répondu. Rien que de la répétition argumentaires comme si nous n'avons que ça à faire. Eux , ils sont payer pour produire ces genres de documents toute la journée, lui et ses echochambers. Je ne juge même plus utile de le lui répondre , tellement il répète les mêmes erreurs de compréhension. On dirait qu'il veut se convaincre que ce qu'il dit est juste et véridique, car lui-même n'en est pas encore convaincu.

> 

> English 

> 

> Dear community members

> 

>  Can't you see that Owen is "paying our head " (French expression I don't know if it exists in English).  He repeats the same refrain all the time as Fernando pointed out.  Despite all the evidence provided to him by all the other contributors, he repeats the same things, now I doubt that even him, is not the author of the various texts that he posts, because without any consistency with the others contributions answering him.  Nothing but repeating arguments as if we have only that to do.  They are paid to produce these kinds of documents all day long, with his echochambers.  I no longer even consider it useful to answer him, because he is repeating the same errors of understanding.  It looks like he wants to convince himself that what he is saying is right and true, because himself is not yet convinced.

> 

> --

> Arnaud

> 

> Le mar. 3 août 2021 à 04:00, Owen DeLong via Community-Discuss <community-discuss at afrinic.net <mailto:community-discuss at afrinic.net>> 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.

> 

>> 

>> 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

> 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.

> 

> 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.

> 

>> those must be incorporated within the AfriNIC's 

>> service region...they would save a lot of money 

>> comparing to what could be otherwise payed to 

>> an intermediary *LIR*...not *GIR*...

> 

> Many LIRs operate on a global scale, including, for

> example, Verizon, Hurricane Electric, Akamai, and

> more. The term LIR is primarily used not so much to

> indicate some diminutive scope as to provide a convenient

> distinction from RIR (regional, quasi-continental) or

> NIR (National).

> 

>> ...note that no AfriNIC's Resource Member is a GIR (Global Internet Registry) but all are LIRs (Local 

>> Internet Registries) established/approved to serve 

>> their local economic zone and free to deploy their business accross the whole AfriNIC's service 

>> region, wherever they can extend it; legally speaking.

> 

> You are misunderstanding the nature of the term LIR here.

> 

> There is nothing in AFRINIC’s governing documents which prohibits

> its resource members from deploying their business across the entire

> planet. If you believe that there is, please provide relevant citations

> to the appropriate governing document(s).

> 

>> The difference… The only difference… Is that the

>> connectivity service does not come from the same provider as the addresses.

>> 

>> 

>> ...if...then, please see above!

> 

> If what?

> 

>> You seem to read the CPM selectively, if not why could you ignore the notion of valid assignments 

>> and SAW.

> 

> SAW applies to sub allocations made from one LIR to another. Cloud Innovation makes assignments

> and does not make sub allocations, thus the SAW does not apply.

> 

> As to “valid assignments” where is it that you think these are defined? Which section of the CPM

> do you think I have ignored in considering Cloud Innovations assignments valid?

> 

>> ...icymi, please see here: 

>> <https://lists.afrinic.net/pipermail/rpd/2021/013424.html <https://lists.afrinic.net/pipermail/rpd/2021/013424.html>>

> 

> How is this relevant to this case?

> 

> 5.5.1.1.3 is about transfers — Does not apply here.

> 5.5.1.2.3 is about efficiency. — Cloud Innovations utilization fraction is extremely efficient.

> 5.5.1.3 is about slow start — how AFRINIC goes about allocating to LIRs — Does not apply here.

> 5.5.1.4.1 is about utilization percentage required to request more space from AFRINIC — We are not applying for additional space, so this does not apply here.

> 5.5.1.4.2 is about reservations — No reservations are being made. In this context, the term reservation is used to reference

> 	a situation where an LIR has set aside a group of addresses not actually deployed on hosts and attempts to claim that those

> 	addresses set aside in that manner are utilized for the purposes of calculating the utilization percentage in 5.5.1.4.1.

> 	Since 5.5.1.4.1 does not apply in this situation, and we are not making any such reservations, 5.5.1.4.2 does not apply, either.

> 5.5.1.7 We have, in fact, complied with all documentation requirements.

> 5.5.1.8 We are an LIR and not an end users, so not sure how you consider this relevant, please enlighten.

> 5.5.1.9 Utilization — We have properly reported our utilization through WHOIS at all times. 

> 5.5.1.10 Reservations — Again — We are not making reservations, so this does not apply.

> 5.5.1.11 Validity of an assignment — We enforce this upon the assignments we make. We have also updated

> 	AFRINIC as the nature of our assignments changed.

> 5.5.1.13 Suballocation window — We are not making sub allocations, so this does not apply.

> 5.5.1.13.2 — See 5.5.1.13 above

> 5.5.1.13.3 — See 5.5.1.13 above

> 5.5.1.14 Recordkeeping — We have kept all records required under this provision and have provided same to AFIRNIC whenever

> 	a sufficiently specific request to identify the desired documents has been received.

> 

> So, not a selective reading at all… A very detailed reading.

> 

> Owen

> 

>> 

>> copy -> paste:

>> 

>> ~°~

>> <tl;dr>

>> Yes! i took the responsibility to bring the CPM section 5.5 | IPv4 LIR/ISP

>> Allocations (5.5.1 Allocation policies and guidelines) to you, in case it

>> might have been a too hard task to go it the location of that content.

>> Please accept to read it...

>> 

>> ...i did it with the naive expectation that it

>> could help the PDWG to move forward

>> on some recuring topics, such as

>> Internet number resources (at least for

>> IPv4 types) utilisation and responsibilities

>> thereof, within the AfriNIC's service region.

>> 

>> Therefore permit me to recommend the following subventions to your

>> particular attention:

>> 

>> ¿°?

>> • 5.5.1.1.3 If an LIR plans to exchange or transfer address space, it needs

>> to contact AFRINIC so that the changes are properly registered.

>> • 5.5.1.2.3 Must show an existing efficient utilization of IP addresses

>> from their upstream provider.

>> • 5.5.1.3 Slow start mechanism for first allocations

>> • 5.5.1.4.1 An LIR may receive an additional allocation when about 80% of

>> all the address space currently allocated to it has been used in valid

>> assignments and/or sub-allocations.

>> • 5.5.1.4.2 Reservations are not considered as valid assignments or

>> sub-allocations.

>> • 5.5.1.7 Documentation

>> • 5.5.1.8 Network infrastructure (of LIR) vs End-User networks

>> • 5.5.1.9 Utilisation

>> • 5.5.1.10 Reservations not supported

>> • 5.5.1.11 Validity of an assignment

>> • 5.5.1.13 Sub-Allocation Window (SAW)

>> • 5.5.1.13.1 A sub-allocation window (SAW) refers to the maximum number of

>> IPv4 addresses that the LIR may sub-allocate to the end-users without

>> seeking approval from AFRINIC.

>> • 5.5.1.13.2 AFRINIC will review sub-allocation made by the LIR's using

>> their SAW to ensure that policies are followed correctly.

>> • 5.5.1.13.3 Below are a few guidelines for the SAW:

>> • 5.5.1.14 Recordkeeping by LIRs

>> ¿°?

>> 

>> Please let me know if it was a bad initiative :-/

>> 

>> Thanks.

>> </tl;dr>

>> 

>> Source: <https://afrinic.net/policy/manual#lir-isp-allocation <https://afrinic.net/policy/manual#lir-isp-allocation>>

>> ~°~

>> 

>> 

>> 

>>> Please read again the CPM at section 5:

>>> 

>>> ~°~

>>> [...]

>>> • 5.5.1.4.1 An LIR may receive an additional allocation when about 80% of

>>> all the address space currently allocated to it has been used in valid

>>> assignments and/or sub-allocations.

>>> • 5.5.1.4.2 *Reservations* are not considered as valid assignments or

>>> sub-allocations.

>>> [...]

>>> ~°~

>> 

>> Yep… that’s not a prohibition on valid assignment and/or sub allocation independent of

>> connectivity services, that’s a prohibition of addresses not being attached to hosts.

>>   

>> 

>> ...don't divide/separate the tools, please.

>> It's not allowed. The implementers use it all:

>> Bylaws+RSA+CPM to the good of the AfriNIC's 

>> service region. 

>> Do you want to change something?

>> ...you know how to try!

>>  

>> 

>>> It’s simply not prohibited anywhere in policy.

>>> 

>>> 

>>> Are you serious?

>>> 

>>> ...going further, along with what i wrote above, note 

>>> that *conservation* is not valid, that appears to be 

>>> the best description of leasing...of INRs.

>> 

>> Nope… It’s not a good description at all. Reservations (as prohibited in 5.5.1.4.2) refers

>>  

>>  

>> ...i'm already convinced it is!

>> You shall accept it as is :-)

>> Do you want to change it?

>> 

>> 

>> to addresses set aside for later use…Addresses not currently assigned to active hosts.

>> 

>> 

>> ...your words, mine :-/

>> 

>> CPM section 5.5.1.4.2 says:

>> 

>> ~°~

>> 5.5.1.4.2 Reservations are not considered as valid assignments or

>> sub-allocations.

>> 

>> It may be useful for internal aggregation to keep some IP blocks free for

>> future growth. These internal reservations are however not counted as valid

>> usage and must be assigned or sub-allocated before requesting for

>> additional allocation.

>> ~°~

>> 

>> ...my understanding of *reservation* include yours.

>> Hence, there are other possibilities. You can not 

>> change that. Feel free to try with other tactics...

>> 

>>  

>> Such is not the case with leasing. With leasing, the addresses are assigned to hosts active

>> on the internet, but the hosts may be getting their connectivity from a different provider than

>> they are getting the addresses from.

>> 

>> 

>> This is not a practice allowed within the AfriNIC's 

>> service region , you should understand it...but feel 

>> free to keep your business logic...describing it as 

>> you want, will not change what it is in reality...

>> 

>> CPM sections 5.5.1.10 & 5.5.1.11 say:

>> 

>> ~°~

>> 5.5.1.10 Reservations not supported

>> 

>> End-users are not permitted to reserve address space based on long term

>> plans. This violates the goal of conservation and fragments the address

>> space when initial forecasts are not met. If an LIR wants to assign address

>> space for customers, it must make the assignments from any unallocated or

>> unassigned address space it currently holds. For the purposes evaluating

>> allocation requests, space reserved by an LIR for other customers is

>> considered unused.

>> 

>> 5.5.1.11 Validity of an assignment

>> 

>> Assignments remain valid as long as the original criteria on which the

>> assignment was based are still in place and the assignment is registered in

>> the AFRINIC database. An assignment is therefore invalid if it is not

>> registered in the database and if the purpose for which it was registered

>> has changed or no longer holds.

>> ~°~

>> 

>> ...yes! again: *the purpose* [1] coupled with 

>> the RSA section 4(c)(i), to not say all the full 

>> section 4. titled: *Conditions of service*.

>> __

>> [1]: <https://lists.afrinic.net/pipermail/community-discuss/2021-July/004137.html <https://lists.afrinic.net/pipermail/community-discuss/2021-July/004137.html>>

>> 

>>  

>> 

>>> Those who are charged to implement the CPM have

>>>  indicated the same. Could you, please, show us 

>>> where the CPM allows it?

>> 

>> If they have indicated this, then they are simply in error as that is not what it actually says.

>> I have not noticed AFRINIC staff referring to this section as prohibiting leasing, but perhaps

>> their reference escaped me at some point.

>> 

>> It does not need to be specifically permitted. That which is not prohibited is permitted implicitly.

>> 

>> 

>> ...permitted where? 

>> 

>> Have you tried to put Bylaws+RSA+CPM together?

>> 

>> Please try, then come back with your results.

>>  

>> 

>> Unless there is an explicit requirement in the CPM that hosts receive connectivity services from

>> the same provider which provides their addresses, then independent assignment is inherently

>> permitted and this is the current state.

>> 

>> 

>> ...the current course is otherwise, and you know it.

>> 

>> Again, when there is an established RIR, to serve LIRs and End-Users within its own service region...

>> it's by definition the responsibility of the latters to 

>> serve their local end-users, if applicable...i'm ready 

>> to agree if you point me to any section of the CPM, 

>> the Bylaws or the RSA where it's clearly stated that 

>> AfriNIC shall allocate/assign INRs to GIRs (*Global* Internet Registries) or *Global* End-Users.

>> 

>> As long as there is no mention of the existence of 

>> GIRs within the AfriNIC service region, you shall 

>> understand that out-of-region assignments or 

>> sub-allocations could not be the normal trend...

>> 

>> ...i'm awaiting :-/

>> 

>>  

>> I hope you now understand the difference between a reservation (holding unused addresses,

>> 

>> 

>> You expect me to understand what?

>> 

>> ...please see above and get my answer from there.

>> 

>>  

>> such as what Seacom and many others are doing) vs. providing addresses that are actually 

>> in use, but not simultaneously providing transit or transport services.

>> 

>> 

>> ...don't mix problems, do fill your complain 

>> appropriately, please, and the community 

>> shall address it usual.

>> 

>> Thanks to stop your divertion! but you are free 

>> to continue to support some wrong doings...

>> 

>> Have a blessed monday!

>> 

>> Shalom,

>> --sb.

>> 

>>  

>> Owen

>> 

>>> 

>>> Shalom,

>>> --sb.

>>>  

>>> 

>>>> Or wait... I can not find this so-called LIR Cloud Innovation Limited with offices in Seychelles using this BGP tool.

>>>> 

>>>> https://bgp.he.net/country/SC <https://bgp.he.net/country/SC>

>>> 

>>> And?

>>> [...]

>> 

>> 

>> 

>> -- 

>> --

>> Best Regards !

>> __

>> baya.sylvain[AT cmNOG DOT cm]|<https://cmnog.cm/dokuwiki/Structure <https://cmnog.cm/dokuwiki/Structure>>

>> Subscribe to Mailing List: <https://lists.cmnog.cm/mailman/listinfo/cmnog/ <https://lists.cmnog.cm/mailman/listinfo/cmnog/>>

>> __

>> #‎LASAINTEBIBLE‬|#‎Romains15‬:33«Que LE ‪#‎DIEU‬ de ‪#‎Paix‬ soit avec vous tous! ‪#‎Amen‬!»

>> ‪#‎MaPrière‬ est que tu naisses de nouveau. #Chrétiennement‬

>> «Comme une biche soupire après des courants d’eau, ainsi mon âme soupire après TOI, ô DIEU!»(#Psaumes42:2)

>> 

>> 

>> _______________________________________________

>> Community-Discuss mailing list

>> Community-Discuss at afrinic.net <mailto:Community-Discuss at afrinic.net>

>> https://lists.afrinic.net/mailman/listinfo/community-discuss <https://lists.afrinic.net/mailman/listinfo/community-discuss>

> 

> _______________________________________________

> Community-Discuss mailing list

> Community-Discuss at afrinic.net <mailto:Community-Discuss at afrinic.net>

> https://lists.afrinic.net/mailman/listinfo/community-discuss <https://lists.afrinic.net/mailman/listinfo/community-discuss>


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