From owner-freebsd-small Tue Oct 27 04:31:07 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id EAA13406 for freebsd-small-outgoing; Tue, 27 Oct 1998 04:31:07 -0800 (PST) (envelope-from owner-freebsd-small@FreeBSD.ORG) Received: from korin.warman.org.pl (korin.nask.waw.pl [148.81.160.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id EAA13400 for ; Tue, 27 Oct 1998 04:31:01 -0800 (PST) (envelope-from abial@nask.pl) Received: from localhost (abial@localhost) by korin.warman.org.pl (8.9.1/8.8.5) with SMTP id NAA22245; Tue, 27 Oct 1998 13:35:57 +0100 (CET) X-Authentication-Warning: korin.warman.org.pl: abial owned process doing -bs Date: Tue, 27 Oct 1998 13:35:56 +0100 (CET) From: Andrzej Bialecki X-Sender: abial@korin.warman.org.pl To: Terry Lambert cc: small@FreeBSD.ORG Subject: Re: Unified Configuration Interface In-Reply-To: <3634F5CF.373F@whistle.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-small@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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 -------------------- ++-------++ ------------------------------------- ||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