Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 11 Jan 1999 08:58:45 -0500
From:      "Louis A. Mamakos" <louie@TransSys.COM>
To:        Garrett Wollman <wollman@khavrinen.lcs.mit.edu>
Cc:        Nate Williams <nate@mt.sri.com>, committers@FreeBSD.ORG
Subject:   Re: Another approach... Re: sysctl descriptions 
Message-ID:  <199901111358.IAA91434@whizzo.transsys.com>
In-Reply-To: Your message of "Mon, 11 Jan 1999 07:44:28 EST." <199901111244.HAA13985@khavrinen.lcs.mit.edu> 
References:  <199901101807.KAA07319@dingo.cdrom.com>  <199901102149.VAA00631@keep.lan.Awfulhak.org> <199901110452.VAA13815@mt.sri.com> <199901111244.HAA13985@khavrinen.lcs.mit.edu>

next in thread | previous in thread | raw e-mail | index | archive | help

> I think, if we want to be serious about describing what's in sysctl(3)
> as a ``MIB'', we should sit down and write an ACTUAL MIB, i.e., a hunk
> of ASN.1 that is a *specification* for the information we wish to
> present.  (Before everyone gags, I'm not at all suggesting that we go
> the BER/DER/PER/FooER route for conveying the information; merely that
> we write an ASN.1 description of what the MIB is supposed to be and
> what the data types in it are.)

In some sense this is orthoganal to the issue at hand (e.g., what if you
don't have the MIB "source" that describes the functions of the OID's
in question).  Nevertheless, this is a wonderful solution that we should
pursue.

> This would require an ASN.1 interpreter in the base system, but what
> it gives us is the following:
> 
> 	1) An even-more-automated way of creating the code to define
> 	   the things.
> 
> 	2) A specification against which the actual implementation can
> 	   be checked.
> 
> 	3) Easy interface to SNMP.  Things like the interface MIB can
> 	   be directly expressed using the SNMP-defined MIB tree.
> 
> 	4) Machine-parseable documentation.

And, as someone that's recent written code with a bunch of SYSCTL's for
instrumentation, you left out:

	5) An easy and obvious way to have instances.

It currently sucks to have a set of SYSCTL variables, one set per instance
of a driver.  As someone that's done SNMP for quite a while, it always
struck me very strange that the OID's that sysctl() use don't have an
instance as the last identifier element.

> Since we have already committed to including an SNMP agent in the base
> system RSN, we should end up with enough of an ASN.1 parser to do
> anything we need (with perhaps a bit of hacking).  We already have an
> SNMP enterprise MIB arc which can be used to represent all our
> non-standardized features.

I dunno which one you have in mind, but in this day and age, it should have
(or have very soon) SNMPv3 capability with the security mechanisms it
brings to the table.

louie



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe cvs-all" in the body of the message



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199901111358.IAA91434>