- db-wg - mailman.ripe.net

Re: [db-wg] mntner with misleading primary key
by Matthias Merkel 01 Jul '20

01 Jul '20

Apologies, I was actually counting the objects twice (once the mntner attribute and once the mnt-by attribute). Here are the objects in question: AS327833 AS58224 AS42910 AS37527 AS8362 AS202723 as2856 AS12400 AS427313 AS397268 AS12655 AS30956 AS49717 Given the small number of objects, I don't think implementing a filter would have any significant impact (negative or positive) and may not be worth the effort. Matthias Merkel Vice President Staclar, Inc. [https://cdn2.hubspot.net/hubfs/53/tools/email-signature-generator/icons/pho…] +1-302-291-1141 | +49 15678 585608 [https://cdn2.hubspot.net/hubfs/53/tools/email-signature-generator/icons/ema…] matthias.merkel(a)staclar.com<mailto:matthias.merkel@staclar.com> [https://cdn2.hubspot.net/hubfs/53/tools/email-signature-generator/icons/lin…] staclar.com<https://staclar.com/> [https://cdn2.hubspot.net/hubfs/53/tools/email-signature-generator/icons/add…] Munich, Germany [https://staclar.com/images/logo.png] [linkedin]<https://www.linkedin.com/in/matthias-merkel/> ________________________________ From: db-wg on behalf of Gert Doering via db-wg Sent: Wednesday, July 1, 2020 8:52 PM To: Cynthia Revström Cc: DB-WG Subject: Re: [db-wg] mntner with misleading primary key Hi, On Wed, Jul 01, 2020 at 07:36:53PM +0200, Cynthia Revström via db-wg wrote: > I am not sure how feasible the mandatory "-mnt" would be at this point tbh. > I can easily think of at least 2 maintainers that are actually used that I > see quite often that wouldn't fit that pattern. It would annoy me a bit, because all our stuff is under SPACENET-N and SPACENET-P ("networks and person objects"). And all tools. Of course it is doable, but... why? Convince me :-) 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

2 1

Question regarding delta between "delegated-ripencc-extended-latest" and Whois output
by Peter Müller 29 Jun '20

29 Jun '20

Dear RIPE DB mailing list people, we, the IPFire development team, just bumped across an IP address somewhere in the 51.15.0.0/17 network (no abuse, we were just curious :-) ). While the RIPE Whois server returned "NL" as the country of that subnet [1], the "delegated-ripencc-extended-latest" file available at ftp.ripe.net [2] only contains 51.15.0.0/16, which points to "FR". Since the first one result contains the correct country code of that IP network, I would like to ask why "delegated-ripencc-extended-latest" does not include subnets like this, and where the Whois server fetches his answer from. Did we miss something? Is there another or a better way of fetching precise subnet data from RIPE? It would be great if someone could point us into the right direction. :-) Thanks, and best regards, Peter Müller [1] Relevant snippet of the Whois server output: > inetnum: 51.15.0.0 - 51.15.63.255 > [...] > country: NL > [...] [2] https://ftp.ripe.net/pub/stats/ripencc/delegated-ripencc-extended-latest, relevant snippet of this file: > ripencc|FR|ipv4|51.15.0.0|65536|19930901|assigned|925547da-35fb-4346-b464-aadff095c6ea

3 5

RDAP snapshots
by Lars Prehn 27 Jun '20

27 Jun '20

Hi everyone, Is there a "fast" way to obtain a snapshot of the RDAP databases from RIPE (http://rdap.db.ripe.net/) as well as the other RIRs for local use? I saw some presentations on proposals for RDAP mirroring, but couldn't find any working implementations. I want to run a massive amount of requests against it (for a research project) and would like to keep the load on the RIR APIs low. Unfortunately, our deadline is Monday night. Therefore "fast" really boils down to 'till tomorrow'. Thanks for answers in advance! Best regards, Lars

3 3

RDAP fails, WHOIS works
by Brian Rak 16 Jun '20

16 Jun '20

We have some automation in place that queries RDAP to retrieve contacts in order to validate BGP announcements. We've been running into issues with one contact in particular: https://rdap.db.ripe.net/entity/KR4422-RIPE However, WHOIS returns valid responses for this https://apps.db.ripe.net/db-web-ui/query?searchtext=KR4422-RIPE RIPE support suggested that this was a known issue but didn't really offer any suggestions as to when (if ever?) it's going to be fixed. Is this being tracked somewhere?

2 1

Re: [db-wg] RIPE DB Route Object fails creation
by Tom Hill 11 Jun '20

11 Jun '20

On 11/06/2020 14:17, Job Snijders wrote: >>> ***Error: Authorisation for [route] 194.76.156.0/22AS20676 failed >>> using "mnt-by:" >>> not authenticated by: PLUSNET-NOC >> Could we reduce the confusion, and/or spread some more clue, by being >> more specific with this error? e.g. >> >> Authorisation for [blah] failed using "mnt-by:" >> - matching route object already exists >> - not authenticated by: PLUSNET-NOC > Perhaps instead of an error message, the operation that Sasha tried to > do should just be allowed? Because of the following (stunningly regular) corner case: 1. PI space owner doesn't understand what the implications are of migrating prefixes between origins/networks, or dual-homing from two networks 2. New origin/network creates route without the knowledge of the existing origin/network provider (whom are often different providers) 3. Customer blames existing origin/network for breaking their traffic routing, whom had no idea anything was going on Having that route object check at the beginning of the flow chart ensures that all parties required to provide service, are aware of the changes to advertisements & can properly prepare their networks/customer networks, and prevent outages. If all our customers knew exactly what they were doing, they'd usually be running their own BGP AS and handling their own announcements, resilience, and/or migrations. Regards, -- Tom

2 1

RIPE DB Route Object fails creation
by Sascha E. Pollok 11 Jun '20

11 Jun '20

Dear friendly DB people, here is a problem I don't find easy to solve. Would you assist me in understanding the constraints? Customer has a /22 network 194.76.156.0/22 with the proper inetnum object. The inetnum objects has a mnt-by: IPHH-NOC and mnt-routes: IPHH-NOC. A route object exists but with a different maintainer: route: 194.76.156.0/22 descr: CMELCHERS-QSC-NET descr: via Plusnet origin: AS20676 mnt-by: PLUSNET-NOC <<<---- not IPHH-NOC We are now trying to create an additional route object for a different ASN: route: 194.76.156.0/22 descr: C. Melchers via MEKO-S origin: AS207630 mnt-by: IPHH-NOC <<<--- This is the maintainer in the inetnum object source: RIPE The RIPE DB refuses the update: Create FAILED: [route] 194.76.156.0/24AS207630 route: 194.76.156.0/24 descr: C. Melchers via MEKO-S descr: belongs to 194.76.156.0/22 origin: AS207630 mnt-by: IPHH-NOC source: RIPE ***Error: Authorisation for [route] 194.76.156.0/22AS20676 failed using "mnt-by:" not authenticated by: PLUSNET-NOC So the DB expects the maintainer from the other route object. But I don't understand why the mnt-routes in the inetnum-object doesnt give preference over the maintainer on a different route-object. Anyone who could share their honest opinion? Cheers Sascha

9 10

DBTF BoF Minutes
by Boris Duval 08 Jun '20

08 Jun '20

Dear all, The minutes and recording of the RIPE Database Requirements Task Force (DBTF) BoF are now available at: https://www.ripe.net/participate/ripe/bof/dbtf-bof <https://www.ripe.net/participate/ripe/bof/dbtf-bof> Thank you to all attendees for the active participation and input. Best, Boris Duval Communications Officer RIPE NCC

1 0

New on RIPE Labs: Lessons Learned from RIPE when Creating a New Community Database - in a Very Different Field
by Mirjam Kuehne 03 Jun '20

03 Jun '20

Dear colleagues, A new repository of social audits is more similar to the RIPE Database than you might think. Adam Castle and his colleagues at SLCP documented some lessons learned and what processes they've reused from the RIPE Database. Please read this interesting article on RIPE Labs: https://labs.ripe.net/Members/ad_castle/lessons-learned-from-ripe-when-crea… Kind regards, Mirjam Kühne RIPE NCC

1 0

Re: [db-wg] Fw: Not yet NWIs: Support for IDNs
by Leo Vegoda 01 Jun '20

01 Jun '20

Hi Job, On Fri, May 29, 2020 at 10:56 PM Job Snijders <job(a)ntt.net> wrote: > > Dear Leo, group, > > On Mon, May 25, 2020 at 01:21:02PM -0700, Leo Vegoda via db-wg wrote: > > On Mon, May 25, 2020 at 1:09 PM Piotr Strzyzewski > > <Piotr.Strzyzewski(a)polsl.pl> wrote: > > > > [...] > > > > > > The RIPE NCC service region includes countries whose language is not > > > > written using Latin script. Languages using other scripts include (in > > > > English alphabetical order) Arabic, Georgian, Greek, Hebrew, and > > > > Russian. Many of the languages used in the RIPE NCC service region are > > > > > > The list is lacking a lot of languages that are written in Cyrillic and > > > its variations (like Bulgarian or Serbian Cyrillic). This should be > > > noted. > > > > Absolutely. I wasn't trying to be comprehensive. I do not think a > > complete list is required to make either the practical or moral case. > > I'd like to add that ascii vs unicode vs utf-8 seems to be a complicated > story. > > Big question: What do we expect to happen here? now? My personal view is that I'd like the WG Chairs to evaluate whether there is community support for this change in principal. If they believe that there is support, I'd like the RIPE NCC to let the WG know what would be needed to update the RIPE Database and any other RIPE NCC systems that need changes. I'd also like an evaluation of the likely changes needed by other systems that interact with the RIPE Database, like IPAMs. Kind regards, Leo Vegoda

1 0

Cleanup Locked Person Objects in the RIPE Database (Implementation on 3rd June)
by Edward Shryane 29 May '20

29 May '20

Dear colleagues, As previously announced, the RIPE Database Team plan to clean up locked person objects in the RIPE Database. We will select person objects maintained by RIPE-NCC-LOCKED-MNT, which are referenced by inetnum allocations or assignments, and re-assign them to the resource maintainer, so they can be properly maintained, and it is clear who is responsible for them. We now plan to perform this cleanup on Wednesday, 3 June 2020. We have already notified the affected LIRs and resource maintainers by email. You do not need to take any action. For more information on the Locked Person Objects Cleanup, please refer to this RIPE Labs article : https://labs.ripe.net/Members/ed_shryane/cleaning-up-locked-person-objects-… Regards, RIPE NCC Database Team

1 0