- ripe-db-requirements-tf - mailman.ripe.net

Geolocation in the RIPE database
by Edward Shryane 02 Mar '20

02 Mar '20

Hi all, Here are some statistics for geolocation in the RIPE database. 25% of respondents in the recent survey use the RUPE database for geolocation. Background reading on geolocation in the RIPE database: https://www.ripe.net/manage-ips-and-asns/db/tools/geolocation-in-the-ripe-d… https://labs.ripe.net/Members/denis/geolocation-prototype-for-ripe-database * There are 24,408 inetnum objects with a geoloc: attribute (with 7,731 distinct values). 25 different organisations are responsible for 51% of inetnums with a geoloc: attribute. * There are 516,354 inet6num objects with a geoloc: attribute (with 1,045 distinct values). 1 single organisation is responsible for 99% of inet6nums with a geoloc: attribute. * 127,105 occurrences of "51.507351 -0.127758" (London) * 130,175 occurrences of "40.712784 -74.005941" (New York) * 255,998 occurrences of "34.052235 -118.243683" (Los Angeles) There is no special query flag for geolocation - the geoloc: attribute will be included if present in any matching inetnum or inet6num. Let me know if you have any questions or would like more details. Regards Ed Shryane RIPE NCC

1 0

Notes from 4 February 2020 Call
by Boris Duval 07 Feb '20

07 Feb '20

Dear all, Here's the meeting notes from our last call. Best, Boris *RIPE Requirements Database Task Force Meeting Notes* 4 February 2020 Attendees: Shane Kerr, Nick Hilliard, Bijal Sanghani, James Kennedy, Edward Shryane, Maria Stafyla, Boris Duval Agenda: 1/ Review actions a) Nick to liaise with George Michaelson (APNIC) Update: Nick contacted George but is still waiting from him to reply. b) Ed to send RIPE Database stats to Nick and James Update: Ed started to send data samples to Nick and James and is liaising with them to determine which data sets will be the most useful to analyse. c) Boris to create and publish Database usage survey Update: The survey is now closed and collected 206 replies. For further information see agenda item 2. d) Maria to follow-up with the RACI programme manager if there are candidates interested in doing new research on database accuracy. Update: Ongoing 2/ Review survey results The task force was satisfied with the number of survey respondents and the overall quality of the feedback received. Ed mentioned that the results were useful for the RIPE NCC Database team and complementary to the 2019 RIPE NCC survey. Nick stressed out that some of the outcomes were peculiar. James mentioned that he was surprised by some of the answers, especially regarding Question 3 "What do you use the RIPE Database for?”. Bijal and Shane agreed. A high number of respondents answered that they were using the RIPE Database for personal IP address management and Geolocation purposes. These results are odd because they don’t align with the initial purpose of the Database. Nick added that the community always devised against using the Database for Geolocation but that users were still doing it anyway. Shane shared that he was surprised by the high amount of people using the Database for abuse handling. Ed mentioned that the Abuse C policy was rolled-out years ago and that the RIPE NCC actively promoted it. Shane asked what the best approach would be to evaluate the feedback received and to integrate it into the requirements document. Bijal replied that this could be discussed during the face-to-face meeting. Shane proposed to start discussing the results with the community. James agreed but added that it will be better to start this conversation after the next face-to-face meeting to give the Task Force more time to analyse the data. 3/ Next steps Boris will send the survey results excluding the open questions to the mailing list. Boris will categorise and collate the open question answers and send it to the mailing list as soon as possible. 4/ Planning next face-to-face meeting The meeting will take place at the RIPE NCC office in Amsterdam on 18 February 2020 from 9 to 16. The Task Force will further discuss the survey results and continue its work on the requirements document.

1 0

RIPE Database Usage Survey
by Boris Duval 22 Jan '20

22 Jan '20

Hi all, The RIPE Database Usage Survey is now available online at: https://www.surveymonkey.com/r/PC9HTYP <https://www.surveymonkey.com/r/PC9HTYP> The deadline to answer the survey is 31st January. We will now promote it on the RIPE NCC channels (DB page, social media etc). Feel free to also share the survey with your personal contacts as we need as many replies as possible. Thanks! Best, Boris

1 1

updates
by ripedenis＠yahoo.co.uk 19 Jan '20

19 Jan '20

Hi Shane Thanks for the update. Did anyone take minutes during the calls and meeting? Are these minutes going to be published as other Task Forces have done? I would like the discussions to be as open as possible so anyone who is interested can follow them. cheers denis co-chair DB-WG

1 0

RIPE Database Requirements Task Force status update
by Shane Kerr 18 Jan '20

18 Jan '20

Friends & colleagues, The RIPE Database Requirements Task Force was formed to create a RIPE Document containing requirements for the RIPE Database, with the intention to use that for changes to the RIPE Database going forward. In addition to some discussion on the mailing list, we have had 5 calls and 1 face-to-face meeting on the topic. While we have some conclusions in our draft document, we feel additional input is necessary, so we will be publishing a survey on Monday. In our original timeline we were to publish an outline of the document by the end of 2019, but this was too optimistic. Our current timeline involves collating the results of our survey and having another face-to-face meeting in February, with an expectation of having a draft document in mid-April. We are planning a BoF for RIPE 80, which is mid-May, to discuss the draft with the community present at the RIPE meeting. Cheers, -- Shane Kerr RIPE Database Requirements Task Force Vice Chair

1 0

Alternate Universe RIPE Database
by Shane Kerr 19 Nov '19

19 Nov '19

Fellow task force members, [ Apologies for the length. ] Yesterday on a conference call one of the things that we agreed was that it would be a useful exercise to consider what the RIPE Database would look like if we were building one from scratch today. The idea is that we can start with a set of requirements that is truly necessary. I think of this as an alternate universe version of the RIPE Database, a universe where somehow there has never been a RIPE Database, but all of a sudden 25000 network operators decided to get together and create one. -------------------------------------------------------------------------- As a starting point, possibly our other selves would look at RFC 7020 for guidance. Particularly the goals: Internet number resources are currently distributed according to the following (non-exclusive) goals: 1) Allocation Pool Management: Due to the fixed lengths of IP addresses and AS numbers, the pools from which these resources are allocated are finite. As such, allocations must be made in accordance with the operational needs of those running the networks that make use of these number resources and by taking into consideration pool limitations at the time of allocation. 2) Hierarchical Allocation: Given current routing technology, the distribution of IP addresses in a hierarchical manner increases the likelihood of continued scaling of the Internet's routing system. As such, it is currently a goal to allocate IP addresses in such a way that permits aggregation of these addresses into a minimum number of routing announcements. However, whether IP addresses are actually announced to the Internet and the manner of their advertisement into the Internet's routing system are operational considerations outside the scope of the Internet Numbers Registry System. 3) Registration Accuracy: A core requirement of the Internet Numbers Registry System is to maintain a registry of allocations to ensure uniqueness and to provide accurate registration information of those allocations in order to meet a variety of operational requirements. Uniqueness ensures that IP addresses and AS numbers are not allocated to more than one party at the same time. These goals may sometimes conflict with each other or with the interests of individual end users, Internet service providers, or other number resource consumers. Careful analysis, judgment, and cooperation among registry system providers and consumers at all levels via community-developed policies are necessary to find appropriate compromises to facilitate Internet operations. And also the technical considerations: As a result of the system of technical standards and guidelines established by the IETF as well as historical and operational constraints, there have been technical considerations regarding the services provided by the Internet Numbers Registry System as it evolved. These technical considerations have included: 1) Reverse DNS: In situations where reverse DNS was used, the policies and practices of the Internet Numbers Registry System have included consideration of the technical and operational requirements posed by reverse DNS zone delegation [RFC5855]. 2) Public WHOIS: The policies and practices of the Internet Numbers Registry System have included consideration of the technical and operational requirements for supporting WHOIS services [RFC3013] [RFC3912]. As the Internet and the Internet Numbers Registry System continue to evolve, it may be necessary for the Internet community to examine these and related technical and operational considerations and how best to meet them. This evolution is discussed in the next section. https://tools.ietf.org/html/rfc7020 I think that even these requirements are too broad for our re-imagined database. Lets look at the goals one by one: 1) Allocation Pool Management IPv4 has run out and IPv6 is effectively unlimited, so this is not actually a real goal any more. 2) Hierarchical Allocation While this is important in the context of IP usage (especially routing), I think that the RIPE Database only need record where it has gotten addresses from (the layer up in the hierarchy) and where it has given addresses to (the layer down in the hierarchy). 3) Registration Accuracy This one remains super important. Probably today this is our most important requirement. And the technical requirements, also one by one: 1) Reverse DNS The RIPE NCC plays a key role in the reverse DNS, but it is not clear exactly what requirements this places on the DNS. One can imagine other models of DNS delegation where the database does not contain any information about the DNS directly. However, reinventing how reverse DNS works is out of scope of our task force, and certainly including reverse DNS information in the database is a straightforward solution. 2) Public WHOIS Similar to DNS, there is no particular reason that there needs to be a public WHOIS for registration information. There may not be any particular need for there to be any public information about registrations at all. (I would prefer maximum transparency possible, but this does not seem like a strict requirement to me.) -------------------------------------------------------------------------- Getting back to our own universe, while the RIPE Database is first documented in the document RIPE 13, the original purpose for the database is probably best documented in RIPE 4: Task Force 2: Network Management and Operations European IP traffic is carried by a multitude of different infrastructures. The resulting pan-European IP infrastructure needs to be well managed in coordination with the managements of the underlying infrastructures. Currently this works well enough. With the expected growth a generally agreed management coordination is needed. This task force should develop a managament framework and collect the necessary management information. Coordination with all other task forces activities is needed. Task 2-1: Create and maintain a (`whois') database about RIPE IP networks and their management information. Term: Ongoing, reports monthly, first Dec89 Task 2-2: Create an infrastructure of operational contacts via various means of communication. Term: Jan90 Task 2-3: Create a procedure for notification of security relevant problems assuming that the networks itself are unusable. Term: Jan90 Task 2-4: Develop procedures for common network operations. These can be loosely agreed and need not be formally specified. Topics: Use of SNMP, reciprocal logins for testing purposes etc. Term: Mid90, first rep Jan90 Task 2-5: Gather operating statistics. Traffic volume. Number of networks, hosts. etc. These are useful for planning and external publicity. Term: Ongoing, first rep Jan90 Task 2-6: Set up a European NIC which makes available the results of tasks 2-1 to 2-5 to all interested parties. Term: End90, first rep Mar90 Task 2-7: Maintenance and distribution of sets of common utilities, needed for the execution of the tasks 2-1 to 2-5. Term: ongoing. Task 2-8: Create and maintain centers of expertise in certain areas: router hardware and software, NSS, IBM software, etc. Term: ongoing. https://www.ripe.net/publications/docs/ripe-004 Sadly the motivation for this particular list is not included in the RIPE document, although we can ask one of the authors (Daniel) if he thinks that it is useful for him to provide this. I tend to think in our alternate universe only the first three tasks have much relevance any more. -------------------------------------------------------------------------- So, my own straw-man proposal for the minimum set of goals of a greenfield RIPE Database would be mostly based on RFC 7020: A) Support accurate Internet number registration. B) Provide views of the registration information, including a public one. C) Include whatever data is needed to support dependent technologies like DNS and RPKI. If we can agree on a set of goals (whether a version of these or something radically different) we should be able to list requirements that follow from them. Cheers, -- Shane

1 0

Requirements for the RIPE Database... or Databases?
by Shane Kerr 18 Nov '19

18 Nov '19

Fellow TF members, tl;dr Do we want to explicitly say that we are making requirements for separate databases? (Probably with separate requirements.) More words follow... I was thinking about starting off a discussion about stakeholders in the RIPE Database, and I quickly remembered that the RIPE Database is at least two and maybe more databases in one. We have the number registry: * IP address assignments (hierarchical) * ASN assignments (semi-hierarchical) We have the routing registry: * Routes * Routers * Other routing policy information in various objects & attributes We have some DNS information, which is used to configure DNS delegation in DNS servers that the RIPE NCC maintains: * Reverse DNS domains We have abuse/security information: * "Incident Response Team" (a.k.a. CERT) * Various attributes (abuse-c, remarks, ...) We have the last remains of attempts at lighthearted fun: * Poems We have contact information used by everything (secondary data, cleaned up automatically if not referenced by something else): * Organisations * Persons * Roles We have the authentication/authorization that protects stuff (also secondary data, although I don't think cleaned up automatically): * Maintainers * PGP & X.509 certificates Finally, I'd like to note that there is a highly-coupled database, which is the RIPE NCC member database. The RIPE NCC keeps all kinds of non-public information, some of which is pushed to the RIPE Database (like organization contact information), some of which the RIPE Database has specific access to (like SSO authentication), and some of which is never entered into the RIPE Database (like billing status). So... do we want to explicitly say that we are making requirements for separate databases? 😄 Cheers, -- Shane

4 3

@EXT: RE: Requirements for the RIPE Database... or Databases?
by Marcolla, Sara Veronica 06 Nov '19

06 Nov '19

Dear all, tl;dr:No, because I agree with the need to understand these several "functionally diverse” DB as ONE holistic concept of RIPE DB. Additional context: Reading the RIPE Database Documentation (https://www.ripe.net/manage-ips-and-asns/db/support/documentation/ripe-data…) it says that yes, the RIPE Database holds data for three separate registries (RIPE Internet Number Registry (RIPE INR) RIPE Internet Routing Registry (RIPE IRR) Reverse Delegation and ENUM Registry). However, while these could be three independent databases, the information in each of them is related to each other. In the past it was therefore decided to integrate the three registries into one logical database (which is also one physical database). I too substantially agree with the need to understand these several "functionally diverse' DB as one holistic concept of RIPE DB. One of the things I want to stress is that the RIPE Database is in reality used by many members of the RIPE community on a day-to-day basis and for many reasons, and if it is true that the RIPE Database has grown in complexity with more features, we need to keep in mind this practical usage, and perhaps strive for simplicity. Sara From: ripe-db-requirements-tf <ripe-db-requirements-tf-bounces(a)ripe.net> On Behalf Of Bijal Sanghani Sent: 05 November 2019 17:46 To: Shane Kerr <shane(a)time-travellers.org> Cc: ripe-db-requirements-tf(a)ripe.net Subject: Re: [ripe-db-requirements-tf] Requirements for the RIPE Database... or Databases? On 17 Oct 2019, at 14:07, Shane Kerr <shane(a)time-travellers.org<mailto:shane@time-travellers.org>> wrote: Fellow TF members, tl;dr Do we want to explicitly say that we are making requirements for separate databases? (Probably with separate requirements.) More words follow... I was thinking about starting off a discussion about stakeholders in the RIPE Database, and I quickly remembered that the RIPE Database is at least two and maybe more databases in one. We have the number registry: * IP address assignments (hierarchical) * ASN assignments (semi-hierarchical) We have the routing registry: * Routes * Routers * Other routing policy information in various objects & attributes We have some DNS information, which is used to configure DNS delegation in DNS servers that the RIPE NCC maintains: * Reverse DNS domains We have abuse/security information: * "Incident Response Team" (a.k.a. CERT) * Various attributes (abuse-c, remarks, ...) We have the last remains of attempts at lighthearted fun: * Poems We have contact information used by everything (secondary data, cleaned up automatically if not referenced by something else): * Organisations * Persons * Roles We have the authentication/authorization that protects stuff (also secondary data, although I don't think cleaned up automatically): * Maintainers * PGP & X.509 certificates Finally, I'd like to note that there is a highly-coupled database, which is the RIPE NCC member database. The RIPE NCC keeps all kinds of non-public information, some of which is pushed to the RIPE Database (like organization contact information), some of which the RIPE Database has specific access to (like SSO authentication), and some of which is never entered into the RIPE Database (like billing status). So... do we want to explicitly say that we are making requirements for separate databases? 😄 I believe we should cover all databases that come under the RIPE Database umbrella today and as part of our role we should review their role and need. It would be good to hear what others think, should our work cover ALL databases within the RIPE database? Is there agreement here? Thanks, Bijal Cheers, -- Shane ******************* DISCLAIMER : This message is sent in confidence and is only intended for the named recipient. If you receive this message by mistake, you may not use, copy, distribute or forward this message, or any part of its contents or rely upon the information contained in it. Please notify the sender immediately by e-mail and delete the relevant e-mails from any computer. This message does not constitute a commitment by Europol unless otherwise indicated. *******************

3 2

archive
by ripedenis＠yahoo.co.uk 25 Oct '19

25 Oct '19

Hi guys Are you using this email for your discussions and is it publicly archived as Hans Petter suggested? cheersdenis

2 1

RIPE DB Requirements - F2F
by Bijal Sanghani 24 Oct '19

24 Oct '19

Here’s the doodle for the face to face, can you please complete this by Tuesday 28th October - https://doodle.com/poll/pa6znwp39yxgp7h8 Let’s aim for a 9am start and finish by 4:30pm so those traveling can most likely get a flight home that evening, if that’s a problem for anyone please let me know. Thanks, Bijal

1 1