RE: Last Call: Naming Plan for Internet Directory-Enabled Applic ations to Proposed Standard

[Alexis Bor <[e-mail]>]

On the RDN requirement:

It seems that there is a significant gap in understanding what is really
going on out there.  I have been working with many large accounts that
have strong requirements to store all employees in the directory.  This
is not a one to one correlation to who has an email address.  For
example, one of my customers has 160,000 email users and 400,000
employees.  Most companies that do manufacturing do not have email
addresses for the assembly line workers, or at least no where near to
100 %.  At the same time, they are looking at issuing certificates for
everyone and perhaps using them in the badging/smartcard applications.

In fact, what I am finding is that a driving force at larger companies
is to have the DN be very stable for people, surviving organization
changes, personal name changes, geographic changes and any other change.
In addition, they want to truly simplify the tree process by putting all
of their entries into one branch of the directory tree, or at least only
have a few branches that separate employees, contractors and trading
partners.  The vision is to issue an employee a distinguished name at
hire time (perhaps the badging people or HR issue it and create the
initial directory entry) and then have that DN stay with the employee
forever.  This really helps people developing applications that want to
store a DN identifying someone and always be able to get back to the
data in the future.  Think of what this means to security
certificates...changing DNs makes much more work for certificates.

Clearly, I would like to separate the two discussions as well.  I like
the concept of the DC plan, but really have trouble with the RDN ideas.

-- Alexis

Alexis Bor
Directory Works, Inc.
16312 194th Avenue NE
Woodinville, WA  98072
425-788-7647
425-844-2375 (FAX)
[e-mail]
http://www.directoryworks.com 

-----Original Message-----
From: Chris Weider [mailto:[e-mail]]
Sent: Monday, December 29, 1997 5:08 PM
To: '[e-mail]'; [e-mail]
Subject: RE: Last Call: Naming Plan for Internet Directory-Enabled
Applic ations to Proposed Standard


I have to agree with Jeff here, and with some comments that Bruce
Greenblatt
made in his earlier message to this list.

The current document (draft-ietf-ids-dirnaming-03.txt) really contains
two
main threads: the use of DC= naming, and the suggestion that entry RDNs
be
only cn or uid, with a specific format. Let's examine each of these
separately.

The use of the DC naming convention is a Good Thing. It allows more
rapid
directory setup, somewhat easier navigation given certain types of
starting
information, and leverages an existing unique name space (why should we
have
two?). If anything should be kept out of this document in the absence of
requirements, this is it.

However, the second suggestion is much more problematic. As Jeff points
out,
the requirements are fuzzy. Is it a requirement that we be able to
locate an
entry from someone's email address? In which case, examples 2, 3, and 4
in
section 1.0 show that the authors expect this to be used in a way that
directly contradict this requirement. Is it a requirement that we help
administrators 'uniquify' their RDNs? Given most LDAP implementations,
they
are forced to uniquify it, and no one way of uniquification is clearly
better than any other.

Taking out the RDN recommendation gives us a document that covers
requirements a, b, c, and d in section 4 (note that RFC 822 addresses do
not
really constitute an 'existing Internet name registry' beyond their use
of
DNS). Requirement e is where the fuzziness comes in: user-friendly *FOR
WHICH USES AND USERS?*. The examples are almost completely drawn from
White
Pages (specifically human client) operations. And the examples are
completely in English, as well. Minimally useful public directories,
even
for the types of applications listed above, may vary wildly depending on
the
data available, the organizational restrictions on public exposure of
data,
the expected user base, and so on. Just as a single example of how this
can
go awry, which of my multiple email addresses should I use as my RDN?
Frankly, requirement e is content-free. And given that, why is the RDN
approach the optimal solution when you haven't even detailed how this is
supposed to be used?

Speaking from the vendor perspective, restricting my customer's ability
to
pick their own naming techniques for RDNs needs to have a damn good
payoff,
which I don't get from either this document or from any of the
statements
the authors have made on the list. In my opinion, progressing the
current
document as it stands will cause the document to be widely ignored. And
that's a shame, as I do think that the IETF needs to really get behind
the
DC naming. I recommend that the document be split into a DC naming
document
and an RDN document, and that we should really look carefully at the RDN
requirements in LSD or another appropriate group. 
Chris


> -----Original Message-----
> From:	[e-mail] [SMTP:[e-mail]]
> Sent:	Wednesday, December 24, 1997 4:49 PM
> To:	[e-mail]
> Cc:	[e-mail]
> Subject:	Re: Last Call: Naming Plan for Internet
Directory-Enabled
> Applications to Proposed Standard
> 
> I don't feel that draft-ietf-ids-dirnaming-03.txt should presently go
> forward 
> on the standards track because, as it is presently written, the
> requirements
> section (sec 3.0) is vague and not thoroughly presented -- thus the
> problem 
> space definition is fuzzy. Additionally, dirnaming-03.txt presents a
> specific
> solution to the problem space, built on top of the fuzzy requirements 
> analysis. My understanding of the IESG's stated position is that we
must
> have 
> well-defined requirements before we can devise reasonable solutions, 
> especially in complex, subtle, and far-reaching problem spaces, such
as 
> directories.
> 
> I believe that the we need to agree on the requirements before moving
> forwards 
> on implementations (i.e. specific plans). A DN requirements document 
> (draft-hodges-ldap-dir-dn-reqs-00.txt) is being currently discussed on
the
> 
> LDAP Service Deployment distribution list <[e-mail]>
and
> will 
> be added to the LSD charter.
> 
> It seems to me that when the IESG has accepted that or another
> requirements 
> document, then it's appropriate for drafts describing specific naming
> plans 
> based upon those requirements to go forward. Until then, I feel the
> dirnaming 
> draft is premature and unlikely to meet the our long-term needs.
> 
> thanks,
> 
> Jeff
> 
 <<Alexis Bor (E-mail).vcf>>