Internet Engineering Task Force David Kessens
Draft ISI
Expires February 1998 August 1997
<draft-ride-requirements-00.txt>
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]