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

[Wes Hardaker <wes@hardakers.net>]

>>>>> On Fri, 29 Dec 2000 10:04:28 -0800, "Durham, David" <david.durham@intel.com> said:

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).

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).

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;
  }
}

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)

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.

(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.

-- 
Wes Hardaker
NAI Labs
Network Associates