Dear TF, Thank you for holding the BoF yesterday. After learning that minutes of task force meetings were indeed published and after some more searching I have now found these minutes in the mailing list archives. You could probably have prevented some of the criticism about lack of transparency by publishing them in a more obvious place. For my part I apologise for not searching more thoroughly before this morning. For your convenience here is a summary of the input I intended to give yesterday. This is based on the discussion at the BoF and the previously published draft document. I have tried to take your minutes into account as much as the limited time allowed, but I may have missed some things. First and foremost I advise you to structure your document in a way that readers expect from a requirements document for an existing system. As an example here is an outline that I personally would expect: - Description of the Current State of the System - some information about the system evolution over time would be useful - start with contacts database for networks and domains maintained by volunteers - add reverse DNS delegation - add authoritative record of number resource distribution / delegation by RIPE NCC - remove domains - add routing registry / policy - [this is from memory and certainly incomplete] - this should definitely include where various objects and attributes originate and who is responsible to maintain them - List of New and Changed Requirements - describe where each requirement originates - there can be conflicting requirements here - notably absent in previous published draft is the privacy requirement - Recommendations for Further Action - list of recommendations - some recommendations for priorities and sequencing - list of identified requirements with no recommendation - suggestions for an action plan Note that this does not include engineering decisions as per your charter. Again: just a suggestion based on common expectations. —— On the feedback you requested: Your difficulties in making progress on the question of ‘legal address’ may be overcome by clearly recognising the conflicting requirements of privacy and implementation cost on the one hand and preserving LEA resources on the other. Once you clearly identify and enumerate the conflicting requirements it may become more obvious what you should recommend. If not I would consider your task achieved by enumerating the requirements and explicitly declining to make a recommendation. Then the community has to find a way to resolve the conflicting requirements. On person objects I get the impression that the requirements are also not clearly stated. The implicit requirement seems to be to eliminate ‘personal data’ for which the person concerned has not given permission to store it from the database. As far as I know there is a legal requirement today to give persons a way to remove or change their personal data too. Of course this requirement is more complex when it conflicts with other requirements such as keeping and publishing authoritative records about internet resources. Again it may help if these conflicting requirements were explicitly listed first before discussing your recommendations. I also have the impression that some people focus on the object type of ‘person:’. Changing that to ‘role:’ and keeping the same information will not solve the privacy requirements. It will also help you if you actually include some statistics and behavioural patterns of database users regarding these objects into the ‘status quo’ part of your report. In particular it may be useful to consider differences depending on the source/maintainer of the data here. — Here is some more input on requirements: # Maintainer / Controller ## Requirement The person or entity responsible for maintaining each object and, where different, particular attributes within the object is clearly defined an queryable. ## Rationale RIPE database objects originate from different sources. The responsibility and authority for entering the data and for making changes to it rests with different parties. A common misconception by database users is that the RIPE NCC is responsible for all data in the database or and that the RIPE NCC can change any data at will. Therefore is important to make it obvious to even the casual user who in fact has this responsibility and authority. ## Originator This requirement originates from both the RIPE community and the RIPE NCC. ## Example Use Cases - Identify who to contact for reporting inaccuracies. - Select data maintained by a specific entity. - Assess the credibility of data. # Historic Data ## Requirement The RIPE Database should preserve historical data, e.g. data that is no longer current and make it queryable as much as possible. ## Rationale Historic information is required to investigate the usage history of number resources. This can help diagnose operational problems that originate in recent changes to the use of number resources, including abuse. This information is required for interpreting measurement data. This information is required for research of Internet development. ## Originator ISPs, LEAs, Researchers in General ## Example Use Cases - Research into routing/traffic trends: identify changes caused by registration changes, take into account registered policies, … . - Investigate the usage history of resources. — I hope this all helps to reduce entropy for you. In case my remarks are too terse or obscure, I’ll be happy to expand and clarify. Thank you for your consideration and your difficult work. If it were easy it would have been done already. Daniel [Full disclosure for the record: I am on the RIPE NCC staff and I do *not* speak for the RIPE NCC here. As the first volunteer in 1989, I have maintained both the software and the data from the beginning. Between 1992 and 2000 I have been responsible for the operation and development of the RIPE Database as Managing Director of the RIPE NCC; during that time I have moved from extremely hands-on to very general management of RIPE Database operations and development. Since then I have had no responsibility for the RIPE Database other than providing advice from time to time.]