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

[Al Grimstad <[e-mail]>]

...
> >I've participated in the ids group, and attempted to provide my input to
> >the authors of the "dirnaming" draft since it was first put before the
> >working group at the Montreal meeting in the summer of 1996.  Since
> >virtually none of my input has been accepted by the authors, I'll voice
> >some of it again here.

With exactly the same effect! :-)

> >- The implied goal of the naming plan is to create an infrastructure
> >that provides an algorithmic mapping from an object's email address to
> >that same object's directory entry.  It is not clear that there is any
> >evidence that this is a requirement, or even a good thing.  To my mind
> >it is more than likely a bad thing.  For example, if I pay money, and am
> >issued a certificate that contains a distinguished name, I would want
> >this distinguished name to be valid, for several different email
> >address, and indeed, continue to be valid, even when my email address
> >changes.  A significantly more flexible arrangement has already been
> >proposed in Ryan Moats' drafts for finding (see
> >http://info.internet.isi.edu:80/in-drafts/files/draft-moats-client-finding-
> 00.txt)

The premises of the paragraph are not correct, so there's no point
refuting the conclusions.

> >- Email address structures are normally flat, so that they can be easily
> >remembered, e.g. [e-mail].  Directory name structures, are normally
> >hierarchical, so that they can be used to distribute directory
> >administration responsibility, among other reasons, e.g. uid=fred,
> >ou=division x, ou=san jose, o=acme computers, l=california, c=us.  It is
> >not clear that tying the two structured name forms together is possible
> >in general, and even when it can be done, it is equally unclear whether
> >anything has actually been accomplished.

If you were to consult the ID, you'd notice that our main issue was to
enable the re-use of existing name registries such as (but not
restricted to) DNS. We note that real registries for the name form you
indicate are either highly problematic (ANSI for children of c=US) or
non-existent (children of l=California). You have no interest in this
issue. Nothing in the plan prohibits building entries under ou=San
Jose, dc=acme, dc=com by the way.

> >- The naming plan uses dns names for directory containers, even though
> >there is no requirement in LDAP that containers actually have any
> >relationship to a dns host.  Many organizational internet directories
> >have created (and will be forced by a variety of internal access control
> >requirements) an elaborate hierarchical infrastructure, with many
> >levels.  In order to conform to this infrastructure, the directory
> >administration would have to come up with host names for each of these
> >containers in the directory, which will more than likely never actually
> >be used as an internet host.  We are creating an artificial
> >infrastructure for no perceptable gain.

There is some confusion here. There is really no law that a DNS name
refer to a host to my knowledge and there are plenty that don't.

> >- As the author's have admitted the naming plan is not interoperable
> >with the existing naming infrastructures (e.g. the NADF
> >recommendations), which means that the auxiliary object class defined in
> >the draft can't be applied to an existing directory hierarchy.  It seems
> >to me that with a little thought that a mechanism could be defined which
> >allows this new proposed naming plan to coexist with other existing and
> >future naming plans.  Any naming plan that is not interoperable, should
> >not be given even the slightest consideration along the standards track.

Who made such an admission? We have said that the NADF plan has severe
practical problems. But if you have directory servers (e.g. X.500
DSAs) using this form of name, there is no technical reason I am aware
of that would not also permit coexistence and interoperability
additional directory data named according to the ID.

> >- I agree completely with the remarks that Mr. Alvestrand made at the
> >San Jose IDS meeting in the discussion of a previous version of this
> >draft when he indicated (and I paraphrase) that any naming plan which
> >forces distinguished names to have any particular meaning is "EVIL".
> >The Internet must allow directory administrators to build their
> >infrastructures in whatever way seems appropriate for there particular
> >corner of the Internet, while at the same time providing some level of
> >guidance for the contruction of their infrastructure.

The ID attempts to provide guidance to directory administrators who
find the NADF approach unworkable. It does not prohibit that approach.

> >- In his talk at one of the ids WG meetings, one of the principal
> >authors (Mr. Sataluri) indicated that his company had built an
> >unsuccessful directory offering, and that he believed that the main
> >reason for its failing was the fact that the NADF naming plan was
> >inadequate in its reliance on the civil infrastructure, and if only
> >there had been a naming plan like this, AT&T's (X.500) offering would
> >have been successful.  Internet directories will prolieferate in spite
> >of naming plans, and other shortsighted efforts like it, rather then
> >because of them

Very inspiring.

> >- I don't understand why a naming plan that allows directory
> >adminstrators to use the top level internet assigned host name as the
> >top level in their directory hierachies is not a sufficient solution to
> >the problem of the "Internet Naming Plan".  The IETF should be able to
> >define its top level of its directory tree as "ou=ietf.org, o=internet"
> >since they own the ietf.org host name.  It seems to me that just saying
> >this solve most of the problem that the naming plan is attempting to
> >solve.

This is really quite hopeless. Why don't you admit that your agenda is
to force fit anything whatsoever into a rigid set of naming
attributes, namely cn, ou, o, l and c? Would it be "evil" for a naming
attribute to have meaning? 

-- al

--- Begin Message ---

As long as people are posting there notes on this that went to the iesg on
this issue.  Here's what I wrote:

>Subject: Re: Last Call: Naming Plan for Internet Directory-Enabled
Applications to Proposed Standard
>Date: Mon, 22 Dec 1997 23:31:08 -0800
>From: Bruce Greenblatt <[e-mail]>
>To: [e-mail], [e-mail]
>CC: Jeff Hodges <[e-mail]>,
>     Harald T Alvestrand <[e-mail]>
>
>I've participated in the ids group, and attempted to provide my input to
>the authors of the "dirnaming" draft since it was first put before the
>working group at the Montreal meeting in the summer of 1996.  Since
>virtually none of my input has been accepted by the authors, I'll voice
>some of it again here.
>
>- The implied goal of the naming plan is to create an infrastructure
>that provides an algorithmic mapping from an object's email address to
>that same object's directory entry.  It is not clear that there is any
>evidence that this is a requirement, or even a good thing.  To my mind
>it is more than likely a bad thing.  For example, if I pay money, and am
>issued a certificate that contains a distinguished name, I would want
>this distinguished name to be valid, for several different email
>address, and indeed, continue to be valid, even when my email address
>changes.  A significantly more flexible arrangement has already been
>proposed in Ryan Moats' drafts for finding (see
>http://info.internet.isi.edu:80/in-drafts/files/draft-moats-client-finding-
00.txt)
>
>- Email address structures are normally flat, so that they can be easily
>remembered, e.g. [e-mail].  Directory name structures, are normally
>hierarchical, so that they can be used to distribute directory
>administration responsibility, among other reasons, e.g. uid=fred,
>ou=division x, ou=san jose, o=acme computers, l=california, c=us.  It is
>not clear that tying the two structured name forms together is possible
>in general, and even when it can be done, it is equally unclear whether
>anything has actually been accomplished.
>
>- The naming plan uses dns names for directory containers, even though
>there is no requirement in LDAP that containers actually have any
>relationship to a dns host.  Many organizational internet directories
>have created (and will be forced by a variety of internal access control
>requirements) an elaborate hierarchical infrastructure, with many
>levels.  In order to conform to this infrastructure, the directory
>administration would have to come up with host names for each of these
>containers in the directory, which will more than likely never actually
>be used as an internet host.  We are creating an artificial
>infrastructure for no perceptable gain.
>
>- As the author's have admitted the naming plan is not interoperable
>with the existing naming infrastructures (e.g. the NADF
>recommendations), which means that the auxiliary object class defined in
>the draft can't be applied to an existing directory hierarchy.  It seems
>to me that with a little thought that a mechanism could be defined which
>allows this new proposed naming plan to coexist with other existing and
>future naming plans.  Any naming plan that is not interoperable, should
>not be given even the slightest consideration along the standards track.
>
>- I agree completely with the remarks that Mr. Alvestrand made at the
>San Jose IDS meeting in the discussion of a previous version of this
>draft when he indicated (and I paraphrase) that any naming plan which
>forces distinguished names to have any particular meaning is "EVIL".
>The Internet must allow directory administrators to build their
>infrastructures in whatever way seems appropriate for there particular
>corner of the Internet, while at the same time providing some level of
>guidance for the contruction of their infrastructure.
>
>- In his talk at one of the ids WG meetings, one of the principal
>authors (Mr. Sataluri) indicated that his company had built an
>unsuccessful directory offering, and that he believed that the main
>reason for its failing was the fact that the NADF naming plan was
>inadequate in its reliance on the civil infrastructure, and if only
>there had been a naming plan like this, AT&T's (X.500) offering would
>have been successful.  Internet directories will prolieferate in spite
>of naming plans, and other shortsighted efforts like it, rather then
>because of them
>
>- I don't understand why a naming plan that allows directory
>adminstrators to use the top level internet assigned host name as the
>top level in their directory hierachies is not a sufficient solution to
>the problem of the "Internet Naming Plan".  The IETF should be able to
>define its top level of its directory tree as "ou=ietf.org, o=internet"
>since they own the ietf.org host name.  It seems to me that just saying
>this solve most of the problem that the naming plan is attempting to
>solve.
>
>Thanks for your consideration.
>
>Bruce Greenblatt
>
>The IESG wrote:
>>
>> 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-02.txt
>
================================================
Bruce Greenblatt              [e-mail]
http://www.innetix.com/~bruceg
================================================

--- End Message ---