Phasing out illegal OIDs

["Erik Huizer (SURFnet BV)" <[e-mail]>]

We need to seriously look at phasing out the illegal OID tree used in
RFC-1274. Colin had a suggestion way back (see below) that he's
willing to brush up and make non-quipu specific. Let me know what you
think.

Erik

--- Begin Message ---

Eric,

Here's the ID I referred to yesterday on OID aliases.  Looking back at
it, I see it does need revision to remove the QUIPU stuff, but that
can be done quite easily.

If you think the concepts are sound, I'll update it as soon as I can.

Colin

PS I love the old X-Tel/extel stuff - such history!


--------------------------------------------------------------------

                                                                  C.J. Robbins
OSI-DS 36                                                   X-Tel Services Ltd
                                                                 January, 1993



               An Aliasing Mechanism for Object Identifiers



1    Abstract

This is a DRAFT document for comments, following a request from the
PARADISE Christmas party. Disribution of this memo is unlimited.
Please send comments to the author, or the discussion group
<[e-mail]>.

This paper describes the Object Identifier alias mechanism used by
QUIPU. The mechanism is used to allow a smooth migration when the
dotted numeric representation of an OID being used in protocol
transfers has to be altered from one value to another.


2    Introduction

Object Identifiers (OIDs) are a crucial part of OSI networking, they
are used for a number of purposes:

   o Application Contexts.

   o Attribute types.

   o Object Classes.

   o Body part definitions.

There are a number of different sources of OID assignments, including:

   o ISO/CCITT Standards documents.

   o RFC documents.

   o Implementation specific.

These OIDs are often built into applications, or stored in static tables.

In most cases "stable" OIDs are defined by these documents, but in
some cases they are classed as experimental. If these experimental
OIDs start to be used in OSI services or pilots, then there can be
operational problems when the OIDs are upgraded to "stable", as this
often involves re-numbering in a different part of the OID numbering
hierarchy.

OSI-DS 36       An Aliasing Mechanism for Object Identifiers      January, 1993


An example of the is in the COSINE PARADISE X.500 Directory pilot. The
initial pilot was set up using attribute types and object classes
defined in a paper called "The THORN X.500 Naming Architecture".
During the course of the PARADISE pilot, this paper was revised, and
became RFC 1274 "The COSINE and Internet X.500 Schema". This revision
resulted in some of the OIDs being re-numbered.

This paper describes the mechanism implemented in QUIPU to allow the
PARADISE pilot to migrate to the new OIDs in RFC 1274 without
disrupting the pilot service. During the change over period, both old
and new OIDs were co-existent in the pilot for the same attribute.

It is recognised that RFC 1274 will need further change in the future.
Other implementors are encouraged to look at the mechanism described
here, so that such a change can be introduced into the pilot with
minimum of disruption.  This mechanism does not only apply to the
Directory, it should work equally well with all OSI applications.


3    Alias OIDs

QUIPU uses a set of OID tables to represent all OIDs used by the
system. These tables contain infor- mation such as the OID value
itself, string representations and where appropriate other information
such as the attribute syntax used if the OID is an attribute type

All OIDs are stored internally as pointers into these tables. When
ASN.1 protocol is decoded into program structures, all OIDs found are
represented as pointers into these tables.

A simple extension to this tables gives an aliasing mechanism. Where
an OID has two (or more) possible values, such as a new and old value,
only one entry is made in the table, this is used for the "preferred"
OID value. A stub table entry is then made for the other OID value(s),
and simply contains a reference to the "preferred" OID table entry.

When one of the "old" OIDs is encountered, the reference in the stub
table is found and followed, this gives a pointer to the "preferred"
OID table entry, which is used as the table entry for this OID.  From
here on, the "preferred" OID is then used instead of the old OID.

Using this mechanism, which ever OID (new or old) comes across in
protocol, the same "preferred" table entry is referenced. When an OID
is sent out over protocol the "preferred" value is always used.


4    Change over mechanism

The change over process from one OID value to another must be a three
phase process to allow time for the changes to propagate.

Consider the case where and OID "A" is to be replace with the OID "B".
The following procedure should be followed:

   1. Add "B" to the alias table, this means "B" will be recognised
      but not used (yet). When this has propagated to ALL components
      of the system (e.g., ALL) DSAs) then it is safe to start using
      "B" in protocol so:

C.J. Robbins	      						      [Page 2]

OSI-DS 36 An Aliasing Mechanism for Object Identifiers January, 1993



   2. Swap "A" and "B" in the tables. "B" is now the "preferred" OID,
      with "A" as an alias. This means the OID "A" will still be 
      recognised by applications entities, but OID "B" will be used in
      protocol. When this has propagated to ALL components of the system
      (e.g., ALL DSAs), then:

   3. The entry for "A" can be removed, and the change over is complete.

From experience in the PARADISE pilot, where such a change over was
introduced* a period in excess of six months was required between each
phase, as not all system administrators applied the changes as quick
as others.


5 QUIPU Limitation

The mechanism described above copes well when only one OID change is
involved. However during the pilot phase of new protocols the turn
around on OIDs can be much quicker, and a new OID "C" may be
introduced whilst "A" is still active. The basic procedure described
above will still work, however it should be noted the current QUIPU
implementation only allows one such alias OID.


6 Conclusion

Changing OIDs is a read administrative headache. This paper shows such
a change can be made smoothly if treated with care.  A situation such
as the "overnight swap" imposed by the FTAM change of NBS-9 OIDs must
be avoided.


Authors Address

Colin Robbins,
X-Tel Services Ltd.,         Phone:  [phone]
University Park,             EMail:  [e-mail]
Nottingham,                  UFN:    Robbins, X-Tel Services Ltd, GB
NG7 2RD, UK.



     Please note that X-Tel Services is not connected in any way with
     Extel Financial or the Exchange Telegraph Company Limited and is
     about to change its name to prevent any such confusion.






* The aliases were introduced with the release of ISODE-6.8, and swapped
  in ISODE-7.0. ISODE-8.0 should have removed the aliases, but never
  seemed to make it! 



C.J. Robbins                                                           [Page 3]

--- End Message ---