Subject: Last Call: Naming Plan for Internet Directory-Enabled Applications to Proposed Standard

From: The IESG <[email-masked]>
Date: Tue, 16 Dec 1997 15:03:58 -0500

Note: The previous Last Call notice referred to an incorrect document
      version number.
======================

The IESG has received a request from the Integrated Directory Services
Working Group to consider Naming Plan for Internet Directory-Enabled
Applications <draft-ietf-ids-dirnaming-03.txt> as a Proposed Standard.

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send any comments to the
[email-masked] or [email-masked] mailing lists by December 29, 1997.

Files can be obtained via
ftp://ds.internic.net/internet-drafts/draft-ietf-ids-dirnaming-03.txt

---

From: "Paul Leach" <[email-masked]>
Date: Thu, 18 Dec 1997 10:17:45 -0800

-----Original Message-----
From: The IESG <[email-masked]>
To: IETF-Announce: ; <IETF-Announce: ;>
Date: Tuesday, December 16, 1997 12:10 PM
Subject: Last Call: Naming Plan for Internet Directory-Enabled Applications
to Proposed Standard

>ftp://ds.internic.net/internet-drafts/draft-ietf-ids-dirnaming-03.txt

First, we like the general direction inherent in the use of the "dc"
component to construct DNs that parallel the DNS naming hierarchy. This is
an extremely practical way to leverage an existing deployed resolution and
registration infrastructure.

However, we have several issues with the proposal:
1. It does not specify that one may expect to be able to resolve DNs ending
with "dc" components by resolving the corresponding DNS name to locate an
LDAP server that can then finish the DN resolution. This is an absolutely
essential piece of the picture.. We believe that this usage is implicit, but
that it should be made explicit. Absent a defined resolution mechanism, "dc"
names are no more resolvable than the "o=x,c=y" flavor.

2. It proposes a way to construct DNs of various objects via the use of
"uid" and "cn" components as RDNs. We believe it instead should propose a
way to search for these objects via those attributes, which may or may not
be RDNs. We believe that this is both more useful and more flexible.  More
useful, in that a common scenario will be to know the e-mail address of a
person, and want to find other attributes (e.g., a certificate); the
proposal does not provide any help in this scenario. More flexible, in that
it does not constrain the DNs of the objects -- especially since such
constraints are not really needed.  Our experience with large numbers of
organizations is that the way they structure their name space is is very
dependent on organization dynamics, and they insist on near-complete freedom
in this regard.

3. It is not clear which sections are normative. For example, schema
definitions which seem to be needed for interoperabilty are defined in
section 5, which is entitled "Implementation Issues". The same section also
describes requirements on the subject name DN in SSL certificates that is in
conflict with existing defacto standards. If the described mechanism is
desirable, then it assuredly must be clearly declared to be normative to
have any hope of effecting a change in the existing procedures.

As a result, we would suggest that these problems be fixed before proceeding
to Proposed Standard.

Paul

---

From: "Paul Leach" <[email-masked]>
Date: Thu, 18 Dec 1997 10:17:45 -0800

-----Original Message-----
From: The IESG <[email-masked]>
To: IETF-Announce: ; <IETF-Announce: ;>
Date: Tuesday, December 16, 1997 12:10 PM
Subject: Last Call: Naming Plan for Internet Directory-Enabled Applications
to Proposed Standard

Paul