[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
RE: [ldapext] Directory Best Practice Guide
- To: "'Jim Willeke'" <jim@willeke.com>, "'Chris Harding'" <c.harding@opengroup.org>
- Subject: RE: [ldapext] Directory Best Practice Guide
- From: "Chris Apple" <capple@dsi-consulting.net>
- Date: Wed, 21 Aug 2002 11:45:07 -0400
- Cc: <christine.yoon@us.pwcglobal.com>, <ldapext@ietf.org>, "'Liben, Michael \(GTS\)'" <mliben@exchange.ml.com>, <dif-members@opengroup.org>, <michael.d.compton@us.pwcglobal.com>, <jamie.quick@us.pwcglobal.com>, <brian.jensen@us.pwcglobal.com>
- Importance: Normal
- In-reply-to: <3D5CD1BE.3050801@willeke.com>
- Organization: DSI-Consulting, Inc.
Ditto. I'm in.
Chris Apple - Principal Architect
DSI Consulting, Inc.
http://www.dsi-consulting.com
mailto:capple@dsi-consulting.net
-----Original Message-----
From: ldapext-admin@ietf.org [mailto:ldapext-admin@ietf.org] On Behalf
Of Jim Willeke
Sent: Friday, August 16, 2002 6:20 AM
To: Chris Harding
Cc: christine.yoon@us.pwcglobal.com; ldapext@ietf.org; 'Liben, Michael
(GTS)'; dif-members@opengroup.org; michael.d.compton@us.pwcglobal.com;
jamie.quick@us.pwcglobal.com; brian.jensen@us.pwcglobal.com
Subject: Re: [ldapext] Directory Best Practice Guide
I'm In.
-jim
http://www.directory-info.com/
Chris Harding wrote:
> Hi, Christine -
>
> That's great! We need lots more volunteers, though. How about it,
folks?
>
> At 10:40 15/08/2002 -0400, christine.yoon@us.pwcglobal.com wrote:
>
>> Chris,
>>
>> We (PwC) have many years of experience in directory/security
>> implementation for various clients including Fortune 500 companies.
>> I would like to volunteer to author the Directory Best Practice
Guide.
>>
>>
>> -Christine Yoon
>> PricewaterhouseCoopers
>> (201)981-1172 - cell
>> (732)706-3559 - office
>>
>>
>>
>>
>>
>> Chris Harding
>> <c.harding@opengro To: "Alexis Bor"
>> <alexis.bor@directoryworks.com>
>> up.org> cc:
>> <ldapext@ietf.org>, "'Liben, Michael \(GTS\)'"
>> <mliben@exchange.ml.com>, "'Patrik
>> Sent by: Fältström'"
>> <paf@cisco.com>, dif-members@opengroup.org
>> ldapext-admin@ietf Subject: RE:
>> [ldapext] draft-ietf-ldapext-locate
>> .org
>> 08/15/2002 06:20
>> AM
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> Hi, Alexis -
>>
>> A Directory Best Practices Guide is something that is clearly needed.
I
>> believe that the Directory Interoperability Forum should support its
>> creation and contribute to it. The DIF could for example provide
>> publication or web page hosting facilities if needed, and could
provide
>> some review effort. However, I don't believe that the DIF could on
>> its own
>> provide the technical authoring and review effort needed to deliver
an
>> authoritative guide.
>>
>> Because there is (as you point out) a need for rapid evolution, a set
of
>> web pages would be far and away the best medium for such a guide.
>> What we
>> need is a set of contributors, a review group, and an editorial
>> committee,
>> working within the framework of an established review and
publications
>> procedure. This procedure must be public and must allow rapid
turnaround
>> from authoring to publication - I would say within 2 months at the
>> outside.
>>
>> Perhaps it could be handled as a kind of Open Source project.
>>
>> I believe (the members make the decisions, I just support them) that
the
>> DIF would be interested in co-ordinating or participating in a
>> project of
>> this nature.
>>
>> At 16:00 14/08/2002 -0400, Alexis Bor wrote:
>> >I proved to myself and others (while I was at Boeing doing R&D work
in
>> >Directory) back in 1992 that putting any meaning into a DN is not a
>> good
>> >practice. We took the example of a company of 100,000 and looked at
the
>> >different approaches for DN's - Geographic, Political, Hybrid and
>> >others.
>> >
>> >It became clear that it would be a maintenance headache and cause
lots
>> >of stress on the overall infrastructure. It was very hard to
convince
>> >most people for a long time until some work that Jeff Hodges did at
>> >Stanford got a lot of attention in the late 90's.
>> >
>> >A real hard piece of work to put forward is a best practices
document.
>> >The number of opinions will typically exceed the number of people
>> >working on the document. What we learned in the mid 90's was that
such
>> >a document evolves faster than the review cycle (part of an EMA
effort
>> >to write a white paper on directory best practices), making it out
of
>> >date before you even finish the review of it. However, with all of
the
>> >experience that everyone is getting, it may be worth resurrecting
the
>> >idea again.
>> >
>> >Perhaps an industry group can step up to the challenge - any takers?
>> >
>> >-- Alexis
>> >
>> >Alexis Bor
>> >Directory Works, Inc.
>> >www.directoryworks.com
>> >
>> >
>> >-----Original Message-----
>> >From: ldapext-admin@ietf.org [mailto:ldapext-admin@ietf.org] On
Behalf
>> >Of Liben, Michael (GTS)
>> >Sent: Tuesday, August 13, 2002 5:32 PM
>> >To: 'Patrik Fältström'
>> >Cc: ldapext@ietf.org
>> >Subject: RE: [ldapext] draft-ietf-ldapext-locate
>> >
>> >In general, divining any meaning from a distinguished name is not
good
>> >practice (my $.02). The implications are that your app will likely
>> >break. The SHOULD NOT allows you impart meaning to your
>> >distinguished name if you so choose. A MUST NOT would be an absolute
>> >prohibition.
>> >
>> >
>> >
>> >-----Original Message-----
>> >From: Patrik Fältström [mailto:paf@cisco.com]
>> >Sent: Tuesday, August 13, 2002 5:54 AM
>> >To: micharm@microsoft.com; paulle@microsoft.com;
levone@microsoft.com;
>> >rlmorgan@washington.edu
>> >Cc: ldapext@ietf.org; Ned Freed; ietf-ldap@paf.se
>> >Subject: [ldapext] draft-ietf-ldapext-locate
>> >
>> >Comments from the IESG:
>> >-------
>> >The document says:
>> > If there are no
>> > matching SRV records available for the converted DN the
client
>> >SHOULD
>> > NOT attempt to 'walk the tree' by removing the least
significant
>> > portion of the constructed fully qualified domain name.
>> >
>> >The meaning of "SHOULD NOT" is "don't do this unless you understand
the
>> >implications". Well, I don't know where to look to understand the
>> >implications.
>> >Thus I think it would be useful to either make it a MUST NOT, or
>> explain
>> >something about the implications of using shorter labels.
>> >
>> >Alternatively specify SHOULD NOT do this in general, but MUST NOT
ever
>> >use this with just one label (i.e. MUST NOT look for
_ldap._tcp.<TLD>)
>> >or something similar.
>> >
>> >-------
>> >The document is unclear (see next note) on:
>> >
>> >(a) When this is to be used (only when not having the foggiest clue
>> >where a
>> >record with a specific DN is, or every time a record is to be
>> accessed?)
>> >
>> >(b) How to handle the case when one have a DN which have both dc and
>> >non-dc
>> >components. Example of this is when two records stored on two
different
>> >servers share the same dc components. IF those records per
definition
>> >(of
>> >this document) have to be stored on the same server, or referrals
have
>> >to
>> >be stored on them to point to the other, then this document has a
scope
>> >which is larger than at first glance. I.e. part from stating how to
>> >locate
>> >a record using DNS, it also has an implicit result that DC is _the_
>> >naming
>> >convention for the Internet. Please explain.
>> >
>> >-------
>> >This document define a conversion that is over-restrictive.
>> >
>> > The output domain name is initially empty. The DN is
processed
>> >in
>> > right-to-left order (i.e., beginning with the first RDN in
the
>> > sequence of RDNs). An RDN is able to be converted if it (1)
>> > consists of a single AttributeTypeAndValue; (2) the
attribute
>> >type
>> > is "DC"; and (3) the attribute value is non-null. If it can
be
>> > converted, the attribute value is used as a domain name
>> >component
>> > (label). The first such value becomes the rightmost (i.e.,
>> most
>> > significant) domain name component, and successive
>> converted RDN
>> > values extend to the left. If an RDN cannot be converted,
>> > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> > processing stops. If the output domain name is empty when
>> > ^^^^^^^^^^^^^^^^^
>> > processing stops, the DN cannot be converted into a domain
>> name.
>> >
>> >The underscored text should be removed and replaced with text that
>> >states the non-DC RDN's are skipped over. So for example the DN:
>> >
>> > cn=Jeffrey Schiller,ou=LEES
Laboratory,dc=lees,o=MIT,dc=mit,
>> > dc=edu
>> >
>> >Can be unambiguously translated into:
>> >
>> > lees.mit.edu
>> >
>> >Yet the underscored words make this translation invalid. With the
>> >Underscored rule in place this DN would convert to just 'mit.edu'
>> >which is not the desired result.
>> >
>> >The additional flexibility offered will permit us to convert
existing
>> >PKI systems to make use of this feature without requiring all
>> >certificates to be re-issued. It will also permit us to create DIT's
>> >that can be delegated at more points rather then requiring all
>> >structure to be at the very top where the DC components are, prior
to
>> >any non-DC component.
>> >
>> >For example if MIT had a DIT with a top level name of:
>> >
>> > o=MIT,c=US
>> >
>> >and a subordinate lab wanted to use this document, they could have a
>> >delegated subtree like:
>> >
>> > ou=Lab for X,o=MIT,c=US
>> >
>> >and then add a DC component below this as:
>> >
>> > dc=labx,dc=mit,dc=edu,ou=Lab for X,o=MIT,c=US
>> >
>> >Under my more flexible approach this would work. Without the
>> >flexibility they would be SOL until MIT redid its entire DIT to
>> >be:
>> >
>> > o=MIT,c=US,dc=mit,dc=edu
>> >
>> >and then they would have to be jointed in as:
>> >
>> > o=MIT,c=US,dc=labx,dc=mit,dc=edu
>> >
>> >Ned: I have three concerns here:
>> >
>> >(0) It isn't clear when this approach is supposed to be used. DNs
are an
>> > integral part of *every* LDAP operation. Is it the intent
that
>> >an
>> >LDAP
>> > client check every DN it sees for DC fields and if it finds
>> them
>> >use
>> > this approach. Or is it only appropriate in specific
>> situations?
>> >
>> >(1) This document specifies two things: How to translate a DN to a
DNS
>> > name and how to use a DNS name to locate a corresponding
LDAP
>> >server.
>> > The document seems to imply that the latter is only used
when a
>> >DNS
>> > name is produced by the former. I wonder if this
restriction is
>> >a
>> >good
>> > idea: Isn't the ability to use SRV records to locate more
>> >generally
>> > useful than this limited context?
>> >
>> > The answer to this may be no, but if so, the rationale for
>> that
>> >answer
>> > should be part of the specification.
>> >
>> >(2) I don't see any provision for fallback to A records if SRV
records
>> > don't exist. I can easily see this being a Bad Idea, if so,
>> >there
>> > should be an explicit prohibition of it in the document
along
>> >with
>> > some explanation of why it is a bad idea.
>> >
>> >
>> >
>> >-------
>> >References should be split in normative and non-normative.
>> >-------
>> >I wonder about the reference to RFC1700, which has been obsoleted
>> >by RFC3232, and that RFC actuallt talks about a DB that contains
>> >the info. So How should this doc refer to that?
>> >-------
>> >Needs better abstract; doesn't even use the word "SRV". (and the rfc
>> >editor will surely complain when they get it...)
>> >
>> >Might be good to use SRV in the title as well, as opposed to just
>> >"DNS". But this I'm less concerned about, as there are two steps,
and
>> >only the second step is SRV records.
>> >
>> >E.g., maybe change:
>> >
>> > Discovering LDAP Services with DNS
>> >
>> >To something like:
>> >
>> > Discovering LDAP Services with DNS SRV Resource Records
>> >
>> >However, the rfc editor probably won't like the abbreviation
>> >"SRV". Unfortunately, I don't think the acronym expands into
anything
>> >useful.
>> >-------
>> >I have three concerns here:
>> >
>> >(0) It isn't clear when this approach is supposed to be used. DNs
are an
>> > integral part of *every* LDAP operation. Is it the intent that
an
>> >LDAP
>> > client check every DN it sees for DC fields and if it finds
>> them use
>> > this approach. Or is it only appropriate in specific
situations?
>> >
>> >(1) This document specifies two things: How to translate a DN to a
DNS
>> > name and how to use a DNS name to locate a corresponding LDAP
>> >server.
>> > The document seems to imply that the latter is only used when a
DNS
>> > name is produced by the former. I wonder if this restriction is
a
>> >good
>> > idea: Isn't the ability to use SRV records to locate more
>> generally
>> > useful than this limited context?
>> >
>> > The answer to this may be no, but if so, the rationale for that
>> >answer
>> > should be part of the specification.
>> >
>> >(2) I don't see any provision for fallback to A records if SRV
records
>> > don't exist. I can easily see this being a Bad Idea, if so,
there
>> > should be an explicit prohibition of it in the document along
with
>> > some explanation of why it is a bad idea.
>> >
>> >
>> >
>> >
>> >
>> >_______________________________________________
>> >Ldapext mailing list
>> >Ldapext@ietf.org
>> >https://www1.ietf.org/mailman/listinfo/ldapext
>> >
>> >
>> >_______________________________________________
>> >Ldapext mailing list
>> >Ldapext@ietf.org
>> >https://www1.ietf.org/mailman/listinfo/ldapext
>> >
>> >
>> >
>> >_______________________________________________
>> >Ldapext mailing list
>> >Ldapext@ietf.org
>> >https://www1.ietf.org/mailman/listinfo/ldapext
>>
>>
>> Regards,
>>
>> Chris
>> +++++
>>
>>
========================================================================
>> Dr. Christopher J. Harding
>> T H E Executive Director for the Directory Interoperability
Forum
>> O P E N Apex Plaza, Forbury Road, Reading RG1 1AX, UK
>> G R O U P Mailto:c.harding@opengroup.org Phone: +44 118 902 3018
>> WWW: http://www.opengroup.org Mobile: +44 774 063 1520
>>
========================================================================
>> The Open Group Conference
>> Boundaryless Information Flow: The Role of Open Source
>> Cannes, France, 14-18th October
>> http://www.opengroup.org/cannes2002
>>
========================================================================
>>
>>
>> _______________________________________________
>> Ldapext mailing list
>> Ldapext@ietf.org
>> https://www1.ietf.org/mailman/listinfo/ldapext
>>
>>
>>
>>
>> _________________________________________________________________
>> The information transmitted is intended only for the person
or
>> entity to which it is addressed and may contain confidential
>> and/or privileged material. Any review, retransmission,
>> dissemination or other use of, or taking of any action in
>> reliance
>> upon, this information by persons or entities other than the
>> intended recipient is prohibited. If you received this in
>> error,
>> please contact the sender and delete the material from any
>> computer.
>>
>>
>> _______________________________________________
>> Ldapext mailing list
>> Ldapext@ietf.org
>> https://www1.ietf.org/mailman/listinfo/ldapext
>
>
>
> Regards,
>
> Chris
> +++++
>
>
========================================================================
> Dr. Christopher J. Harding
> T H E Executive Director for the Directory Interoperability Forum
> O P E N Apex Plaza, Forbury Road, Reading RG1 1AX, UK
> G R O U P Mailto:c.harding@opengroup.org Phone: +44 118 902 3018
> WWW: http://www.opengroup.org Mobile: +44 774 063 1520
>
========================================================================
> The Open Group Conference
> Boundaryless Information Flow: The Role of Open Source
> Cannes, France, 14-18th October
> http://www.opengroup.org/cannes2002
>
========================================================================
>
>
> _______________________________________________
> Ldapext mailing list
> Ldapext@ietf.org
> https://www1.ietf.org/mailman/listinfo/ldapext
>
_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www1.ietf.org/mailman/listinfo/ldapext
_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www1.ietf.org/mailman/listinfo/ldapext