Date: Wed, 12 Jul 2000 21:37:06 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: phk@critter.freebsd.dk (Poul-Henning Kamp) Cc: abial@webgiro.com (Andrzej Bialecki), tlambert@primenet.com (Terry Lambert), green@FreeBSD.ORG (Brian Fundakowski Feldman), dfr@FreeBSD.ORG, jlemon@FreeBSD.ORG, kbyanc@posi.net, freebsd-arch@FreeBSD.ORG Subject: Re: Final call for review: Dynamic sysctls. Message-ID: <200007122137.OAA23754@usr02.primenet.com> In-Reply-To: <1272.963424753@critter.freebsd.dk> from "Poul-Henning Kamp" at Jul 12, 2000 07:59:13 PM
next in thread | previous in thread | raw e-mail | index | archive | help
> >> Please obtain an OID arc from IANA, and establish your > >> hierarchy under an OID, with both dynamic and static subtrees, > >> so that these controls can also be exported via SNMP, ACAP, > >> LDAP, SLPv2, Saluatation, HP JetSend, JINI, LISA, and T-Spaces, > >> as well as other externalization protocols. > > > >Sounds like a good idea. How do I go about it? > > I already have registered a vendor OID with IANA for FreeBSD. > > Terry on the other hand doesn't realize what he is saying here > so don't pay too much attention to him for now. Poul, I'm sick and tired of people who piss everyone off saying crap like your statement above, merely to have the last word in a discussion. I'm not going to let you get away with it this time. I daresay you have pissed off as many FreeBSD people as Charles Hannum did NetBSD people. Yeah, I'm only participating in the relevent IETF working groups, while you are ...nowhere to be found. Poul, try avoiding the ad hominim attacks. You yourself are more than vulnerable. --- The sysctl namespace is one that should be externalized via SNMP, at a minimum, and should probably be externalized via ACAP and LDAP in order to permit FreeBSD systems to autoconfigure themselves using a Cyrus ACAP server or an LDAP directory which could be acting as an SLPv2 DA for registering service discovery information from systems that want to offer services to other machines on the network. For example, servers. For example, FreeBSD-based thin servers. For example, FreeBSD-based thin servers autoconfiguring themselves from an IBM SecureWay or IBM NuOffice directory server. It's very important that an OID-arc be allocated for configuration data that could be externalized. ACAP does not technically require this, but LDAPv3 _does_ and SNMP _does_. It's also important that the OIDs be immutably associated with the sysctl elements which they represent, so as to preclude one company form implementing things with one schema, and another with a different schema; then whose "FreeBSD schema" do you load into the management console? Which one is "right"? In particular, it is _very_ important that the variant part of the namespace be isolated from the invariant part of the namespace, and that FreeBSD follow the relevent RFCs with regard to schema definitions, as opposed to "rolling its own", like most morons who believe they understand SNMP are wont to do with their own OID-spaces, and screw the people who have to load umpteen million object definitions into their consoles in order to manage their networks. I am most concerned with the "you can ignore this part of the namespace" for the variant parts, since there is no way a managment console, such as the one from Tivoli systems, will be able to interpret this correctly. The LDAP and ACAP externalizations are more interesting in this regard, since these protocols are capable of exporting subschema entries such that a console/browser _could_ interpret and manipulate this data (for example, for supporting configuration for a deployment of tens of thousands of FreeBSD based thin servers). Did you even _read_ the message concerning the alpha stuff, and _see_ how large the alphabetic sysctl namespace has grown? Just because you aren't using FreeBSD for something commercial, don't assume that others aren't. Thanks. Terry Lambert Infrastructure Architect IBM terrylam@us.ibm.com --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200007122137.OAA23754>