- db-wg - mailman.ripe.net

New on RIPE Labs: RPKI Repositories and the RIPE Database in the Cloud
by Alun Davies 10 May '21

10 May '21

Dear colleagues, The mission critical services the RIPE NCC provides to the Internet community require a solid technical foundation. In this new article on RIPE Labs, Felipe Silveira looks at plans to use cloud infrastructure as a means to that end. The full article is available here: https://labs.ripe.net/author/felipe_victolla_silveira/rpki-repositories-and… Kind regards, Alun Davies RIPE Labs Editor RIPE NCC

1 0

Re: [db-wg] Cleanup of route(6) objects in the RIPE NONAUTH database using unregistered space
by denis walker 07 May '21

07 May '21

Hi Arash For most issues we would not come to such a quick conclusion. But deleting ROUTE objects for unallocated address space seems to be a very non-contentious issue. Over this last year it has been difficult to get comments, feedback or any discussion on many issues. So I think two weeks (just before a RIPE Meeting) is a reasonable time frame for objections for this, and none were received. cheers denis co-chair DB-WG On Fri, 7 May 2021 at 12:59, Arash Naderpour <arash.naderpour(a)gmail.com> wrote: > > I have no objection but it looks a bit weird to me to come to this quick conclusion. > > Regards, > > Arash > > On Fri, 7 May 2021, 22:56 denis walker via db-wg, <db-wg(a)ripe.net> wrote: >> >> HI Ed >> >> As no one has objected I think we can assume you can go ahead with this plan. >> >> cheers >> denis >> co-chair DB-WG >> >> On Fri, 7 May 2021 at 09:20, Edward Shryane <eshryane(a)ripe.net> wrote: >> > >> > Hi Cynthia, Denis, >> > >> > Thanks for your feedback. I will plan to implement a cleanup job without an NWI, and will keep the DB-WG informed. >> > >> > Regards >> > Ed Shryane >> > RIPE NCC >> > >> > On 25 Apr 2021, at 13:03, Cynthia Revström <me(a)cynthia.re> wrote: >> > >> > imo an NWI seems unnecessary unless we want it for purposes of referencing back to in the future. >> > >> > -Cynthia >> > >> > On Wed, Apr 21, 2021, 04:02 denis walker via db-wg <db-wg(a)ripe.net> wrote: >> >> >> >> Colleagues >> >> >> >> How do you want to proceed with this suggestion? Do we have support >> >> for deleting these ROUTE(6) objects for deregistered space and where >> >> the objects were created before registration? Does anyone have any >> >> objections to this as an ongoing cleanup? >> >> >> >> Do we even need an NWI or can we just ask the NCC to go ahead with it? >> >> >> >> cheers >> >> denis >> >> co-chair DB-WG >> >> >> >> On Thu, 11 Mar 2021 at 15:07, Edward Shryane via db-wg <db-wg(a)ripe.net> wrote: >> >> > >> >> > Dear colleagues, >> >> > >> >> > In response to the recent discussion on "196.52.0.0/14 revoked, cleanup efforts needed", I'd like to propose a regular automated cleanup of route(6) objects in the RIPE-NONAUTH database using unregistered space. >> >> > >> >> > Regards >> >> > Ed Shryane >> >> > RIPE NCC >> >> > >> >> > >> >> > >> >> > Problem Definition >> >> > ------------------ >> >> > When an RIR deregisters IPv4/IPv6 address space, any route(6) objects in the RIPE-NONAUTH database using that address space are not cleaned up (deleted). >> >> > >> >> > >> >> > Solution Definition >> >> > ------------------- >> >> > Once a day, compare route(6) IPv4/IPv6 prefixes in the RIPE-NONAUTH database against the combined delegated stats from all RIRs. >> >> > >> >> > Only route(6) prefixes that are "allocated" or "assigned" in any RIRs delegated stats should remain in the RIPE NONAUTH database. If a prefix is "available" or "reserved" then it is considered to be unregistered, and any associated route(6) objects will be eligible for deletion. >> >> > >> >> > If a prefix is partially "available" or "reserved" then it is also considered to be unregistered. >> >> > >> >> > If a prefix is not listed in any RIRs delegated stats, that prefix is skipped. >> >> > >> >> > The origin AS status is not considered, only the IPv4/IPv6 prefix. >> >> > >> >> > If a newly unregistered prefix is discovered, first allow a grace period of 1 week. This allows time for mistakes in the delegated stats to be corrected. >> >> > >> >> > After 1 week, contact the route(6) maintainer(s) to notify them that the route(6) object will be deleted. >> >> > >> >> > After a further 2 weeks, delete the route(6) object. >> >> > >> >> > A maintainer can request the RIPE NCC to exclude a route(6) prefix from deletion (for example, the deregistration of the prefix is being disputed). For any excluded prefixes, any associated route(6) objects will not be deleted. >> >> > >> >> > >> >> > Impact Analysis >> >> > ------------------ >> >> > There are approximately 738 routes (out of 56,230) in the RIPE-NONAUTH database using a prefix with status "available" or "reserved" in an RIRs delegated stats, which will be eligible for deletion. >> >> > >> >> > There are approximately 94 route6's (out of 1,564) in the RIPE-NONAUTH database using a prefix with status "available" or "reserved", so also eligible for deletion. >> >> > >> >> > There are approximately 64 routes and 37 route6's with a prefix not listed in any RIR's delegated stats. These will not be affected. >> >> > >> >> > When this cleanup is implemented, the backlog of route(6) objects eligible for deletion will be processed at the same time, leading to a large amount of emails to affected maintainers. Once this backlog is processed, the number of route(6) objects affected is expected to be low. >> >> > >> >> > >> >> > >> >> >> > >>

1 0

Re: [db-wg] Cleanup of route(6) objects in the RIPE NONAUTH database using unregistered space
by Edward Shryane 07 May '21

07 May '21

Hi Cynthia, Denis, Thanks for your feedback. I will plan to implement a cleanup job without an NWI, and will keep the DB-WG informed. Regards Ed Shryane RIPE NCC > On 25 Apr 2021, at 13:03, Cynthia Revström <me(a)cynthia.re> wrote: > > imo an NWI seems unnecessary unless we want it for purposes of referencing back to in the future. > > -Cynthia > > On Wed, Apr 21, 2021, 04:02 denis walker via db-wg <db-wg(a)ripe.net <mailto:db-wg@ripe.net>> wrote: > Colleagues > > How do you want to proceed with this suggestion? Do we have support > for deleting these ROUTE(6) objects for deregistered space and where > the objects were created before registration? Does anyone have any > objections to this as an ongoing cleanup? > > Do we even need an NWI or can we just ask the NCC to go ahead with it? > > cheers > denis > co-chair DB-WG > > On Thu, 11 Mar 2021 at 15:07, Edward Shryane via db-wg <db-wg(a)ripe.net <mailto:db-wg@ripe.net>> wrote: > > > > Dear colleagues, > > > > In response to the recent discussion on "196.52.0.0/14 <http://196.52.0.0/14> revoked, cleanup efforts needed", I'd like to propose a regular automated cleanup of route(6) objects in the RIPE-NONAUTH database using unregistered space. > > > > Regards > > Ed Shryane > > RIPE NCC > > > > > > > > Problem Definition > > ------------------ > > When an RIR deregisters IPv4/IPv6 address space, any route(6) objects in the RIPE-NONAUTH database using that address space are not cleaned up (deleted). > > > > > > Solution Definition > > ------------------- > > Once a day, compare route(6) IPv4/IPv6 prefixes in the RIPE-NONAUTH database against the combined delegated stats from all RIRs. > > > > Only route(6) prefixes that are "allocated" or "assigned" in any RIRs delegated stats should remain in the RIPE NONAUTH database. If a prefix is "available" or "reserved" then it is considered to be unregistered, and any associated route(6) objects will be eligible for deletion. > > > > If a prefix is partially "available" or "reserved" then it is also considered to be unregistered. > > > > If a prefix is not listed in any RIRs delegated stats, that prefix is skipped. > > > > The origin AS status is not considered, only the IPv4/IPv6 prefix. > > > > If a newly unregistered prefix is discovered, first allow a grace period of 1 week. This allows time for mistakes in the delegated stats to be corrected. > > > > After 1 week, contact the route(6) maintainer(s) to notify them that the route(6) object will be deleted. > > > > After a further 2 weeks, delete the route(6) object. > > > > A maintainer can request the RIPE NCC to exclude a route(6) prefix from deletion (for example, the deregistration of the prefix is being disputed). For any excluded prefixes, any associated route(6) objects will not be deleted. > > > > > > Impact Analysis > > ------------------ > > There are approximately 738 routes (out of 56,230) in the RIPE-NONAUTH database using a prefix with status "available" or "reserved" in an RIRs delegated stats, which will be eligible for deletion. > > > > There are approximately 94 route6's (out of 1,564) in the RIPE-NONAUTH database using a prefix with status "available" or "reserved", so also eligible for deletion. > > > > There are approximately 64 routes and 37 route6's with a prefix not listed in any RIR's delegated stats. These will not be affected. > > > > When this cleanup is implemented, the backlog of route(6) objects eligible for deletion will be processed at the same time, leading to a large amount of emails to affected maintainers. Once this backlog is processed, the number of route(6) objects affected is expected to be low. > > > > > > >

3 2

Reminder, join us today for the RIPE Database Requirements Task Force BoF
by Bijal Sanghani 05 May '21

05 May '21

Dear all, The third RIPE Database Requirements Task Force (DBTF) BoF will take place today from 16:00 - 17:30 (UTC +2) via zoom. We will present our latest recommendations and discuss a list of open issues with the community ahead of the publication of our final draft. More information and joining details are available at:https://www.ripe.net/participate/ripe/tf/rdb-requirements-tf/bof-5-may-2… Hope to see many of you online later! Kind regards, Bijal on behalf of the DBTF

2 1

RIPE DB Website template update
by Cynthia Revström 04 May '21

04 May '21

Hi Ed and WG, I am sorry for not looking at this during it's time in RC, but I have some comments on the new website templates. I very much appreciate trying to do a more responsive design, to support mobile and other non-landscape screen layouts etc. (I have actually needed to use the hosted RPKI interface once on my phone in the past) However I think there needs to be some more polish done here, not just for the DB thing but all the pages that seem to be in that UI, that being LIR portal, requests etc, DB, and RPKI UI. But a general overview of the issues I have seen is weird scroll bars, menus sometimes not working on my phone, weird spacing, and the content (RPKI UI, Database Query UI, etc) scaling very weirdly on my phone but not on my desktop computer. A few more things probably but I guess my summary is that it just needs a bunch of polish and more integration with the actual page (the section that has the ID "app-workspace" on the database query page). I am not quite sure if I should bring it up with the DB-WG as it does affect the DB interface or if there is some better person/wg to bring it up with, I would appreciate it if Ed could give me some input here. I have also seen similar comments from others, and if easy to implement, I would appreciate an option stored in a cookie or something to use the old UI until these issues have been sorted out. Once again, sorry for not commenting during the RC, I was a bit busy last week. -Cynthia

2 1

New Website Template Deployed to Release Candidate Environment
by Edward Shryane 03 May '21

03 May '21

Dear Colleagues, We have deployed a test version of the new website interface to the release candidate environment: https://rc.db.ripe.net/db-web-ui/query We have reorganised the left-hand and top menus, and modernised the template so it's more mobile friendly. Please let us know what you think. We plan to deploy to production next Monday, 3rd May. Keep in mind the interface is provisional so expect some changes before we go live. 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… Regards Ed Shryane RIPE NCC

1 1

Re: [db-wg] Cleanup of route(6) objects in the RIPE NONAUTH database using unregistered space
by denis walker 26 Apr '21

26 Apr '21

Thanks for the input Cynthia. As you are one of the few people who regularly comment on DB issues at the moment, maybe you could take a look at the request for feedback from the DB Task Force recently. Any comments would be appreciated, who knows it may even start a discussion :) cheers denis co-chair DB-WG On Sun, 25 Apr 2021 at 13:03, Cynthia Revström <me(a)cynthia.re> wrote: > > imo an NWI seems unnecessary unless we want it for purposes of referencing back to in the future. > > -Cynthia > > On Wed, Apr 21, 2021, 04:02 denis walker via db-wg <db-wg(a)ripe.net> wrote: >> >> Colleagues >> >> How do you want to proceed with this suggestion? Do we have support >> for deleting these ROUTE(6) objects for deregistered space and where >> the objects were created before registration? Does anyone have any >> objections to this as an ongoing cleanup? >> >> Do we even need an NWI or can we just ask the NCC to go ahead with it? >> >> cheers >> denis >> co-chair DB-WG >> >> On Thu, 11 Mar 2021 at 15:07, Edward Shryane via db-wg <db-wg(a)ripe.net> wrote: >> > >> > Dear colleagues, >> > >> > In response to the recent discussion on "196.52.0.0/14 revoked, cleanup efforts needed", I'd like to propose a regular automated cleanup of route(6) objects in the RIPE-NONAUTH database using unregistered space. >> > >> > Regards >> > Ed Shryane >> > RIPE NCC >> > >> > >> > >> > Problem Definition >> > ------------------ >> > When an RIR deregisters IPv4/IPv6 address space, any route(6) objects in the RIPE-NONAUTH database using that address space are not cleaned up (deleted). >> > >> > >> > Solution Definition >> > ------------------- >> > Once a day, compare route(6) IPv4/IPv6 prefixes in the RIPE-NONAUTH database against the combined delegated stats from all RIRs. >> > >> > Only route(6) prefixes that are "allocated" or "assigned" in any RIRs delegated stats should remain in the RIPE NONAUTH database. If a prefix is "available" or "reserved" then it is considered to be unregistered, and any associated route(6) objects will be eligible for deletion. >> > >> > If a prefix is partially "available" or "reserved" then it is also considered to be unregistered. >> > >> > If a prefix is not listed in any RIRs delegated stats, that prefix is skipped. >> > >> > The origin AS status is not considered, only the IPv4/IPv6 prefix. >> > >> > If a newly unregistered prefix is discovered, first allow a grace period of 1 week. This allows time for mistakes in the delegated stats to be corrected. >> > >> > After 1 week, contact the route(6) maintainer(s) to notify them that the route(6) object will be deleted. >> > >> > After a further 2 weeks, delete the route(6) object. >> > >> > A maintainer can request the RIPE NCC to exclude a route(6) prefix from deletion (for example, the deregistration of the prefix is being disputed). For any excluded prefixes, any associated route(6) objects will not be deleted. >> > >> > >> > Impact Analysis >> > ------------------ >> > There are approximately 738 routes (out of 56,230) in the RIPE-NONAUTH database using a prefix with status "available" or "reserved" in an RIRs delegated stats, which will be eligible for deletion. >> > >> > There are approximately 94 route6's (out of 1,564) in the RIPE-NONAUTH database using a prefix with status "available" or "reserved", so also eligible for deletion. >> > >> > There are approximately 64 routes and 37 route6's with a prefix not listed in any RIR's delegated stats. These will not be affected. >> > >> > When this cleanup is implemented, the backlog of route(6) objects eligible for deletion will be processed at the same time, leading to a large amount of emails to affected maintainers. Once this backlog is processed, the number of route(6) objects affected is expected to be low. >> > >> > >> > >>

1 0

input from community???
by denis walker 22 Apr '21

22 Apr '21

Colleagues Over recent months several important issues have been raised on this mailing list. We have seen comments from maybe 1 or 2 people to some of them. No comments at all to others. We appreciate that covid issues affect many businesses in many ways. So perhaps some of you have far more important issues to deal with than the RIPE Database. It is very difficult for the chairs to see consensus with only a couple of comments. The DB Task Force has also asked for feedback on a number of issues to help them finalise their recommendations. With 3 weeks to the RIPE Meeting and 2 weeks to the DBTF bof, if any of you have some spare moments to review any of the issues raised over the past months it really would help if you can offer some feedback, even better if that promotes some real discussion. cheers denis co-chair DB-WG

1 0

Call for Presentations / DRAFT Agenda RIPE82 - Database Working Group
by William Sylvester 22 Apr '21

22 Apr '21

Dear Working Group Members, Below is the proposed agenda for the Database Working Group for RIPE82. 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. Geofeeds – YY mins Massimo Candela, NTT D. YOUR PRESENTATION HERE – ZZ mins Community Member, RIPE Community E. NWI - Open Proposals – 5 mins Z. AOB (open discussion)

1 0

Whois Release 1.100
by Edward Shryane 22 Apr '21

22 Apr '21

Dear Working Group, RIPE Database release 1.100 has been deployed to the Release Candidate environment. We plan to deploy to production on Thursday 22nd April. This release includes the following main changes: * Separate email address and leading/trailing space during Punycode conversion (#782) * Use status index during update validation (#725) * Fixed aut-num attribute managed flag in lookup and search response (#749) * Added client flag to API for proxying requests (#728) * RDAP nameserver not implemented (#711) * Fixed delete object bug (#723) In addition to other 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