- db-wg - mailman.ripe.net

Regarding non-ASCII org-name
by Cynthia Revström 07 Jul '20

07 Jul '20

Hiya DB-WG, As you may be aware, the org-name attribute in the organisation object doesn't support non-ASCII characters such as "ö" (umlaut). This presents an issue as for certain entities where that is part of the legal name and thus not being able to represent the legally registered name. I would like to ask the working group if this is something we consider a real problem or just a thing that will stay like this. I have 2 proposed solutions, either use Latin-1 for the org-name which would fix my issue but not all issues, however may be the only possible solution currently as the database uses Latin-1, alternative just use UTF-8. My personal example is my name being represented as "Revstrom" instead of "Revström" in the database, this makes it so you might not be able to search for the name registered in the database in government registers etc. - Cynthia

1 0

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

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

01 Jul '20

Hi, if we consider this issue tho we should consider completely disallowing objects with names of existing objects. I'm personally not a big fan of mandatory -MNT because there seems to be a larger amount of people using other formats. 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

1 0

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

01 Jul '20

An alternative approach might be to make an authentication check (user has to have access to a maintainer of the ASN), however given the small amount of maintainers actually being named this way this would likely not be justifiable. 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

1 0

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

Fw: Not yet NWIs: Support for IDNs
by ripedenis＠yahoo.co.uk 25 May '20

25 May '20

Please do Leo :) cheersdenis co-chair DB-WG On Friday, 22 May 2020, 18:02:07 CEST, Leo Vegoda via db-wg <db-wg(a)ripe.net> wrote: Hi Nick, On Fri, May 22, 2020 at 8:51 AM Nick Hilliard <nick(a)foobar.org> wrote: > > Leo Vegoda via db-wg wrote on 21/05/2020 23:35: > > At RIPE 80, Denis asked for feedback on some items that are not yet > > NWIs, including internationalized domain names. > > > > My feedback is that the RIPE Database should support internationalized > > e-mail addresses. The RIPE region includes a number of countries that > > use a non-Latin script. Most of these countries have an IDN version of > > their ccTLD and there are also a number of IDN gTLDs serving these > > language communities. > > this looks like an offer to write a brief NWI, no? :-) I am happy to draft some text for the problem statement and circulate it on the list. Kind regards, Leo Vegoda

3 3

Not yet NWIs: Support for IDNs
by Leo Vegoda 24 May '20

24 May '20

Hi, At RIPE 80, Denis asked for feedback on some items that are not yet NWIs, including internationalized domain names. My feedback is that the RIPE Database should support internationalized e-mail addresses. The RIPE region includes a number of countries that use a non-Latin script. Most of these countries have an IDN version of their ccTLD and there are also a number of IDN gTLDs serving these language communities. People who register in those domains will want to use them for e-mail. If an organization using an IDN is required to set up a secondary e-mail address to register information in the RIPE Database there is a greater risk that the published contact information will go stale as it is not the organization's primary domain. That would undermine the utility of the RIPE Database. Kind regards, Leo Vegoda

3 3

Fw: Regarding NWI-8 phase 2 - user defined auth groups
by ripedenis＠yahoo.co.uk 14 May '20

14 May '20

Hi Tore Sorry if you misunderstood what I meant. I didn't say that 'you' proposed this. I said only 'the proposer' of having user defined groups wanted it. I couldn't remember who it was who suggested it. It may have even been myself who first suggested that this 'could' be extended to user groups and then picked up by someone else :) cheersdenis co-chair DB-WG On Thursday, 14 May 2020, 16:24:47 CEST, Tore Anderson via db-wg <db-wg(a)ripe.net> wrote: The following was stated in the db-wg session just now (https://ripe80.ripe.net/archives/video/377/ @ 1:03): «Phase 2 was user defined authentication groups. Nobody objected to this, but really only the proposer actually said it was a good idea.» This is categorically false. I did not propose this, nor did I think it was a particularly useful feature (at least not to myself). For the record, the thread where I proposed this feature starts here: https://www.ripe.net/participate/mail/forum/db-wg/PGExMTJhNDAyLWUxYTAtZDhlN… I believe it was Nick Hilliard who initially came up with the group idea: https://www.ripe.net/participate/mail/forum/db-wg/PGExMTJhNDAyLWUxYTAtZDhlN… While I did not have any objections per se to this feature being implemented as well, I did voice a concern that it would constitute feature creep that would potentially complicate the implementation of the core of my proposal (which in the end was implemented as phase 1, fortunately): https://www.ripe.net/participate/mail/forum/db-wg/PGExMTJhNDAyLWUxYTAtZDhlN… So let me for the record categorically state that I do not care about the user defined authentication groups phase of NWI-8. I am perfectly happy with the already implemented phase 1, as that covers everything I ever wanted from the «magic maintainer» proposal of mine that eventually became NWI-8. Tore

1 0

Regarding NWI-8 phase 2 - user defined auth groups
by Tore Anderson 14 May '20

14 May '20

The following was stated in the db-wg session just now (https://ripe80.ripe.net/archives/video/377/ @ 1:03): «Phase 2 was user defined authentication groups. Nobody objected to this, but really only the proposer actually said it was a good idea.» This is categorically false. I did not propose this, nor did I think it was a particularly useful feature (at least not to myself). For the record, the thread where I proposed this feature starts here: https://www.ripe.net/participate/mail/forum/db-wg/PGExMTJhNDAyLWUxYTAtZDhlN… I believe it was Nick Hilliard who initially came up with the group idea: https://www.ripe.net/participate/mail/forum/db-wg/PGExMTJhNDAyLWUxYTAtZDhlN… While I did not have any objections per se to this feature being implemented as well, I did voice a concern that it would constitute feature creep that would potentially complicate the implementation of the core of my proposal (which in the end was implemented as phase 1, fortunately): https://www.ripe.net/participate/mail/forum/db-wg/PGExMTJhNDAyLWUxYTAtZDhlN… So let me for the record categorically state that I do not care about the user defined authentication groups phase of NWI-8. I am perfectly happy with the already implemented phase 1, as that covers everything I ever wanted from the «magic maintainer» proposal of mine that eventually became NWI-8. Tore

1 0

Agenda RIPE80 - Database Working Group
by William Sylvester 10 May '20

10 May '20

All, Db-wg members, Here’s the database working group agenda for our meeting this week. Best regards, DB-WG Chairs A. Introduction - 1 min * Welcome * Scribe * Jabber * Agenda B. Operational Update RIPE Database – 10 mins Edward Shryane, RIPE NCC C. Cloud Migration – 15 mins Edward Shryane, RIPE NCC D. NWI - Open Proposals – 20 mins Z. AOB (open discussion)

1 0

Whois Release 1.97.1
by Edward Shryane 06 May '20

06 May '20

Dear Working Group, RIPE Database release 1.97.1 has been deployed to the Release Candidate environment. We plan to deploy to production on Wednesday 6th May. This is a bugfix release, with no new functionality. 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

RIPE Database Requirements Task Force BoF
by Bijal Sanghani 06 May '20

06 May '20

Dear colleagues, The RIPE Database Requirements Task Force (DBTF) will organise its BoF on Wednesday, 6 May from 14h00-15h00 CEST via Zoom. During this BoF, the DBTF will present its latest work and invite participants to discuss what functionality the RIPE Database should provide in the future. The presentation will include quick polls and will be followed by a moderated Q&A. You can register for the BoF at (no Zoom account required): https://ripe.zoom.us/meeting/register/tJMkd-yhrz4uHNDuOIBm8hGvcj8DSDK1Ybog <https://ripe.zoom.us/meeting/register/tJMkd-yhrz4uHNDuOIBm8hGvcj8DSDK1Ybog> We look forward to discussing the future of the RIPE Database with you! Kind regards, Bijal Sanghani on behalf of the DBTF

2 1

New on RIPE Labs: Cleaning Up Locked Person Objects in the RIPE Database
by Mirjam Kuehne 30 Apr '20

30 Apr '20

Dear colleagues, Unmaintained person objects in the RIPE Database were locked by the RIPE NCC so they could not be used to hijack resources. Now we plan to set the correct user maintainer on those person objects. Please find more details in this RIPE Labs article: https://labs.ripe.net/Members/ed_shryane/cleaning-up-locked-person-objects-… Kind regards, Mirjam Kühne RIPE NCC

1 0

RIPE NCC Executive Board election
by Ronald F. Guilmette 17 Apr '20

17 Apr '20

Greetings all, I know that all is not right with the world right now, and that most of you, like me, have much more pressing things on your minds right now, but someone just sent me the following link and I cannot exactly ignore it: https://www.ripe.net/participate/meetings/gm/meetings/may-2020/confirmed-ca… I would like to call everyone's attention to the last of the three candidates who have, it seems, "qualified" as candidates for open seats of the RIPE NCC Executive Board. As I have already said, I know that things are bad in the world right now, but I must ask this question: Is there really no one other than these three candidates who is willing and/or able to stand for the three open seats on the RIPE NCC Executive board... three open seats that will be voted on at the next general meeting, 13-15 May 2020 ? If not, then it seems that RIPE NCC will soon be following in the new tradition, established first by AFRINIC only last year, of placing well and widely known crooks on it board. I desperately hope it won't come to that, but that is not for me to decide. The decision is in your hands dear friends. Regards, rfg

4 5

poetic-form mnt-by/creation
by Cynthia Revström 14 Apr '20

14 Apr '20

Hello DB-WG, I would just like to make the working group aware of the fact that currently anyone can create a new poetic-form and it doesn't require the LIM-MNT to be used. I am not sure if this is intended or not, but I thought it was worth posting about if anyone has input on it. Considering the poem objects require the LIM-MNT as mnt-by I don't think this was really the intended situation. - Cynthia

2 1

Whois Release 1.97
by Edward Shryane 01 Apr '20

01 Apr '20

Dear Working Group, RIPE Database release 1.97 has been deployed to the Release Candidate environment. We plan to deploy to production on Wednesday 1st April. The major change in this release is to open the NRTM service (regardless of membership status). 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

4 4