- members-discuss - mailman.ripe.net

Change of conditions
by Aleksey Bulgakov 17 Dec '18

17 Dec '18

Dear all. I would like to ask you one question. If one company open account in June 2018, but respected executive board decides to implement restrictions in September - should the company to apply this restrictions? I mean the document https://www.ripe.net/publications/docs/ripe-709#transfer35 -- ---------- Best regards, Alexey Bulgakov

9 9

Re: [members-discuss] [exec-board] Change of conditions
by Rob Golding 17 Dec '18

17 Dec '18

> Curious about the statement that Companies House don't maintain records > of M&A activity. Surely they maintain a record of the controlling interest for > all UK companies They do, however whilst for most companies that's "correct" at least once a year (we hope), in the majority of M&As there are no changes at companies house as the original "org" is no longer required/wanted - Directors/owners/shareholders details do get updated where they want to continue that "brand" but that's sub-10% of company acquisitions, the bulk of M&A activity in the LTD space (rather than PLC space) is "asset" rather than "share" based [with about 1/3rd being where the liquidators sell off the assets , or goodwill/brand or whatever] So the statement is correct in general terms, that nothing appears at companies house As to whether you can "infer" it (as some of us do when regular buyers take over companies we're following) ... > If it is on record that A is now a PSC with >50% voting/equity of B then an > acquisition has taken place No it means A has 50% of the equity, that’s very different to an acquisition, although can be indicative of takeover - the ability to vote on a resolution and the running of a company are very different things > and if B and C notify their PSCs are the same then > a merger between B & C has taken place. It means nothing of the sort. Being listed as the same PSC on multiple companies absolutely does not mean in any way they have merged. IP Cortex own corporate structure being a good example of why this doesn’t mean what you're saying - 2 separate legal entities despite same PSCs/Shareholders - not Merged, not Acquired, just "similarly owned" > My understanding is that for many things RIPE want a (virtual) piece of paper > that certifies X is true, rather than a process for verifying in a public database > that X is true I think the idea of formalising what can be used where public-database doesn't contain the data is good overall, but exactly how you do that I am not sure - I can see lots of ways to not do it effectively though :) Rob --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus

2 1

Re.: Policy violation
by FreeData 14 Dec '18

14 Dec '18

1 0

Policy violation
by Николай Давыденко 14 Dec '18

14 Dec '18

1 0

Policy violation
by FreeData 14 Dec '18

14 Dec '18

1 0

Policy violation
by FreeData 14 Dec '18

14 Dec '18

1 0

Re: [members-discuss] billing problem on multiple lir accounts.
by ripe-member-discuss+lr＠c2play.de 12 Dec '18

12 Dec '18

1 0

Re: [members-discuss] Our AS is in a macro that we don't authorize.
by Erik Bais 10 Dec '18

10 Dec '18

I have to agree with Karl. I also have some AS-SETS in the RIPEDB that we use for RPSL stuff that we feed into a routeserver of an IXP for instance.. with whom we don't want to peer with .. it works as an exclude list. The list isn't used for providing transit or telling others that they can find them in our AS cone ... so doing authorisations on them or other stuff would break things in our case.. Depending of the usage, it will give a different result. Regards, Erik Bais On 05/11/2018, 07:49, "members-discuss on behalf of Kaiser, Karl" <members-discuss-bounces(a)ripe.net on behalf of karl.kaiser(a)upc.at> wrote: Hi, I do understand your concerns, but: also your AS number shows up in someone elses AS-SET is does not mean any traffic being routed anywhere. This is mainly a documentational and a possible security issue (also no harm seems to be done by now). AS24748 seem to have 106 Peers - far away from the "thousands". The macro: AS24748:AS-THINX contains about every single active AS-Number i know of (at least the first 10 of 15 that came into my mind were in there). So there guy's built a fancy and completely useless macro - maybe they shouldn't consider their upstream to be their customers. Anyhow - forget about them or try to make them clean up their mess - but I don't think this mailinglist might be able to help you any further. Kind regards Karl ________________________________________ Von: members-discuss [members-discuss-bounces(a)ripe.net]" im Auftrag von "José Manuel Giner [jm(a)ginernet.com] Gesendet: Freitag, 02. November 2018 10:27 An: members-discuss(a)ripe.net Betreff: Re: [members-discuss] Our AS is in a macro that we don't authorize. I want my traffic routed where I want it. I'm not a member of that IX and if you're routing traffic through this IX, it's being a latency problem (my servers are a far away from that IX, +60 ms) and possibly a hijaking security problem. On 01/11/2018 10:13, Tapio Haapala wrote: > Why you want remove your AS from IX routing list? You want that your > prefixes does not get routed to some part of internet? Correct if I am > wrong but for me that looks more like that at least someone (atman) do > filtering even for tier1 operators and at least in theory it should be > good thing. > > > On 30.10.2018 16:27, José Manuel Giner wrote: >> Hi, we checked that our AS is present in the macro: AS24748:AS-THINX >> (they have thousands of AS in their macro) >> >> After contacting atman.pl who is responsible for this macro, they tell me: >> >>> It appears that AS59432 is contained in one of our customers AS-SETs and >>> it is automatically added to our AS-SET AS24748:AS-THINX >>> >>> As soon as they remove AS59432, it will disappear from AS24748:AS-THINX >> >> We have asked him how we can find out who that customer is. But their >> answer doesn't give us any information. >> >>> Please be kindly informed that our macros are being built automatically >>> according to our customers` macros. If your AS happens to be removed >>> from whichever of our customer`s macros, ours is to be changed >> accordingly. >> >> We are concerned about this situation and do not know how to proceed. >> >> Thank you for your help! >> > > -- José Manuel Giner http://ginernet.com _______________________________________________ members-discuss mailing list members-discuss(a)ripe.net https://lists.ripe.net/mailman/listinfo/members-discuss Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/karl.kaiser%40upc.at Information gemäß § 14 Unternehmensgesetzbuch: T-Mobile Austria GmbH, Firmensitz: Wien, Geschäftsanschrift Rennweg 97-99, 1030 Wien, Firmenbuchnummer: FN 171112 k, Handelsgericht Wien. _______________________________________________ members-discuss mailing list members-discuss(a)ripe.net https://lists.ripe.net/mailman/listinfo/members-discuss Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/erik%40bais.name

1 0

Re: [members-discuss] LIR???s billing issues with RIPE NCC, need support
by Bunea TELECOM 06 Dec '18

06 Dec '18

Can you please show me a successful implementation of NAT in a medium sized datacenter? I am quite curious. Also, how about companies that have a dormant /8 which they don’t even announce ? I think you should be angry over them, for having millions of IPv4 unused, and not over us, who have a few thousands. I think they are the ones you refer to as stealing the future of other companies, right ? — Petru Bunea / CEO suport(a)bunea.eu <mailto:suport@bunea.eu> / +40752481282 <tel:+40752481282> Bunea TELECOM / DATACENTER / APP DEVELOPMENT http://www.bunea.eu <http://www.bunea.eu/> / +40745495495 <tel:+40745495495> > On 4 Dec 2018, at 15:50, Lutz Donnerhacke <L.Donnerhacke(a)iks-service.de> wrote: > > You can’t avoid NAT, because there are not enough IPv4’s for everybody. > You can’t change this, because the IPv4 pool is limited by technical standards. > So you either implement NAT or move to IPv6. The best advice is to do both. > > Faking LIRs for RIPE in order to grab legacy IP space is stealing the future of other companies. > > Von: Bunea TELECOM <suport(a)bunea.eu <mailto:suport@bunea.eu>> > Gesendet: Dienstag, 4. Dezember 2018 14:16 > An: Lutz Donnerhacke <L.Donnerhacke(a)iks-service.de <mailto:L.Donnerhacke@iks-service.de>> > Cc: members-discuss(a)ripe.net <mailto:members-discuss@ripe.net> > Betreff: Re: [members-discuss] LIR???s billing issues with RIPE NCC, need support > > Hello Lutz, > > Perhaps you should also offer some advice for us, we run a datacenter and we are very curious how we can evolve without having to open up multiple LIR accounts? > I don’t think NAT is a solution, so I am waiting for your answer. > > Thanks > — > > > <image001.jpg> > > > > > Petru Bunea / CEO > suport(a)bunea.eu <mailto:suport@bunea.eu> / +40752481282 <tel:+40752481282> > Bunea TELECOM / DATACENTER / APP DEVELOPMENT > http://www.bunea.eu <http://www.bunea.eu/> / +40745495495 <tel:+40745495495> > > > On 4 Dec 2018, at 14:50, Lutz Donnerhacke <L.Donnerhacke(a)iks-service.de <mailto:L.Donnerhacke@iks-service.de>> wrote: > > Because I need more addresses to offer to my customers. Purchasing > addresses from open market is risky. Thats why I open new LIRs. > > You are doing it wrong. > > Please learn how to operate an ISP in modern times. > Two hints: > - https://lutz.donnerhacke.de/eng/content/search?SearchText=NAT <https://lutz.donnerhacke.de/eng/content/search?SearchText=NAT> (use deepl.com <http://deepl.com/>) > - https://tools.ietf.org/html/rfc6540 <https://tools.ietf.org/html/rfc6540> > > But please stop wasting tight resources by incompetence. > And please stop stealing resources from others by tricking RIPE policies. > > Please note, that your message is enough to reclaim the illegal obtained resources back by RIPE NCC. That's one of the activities we pay them for. > _______________________________________________ > members-discuss mailing list > members-discuss(a)ripe.net <mailto:members-discuss@ripe.net> > https://lists.ripe.net/mailman/listinfo/members-discuss <https://lists.ripe.net/mailman/listinfo/members-discuss> > Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/suport%40bunea.eu <https://lists.ripe.net/mailman/options/members-discuss/suport%40bunea.eu> >

3 2

Re: [members-discuss] LIR???s billing issues with RIPE NCC, need support
by support 05 Dec '18

05 Dec '18

Ist very good what you are writing there Lutz.The reality is another thing, especially about IPv6.We are using both well, but we are a company located in Kenya.Kenya dont use IPv6 which means that when we dont work with both (IPv4 and IPv6) our Sites will not be available worldwide, especially in Kenya. This dont mean right now that I support lower prices and lower transfer time.Who opens a LIR have to accept the rules, otherwise dont think even to open one!Have a nice day guys. Christian Lutzner Vhost Meremeta LTDVon meinem Samsung Galaxy Smartphone gesendet.

3 3