Discovering LDAP Services with DNS
draft-ietf-ldapext-locate-08
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2015-10-14
|
08 | (System) | Notify list changed from , , , to |
2004-05-22
|
08 | (System) | Document has expired |
2004-05-21
|
08 | (System) | Ballot writeup text was added |
2004-05-21
|
08 | (System) | Last call text was added |
2004-05-21
|
08 | (System) | Ballot approval text was added |
2004-05-21
|
08 | Ted Hardie | State Changes to Dead from IESG Evaluation::Revised ID Needed by Ted Hardie |
2004-05-21
|
08 | Ted Hardie | After talking to LDAP directorate, it appears that the authors intend to submit two replacement documents to replace this one; no indication of when this … After talking to LDAP directorate, it appears that the authors intend to submit two replacement documents to replace this one; no indication of when this will get attention though. Since new split is anticipated, this is getting marked dead. |
2003-07-15
|
08 | Ted Hardie | Discussed during IETF57; individual submission with slimmed-down description of SRV processing likely. When that occurs, this will be marked date. |
2003-03-24
|
08 | Ted Hardie | Shepherding AD has been changed to Hardie, Ted from Faltstrom, Patrik |
2002-11-14
|
08 | Patrik Fältström | Discuss from Allison: My read of this document is that it is overly simple and constraining of the LDAP location usage through SRV. There is … Discuss from Allison: My read of this document is that it is overly simple and constraining of the LDAP location usage through SRV. There is a single formulation of "the" LDAP server for the domain. I believe that there might be a model where different LDAP services existed for the domain on different port numbers, and this would result in a different construction of the SRV record... Also, as TSV AD, I'd like to have the phrase "that supports the TCP protocol" a little more tuned - LDAP with UDP is deprecated, right? Is LDAP with SCTP under development? It might be that the phrase should be "that supports the TCP protocol (in future, there may be an analogue for sctp or another protocol)" |
2002-10-29
|
08 | Patrik Fältström | Comments: Scott: note: references should be split Bert: I wonder about the reference to RFC1700, which has been obsoleted by RFC3232, and that … Comments: Scott: note: references should be split Bert: 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? Thomas: I'd also like to better understand the issue Erik raised. In addition, 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. |
2002-10-29
|
08 | Patrik Fältström | by paf |
2002-10-29
|
08 | Patrik Fältström | Jeff: This document define a conversion that is over-restrictive. The output domain name is initially empty. The DN is processed in … Jeff: 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 |
2002-10-29
|
08 | Patrik Fältström | by paf |
2002-10-29
|
08 | Patrik Fältström | Ned: I have three concerns here: (0) It isn't clear when this approach is supposed to be used. DNs are an … 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. |
2002-10-29
|
08 | Patrik Fältström | by paf |
2002-10-29
|
08 | Patrik Fältström | by paf |
2002-10-29
|
08 | Patrik Fältström | Erik: The document says: If there are no matching SRV records available for the converted DN the client SHOULD … Erik: 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.) or something similar. Nit: split references into normative and non-normative. |
2002-10-29
|
08 | Patrik Fältström | by paf |
2002-10-29
|
08 | Patrik Fältström | State Changes to IESG Evaluation -- Revised ID Needed from IESG Evaluation -- Point Raised - writeup needed by paf |
2002-08-09
|
08 | Stephen Coya | State Changes to Evaluation: Discuss from Ready for Telechat … State Changes to Evaluation: Discuss from Ready for Telechat by scoya |
2002-07-29
|
08 | Stephen Coya | State Changes to Ready for Telechat from Wait for Writeup … State Changes to Ready for Telechat from Wait for Writeup by scoya |
2002-07-29
|
08 | Patrik Fältström | Writeup sent in |
2002-07-29
|
08 | Patrik Fältström | A new comment added by paf |
2002-06-12
|
08 | (System) | New version available: draft-ietf-ldapext-locate-08.txt |
2002-03-26
|
07 | (System) | New version available: draft-ietf-ldapext-locate-07.txt |
2002-02-05
|
08 | (System) | Last call sent |
2001-11-29
|
06 | (System) | New version available: draft-ietf-ldapext-locate-06.txt |
2001-03-07
|
05 | (System) | New version available: draft-ietf-ldapext-locate-05.txt |
2000-08-29
|
04 | (System) | New version available: draft-ietf-ldapext-locate-04.txt |
2000-07-20
|
03 | (System) | New version available: draft-ietf-ldapext-locate-03.txt |
2000-04-26
|
02 | (System) | New version available: draft-ietf-ldapext-locate-02.txt |
2000-01-06
|
01 | (System) | New version available: draft-ietf-ldapext-locate-01.txt |
1999-09-09
|
00 | (System) | New version available: draft-ietf-ldapext-locate-00.txt |