Subject: draft-ietf-ldapext-locate-02 and UDP

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 23 Jun 2000 20:32:38 -0700

Another last call comment...

Section 4 states that the protocol can be either "udp" or "tcp".
It is unclear to me whether this I-D is intended "udp" <Proto> 
is to be used to locate CLDAPv2 (RFC1798) services or to locate
CLDAPv3 (draft-ietf-ldapext-cldap-00) or was just an alias
for "tcp".

As LDAP (RFC1777/RFC2251) does not provide a specification for
LDAP over UDP, this proposal should not provide location of
services operating over UDP.  

I suggest that
	<Proto> is a protocol that can be either "udp" or "tcp"

be replaced with:
	<Proto> is "tcp" or other transfer protocol (RFC2251, 5.2)

and that location of CLDAP be left to future CLDAP specifications
(which, if appropriate, may update this specification).

---

From: "RL 'Bob' Morgan" <[email-masked]>
Date: Sat, 24 Jun 2000 09:55:23 -0700 (PDT)

> services operating over UDP.  

I agree that this needs to be more clear but I'm not sure I agree with the
conclusion.

RFC 1798 is a Proposed Standard.  It seems reasonable to specify a means
to discover services that implement it, and seems obvious to do so using
"_ldap._udp" as the -locate- draft implies.  There is enough compatibility
between LDAPv2-over-TCP and LDAPv3-over-TCP that servers can reasonably do
both, so we're not motivated to specify something like "_ldapv3._tcp" as a
separate name.  The only reason I can think of for removing references to
UDP from this document, that is, for deciding to have the DNS SRV method
*not* apply to services conforming to RFC 1798, is that we think that RFC
1798 is technically flawed enough that CLDAPv3 is likely to be
incompatible with it, hence we're inclined to reserve "_ldap._udp" to
apply to CLDAPv3 implementations only.  Is that what you're asserting,
Kurt?  (Obviously we can't refer to CLDAPv3 in this doc since CLDAPv3 is
not done yet; and I don't think publication of -locate- wants to wait on
it.)

Otherwise, I suggest that the text be modified to say:

  The name of this record has the following format:

      _<Service>._<Proto>.<Domain>

   where <Service> is always "ldap", and <Proto> is a protocol that can
   be either "udp" or "tcp".  "_ldap._tcp" applies to services compatible
   with LDAPv2 [RFC1777] or LDAPv3 [1].  "_ldap._udp" applies to services
   compatible with CLDAP [RFC1798].

 - RL "Bob"

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Sat, 24 Jun 2000 10:28:46 -0700

At 09:55 AM 6/24/00 -0700, RL 'Bob' Morgan wrote:
>Is that what you're asserting, Kurt?

I'm simply asserting that CLDAP is not LDAP and I would prefer
that each protocol have separate specifications for service location.
This would allow specifications for each protocol to be developed
and progressed independently from each other.  I would hate to see
LDAP location service eventual progression to Draft Standard or
Standard held up due to lack of CLDAP maturity.

---

From: Bruce Greenblatt <[email-masked]>
Date: Sat, 24 Jun 2000 21:16:03 -0700

At 10:28 AM 6/24/2000 -0700, Kurt D. Zeilenga wrote:
>I'm simply asserting that CLDAP is not LDAP and I would prefer...

Huh.  CLDAP is supposed to be a subset of LDAP over UDP?

==============================================
Bruce Greenblatt, Ph. D.
Directory Tools and Application Services, Inc.
http://www.directory-applications.com
Sign up for our LDAP Technical Overview Seminar at:
http://www.acteva.com/go/dtasi

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Sat, 24 Jun 2000 22:51:21 -0700

>Huh.  CLDAP is supposed to be a subset of LDAP over UDP?

I'll leave that for the authors to answer.

The issue here is quite simple.  Is it better to have one
document or two?  I argue two is better as one as they
could be developed and progressed independently of each
other.

Kurt