RE: Latest posted agenda for SMIng meeting at the 49th IETF...

["Durham, David" <david.durham@intel.com>]

> -----Original Message-----
> From: Wes Hardaker [mailto:wes@hardakers.net]
> 
> Wes> D. An entirely different beast - usage of new features of the
> Wes> language may mean that the way the protocol(s) is interpreted
> Wes> might be changed.  (As an example, do you want to drop the Entry
> Wes> node requirement for tables created in the future in the new
> Wes> language (this doesn't mean that there wouldn't be a way to
> Wes> specify it for translation/backwards-compatibility purposes)?)
> 
> David> [Dave] Well, D seems to violate the charter since we are not
> David> re-doing any protocols here (if that's what you mean).
> 
> D does not violate the SNMP protocol.  The SNMP protocol merely
> explains how to send data over the wire.  It doesn't say how to
> interpret that data.  We could very easily drop the Entry subnode
> requirement for tables without changing a single line of the main SNMP
> definition RFCs (until you rewrote the MIBs contained within using the
> new SMI language).
> 
[Dave] True, the row entry is about as useful as my appendix, which, still
hasn't been removed either.

> The problem comes from the fact that we're trying to take a lot of new
> concepts (OO, etc) and mapping them back onto the same interpretation
> that was implied from SMIv2.  IMHO, we should completely rethink how
> OIDs are to be used with reference to tables.  It would fix some of
> the problems that were brought up in San Diego with respect to class
> hierarchies.  As a radical example, consider changing the column
> number inside the oid such that it was no longer a single digit.  That
> would allow the definition of the column section of the oid to be
> something like "1.2" for "the second attribute (a base data type, like
> Integer32) of the first attribute (the class containing the Int32) of
> the class defining the table".  This means that the long-winded
> process of defining a table inside of SNMP can be boiled down
> significantly unless you need backwards compatibility (IE, rewriting
> old tables).
> 
[Dave] I see your point, however, the process of mapping a class into a
table does provide for backward compatibility to some degree. As far as the
future definitions are concerned, I imagine that the process could be
automated. 

Now, I suppose another question might be, is it better to have
shorter/flatter oids or longer more hierarchical oids? There seems to be an
extra price to pay for a non-tabular oid structure in terms of what needs to
be sent over the wire.

> Forgive me for blowing this example and not using proper SMIng syntax:
> 
> class A {
>   Integer32 x;
>   Integer32 y;
> };
> 
> class B {
>   A point1;
>   B point2;
>   Integer32 stat;
> };
> 
> Right now, in order to define this class in the OID tree you'd have to
> do something like:
> 
> snmp {
>   table sometable ISA B indexed by point1.x {
>     implements point1.x somecolumnname1;
>     implements point1.y somecolumnname2;
>     implements point2.x somecolumnname3;
>     implements point2.y somecolumnname4;
>     implements stat     somecolumnname5;
>   }
> }
> 
[Dave] I assume you mean "Class B { A point1; A point2; Integer32 stat; };"
 
> This would map oid scheme like:
> 
>   sometable.someEntry.somecolumnname1.0  (= table.1.1.0)
>   sometable.someEntry.somecolumnname2.0     ...
>   sometable.someEntry.somecolumnname3.0
>   sometable.someEntry.somecolumnname4.0
>   sometable.someEntry.somecolumnname5.0  (= table.1.5.0)
> 
> This is necessary because you have to map class attributes to a
> singular column number, and hence a inheritance ordering has to be
> explicitly listed to meet how the current SMI expects OIDs to be
> formed.  Wouldn't it be nicer to say:
> 
> snmp {
>   table sometable ISA B indexed by point1.x;
> }
> 
> Which would map to:
> 
>   sometable.point1.x.0     (= table.1.1.0)
>   sometable.point1.y.0     (= table.1.2.0)
>   sometable.point2.x.0     (= table.2.1.0)
>   sometable.point2.y.0     (= table.2.1.0)
>   sometable.stat.0         (= table.3.0)
> 
[Dave] I assume that a compound INDEX would never conflict with one of these
hierarchical columnar oid... Say INDEX {sometable.point1.x,
sometable.point1.y, sometable.point2.x, sometable.point2.y}?

> Additionally you solve having to rewrite the snmp extension definition
> when someone adds a new attribute to a base class.  You can inherit it
> automatically, like a true OO SMI should let you do without having to
> forcibly assign a new column number to it.
> 
[Dave] Good point.

> (we could of course support the previous implements definition for
> defining old mibs in the new language (backwards compatibility)).
> 
> It's things like this that I thought option D could cover.  I suspect,
> though, that I've suddenly become the target of an awful lot of
> tomatoes that are about to be thrown my way.  In the long run,
> redefining how the language mapped to SNMP (rather than trying to
> force the same older SMI interpretation upon the new language) would
> be beneficial.  However, its a radical change.
> 
[Dave] Yes, but my gut feeling is that existing implementations of the SNMP
protocol have certain expectations for how OIDs are formulated. I wonder if
any actually expect to see, say the .1 row sub OID. Another question: during
the transition phase from SMIv2 to SMIng, do we expect the new and old tools
to overlap. If yes, even the new SMIng definitions may still need to be
translated to SMIv2 MIBs. Some of the existing MIB tools are tightly
dependent on a particular SNMP protocol stack, and obviously will not be
able to generate/interpret hierarchical table definitions (unless, you add a
row entry value for every contained class, forcing every contained class to
look like a separate table oid-wise, but indexed the same).

> -- 
> Wes Hardaker
> NAI Labs
> Network Associates
>