You're viewing an archived page. It is no longer being updated.
Wednesday, 16 May 2018, 14:00-15:30
WG Co-Chairs: William Sylvester, Denis Walker
Scribe: Marco Schmidt
Status: Final
William Sylvester, WG Co-Chair, opened the session, asking for any other items to put on the agenda. No items were suggested.
The presentation is available at:
https://ripe76.ripe.net/archives/video/58/
Dennis Walker, WG Co-Chair, mentioned one point about the change attribute, that historically they haven’t been really good at doing database clean-up efficiently. He asked if anybody would have issues if the RIPE NCC proactively contacts the people who still submit updates including the change.
Peter Hessler, Hostserver GmbH, stated that he still liked the change attribute and wanted to keep it. He added that if the WG insists on deleting it, that the RIPE NCC notifies the relevant party before deletion.
Edward responded that the changed attribute has already been deprecated, already filtered out and been completely removed from the RIPE dDatabase. The RIPE NCC sent alerts about this over the past two years. He added that it was misleading to users that they were still semi‑supporting it.
Peter asked to then properly reject such update attempts.
Ruediger Volk, Deutsche Telekom, responded that there was no use in breaking processes that are operating. While more could be done than just sending out the regular warnings, it’s also important to look what is the trade‑off that they gain from ignoring irrelevant additional submitted attributes that are at least syntactically correct. He also like the changed attribute because it has been a really good resource for people who could interpret the value of the object, but nevertheless it's not in the database any more.
Dennis responded that this attribute is just noise and it’s better have a clean RIPE Database.
Ruediger replied that they have to make sure that the database rejects stuff that is syntactically incorrect.
Dennis asked if this was a proposal, to which Ruediger responded that somehow it is. He had reported attributes that he would have liked to be fixed before the change attribute. For details on these reports he would need to look into his database.
Tim Bruijnzeels, RIPE NCC, said that usually all reports are followed up. Her suggested to look at this offline. With regards to the changed attribute, he said that there is a trade‑off. Currently the RIPE NCC is still allowing the attribute as they didn't want to impact operations. On the other hand, that does not send a clear signal to people who may still believe that by submitting the changed attribute they will have something that ends up in the database that will be useful.
Ruediger responded that he mentioned the topic that attributes were syntactically correct. This is consistent with a definition of RPSL. Removing attributes that were in the base definition would kickstart the process of asking whether they really declare they have their own standard.
Denis replied that they removed attributes in the past that were in the original definition and told Ruediger that he will let him know afterwards which attributes these were in detail.
Peter added, after clarification by Denis that unrecognised attributes were rejected, to reject the change attribute now, but don't let it be ignored forever.
Ruediger objected, adding that as such attributes might be burnt down in code of automatic management systems.
William suggested to take the conversation offline because of time constraints.
The presentation is available at:
https://ripe76.ripe.net/archives/video/61/
Ruediger asked if there was a schema language.
Andrew responded that in JSON there was no schema language and so right now most JSON protocols either used something that was not a standard such as JSON schema or they did it in pros like RDAP.
Mario Alfredo, dot IT, commented that there was a JSON schema version for RDAP, which was almost complete. He added that ARIN had been working on JSON content rules, which was a separate schema language and the ARIN conformance tool uses that to verify whether the JSON is schema‑compliant or not.
Ruediger asked if there was a schema document explaining one common schema.
Andrew clarified that this would be RFC 7842 and that RDAP has an extension mechanism too, so if they wanted to add things to it there was a very clear extension mechanism for doing that.
The presentation is available at:
https://ripe76.ripe.net/archives/video/62/
Bengt Gorden, Resilans AB, wanted to know about the article 17, the “right to be forgotten” article. He wondered how difficult this was from a legal and database standpoint and how that was going to be handled.
Maria responded that users could delete their objects themselves in the RIPE Database. She added that if someone did not have their maintainer there, they could always go to the maintainer and if their maintainer isn't responsive, there is a procedure for the RIPE NCC to take action.
Bengt clarified that he meant people who don't really know that they are mentioned in the RIPE Database but they are still there. Also, how could the RIPE NCC tell that the right “Jon Smith” was asking to delete his personal data.
Maria explained that the RIPE NCC has procedures in place for such cases. They also had also procedures in place, for example, the Assisted Registry Check (ARC), as well as other verification mechanisms that allow them to verify the accuracy and the validity of certain data.
Peter Hessler said that he had a lot of contact information in the RIPE Database as a company representative but also as a natural person. He added that he was not really happy with his home address being available via Whois and asked if there was a way that a natural person could restrict which of those required attributes are displayed.
Maria replied that she sees Peter’s point about mandatory attributes like a street address and that the RIPE NCC would take this into consideration and come back to Peter with feedback.
Peter Koch, commented that he wanted to go on the record as a former member of the RIPE Data Protection Task Force that he didn’t wish to be involved in the report because it was first based on an interpretation of Dutch privacy laws in accordance with the Dutch data protection authority. He added that GDPR has very subtle differences, especially concerning consent, so the report was based on an old assessment of the situation that is no longer sustainable. He suggested discussing this in more detail.
He added that Maria mentioned that the RIPE Database is fundamentally different from the DNS Whois. Traditionally, most of the European ccTLDs had their Whois data in the RIPE Database and the primary reason for migrating out was not so much a fundamental difference but a matter of scale and organisational responsibility. He added that he wanted to better understand how the RIPE NCC came to this fundamental difference because they have a European-based assessment on what can and cannot be published in one sphere and a contradictory assessment on what is going to be published there. He added that some users are in the delicate situation as maintainers in both worlds.
Peter continued that he thought there was still a lot of address space in the database that was not routed in the public Internet and that the necessity assessment for cooperation and coordination might need to be revisited. He added that historically there have been individuals as the holders of address space.
Peter said he was surprised that Maria was suggested basing the processing of personal data on consent and that the LIR/maintainer go collect the consent from the data subjects. There have been very strong voices both from the article 29 group and especially from the Dutch data protection agency that this is a “no go” and he wanted to understand why there is a different conclusion in this case.
Athina Fragkouli, RIPE NCC, thanked Peter for his comments and questions because these are issues that may be confusing to the public, and it was very important that they clarify them. The Data Protection Task Force was established in 2006 and they did a lot of work on things that were not there before. The purpose as a concept is fundamental in data protection legislation. The data protection authorities need the purpose to justify whether this process is lawful or not. This work by the Data Protection Task Force was so valuable for the recent review of the GDPR because the community came up with a purpose and they based their assessment on this new legislation. This new legislation doesn't change much, it inserts new obligations, but the principles are the same.
She added that back then, the community said that one of the purposes was facilitating the coordination of network operators, and this was fundamental reason to publish personal data in the database.
Athina then explained the difference with ICANN. DNS was a very hierarchical system, so any operational problems are solved along these hierarchical business relationships in place. The Internet is a little bit different. When there are issues with one side of the Internet, others want to communicate with the person responsible. They don't necessarily have a business relationship or any other kind of hierarchy there, it's more horizontal. The only way to communicate with the responsible person for this part of the network is through the database. Being able to establish a communication channel with this person was important.
Regarding the final point of consent, Athina explained that when someone was assigned or allocated Internet number resources, it was important to know who the person was responsible for a network. This person has an obligation and a responsibility towards the Internet community and the public to give their contact details. If this person doesn't want to give their contact details themselves they can ask an friend or colleague to do that instead. However, they should get the consent of this third person. If not, they cannot just put their contact details there. And the database is maintained both by the RIPE NCC and by the maintainers. The RIPE NCC shares this responsibility with those that actually insert this personal data.
Ruediger Volk, Deutsche Telekom, wondered whether it would be possible and appropriate that the RIPE NCC legal team write an article targeted at other legal teams to explain to them what they expect and what the arguments about the sharing of responsibilities are.
Maria responded that they will take these into account and they can publish another RIPE Labs article in the communication and explain more in details.
The presentation is available at:
https://ripe76.ripe.net/archives/video/65/
There were no questions or comments after this presentation
The presentation is available at:
https://ripe76.ripe.net/archives/video/66/
Sander Steffann, SJM Steffann and Retevia, said that he was informed that large parts of the AFRINIC community weren't aware of this change and were surprised by it. While they can basically host everything now in their own AFRINIC database, many weren't aware of this and haven't done this yet. They were a bit afraid that operationally things were going to break there. Sander presented a proposal from Andrew Alston who has a couple of objects in the RIPE NCC database and suggested to tag them with a different source to see the operational impact on those prefixes.
Denis responded that AFRINIC and APNIC were both keen to have this service dropped, so he was surprised that the communication hadn't been passed on.
Sander clarified that while AFRINIC staff is very happy with this, the message didn't reach large parts of the rest of the community, so the request would be to slow down a little bit, so they can get their stuff together.
Peter Hessler asked if there a plan for when those objects would be deleted.
Denis clarified that there is no plan yet for formally deleting them. You can still maintain them and when you decide you no longer need them, you can delete them. Once this current phase is over, we will ask for feedback from the community as to how we should approach any remaining existing objects.
Ruediger Volk, Deutsche Telekom, said that he was confused about many topics. Firstly, he understood that first the RPSS requirement that the AS co‑signs route objects get removed and then removing the maintainer that has allowed traditionally to do out of region stuff. He would have preferred the other way around, to close the loophole of the maintainer with the public password.
On Denis’ question as to why this order would be better, Ruediger explained that the public loophole maintainer could have been done with his consent a long time ago. But he was unhappy that we were moving out of that change of the complex AS authorisation model, which has a lot of implications and they need to understand the full details before they can actually move there.
He asked Denis to write a document that fully explained the new model so that he could check all the details that are relevant to his processes and existing data.
Denis said that he is sure that the RIPE NCC would prepare some documentation.
Ruediger said that as long as they don't have that documentation, obviously they cannot take the step.
Denis responded that it is unusual to have such documentation in advance but it should be possible.
Ruediger objected to change of the authorisation model without full documentation in advance and sufficient lead time.
Lu Heng, Larus Cloud Service Ltd, said that currently he creates a routing entry for AFRINIC address space with an APNIC ASN in the RIPE Database and it works. If he does the same in the AFRINIC database, then the routing was just half announced and then the traffic goes through Level3 and doesn’t pass so that could possibly break down a lot of networks. He added that, to his knowledge, quite a few transit provider don't recognise the AFRINIC routing database at all.
Job Snijders, NTT Communications, responded that he didn’t believe the former statement and that Lu Heng can email him if he really has operational issues with any of the large networks, so he will put him in touch with the right people.
Denis suggested that Heng and Job can talk and let the mailing list know the outcome.
Alvaro Vives, chat monitor, read out a comment from Andrew Alston, Liquid Telecom. Andrew wrote that he was happy to supply a test prefix, AFRINIC space against his RIPE NCC ASN, to do a reachability test because some of them that are both RIPE NCC and AFRINIC members were sitting on RIPE NCC ASNs which cannot be entered in the AFRINIC database. He added that this leaves him with significant concerns as to potential impact.
Sander clarified that this is the same proposal he had mentioned before. He added that he had just verified with the people at AFRINIC that their current online tooling doesn't allow for the creation of such objects but people who want them can request hostmasters and they will create them. It's not technically impossible, just very inconvenient.
Job stated that he is extremely happy that they were moving forward with this type of change, and it will prevent IRR hijacking. If this proposal had not reached consensus and there was no commitment to do this, the alternative approach would be to simply register all remaining IP space in the RIPE Database thereby precluding everybody else from making false registrations. He added that it was work for the community, but it was necessary to improve Internet security. The RIPE Database has been abused endlessly by spammers and other nefarious purposes. And any of the operational issues that we may encounter will be worth it.
Andrea Cima, RIPE NCC Registration Services, clarified that he would not give an opinion about this topic but wanted to let them know about a trend that he has seen over the last few months. The RIPE NCC had received more complaints in the last few months than ever regarding the creation of route objects for out-of-region space. He added that it felt like a number of people knew this was coming and they were quickly trying to create as many route objects as possible. The RIPE NCC has been contacted by colleagues of other RIRs, saying there are people creating route objects for address space that the other RIRs have not allocated yet. Andrea confirmed an increasing trend on the topic of hijacking that Job Snijders just mentioned.
Denis responded that they may need to move a bit more quickly into a clean‑up phase and discuss what to do with all these route objects sitting in the RIPE Database.
Sean Stewart, Verisign, commented that he has addresses from ASNs of three separate RIRs and he hoped that at some point in the future once the objects are cleaned up, they could find a way to authorise routes announced from another registry.
Denis said that perhaps they needed a global routing registry.
Lu Heng said he thought there were two problems. The first one was the risk of abuse and he suggested to maybe inquiring the foreign database for inquiring the registry. And secondly, that other databases are less functional. It's not technically a responsibility of the RIPE Database, however it's a reality operators face.
Denis responded that as far as cross-registry authorisation is concerned, over the years many ideas have been put forward and discussed but nobody had ever managed to come up with an idea that was in any way close to consensus.
William said that they would take this to the list and if someone has a proposal, it would be helpful.
Ruediger and Denis continued their discussion whether or not to remove the public maintainer password immediately. Denis suggested that they can ask the question on the mailing list right now, do they have consensus to change that public password tomorrow and if there was consensus there, it could be done like that.
Alvaro, chat monitor, read out another comment from Andrew Alston: He agreed with Job and while he wasn’t opposing the change, he was asking that the RIPE community work with the global community to ensure that this was done in a way that was properly tested and without adverse impact where necessary. If they needed to get the changes made to the database at the other RIRs to make sure that the objects can be properly released to there.
William said that they were over time by about ten minutes and still had two agenda items. With their open proposals, they have a bunch of proposals that haven't been talked about in over a year, they were going to raise them on the mailing list in coming weeks to see if there was any interest and if not, they would close them.
William continued with the last item, that the WG do has one co-chair slot open. They revised the process for chair selection from the last meeting and were hoping to get it back out in the fall. He and Denis look forward to people putting their hands up to help out.
William asked if there is any other open business.
Ruediger asked how the RIPE NCC was reporting back on fixes for the database.
Tim responded and said that he found some communication that Ruediger had reported an issue with the syntax of emails and that they found there was about 2,000 cases out of 4.5 million occurrences. They tried to find a quick fix for this, but it proved to be a little bit more difficult so the RIPE NCC needs to see what can done and with what priority.
Ruediger added that it would be good to have a general way to see which reports and bugs are open and how are they being tracked.
Tim said he will take that feedback back to the RIPE NCC. This particular issue is reported on a ticket and that was how the communication wen't but it's not visible to everybody of course.
William thanked everybody for their participation in the session.