- db-wg - mailman.ripe.net

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

Cleanup of route(6) objects in the RIPE NONAUTH database using unregistered space
by Edward Shryane 21 Apr '21

21 Apr '21

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.

2 1

RIPE Database Requirements Task Force BoF, 5 May 2021
by Bijal Sanghani 15 Apr '21

15 Apr '21

Dear all, The RIPE Database Requirements Task Force (DBTF) will organise its third BoF on Wednesday, 5 May 2021 from 16:00-17:30 (UTC+2) via Zoom. During this BoF, the DBTF will present its latest recommendations and discuss open issues. More information and joining details are available at: https://www.ripe.net/participate/ripe/tf/rdb-requirements-tf/bof-5-may-2021 Kind regards, Bijal on behalf of the DBTF

1 0

RIPE Database - Historical Information
by Bijal Sanghani 14 Apr '21

14 Apr '21

Dear colleagues, As part of our work in the RIPE Database Requirements Task Force (DBTF), we are trying to understand if providing historical data is one of the requirements the RIPE Database must fulfil. Currently some attributes are filtered out to limit the exposure of unnecessary personal data. If providing historical data is a requirement the RIPE Database must fulfill, we will recommend the RIPE NCC to examine if additional filtering can be applied to limit further the unnecessary exposure of personal data in attributes that are not meant to contain personal data. We are looking specifically for arguments pro or against this recommendation. We’ll then discuss each argument with the task force and make a decision. Kind regards, Bijal on behalf of the DBTF

3 3

RIPE Database - Legal Address
by Bijal Sanghani 14 Apr '21

14 Apr '21

Dear colleagues, As part of our work in the RIPE Database Requirements Task Force (DBTF), we are trying to evaluate if we should recommend that the RIPE NCC publish the legal address of resource holders in the RIPE Database. It will include everybody that is directly receiving resources from the RIPE NCC. This information is already stored in the RIPE Registry but not available in the RIPE Database. However it’s good to note that since the implementation of NWI-10, a new attribute was added to the ORGANISATION object with the Country Code for the country in which the resource holder is legally based. As a reminder, this is our current recommendation: “The task force recommends that the legal address of resource holders who are legal persons be published in the RIPE Database. This will clarify which organisation holds which Internet number resources and ensure quick action from incident responders such as CSIRTs and LEAs in case of abuse.” The task force is aware that there are legal and technical constraints attached to this recommendation. The main challenge is to find a system that can clearly separate natural and legal persons across our service region, so that the privacy of natural persons in the RIPE Database is respected. This also includes corner cases such as SMEs using their home addresses as their legal addresses. We are looking specifically for arguments pro or against this recommendation. We’ll then discuss each argument with the task force and make a decision. Kind regards, Bijal on behalf of the DBTF

3 2

RIPE Database - PERSON Objects
by Bijal Sanghani 14 Apr '21

14 Apr '21

Dear colleagues, As part of our work in the RIPE Database Requirements Task Force (DBTF), we are trying to understand where there is a requirement to keep allowing PERSON objects to be created. We have received arguments for both pro and against this and we propose the following recommendation: promote ROLE objects instead of PERSON objects but still make it possible for users to create PERSON objects. We want to recommend the RIPE NCC to implement stricter checks and measures to prevent users from unknowingly entering personal data in both object types. We are looking specifically for arguments pro or against this recommendation. We’ll then discuss each argument with the task force and make a decision. Kind regards, Bijal on behalf of the DBTF

1 0

Comments on RIPE Database requirements progress
by denis walker 09 Apr '21

09 Apr '21

Colleagues For the benefit of those who don't often check the mail archives of the RIPE Database Task Force there have been 4 meetings in February and March with 3 sets of minutes published so far on their mail archive which can be found here: https://www.ripe.net/ripe/mail/archives/ripe-db-requirements-tf/ The chairs really appreciate the work done by the TF and acknowledge that it is a long and complex task. I have read through these last sets of minutes and feel some things need to be clarified. It may just be language but the minutes suggest the TF has or will make decisions on a number of items, rather than decisions on their recommendations for these items. As it says in their charter "The task force is a small and focused drafting team of up to six persons and not a representative body....Consensus building will take place in the appropriate RIPE working groups". Up to now there has been very little discussion in any working group and certainly no consensus on any of the issues raised as yet. I see the TF making a number of very important recommendations which can then be discussed publicly in appropriate WGs to see if there is a consensus. Let me try to clarify or question some specific issues from recent minutes. I am doing this here, rather than privately with the TF as I have done in the past, as I feel more public discussion is needed on this document the TF is producing. "The task force also discussed what will happen after their final report is published. They agreed that the implementation of the requirements could be delegated to the relevant working groups but mentioned that it will be up to the RIPE Chair team to decide what to do next with it." This implies that the requirements, as suggested by the TF, 'will be' implemented and that the implementation details 'could be' delegated to WGs. The requirements and recommendations themselves, from the TF, need to be discussed in WGs to see if the community even agrees with them. That needs to happen before any discussion on possible implementation. "Ed asked if the task force was considering to make a recommendation regarding assignments as it seems to drive the creation of a lot of unmaintained objects (especially PERSON objects). The task force replied that they were working on a recommendation dealing with assignments but didn’t reach a final decision yet." Firstly it should not be possible to create any unmaintained objects in the database now. If creating assignments is causing too much personal data to be entered into the database it may be the issue of personal data that needs to be addressed. The issue of assignments (whether or not they are needed) should not be confused with that of personal data. These two issues should be considered completely separately. "They [TF] also decided to only publish a final draft ahead of RIPE 82 and skip the publication of an intermediate draft." This is unfortunate as it again reduces community discussion and the chances for the community to offer any feedback to the TF to be incorporated into the final draft. "The task force discussed Randy and Denis’s recent comments on the db-wg mailing list about NWI-2 [historical data]. Ed mentioned that this was one final call from Denis to see if there are any interest from the community to move NWI-2 forward. As the task force is already working on this topic, Ed proposed to inform the db-wg that they can close NWI-2. The task force agreed." The NWIs are action points on the DB-WG. It is for the co-chairs to decide on these action points based on discussion and consensus by the WG members. The issue of historical data queries has been on and off the agenda of the WG for a number of years. I am sure the members of the DB-WG will have more to say yet on this issue. There have been many individual comments. The key to resolving this issue is to get all interested parties to discuss it, openly, at the same time. "The task force decided to keep the current baseline [registration] information data" I presume you mean 'the TF recommends keeping...'. There has been no discussion in any WG on changing this registration data so no consensus either way as yet. "The task force didn’t get enough information and arguments from the questionnaire survey results to decide whether or not the legal address of resource holders should be published in the RIPE Database. The task force will therefore ask the community via email to get more feedback on this topic before making a decision." Again this is an important issue which cannot be decided behind closed doors, based on private comments to a non representative body. There are some major issues in this list of points. In an open, transparent, bottom up, community driven industry these issues can only be decided by open discussion and consensus within WGs. We all welcome the recommendations put forward by the TF but they are by no means final decisions on these issues. They will be the starting points for open, public discussion leading to community consensus. In the meantime, please feel free to comment on and discuss publicly on this WG mailing list any issues regarding the TF draft requirements document which can be found here https://www.ripe.net/participate/ripe/tf/rdb-requirements-tf/the-ripe-datab… cheers denis co-chair DB-WG

3 2

RIPE Database requirements progress
by denis walker 08 Apr '21

08 Apr '21

Colleagues For the benefit of those who don't often check the mail archives of the RIPE Database Task Force there have been 4 meetings in February and March and the TF has just published the minutes of their most recent meeting on their mail archive which can be found here: https://www.ripe.net/ripe/mail/archives/ripe-db-requirements-tf/ Their latest draft requirements document can be found here: https://www.ripe.net/participate/ripe/tf/rdb-requirements-tf/the-ripe-datab… It would be helpful if more people would read this document and comment or discuss publicly on this WG mailing list any issues regarding the TF draft document before they publish their final version of the requirements. They also plan to hold a BOF sometime in May where you can make comments. cheers denis co-chair DB-WG

1 0

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

31 Mar '21

Hi Cynthia, Thanks for your support, my proposal is to automatically delete route(6) objects using de-registered prefixes from the NONAUTH database. For example, this would apply to the routes using the revoked 196.52.0.0/14 prefix which was discussed in January. If there is no objection from the DB-WG, I'd like to turn this proposal into a Numbered Work Item. Regards Ed Shryane RIPE NCC > On 31 Mar 2021, at 07:36, Cynthia Revström <me(a)cynthia.re> wrote: > > Hi Ed, > > I am not sure if this was something to discuss or just something you wanted to mention. > > Anyways as I saw this while looking through older emails, this sounds like a good idea to me. > > -Cynthia > > On Thu, Mar 11, 2021, 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. > > >

1 0

Re: [db-wg] db-wg Digest, Vol 113, Issue 1
by Tyrasuki 26 Mar '21

26 Mar '21

I approve implementation of this, and already use geofeeds in "remark" attributes. I've not seen much movement about this in a while so i think it might be a good idea to bring up again. Has there been any further discussion anywhere about this? \- Jori (Tyrasuki) \-------- Original Message -------- On Jan 4, 2021, 4:18 AM, < db-wg-request(a)ripe.net> wrote: > > > > Hi Job and db-wg, > > > > > I just want to start out by saying that I think this is a very worthwhile endeavour IMO, and thank you Job for reminding me of this thread. :) > > > > > I have also written some opinions about your questions and ideas below, and I would like to hear some input from people on the WG as this is sort of my initial thoughts but have not been thoroughly considered. > > > > > > Why not use the RPKI to distribute geofeed information? > > > > > I think using RPKI for this will make it needlessly complicated for people to use. I think we want to make this as simple as possible for someone to find. > > > > > To me it seems like it might be a good idea to add it as an attribute in the RIPE DB and then additionally having some like the HTTP API for finding abuse contacts but for geofeed ( https://github.com/RIPE-NCC/whois/wiki/WHOIS-REST-API-abuse-contact ). > > > > > > What downsides/risks/challenges down the road might exist? > > > > > As I noted in the comment above, I think the main challenge will be to make it simple and basic enough to implement for people wanting to publish geofeed URLs and people wanting to fetch geofeed URLs. > > I think having a basic HTTP JSON API to get this URL would really help with implementation as it would be really easy for data consumers to query for the URL and not have to parse WHOIS data or read RDAP RFCs or whatever. > > > > > Additionally, WHOIS is not encrypted/authenticated (which HTTPS/TLS is) and as such while the risk for malicious activity here might be low, I think having it authenticated would help (as in making sure you get the URL that the resource holder provided, not that the data in there is necessarily correct). > > > > > I think that if this is implemented, only HTTPS urls should be allowed, as in no plain text HTTP. (I don't have very strong feelings but it seems reasonable to me) > > > > > And on the note of the main challenge, I also think a part of making it simple to implement is to try to have the same API for this between all of the RIRs, because I don't think this will really succeed if only RIPE NCC has it. > > I think that if the RIPE NCC implements this, the next step will be to try to coordinate this with other RIRs so it can be a workable system for all RIRs. > > > > > > Will this be the final and full solution to GeoIP challenges? > > > > > I would say that this is probably not something that can easily be figured out other than by implementing it and waiting for a few years. > > > > > > Have any of the GeoIP aggregators/vendors responded to the 'geofeed:' initiative? What do the likes of amazon/google/maxmind think of the format? > > > > > I am also very curious about this, in particular to what the people wanting to use this data think of it (aka google, amazon, etc). > > I don't think maxmind is likely to approve of it as it basically destroys their product if successful. > > > > > Additionally I think this would be quite useful if it succeeded as if I recall correctly, the BBC uses the delegated list files on [ftp.ripe.net][] for GeoIP. > > This sort of became problematic when the whole delegated list file country code has to correspond to legal address thing happened, as this broke for some cases. > > > > > \- Cynthia > > > > > > > > On Sun, Jan 3, 2021 at 7:30 PM Job Snijders via db-wg <[db-wg(a)ripe.net][db-wg_ripe.net]> wrote: > > > > Dear DB-WG chairs, > > > > Today an acquaintance (who works at an ISP) reached out to me describing > > some annoying Geo IP location issues they were facing. > > > > I thought to myself "didn't we have a solution to such issues?" and was > > reminded of this thread. > > > > Chairs, how do we proceed to work towards the deployment of this new > > RPSL 'geofeed:' attribute? What is the next step? > > > > strawman problem statement for NWI process: > > > > "Associating an approximate physical location with an IP address > > has proven to be a challenge to solve within the current constraints > > of the RIPE database. Over the years the community has choosen > > to consider addresses in the RIPE database to relate to entities in > > the assignment process itself, not the subsequent actual use of IP > > addresses after assignment. > > > > The working group is asked to consider whether the RIPE database can > > be used as a springboard for parties wishing to correlate > > geographical information with IP addresses by allowing structured > > references in the RIPE database towards information outside the RIPE > > database which potentially helps answer Geo IP Location queries." > > > > Outstanding questions to the group & authors of the geofeed draft: > > > > \- What would the RDAP integration look like? (as per George: ideally > > WHOIS and RDAP stay aligned) > > \- Why not use the RPKI to distribute geofeed information? > > \- What downsides/risks/challenges down the road might exist? Will > > this be the final and full solution to GeoIP challenges? > > \- Have any of the GeoIP aggregators/vendors responded to the > > 'geofeed:' initiative? What do the likes of amazon/google/maxmind > > think of the format? > > > > Kind regards, > > > > Job > > > > [ftp.ripe.net]: http://ftp.ripe.net [db-wg_ripe.net]: mailto:db-wg@ripe.net

2 1

Time for new Announcements?
by Fergal Cunningham 25 Mar '21

25 Mar '21

Hi Marcel, all, Another forum you might want to explore is your local network operators group (NOG). There are 25-30 in our service region and lots more globally, and these are generally good places to connect with operators close to you on all manner of things. I would say they carry out a similar role to RIPE but on the national or even city level. And the discussions can be more specific than on the RIPE lists and might even be in your native language. They do a lot of good work. We have a pretty comprehensive list on RIPE Labs - https://labs.ripe.net/nogs - with links to the NOGs' webpages. All the best, Fergal Cunningham RIPE NCC

1 0

Time for new Announcements?
by Marcel Zimmer 13 Mar '21

13 Mar '21

Good morning dear community, it is an honor to be part of it :) We have applied for and been assigned our own AS at the beginning of the year (AS212033). Since yesterday the link to the first peering partner Lumen (AS3356) is available and the following networks should be announced: IPv4 193.3.45.0/24 IPv6 2a10:5dc0::/32 the corresponding routing objects sid created - so far so good :) Now yesterday I could observe the following: The first routers processed quite fast the Ipv4 routes and yesterday evening we had the following picture while looking glass of the Ipv4 and ipv6 network. https://www.bilder-upload.eu/bild-4a9957-1615622772.png.html https://www.bilder-upload.eu/bild-296f5c-1615622785.png.html Since then, somehow nothing happens. Do you have a tip for me where I should go troubleshooting? Greetings Marcel Zimmer

4 3

Webupdates UI bug?
by Cynthia Revström 11 Mar '21

11 Mar '21

Hi DB-WG, When creating a new object via webupdates, it selects IRT objects too in addition to the maintainers that are connected to the SSO account. This ofc doesn't work, and you just get an error, but it might be somewhat confusing and should probably be fixed. -Cynthia

2 4

Forcing two-factor authentication for maintainer
by Antti Ristimäki 01 Mar '21

01 Mar '21

Hi list, Is it possible or could it be possible to force two-factor authentication for RIPE Access SSO accounts that are being referenced from a maintainer object? Given that many critical objects are protected by a maintainer, I would find it very convenient to be sure that every single SSO account that can be used to authenticate against the maintainer object, are properly secured. Antti Ristimäki CSC/Funet

2 1

RIPE Database history - let's make a decision
by denis walker 25 Feb '21

25 Feb '21

Colleagues "NWI-2 - displaying history for DB objects where available" has been open for almost 5 years. Every time we raise this we get 1 or 2 responses, but not enough to declare a consensus on. Although no one has spoken against the idea of making (moree) history available, there is no consensus on what and how to display historical data. So lets review where we are and where we 'could' go...then make some decisions. Available data: The RIPE Database keeps every version of every object since the current RPSL database was launched in April 2001. The data set is almost a complete set. Due to a technical issue a small amount of historical data was permanently lost from the database around 2003. This data does include all deleted objects and objects that have been deleted and recreated. The primary key of any object allows for the correlation of versions across a deletion/re-creation break. However it should be realised that, even if the primary key is the same, a re-created object may not be related to a previous version that was deleted. For example, an assignment may be made to company A. It is later deleted. At some point the same addresses may be assigned to company B. This 're-creates' an INET(6)NUM object with the same primary key as the deleted one. But the two sets of data are unrelated. All of this data is technically available. Excluded data: Privacy laws are quite strict now in the EU. The 'right to be forgotten' in an age where the internet forgets very little is also a significant concern these days. Because the RIPE Database is operated by the RIPE NCC, which is a company registered in the EU, all EU privacy laws apply to all the data held in the RIPE Database. This is a fact. There is no point having any further debate on this issue. So objects that contain only personal data will never be made available through any historical data interface. This includes the PERSON object. Because the ROLE object has been used interchangeably with the PERSON object over the last 20 years it has to be assumed that they may also contain mostly personal data. These objects are excluded from historical data. Operational objects include attributes that are considered to hold personal data. For example the "nic-hdl:" and various email, phone, address attributes are deemed to potentially hold personal data. This data is redacted from historical data in query results. A question that I don't believe has been put to the legal team is whether any case can be made to allow any of the redacted data to be legally included. In other words is there any gray area here? Can an argument be made that some data items, like say "nic-hdl:" are of sufficient interest to some groups, maybe investigators of hijacking resources or LEAs, that would overcome the EU's privacy concerns? Current service: Every time we discuss this issue some people keep turning the conversation onto the current service, who, why, what... It is what it is. It was explained in detail at the time in a RIPE Labs article: https://labs.ripe.net/Members/kranjbar/proposal-to-display-history-of-objec… Lets move on and discuss what you want rather than what you now have. Possibilities: -The focus will be, as it is now, on operational object data. With the one possible caveat on redacted elements mentioned above. -We can remove the arbitrary limitation on presenting history beyond a delete/re-created boundary. -We can allow historical queries on deleted data that does not exist in the database now as a 'current' object. (deleted but not re-created). -How do you want to access historical data? *through all RIPE Database query interfaces *only through a visual representation in RIPEstat *a dedicated whowas service *should historical data be available in bulk *could historical data be a part of the NRTM (in theory if historical operational data is available through unlimited queries, including deleted data, then it would be possible to data mine the entire historical data set) With big data technology, it is technically possible to present a view across the database at a given point in time. This would allow you to query the version of all objects which existed at that point in time. Whether this could be technically managed as a public service I don't know. Anything else that you would like regarding historical data? We can make this as simple or complex as you wish...if you have a use case and subject to legal constraints and technical challenges. Discuss..... cheers denis co-chair DB-WG

2 2

DBTF Questionnaire – Deadline Extended to 22 February 2021
by Bijal Sanghani 12 Feb '21

12 Feb '21

Dear colleagues, We’ve received 20 replies so far to the RIPE Database Requirements Task Force (DBTF) questionnaire. Thank you for that and the discussion on the mailing list. As we would like more feedback on these questions, we’ve decided to extend the deadline to 22 February 2021. The questionnaire takes less than 10 minutes and really will give us valuable feedback to consider for our final draft. You can take the questionnaire here: https://www.surveymonkey.com/r/ZM222M3 Thank you for your participation and support. Have a lovely weekend! Kind regards, Bijal Sanghani RIPE DBTF Chair

1 0

The DBTF needs your feedback!
by Ronald F. Guilmette 05 Feb '21

05 Feb '21

I am attempting to fill out this apparently endless survey, and it's obvious from the get-go that this whole thing was designed as an artificial device to justify the deep-sixing of critical WHOIS information which has traditionally been kept open and public. I mean seriously, who designed these questions? The way the questions are framed, they are all quite obviously pushing one particular point of view, and one specific political agenda, namely to excuse the hiding of information which has never before been hidden... and which does not need to be hidden, except for the benefit of criminals. Here's an example of how to frame a question in a way that pre- supposes one specific outcome: *) QUESTION: What would you prefer? 1) To be beaten and strangled to death? 2) To die of a horrible communicable infectious disease? 3) To be mercifully euthanized in your sleep? How about (4) NONE OF THE ABOVE? I'd actually like to go on living, if it's all the same to you. The survey questionare is positively jam packed with questions that are framed in this same manner... questions that, in effect, ask "How much information should we hide?" How about NONE OF THE ABOVE? Here is a concrete example from the questionaire: * 16. Rank this contact information from most (1) to least (3) important to facilitate Internet operations in the RIPE Database: Email address Phone number Fax number Well, hardly anyone ever sends FAXes anymore, so that one is a no-brainer. But the way the question has been formulated, it is obvious that *someone* wants to get rid of either phone numbers or email addresses in the contact data for various assigned resources, and that answers to this carefully crafted (and methodologically bogus) questionare are going to be used as a lame excuse to do that. I, for one, have seen this movie before... https://www.youtube.com/watch?v=ic6c3WvwbAw This kind of too-clever-by-half way of formulating questions in a way so as to get some desired set of pre-determined answers is both shameful and really beneath the dignity of RIPE. I suggest that the whole thing should be thrown out and replaced by the following single question: "Are you in favor of hiding the traditionally open WHOIS infornmation?" Then the folks who are in favor of allowing criminals in the RIPE region to hide behind GDPR can simply out-vote the rest of us and we can then wrpa up this entire sham process far more quickly and efficiently, saving time for all concerned, since the outcome has already been determined. Regards, rfg P.S. Whoever designed this survey form also does not believe, apparently, that any participant has the right to NOT have an opinion on any single one of the myriad of questions set forth. Do not pass GO and do not collect $200 UNLESS you have given answers even to the questions for which you have no opinion. P.P.S. Apparently, there is no constraint whatsoever on anyone who wishes to skew the results of this "survey" by simply filling in the form several thousand times. It's 2021. People are still running online surveys that can be trivially gamed?? <<me -- shakes head>>

6 7

Deprecation of whitepages
by denis walker 01 Feb '21

01 Feb '21

Colleagues Way back in 2008 it was suggested that the RIPE Database could be used for linking people well known within the network operating industry. The concept of 'whitepages' was introduced. This was an ORGANISATION object (ORG-PAGE1-RIPE) with 'org-type: WHITEPAGES' that could be referenced by PERSON objects to override the automatic deletion of PERSON objects not referenced by any resource object. In today's privacy world, it is a bad idea to use the RIPE Database as a phone book. Currently there are only 4 people whose PERSON object references this ORGANISATION object. (There are also 5 moderators referenced in the ORGANISATION object who have probably long since forgotten they had anything to do with it :) ) I think we should now deprecate this concept. LinkedIn is much more suited to keeping in touch with networking people. Comments appreciated... cheers denis co-chair DB-WG

11 16

"Hidden" historical WHOIS records
by Ronald F. Guilmette 01 Feb '21

01 Feb '21

The Co-Chairman's declaration that my prior post was off-topic for this mailing list... an assertion that I take strong exception to... has at least had the salutary effect of reminding me of a number of what I consider to be "open issues" -- issues which ARE quite unambiguously on-topic for this mailing list, and which I first broached here way back around December 3rd: https://www.ripe.net/ripe/mail/archives/db-wg/2020-December/006736.html At that time and ever since I do not believe that I have seen any resoponse to the clear and pointed questions I posed in the message linked to above. I thus am now obliged to restate and reiterate those still-pending questions. As part of my effort to clarify my goals, vis a vis historical WHOIS transparency, back on December 3rd I threw out what I felt would be a perfectly ludicrous and absurd suggestion, just for retorical purposes, in order to try to make a point. I said something along the lines of "Hey why don't you all just make the entire RIPE WHOIS data base private rather than public?" I felt sure that when I did this that at least some of the denizens of this list... at least the few who might still care about either transparency or accountability... would immediately recognize the utter absurdity of my retorical suggestion, and that those folks, at least, would get up on their hind legs to vigorously protest any such move away from the longstanding and historical open and public nature of the WHOIS data base in all five regions. I was thus shocked and more than a little dismayed to see some of the folks here on this list taking my suggestion as something other than the lame joke and retorical device it was intended to be. Some folks here, it seems, would be entirely fine with hiding literally *everything* from the eyes of outside and independent investigators, including but not limited to me personally -- outside and independent investigators who's only goals are honesty, fairness, and a lack of thievery and self-dealing on the part of RIPE "insiders". I will not mince words. I find this type of position and this type of orientation, in favor of secrecy and against transparency, to be nothing less than shameful. Who does secrecy and darkness help other than the criminal element within the RIPE region? Some of you may still remember the discussion which I engaged in here, on and around December 3rd. For those that do not, the above link may be helpful in refreshing your memories. At that time the subject at hand was the availability, or lack thereof, of access to historical RIPE records, in particular (a) access to records that have since been purged from the data base and also (b) access to the historical versions of various ostensibly "privileged" record types, specifically PERSON, ROLE, and MNTNER records. As noted above, to this day I have never seen an answer to the basic question that I had asked, back on December 3rd about access to either or both of these two broad categories of historical data, and more specifically, who, if anyone, decided or approved, unilaterally or otherwise, the notion that either of these two broad categories of historical data should be made unavailable. Thus, I ask yet again, who made these decisions to hide what was at one time open and public WHOIS data? I certainly do not wish to draw any improper or unjustified inference from the lack of response on this key point, but it quite certainly does seem to be the case, from where I am sitting, that nobody much wants to talk about how these decisions were made, let alone who made them. So, once again: Who exactly decided that these two categories of historical WHOIS records should be unavailable? Was this a decision of the membership and/or the community? Were these decision points / policy points debated openly and fairly, taking into account what may perhaps be multiple divergent views on the matter? Or did certain people in positions of power just make these decisions entirely unilaterally and without ever consulting anyone? I look forward to some clarity here as regards to how these decisions were made and who made them. I hope that others on this list, even if you may disagree with my personal preference for total openness and transparency of the data base, will at least join me in hoping that all -decisions- relating to data base access should at least be made in the clear light of day, and in an open and transparent manner. Regards, rfg P.S. I remind everyone that during the discussion back in early December it was noted that a relevant policy proposal had already been lingering in a state of suspended animation for some years already. Perhaps someone can help me out here. I have been searching for the reference to the specific (still pending?) policy proposal in question but I can't seem to find it now.

4 3

The DBTF needs your feedback!
by Bijal Sanghani 01 Feb '21

01 Feb '21

Dear colleagues, The DBTF (RIPE Database Requirements Task Force) would like to thank those that have given feedback so far on the published draft document - https://www.ripe.net/participate/ripe/tf/rdb-requirements-tf/the-ripe-datab… We appreciate the feedback given so far, however need a little bit more clarity on some aspects and have therefore published a new questionnaire to collect further feedback. Please can you take a few moments to compete this survey - https://www.surveymonkey.com/r/ZM222M3 You have until Monday, 15 February 2021 and the results will be reviewed and integrated by the task force in the final draft. More information about the task force is available at - https://www.ripe.net/participate/ripe/tf/rdb-requirements-tf Thank you for your participation! Kind regards, Bijal Sanghani RIPE DBTF Chair

1 0