[Search] [txt|pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00                                                            
Internet Engineering Task Force                            David Kessens
Draft                                                                ISI
Expires February 1998                                        August 1997

                      RIDE functional requirements

Status of this Memo

   This document is an Internet-Draft.  Internet-Drafts are working
   documents of the Internet Engineering Task Force (IETF), its areas,
   and its working groups.  Note that other groups may also distribute
   working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet- Drafts as reference
   material or to cite them other than as ``work in progress.''

   To learn the current status of any Internet-Draft, please check the
   ``1id-abstracts.txt'' listing contained in the Internet- Drafts
   Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
   munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
   ftp.isi.edu (US West Coast).


   This document describes the (functional) requirements for the RIDE
   format and protocols.


   The solution to the problem of exchanging information between
   different Internet registry systems, and in particular the regional
   IP registries, has a lot of requirements. Those requirements are
   summarized in the first section. The second section describes the
   actual functional requirements that should be supported in the


   There are a couple of important requirements that need to be
   considered when building an Internet registry exchange mechanism.

Kessens                                                         [Page 1]

Draft                 RIDE Functional Requirements           August 1997

   - simple implemention
     The new registry exchange format and protocols should be an easy,
     simple and straight forward add-on to the current registry systems
     in order to make it likely that the specification will be

   - no new registry system
     The format and protocols are not intended to substitute one of the
     current registry systems. They are intended to allow to let the
     different registry systems to work together, as best as possible
     without requiring major changes to the current systems. Therefore,
     the design should be focussed solely to provide a framework for
     cooperation with minimal bells and whistles.

   - consistency and security issues
     The formats and protocols will not make the registries data
     consistent or secure by itself. All registries will have to work
     that out individually for their own particular registry
     implementation. However the design shall try not to increase
     inconsistencies or pose additional security problems. We can also
     consider to put forward some guidance for the individual registries
     how they can deal with those issues. Due to the public nature of
     the data that will be exchanged, security issues for the RIDE
     protocols are mainly limited to proper authentication mechanisms
     for the exchange of the full registry dataset and minimal exposure
     to denial of service attacks.
   - timing is important
     While it is nice to design a system that will be able to cope with
     every possible use in the future, we need a system right now. We
     therefore prefer to design a simple but expandable exchange
     mechanism rather than a perfect one which takes too long to define
     and deploy.

   - efficiency
     Whatever mechanisms are choosen, it is expected that, specifically
     for resolving references, the load on some servers in the system
     could be fairly high. Loads could be of the same order of magnitude
     as an ordinary non distributed registry server. In addition to
     this, data volumes for an exchange of the full contents of a
     registry system can be very high.

Functional requirements

   Protocol requirements

      - very simple but effective version negotiation mechanism

Kessens                                                         [Page 2]

Draft                 RIDE Functional Requirements           August 1997

      There are two different types of functionality that are needed in
      the system. Both are optional, the use of only one of the two
      makes the system already very useful.

      - retrieval of registry information for mirroring purposes

        This feature will need optional identification of the querying
        party for authorization purposes and possibly encryption
        capabilities for ensuring the privacy of the information.
        Information should be sent in a compressed format for efficiency

        The feature has two operating modes:

        - retrieval of all the information stored in a registry

        - retrieval of information that changed after the last retrieval

        The incremental retrieval feature is optional.

      - resolving of a reference

        This feature will do a lookup of an object using an identifier
        that is already known to the party doing the lookup. The
        identifier format will be standarized by RIDE to make this
        possible. The information is returned in RIDE format and the
        querying software can return the data to the user in native
        format by using it's mapping from RIDE to it's own formats. A
        shortcut (not using the RIDE mapping) might be desired in case
        two registries are talking together using the same registry

        The data is already publicly available in the native format of
        the registry and no identification or authorization for the
        querying party is needed.


        An object in the ARIN registry references an object with contact
        information using a NIC handle registered in the RIPE registry.

        One does a query to the ARIN registry and the ARIN registry will
        be able to resolve and display the referenced object from the
        RIPE registry.

   Format requirements

Kessens                                                         [Page 3]

Draft                 RIDE Functional Requirements           August 1997

      The registry data itself will be represented in US ASCII. Regional
      IP registries support only this, thus more is not needed.
      Furthermore, it can be very difficult in an international
      environment to use charactersets on a computersystem that is not
      configured for it, and can be even more difficult when the
      information is needed quickly to solve an operational problem.

Security considerations

   Security considerations are dealt with in the regular sections


   I would like to thank Kim Hubbard, Daniel Karrenberg, Dhaval Shah and
   everybody that contributed to the work of the RIDE IETF working group
   in general, for their various comments and suggestions.

Author's Address:

   David Kessens,
   4676 Admiralty Way, Suite 1001
   Marina del Rey, CA 90292-6695

Kessens                                                         [Page 4]