Re: Nesting levels in existing mibs

[Frank Strauss <strauss@ibr.cs.tu-bs.de>]

Hi!

DD> <dbh>
DD> -----Original Message-----
DD> From: Harrington, David [mailto:dbh@enterasys.com]
DD> Sent: Wednesday, September 18, 2002 9:43 AM

DD> ... snip...

DD> 3) operators have spoken out strongly against applications that
DD> have to do a lot of "conversion" of the data stream to make it
DD> understandable, because when they are debugging, they don't want
DD> to add yet another potentially-buggy layer of interpretation
DD> between them and the raw data; and
DD> </dbh>

DD> <DaveD> In fact, I recall the operators making a much stronger
DD> statement that they regularly work (and want to work) with the raw
DD> snmp data via command line get & set, and don't want to be
DD> dependent on application driven data conversion, interpretation,
DD> or anything else. Frank, given the operator preference for
DD> low-level visibility, how does adding multiple levels of
DD> indirection between smiv2 tables make their life easier? In this
DD> case it seems that it would be a benefit to have hierarchical oids
DD> "on-the-wire" to make the low level data more readily
DD> understandable as well as the data definitions...  </DaveD>

I don't understand what you mean by `multiple levels of indirection'
in this context. If operators want to see what's on the wire then with
the NMRG-based approach there is no difference from what we have right
now. E.g., tcpdump or ethereal would print OID-value pairs, or if the
tools is aware of the MIB definition it could also be able to print
the nested identifiers. The same would be true for tools like
snmpget/set/walk/...



My feeling is still, that I'm the only person who believes that the
current approach leads to incompatibilities or in other words to a
split world of SMIv2 and SMIv3 MIBs. The responses to my concerns so
far, weigh the advantages of the changed naming in SMI-DS higher than
the disadvantages.  Based on this fact and based on the minutes from
recent meetings, I really accept this situation and I really don't
intend to stop the WG from making progress. However, I wanted to make
clear that I don't support this direction.

 -frank