Subject: [ldapext] cn=monitor

From: "Vithalprasad Gaitonde" <[email-masked]>
Date: Wed, 05 May 2004 10:10:04 -0600

Is the cn=monitor present in some LDAP server based on a standard? If
not is there a plan/interest for standardization for this.

Thanks,
Prasad

_______________________________________________
Ldapext mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ldapext

---

From: "David Boreham" <[email-masked]>
Date: Wed, 5 May 2004 09:44:32 -0700

> not is there a plan/interest for standardization for this.

There's an existing SNMP MIB for Directory Servers,
and I know that there's a vague similarity between that
and a _subset_ of the content of cn=monitor for at least
one server implementation. 

It might be possible to define a cannonical mapping 
between the MIB and the cn=monitor content.

Another useful (IMHO) activity would be to 
work on the MIB (or the mapped LDAP equivalent) some
to bring it in line with the needs of present-day deployents
and implementations.

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 05 May 2004 10:01:18 -0700

At 09:10 AM 5/5/2004, Vithalprasad Gaitonde wrote:
>Is the cn=monitor present in some LDAP server based on a standard?

At present, there are no standards for publishing monitoring
information via LDAP.  There is, of course, some standardized
MIBs which one can access via SNMP.

>If not is there a plan/interest for standardization for this.

I'd be interested in publishing a general approach for
accessing MIBs via LDAP.  And them maybe design some new
MIBs.

I'd also be interested in an (informational?) RFC discussing
some good and bad implementation practices.  One thing that
concerns me is that some implementations publish "cn=monitor"
(and DNs of like DSA specific information trees) as
values of the root DSE namingContexts attribute.  That's
bad as namingContexts is intended specifically for DIT naming
context discovery.

Kurt

---

From: Chris Ridd <[email-masked]>
Date: Wed, 05 May 2004 18:47:49 +0100

> bad as namingContexts is intended specifically for DIT naming

We avoid polluting the namingContexts attribute by using virtual attributes
(one for each MIB we support) on our root DSE which are generated/returned
on demand. A mechanism for reporting which attributes hold which MIB
contents might be nice, as currently clients just "have to know" what
attributes the server's using :-(

Cheers,

Chris