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

[Wes Hardaker <wes@hardakers.net>]

>>>>> On Wed, 3 Jan 2001 13:25:50 -0800 , "Durham, David" <david.durham@intel.com> said:

David> [Dave] I see your point, however, the process of mapping a
David> class into a table does provide for backward compatibility to
David> some degree. As far as the future definitions are concerned, I
David> imagine that the process could be automated.

Right.  I (thought I) stated that it should be possible to implicitly
map classes and sub-components for the purpose of re-defining old MIBs
in the new language (or defining new ones using the same implicit
numbering method if there was a need to map them back to SMIv2, etc).

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

It's true that the one-the-wire bits would be longer (maybe its
finally time for OID compression).  Anyway, it's a sacrifice you're
right.  However, if we truly cared about short OIDs then we should
remove that silly "Entry" node as well ;-)

Actually, the way most mibs are currently structured adds multiple
nodes of cruft to the oid:

% snmptranslate -Ofn -IR usmUserTable
.iso.org.dod.internet.snmpV2.snmpModules.snmpUsmMIB.usmMIBObjects.usmUser.usmUserTable                  
                                         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

We're obviously willing to put in extra nodes to make the oid tree
"cleaner".  If we wanted shorter OIDs I'd suggest dropping a seperate
tree for "object" vs "conformance" vs ... definitions.  They are there
because it makes logical sense to construct things that way (as it
makes logical sense, in my mind, to construct columns out of multiple
nodes).

...
>> class B {
>> A point1;
>> B point2;
>> Integer32 stat;
>> };
...
David> [Dave] I assume you mean "Class B { A point1; A point2;
David> Integer32 stat; };"

Yes I did, sorry.
 
>> 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)
>> 

David> [Dave] I assume that a compound INDEX would never conflict with
David> one of these hierarchical columnar oid... Say INDEX
David> {sometable.point1.x, sometable.point1.y, sometable.point2.x,
David> sometable.point2.y}?

The indexes in this case are mapped like normal since they are all
base data types.  With that indexing the oid for index values of
{sometable.point1.x = 1, sometable.point1.y = 2 , sometable.point2.x =
3, sometable.point2.y = 4} would become
sometable.point1.x.1.2.3.4. (for the point1.x attribute, for example).

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

David> [Dave] Good point.

Well, there are other ways to accomplish something similar but they
are ugly and lead to large numbers...  Consider limiting the
auto-inheritance to say 4 levels.  You could then map
sometable.point2.x.0 to "sometable.(2<<24 | 1 << 16 | 0 << 8 | 0 <<
0).0", but ick.

David> [Dave] Yes, but my gut feeling is that existing implementations
David> of the SNMP protocol have certain expectations for how OIDs are
David> formulated.

I agree.  I'm not saying that code wouldn't have to be added/changed.
Mine certainly would.  But then, I'm going to have to do that anyway
to support a new SMI language in the first place.  And, I'll probably
have to write a lot more code in order to get the mappings to happen
easily since I'll have to store a hierarchical class structure mapping
to a flat column number.

In short, if an application doesn't know about the mib in question it
probably can't interpret much as is from the OID.

David> I wonder if any actually expect to see, say the .1 row sub
David> OID.

I don't understand this sentence, I'm afraid.

David> Another question: during the transition phase from SMIv2 to
David> SMIng, do we expect the new and old tools to overlap. If yes,
David> even the new SMIng definitions may still need to be translated
David> to SMIv2 MIBs.

That was the exact question I was getting at in the first message.  I
was making the case that we should consider it.  Limiting the language
to requirements that allow complete backwards compatibility means you
can't do "certain things" like the ones I've stated plus others.

David> Some of the existing MIB tools are tightly dependent on a
David> particular SNMP protocol stack, and obviously will not be able
David> to generate/interpret hierarchical table definitions (unless,
David> you add a row entry value for every contained class, forcing
David> every contained class to look like a separate table oid-wise,
David> but indexed the same).

Right.  Do we require the new language to supply only minimal changes
to a given current code base?  Or can we rethink not only how we
represent data textually but binarily (I love making up words) as
well?  Must the textual data *always* be mapped into the *exact same
structures* that exist today?  Must SMIng -> SMIv2 mappings *always*
be possible?

-- 
Wes Hardaker
NAI Labs
Network Associates