Reply to editorial comments to routing document

"Kevin E. Jordan" <Kevin.E.Jordan@cdc.com> Mon, 04 July 1994 15:52 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02815; 4 Jul 94 11:52 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa02811; 4 Jul 94 11:52 EDT
Received: from mercury91.udev.cdc.com by CNRI.Reston.VA.US id aa06588; 4 Jul 94 11:52 EDT
Received: by mercury.udev.cdc.com; Mon, 4 Jul 94 10:52:16 -0500
X-From: kej@mercury.udev.cdc.com Mon Jul 4 10:52 CDT 1994
Received: from localhost by mercury.udev.cdc.com; Mon, 4 Jul 94 10:52:14 -0500
To: Steve Kille <S.Kille@isode.com>
cc: Allan Cargille <cargille@cs.wisc.edu>, mhs-ds@mercury.udev.cdc.com
Subject: Reply to editorial comments to routing document
In-reply-to: Your message of "Mon, 04 Jul 94 12:56:24 BST" <8427.773322984@glengoyne.isode.com>
Date: Mon, 04 Jul 94 10:52:13 -0500
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: "Kevin E. Jordan" <Kevin.E.Jordan@cdc.com>
Message-Id: <2e18302e59d0002@mercury.udev.cdc.com>

> 22.2 - underspecified O/R addresses.   I have mandated an approach to
> be followed, IN THE CONTEXT OF X.400, whereas you suggest that it
> should be optional.   I have tightened the text in this area, and
> invite you to review it.   I do not believe that this sort of thing
> should be left to implementor choice.

Oops!  Before now, I assumed that this section proposed an optional solution
to handling underspecified addresses.  I strongly object to making this
approach mandatory.  Doing so forces every administrator to create many
aliases which will clutter the directory unnecessarily.  This creates a
very significant administrative problem.

Our implementation uses the directory search operation to solve this problem
in a clean way.  We provide optional "searchBase" and "searchStyle" attributes
in each node of the routing tree.  These attributes tell the MTA where to
search for user entries associated with that point in the X.400 hierarchy,
and they also tell the MTA what kind of search operation to execute.   This
eliminates any possible need to proliferate aliases.

I do not object to offering 22.2 as suggested and optional solution, but I
object very much to making it mandatory.  Our implementation should handle it
properly should some administrator choose to define his/her directory using it.
However, 22.2 proposes a solution which is administration and data intensive.
Our approach, using controlled search, is much easier to administer, avoids
proliferation of alias entries, and has not created a performance problem
in practice.

Note also that alias entries not only create an administrative problem, but
they can easily create performance problems too.  Resolution of aliases often
requires many X.500 DAP/DSP operations and can involve several DSA's.  This
is especially true when an alias entry is held by one DSA and the entry it
references is held by a different DSA.  In many such situations, a controlled
search may actually require less X.500 overhead than an alias resolution.

In deploying X.500 directories at many customer and internal sites, we have
learned many practical lessons about maximizing success and performance, and
one of these is:

         Avoid aliases!