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

From: Al Grimstad <[email-masked]>
Date: Tue, 30 Dec 1997 13:42:13 -0500

Message from [email-masked] 
   of "Wed, 24 Dec 1997 16:49:15 PST."References: <[email-masked]> 
> 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 <[email-masked]> 
   of "Mon, 29 Dec 1997 17:08:28 PST."References: <[email-masked]> 

> 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 <[email-masked]> 
   of "Mon, 29 Dec 1997 18:11:35 PST."References: <[email-masked]> 

> 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

---

From: [email-masked]
Date: Fri, 09 Jan 1998 01:35:36 -0800

> from Al Grimstad <[email-masked]> wrote on Thu, Tue, 30 Dec 1997 13:42:13 -0500..
>
> precision and thoroughness. 

It's not simply my level of precision and thoroughness we're dealing with 
here, ultimately it's the IESG's. It's my understanding that recent history 
shows that in tricky areas the IESG has been requesting concrete 
requirements/models docs be written before they consider solutions docs. 
Specific recent examples are from the fax and calendaring working groups..

  draft-ietf-fax-goals-01.txt 
  draft-ietf-calsch-mod-03.txt

> Especially since we're not likely even to
> primary keys). 

This statement seems to be the result of a gross miss-reading of the cited 
dn-reqs-00 draft. The req in question, R1.0 (not "R0", there's no such req), 
doesn't have anything to do with a "single Internetwide Distinguished Name 
namespace".

> Fussing eternally over requirements isn't going to change [how things 
> are going to end up working]

I don't believe that nailing down requirements necessitates "fussing 
eternally". The two docs referenced above are cases in point.

I believe that unless we come to a common, documented understanding on some 
simple, crisp requirements for the problem space, we're only going to have 
fuzzy, poorly-formed solutions to fuzzy, poorly-understood problem spaces.

[..snip..]

> > from Chris Weider <[email-masked]>..
> > 
> from Al Grimstad <[email-masked]>..
>
> setup, also expressed as reuse of existing identification schemes. 

I agree with Chris and Al that "dc"-based DNs are a good thing. But I disagree 
that..

> The dc= bit only solves a tiny fraction of the problem because the data 
> of interest is almost all below these nodes.

I think the dc-based scheme solves a quite large portion of the problem space, 
and that the RDN-specific aspect is less of an issue. Having unique RDNs is a 
site-specific issue, having DNs that are going to be assuredly unique when one 
loosely-couples-up with other parties' directory or indexing services is the 
salient issue.

[..snip..]

> > from Chris Weider <[email-masked]>..
> > 

> from Al Grimstad <[email-masked]>..
>
> this requirement." 

I agree with Chris that this "requirement" on "user friendliness" is highly 
subjective and thus inappropriate for inclusion in a requirements statement.

As an aside, the DNs we will be utilizing in our next directory service rev 
here at Stanford will NOT meet your interpretation of this "requirement" (more 
about this in an accompanying msg). And I firmly believe it won't be a problem 
-- because I don't have any hard evidence that it is a requirement, given the 
manner in which our, and store-bought, tools will utilize the directory.

[..snip..]

> > from Chris Weider <[email-masked]>..
> > 
> from Al Grimstad <[email-masked]>..
>
> plan happen, however weak it's suggestions. 

No, I don't agree. We want to enable having "naming plans" (plural on purpose) 
that are based on concrete requirements.

We feel that *RDN assignment*, in particular, is a site-specific issue, one 
that the IETF might perhaps provide some tutorial guidance and loose 
conventions for, but for which the standards track is inappropriate.

> ... In our experience, customers don't want to have the
> opportunity to invent a naming plan from whole cloth. 

I believe that may be true for small workgroups and companies, but not for 
larger enterprises.  For example, our directory here at Stanford will 
not be following dirnaming-03 in terms of RDNs, though we will be utilizing 
dc-based DNs.

> from Alexis Bor <[email-masked]> on "Mon, 29 Dec 1997 18:11:35 PST..
> > On the RDN requirement:
> > 
> > [..snip..]
> > 
> > Most companies that do manufacturing do not have email
> from Al Grimstad <[email-masked]>..
>
> [..snip..]
> 
> ..plug them into uid attributes for RDNs. Without some guidance,

First, in terms of the word "guidance" -- that's all we, the IETF, should be 
providing in terms of RDNs -- guidance (IMHO). I don't feel that we should be 
trying to annoint any one of the many possible approaches to RDN assignment as 
"standards track". It's up to each site to determine what's "workable" for 
them.

Second, I don't believe it is a matter of standardization what attribute is 
used as the RDN for any given site's entries. We're going to invent our own 
for our directory here at Stanford, for example. If a site picks an attribute 
that's inappropriate for some reason, the size of the value for instance, then 
their directory isn't going to work well, but that's a site-specific problem. 
>From the outside, it just means that they won't be able to participate very 
well in wider general directory service contexts that they may belong to.

Seems that from what I understand of the IESG's "thou shalt interoperate" 
perspective, that this might be a problem. But, it also seems to me that this 
concern might be cast as a requirement like..

  Site-specific RDN naming plans SHOULD utilize attributes for RDNs whose  
  upper size limits for values are within the general limits shown in table 
  such-and-such. This helps assure interoperability between well-known 
  directory server and client implementations. 

..which can be included in a "Guidelines for creating your RDN Naming Plan" 
doc that we might do (i.e. dirnaming-03 might conceivably morph into such). In 
other words, I think we can, and should, only say something like..

  If you do things this way, you'll get these results, which might be better
  than if you do things this other way. 

> from Alexis Bor <[email-masked]>
> 
> > of their entries into one branch of the directory tree...
> > 
> > [..snip..]
> > 
> 
> from Al Grimstad <[email-masked]>..
>
> [..snip..]
>
> The one thing in

I think Alexis is exactly right, and I disagree that "nobody has ever has much 
in the way of generally applicable solutions to suggest". Having unchanging 
DNs is as easy for a site as it is to assign unchanging, non-reuseable 
employee ID numbers, as we do here at Stanford or on my driver's license 
(Calif), or as Alexis has pointed out in past messages (see the ietf-IDS 
archive).

For example, we're planning that DNs in Stanford's next directory rev will be 
unchanging, non-reusable, and assigned for life. If a person leaves the 
University and then returns at a later date, they'll have the same DN. If the 
person's name changes, they'll have the same DN, etc.

In summary, I feel that..

  * dc-based DNs, unto themselves, are a Good Thing, though NOT 
    the Only Thing. 

But, I also feel that..

  * nailing down a crisp definition of the DN problem space and its resultant 
    requirements is worthwhile, and in fact necessary, and..
    
  * ~standardizing~ a particular Internet-wide approach to RDN assignment is 
    not worthwhile (note that I'm aware that "standardizing" is not 
    necessarily the same as "mandating"), though..

  * providing informational guidelines describing ~several different~
    approaches to, and the significance/benefits/costs of, RDN assignment, is 
    likely to be worthwhile, 

..and that..

  * dirnaming-03 doesn't sufficiently satisfy these points, and so I
    can't support it as it is presently constituted. 

thanks,

Jeff

ps: I'll accompany this message with another describing more about our DN plan 
and with a pointer to a test directory where it's implemented.