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

Jeff.Hodges@stanford.edu Fri, 09 January 1998 09:35 UTC

Delivery-Date: Fri, 09 Jan 1998 04:35:40 -0500
Return-Path: hodges@Wind.Stanford.EDU
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 EAA09427 for <ietf-archive@ietf.org>; Fri, 9 Jan 1998 04:35:39 -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 EAA16168 for <ietf-archive@cnri.reston.va.us>; Fri, 9 Jan 1998 04:38:26 -0500 (EST)
Received: from Wind.Stanford.EDU (wind.Stanford.EDU [36.53.0.147]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id EAA09424 for <iesg@ietf.org>; Fri, 9 Jan 1998 04:35:37 -0500 (EST)
Received: from localhost (hodges@localhost) by Wind.Stanford.EDU (8.8.3/8.8.3) with ESMTP id BAA24423; Fri, 9 Jan 1998 01:35:36 -0800 (PST)
Message-Id: <199801090935.BAA24423@Wind.Stanford.EDU>
X-Mailer: exmh version 2.0zeta 7/24/97
Subject: Re: reply to comments on draft-ietf-ids-dirnaming-03.txt
To: ietf-ids@umich.edu
cc: iesg@ns.ietf.org
In-reply-to: Your message of Tue, 30 Dec 1997 13:42:13 -0500
Reply-to: ietf-ids@umich.edu
From: Jeff.Hodges@stanford.edu
X-Office: Pine Hall Rm 161; +1-415-723-2452
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Fri, 09 Jan 1998 01:35:36 -0800
Sender: hodges@Wind.Stanford.EDU

> from Al Grimstad <alg@qsun.ho.att.com> wrote on Thu, Tue, 30 Dec 1997 13:42:13 -0500..
>
> I'm sorry, but I'm afraid we're never going to agree on your degree of
> 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
> 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). 

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 <cweider@microsoft.com>..
> > 
> > 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.
> 
> from Al Grimstad <alg@qsun.ho.att.com>..
>
> Of course, the whole document is directed toward rapid directory
> 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 <cweider@microsoft.com>..
> > 
> >  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?

> from Al Grimstad <alg@qsun.ho.att.com>..
>
> 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." 

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 <cweider@microsoft.com>..
> > 
> > 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
> 
> from Al Grimstad <alg@qsun.ho.att.com>..
>
> This seems to indicate that you have no interest in seeing a naming
> 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 <alexis.bor@directoryworks.com> on "Mon, 29 Dec 1997 18:11:35 PST..
> > On the RDN requirement:
> > 
> > [..snip..]
> > 
> > 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.
> 
> from Al Grimstad <alg@qsun.ho.att.com>..
>
> [..snip..]
> 
> ..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)? 

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 <alexis.bor@directoryworks.com>
> 
> > 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...
> > 
> > [..snip..]
> > 
> 
> from Al Grimstad <alg@qsun.ho.att.com>..
>
> [..snip..]
>
> 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.

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.