[ripe-db-requirements-tf] Feedback on Last Week's BoF

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.]