Date: Tue, 27 Oct 1998 13:35:56 +0100 (CET) From: Andrzej Bialecki <abial@nask.pl> To: Terry Lambert <terry@whistle.com> Cc: small@FreeBSD.ORG Subject: Re: Unified Configuration Interface Message-ID: <Pine.BSF.4.02A.9810271312340.3398-100000@korin.warman.org.pl> In-Reply-To: <3634F5CF.373F@whistle.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 26 Oct 1998, Terry Lambert wrote: > Here is my one comment on the management implementation > technology: > > It should be transactional, such that you can engage > in all-or-nothing commits, doing inter-record field > validation to deny/allow a commit as a whole, and it > should be possible to expose via a standard protocol, > such as LDAP or SNMPv2, and less desirable, ACAP. Sounds like a good idea (I mean, the transactional model). Also, I would stress the word "possible" in the above statement - thus far all implementations of LDAP or SNMP agents I've seen are heavy-weight (from my point of view). > Here are my comments on the organizational policy: > > 1) Do not reinvent the wheel. There are existing MIB > standards for organization of configuration data; > leverage them to reduce the size of the task: > > RFC 1902, which defines the SMI, the mechanisms > used for describing and naming objects for > the purpose of management. > RFC 2248, the Network Services Monitoring MIB > RFC 2249, the Mail Monitoring MIB > RFC 2233, the Interfaces Group MIB using SMIv2 > RFC 2096, the IP Forwarding Table MIB > RFC 2047, the Remote Network Monitoring MIB Protocol > Identifiers > RFC 2039, the Applicability of Standards Track MIBs > to Management of World Wide Web Servers > RFC 2037, the ntity MIB using SMIv2 > RFC 1749, the Printer MIB > RFC 1697, the Relational Database Management System > (RDBMS) Management Information Base (MIB) > using SMIv2 > RFC 1696, the Modem Management Information Base (MIB) > using SMIv2 > RFC 1612, the DNS Resolver MIB Extensions > RFC 1611, the DNS Server MIB Extensions > RFC 1514, the Host Resources MIB > RFC 1414, the Identification MIB > RFC 1369, the Implementation Notes and Experience > for the Internet Ethernet MIB > RFC 1354, the IP Forwarding Table MIB > > In particular, RFC 2248 defines a framework for exposing > controls for all network aware applications/servers. Ugh.. Yeah.... This is pretty extensive list. But you make a good point... What worries me, though, is that the only one (free) implementation of snmp agent that I'm aware of is, well, more than bulky... > > 2) I understand that this is supposed to be "lightweight", > an thus will most likely contain a subset of the above > MIB configuration data. > > Let me request that if a subset is to be used, that > it be a true logical subset, i.e., for managed items, > they must conform to the MIB items, such that a full > implementation set at some later date for FreeBSD > proper dill not have a conflicting arrangement for > the same data. That's reasonable. > > 3) If the intent is small, standalone servers/devices > (one of the stated intents of the freebsd-small list > is to explore embedded systems, so this is appropriate), > it is probably worth while to consider an implementation > of SLP (Service Location Protocol, RFC 2165) for peer > discovery and integration. Thanks for the pointer - I'll look at it. > Also, although currently classed "experimental", consideration > should be given to RFC 2307, An Approach for Using LDAP as a > Network Information Service, since it addresses most NIS+ > configuration information, including bootp and machine > information. I'm not familiar with LDAP that much... Is there any implementation of it which takes less than, say, 200kB? Andrzej Bialecki -------------------- ++-------++ ------------------------------------- <abial@nask.pl> ||PicoBSD|| FreeBSD in your pocket? Go and see: Research & Academic |+-------+| "Small & Embedded FreeBSD" Network in Poland | |TT~~~| | http://www.freebsd.org/~picobsd/ -------------------- ~-+==---+-+ ------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-small" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.02A.9810271312340.3398-100000>