RE: Last Call: Naming Plan for Internet Directory-Enabled Applic ations to Proposed Standard
Chris Weider <cweider@microsoft.com> Tue, 30 December 1997 01:08 UTC
Delivery-Date: Mon, 29 Dec 1997 20:08:32 -0500
Return-Path: cweider@microsoft.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 UAA22122 for <ietf-archive@ietf.org>; Mon, 29 Dec 1997 20:08:30 -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 UAA02986 for <ietf-archive@cnri.reston.va.us>; Mon, 29 Dec 1997 20:11:18 -0500 (EST)
Received: from mail5.microsoft.com (mail5.microsoft.com [131.107.3.31]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id UAA22119 for <iesg@ietf.org>; Mon, 29 Dec 1997 20:08:28 -0500 (EST)
Received: by mail5.microsoft.com with Internet Mail Service (5.5.1960.3) id <ZSG9NJ9K>; Mon, 29 Dec 1997 17:08:30 -0800
Message-ID: <B9D1827FDF66D111925800805F3102E36ECD49@red-msg-57.dns.microsoft.com>
From: Chris Weider <cweider@microsoft.com>
To: "'ietf-ids@umich.edu'" <ietf-ids@umich.edu>, iesg@ns.ietf.org
Subject: RE: Last Call: Naming Plan for Internet Directory-Enabled Applic ations to Proposed Standard
Date: Mon, 29 Dec 1997 17:08:28 -0800
X-Mailer: Internet Mail Service (5.5.1960.3)
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: Jeff.Hodges@Stanford.EDU [SMTP:Jeff.Hodges@Stanford.EDU] > Sent: Wednesday, December 24, 1997 4:49 PM > To: iesg@ietf.org > Cc: ietf-ids@umich.edu > 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 <IETF-LSD@LISTSERV.UMU.SE> 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 >
- RE: Last Call: Naming Plan for Internet Directory… Chris Weider
- RE: Last Call: Naming Plan for Internet Directory… Alexis Bor