- members-discuss - mailman.ripe.net

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