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

[Al Grimstad <[e-mail]>]

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

Good.

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

Your perspective is far, far more ambitious than just agreeing on a
naming plan. It seems to demand an operational coupling between DNS
and LDAP that would go way beyond the scope of the IDS group. The
naming plan is focused on re-use of existing name allocations, DNS and
others. The strange concept that one form of name is somehow "more
resolvable" than another is totally foreign to the intentions document
(and IDS, I presume).

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

In other words, you don't want a naming plan. Can you guarantee that
all future LDAP-enabled software will be written so flexibly that it
will be entirely indifferent to the attributes used for naming? Or are
you simply indifferent to such issues? All the discussion regarding
searching, by the way, is completely off topic. Please check the
requirements section again.

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

First, I'm a bit confused as to the consistency of your position. Do
you want "near complete freedom" or "normative" specifications? In any
case, in the area of naming, what is normative is a very delicate
issue. Recall that the current source for guidance in this area, X.521
Annex B is officially "not a part of the standard,", i.e. not
normative. This document describes additional ways to construct names
to solve problems encountered using the X.521 Annex B (and NADF)
structure of DNs. It does not mandate that everyone use them to the
exclusion of anything else; rather, it extends in a public way the
options in DN construction. Those wanting "near-complete freedom" are
always in a position to define any schema and naming plan they
want. What we are shooting for here is an interoperable extension. 

Second, it would help if you were a bit more specific about the existing
defacto standards you feel have been neglected.

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

Thanks for your comments. -- al

--- Begin Message ---

I should have copied this to the IDS list...

-----Original Message-----
From: Paul Leach <[e-mail]>
To: [e-mail] <[e-mail]>; [e-mail] <[e-mail]>
Date: Thursday, December 18, 1997 10:17 AM
Subject: Re: Last Call: Naming Plan for Internet Directory-Enabled
Applications to Proposed Standard


>
>-----Original Message-----
>From: The IESG <[e-mail]>
>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
>
>
>>
>>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
>>[e-mail] or [e-mail] mailing lists by December 29, 1997.
>>
>>Files can be obtained via
>>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
>

--- End Message ---