- members-discuss - mailman.ripe.net

Purchase info
by info＠hecanet.net 25 Dec '19

25 Dec '19

Hello, dear customer We have received your deposit for retailer, document number 7590-833R. You could find your legal receipt and all order № #998026 further details in the file. We are grateful for your business.

3 2

Re: [members-discuss] Feedback Requested: RIPE NCC Broker List
by Schnabeltier 19 Dec '19

19 Dec '19

17 17

LIR contact email for the RIPE Meeting free tickets
by Alessandro Bondesan 18 Dec '19

18 Dec '19

Hello all, doe's someone know where RIPE NCC sends the RIPE Meeting Free Partecipation Tickets? To all LIR users email or to the public email reported on the "Account Details" in the LIR Portal? Thank you Alessandro Bondesan

2 1

Re: [members-discuss] [LIR] Re: Fwd: Re: RIPE DB T&C violation by brokers
by Gruber Wolfgang 15 Dec '19

15 Dec '19

Have also got one today, as everyday. But we will report all these mails to Spamcop ;-) And after every transfer, we did this year (three times) the brokers Are really spamming… Br Wolfgang freundliche Gruesse Ing. Wolfgang Gruber Ing. Wolfgang Gruber Salzburg AG für Energie, Verkehr und Telekommunikation Technische Services / Netzservice T +43/662/8884-9447, M +43/676/86829447, F +43/662/8884-1709447 wolfgang.gruber(a)salzburg-ag.at<mailto:wolfgang.gruber@salzburg-ag.at>, http://www.salzburg-ag.at<http://www.salzburg-ag.at/> Vogelweiderstrasse 65, 5020 Salzburg, Oesterreich Von: Ekatrina Dyakova (e.dyakova(a)supplity.com.tr) <system(a)sent-via.netsuite.com> Gesendet: Donnerstag, 5. Dezember 2019 10:54 An: noc(a)xxx.xx Betreff: Ripe /21, /22, /23. and Apnic /18 Ranges ready to transfere [https://gallery.mailchimp.com/7f4c7cdf177609b1e04b2649e/images/b632b877-255…] [https://gallery.mailchimp.com/7f4c7cdf177609b1e04b2649e/images/c9691064-f37…] BUY YOUR NEW IPV4 We are glad to announce that we are doing special offers for selling the following IPV4 addresses: ARIN IPv4 /18 RIPE IPv4 /21 RIPE IPv4 /22 RIPE IPv4 /23 BUY NOW FROM SUPPLITY<http://mrkt.supplity.com/app/crm/marketing/campaignlistener.nl?c=5081144&__…> Copyright © 2019 SUPPLITY, All rights reserved. Contact Us: info(a)supplity.com<mailto:info@supplity.com> TURKEY - Istanbul - ŞiŞli Tel: +90 850 455 0148 Fax: +90 212 8061288 Click here<http://mrkt.supplity.com/app/crm/marketing/campaignlistener.nl?c=5081144&__…> to manage your email subscription preferences. Click here<http://mrkt.supplity.com/app/crm/marketing/campaignlistener.nl?c=5081144&__…> or reply to this email with 'unsubscribe' in the subject to unsubscribe from this list or if you feel you have received this message in error. This message was sent from SUPPLITY, Sisli, Istanbul, Turkey . Click here<http://mrkt.supplity.com/app/crm/marketing/campaignlistener.nl?c=5081144&__…> to report email abuse. ________________________________ [http://mrkt.supplity.com/app/crm/marketing/campaignlistener.nl?c=5081144&__…] You are subscribed as <noc(a)sol.at<mailto:noc@sol.at>>. Click here<http://mrkt.supplity.com/app/crm/marketing/campaignlistener.nl?c=5081144&__…> to manage your email subscription preferences. Click here<http://mrkt.supplity.com/app/crm/marketing/campaignlistener.nl?c=5081144&__…> or reply to this email with 'unsubscribe' in the subject to unsubscribe from this list or if you feel you have received this message in error. This message was sent from Supplity Kassem IT, Jabel Ali, Freezone, Technology Park PVAXX Building, Office 135 Dubai United Arab Emirates. Click here<http://mrkt.supplity.com/app/crm/marketing/campaignlistener.nl?c=5081144&__…> to report email abuse. Salzburg AG für Energie, Verkehr und Telekommunikation Sitz: Bayerhamerstraße 16, A 5020 Salzburg Firmenbuch: FN 51350 s, Landesgericht Salzburg Rechtsform: Aktiengesellschaft www.salzburg-ag.at<http://www.salzburg-ag.at/> Serviceline 0800 / 660 660 (kostenlos) Fax: +43 (0)662/8884-170 Die Information dieses E-Mails ist vertraulich und nur für den Adressaten bestimmt. Der Text könnte verfälscht sein - der Absender haftet nicht für die Integrität der E-Mail. Die Salzburg AG weist darauf hin, dass rechtsgeschäftliche Erklärungen (insbesondere auch Verpflichtungen) über dieses Medium nicht ausgetauscht werden - ausgenommen dies wurde konkret anders vereinbart. Der Schutz Ihrer Daten ist uns sehr wichtig. Informationen zur Verarbeitung Ihrer Daten finden Sie unter www.salzburg-ag.at/servicemenue/datenschutz.html<http://www.salzburg-ag.at/servicemenue/datenschutz.html>. This e-mail is confidential and for addressee only. This e-mail may be falsified - the sender cannot be held responsible for the integrity of this message. Correspondence with Salzburg AG via e-mail is only for information purposes and non obligatory. If not expressly agreed otherwise this medium is not used for the exchange of legally binding communication. The protection of your personal data is very important to us. Our privacy policy (www.salzburg-ag.at/servicemenue/datenschutz.html) informs you about the processing of your personal data.

6 5

New LIR with existent organization object
by Alexander Shikov 10 Dec '19

10 Dec '19

Hello! Dear Community, recently one of our companies became a LIR. Before that we already had organization, role, nic-hdl objects. For instance, our organization object is present in RIPE DB from 2010. Existent organisation object is not tied to any LIR account, but it is tied to a bunch of other objects like inet-nums, aut-nums etc. RIPE NCC refuses the usage of existent organization object. They just suggest to "update your other object with new one". It is really annoying. Ok, we have not many objects, but what shall we do if we'd have had a hundreds of them? Why we cannot use existent organization object for a new LIR?! Is there any policy which obliges RIPE NCC to create new one? Thanks! -- Alexander Shikov IT Consulting L.L.C. Tel.: +380 44 201 1407 | Fax: +380 44 201 1409 | Mob.: +380 50 410 3057

2 1

RIPE NCC Ticketsystem suggestion
by Dominic Schallert 06 Dec '19

06 Dec '19

Hello List, after the migration from RTT to Zendesk some while ago, it seems it is still not yet possible for members/LIRs to view previous tickets and a particular ticket's message history. Why? - AFAIK Zendesk provides widgets which could be integrated into my.ripe.net <http://my.ripe.net/> aka. the LIR portal. - Another possibility might be SSO-based auth and customer frontend access to ripencc.zendesk.com <http://ripencc.zendesk.com/>. Just my five cents. Mit besten Grüßen Kind Regards Dominic Schallert, BA schallert.com e.U. | Hauptstr. 35b, 6800 Feldkirch, Austria UID: ATU66209211 | FN: 440372g | Gerichtsstand: LG Feldkirch Tel.: +43 5522 26500 | Fax: +43 5522 26500-100 www.schallert.com <http://www.schallert.com/> | office(a)schallert.com <mailto:office@schallert.com>

1 0

BLACK FRIDAY IPv4 transfer
by José Manuel Giner 03 Dec '19

03 Dec '19

Hello, we're interested to buy (full-transfer) a /22, If anybody is interested to sell us with a special price, please contact me with the proposal details. Thanks. -- José Manuel Giner https://ginernet.com

35 42

Re: [members-discuss] [LIR] Re: Fwd: Re: RIPE DB T&C violation by brokers
by Schnabeltier 28 Nov '19

28 Nov '19

1 0

Resource Certification (RPKI) alerts for...
by Carlos Friaças 18 Nov '19

18 Nov '19

Hi, I suspect some of you have also received something similar to this recently: ----- There are alerts about BGP announcements with your certified address space for pt.rccn in the Resource Certification (RPKI) service. These are BGP announcements with your certified address space that have the status Unknown. You should create a ROA for each authorised announcement to make them Valid: AS Number Prefix AS<redacted> 2000::/12 (...) ----- I didn't see the same message repeated 24h after this one, so i hope this huge fumble is now solved. Proper filters are also needed in the IPv6 world -- please don't forget about that :-)) Cheers, Carlos

4 3

An ISP offers to announce our prefix. Is that normal?
by Bernd Naumann 13 Nov '19

13 Nov '19

Hi, I have a question about the validly of an option provided by our ISP. Back story: We will move one of your office uplinks in germany next year to an other provider. They offered us various options how it could be implemented. In my personal option one option sounds technical crazier then the other, even that it is "enterprise". The management involved raised concern when the ISP noticed that if we wanna use "just BGP" we will loose any SLA for L3 services. With no doubt I see managements point but now it comes: Then the ISP offered us to announce _our_ prefix for us, from their ASN, and here I lost trust, and stopped the planning for now to get either confirmation or an other red flag. - Is this even "allowed" or recommend by RIPE policies or BCPs? - Wouldn't that be at least looks like a/an BGP hijacking (attempt)? Because I have not seen / read about that implementation anywhere... - Just in case this is ok-ish, how would I setup the ROA with RPKI so that it would be come valid? An other but related question: Regarding the "No SLA" thing: Could someone point me on how other ISPs handle this or what would be "industrial standard". I highly doubt the reasoning, that just because the customer is using his own gear that the ISP will get way with any disturbance of their service... Naive me thought that it would be like in your data center installations: You get transit v4 and v6 networks from the provider, configure BGP and are done. Yes this does not prevent a customer to mis-configure things but in this case we would just get a default route and announcing one or more prefixes. I hardly see any pitfalls here. Thanks in advise and for your time, Best, Bernd

6 9