- db-wg - mailman.ripe.net

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 25 May '20

25 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