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

[Wes Hardaker <wes@hardakers.net>]

>>>>> On Fri, 5 Jan 2001 10:48:14 -0800 , "Durham, David" <david.durham@intel.com> said:

David> [Dave] So, it sounds like in any case sming would still require
David> the explicit table mapping for backward compatibility reasons.

Correct.  If backwards compatibility for a table is desired.  If not,
then ...

David> I still have some questions regarding reversioning if the
David> alternative approach was used for new mibs however. What if one
David> inserts a new class between two others in the inheritance
David> hierarchy? That is, what if ClassA <- ClassC later becomes
David> ClassA <- ClassB <- ClassC? Or what if someone inserts new
David> attributes in the middle of an existing class? How would such
David> things affect the mapping?

Well, certainly these are issues that need to be resolved.  I hadn't
thought of the new-inheritance one, but for the other I was thinking
that attributes of published classes aren't allowed to be re-ordered
or deleted (though they can be marked as obsolete, or something
similar).  In the same sense, I'd probably say that adding a new child
is illegal.  The classA <- classB,classC, where classB <- classD and
classC <- classD (multiple identical super-parents) is also a issue
that will have to be resolved iff [sic] multiple inheritance is going
to be supported.

David> The idea of using the oids more intelligently, and mapping them
David> closer to the class structure sounds intriguing. Certainly it
David> would simplify the mapping process. Would you be willing to
David> write up a formal proposal on how the non-tabular approach
David> would work so the WG can better assess the pros & cons (and
David> determine what changes would be required for implementations)?

I'd be happy to do it if the WG thought it would be beneficial.  I was
really going to wait and propose it after my question that started all
this had gotten answered:  "Is option D to be considered"?  If we MUST
support mapping back to SMIv2 for all new mib objects, then this whole
discussion is pointless.

I've been surprised that no-one else has joined the conversation.  I'd
expected more people to come forward and tell me it was a bad idea
because they'd have to write too much new code (even though in the end
they'd write less, imho).

-- 
Wes Hardaker
NAI Labs
Network Associates