- db-wg - mailman.ripe.net

Protecting References to Objects in the RIPE Database
by Edward Shryane 29 Mar '22

29 Mar '22

Dear Colleagues, Currently the "mnt-ref:" attribute only protects references to organisation objects in the RIPE database, by specifying which maintainer(s) can authorise the reference. This means it is possible to make references to other object types without any authorisation, for example: * Refer to another organisation's maintainer * Refer to another organisation's abuse-c contact * Refer to any technical contact, admin contact, zone contact Since these references do not need authorisation, it is open to misuse, creating the impression that an unrelated party is responsible for that object. I propose that the "mnt-ref:" attribute be added (as an optional attribute) to other object types to allow references to be authorised: * person * role * mntner * irt This proposal does not eliminate misuse (e.g. contact information can still be copied into a separate object), but protects references to existing objects. If the DB-WG agrees to this proposal, I will prepare a more detailed impact analysis for review. Regards Ed Shryane RIPE NCC

2 2

RIPE NCC Open House: Feedback on our Unified User Interface
by Michela Galante 28 Mar '22

28 Mar '22

Dear colleagues, On Wednesday 6 April from 10:00 to 11:30 UTC, we invite users of RIPE Atlas, RIPE Database, RIPE Labs, RIPE NCC Academy, LIR Portal, RPKI and RIPEstat to give us feedback on our unified user interface. This Open House session will focus on the user interface that was launched in 2020. Our goal is to unify the user experience across all platforms to make it easier and faster for users to navigate our services. You can register for the event at: https://meeting-registration.ripe.net/meeting-pub/registration?0&meetingId=… More information is available on our website: https://www.ripe.net/participate/meetings/open-house/ripe-ncc-open-house-fe… Best regards, Michela Galante RIPE NCC

1 0

Last call and final reminder for nominations to the 2022 Rob Blokzijl Award
by Carsten Schiefner 14 Mar '22

14 Mar '22

[Apologies for cross-posting to various RIPE lists] Dear DB WG members - this is the last call and final reminder for nominations to the 2022 Rob Blokzijl Award that will be accepted until this Friday, 18th March, at 23:59 UTC. In seeking nominations for this prestigious award, which was created to celebrate Rob's contributions to the development of the Internet, the Award Committee (https://rob-blokzijl-foundation.org/2021/11/22/2022-award-committee/) is interested to receive nominations of those who have reflected Rob's approach in either a technical or operational capacity. Please give some consideration to nominating individuals - but also teams and groups of people! - in your own community and/or the wider industry in the RIPE region who, in your opinion, deserve to be recognised for their work to make the internet and/or internet community better. To specifically have this emphasised again after some according queries: nominations of teams and groups of people are very well possible and wished for as well in case their collective work would match the criteria of the call as laid out! The Award Committee is particularly interested to receive nominations of contributors who, in addition to their own contributions, have also supported and enabled others anywhere in the world. Also, the Award Committee would like to encourage those making nominations to consider not only the community members in the later stages of their careers or who are widely known but also those who may have contributed greatly in the springtime of their career or discreetly for the greater good or who may be considered to be part of an unrepresented group. And last but not least: those of you who previously have made a nomination other than Wilfried Woeber, the 2018 awardee, may want to consider resubmitting a nomination. The complete details of the call and the nomination process can be found at: https://rob-blokzijl-foundation.org/2021/11/25/call-for-nominations-2022/ Best wishes and kind regards Carsten (on behalf of the Award Committee)

1 0

Removing Apache Proxy Servers from DB Services
by Edward Shryane 02 Mar '22

02 Mar '22

Dear Colleagues, Next Tuesday, 1st March, the DB team plan to remove the Apache httpd proxy servers for the following services: * https://apps.db.ripe.net/ * https://rdap.db.ripe.net/ * https://rest.db.ripe.net/ * https://syncupdates.db.ripe.net/ This will allow us to simplify our production environment, reducing operational work and maintenance. Be aware that URL validation will be stricter after this change. For example, the following will return a 400 Bad Request: * Empty path segments (i.e. '//') * Encoded path separators (i.e. %2F for '/') * Encoded query separator (i.e. %3F for '?') Please test your client using the TEST environment: https://www.ripe.net/manage-ips-and-asns/db/ripe-test-database or the Release Candidate environment: https://www.ripe.net/manage-ips-and-asns/db/release-notes/rc-release-candid… Regards Ed Shryane RIPE NCC

1 1

Clear up of old issues - Whiepages
by denis walker 01 Mar '22

01 Mar '22

Colleagues The co-chairs recently had a zoom meeting with the RIPE NCC. One of the things we discussed was clearing up a number of old issues. We need to clear the deck and move on with new and perhaps more relevant issues. We will address a number of issues for the last time. In some cases the chairs will make a recommendation. As these are quite old issues, we will take silence as consensus for the chair's recommendation. The first issue is Whitepages. This is a feature from about 10+ years ago. It was intended to preserve the PERSON object in the RIPE Database and protect it from automatic deletion if it is not referenced from any operational data. It was to use the RIPE Database as a phone book for well known people in the industry who may not be resource holders. There are many other ways to provide such contact details today. It was only ever used by a handful of people. The RIPE NCC now has other ways to preserve ROLE objects if needed, for example if used by RIPE Atlas users. The chairs recommend removing this feature from the RIPE Database. If you need a ROLE object to be preserved, contact ripe-dbm(a)ripe.net to discuss. cheers denis co-chair DB-WG

4 8

geofeed issue: can't add geofeed attribute to PI /48
by Job Snijders 28 Feb '22

28 Feb '22

Dear all, Like all good netizens, I tried to align information I publish in the RIPE database to reality, but there is an obstacle: https://sobornost.net/~job/geofeed.png """Adding or modifying the "geofeed:" attribute of an object with a prefix length greater or equal to 48 is not allowed.""" No such restriction exists if you use the 'remarks: Geofeed' approach, as demonstrated here: $ whois -h whois.ripe.net 2001:67c:208c::/48 | grep Geofeed remarks: Geofeed https://sobornost.net/geofeed.csv I appreciate concerns about privacy, but I'm not wholly convinced restricting /48s from having a proper 'geofeed:' attribute is the best path forward. How does the working group feel about this restriction? Is it useful? Should it be lifted? If the latter, what would be the process? Kind regards, Job

14 52

Clear up of old issues - NWI-4 role of status: field
by denis walker 28 Feb '22

28 Feb '22

Colleagues The co-chairs recently had a zoom meeting with the RIPE NCC. One of the things we discussed was clearing up a number of old issues. We need to clear the deck and move on with new and perhaps more relevant issues. We will address a number of issues for the last time. In some cases the chairs will make a recommendation. As these are quite old issues, we will take silence as consensus for the chair's recommendation. NWI-4 https://www.ripe.net/ripe/mail/archives/db-wg/2016-May/005242.html This item has been 'open' for 6 years, and it was talked about before then. So we do need to come to a decision on how to move forward or drop it and just accept the constraints. To describe it in simple terms, it is about documenting an assignment the same size as an allocation. One idea that was put forward was to allow a twin attribute primary key for the INETNUM object: range/status similar to the primary key of a ROUTE object: prefix/origin. The RIPE NCC's impact analysis ruled out this option. This change would cut so deep into the software, changing core functionality of the data model with a ripple effect right across the system. The only other option currently on the table is one I put forward to allow the "status:" attribute to be 'multiple'. Business rules would then limit the use of this feature to only one use case. If the status is 'ALLOCATED PA' a second "status:" attribute would be allowed with the value 'ASSIGNED PA'. I don't think any other use case would require it. Where 2 status attributes exist, only the one with 'ASSIGNED PA' could be removed. This would be a relatively straightforward change to the software. Whilst "descr:", "country:", "admin-c:" and "tech-c:" are already multiple attributes, "org:" and "abuse-c:" are only single. They could also be made multiple in this one use case but that may have further consequences. It depends how far you want to go in fully defining an assignment or just documenting the fact that this allocation is also an assignment. Any change to allow a range to be dually represented as both an allocation and an assignment may break scripts people use to parse the objects returned by a database query. That is unavoidable. But it may affect some users' views on whether or not this is a sufficiently important problem that needs to be solved. Perhaps now there are so many /24 allocations, it raises the importance of being able to document an allocation as an assignment. There is of course an even simpler (pseudo) option, following on from the geofeed discussion, to define a convention to add: "remarks: status: ASSIGNED PA" Which throws us straight back into the debate on parsing "remarks:" attributes. The database software should not do so. But users querying this data can do whatever they wish. As Randy says, its interpretation is in the eye of the beholder. The chairs make no recommendation on this item. But if there is no discussion we will simply mark NWI-4 as cancelled. cheers denis co-chair DB-WG

1 1

Re: [db-wg] geofeed issue: can't add geofeed attribute to PI /48
by Jeroen Massar 14 Feb '22

14 Feb '22

> Hi Job, Colleagues, > > On 3 Jan 2022, at 13:36, Job Snijders via db-wg <db-wg at ripe.net> wrote: > > > > ... > > I appreciate concerns about privacy, but I'm not wholly convinced > > restricting /48s from having a proper 'geofeed:' attribute is the best > > path forward. > > > > How does the working group feel about this restriction? Is it useful? > > Should it be lifted? If the latter, what would be the process? > > > I will ask our Legal team to re-examine the prefix size restriction and keep you and the DB-WG informed. > Regards Ed Shryane RIPE NCC Hi Ed, Did something come out of this? It is a very silly restriction, especially for PI /48's but also for the simple fact that one can register very small prefixes (I've done IPv4 /28 and IPv6 /56) in the actual geofeeds file. Greets, Jeroen

2 1

update on draft-spaghetti-grow-nrtm-v4-00
by Sasha Romijn 04 Feb '22

04 Feb '22

Hello all, FYI, following up on various discussions and the BoF we had on this list about NRTMv4 and NWI-12, a draft has now been submitted. If you’re interested in discussing further details of the proposed protocol, do send your questions and comments to that mailing list. Sasha Forwarded message: > From: Sasha Romijn > To: grow(a)ietf.org > Subject: [GROW] draft-spaghetti-grow-nrtm-v4-00 > Date: Fri, 04 Feb 2022 13:04:48 +0100 > > Hello, > > We’ve submitted a draft for the Near Real Time Mirroring Protocol (NRTM) version 4: https://datatracker.ietf.org/doc/draft-spaghetti-grow-nrtm-v4/ > > This document specifies a one-way synchronization protocol for Internet Routing Registry (IRR) records. The protocol allows instances of IRR database servers to mirror IRR records, specified in in the Routing Policy Specification Language (RPSL), between each other. > > NRTMv4 is intended as a replacement of current synchronization methods mainly based on FTP downloads and NRTM version 3, which have many problems that are addressed in NRTMv4. > > The need for this originated from experiences by users of IRRD v4, and discussions in the RIPE Database working group, tracked under NWI-12: > https://www.ripe.net/ripe/mail/archives/db-wg/2020-November/006720.html > > The broad strokes of this draft were previously discussed in a BoF in the RIPE Database wg, which included several operators of IRR databases, and responses were overall positive. I am also the maintainer of IRRD v4, one of the most widely used IRR database servers, and will implement it in there. > > I’m proposing this draft for adoption by this working group. I would also be happy to present it in the IETF 113 session. > > Sasha Romijn > > _______________________________________________ > GROW mailing list > GROW(a)ietf.org > https://www.ietf.org/mailman/listinfo/grow

2 1

RDAP Conformance Level "cidr0"
by Benjamin Pereto 26 Jan '22

26 Jan '22

Dear RIPE DB wg, The RDAP for querying ip and network information on rdap.db.ripe.net is really useful. Currently you support the rdapConformance level "rdap_level_0" and this is missing the CIDR or Prefix Information about the Length/Mask. Other RIR have implemented a rdap conformance level "cidr0" for this: * https://rdap.arin.net/registry/ip/9.9.9.9 * https://rdap.apnic.net/ip/1.1.1.1 with the desired information: "cidr0_cidrs": [ { "v4prefix": "1.1.1.0", "length": 24 } ] Information about the Origin ASN is also available by arin with "arin_originas0", which is also very helpful, but the format seems to be arin specific and not standardized. May I suggest to also implement the cidr0 level, or even additionally the "origin as" for the RIPE DB RDAP? Kind regards, Benjamin

2 1