NIC handle writeup

Hi,

We discussed in depth the issue of NIC handles during the db-wg
session of the Stockholm RIPE meeting. I promised to write a draft
with a proposal. It's enclosed below for your review,

David K.
---

Internet Engineering Task Force                            David Kessens
Draft                                                                ISI
Expires March 1999 <draft-kessens-registryobject-identifiers.txt>



                      Registry Object Identifiers


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

   NIC handles have existed for a long time while they were never
   properly defined. At the same time, many registries started with
   their own interpretation of a definition that didn't exist. This
   document attempts to describe a definition that mostly backwards
   compatible with the definitions that most registries currently use.


Introduction

   For a long time, a need existed for a unique identifier to identify
   personal data in the regional registries. The NIC handle has been
   invented to address this issue. However, the concept of NIC handles
   has never been documented in any place and as a result, several
   registries use different definitions.

   This draft is an attempt to write up a definition that is compatible
   with the current definitions that most registries use and that allows
   other, possibly new registries, to design their own identifiers that



Kessens                                                         [Page 1]

Draft                        RIDE References                 August 1997


   are guaranteed to be unique. In addition, this document generalizes
   the concept to allow registries to use these unique identifiers for
   other classes (like host objects) then the personal data classes.


Concepts

   The identifier consists of two parts:

   - internal registry identifier

     The identifier is unique within the registry, but doesn't need
     to be unique on a global scale. This gives the registry maximum
     freedom to design their own identifiers for local use. In the
     past, one of the most difficult problems was the entropy in
     the the NIC handle name space.

   - global registry identifier

     This identifier makes the internal registry identifier unique on a
     global scale.

   A registry can be queried using the internal identifier or with a
   combination of internal and global identifier. The registry will add
   it's own identifier when the internal identifier is omitted.


Definition

   InternalIdentifier[@GlobalIdentifier]

   The global identifier is the same as a domain which is in use by the
   registry.

   The internal identifier is an RPSL word [1].

   Identifiers are not case sensitive.


Discussion

   No central authority was ever present to allocate global identifiers.
   This caused name collisions. However, it's undesirable to have such
   an authority. Therefore, it is needed to get an identifier from some
   other already defined namespace. The domain name system provides us
   such an identifier with minimal cost.

   A convention for internal identifiers for use in conjunction with



Kessens                                                         [Page 2]

Draft                        RIDE References                 August 1997


   personal data exists:

   InitialsOfPerson#

   It is recommended but not required to follow this convention.

   The '@' sign is choosen since it cannot be part of the internal
   identifier. In the past '-' was used which is causing ambiguities.

   It is not required that every registry is actually using the
   convention. A registry can mirror another registries data that
   doesn't participate in the scheme and assign a global identifier
   using a domain that is used by the other registry.


Example

   example: KH1 at ARIN.NET

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


Security considerations

   The model describes a dataformat which doesn't have security problems
   in itself. It doesn't make the system more or less secure.


Acknowledgments

   The ideas presented in this document are a composition of ideas and
   thoughts of the author and many other people that have developed over
   the years. In particular, the people that were present at the RIPE
   database working group, IETF ride BOFs and their respective mail
   lists have had quite some influence on the final outcome of this
   draft.


References

   [1]  Cengiz Alaettinoglu e.a., RPSL, rfc2280.txt


Author's Address:

   David Kessens,
   ISI



Kessens                                                         [Page 3]

Draft                        RIDE References                 August 1997


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















































Kessens                                                         [Page 4]