March 2019 - db-wg - mailman.ripe.net

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

Personal Data in the RIPE Database - next step
by ripedenis＠yahoo.co.uk 11 Mar '19

11 Mar '19

Colleagues All the responses made indicated a preference for the lightweight option to move forward. Elvis Velea and James Kennedy indicated that they are interested in working with myself on a policy proposal. We will make a start on this and bring some issues to the community as we go along that need a wider viewpoint. cheersdenisco-chair DB-WG

1 0

as-set object(s) to declare AS value frameworks
by Niels ten Oever 08 Mar '19

08 Mar '19

Dear Database WG, Recent public debates on the ethics and social implications of digital technology, as well as the feedback I received on my presentation at RIPE77 [0], have stimulated me to think more about how value frameworks can inform routing decisions. Based on the analysis of several discussions in the IETF community [1], the ICANN community [2], and the recent book by David Clarke [3], I thought a voluntary declaration of values might be relevant for discussion in the RIPE community. A way of doing this could be the discussion of the introduction of two AS-SET objects in the routing database. This could enable Autonomous Systems to declare the values frameworks they adhere to. An example of possible objects would be: [object0] as-set: AS-GDPR remarks: members of this set declare to be compliant with the General Data Protection Regulation of the European Union mbrs-by-ref: ANY [/object0] [object1] as-set: AS-UNGP remarks: members of this set declare to have adopted and implemented the United Nations Guiding Principles on Business and Human Rights mbrs-by-ref: ANY [/object1] Members of these sets would declare to live up to these values. Based on these sets, other AS-es could, for example, choose to preferentially route via AS-es that are member of (one of) these sets. These value frameworks (the GDPR and UNGPs) were chosen because these are widely known and adopted standards in our community [4], so the understanding of these values should not be subject to a lot of interpretation and discussion. Do you think this would be a reasonable approach, and if so, would you consider becoming a member of (one of) these sets? Or do you think there are better ways to achieve this? Looking forward to hear what you think. Best, Niels PS I posted a similar e-mail to the routing WG to discuss the routing implications of this proposal. Please accept my apologies if this is considered as cross-posting, but I thought both aspects of this proposal might be interesting to discuss. [0] https://ripe77.ripe.net/archives/video/2113/ [1] For instance in the discussions on RFC1958, RFC3935, RFC6873, RFC7258, and RFC8280 [2] Most notably resulting in the addition of a commitment to human rights during the IANA transition, but of course as well during the extensive WHOIS discussions [3] https://mitpress.mit.edu/books/designing-internet [4] For instance SIDN has engaged in a Human Rights Impact Assessment https://www.sidn.nl/a/over-sidn/mensenrechten-daar-voldoen-we-toch-aan , and Cisco, Ericsson, Google, NTT, Orange, AT&T, IBM and many others have adopted the UNGPs - Cisco https://www.business-humanrights.org/en/cisco-systems-0?keywords=cisco - Ericsson https://www.business-humanrights.org/en/ericsson-0?keywords=ericsson#a117755 - Google https://www.business-humanrights.org/en/google-0?keywords=google - NTT https://www.business-humanrights.org/en/nippon-telegraph-and-telephone-ntt-… http://www.ntt.co.jp/csr_e/report.html - Orange https://www.business-humanrights.org/en/orange-0 - AT&T https://www.business-humanrights.org/en/att-0?keywords=AT&T - IBM https://www.business-humanrights.org/en/ibm-0?keywords=IBM -- Niels ten Oever Researcher and PhD Candidate Datactive Research Group University of Amsterdam PGP fingerprint 2458 0B70 5C4A FD8A 9488 643A 0ED8 3F3A 468A C8B3

2 1

personal data...next step?
by Jetten Raymond 04 Mar '19

04 Mar '19

Hi, I would prefer the lightweight option as well. Rgds, Ray

2 1

Whois Release 1.93
by Edward Shryane 04 Mar '19

04 Mar '19

Dear Working Group, RIPE Database release 1.93 has been deployed to the Release Candidate environment. If no issues are found, we plan to deploy to production on Monday, 25th February. Release 1.93 includes the following main changes: * Improved email address validation. * Do not allow expired public keys to authenticate updates, and expire signed messages after 1 hour. * Validate bogon space in route(6) creation. * Warn the user if the resource abuse-c is identical to the organisation's abuse-c. * Allow use of elliptic curve algorithm in key-cert objects (updated cryptography library). * Fixed NRTM client parsing end of stream comment in keepalive mode. * Filter out comment in autocomplete API (used by the DB web application) * Only validate reserved words in primary key on create, so existing objects can be updated. * Database schema changes for 2017-02 Abuse-c Validation implementation. 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 will also be published shortly: 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 2

Whois Release 1.92.6.2
by Edward Shryane 01 Mar '19

01 Mar '19

Dear Working Group, RIPE Database release 1.92.6.2 was deployed to production yesterday evening, with a single change from the previous 1.92.6 release. Following the Database downtime on 22 February, this change restores the Full Text Search functionality. More information on the downtime can be found on our website: https://www.ripe.net/support/service-announcements/ripe-database-full-text-… We apologise for any inconvenience caused by this incident. Regards Ed Shryane RIPE NCC

1 0