[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
RE: [ldapext] Directory Best Practice Guide
- To: "Chris Harding" <c.harding@opengroup.org>, <christine.yoon@us.pwcglobal.com>
- Subject: RE: [ldapext] Directory Best Practice Guide
- From: "Howard Chu" <hyc@highlandsun.com>
- Date: Thu, 15 Aug 2002 11:05:03 -0700
- Cc: <ldapext@ietf.org>, "'Liben, Michael \(GTS\)'" <mliben@exchange.ml.com>, "'Patrik Fältström'" <paf@cisco.com>, <dif-members@opengroup.org>, <michael.d.compton@us.pwcglobal.com>, <jamie.quick@us.pwcglobal.com>, <brian.jensen@us.pwcglobal.com>, "Alexis Bor" <alexis.bor@directoryworks.com>
- Importance: Normal
- In-reply-to: <5.1.0.14.1.20020815174302.00b06740@mailhome.rdg.opengroup.org>
I work with the OpenLDAP project and would be happy to contribute.
-- Howard Chu
Chief Architect, Symas Corp. Director, Highland Sun
http://www.symas.com http://highlandsun.com/hyc
Symas: Premier OpenSource Development and Support
> -----Original Message-----
> From: ldapext-admin@ietf.org [mailto:ldapext-admin@ietf.org]On Behalf Of
> Chris Harding
> Sent: Thursday, August 15, 2002 9:45 AM
> To: christine.yoon@us.pwcglobal.com
> Cc: ldapext@ietf.org; 'Liben, Michael (GTS)'; 'Patrik Fältström';
> dif-members@opengroup.org; michael.d.compton@us.pwcglobal.com;
> jamie.quick@us.pwcglobal.com; brian.jensen@us.pwcglobal.com; Alexis Bor
> Subject: [ldapext] Directory Best Practice Guide
>
>
> 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