Internet Engineering Task Force                            David Kessens
Draft                                                                ISI
Expires February 1998                                    Wilfried Woeber
<draft-kessens-ride-referencing-00.txt>                           ACONET
                                                            David Conrad
                                                                   APNIC



                            RIDE referencing

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 two variants of a proposal on how to find
   information regarding some critical resources (domain names, IP
   addresses and routing registry information) on the Internet. The
   proposed solution uses globally unique registry identifiers that are
   derived from a domain name in use by a registry.


Introduction

   use your domain name as the global registry identifier

   register in DNS where to query for the data

   query the appropriate server using the local identifier





Kessens                                                         [Page 1]

Draft                       RIDE referencing                 August 1997


Discussion

   Advantage:

   no central authority needed

   Disadvantage:

   the same thing.

   Variant of the prososal:

   double tree. IANA managed registries.int tree.

Detailed proposal

   globally unique registry identifier

   local to the registry unique identifier

   example: KH1-ARIN

   KH1 is local identifier ARIN is global registry identifier (last part
   of domain name can possibly be omitted)

   example: ISI-DOM

   suffix is not globally unique

   ISI-DOM is local identifier INTERNIC is global identifier

What do we store in DNS?

   - server, protocol and protocol options - what kind of data is
   available:
     IPv4 193/8, 194/8, 195/8, 62/8
     Domain .NOM, .STORE, ...
     AS 100-300, 1000-2000

     Note: IANA is authoritive for most of this data!

   Which records to use: new record, TXT record, kitchen sink, reusing
   old record

Security considerations

   The two different schemas described here have somewhat different
   properties regarding security.



Kessens                                                         [Page 2]

Draft                       RIDE referencing                 August 1997


   The IANA delegated model is in principle a very secure way of
   providing identifiers that indeed point to the registry that contains
   authoritive data regarding the allocation of Internet resources,
   provided that DNS security mechanisms get implemented soon. The
   situation for contact information pointers is somewhat different.
   While the IANA delegated model provides trusted pointers to trusted
   repositories of such data, anybody has the ability to register
   whatever contact data they want to such a trusted registry, and thus
   not providing much extra trust in the data itself. The distributed
   approach has no guarantees whatsoever that one can trust that a
   pointer points to a trusted party, since their is no system in place
   that checks if registries are trustable. However, the poiters itself
   are reliable provided that DNSSEC is widely used. Also, the RIDE
   mechanisms itself provides ways of retrieving the pointed to data and
   letting an individual registry decide after parsing the data if it
   contains enough and good enough information to accept the reference.


Acknowledgments

   We would like to thank Carol Orange and everybody that contributed to
   the work of the RIDE IETF working group in general, for their various
   comments and suggestions.


References

   [] D. Kessens  et. al., draft-ride-classes-00.txt,
       March 1997

Author's Address:

   David Kessens,
   ISI
   4676 Admiralty Way, Suite 1001
   Marina del Rey, CA 90292-6695
   USA
   davidk@ISI.EDU

   Wilfried Woeber
   Vienna University
   Computer Center - ACOnet
   Universitaetsstrasse 7
   A-1010 Vienna
   Austria
   Woeber@CC.UniVie.ac.at

   David Conrad



Kessens                                                         [Page 3]

Draft                       RIDE referencing                 August 1997


   APNIC
   Japan
   davidc@apnic.net
















































Kessens                                                         [Page 4]