- db-wg - mailman.ripe.net

Agenda RIPE78 - Database Working Group
by William Sylvester 15 May '19

15 May '19

Database WG Members, Please find the attached agenda for the RIPE Database Working group meeting in Iceland. Regards, William & Denis A. Introduction - 5 min * Welcome * Scribe * Jabber * Agenda B. Operational Update RIPE Database – 20 mins Edward Shryane, RIPE NCC C. Personal Data in the RIPE Database – 15 mins Denis Walker D. Cleaning Up Locked Persons – 10 mins Edward Shryane, RIPE NCC E. Country Codes Proposal – 10 mins Nikolas Pediaditis, RIPE NCC F. NWI - Open Proposals – 5 mins Z. AOB (open discussion)

1 0

Whois Release 1.94
by Edward Shryane 08 May '19

08 May '19

Dear Working Group, RIPE Database release 1.94 has been deployed to the Release Candidate environment. If no issues are found, we plan to deploy to production on Wednesday, 8th May. Release 1.94 includes the following changes: * Notify the user in the abuse-c comment if address validation has not been completed. * Improved email address validation. * Perform daily limit accounting for personal data in the Full Text Search interface. * Do not remove an abuse-mailbox attribute from a role object, if that role is referenced in a resources' abuse-c attribute. The complete list of changes in this release can be found in GitHub: https://github.com/RIPE-NCC/whois/blob/master/changes.txt The release notes have been published: https://www.ripe.net/manage-ips-and-asns/db/release-notes 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

NWI-9 In-band notification mechanism? ???
by ripedenis＠yahoo.co.uk 15 Apr '19

15 Apr '19

Colleagues Problem Definition There is a need within the routing community to have changes to all/nominated routing data objects in the RIPE Database pushed out to them, regardless of membership status. Last week Aris was the only person to confirm that he wants this feature. If we are to move forward with this feature can a few more people wave their hands in the air, or send a +1 email. cheersdenis co-chair DB-WG

6 5

NWI-8 LIR´s SSO Authentication Groups
by ripedenis＠yahoo.co.uk 15 Apr '19

15 Apr '19

Colleagues I think we have now agreed on these problem and solution definitions: Problem Definition LIRs would like a mechanism to easily add/remove users to centralised SSO authentication groups for maintaining objects in the RIPE Database. Solution Definition Stage 1 -Non billing Users listed in an LIR´s portal account will be contained in a default authentication group -Non billing users added or removed through the portal UI will be automatically adjusted in this group -This authentication group can be referenced in MNTNER objects by a new authentication method -These authentication groups for LIRs will be stored in a way that updates to the RIPE Database is not dependent on the availability of the portal service Stage 2 -Non billing Users listed in an LIR´s portal account can be added to and removed from user defined SSO authentication groups -Each User can be a member of any number of named groups -The authentication groups can be configured using the portal UI -These groups can be referenced in MNTNER objects by the new authentication method The chairs will now ask the RIPE NCC to work from these definitions in preparing their implementation plan. cheersdenis co-chair DB-WG

2 1

NWIs update
by ripedenis＠yahoo.co.uk 10 Apr '19

10 Apr '19

Colleagues We would like some feedback on the following NWIs and their current status. I would also like to remind colleagues that we have posted a couple of questions on the Address Policy WG mailing list about policy requirements for contact details. We would appreciate some feedback on those questions on that mailing list. cheersdenisco-chair DB-WG NWI-7 abuse-c implementation If the RIPE NCC can confirm that the cleanup of PERSON, ORGANISATION, MNTNER and IRT objects has been done to remove any "abuse-mailbox:" attributes and the 'person' keyword has been updated to take account of the "abuse-c:", we would like to mark NWI-7 as 'Finished'. NWI-8 LIR´s SSO Authentication Groups We agreed on this problem definition: Problem DefinitionLIRs would like a mechanism to easily add/remove users to centralised SSO authentication groups for maintaining objects in the RIPE Database. Do we agree on this (staged) solution definition?(Draft) Solution Definition Stage 1 -Non billing Users listed in an LIR´s portal account, who have an SSO authentication account, will be contained in a default authentication group -Non billing users added or removed through the portal UI, who have an SSO authentication account, will be automatically adjusted in this group -This authentication group can be referenced in MNTNER objects by a new authentication method -These authentication groups for LIRs will be stored in a way that updates to the RIPE Database is not dependent on the availability of the portal service -(Non billing users who did not have an SSO authentication account who then create one, will be automatically adjusted in this group - NCC, is this feasable?) -(Non billing users who are listed in the LIR's authentication group who then delete their SSO authentication account, will be automatically adjusted in this group - NCC, is this feasable?) Stage 2 -Non billing Users listed in an LIR´s portal account, who have an SSO authentication account, can be added to and removed from user defined SSO authentication groups -Each User can be a member of any number of named groups -The authentication groups can be configured using the portal UI -These groups can be referenced in MNTNER objects by the new authentication method NWI-9 In-band notification mechanism? ???Is there a wish to create this issue as an NWI with the following problem definition? Problem DefinitionThere is a need within the routing community to have changes to all/nominated routing data objects in the RIPE Database pushed out to them, regardless of membership status.

9 25

Call for Presentations / Draft Agenda RIPE78 - Database Working Group
by William Sylvester 08 Apr '19

08 Apr '19

Dear Working Group Members, Below is the proposed agenda for the Database Working Group for RIPE78. 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 – 50 mins Edward Shryane, RIPE NCC C. Proposed Presentation HERE – 10 mins D. NWI - Open Proposals – 5 mins Z. AOB (open discussion)

1 0

NRTM Open access
by Cynthia Revström 03 Apr '19

03 Apr '19

Hello db-wg, This is sort of a follow up on a previous discussion. I would just like to say that in a project I am working on as a volunteer I would like to have NRTM, but really we can't mess around with the agreements and such for how NRTM currently is at RIPE. So I would really like the NRTM access to be open. Because if you look at it like this, you can very easily download the entire database that is updated every 24h, but not get NRTM access which is the same but realtime. How does this make sense? - Cynthia

1 0

personal data...next step?
by ripedenis＠yahoo.co.uk 25 Mar '19

25 Mar '19

Colleagues I made a presentation at RIPE 77 last year about personal data in the RIPE Database. Whilst I have been thinking a lot about this since then, and some other comments have been made on different mailing lists recently, no action has yet been considered. This is not a trivial issue to fix and there are a number of points to consider. It will most likely require some semantic changes to the RIPE Database, and possibly the internal Registry Database and member portal may need some changes, as well as some work to be done by resource holders. It may also be an appropriate moment to review the requirements for contacts and contact data in both databases. The optimal solution is to manage the changes necessary to be compliant with privacy laws and practices with the least technical changes and work required by resource holders within a reasonable time frame. I see two approaches to doing this, a lightweight and a heavyweight option. The lightweight option is for myself, working with a couple of members who are interested in finding solutions for this issue, to look at all the concerns, raise points with the community for clarification and work towards a policy proposal on personal data in the RIPE Database. The heavyweight option is to set up a task force to look at the whole issue surrounding contacts and personal data, consider possible solutions and report back to the community at a future RIPE Meeting. My personal preference is for the lightweight option. Whilst it is an issue suitable for a Task Force to consider, history shows that Task Forces often take years to reach conclusions and workable solutions. The previous Data Protection Task Force met for 3 years and the recent Accountability Task Force has been meeting for over 2 years, whilst BCOP has been in operation for more than 5 years. I feel this issue needs a solution implementing this year. I would like to hear opinions from the community on which way to go.... cheersdenisco-chair DB-WG

4 4

In-band notification mechanism?
by Aris Lambrianidis 24 Mar '19

24 Mar '19

Dear all, Back in the day, RFC1996 introduced the NOTIFY mechanism in DNS, which significantly helped with information propagation delay, as it facilitated the transition from a pull (poll) to a push (interrupt) model. The problem we, as AMS-IX, are facing is quite similar when it comes to polling the RIPE database for changes. This seems inefficient. Although the analogy breaks down quickly, as there are no RIPE database "clients" similar to DNS slave servers parsing NOTIFY messages, we would love to see any RIPE API created or extended, or any other mechanism implemented by which a client "registers interest" for any objects it wants to be notified of changes. As a simple example, if we were to "register interest" (e.g. via a REST POST or PUT method) for the AS-AMS-IX-SET as-set object, we would be programmatically notified whenever the "last-modified" field of the as-set was changed. Based on the above, I have 3 questions: 1. Does something like what is described above already exist? 2. If it doesn't exist, would others be interested on such functionality? 3. If it doesn't exist, while knowing that this is only a high level overview of the concept and many details are missing, is this generally feasible? Kind regards, Aris Lambrianidis AMS-IX

7 20

Database website supporting the template and verbose flags on the query page again
by Ivana Svonja 15 Mar '19

15 Mar '19

Dear Working Group, we have now restored support for the template (-t) and verbose (-v) flags to the query page on the Database website: https://apps.db.ripe.net/db-web-ui/#/query <https://apps.db.ripe.net/db-web-ui/#/query> Regards Ivana Svonja RIPE NCC

1 0