[db-wg] Reminder: RIPE Database Requirements Task Force – Draft Report Published

Hi Bijal,

> Regarding data minimisation, the question of “data inheritance” is
interesting but probably out of scope for this document.

Why is this out of scope?
I would personally consider this an essential part when talking about data
minimisation and not something you can just ignore.

I have not been following this closely as of late so apologies if I
misunderstood something.

-Cynthia

On Wed, Sep 29, 2021 at 2:32 PM Bijal Sanghani via db-wg <db-wg at ripe.net>
wrote:

> Dear Denis,
>
> Thank you for your feedback. You will find the task force’s reply to your
> suggestions and comments below. If you need clarifications feel free to
> contact us.
>
> -- Data management principles
> Regarding data accuracy, we decided to stick with the current wording as
> we think it encompasses all database users and not only network operators.
> Regarding data minimisation, the question of “data inheritance” is
> interesting but probably out of scope for this document.
>
> -- Purposes
> We chose to use existing RIPE Database purposes to build our requirements
> list as they were still relevant. Even though there is a use case for
> geolocation, we didn’t think that it constituted a purpose. The RIPE
> Database only offers partial geolocation data and the “geoloc:” attribute
> data is user-maintained and mainly unreliable.
>
> The task force suggested to rephrase the research purpose to “enabling
> research and analysis into IP networking in the RIPE region”. This way, it
> will also include IP research from the general public which was one of your
> suggestions. We will also give this purpose its own section and add more
> background information.
>
> — Requirements
> 5.1.2 Requirement: IPv4 PA assignments
> Under the current policy which we are recommending to remove, for reasons
> previously explained (https://ripe82.ripe.net/archives/video/542/), there
> are a lot of discrepancies in how resource holders document assignments and
> it’s already possible for them to delete assignments. Also, removing this
> policy requirement will be in line with the data minimisation principle.
>
> 5.1.3 Other consideration: Using the RIPE Database as an IPAM solution
> As stated in the document, IPAM goes against the data minimisation
> principle and is not directly matching the purposes of the RIPE Database.
> This is why we didn’t consider it as a requirement.
>
> 5.1.4 Requirement: Historical data and personal data filtering
> The historical data was added since 2001, but we implemented a feature to
> return historical data in 2013. We will edit the draft to make the
> distinction. We also appreciate your suggestion regarding historical data
> to: “Make as much historical data publicly available as is legally
> permitted.” but decided to stick with the current recommendation. This
> recommendation came as the result of discussions we had at previous BoFs
> and seems to be responding to the needs of the community.
>
> 5.2 Purpose: Provisioning of Reverse Domain Name System (rDNS)
> We didn’t identify any specific requirements that will be worth mentioning
> in this section. Regarding ENUM data, we will mention it as a side note in
> the document as it holds a special status in the RIPE Database.
>
> 5.3.1 Requirement: Routing information and 5.3.2 Requirement: Maintaining
> accurate routing origin information
> These requirements were developed in line with today’s best practices and
> might indeed reflect some of the status quo.
>
> 5.3.3 Other Consideration: Routing Policy Specification Language (RPSL)
> We do think that it’s worth clarifying that RPSL is not a requirement of
> the RIPE Database and that the relevant working groups should look into
> deprecating this old standard.
>
> 5.4 Purpose: Facilitating Internet operations and coordination
> Adding a stakeholder list is complicated as you’ll always end up excluding
> some people even if it’s a non-exhaustive list. This is why the task force
> decided to stick with a broader definition of RIPE Database users.
>
> Kind regards,
> Bijal Sanghani
>
>
> On 11 Aug 2021, at 13:50, denis walker via db-wg <db-wg at ripe.net> wrote:
>
> Colleagues
>
> The DBTF asked for comments about their latest draft document by 13
> August. So far I have seen only one comment. So I am taking off my
> co-chairs hat and putting my devil's advocate hat on again and I will
> make some comments of my own and raise a number of questions. I make
> no apologies for the length of this email and I accept some people
> won't read it for that reason. But as the DBTF is approaching the end
> of it's work, there are many things that need to be said about this
> document. Whether the DBTF can or will or should take these into
> account is for others to decide. The document can be found here
>
> https://www.ripe.net/participate/ripe/tf/rdb-requirements-tf/the-ripe-database-requirements-task-force-draft-report-july-2021.pdf
>
> '4.1 Data accuracy'
> Here you say data should be accurate for "all parties involved in
> network operations.". But In section 3 you accept that there are
> different user groups who use the database now. So data should be
> accurate for "all parties.". It may sound irrelevant, but you also
> accept in section 3 that there is friction between different user
> groups. If this document appears to favour one user group, network
> operators, it may be used in the future to argue against changes that
> benefit user groups other than network operators.
>
> '4.3 Data minimisation'
> You only refer to personal data and your definition only relates to
> limiting data to match the purposes. While they are valid examples,
> they are not the only issues regarding data minimisation. You haven't
> covered the issue of inheritance for example. Having one "tech-c:"
> attribute which is inherited by 10,000 INETNUM objects is far better
> than having 10,000 identical copies of that one piece of data. The
> concept of inheritance is certainly within scope of the business
> requirements as it can lead to improved data accuracy.
>
> '5. Purposes, Requirements and Recommendations'
> You start by saying:
>
> "To produce its requirements, the task force looked at four purposes
> of the RIPE Database.
>
> ● Providing authoritative and accurate registration of Internet number
> resources
> ● Provisioning of the Reverse Domain Name System (rDNS)
> ● Publishing routing policies by network operators (RIPE IRR)
> ● Facilitating Internet operations and coordination
>
> Even though this document is based around the four purposes mentioned
> above, the task force is aware that there is a fifth purpose that
> should be taken into consideration:
> ● Enabling scientific research into network operations and topology"
>
> This suggests that the DBTF considers that these 5 items are the only
> purposes of the RIPE Database. Although you say the fifth purpose
> "should be taken into consideration", you don't consider it in this
> document. This confuses me about the nature of this document. If it is
> to be the business requirements of the RIPE Database how can you not
> discuss one of the defined purposes?
>
> When I wrote the first set of Terms & Conditions for the RIPE Database
> 10+ years ago (which were approved at the time by the community) the
> purposes were listed as:
>
> ● Ensuring the uniqueness of Internet number resource usage through
> registration of information related to the resources and Registrants
> ● Publishing routing policies by network operators (IRR)
> ● Facilitating coordination between network operators (network problem
> resolution, outage notification etc.)
> ● Provisioning of Reverse Domain Name System (DNS) and ENUM delegations
> ● Providing information about the Registrant and Maintainer of
> Internet number resources when the resources are suspected of being
> used for unlawful activities, to parties who are authorised under the
> law to receive such information.
> ● Scientific research into network operations and topology
> ● Providing information to parties involved in disputes over Internet
> number resource registrations to parties who are authorised under the
> law to receive such information.
>
> Do you not regard these items as valid purposes of the RIPE Database now:
>
> ● Providing information about the Registrant and Maintainer of
> Internet number resources when the resources are suspected of being
> used for unlawful activities, to parties who are authorised under the
> law to receive such information.
> ● Providing information to parties involved in disputes over Internet
> number resource registrations to parties who are authorised under the
> law to receive such information.
>
> All of the 5 purposes you have listed are the historic purposes of the
> RIPE Database. Has the DBTF not recognised any new, valid purposes of
> the RIPE Database? (Besides IPAM that you have rejected.) Accepting
> that some historic purposes have been dropped (like forward domain
> registrations) do you consider that the purpose of the RIPE Database
> in 2021 has not moved on or developed from what it was, say, in 2001?
> It seems to me that there is a fundamental piece of information
> missing from this document. Who are the main user groups who enter
> data into and consume data from the RIPE Database, for what purposes
> and what data do they need? Do they have an equal stake or are there
> priorities? Do conflicts exist between stakeholders and data
> requirements? I don't see how you can document the business
> requirements and functionality without first defining the main
> stakeholders, actors, end users, data consumers and their data
> requirements. (Technically the Business Enterprise Requirements would
> be followed by the Stakeholder Requirements then the Solution
> Requirements. But as this document is shifting between requirements
> and functional review it seems to have merged all these into one, but
> without including some key elements.)
>
> In section 3 you say:
>
> "Some database users, such as ISPs or IXPs, have been part of the RIPE
> community for years, while others are relatively new, such as Law
> Enforcement Agencies (LEAs) or regulators. These user groups have
> different needs and expectations regarding the database which is
> creating friction within the community."
>
> So you have recognised that there are new user groups with different
> needs but this is not reflected in the historic purposes of the
> database. The purposes clearly have changed but these changes have not
> been recognised or formally accepted. Hence the friction you refer to.
> Unless we address the purposes these new user groups want from the
> database this friction is not going to be resolved. If these issues
> are not addressed then I would consider this document does not fully
> represent the business/stakeholder requirements.
>
> Geolocation is another purpose the database has long been used for and
> this has taken on a higher profile recently by a significant user
> group. This does not fit under the purpose 'Facilitating Internet
> operations and coordination' as some other features do like abuse
> contact definitions. Being a completely separate and external service
> that requires some new data to be stored in the RIPE Database for this
> service to function it is a different type of purpose to the other
> defined purposes. This should be listed in this document as a new
> purpose.
>
> Should it be generally accepted now that the RIPE Database is a public
> registry of all users of blocks of IP addresses? This would be similar
> to the public set of domain name registries. Anyone who wants to know
> who operates a domain name can look it up in the appropriate domain
> registry.  It has become quite common that anyone who wants to know
> who is using a block of IP addresses will look up those addresses in
> the RIPE Database. Has it evolved from just being a tool for network
> operators to a more general public service? Is it time to recognise
> this as a purpose of the RIPE Database?
>
> '5.1.2 Requirement: IPv4 PA assignments'
> You refer to "A core reason for registration of IPv4 PA assignments"
> in the address policy. It should be pointed out that this is also a
> 'historic' reason. Perhaps in 2021 it is not the only reason. If it is
> accepted that the RIPE Database has evolved into a public service
> registry and this is defined as a purpose of the database then that
> provides another reason for documenting all assignments in the
> database.
>
> For the DBTF to recommend not deleting assignments after making them
> optional is like a government recommending wearing masks after
> dropping the legal requirement. Most people don't wear masks now. Most
> optional assignments will probably be deleted. Why would operators
> spend time and money maintaining optional assignment data? Unless
> there is a clear benefit to the operator or some greater need covered
> by a requirement to provide assignments, I suspect most will simply
> ditch this public data. This would destroy the RIPE Database as a
> public service registry. If some operators maintained the optional
> data and some deleted it then we end up with an incomplete and
> inconsistent data set, which is what happened with forward domain
> data.
>
> '5.1.3 Other consideration: Using the RIPE Database as an IPAM solution'
> According to your survey results almost 54% of the respondents said
> they use the RIPE Database for their IPAM. That is the second largest
> percentage of all the listed uses. Only slightly behind general number
> resource management at 57%. Given the level of usage, why do you not
> accept IPAM as a valid, new purpose of the RIPE Database? Many years
> ago forward domain data was stored in the database. Many of the
> smaller domain registries used the database as their primary registry
> database. Most of the bigger registries only published a limited data
> set and used a referral mechanism to direct queries to their whois.
> One of the main reasons for deleting this data was the inconsistent
> and incomplete, public facing, data set. What is your reasoning for
> recommending not accepting IPAM as a new purpose of the database and
> maybe a resource holder benefit?
>
> '5.1.4 Requirement: Historical data and personal data filtering'
> This is the third draft doc you have published containing this statement:
> "Since 2013, the RIPE Database has stored historical data, as
> requested by the RIPE community"
> and this is the third time I have commented that this is simply not
> correct. The database contains every version of every object that has
> ever existed since April 2001. Historical queries were implemented in
> 2013, but the data was already there going all the way back to 2001. I
> trust the DBTF will finally correct this in the next draft.
>
> Your recommendation makes no sense whatsoever. Availability of
> historical data should depend on the type of data, not on the use case
> for accessing it. To suggest that researchers could be given more data
> access on a case by case basis is madness. The principle of
> availability of historical data is basically that operational data is
> available, personal data and any data subject to privacy is not
> available. There is no reason to limit any of the available data by
> user group or use case. It should all be publicly available. No user
> group or use case is going to make the excluded personal and privacy
> data available to anyone for very strict legal reasons. (In particular
> the right to be forgotten granted by GDPR. Of course that can be
> overruled by a court order but that is an exceptional use case.)
>
> The recommendation should be to make as much historical data publicly
> available as is legally permitted. I believe some of the data
> currently redacted could still be made available. I won't go into
> details here as it gets too technical for this doc.
>
> '5.2 Purpose: Provisioning of Reverse Domain Name System (rDNS)'
> ENUM may be a small part of this but it is still significant and
> should not be overlooked in terms of defining the purpose of the RIPE
> Database.
>
> "The task force didn’t find the need for any requirements or
> recommendations attached to this purpose and therefore recommend
> maintaining the current status quo."
> Comments like this really confuse me. It again makes me question what
> is this document? If it is a business requirements document then you
> cannot say there is no need to document any requirement for one of the
> purposes of the database.
>
> '5.3.1 Requirement: Routing information'
> The DBTF makes a long list of recommendations, but the whole list is
> simply a definition of the status quo. If you want to document this
> functionality that is fine, but that is then inconsistent with the way
> you have handled other functionality. There is nothing new or
> different in these recommendations so you could have said the same as
> you did for rDNS "we recommend the status quo".
>
> '5.3.2 Requirement: Maintaining accurate routing origin information'
> Again the list of recommendations are simply the status quo. I find
> this very confusing. Initially you appear to be recommending
> something. But you are only documenting the current practise.
>
> '5.3.3 Other Consideration: Routing Policy Specification Language (RPSL)'
> I think this section is out of scope for this document. This is choice
> of technology and technical implementation. First of all, what the
> DBTF says here is not strictly accurate. The RIPE Database data model
> is 'based' on RPSL and RPSLng. It never has been a strict
> implementation. Although the RPSL standard may not have been
> maintained for decades, the implementation in the RIPE Database has
> been modified, added to and cut down many times according to the needs
> of the RIPE community. The way data is input and output does not need
> to exactly match the way data is stored internally in the database.
> All the data, not only the routing information, is currently still
> stored internally in an RPSL like format. This is because the
> community has never had the appetite to redesign the data model, not
> even with a small iterative approach (despite numerous attempts by
> myself to push for this over the last 10 years).
>
> If this document is the business requirements then it may be in scope
> to recommend a review of the format(s) of data input to and output
> from the database. The internal representation of that data is
> definitely out of scope. Even discussing what detailed routing
> information is useful is more for the level of technical specification
> than a high level business requirements document.
>
> '5.4 Purpose: Facilitating Internet operations and coordination'
> "The RIPE Database should facilitate communication and cooperation
> among stakeholders for the following reasons:"
> This needs to say, "for reasons including the following:". The list is
> not exhaustive now and there may well be other reasons in the future.
>
> 'Accuracy'
> (hair splitting comment) RFC7020 does not define 'registration
> accuracy'. It simply uses the words as in "provide accurate
> registration information". So what 'accurate' means in terms of
> registration information does not appear to have been defined
> anywhere. I think correct would be a more appropriate word than
> accurate.
>
> 'Resource Holder:'
> It should say "allocated or assigned....from the RIPE NCC directly" to
> be correct.
>
> General closing comment from me..
> Having read this document several times I am still confused about what
> it is. It is not (some form of) a Requirements document, nor is it a
> review of RIPE Database functionality. In either of those cases it
> only presents a select subset of what would be needed. What it appears
> to be, to me, is mostly a review of RIPE Database functionality that
> has been the subject of (recent) discussion and has outstanding open
> issues, with some requirements added in some cases. But even that is
> not complete.
>
> I really do appreciate the work the task force members have done. I am
> just not sure how to interpret the outcome.
>
> In the first bof in Iceland, Daniel's opening remark was "it is time
> to stop tinkering around the edges...". Looking around the room at the
> time I saw a lot of heads nodding in approval at that comment, even
> from some of the 'old grandees' of the community. Unfortunately most
> of this document, in my opinion, is still tinkering around the edges.
>
> I don't know if the DBTF was meant to document where we are now with
> the database or produce a guiding light to move onwards and upwards.
> Given that there are many recommendations it suggests it was to be the
> way forward. For me it falls well short of taking me to the place I
> imagined after listening to Daniel's inspiring speech. Perhaps an
> opportunity missed....or maybe I misunderstood the destination and/or
> route...or maybe that is the next step?
>
> cheers
> denis
>
> On Wed, 11 Aug 2021 at 12:26, Bijal Sanghani via db-wg <db-wg at ripe.net>
> wrote:
>
>
> Dear all,
>
> A gentle reminder for feedback on the report the RIPE Database
> Requirements Task Force published last month.
>
> Please let us know if you have any questions or concerns on the draft or
> if you’re happy with our recommendations. This will give us input into
> finalising the report which we plan to publish before RIPE82.
>
> We look forward to your feedback, thank you for your time -
> https://www.ripe.net/participate/ripe/tf/rdb-requirements-tf/the-ripe-database-requirements-task-force-draft-report-july-2021.pdf
>
> Kind regards,
> Bijal Sanghani
>
>
>
> On 1 Jul 2021, at 13:31, Bijal Sanghani <bijal at euro-ix.net> wrote:
>
> Dear colleagues,
>
> The RIPE Database Requirements Task Force has just published a draft
> report for your review:
> https://www.ripe.net/participate/ripe/tf/rdb-requirements-tf/the-ripe-database-requirements-task-force-draft-report-july-2021.pdf
>
> In this third draft, we’ve added new recommendations and edited our
> document based on feedback received via emails, survey and during our third
> BoF in May.
>
> Please review this draft and share any comments on the ripe-list before
> Friday, 13 August 2021.
>
> The task force will reconvene in August to discuss the feedback received
> and work on its final report that will be published ahead of RIPE 83.
>
> We look forward to your feedback.
>
> Best Regards,
>
> Bijal Sanghani
>
>
>
>
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </ripe/mail/archives/db-wg/attachments/20210929/6d112324/attachment.html>