- db-wg - mailman.ripe.net

Call for Presentations / DRAFT Agenda RIPE81 - Database Working Group
by William Sylvester 14 Sep '20

14 Sep '20

Dear Working Group Members, Below is the proposed agenda for the Database Working Group for RIPE81. If you would like to present please submit your content as soon as possible to the chairs. If you have any questions, comments, or requested changes please let the chairs know. Best regards, William & Denis DB-WG Chairs A. Introduction - 5 min * Welcome * Scribe * Jabber * Agenda B. Operational Update RIPE Database – XX mins Edward Shryane, RIPE NCC C. Proposed Presentations HERE – YY mins D. NWI - Open Proposals – 5 mins Z. AOB (open discussion)

1 0

mntner with misleading primary key
by Tom Hill 08 Sep '20

08 Sep '20

Hello db-wg, A simple query to the RIPEDB ('whois -h whois.ripe.net -r AS2856') returns the aut-num AS2856 that you would expect, but it also returns a mntner with the same primary key: % Information related to 'as2856' mntner: as2856 admin-c: JA6431-RIPE auth: SSO # Filtered mnt-by: as2856 created: 2018-08-23T15:46:37Z last-modified: 2018-08-23T15:46:37Z source: RIPE # Filtered This has caused some concern, and while we (2856) have already determined how that mnter came to be in the database - and that there isn't any immediate risk - it isn't in any way affiliated with the AS2856 network, or any part of the parent company. One can imagine that given the quality of NOCs & their understanding of database objects the world over, that one of them might be convinced that the person associated with this mntner was indeed associated with the network AS2856, and they might also be convinced to announce prefixes that they otherwise should not. It is obvious that speaking to the owner of the mntner and politely asking them to switch to a new mntner would be pertinent, but as far as I'm aware they're under no obligation to do so. Yet, it feels that AS2856 (or any network in the RIPE region) remains potentially at some risk should a bad actor combine such a mntner, with some questionable verification of their credentials, and socially engineer their way toward a route hijack. Should it be possible to create mntners (or other objects) that infer a relationship and/or authority to a given aut-num (or organisation?) Might there be negative side-effects in restricting the primary key of mntners from impersonating other objects? I'm unable to construct a query to the RIPEDB that looks for mntner objects beginning with 'as', in order to gauge how common this is. I suspect that's because the phrase is too short, but if it is possible please do enlighten me! :) Regards, -- Tom

12 22

Re: [db-wg] RPSL requirements in aut-num objects
by Lutz Donnerhacke 28 Aug '20

28 Aug '20

> On Thu, Jul 02, 2020 at 05:58:19PM +0000, Lutz Donnerhacke via db-wg > wrote: > > I'd suggest to remove the crippled parser from the records in the > > first step. > > Even if someone tries to use the data-set, it's not even possible to > > bring in correct data. > > How do you expect an adoption under this condition? > > > > So, my primary question: Where is the source code and how to > > contribute? > > Secondary question: Can we first declare the fields as free from text > > fields, before removing them? > > What is the benefit of declaring such fields 'free form'? RFC 2622 requires to accept attributes which are not defined in the dictionary during paring. Of course, then the parser has no ability to validate the arguments or the allowed operators. It should issue a warning or ignore the attribute. Unfortunately the current parser in the RIPE DB has a different understanding of RPSL: it does not even allow attributes defined in the RFC (i.e. next-hop, protocols). So it's not possible to fill the aut-num with valid RPSL, or even adding new attributes. As long as the parser is broken, the field might be not validated (or issue a warning instead of an error). And the parser should be fixed. That's why I'm asking for the location of the source code.

1 0

RPSL parser nits
by Lutz Donnerhacke 18 Aug '20

18 Aug '20

Hello, I try to be a bit more expressive in the aut-num of ASN199284, but fail to get accepted at least the valid parts by the RPSL parser. Of course, there are invalid expressions in my terms for the sake of expressiveness, i.e. - next-hop is only valid for static routes - communities must not contain the PeerAS pattern But the other parts should be accepted, i.e. - protocol OSPF - rtr-sets in router expression part It would be a cool idea to keep the formatting, or better have smart pretty printing of the RSPLng structures. Currently only the "syncupdate" Interface is able to keep the line warps, which is pretty annoying. Where can I found the currently running code and do you accept patches in this regard? Many thanks in advance Lutz Donnerhacke

6 10

NWI-11 Internationalised Domain Names
by ripedenis＠yahoo.co.uk 06 Aug '20

06 Aug '20

Hi Ed The chairs see there is a consensus to move forward with implementing Punycode. Can you present an impact analysis explaining what changes you propose, what effect those changes will have on updates and queries (by all the different methods), if anyone needs to modify their software interacting with the database. cheersdenis co-chair DB-WG

4 9

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

Puny code or UTF-8 (or both)?
by ripedenis＠yahoo.co.uk 13 Jul '20

13 Jul '20

Colleagues After the recent discussion it seems their is support for the idea of UTF-8, whilst there is also support for Puny code as an interim step. To implement UTF-8 in the RIPE Database requires much more detailed discussions, including non technical aspects of the change. This is not likely to happen quickly. There has been support shown to introduce Puny code as a first step towards internationalisation of the data, which can be done quickly by the RIPE NCC. Do we therefore have support to introduce Puny code now and then consider how to move forward with UTF-8? cheersdenis co-chair DB-WG

8 7

Re: [db-wg] NWI-11 Internationalised Domain Names
by Elad Cohen 07 Jul '20

07 Jul '20

Hello, I would like to suggest an improvement: In the whois database backend, each textual attribute (last name, etc) can have an additional column and in that column the punycode-representation of the attribute value can be written. The punycode-representation can be added in the related column only if there was at least a single non-ascii character in the textual value that was inputted by the user, otherwise it will be empty. The punycode-representation can be in the format of [FIELD-NAME]--[punycode-ascii-characters] instead of xn--[punycode-ascii-characters], in order to avoid duplication with textual strings that starts with "xn--". There shouldn't be "punycode representation" columns in the database for email-related fields, nor for object-reference fields. Using the above, old protocols will still be able to interact with the database as they are now, no ground up development of the whole backend will be needed to support internationalization, the new "punycode-representation" columns encoding is similar to the encoding of the current columns, end-users will be able to use their internationalized names and other internationalized textual strings, RIPE NCC will be able to display internationalized strings online and through supported-services. Regards, Elad ________________________________ From: db-wg on behalf of Edward Shryane via db-wg Sent: Friday, June 26, 2020 5:55 PM To: db-wg Cc: ripedenis(a)yahoo.co.uk Subject: Re: [db-wg] NWI-11 Internationalised Domain Names Dear Working Group, I'd like to propose the following Solution Definition for NWI-11. Introduction Currently, the RIPE database supports email addresses encoded in the Latin-1 character set. However an email address can have an Internationalised Domain Name (IDN), with characters outside Latin-1 (i.e. Unicode). This causes interoperability problems as non-ASCII characters in an email address may not be accepted by a mail server, and only a small subset of Unicode characters can be encoded as Latin-1. Solution Definition In order to support Internationalised Domain Names (IDN) in an email address in the RIPE database, I propose to automatically encode email addresses in the Punycode format. Punycode (as defined in RFC 3492) is a way to encode strings containing Unicode characters, such as internationalised domain name (IDN) domains, into ASCII. When updating the RIPE database, it is already possible to submit a Punycode encoded value (i.e. with ASCII encoding) for an email address value, but this change automates the conversion of any non-ASCII encoded email address to Punycode. This change will only affect attributes with an email address syntax (i.e. abuse-mailbox, e-mail, irt-nfy, mnt-nfy, notify, ref-nfy, upd-to). Automatic Punycode encoding will only be applied to the domain part of the email address. The local part of the address must only contain ASCII characters. If non-ASCII characters are found in the local part, the address is rejected as invalid. When querying the RIPE database, any Punycode encoded email address is returned in Punycode (i.e it is not decoded). I welcome feedback from the community on this proposal. Regards Ed Shryane RIPE NCC On 22 Jun 2020, at 22:49, ripedenis--- via db-wg <db-wg(a)ripe.net<mailto:db-wg@ripe.net>> wrote: 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. cheers denis 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.

1 0

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 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

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