RIPE Database Working Group Minutes RIPE 75

Wednesday, 25 October 14:00 - 15:30
Co-Chairs: William Sylvester, Denis Walker
Scribe: Michael Frearson

A. Introduction [5 min]

• Welcome
• Scribe
•  Jabber
• Agenda

William Sylvester opened the session, asking for any other items to put on the agenda. No items were suggested. William then introduced Tim Bruijnzeels.

B. Operational Update RIPE Database [40 min]Tim Bruijnzeels, RIPE NCC

The presentation is available at:
https://ripe75.ripe.net/archives/video/172

Marco Schmidt, chat monitor, read out a comment from Job Snijders, NTT Communications: “Currently there is a 'community' keyword in the RPSL dictionary that refers to RFC 1997 communities. Now that we have RFC 8092 Large BGP communities it may be good to extend the dictionary and support documenting large communities too. However I am not aware of many networks parsing import/export RPSL aut-num lines, so this may be a change that offers very little return on investment."

Ruediger Volk, Deutsche Telekom, responded first to Job, saying the working group needed to discuss a very specific proposal for the extension of RPSL, as the extension mechanism has to be respected, given the risk of breaking existing clients.

Ruediger then moved to the subject of change attributes, saying the impact on people is likely to be indirect, as the main impact will be on robots. Ruediger added that, as the process of fixing or updating every robot out there is hard to control, it’s worth making the effort to maintain that part of code in order to avoid this process.

Tim replied that there is value in telling people in case they are using the attribute to keep a record of changes that they made and are not aware of changes made to the attribute.

Ruediger replied that the loss of the “changed:” attribute was painful to him as he lost some valuable information in the process, adding that when email was used, changes were announced along with the changer’s email address, which gave users a good idea of what was happening. He went on to say the online update process only provides the changer’s IP address, which does not give a clear idea of whom in the organisation is making this change and why, so some kind of identification of the account used when making changes should be included in all the change messages.

Tim replied that on all updates of objects the RIPE NCC includes this info where it can, but not on the creation of objects. Tim further explained that sometimes the RIPE NCC can’t say who made the change, if the person used password-based authentication, as there may be multiple maintainers on the object, and if the database reveals which maintainers match a password, that is a security risk. He suggested the solution is that people use more identifiable mechanisms such as SSO or PGP keys. Tim concluded his reply by adding the RIPE NCC has had discussions about personalising authentication but hasn’t gone with that yet, as it is difficult to see how to improve the function without introducing a security risk.

Ruediger said he thinks the old change reports didn’t give away anything, except for which authorisation was used, and that he’d like to see that again, or having some kind of ID on who actually acted. Ruediger then asked if password-based actions are possible in the online environment.

Tim answered yes, explaining you are required to log in, and if your SSO account is not associated with a maintainer, the system offers you the option to associate the maintainer with your SSO account. Tim added that if the user opts out of this, the system then remembers their choice.

Ruediger then asked whether, when using the online update functionality, the user is always on SSO or if there is a path that doesn’t identify the user.

Tim replied that the user can use syncupdates, and that the problem with a password-only authentication model is that you don’t have to supply the context of the maintainer/password association. He explained that, technically, the RIPE NCC can do it but thinks it introduces a security risk.

Ruediger replied that careful analysis is needed, and added that he would expect there is a function that can identify which information is available and can be passed on without disclosing too much.

Tim replied that if someone notices the password matches only one maintainer, they can tell which one it is.

William then stepped in and suggested people continue this discussion outside of the working group.

Peter Hessler, Hostserver, said he joined the Database Working Group to know who made changes to his objects, and he wants to see this with any deleted or created object. He added that when the RIPE NCC cleans up the database, he wants to be told that this action falls under a certain clause, which will help recipients of the mails to understand what happened.

Erik Bais, A2B Internet, referencing Job’s comment, said he would like to see how RPSL can be implemented if possible.

Tim replied that he is not as familiar with RPSL as some of the working group, so he can pass on this request but would be happier if the discussion is between Job and Ruediger. Tim offered to take the request to GitHub and send it to the mailing list, but that requires the mailing list to take it and discuss it. He explained that he would need some feedback there, as this is not his request, and others may have reservations about it.

Ruediger offered one short comment on Erik: changing RPSL is not going to happen on the basis of some GitHub unless the wider community will use this GitHub area as the discussion forum.

William then interjected, suggesting the conversation was continued outside of the working group.

Marco Schmidt read a subsequent comment in the chat: “RPSL was originally discussed on Routing-WG.”

Rob Evans, Jisc, owned up to the comment, saying RPSL was originally discussed in the Routing Working Group, so perhaps that is the place to discuss whether this change is appropriate.

Tim announced that Alex Band, formerly Product Manager at the RIPE NCC, has left the RIPE NCC. From next year onwards, Nathalie Trenaman, currently RIPE NCC IPv6 Programme Manager, will take on the role.

Update on DB-WG Mailing List Challenges [5 min]
William Sylvester

William announced a change on the DMARC issues the mailing list has been experiencing, and now when a user clicks “reply all” it CCs the Database Working Group mailing list.

William reminded the group to make sure they are replying back to the list and he asked the group to let him know any comments or problems about this. He ended by saying this whole issue started because the mailing list had users who were not getting emails on the list from major providers.

Peter Hessler said in his mail client, if he presses “reply”, it is private. Peter asked if this was the intention.

William replied that it was.

Peter then said the working group should not be making changes to these people who are trying to break email.

Peter Koch, DENIC eG, mentioned William had said the Database Working Group has been “leading” the DMARC discussion, and asked if the issue is under discussion in every other working group.

William said he’d let Adam Castle answer the question.

Adam Castle, RIPE NCC, said the RIPE NCC is in the process of upgrading mailman solutions to have better DMARC settings for the mailing list, and that ideally there would be one solution for all mailing lists. Adam went on to explain that, though the Database Working Group mailing list was affected in particular, in future the RIPE NCC wants better settings for all mailing lists.

Peter suggested there will be DMARC setting unification when there is equal chair selection processes.

D. NWI - Open Proposals [10 min]William Sylvester

The video of this discussion is available at:
https://ripe75.ripe.net/archives/video/175

Peter Hessler asked whether the AFRINIC cleanup and opening up of the RIPE Database to non-RIPE objects are in conflict.

William replied that there is a solution around the out of region objects that is being reviewed by the RIPE NCC, and the other proposal has been in same status for year and a half and is still in the solution-finding phase.

Ruediger suggested the working group wait for AFRINIC to come back and report that things are good at AFRINIC, rather than interfering too much in what is happening over there.

Brian Nisbet, HEAnet, said he sent an email to the list after Budapest, proposing the working group ensures they close the loop on pieces of work, and even if suggestion is made and people say no, the group closes that item for the sake of clarity. He asked the group to clean up the outstanding items.

William replied that the working group has been working through the list, resolving one issue and moving to the next phase. He explained that as previous NWIs are reintroduced to the list, people have opinions and some things have continued to move forward. He concluded that it’s a long process but the group has got through almost half of that list in the last year and so is making good progress.

E. Identifier Technology Health Indicators (ITHI) [20 min]
Alain Durand, ICANN

The presentation is available at:
https://ripe75.ripe.net/archives/video/176

Piotr Strzyżewski, Silesian University of Technology, Computer Centre, said he found Alain’s presentation mostly about the DNS, which was being discussed in the other room. He asked Alain why he presented in the Database Working Group.

Alain replied that the fundamental reason is that the presentation is about the accuracy of data and the Database Working Group is the most appropriate to talk to about data accuracy and provide a heads up about what ICANN is doing.

Piotr suggested, due to the relevance of this discussion to the Anti-Abuse Working Group, that this presentation is appropriate for a Plenary session in order to reach a wider audience.

Alain agreed, saying he’d be happy to do that at the next RIPE Meeting.

Z. AOB

The video is available at:
https://ripe75.ripe.net/archives/video/178

William Sylvester, chairing this section, raised the chair selection process, saying the working group is looking to revise or modernise some issues and implement a better process that provides continuity with the chairs to avoid a situation like last year where three new co-chairs all join at once. William went on to explain that there is currently no process for removing chairs or replacing chairs, and he opened up the floor for comments regarding this.

Brian Nisbet said RIPE Chair Hans Petter Holen is looking at a single system for all working groups, which he is in favour of, but if that doesn’t happen, he implores the Database Working Group to not draw lots again. Brian reported he is trying to persuade the IoT Working Group not to adopt that system, and suggested the Database Working Group “steal” a policy from another working group, or at least ensure it has something that doesn’t lead to random chance.

William asked Brian if he had any recommendations.

Brian replied he is in favour of the Anti-Abuse Working Group policy, but he doesn’t mind if this is not adopted. If there is no consensus, then the working group could default to an election situation. He then said there should also be a right for the working group members to ask for a co-chair to be removed.

Nigel Titley, RIPE NCC Executive Board, said there are problems with the current process: not staggering the terms was a major issue, but the working group is not currently short of a chair, according to the letter of the chair selection process. Nigel also pointed out that the working group can’t use voting to elect a co-chair because it doesn’t have a defined franchise.

Peter Koch said consensus-based decision making is a very good approach to a number of things, but can be a compromise in disguise. He suggested if the process ends up stuck, a tie breaker will be needed. He went on to say applying IETF-style consensus isn’t necessarily a good thing in personnel decisions, and that the IETF also has tie breakers it uses sometimes. Peter asserted his belief that the tie breaker (in the case of the working group chair selection process) worked very well, and that the deficiencies in continuity weren’t necessarily caused by the tie breaker.

Peter Hessler said a concern brought up on mailing list was that breaking the RIPE Database Terms and Conditions is not allowed, and there is the question of whether the members and co-Chairs of the Database Working Group should be held more strictly to this. Peter then suggested these issues be covered in the modification of the chair selection process.

William asked Peter if he had a proposal as to what he would advocate.

Peter said no.