Subject: RE: draft-mmeredith-rootdse-vendor-info-02.txt

From: "Mark Meredith" <[email-masked]>
Date: Fri, 25 Feb 2000 10:45:44 -0700

Bruce,

I can see your point on duplication of information, but what if a site is not running SNMP, or the client being used does not support SNMP how would the information be known?

If the information is in the ROOT DSE, I do not care how the information is retrieved from a ldap server stand point, the server could query SNMP or DNS ..... etc. That way the information would not be duplicated per say, but multiply viewable.

Does this sound reasonable to you?

What do the client developers on this list think?

-Mark

>>> Bruce Greenblatt <[email-masked]> 02/24/00 06:31PM >>>
I understand that you don't want to look the information up in SNMP.  But,
why not?  It's already there, and SNMP is pretty lightweight (simple even).
 Do we really want to duplicate this vendor information in several places?
It could just as easily be added to SRV records in DNS?  What about all of
the other informaiton in RFC 2248 and RFC 2605?  Do you want to plop that
into the RootDSE as well?

Bruce

At 10:49 AM 2/18/00 -0700, Sukanta Ganguly wrote:
>   It is very difficult and unclear at this point whether we should assume 
>that all Internet Directory Client are in the position to talk different 
>Internet protocols. Instead of assuming that the Directory Client will talk
>SNMP  and query the MIB for getting the vendor specific information, why
>can't we  state that the Directory Client queries the rootDSE for the
>information and the  implementation would determine whether to go to the
>SNMP MIB for the information  or to have the vendor specific information,
>requested by Mark, within the  Directory Repository.   I think it will
>bring in more value to have the access to the information  through the
>rootDSE but at the same time leave the invididual implementations to 
>handle them. We all agree, based on the emails that I have seen flowing
>around  related to this matter, that the information is useful so why not
>provide the  flexibility.   Thanks Sukanta Ganguly [email-masked] 
>
>>>><>>>>
>At 09:13 AM 2/18/00 -0500, Peter Strong  wrote:
>>
>>>
>>>
>>> To be blunt, I don't believe  that there is much use for this draft.
>>
>>For those of us who  attempt to build applications that work with
>>multiple directory  implementations, this information is very useful.
>>
>
>   I said that
>  Get it from there, since that  is
>  I don't see much point in duplicating  this
>  In my opinion, a good internet directory client will  get
>information from a variety of internet servers: DNS, LDAP, SNMP, and  others.
>
>>> The information that it proposes to add to the Root DSE  is already
>>> published is
>>>  The
>>>  I think that this draft
>>> should just  point to RFC 2248 (and perhaps 2605) and explain where the
>>>  These are already standards  track
>>> documents, and have places to put the information that this  draft
defines.
>>> (Just my $0.02 worth)
>>
>>The products we  build are LDAP clients, not SNMP clients.
>>
>>This information should  be available via LDAP.
>>
>>>
>>>  Bruce
>>>  ==============================================
>>> Bruce Greenblatt, Ph.  D.
>>> Directory Tools and Application Services, Inc.
>>> http://www.directory-applications.com 
>>>
>>
>>------------------------------------------------------------------------
>>Peter  Strong
>>Software Architect
>>Nortel Networks - Optivity Policy  Services (OPS) and NetID
>><>
>>(613)  831-6615
>>
>>
>>
>>
>>
>>
>==============================================
>Bruce  Greenblatt, Ph. D.
>Directory Tools and Application Services, Inc.
>http://www.directory-applications.com 
>
> 
==============================================
Bruce Greenblatt, Ph. D.
Directory Tools and Application Services, Inc.
http://www.directory-applications.com

---

From: Mark Smith <[email-masked]>
Date: Fri, 25 Feb 2000 14:13:59 -0500

I've written or helped people write dozens of LDAP clients (hundreds?)

None of these clients includes SNMP client code, although they include
many other protocols (SMTP, IMAP, POP, S/MIME, HTTP and many others).

I conclude that most (LDAP) client applications don't have any need to
speak SNMP today, and therefore we shouldn't force them to do so just to
get at this information.  A little redundancy doesn't seem like a bad
thing in this instance.

-- 
Mark Smith
Directory Product Development / iPlanet E-Commerce Solutions
My words are my own, not my employer's.            Got LDAP?

---

From: Bruce Greenblatt <[email-masked]>
Date: Sun, 27 Feb 2000 09:11:07 -0800

It would be acceptable to me if wording similar to the following were
included in the "vendor info" draft:

"Server implementations conforming to this document must also support RFC
2248.  In particular the strings that are stored in the vendorName and
vendorVersion attribute values defined here must be also available via SNMP
from the applName and applVersion fields of the applTable MIB defined in
RFC 2248."

Note that I'd mandate this, so that the information is duplicated rather
than in place of.  Does any one produce an LDAP server on a platform where
there is no SNMP agent?

Bruce

At 02:13 PM 2/25/00 -0500, Mark Smith wrote:
>> I can see your point on duplication of information, but what if a site
is not running SNMP, or the client being used does not support SNMP how
would the information be known?
>> 
>> If the information is in the ROOT DSE, I do not care how the information
is retrieved from a ldap server stand point, the server could query SNMP or
DNS ..... etc. That way the information would not be duplicated per say,
but multiply viewable.

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Sun, 27 Feb 2000 18:00:26 -0800

>from the applName and applVersion fields of the applTable MIB defined in

There should be no requirement for a implementation of LDAP to
implement any other application level protocol.  LDAP should be
sufficient for accessing directories.

>Does any one produce an LDAP server on a platform where
>there is no SNMP agent?

Yes.  And even where there is an SNMP agent, that agent is not
necessarily aware of directory services.

Kurt