[ripe-db-requirements-tf] Alternate Universe RIPE Database

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