- members-discuss - mailman.ripe.net

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

Re: [members-discuss] An ISP offers to announce our prefix. Is that normal?
by Bernd Naumann 12 Nov '19

12 Nov '19

Hi Matthias, But that's the point, we can and would prefer to maintain our own gear. I'm just find it curious that the provider states, that in this case we would get no L3 SLA. And regarding "someone else announces our prefix": I just never heard of it that this is common. That's why I'm asking. With this provider, or at this location we have not yet BGP in place. To recap: Announcing "someone else" prefix is OK, and the ROA can be signed. As I have not seen this in the RPKI FAQ: can I also sign i.e. the aggregate ROA prefix, one time from our ASN and one time from the providers ASN? And things are still valid? In this case I would not see a reason not to do it that way. Bernd On 12.11.19 12:50, Matthias Brumm | tkrz Stadtwerke GmbH wrote: > Hi! > > We have done simlar things, if the customer does not want to maintain his own router or has no knowledge in this. Could you please explain, why there is such a problem? If you have an ASN and there are BGP sessions in place, announcing your prefix, you just change one session for the other. > > Regards, Mit freundlichen Grüßen, > > > 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

3 3

Re: [members-discuss] An ISP offers to announce our prefix. Is that normal?
by Bothe, Jason 12 Nov '19

12 Nov '19

HI Michael, we do have a quite large relationship with them but it seems the issue is with their sister org, HKT which is behind the PCCW. I have submitted tickets, completed forms and all I get is its 'in progress'. It's been months. J~ On 11/12/19, 7:13 AM, "Michael Boehme" <mboehme(a)webdiscount.net> wrote: Jason, do you have any contractional relationship with PCCW so you could officially insert a ticket and ask them to remove it? They´re not supposed to do so if origin in RIRs databases points to your AS number. We do have ip transit from them in Hong Kong so we could try to see if this helps Thanks Michael Mit freundlichen Grüßen Michael Böhme KOMPETENZ VERBINDET. WEBDISCOUNT GmbH & Co. KG Robert-Bosch-Straße 20 48153 Münster, Deutschland Fon +49 251 263930-0 Fax +49 251 263930-49 https://urldefense.proofpoint.com/v2/url?u=http-3A__www.webdiscount.net&d=D… Sitz der Kommanditgesellschaft: Münster Amtsgericht Münster HRA 8897 USt.ID: DE 815 197 935 Persönlich haftende Gesellschafterin: WEBDISCOUNT Verwaltungs GmbH Sitz der GmbH: Münster Amtsgericht Münster HRB 12721 Geschäftsführer: Michael Böhme -----Ursprüngliche Nachricht----- Von: members-discuss <members-discuss-bounces(a)ripe.net> Im Auftrag von Bothe, Jason Gesendet: Dienstag, 12. November 2019 14:08 An: Job Snijders <job(a)ntt.net>; Bernd Naumann <bena(a)spreadshirt.net> Cc: members-discuss(a)ripe.net Betreff: Re: [members-discuss] An ISP offers to announce our prefix. Is that normal? If anyone could tell me how to get an ISP to 'un-announce' prefixes on your behalf I will buy them dinner. I have two prefixes of mine that PCCW won't to take down and at this point I have better chances of convincing Donald Trump to resign than I do getting PCCW to remove them from their announcements. J~ On 11/12/19, 6:48 AM, "members-discuss on behalf of Job Snijders" <members-discuss-bounces(a)ripe.net on behalf of job(a)ntt.net> wrote: Dear Bernd, Good questions, thanks for bringing them up, this topic indeed doesn't receive much attention. I can't comment on the specifics of your case in regard to SLA and what the best choices are for your organisation, but I can share one small data point. On Tue, Nov 12, 2019 at 12:16:53PM +0100, Bernd Naumann wrote: > 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. This actually is a common practise! Speaking from NTT's perspective we see that customer's used to run BGP in the past, but no longer have interest in maintaining that infrastructure and switch to a "Direct Internet Access" (DIA) product which usually is statically routing the IP space and perhaps using a first-hop redundancy protocol. In such cases the customers request NTT to announce the space on their behalf - which we can do provided that a RPKI ROA and IRR route object are created to demonstrate to the world that we in fact are allowed to originate the prefix. > - Is this even "allowed" or recommend by RIPE policies or BCPs? yes, this is allowed; and if it adequately addresses the challenges you are trying to solve for your organisation I'd say it is even 'recommended' ;-) - the real answer is "it depends". > - Wouldn't that be at least looks like a/an BGP hijacking (attempt)? it would not look like a BGP hijack if RPKI ROAs / IRR "route:/route6:" objects are created in the appropriate places authorising the ASN that originates the prefix. > - Just in case this is ok-ish, how would I setup the ROA with RPKI so that > it would be come valid? You'd go to the RIPE web portal, and create a RPKI ROA like you'd normally do, but instead of inputting your own ASN you input the ASN of the provider that will announce the space on your behalf. You create/have multiple ROAs covering the same prefix but with different Origin ASNs co-exist - this allows you to make-before-break in transitions such as you might be going through at this moment. A variant of the scenario you describe is "BYOIP" in context of the cloud providers. The analogy is that instead of routing your IP space to your office, some cloud providers offer to announce your IP space and route it to your virtual datacenter: https://urldefense.proofpoint.com/v2/url?u=https-3A__aws.amazon.com_vpc_faq… https://urldefense.proofpoint.com/v2/url?u=https-3A__developers.cloudflare.… https://urldefense.proofpoint.com/v2/url?u=https-3A__cloud.ibm.com_docs_tut… https://urldefense.proofpoint.com/v2/url?u=https-3A__www.zdnet.com_article_… https://urldefense.proofpoint.com/v2/url?u=https-3A__ideas.digitalocean.com… . Your IP resources are yours*, and you are free to authorize anyone to route them on your behalf on the public internet. Kind regards, Job * not meaning to start debate about ownership, just wanted to emphasize that whether you do your own BGP or have someone do it on your behalf is the same. _______________________________________________ members-discuss mailing list members-discuss(a)ripe.net https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.ripe.net_mailman… Unsubscribe: https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.ripe.net_mailman… **************************************************************** Confidentiality Note: The information contained in this message, and any attachments, may contain confidential and/or privileged material. It is intended solely for the person(s) or entity to which it is addressed. Any review, retransmission, dissemination, or taking of any action in reliance upon this information by persons or entities other than the intended recipient(s) is prohibited. If you received this in error, please contact the sender and delete the material from any device. **************************************************************** _______________________________________________ members-discuss mailing list members-discuss(a)ripe.net https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.ripe.net_mailman… Unsubscribe: https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.ripe.net_mailman…

1 0

Ausente por vacaciones
by jg.mondejar＠airenetworks.es 12 Nov '19

12 Nov '19

Gracias por ponerse en contacto con Aire Networks. Le informamos que esta cuenta de correo: jg.mondejar(a)airenetworks.es; no será atendida hasta el próximo 13 de Noviembre. Por favor, utilice la siguiente cuenta de correo para contactar con nosotros: ingenieriadered(a)airenetworks.es. Saludos cordiales, Thank you for contacting with Aire Networks. We inform you that this email account: jg.mondejar(a)airenetworks.es; won't be answered till 13th of November. Please, use this email account to contact us: ingenieriadered(a)airenetworks.es. Best Regards,

1 0

Re: [members-discuss] IPv6 amount for one member
by Aleksey Bulgakov 16 Oct '19

16 Oct '19

20:27 Laurenz Ruprecht <mail(a)prvy.eu>: >>>Where did you notice that? Many partners couldn't transfer their IPv6, because receiving party already had /29. Also during audit the support asked: "Do you need 3×/29 IPv6, if not are you going to return them to the free pool? Please provide your further plan of deployment" вт, 15 окт. 2019 г., 20:27 Laurenz Ruprecht <mail(a)prvy.eu>: > > Hi Alex! > > > Earlier I have noticed that the NCC tries to return back > Where did you notice that? > > ------------------------------ > *From:* Aleksey Bulgakov <aleksbulgakov(a)gmail.com > <http:///email/new/1/aleksbulgakov%40gmail.com>> > *Sent:* Tuesday, 15. Oct 2019 – 19:15 CEST +0200 > *To:* members-discuss(a)ripe.net > <http:///email/new/1/members-discuss%40ripe.net> > > *Subject:* [members-discuss] IPv6 amount for one member > > Hi, all! > > Earlier I have noticed that the NCC tries to return back IPv6 allocations > to free pool if LIR has more than one /29. I understand that /29 is very > big, but is there any policy, which denies to keep more than /29 per LIR > (including additional accounts)? Or maybe is the IPv6 exhaustion like IPv4? > Also the NCC prevents IPv6 transfer to other LIR if the last one already > has IPv6. > > If you remember, some time ago the NCC required to request IPv6 prior IPv4 > request. So, what happens now? > > --- > Kind regards, > Alex >

4 4

Re: [members-discuss] IPv6 amount for one member (TicketID: KAYD-2122-VCOQ)
by AIXPRO 16 Oct '19

16 Oct '19

Dear Marian Marinov, dies ist eine automatische Antwort und bestätigt den Eingang Ihrer Nachricht. Wir werden uns so schnell wie möglich um die Bearbeitung kümmern. Damit wir jede Anfrage eindeutig zuordnen können, haben wir Ihrer Anfrage die folgende Ticket-Nr. zugewiesen: KAYD-2122-VCOQ Anfragen, die uns außerhalb der regulären Geschäftszeiten (montags bis freitags von 9 bis 18 Uhr) sowie an Feiertagen erreichen, bearbeiten wir spätestens am darauffolgenden Werktag. Handelt es sich bei Ihrem Anliegen um einen Notfall (z.B. Shop nicht erreichbar), können Sie im Kundenbereich ein Notfall-Ticket eröffnen, welches rund um die Uhr mit höchster Priorität durch unsere Techniker bearbeitet wird. Wir leisten kostenlosen Support für die überwachten und inkludierten Dienste Ihres Webspace-Paketes (E-Mail (IMAP, POP3, SMTP), MySQL, FTP, HTTP/HTTPS). Weiterführender Support wird in Abstimmung mit dem Kunden gesondert berechnet. Bei Dienst-Ausfall veröffentlichen wir Status-Meldungen unter Server-Status im Kundenbereich. Sie werden benachrichtigt, sobald Ihr Ticket eine Anwort erhält. Die Details zu Ihrer Anfrage sind unten dargestellt. On Wed, 16th Oct 2019 at 13:13, Marian Marinov <mm(a)1h.com> wrote: What if the IPv6 is used privately? I mean we have a /29 and we have used some of it for internal infrastructure on networks, that are currently not linked to upstream IPv6 provider. Are we in danger of loosing our current IPv6 allocation? Marian On 10/16/19 1:41 PM, Paul Thornton wrote: > Hi Gert, > > On 15/10/2019 22:46, Gert Doering wrote: >> I am fairly sure there is more to this than "just because receiving >> party already had a /29" - nothing in the policies would forbid that. >> >> Gert Doering >> -- NetMaster >> > As a datapoint, I certainly have been on the receiving end of this. > > Consider this scenario: LIR X has an existing /29, and LIR Y has a /32. Closing LIR Y and transferring all resources to LIR X triggered just such a question. > > I know that >/29 allocations are of course allowed - I think the issue arises when an LIR has their whole "initial largest" /29 allocation and then adds more through acquisition or transfer. > > Paul. > > > _______________________________________________ > 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/mm%401h.com > -- Marian Marinov Founder & CEO of 1H Ltd. Jabber/GTalk: hackman(a)jabber.org ICQ: 7556201 IRC: hackman @ irc.freenode.net Mobile: +359 886 660 270 _______________________________________________ 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/office%40aixpro.de Attachments • signature.asc <https://helpdesk.dogado.de/file.php/25169WGQMCAQRCT25168203C89AFDT/signatur…> (196.00 B) AIXPRO powered by dogado ____________________________________________ dogado GmbH - Saarlandstr. 25 - D–44139 Dortmund Telefon: +49 (0) 231 / 54385451-0 / Fax: +49 (0) 231 / 54385451-1 Handelsregister: HRB 19737, Amtsgericht Dortmund, Ust-IdNr: DE249338561 Geschäftsführer: Marcel Chorengel, Daniel Hagemeier, Ralph Cammerrath ____________________________________________ (#CQYMJ8MNCYJ355KB3S68)

1 0

Re: [members-discuss] IPv6 amount for one member (TicketID: LKZL-4318-RNRO)
by AIXPRO 15 Oct '19

15 Oct '19

Dear Gert Doering, dies ist eine automatische Antwort und bestätigt den Eingang Ihrer Nachricht. Wir werden uns so schnell wie möglich um die Bearbeitung kümmern. Damit wir jede Anfrage eindeutig zuordnen können, haben wir Ihrer Anfrage die folgende Ticket-Nr. zugewiesen: LKZL-4318-RNRO Anfragen, die uns außerhalb der regulären Geschäftszeiten (montags bis freitags von 9 bis 18 Uhr) sowie an Feiertagen erreichen, bearbeiten wir spätestens am darauffolgenden Werktag. Handelt es sich bei Ihrem Anliegen um einen Notfall (z.B. Shop nicht erreichbar), können Sie im Kundenbereich ein Notfall-Ticket eröffnen, welches rund um die Uhr mit höchster Priorität durch unsere Techniker bearbeitet wird. Wir leisten kostenlosen Support für die überwachten und inkludierten Dienste Ihres Webspace-Paketes (E-Mail (IMAP, POP3, SMTP), MySQL, FTP, HTTP/HTTPS). Weiterführender Support wird in Abstimmung mit dem Kunden gesondert berechnet. Bei Dienst-Ausfall veröffentlichen wir Status-Meldungen unter Server-Status im Kundenbereich. Sie werden benachrichtigt, sobald Ihr Ticket eine Anwort erhält. Die Details zu Ihrer Anfrage sind unten dargestellt. On Tue, 15th Oct 2019 at 23:49, Gert Doering <gert(a)space.net> wrote: Hi, On Tue, Oct 15, 2019 at 08:58:13PM +0300, Aleksey Bulgakov wrote: > 20:27 Laurenz Ruprecht <mail(a)prvy.eu>: > >>>Where did you notice that? > > Many partners couldn't transfer their IPv6, because receiving party already > had /29. I am fairly sure there is more to this than "just because receiving party already had a /29" - nothing in the policies would forbid that. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 _______________________________________________ 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/office%40aixpro.de Attachments • signature.asc <https://helpdesk.dogado.de/file.php/25147TJYJXPGQCX2514639833E29FT/signatur…> (834.00 B) AIXPRO powered by dogado ____________________________________________ dogado GmbH - Saarlandstr. 25 - D–44139 Dortmund Telefon: +49 (0) 231 / 54385451-0 / Fax: +49 (0) 231 / 54385451-1 Handelsregister: HRB 19737, Amtsgericht Dortmund, Ust-IdNr: DE249338561 Geschäftsführer: Marcel Chorengel, Daniel Hagemeier, Ralph Cammerrath ____________________________________________ (#CQXRP5BJWGD9W2GKQ4D5)

1 0

IPv6 amount for one member
by Aleksey Bulgakov 15 Oct '19

15 Oct '19

Hi, all! Earlier I have noticed that the NCC tries to return back IPv6 allocations to free pool if LIR has more than one /29. I understand that /29 is very big, but is there any policy, which denies to keep more than /29 per LIR (including additional accounts)? Or maybe is the IPv6 exhaustion like IPv4? Also the NCC prevents IPv6 transfer to other LIR if the last one already has IPv6. If you remember, some time ago the NCC required to request IPv6 prior IPv4 request. So, what happens now? --- Kind regards, Alex

2 1

Re: [members-discuss] [ncc-announce] [GM] Voting on the RIPE NCC 2019 Financial Surplus
by Nick Hilliard 15 Oct '19

15 Oct '19

CK, can you advise on the tax situation regarding the capital reserve? Previously the board stated that the agreement reached with the NL tax authorities specified an upper limit in how large the capital reserve could be without attracting corporation tax. Is this a floating limit relating to the annual revenue of the organisation, or was/is it a static limit? I.e. do either Options A or B have tax implications that we as members should know about? Nick > Christian Kaufmann <mailto:exec-board@ripe.net> > 10 October 2019 at 13:15 > Dear members, > > For the upcoming RIPE NCC General Meeting (GM), the Executive Board is > proposing three options for the RIPE NCC 2019 financial surplus. > > The Board feels strongly that this is an appropriate moment to > strengthen the RIPE NCC's capital position to make sure that it can > continue its work with a solid financial basis in the coming years. > > Therefore, the Board suggests that the membership vote for the option to > add 50% of the financial surplus to the RIPE NCC Clearing House reserves > and redistribute 50% to the membership in 2020. This option is a good > compromise between adding more capital for improved stability and a > predictable redistribution process where we return the financial surplus > to our members. > > Although there are three possible outcomes (the two usual choices and > the 50% choice), there are two voting options. This avoids the > possibility of all options being rejected and no decision being made on > the surplus. > > Option A (to add 100% to the reserves) is approved if it receives over > 50% of Yes votes. Votes for Option B (to add 50% to the reserves) are > only considered if Option A does not pass. If both options receive less > than 50% of Yes votes, then the entire surplus will be redistributed to > the membership in 2020. > > You can find more information in the supporting document: > https://www.ripe.net/participate/meetings/gm/meetings/october-2019/redistri… > > And we encourage all members to register to vote at the upcoming GM: > https://www.ripe.net/s/gm-registration-october-2019 > > Regards, > > Christian Kaufmann > RIPE NCC Executive Board Chairman >

2 1

Broker trade history
by Payam Poursaied 01 Jul '19

01 Jul '19

I wonder to know if there is any public statistic from brokers who were involved in RIPE NCC region transfers. Any comments is appreciated Best Regards Payam

2 1

New (silent) reverse dns checks
by Jonas Frey 10 Jun '19

10 Jun '19

Hi all, we just found out that RIPE seems to have silently integrated new checks for reverse delegation of zones. Its no longer possible to add or even change a zone if the nameservers used by them are open recursors. The update will fail. Yes - open recursors are (sometimes) bad. But there are legitimate reasons to run them (freedom of speech, filtered resources etc). Once properly configured (i.e. querys rate limited) they wont pose a threat. I wasnt able to find any information on when this was implemented or if this was even voted for (please someone supply me with links if possible). I dont know of any NIC/registrar that will deny the creation/update of a domain name if the nameservers are recursors. I know that some will warn but none will refuse it. Please fix me if there are some which will indeed deny. Of course i have created a ticket about this but it all went like "fix the dns or we wont delegate". So basically this is about 2 things: silently changing checks (if it was indeed silent) and if those checks are really usefull or should rather be dropped/changed to warnings. Regards, Jonas

9 18

Re: [members-discuss] New (silent) reverse dns checks
by Rudolf E. Steiner 08 Jun '19

08 Jun '19

Måns Nilsson wrote: > Mentioning djb and DNS operations is a bait, but I'm stupid and I'll bite. [...] All your arguments are understandable. But it's not up to RIPE to make one or another ideology technically compulsory. -- nemox.net Rudolf E. Steiner r.steiner(a)nemox.net http://nemox.net/pdat/res/

1 0

Transfer agreement
by Aleksey Bulgakov 24 May '19

24 May '19

Hi all. I think it would be great if the scan copy of the Transfer Agreement would be abolished and published as a checkbox when you create the request for transfer. What do you think? --- Regards, Alex.

11 15

Re: [members-discuss] Transfer agreement
by Francesco Cristofori 23 May '19

23 May '19

Fully agree with Bruno. Not having trading platforms on RIPE environment is net neutrality. [cid:image001.png@01D51194.972C6A00] Francesco Cristofori Solution Design & PM Manager T +39 059 7470500 @francesco.cristofori@adcgroup.com<mailto:francesco.cristofori@adcgroup.com> AD Consulting S.p.A. Via Natalia Ginzburg, 40 41123 Modena www.adcgroupspa.com<http://www.adcgroupspa.com/> From: members-discuss <members-discuss-bounces(a)ripe.net> On Behalf Of bruno.carvalho Sent: giovedì 23 maggio 2019 18:16 To: Oleg Zinkov <o.zinkov(a)kyivlink.com>; members-discuss(a)ripe.net Subject: Re: [members-discuss] Transfer agreement RIPE is a non-profit organisation. The purpose of selling/trading or acting has an escrow is not possible and not doable. Enviado a partir do meu smartphone Samsung Galaxy. -------- Mensagem original -------- De : Oleg Zinkov <o.zinkov(a)kyivlink.com<mailto:o.zinkov@kyivlink.com>> Data: 23/05/19 18:02 (GMT+01:00) Para: members-discuss(a)ripe.net<mailto:members-discuss@ripe.net> Assunto: Re: [members-discuss] Transfer agreement This is interesting. I support the sale/purchase of IP blocks on the RIPE platform. 23.05.2019 18:48, RedCluster пишет: Maybe digitally signed contracts? I'd personally prefer RIPE to act as a market and escrow intermediary between buyers and sellers. It would be much healthier to have all the blocks listed for sale and being able to buy risk-free directly on the RIPE platform. On 5/23/2019 6:38 PM, Oleg Zinkov wrote: Definitely. Only signed contracts. 23.05.2019 18:19, Michele Neylon - Blacknight пишет: Legally binding documents need to be “signed”. A checkbox will not suffice and it shouldn’t. Regards Michele -- Mr Michele Neylon Blacknight Solutions Hosting, Colocation & Domains https://www.blacknight.com/ http://blacknight.blog/ Intl. +353 (0) 59 9183072 Direct Dial: +353 (0)59 9183090 Personal blog: https://michele.blog/ Some thoughts: https://ceo.hosting/ ------------------------------- Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty Road,Graiguecullen,Carlow,R93 X265,Ireland Company No.: 370845 _______________________________________________ members-discuss mailing list members-discuss(a)ripe.net<mailto:members-discuss@ripe.net> https://lists.ripe.net/mailman/listinfo/members-discuss Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/o.zinkov%40kyivlink.… -- ---------------------- www.kyivlink.com<http://www.kyivlink.com> (044)332-96-55 Zinkov Oleg _______________________________________________ members-discuss mailing list members-discuss(a)ripe.net<mailto:members-discuss@ripe.net> https://lists.ripe.net/mailman/listinfo/members-discuss Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/admin%40redcluster.o… _______________________________________________ members-discuss mailing list members-discuss(a)ripe.net<mailto:members-discuss@ripe.net> https://lists.ripe.net/mailman/listinfo/members-discuss Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/info%40kyivlink.com -- ---------------------- www.kyivlink.com<http://www.kyivlink.com> (044)332-96-55 Zinkov Oleg

1 0

Conexions: Modify port - no option
by Dominik Nowacki 13 May '19

13 May '19

Hi, Hope you’re well. I don’t seem to have an option to modify any ports on connexions for some reason. Can you please have a look? [cid:19FE5E11-70A0-494D-A012-5D8017D59CFE] The links to the forms I’d normally use are no longer working, I get 404. Please advise. Kind Regards, Dominik

1 1

RIPE NCC Charging Scheme 2020 - Board Reasoning
by Christian Kaufmann 03 May '19

03 May '19

Dear members, First of all, I'd like to thank you for the feedback we received from everyone so far, and special thanks to the people who gave some more context and explanation. Trying to arrive at a charging scheme that will please everyone is not an easy task. The reason the board proposes two charging schemes is because some members requested a real alternative and difference to the existing "one LIR account-one fee" version we have right now and that is more volume based. This came up previously in the charging scheme task force discussions but also from individual members via emails or through personal contact. Nigel and I promised at the last two GMs that we would present a new one before the May GM this year. So what was the board's thinking in proposing these two models? Firstly, many people like the existing model and the board believes that it covers the spirit of what some members want by maintaining the financial stability of the NCC while keeping fairness and equality in mind. The board also does not want a price per IP model because this would have tax implications (the RIPE NCC does not sell IP addresses and the charging scheme should reflect this) and we feel it is not in keeping with the idea of a membership association. We have also found in the past that having more than two options does not work well from a voting perspective. This would add considerable complexity to the voting in which resolutions must be approved by more than 50% of voters to be adopted. The second charging scheme option is one that the board believes offers a real alternative while staying away from the price per IP aspect. The board's thinking in making the Option B proposal is that every registry entry consumes resources such as customer support time, database memory, registration time, etc. regardless of the size of the allocation. A /24 and a /12 are not so different in this regard so we see this as fair in terms of the work required by the RIPE NCC to maintain the registry. The reason we suggest to charge IPv4 and IPv6 in the same way follows the same logic - there is no tax designed to move people to IPv6. We did not want to have a political, policy-driven charging scheme because the board believes this is the work of community rather than for the board or membership to decide on. I understand that the "volume-based" description could be seen as misleading and I apologise for the misunderstanding here. The proposed model is based on registrations and not per IP as we do not want to indicate that IP is a sellable product but rather the RIPE NCC should charge members for the registry services it provides. The new charging scheme was also not proposed so that the RIPE NCC could make more money - it takes the current budget and calculates backwards to achieve the amount required to run the RIPE NCC. It is just a different model to share the current cost among members. Despite concerns that were raised on this list, the board took the request of some members to propose a new model very seriously and we spent quite some time to discuss and model the current scenario by trying to be as fair as possible and sticking with the principles of a membership organisation. Again, we are very thankful for your input and the feedback on the two models. We will continue to monitor discussions and we will of course present on the Charging Scheme 2020 at the upcoming GM. We encourage you to register your vote so you can have the final say on the two proposals. Best regards, Christian Kaufmann RIPE NCC Executive Board Chairman

26 37

Regarding RIPE NCC Charging Scheme 2020 - Two Options to Vote On
by Alexandru Doszlop 18 Apr '19

18 Apr '19

24 36

Re: [members-discuss] RIPE NCC Charging Scheme 2020 - Two Options to Vote On
by Peter Koch 18 Apr '19

18 Apr '19

Dear Board, {re-sent due to mailing list issues} On Wed, Apr 17, 2019 at 05:08:11PM +0200, Gwen van Berne wrote: > https://www.ripe.net/participate/meetings/gm/meetings/may-2019/supporting-d… while I do not have an issue with the current scheme "A", I would like to better understand the proposed scheme "B" and its overall impact. Quoting from the "Option B" document For the volume-based fee charges, we used the existing registration fee (50 EUR for Independent number resource assignments) as our starting point to arrive at a higher proportion of volume-based income. For the final volume-based fee calculations, we also looked at the 2020 budget for RIPE Registry-related activities (e.g. registry maintenance, resource certification) and we divided this number by the total number of registration blocks held by the member base to arrive at the cost per registration. In turn, each member is charged based on the total number of blocks the respective member holds multiplied by the cost per registration. The fixed annual LIR account fee will be EUR 1,150 as a consequence of the higher variable income stream related to registrations. Is non-consecutive address space allocated in a single 'registration transaction' counted as a single "registration block"? Does the above calculation assume that all "registrations" incur equal cost? Is scheme "B" supposed to be revenue neutral and how would or could this be maintained over time? While every LIR can do the calculations for themselves, how does the overall increase/decline picture look like, e.g., what is the maximum fee that, as of $today, an LIR would have to pay? Regards, Peter

1 0

Regarding RIPE NCC Charging Scheme 2020 - Two Options to Vote On
by REG ID: pl.skonet 18 Apr '19

18 Apr '19

Dear RIPE, Who asked about "volume" (quotes intentional) charging? First of all, please submit a plan to spend the huge amount of extra money you will get from option B. Today, you give the members a surplus from the annual budget, because you are not able to spend everything that you collect. I am definitely against option B. Please keep charging scheme as is. -- Tomasz Śląski pl.skonet

7 6

Charging Scheme 2020, calarification on resources issued on the same date
by Hostserver NOC 18 Apr '19

18 Apr '19

With the existing charging scheme, multiple PI resources that were issued on the same day share the same fee. With Option B, will that stay the same or will each PI resource be charged separately? Best Regards, Peter Hessler Hostserver GmbH

1 0

Regarding RIPE NCC Charging Scheme 2020 - Two Options to Vote On
by Alessandro Bondesan 18 Apr '19

18 Apr '19

Hello all On the charging scheme B it’s stated “50 € per registration” I don’t understand if “registration” means “Database entry” or “Assignment made by RIPE” someone can explain that? Many thanks ---------- Forwarded message ---------- From: Gwen van Berne <gvanberne(a)ripe.net> Date: Apr 17, 2019 18:08 Subject: [ncc-announce] [GM] RIPE NCC Charging Scheme 2020 - Two Options to Vote On To: ncc-announce(a)ripe.net Cc: Dear colleagues, Members will vote on the RIPE NCC Charging Scheme 2020 at the General Meeting from 22-24 May. In response to requests from members, the Executive Board is proposing two charging scheme options that the members can choose from at the GM. An overview of the two options is also available that explains the two models in more detail. The overview and the two charging schemes are available at: https://www.ripe.net/participate/meetings/gm/meetings/may-2019/supporting-d… In short, the options that members will choose between are: Option A: The RIPE NCC will maintain the existing charging scheme, according to which members pay an annual fee of EUR 1,400 plus an extra EUR 50 per independent number resource assignment. Option B: The RIPE NCC will switch to a new volume-based, per registration charging scheme. This would involve lowering the annual fee to EUR 1,150 whilst broadening the applicability of the separate EUR 50 charge to all number registrations held by the member. See the full list of registrations that would be charged in the document. The existing sign-up fee of EUR 2,000 will apply to both options. We encourage members to discuss the options on the Member Discuss mailing list at <members-discuss(a)ripe.net>. The Executive Board and the RIPE NCC Management will follow discussions closely ahead of the GM. If you have not yet registered for the GM, we strongly encourage you to do so and make sure you have your say on which of two distinct charging scheme options should be adopted in May. Full participation and voting options are available for all members. You can register now via the LIR Portal at: https://www.ripe.net/s/gm-registration-may-2019 All details on the GM, including the draft agenda, are available from: https://www.ripe.net/participate/meetings/gm/meetings/may-2019/ Kind regards, Gwen van Berne Chief Financial Officer RIPE NCC

2 1

Re: [members-discuss] [ncc-services-wg] Update of RIPE NCC Procedural Document
by Sergey Myasoedov 04 Apr '19

04 Apr '19

Dear Maria, Thank you for the announcement. I'm moving the discussion to members-discuss. > Other amendments were carried out to align the wording of specific sections with the wording used in the rest of the document, the RIPE NCC Standard Service Agreement (Sections A.1.2.2.g and B.1.d), and other RIPE NCC procedural documents (Section A.1.1). Similarly, changes were made to reflect changes in the RIPE Database (both operational and structural) and in RIPE Policy requirements (Sections A.1.2.1.1.c and B.1.c). I would not call this 'wording changes': $ diff ripe697 ripe716 7c7 < The Member repeatedly provides falsified data or information, or purposefully and/or repeatedly provides incorrect data or information (for example, falsified registration documents or IDs, incorrect/inaccurate contact details, etc.). --- > The Member provides falsified or misleading data or information (for example, falsified registration documents or IDs), or repeatedly provides incorrect data or information (for example, incorrect/inaccurate contact details). 11c11 < The Member submits repeatedly fraudulent requests for Internet number resources (for example, providing incorrect purpose/need or falsified information about the network, etc.). --- > The Member submits fraudulent requests for Internet number resources (for example, providing incorrect purpose/need or falsified information about the network, etc.). So the word 'repeatedly' disappear and in case of _any_ only document mistake, deliberately or not made by the member, the RIPE NCC can call this 'misleading data' or 'fraudulent request' and terminate the membership? Thank you. -- Kind regards, Sergey Myasoedov > On 1 Apr 2019, at 10:56, Maria Stafyla <mstafyla(a)ripe.net> wrote: > > Dear Colleagues, > > The RIPE NCC Procedural document 'Closure of Members, Deregistration of Internet Resources and Legacy Resources' has recently been reviewed and updated. The following is an overview of the amendments made. > > Section A.1.1 was amended to include situations where both the Member and the RIPE NCC agree to terminate the SSA before the usual three month period has passed. Other changes were made to avoid duplication of information. > > Section B.2 was updated to specify certain conditions under which a three month timeframe for deregistration of either Member or End User resources would be unreasonable. > > The wording in Section B.2.1 was amended to clarify that during the deregistration process the Member is not allowed to make new announcements using the resources to be deregistered, and that the RIPE NCC will update the maintainer on all the Member's resource objects - not just on the inetnum object. > > Section B.2.2 was amended to bring about alignment of the procedures for the deregistration of End User and Member resources and to clarify that if an End User does not have a sponsoring LIR when the deregistration procedure is initiated, they must first establish a contractual relationship with one before they can object to that procedure. > > Other amendments were carried out to align the wording of specific sections with the wording used in the rest of the document, the RIPE NCC Standard Service Agreement (Sections A.1.2.2.g and B.1.d), and other RIPE NCC procedural documents (Section A.1.1). Similarly, changes were made to reflect changes in the RIPE Database (both operational and structural) and in RIPE Policy requirements (Sections A.1.2.1.1.c and B.1.c). > > Please see here the relevant link: > https://www.ripe.net/publications/docs/ripe-716/ > > Kind regards, > > Maria Stafyla > Legal Counsel > RIPE NCC

8 9

RIPE NCC LIR Ticketsystem
by Sebastian Wiesinger 03 Apr '19

03 Apr '19

Hello, I'm currently communicating with the RIPE NCC and I'm learning that I really and passionately dislike the new ticket system. There is no way to see a coherent and complete history of my ticket. The LIR web portal has no way to see the ticket history, you can only upload documents to it. You cannot comment on the ticket (which would be useless anyway as you see no context). Also apparently sending documents as attachment by mail is not possible anymore. So I'm forced to use email to update the ticket while I'm unable to see any status or history for my ticket. On the other hand I'm forced to use the website to upload documents to the ticket and I can't even see which documents are already uploaded. Please, this is a really bad user experience. Is this going to be improved? Regards Sebastian

10 11