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