June 2020 - db-wg - mailman.ripe.net

NWI-11 Internationalised Domain Names
by ripedenis＠yahoo.co.uk 14 Jul '20

14 Jul '20

Colleagues There has been some discussion recently and many times over the years about addressing this issue. The chairs believe there has been enough support shown to move forward with this. We would therefore like to present this as 'NWI-11 Internationalised Domain Names'. We propose a problem statement based on the text provided recently by Leo Vegoda, as shown below. The RIPE NCC has a proposal for a solution to this problem using punycode. We would like to ask the RIPE NCC to present this proposal to the working group. If anyone has any other proposals for a solution, we welcome a discussion on this matter. cheersdenis co-chair DB-WG Problem Statement The RIPE NCC service region includes countries whose language is not written using Latin script. Many of the languages used in the RIPE NCC service region are written in Latin script but use diacritical marks that fall outside the US-ASCII character set. Internationalized Domain Names (IDNs) support the use of these scripts in DNS. ICANN began delegating IDN Top-Level Domains as part of a test program in 2007 and the IETF updated the IDNA protocol in 2008 and as of mid 2020, there were over 160 IDN TLDs in the root zone. The IETF published eight standards track RFCs on using IDNs in e-mail in 2012 and 2013. It is reasonable that organizations communicating with people whose preferred script is not Latin-based would want to use an IDN domain for e-mail as well as a web presence. It is also likely that the registry for an IDN TLD would want to use that TLD for its e-mail addresses. RFC 3912 explicitly notes that the WHOIS protocol has not been internationalized while recognizing that some servers attempt to do so. RDAP has been deployed by the RIPE NCC and explicitly supports internationalization by UTF-8 encoding all queries and responses. The RIPE community could decide to ignore EAI by trying to require organizations to deploy a secondary e-mail address for use in the RIPE Database. This would reduce the effectiveness of the RIPE Database as the secondary address is less likely to be monitored and used, and so be ineffective.

7 19

Whois Release 1.97.2
by Edward Shryane 06 Jul '20

06 Jul '20

Dear Working Group, RIPE Database release 1.97.2 has been deployed to the Release Candidate environment. We plan to deploy to production on Monday 6th July. This release includes the following changes: • Improved inetnum status validation to align with RIPE policy • ASSIGNED PA status will no longer be allowed under ALLOCATED UNSPECIFIED. • ASSIGNED PI status will no longer be allowed under ASSIGNED PI. • Removed obsolete inetnum status values • EARLY-REGISTRATION • NOT-SET • ALLOCATED PI • LIR-PARTITIONED PI In addition to small improvements and bug fixes. The release notes are on the website: https://www.ripe.net/manage-ips-and-asns/db/release-notes/ripe-database-rel… More information on the Release Candidate environment can be found on our website: https://www.ripe.net/manage-ips-and-asns/db/release-notes/rc-release-candid… Please let us know if you find any issues with this release in the RC environment. Regards Ed Shryane RIPE NCC

1 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 28 Jun '20

28 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