Subject: Re: Last Call: Naming Plan for Internet Directory-Enabled Applications to Proposed Standard

From: Bruce Greenblatt <[email-masked]>
Date: Mon, 22 Dec 1997 23:31:08 -0800

I've participated in the ids group, and attempted to provide my input to
the authors of the "dirnaming" draft since it was first put before the
working group at the Montreal meeting in the summer of 1996.  Since
virtually none of my input has been accepted by the authors, I'll voice
some of it again here. 

- The implied goal of the naming plan is to create an infrastructure 
that provides an algorithmic mapping from an object's email address to
that same object's directory entry.  It is not clear that there is any
evidence that this is a requirement, or even a good thing.  To my mind
it is more than likely a bad thing.  For example, if I pay money, and am
issued a certificate that contains a distinguished name, I would want
this distinguished name to be valid, for several different email
address, and indeed, continue to be valid, even when my email address
changes.  A significantly more flexible arrangement has already been
proposed in Ryan Moats' drafts for finding (see
http://info.internet.isi.edu:80/in-drafts/files/draft-moats-client-finding-00.txt)

- Email address structures are normally flat, so that they can be easily
remembered, e.g. [email-masked].  Directory name structures, are normally
hierarchical, so that they can be used to distribute directory
administration responsibility, among other reasons, e.g. uid=fred,
ou=division x, ou=san jose, o=acme computers, l=california, c=us.  It is
not clear that tying the two structured name forms together is possible
in general, and even when it can be done, it is equally unclear whether
anything has actually been accomplished.

- The naming plan uses dns names for directory containers, even though
there is no requirement in LDAP that containers actually have any
relationship to a dns host.  Many organizational internet directories
have created (and will be forced by a variety of internal access control
requirements) an elaborate hierarchical infrastructure, with many
levels.  In order to conform to this infrastructure, the directory
administration would have to come up with host names for each of these
containers in the directory, which will more than likely never actually
be used as an internet host.  We are creating an artificial
infrastructure for no perceptable gain.

- As the author's have admitted the naming plan is not interoperable
with the existing naming infrastructures (e.g. the NADF
recommendations), which means that the auxiliary object class defined in
the draft can't be applied to an existing directory hierarchy.  It seems
to me that with a little thought that a mechanism could be defined which
allows this new proposed naming plan to coexist with other existing and
future naming plans.  Any naming plan that is not interoperable, should
not be given even the slightest consideration along the standards track.

- I agree completely with the remarks that Mr. Alvestrand made at the
San Jose IDS meeting in the discussion of a previous version of this
draft when he indicated (and I paraphrase) that any naming plan which
forces distinguished names to have any particular meaning is "EVIL". 
The Internet must allow directory administrators to build their
infrastructures in whatever way seems appropriate for there particular
corner of the Internet, while at the same time providing some level of
guidance for the contruction of their infrastructure.

- In his talk at one of the ids WG meetings, one of the principal
authors (Mr. Sataluri) indicated that his company had built an
unsuccessful directory offering, and that he believed that the main
reason for its failing was the fact that the NADF naming plan was
inadequate in its reliance on the civil infrastructure, and if only
there had been a naming plan like this, AT&T's (X.500) offering would
have been successful.  Internet directories will prolieferate in spite
of naming plans, and other shortsighted efforts like it, rather then
because of them

- I don't understand why a naming plan that allows directory
adminstrators to use the top level internet assigned host name as the
top level in their directory hierachies is not a sufficient solution to
the problem of the "Internet Naming Plan".  The IETF should be able to
define its top level of its directory tree as "ou=ietf.org, o=internet"
since they own the ietf.org host name.  It seems to me that just saying
this solve most of the problem that the naming plan is attempting to
solve.

Thanks for your consideration.

Bruce Greenblatt

The IESG wrote:
> 
> The IESG has received a request from the Integrated Directory Services
> Working Group to consider Naming Plan for Internet Directory-Enabled
> Applications <draft-ietf-ids-dirnaming-03.txt> as a Proposed Standard.
> 
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action.  Please send any comments to the
> [email-masked] or [email-masked] mailing lists by December 29, 1997.
> 
> Files can be obtained via
> ftp://ds.internic.net/internet-drafts/draft-ietf-ids-dirnaming-02.txt

---

From: Bruce Greenblatt <[email-masked]>
Date: Mon, 22 Dec 1997 23:31:08 -0800

Bruce Greenblatt