reply to comments on draft-ietf-ids-dirnaming-03.txt

Al Grimstad <alg@qsun.ho.att.com> Tue, 30 December 1997 18:42 UTC

Delivery-Date: Tue, 30 Dec 1997 13:42:12 -0500
Return-Path: agrim@qsun.ho.att.com
Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id NAA08708 for <ietf-archive@ietf.org>; Tue, 30 Dec 1997 13:42:11 -0500 (EST)
Received: from ns.ietf.org (ietf.org [132.151.1.19]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id NAA04407 for <ietf-archive@cnri.reston.va.us>; Tue, 30 Dec 1997 13:45:01 -0500 (EST)
Received: from att.com (kcgw1.att.com [192.128.133.151]) by ns.ietf.org (8.8.7/8.8.7a) with SMTP id NAA08705 for <iesg@ietf.org>; Tue, 30 Dec 1997 13:42:09 -0500 (EST)
Received: by kcgw1.att.com; Tue Dec 30 12:38 CST 1997
Received: from hoccson.ho.att.com (hoccson.ho.att.com [135.16.2.30]) by kcig1.att.att.com (AT&T/GW-1.0) with SMTP id MAA18687 for <iesg@ietf.org>; Tue, 30 Dec 1997 12:30:18 -0600 (CST)
Received: from qsun (cafe.ho.att.com) by hoccson.ho.att.com (4.1/EMS-1.1.1 SunOS) id AA00381; Tue, 30 Dec 97 13:46:36 EST
Message-Id: <9712301846.AA00381@hoccson.ho.att.com>
X-Mailer: MH 6.8.3
From: Al Grimstad <alg@qsun.ho.att.com>
To: ietf-ids@umich.edu
Cc: iesg@ns.ietf.org
Subject: reply to comments on draft-ietf-ids-dirnaming-03.txt
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Id: <13508.883507332.1@qsun.att.com>
Date: Tue, 30 Dec 1997 13:42:13 -0500
Sender: agrim@qsun.ho.att.com

Message from Jeff.Hodges@Stanford.EDU 
   of "Wed, 24 Dec 1997 16:49:15 PST."References: <199712250049.QAA12659@Breakaway.Stanford.EDU> 
> 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'm sorry, but I'm afraid we're never going to agree on your degree of
precision and thoroughness. Especially since we're not likely even to
agree to your draft's (draft-hodges-ldap-dir-dn-reqs-00.txt)
requirement "RO", namely the creation of a single Internetwide
Distinguished Name namespace (i.e. DNs as Internet-wide universal
primary keys). Islands of coordinated LDAP servers (i.e. islands of
independent DN namespaces) linked at a higher level via LDAP URLs
(which you could view as primary keys if you like) is pretty much
what's going to happen. Fussing eternally over requirements isn't
going to change that.

Message from Chris Weider <cweider@microsoft.com> 
   of "Mon, 29 Dec 1997 17:08:28 PST."References: <B9D1827FDF66D111925800805F3102E36ECD49@red-msg-57.dns.microsoft.com> 

> 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.

Not quite accurate. The intent was to get beyond cn= naming for
persons which (without use of additional RDN attributes) doesn't scale.
The uid attribute was suggested as another way to go. There is no
constraint in the draft on its format, although suggestions are made.

> 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.

Of course, the whole document is directed toward rapid directory
setup, also expressed as reuse of existing identification schemes. The
dc= bit only solves a tiny fraction of the problem because the data of
interest is almost all below these nodes.

> 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.

If something is not described as a requirement in the draft, then it's
not a requirement. We decided early on not to provide a long list of
non-requirements. Sorry if that's too fuzzy. The business about
locating an entry from an e-mail address is NOT a 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.

This is not a very constructive remark. I can't really believe you
seriously hold it.

> 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).

Gosh, could have fooled me. Possibly the term "registry" is a problem
here. Certainly they form an identification scheme although a given
person isn't limited to one identifier.

 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?

Frankly, the above paragraph is full of cheap shots. We will never,
every get an agreed precise definition of "user friendly". I confess
that we have a strong bias toward humans when it comes to user
friendlyness. The relevant text of the requirement is "Minimally, a
user should be capable of recognizing the information encoded in
his/her own DN. Names that are totally opaque to users cannot meet
this requirement." How can you criticize an Internet Draft for being
written in English? Your remark regarding which of multiple e-mail
addresses has also been discussed to death. First, it doesn't
matter. Second, you won't typically decide. Third, the person
(administrator) making the decision will find it typically much
simpler. And Fourth, the uid doesn't have to be a full e-mail address;
that was only used as an example.

> 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

This seems to indicate that you have no interest in seeing a naming
plan happen, however weak it's suggestions. They would restrict your
customers. In our experience, customers don't want to have the
opportunity to invent a naming plan from whole cloth. In our plan, if
they don't have existing identifiers, we suggest some; if they have
some existing identification plan (typically flat), they can just plug
it into uid attributes below their favorite DNS node. Seems like a
reasonable payoff to me.

Message from Alexis Bor <alexis.bor@directoryworks.com> 
   of "Mon, 29 Dec 1997 18:11:35 PST."References: <41F77E366C97D011B13400609778F568026AE4@smtp.directoryworks.com> 

> 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.

Hey, no one is disagreeing with this observation. Even if you
construct uid values from RFC822 identifiers, you have to address the
issue of folks without them. A company with only a minority of e-mail
users that wants directory entries for all of its people obviously
won't be able to reuse universally allocated e-mail addresses to
automatically create DNs. But they probably do have one or more
universal identification scheme; they could then pick one of them and
plug them into uid attributes for RDNs. Without some guidance,
e.g. from a naming plan, who knows what attribute (or attributes) will
be used for RDNs? Why not use uid (if you're not able to use real
personal names in cn attributes)?

> 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.

This sounds pretty familiar. The intent of the plan is to simplify
name assignment in such a scenario. Suppose the company has registered
the DNS name yoyodyne.com and suppose an employee is assigned the ID
xyz123. Then automatically you've got the DN uid=xyz123, dc=yoyodyne,
dc=com. It's even "minimally user friendly" since the employee in
question undoubtedly knows his/her own company ID. The one thing in
your paragraph that I wouldn't agree elevating to requirement status
is the eternality of DNs. That's been talked about in my personal
experience since day one but nobody has ever has much in the way of
generally applicable solutions to suggest. People just aren't static
enough to keep DNs forever frozen.

> 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.

I don't quite understand what your troubles are.

-- al