[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: "James Benedict" <james.benedict@rogers.com>
- Date: Thu, 15 Aug 2002 13:17:36 -0400
- 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>
- Organization: 2009615 Ontario Inc
Add me to the list... I'm sure I can dreg up some
comments/recommendations on directory best practices ;-)
--
James Benedict
-----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