Hi Dave,
On Thu, Nov 29, 2012 at 8:25 PM, <d...@powerstandards.com> wrote:
> Hi Mark,
>
> Thanks so very much. There is not a lot out there about the right way to
> do these things, much less sometimes any way to do them. Sorry if this
> got a bit wordy, but I tried to organize it so that the questions were
> discrete
>
> I have been working from printed copies of the RFCs, in fact.
>
FYI, http://www.rfc-editor.org/ maintains a complete, up to date repository
of all IETF published RFCs, including standards track MIB modules published
as RFCs.
> I have an internal service that returns a (variably indexed upon restart)
> list of sensor readings. What I mean by "dual implementation" is one mib
> requiring and referring to another.
Let's refer to the entPhysicalTable as the "base" table and the
entPhySensorTable as the "extension" table. There is a fate relationship
between an entPhySensorEntry (a row) and the corresponding
entPhysicalEntry. Whenever there is an entPhySensorEntry with a given
value of entPhysicalIndex, there must also be an entPhysicalEntry with same
(corresponding) value of entPhysicalIndex. Additionally, the the value of
entPhysicalClass will be 'sensor(8)'.
> I used mib2c (not now at the office,
> don't remember the config--I believe mfd) to generate code for an agentx
> subagent to implement RFC4133 to read those values. That *basically*
> works. However, I am not sure how to get what I need--or more precisely,
> how to find the best model for doing so--from the 3433 mib.
>
I really have not used the mfd template because I like to have more control
over table handling, especially in the case of a base table and an
extension table.
You can run mib2c multiple times on a MIB module to generate various code
components. For example, with the ENTITY-MIB, you might use:
'column_enums' to generate some #defines for defined enumerated values and
'notify' to generate some nominal code for event notifications. The
'table_data' template worked for me for the ENTITY-MIB and ENTITY-SENSOR-MIB
>
> Do I want to two make subagents if I want to start with mib2c mfd
> invocations?
>
I don't think that's necesssary. I'd recommend modifying the output from
mib2c to include the entPhySensorEntry as part of the entPhysicalEntry data
structure- the general approach would be to have a 'void *more' attribute
added to the entPhysicalEntry that can be dereferenced with a type cast
based upon the value of the entPhysicalClass attribute.
You can still keep the table handlers, registrations, etc. in separate
files...but share a reference to the common data structure.
> Is, indeed, mib2c -config mfd the way to go to start for this problem?
>
> Is "subagent per mib" the way to go unless compelled to do otherwise?
>
> In looking through some code in agent/mibgroup, I found what I believe are
> hackable examples (in the tcp subdir, e.g.)-and those mostly in v4--but
> not really how to go about it fresh from one (or two) "mib2c" invocations,
> if that is even practical.
>
> What is the best working model and best practice for implementing "sparse
> augmentations" (4133 refers to itself as a "sparse augmentation" of 3433)
> developed using netSNMP v5?
>
right - sparse augmentation is a subset of extension table.
>
> I may ultimately need to build in alarms, too. How do I best develop in
> such a way that I am set
> up to implement an alarm function when I need it? (subagent per mib?)
>
>
What do you mean by 'alarms'? This is an overloaded term...
> (I realized as I wrote this that it may have been clearer to me if I'd
> implemented the prereq 3433
> subagent first. Doh!)
>
Yup!
>
> The second part is pretty simple: suppose I wanted to add "Henrys" or
> "VaR" to the list of valid entitySensorDataTypes (note: I am not at all
> anxious to do this, but it may come up and I'll need to explain my "No"
> answer with authority and conviction). I think the "other(1)" theory below
> is the right one, but just wanted to confirm:
>
>
Since the definition of the EntitySensorDataType textual convention appears
in an IETF published RFC, essentially you must adhere with what is defined
in the RFC. You could participate in the IETF process to get the RFC
opened to add enumerated types to the TC...but this takes a non-trivial
amount of time.
So...can you translate Henrys into one of the existing enumerated values?
Probably not. So you can use 'other(1)' and then use entPhySensorUnitsDisplay
to show 'henrys' or 'tenths of henrys' or whatever works best...same with
VaR.
As I understand it, I can't just slam something into the middle of this
> list (p. 5 of RFC 4133),
>
> other(1): a measure other than those listed below
> unknown(2): unknown measurement, or arbitrary,
> relative numbers
> ...
> rpm(10): shaft revolutions per minute
> cmm(11),: cubic meters per minute (airflow)
> truthvalue(12): value takes { true(1), false(2) }
>
> and transpose the subsequent values up, e.g.:
>
> ...
> henrys(10): inductance ## WRONG!
> rpm(11): shaft revolutions per minute ## even
> WRONGER!
> cmm(12),: cubic meters per minute (airflow)
>
> and *I don't think* I can append to the end of it.
>
Right- can't do the above- only the owner of the ENTITY-SENSOR-MIB can make
changes. That's the IETF.
>
> So, do I just use "other(1)" and expect the end user to derive the meaning
> from the UnitsDisplay field, or can I append "Henrys(13)" to the end of
> that list, (which presumably somebody ELSE could do with "VaR(13)" in
> their version at the same time)?
Right- just use 'other(1)'.
> According to the general MIB modification
> rule (RFC1902 sec. 10 or thereabouts), it seems I can "append" but not
> "reorder", but must there then be community wide follow through?
>
>
You can also use http://www.rfc-editor.org to find out that RFC1902 was
obsoleted by RFC2578. This RFC, along with RFC2579 and RFC2580 form IETF
standard 58 specifying the Structure of Management Information version 2
(SMIv2). In addition, there is RFC 4181 "Guidelines for Authors and
Reviewers of MIB Documents" that provide guidance on how to create and
subsequently modify published MIB modules. These rules apply to IETF
published MIB modules as well as MIB modules published by an enterprise.
You can only modify MIB modules published by your enterprise.
I'm presuming and ready to argue that it would be a MISTAKE to put out a
> MIB with Henrys(13) in it, but is there a better way to do it than have
> the end user derive it from the UnitsDisplay field and doc they'll never
> read?
>
Correct- go with 'other(1)' and the the actual units
in entPhySensorUnitsDisplay. The other viable alternative would be to
create an extension table to the entPhySensorTable to augment
the entPhySensorType values in your enterprise name space...but this is
likely 'overkill'.
> Dave
>
> PS No need for the answers to be as wordy as the questions! I'm new to
> snmp agent development, so it is possible some of my presumptions are
> askew. I think things are probably simpler than I make them out to be.
> Before a few weeks ago, all I'd ever seen of snmp was mrtg graphs on
> sysadmin's screens, and the tech dialect challenges even XML and
> SSL--that's saying something--for opacity.
>
>
>
Hope this helps!
Regards,
Mark
>
> . > Hi Dave,
> > I have implemented both the ENTITY-MIB (RFC4133) and ENTITY-SENSOR-MIB
> (RFC3433) multiple times. However, it is not clear what question you
> are
> > asking here. Rather than guess, I prefer to ask for some clarification.
> I am not sure what you mean by the following:
> > "dual implementation"
> > "DataTypes"
> > If you have a moment to re-frame your question in terms of the above
> RFCs,
> > then I am sure you will get the answers you need. What is the
> applicable
> > problem domain (your application)?
> > Regards,
> > Mark
> > On Wed, Nov 28, 2012 at 12:12 PM, <d...@powerstandards.com> wrote:
> >> Which is the best (v5) model for this kind of dual implementation in a
> subagent?
> >> What is the (social) procedure to follow if I want to add new
> DataTypes,
> >> i.e., (extend the Entity Sensor MIB)?
> >> Thanks,
> >> Dave
> >>
> ------------------------------------------------------------------------------
> Keep yourself connected to Go Parallel:
> >> INSIGHTS What's next for parallel hardware, programming and related
> areas?
> >> Interviews and blogs by thought leaders keep you ahead of the curve.
> http://goparallel.sourceforge.net
> >> _______________________________________________
> >> Net-snmp-users mailing list
> >> Net-snmp-users@lists.sourceforge.net
> >> Please see the following page to unsubscribe or change other options:
> https://lists.sourceforge.net/lists/listinfo/net-snmp-users
>
>
>
>
>
------------------------------------------------------------------------------
Keep yourself connected to Go Parallel:
TUNE You got it built. Now make it sing. Tune shows you how.
http://goparallel.sourceforge.net
_______________________________________________
Net-snmp-users mailing list
Net-snmp-users@lists.sourceforge.net
Please see the following page to unsubscribe or change other options:
https://lists.sourceforge.net/lists/listinfo/net-snmp-users
