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). Abstract This document describes the (functional) requirements for the RIDE format and protocols. Introduction 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 system. Requirements 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 implemented. - 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 reasons. 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 technology. The data is already publicly available in the native format of the registry and no identification or authorization for the querying party is needed. example: 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 Acknowledgments 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, ISI 4676 Admiralty Way, Suite 1001 Marina del Rey, CA 90292-6695 USA davidk@ISI.EDU Kessens [Page 4]