Search RPD Archives
[rpd] Cloud Innovation Displays Very Poor, If Not Criminal, Netizenship
Anthony Ubah
ubah.tonyiyke at gmail.com
Tue May 26 18:03:09 UTC 2020
I feel this is gradually brewing up and steering up an unnecessary tension
within the community.
I took time to go through the trail, the post shared by the CEO of Cloud
Innovation contained a email by IPDC in which they have already openly
apologized for their mistake(s).
On the other hand, heaping all blame on Cloud Innovation isn’t totally
logical.
>From my understanding, IPDC hijacked SEACOM’s ASN, IPDC being Cloud
Innovation’s customer. However, I don’t clearly see what role it plays in
the whole process. Predict ing it’s customer’s behaviour is scarcely
possible, hardly any company can. Also is the company in the
position/business to care of it per se, and without violation of privacy?
A typical example is a Kitchenware store; If the store sells a knife to an
individual, and the individual uses the same knife to commit a crime, would
the hardware store also be held partly accountable for the crime?
Thus, whatever the problem is IPDC should settle its differences directly
with SEACOM
*Best Regards,*
*Anthony*
E-mail: anthony.ubah at goldspine.com <anthony.ubah at gloworld.com>.ng
On Tue, May 26, 2020 at 12:01 AM <rpd-request at afrinic.net> wrote:
> Send RPD mailing list submissions to
> rpd at afrinic.net
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.afrinic.net/mailman/listinfo/rpd
> or, via email, send a message with subject or body 'help' to
> rpd-request at afrinic.net
>
> You can reach the person managing the list at
> rpd-owner at afrinic.net
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of RPD digest..."
>
>
> Today's Topics:
>
> 1. Re: Cloud Innovation Displays Very Poor, If Not Criminal,
> Netizenship (Arnaud AMELINA)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Mon, 25 May 2020 23:00:43 +0000
> From: Arnaud AMELINA <amelnaud at gmail.com>
> To: Paschal Ochang <pascosoft at gmail.com>
> Cc: General Discussions of AFRINIC <community-discuss at afrinic.net>,
> "rpd >> AfriNIC Resource Policy" <rpd at afrinic.net>
> Subject: Re: [rpd] Cloud Innovation Displays Very Poor, If Not
> Criminal, Netizenship
> Message-ID:
> <CAGDMR_dmscN4ndR9_xPhpk=
> qjSL5yDjDZFZ1y-PXVE6z1y41RA at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Paschal,
>
> Please explain why it?s a personal attack when no person was mentioned?
>
> Please be enlightened that the topic under discussion is allowed because
> its application of policy with implications.
>
> FWIW, Cloud Innovation Ltd, rendering an apology does not make the problem
> go away and the working group has to solve the real problem at hand
>
> Let us be aware that, the way internet deals with bad netizens may cause
> damage to parents and even to the whole region if nothing is done to stop
> it
>
> --
> Arnaud
>
> Le lun. 25 mai 2020 ? 11:30, Paschal Ochang <pascosoft at gmail.com> a ?crit
> :
>
> > This sounds like a personal attack in my opinion instead of a justified
> > accusation. Why is this topic allowed to be discussed here when it?s
> rather
> > irrelevant?. The parties involved have tendered formal apologies as
> > reflected in their letters which is a sign of admittance and promotes the
> > intent of good netizenship. It?s just irrelevant.
> >
> > On Monday, May 25, 2020, Arnaud AMELINA <amelnaud at gmail.com> wrote:
> >
> >> Hello, community
> >>
> >> +1 @Gregoire and @Mark Tinka
> >>
> >> *cloud innovation* were allocated *big bunch of IPv4* space as a *LIR*
> >> with *no ASN*. Interesting, and no *v6*
> >>
> >> While the bylaws defines LIR as followed:
> >> ++++++
> >> Local Internet Registry (LIR):
> >> any Network Operator that provides Internet services to distinct
> >> end-users and end-sites
> >> ++++++
> >>
> >> I wonder which network does cloud innovation operate and which internet
> >> services it provides to end-users and end-sites in *Africa*.
> >>
> >> How does this network *managing 3 x /11 of IPv4* *operate*?
> >>
> >> There is something here for the community to learn about.
> >>
> >> Regards
> >>
> >> --
> >> Arnaud
> >>
> >> Le sam. 23 mai 2020 ? 14:20, Gregoire EHOUMI via RPD <rpd at afrinic.net>
> a
> >> ?crit :
> >>
> >>> Hello,
> >>>
> >>> Thanks Mark for exposing the details of the SEACOM AS37353 hijacking.
> >>>
> >>> I carefully read your report and also the Cloud Innovation Limited
> quick
> >>> response including their attachments as justifications.
> >>>
> >>> I note that;
> >>>
> >>> ? the service contract with Cloud Innovation covering the announcement
> >>> of their prefixes by SEACOM AS37353 was terminated by SEACOM.
> >>>
> >>> ? some stale IRR route objects existed after termination of the
> contract.
> >>>
> >>> ? through some multiple layer distribution an organisation in Manila
> >>> Philippines was ?delegated? an IP block from Cloud Innovation address
> space.
> >>>
> >>> ? both upstream ISP and the customer in Manila set up a BGP session
> >>> using SEACOM's AS37353 as the ASN of the Manila customer.
> >>>
> >>> ? there was a prompt reaction from the involved parties that included
> >>> apologies to SEACOM and the wider internet community.
> >>>
> >>> ? there were promises from said parties to be a better netizen which
> >>> would mean, them not hijacking other networks ASN's.
> >>>
> >>> ? there was clear refusal to disclose the details of the customer in
> >>> Manila Philippines who hijacked the affected SEACOM ASN.
> >>>
> >>> All put together, demonstrates that what happened was an impersonation
> >>> and not a BGP configuration error, nor an oversight in checking the
> right
> >>> to use of the SEACOM ASN.
> >>>
> >>> 1. Why is it that the real customer did not bother presenting its
> >>> apologies to the community
> >>>
> >>> 2. Why is there refusal to reveal customer?s details?
> >>>
> >>> 3. Why is it that the said prefix is no longer seen in the routing
> table
> >>> originated by the genius ASN or any other ASN?
> >>>
> >>> 4. Which networks were involved and what happened to the end users?
> >>>
> >>> Can someone from AFRINIC explain what ?delegation of IP block? mean?
> >>>
> >>> Note: The self organised Internet knows how to deal with bad net
> >>> citizens.!
> >>>
> >>> Best regards
> >>> Gregoire Ehoumi
> >>>
> >>>
> >>> -------- Original message --------
> >>> From: Lu Heng <h.lu at anytimechinese.com>
> >>> Date: 2020-05-09 5:43 a.m. (GMT-05:00)
> >>> To: Mark Tinka <mark.tinka at seacom.mu>
> >>> Cc: "rpd at afrinic.net >> AfriNIC Resource Policy Discussion List" <
> >>> rpd at afrinic.net>
> >>> Subject: Re: [rpd] Cloud Innovation Displays Very Poor, If Not
> Criminal,
> >>> Netizenship
> >>>
> >>> To whom it may concern,
> >>>
> >>> On May 8, Mark Think posted a claim to multiple lists that Cloud
> >>> Innovation was abusing an ASN (37353) that didn?t belong to them (Cloud
> >>> Innovation) but rather belonged to Seacom through their acquisition of
> >>> MacroLAN.
> >>>
> >>> While we regret this unfortunate incident, Mark?s claims that it was
> >>> criminal or bad netizenship on the part of Cloud Innovation is without
> >>> foundation and utterly incorrect.
> >>>
> >>> As shown below in the attached document from Paul Wollner(Ex-CTO of
> >>> Macrolan who created IRR routes to allow Macrolan to announce Cloud
> >>> Innovation's prefix); letter from Link Infinity International Ltd.
> (Link
> >>> Infinity), A customer of Cloud Innovation; and attached LOA from LARUS
> >>> authorizing IPDC Solutions to announce the prefix with origin AS134190.
> >>> And a Letter from IPDC. This was an innocent mistake committed by third
> >>> parties and had nothing to do with any action by Cloud Innovation or
> LARUS.
> >>>
> >>> Here?s what happened:
> >>>
> >>> Cloud Innovation delegated a /24 to Link Infinity, an ISP in December
> >>> 2019.
> >>>
> >>>
> >>> Link Infinity further delegated that same /24 to IPDC and asked Cloud
> >>> innovation to issue an LOA, which we did. The LOA specifically required
> >>> IPDC to use its own ASN to announce the space (AS134190).
> >>>
> >>> IPDC subsequently authorized one of its customers to use the said
> prefix.
> >>>
> >>>
> >>> For reasons still unknown to Cloud Innovation, IPDC and their customer
> >>> set up a BGP session wherein their customer used AS37353 as the origin
> to
> >>> advertise prefix 156.241.3.0/24.
> >>>
> >>>
> >>> Upon discovering the announcement, rather than contact Cloud
> Innovation,
> >>> Mark contacted IPDC who provided him with an incomplete explanation
> blaming
> >>> their customer and Mark, not realizing that Cloud Innovation was not
> the
> >>> customer in question posted far and wide about the event. It is
> unclear to
> >>> us why he chose to do this rather than contact us to try and resolve
> the
> >>> issue.
> >>>
> >>>
> >>> A contributing factor to the erroneous BGP configuration by IPDC's
> >>> customer may have been data contained in some outdated IRR route
> objects
> >>> for 156.241.0.0/16 which have subsequently been deleted.
> >>>
> >>> As soon as we became aware of the problem (via Mark?s email), we began
> >>> to investigate the situation. As soon as it was clear that this was the
> >>> result of third-party actions, we reached out to Mark privately to let
> him
> >>> know what we knew and that we were still investigating. We delayed
> making a
> >>> public statement in order to try and ascertain all of the facts of the
> >>> situation. We prefer not to make public statements based on incomplete
> >>> information.
> >>>
> >>> We apologize to the community for our small part in this unfortunate
> >>> incident and assure you that we work very hard to remain good netizens
> and
> >>> will address any concerns promptly when they come to our attention.
> >>>
> >>>
> >>> Sincerely,
> >>>
> >>> Lu Heng
> >>> CEO
> >>> Cloud Innovations
> >>>
> >>> Attached:
> >>> 1. Letter from Paul Wollner
> >>> 2. Letter from Link Infinity
> >>> 3. LOA Issued to IPDC Solutions for announcing 156.241.3.0/24 from
> >>> AS134190
> >>> 4. Letter from IPDC
> >>>
> >>> FYI: LARUS is proving IP management service for Cloud Innovation, while
> >>> LARUS is also providing IP management service to other third parties
> in all
> >>> regions, for full disclosure, LARUS and Cloud Innovation are headed by
> same
> >>> CEO.
> >>>
> >>> Content of those letters have been posted here for your convince:
> >>>
> >>> *IPDC:*
> >>>
> >>> FOR IMMEDIATE RELEASE [Perusal of Cloud Innovation Ltd]
> >>>
> >>>
> >>> IPDC Solutions Pte Ltd (IPDC) is a customer of Cloud Innovation Ltd and
> >>> over the course of our corporate relationship we were given the
> authority
> >>> to use address block 156.241.3.0/24 since 9th December 2019.
> >>>
> >>>
> >>> On 12th December 2019, we have delegated that address block to our
> >>> client. Following which our client further instructed us to announce
> the
> >>> prefix with AS37353. In good will after minimal verification through
> WHOIS?
> >>> IP Prefix we have proceeded to execute our client?s request.
> >>>
> >>>
> >>> On 7th May 2020 IPDC was then contacted by SEACOM, the legitimate
> holder
> >>> of record for that ASN and have since learned that the customer?s use
> of
> >>> that ASN was erroneous and not permitted by SEACOM and immediate
> action has
> >>> been taken to rectify this situation.
> >>>
> >>>
> >>> IPDC would like to apologize for our lack of attention in conducting
> >>> thorough verification and wish to highlight that the involvement of
> Cloud
> >>> Innovation Ltd in the entire process was providing the addresses to us
> and
> >>> that we truly apologize as we understand that this incident may have
> >>> indirectly implicated Cloud Innovation Ltd.
> >>>
> >>>
> >>> IPDC however, does not wish to disclose our client information and our
> >>> client information shall remain confidential under present
> circumstances.
> >>> Once again, we apologize for our shortcomings.
> >>>
> >>>
> >>> *Link Infinity:*
> >>>
> >>>
> >>> To whom it may concern,
> >>>
> >>> We at HK Infinity International Ltd are a customer of Cloud Innovation
> >>> and in the course received rights to use 156.241.3.0/24 from them.
> >>> Beginning December, 2019, we delegated the right to announce this
> prefix to
> >>> IPDC Solutions Pte Ltd. (IPDC). We asked Cloud Innovation to provide
> an LOA
> >>> authorizing them to announce the space which was subsequently received.
> >>> IPDC subsequently and without our knowledge delegated this space to
> one of
> >>> their customers and allowed them to originate it from AS37353.
> >>>
> >>> This announcement was not authorized by us, nor is it permitted by the
> >>> LOA provided by Cloud Innovation.
> >>>
> >>> Unfortunately, we were not aware of the situation until after it had
> >>> already been resolved.
> >>>
> >>> It was never our intent to violate the LOA or to allow the prefix to be
> >>> announced from a hijacked ASN. We do not condone this and apologize
> >>> sincerely to the community for what has happened here.
> >>>
> >>> Sincere Apologies,
> >>>
> >>>
> >>> *Paul Wollner:*
> >>>
> >>>
> >>> 8 May 2020
> >>>
> >>> TO WHOM IT MAY CONCERN
> >>>
> >>> In the light of the recent email on NAPAfrica mailing list, I would
> just
> >>> like to clear the air.
> >>>
> >>>
> >>> The IP route objects were created by myself for Cloud Innovation when
> >>> they signed up as a client of Macrolan ( now SEACOM) as they didn't
> have
> >>> their own AS.
> >>>
> >>> At the time I was working for Macrolan (now SEACOM). I left the
> >>> employment of SEACOM in October 2019.
> >>>
> >>> It appears that when Cloud Innovation's contract with SEACOM came to an
> >>> end, the route objects were never cleaned up.
> >>>
> >>> This occurred after I left SEACOM's employment. Since leaving, I have
> no
> >>> access to these objects.
> >>>
> >>> Regards
> >>>
> >>> Paul Wollner
> >>> 082-786-9776
> >>>
> >>>
> >>>
> >>> On Fri, 8 May 2020 at 22:10, Mark Tinka <mark.tinka at seacom.mu> wrote:
> >>>
> >>>> Hi all.
> >>>>
> >>>> I'm not one to b**ch & moan in public, but per subject, I could not
> let
> >>>> this one slide.
> >>>>
> >>>> And if you get this from multiple mailing lists, apologies for that -
> >>>> I'm just trying to make sure that this reaches as wide an audience as
> >>>> possible, on the continent.
> >>>>
> >>>> SEACOM (AS37100) acquired MacroLan (AS37353) a couple of years ago.
> >>>> MacroLan is now part of the SEACOM family, and while we are in the
> process
> >>>> of integrating that network into AS37100, some existing services
> continue
> >>>> to be delivered on AS37353 until that exercise is completed.
> >>>>
> >>>> One of the customers that AS37353 was providing services to was Cloud
> >>>> Innovation, in Cape Town. From a routing perspective, because Cloud
> >>>> Innovation had no AS number for this service, all of their IP address
> space
> >>>> was being originated by AS37353, on their behalf.
> >>>>
> >>>> In December of 2019, AS37353 ceased providing services to Cloud
> >>>> Innovation. That is 6 months ago.
> >>>>
> >>>> In recent days, it came to SEACOM's attention that some of Cloud
> >>>> Innovation's IP address space was being originated by AS37353 -
> >>>> specifically, 156.241.3.0/24 - even though we were sure that they
> were
> >>>> no longer a customer of AS37353 since December of 2019. At first, we
> >>>> thought this was a cached entry in a number of popular looking
> glasses, but
> >>>> then every looking glass had the same entry, which made this an
> unlikely
> >>>> bug.
> >>>>
> >>>> As of yesterday afternoon, see below what Telia's looking glass was
> >>>> saying about this prefix:
> >>>>
> >>>> *****
> >>>>
> >>>> Path #1: Received by speaker 0
> >>>> 4809 134190 37353
> >>>> 2.255.249.42 (metric 2134) from 2.255.253.101 (80.91.242.40)
> >>>> Origin incomplete, localpref 200, valid, internal, best,
> >>>> group-best, import-candidate
> >>>> Communities:
> >>>>
> >>>> 1299:431
> >>>> (RPKI state Unknown)
> >>>>
> >>>> 1299:1000 1299:30000 1299:30600 23456:20413 45352:4500 45352:9204
> >>>>
> >>>> *****
> >>>>
> >>>> But when I run a traceroute from my house to that prefix, it clearly
> >>>> was not ending up in Cape Town, where AS37353's main operation
> resides:
> >>>>
> >>>> *****
> >>>>
> >>>> MacBook-Pro-7:~ tinka$ traceroute -I 156.241.3.1
> >>>> traceroute to 156.241.3.1 (156.241.3.1), 64 hops max, 72 byte packets
> >>>> 1 172.16.0.254 (172.16.0.254) 14.824 ms 11.522 ms 3.525 ms
> >>>> 2 xe-1-3-0-1064.er-01-jnb.za.seacomnet.com (105.22.37.13) 5.620 ms
> >>>> 9.714 ms 9.887 ms
> >>>> 3 ce-0-2-0-0.cr-02-jnb.za.seacomnet.com (105.16.28.2) 175.232 ms
> >>>> 172.699 ms 175.896 ms
> >>>> 4 xe-0-0-0-8.cr-02-cpt.za.seacomnet.com (105.16.9.182) 164.496 ms
> >>>> 163.578 ms 163.546 ms
> >>>> 5 105.16.14.153 (105.16.14.153) 169.812 ms 171.272 ms 177.115 ms
> >>>> 6 xe-0-0-0-0.br-02-lhr.uk.seacomnet.com (105.16.34.253) 168.911 ms
> >>>> 172.958 ms 165.165 ms
> >>>> 7 82.112.115.169 (82.112.115.169) 172.700 ms 176.482 ms 174.375
> ms
> >>>> 8 ae-17.r05.londen12.uk.bb.gin.ntt.net (129.250.2.147) 672.099 ms
> >>>> 613.617 ms 615.109 ms
> >>>> 9 ae-2.r24.londen12.uk.bb.gin.ntt.net (129.250.4.244) 181.952 ms
> >>>> 183.087 ms 187.302 ms
> >>>> 10 ae-16.r20.frnkge13.de.bb.gin.ntt.net (129.250.3.13) 190.511 ms
> >>>> 185.579 ms 187.058 ms
> >>>> 11 ae-3.r20.sngpsi07.sg.bb.gin.ntt.net (129.250.4.17) 520.882 ms
> >>>> 613.982 ms 615.275 ms
> >>>> 12 ae-9.r24.tkokhk01.hk.bb.gin.ntt.net (129.250.7.67) 612.301 ms
> >>>> 586.886 ms 436.711 ms
> >>>> 13 ae-1.r03.tkokhk01.hk.bb.gin.ntt.net (129.250.6.98) 614.470 ms
> >>>> 613.416 ms 614.281 ms
> >>>> 14 ce-0-3-0-3.r03.tkokhk01.hk.ce.gin.ntt.net (203.131.241.126)
> >>>> 614.128 ms 613.661 ms 615.416 ms
> >>>> 15 * * *
> >>>> 16 * * *
> >>>> 17 156.241.3.1 (156.241.3.1) 494.400 ms 410.180 ms *
> >>>> MacBook-Pro-7:~ tinka$
> >>>>
> >>>> *****
> >>>>
> >>>> So we, then, realized that this was a fraudulent use of MacroLan's
> >>>> AS37353, to which we had given no express permission.
> >>>>
> >>>> As luck would have it, due to my days living and working in Malaysia,
> I
> >>>> know the good folk that operate AS134190 (IPDC Solutions), who was the
> >>>> upstream providing transit for this prefix. So I rang them up
> yesterday
> >>>> afternoon, told them what was happening, and within the hour, they
> got that
> >>>> eBGP session shutdown. I am most grateful to them for their quick
> response
> >>>> and immediate understanding of what was going on. Even with all the
> >>>> technology we have today, it, many times, comes down to having good
> friends
> >>>> in good places.
> >>>>
> >>>> Anyway, it turns out the ISP that had acquired this prefix from Cloud
> >>>> Innovation is based in Manila, Philippines. When IPDC delivered their
> >>>> transit service to them in Manila, that ISP informed them that they
> should
> >>>> use AS37353 for the eBGP session. Yes, one could argue that IPDC
> should
> >>>> have done their checks to ensure that the AS number being provided by
> their
> >>>> customer belongs to them, but to be honest, I'm not too bothered
> about that
> >>>> compared to Cloud Innovation's thinking that it was okay to use
> another
> >>>> network's AS number in order to deliver their services to their
> customers.
> >>>>
> >>>> IPDC confirm that this service was activated for the Manila ISP in
> >>>> December of 2019, right around the time Cloud Innovation's service
> with
> >>>> SEACOM, in Cape Town, ended.
> >>>>
> >>>> As it currently stands, the ISP in Manila is now off the Internet,
> with
> >>>> some 12 paying customers currently without service. Their excuse -
> they do
> >>>> not have an AS number of their own.
> >>>>
> >>>> IPDC tried to find out why the ISP in Manila thought that it was okay
> >>>> to use another network's AS number for their service, and as it turns
> out,
> >>>> the network engineer at the Manila ISP that set this up has since
> left the
> >>>> company. All the ones currently there do not have any history about
> all of
> >>>> this.
> >>>>
> >>>> Currently, 156.241.3.0/24 is not in the global BGP table:
> >>>>
> >>>> *****
> >>>>
> >>>> lg-01-ams.nl>sh ip bgp 156.241.3.0/24
> >>>> % Network not in table
> >>>> lg-01-ams.nl>
> >>>>
> >>>> lg-01-nbo.ke>sh ip bgp 156.241.3.0/24
> >>>> % Network not in table
> >>>> lg-01-nbo.ke>
> >>>>
> >>>> lg-01-cpt.za>sh ip bgp 156.241.3.0/24
> >>>> % Network not in table
> >>>> lg-01-cpt.za>
> >>>>
> >>>> *****
> >>>>
> >>>> That Cloud Innovation thought it was okay for them to use MacroLan's
> AS
> >>>> number to originate their own prefixes into the global BGP is as
> morally
> >>>> reprehensible as it is technologically distasteful.
> >>>>
> >>>> SEACOM have been working very closely with AFRINIC to delete previous
> >>>> route objects from their IRR that certify a relationship between Cloud
> >>>> Innovation's parent /16 aggregates that cover this prefix, and
> AS37353, but
> >>>> this is one of those objects that cannot be removed via the MyAFRINIC
> >>>> portal, and requires manual intervention from AFRINIC.
> >>>>
> >>>> I have not, personally, spoken to the proprietors of Cloud Innovation
> >>>> and/or Outside Heaven, as I don't see how anything could explain this
> with
> >>>> any degree of justification.
> >>>>
> >>>> For now, I will find some beer to wipe the foul taste from my mouth,
> >>>> while we (SEACOM) consider what to do about this.
> >>>>
> >>>> And yes, for those who are wondering, RPKI's ROV would not have
> >>>> prevented this, in its current form. This is AS hijacking, and ROV,
> today,
> >>>> tries to solve the prefix-hijacking problem, first.
> >>>>
> >>>> Thank you for your attention.
> >>>>
> >>>> Mark.
> >>>> _______________________________________________
> >>>> RPD mailing list
> >>>> RPD at afrinic.net
> >>>> https://lists.afrinic.net/mailman/listinfo/rpd
> >>>>
> >>>
> >>>
> >>> --
> >>> --
> >>> Kind regards.
> >>> Lu
> >>>
> >>> _______________________________________________
> >>> RPD mailing list
> >>> RPD at afrinic.net
> >>> https://lists.afrinic.net/mailman/listinfo/rpd
> >>>
> >> _______________________________________________
> > RPD mailing list
> > RPD at afrinic.net
> > https://lists.afrinic.net/mailman/listinfo/rpd
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> https://lists.afrinic.net/pipermail/rpd/attachments/20200525/1ba40a18/attachment.html
> >
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> RPD mailing list
> RPD at afrinic.net
> https://lists.afrinic.net/mailman/listinfo/rpd
>
>
> ------------------------------
>
> End of RPD Digest, Vol 164, Issue 26
> ************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.afrinic.net/pipermail/rpd/attachments/20200526/a05bab4c/attachment-0001.html>
More information about the RPD
mailing list