Subject: RE: [ldapext] Directory Best Practice Guide

From: Michael Haines - Sun <[email-masked]>
Date: Thu, 15 Aug 2002 19:19:03 +0100 (BST)

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: [email-masked] [mailto:[email-masked]] On Behalf
>> Of Chris Harding
>> Sent: Thursday, August 15, 2002 12:45 PM
>> To: [email-masked]
>> Cc: [email-masked]; 'Liben, Michael (GTS)'; 'Patrik Fältström';
>> [email-masked]; [email-masked];
>> [email-masked]; [email-masked]; 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, [email-masked] 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" 
>> > <[email-masked]>
>> >                       up.org>                  cc: <[email-masked]>,
>> 
>> > "'Liben, Michael \(GTS\)'" <[email-masked]>, "'Patrik
>> >                       Sent by:                   Fältström'" 
>> > <[email-masked]>, [email-masked]
>> >                       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: [email-masked] [mailto:[email-masked]] On
>> Behalf
>> > >Of Liben, Michael (GTS)
>> > >Sent: Tuesday, August 13, 2002 5:32 PM
>> > >To: 'Patrik Fältström'
>> > >Cc: [email-masked]
>> > >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:[email-masked]]
>> > >Sent: Tuesday, August 13, 2002 5:54 AM
>> > >To: [email-masked]; [email-masked];
>> [email-masked];
>> > >[email-masked]
>> > >Cc: [email-masked]; Ned Freed; [email-masked]
>> > >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
>> > >[email-masked]
>> > >https://www1.ietf.org/mailman/listinfo/ldapext
>> > >
>> > >
>> > >_______________________________________________
>> > >Ldapext mailing list
>> > >[email-masked]
>> > >https://www1.ietf.org/mailman/listinfo/ldapext
>> > >
>> > >
>> > >
>> > >_______________________________________________
>> > >Ldapext mailing list
>> > >[email-masked]
>> > >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:[email-masked] 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
>> >[email-masked]
>> >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
>> >[email-masked]
>> >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:[email-masked] 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
>> [email-masked]
>> https://www1.ietf.org/mailman/listinfo/ldapext
>> 
>> 

_______________________________________________
Ldapext mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ldapext