[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
RE: [ldapext] Directory Best Practice Guide
Hi Chris,
>>
>> Chris,
>> I would be more than happy to help and work on this.
Please include me in this to.
>>
>> -- Alexis
>>
>> Alexis Bor
>> Directory Works, Inc.
>> www.directoryworks.com
Regards
-Michael
Sun Microsystems Inc.
Sun ONE Products - Directory Server Group
>>
>>
>> -----Original Message-----
>> From: ldapext-admin@ietf.org [mailto:ldapext-admin@ietf.org] On Behalf
>> Of Chris Harding
>> Sent: Thursday, August 15, 2002 12:45 PM
>> 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