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