RE: Nesting levels in existing mibs
"Harrington, David" <[email protected]> Wed, 18 Sep 2002 12:42:48 -0400
| Newsgroups | gmane.ietf.sming |
|---|---|
| Message-ID | <6D745637A7E0F94DA070743C55CDA9BA0757F8@NHROCMBX1.ets.enterasys.com> |
This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.
------_=_NextPart_001_01C25F32.6BF86674
Content-Type: text/plain
Hi Frank,
I participate regularly in my company's mib committee, and in reviewing mibs
for Bert. When we have an inexperienced mib writer develop a mib, we
frequently have problems because the underlying implementation that is being
instrumented by the mib is not designed as a bunch of flat tables. I think
every modern programming language supports multiple-level nesting in one
form or another.
By having a mib specification language that cannot properly represent the
programming language constructs used in the actual implementation, we make
it much harder for people to develop mibs. This shows up in the quality of
the design of mibs.
I know your attitude is that we should design an SMI that allows for
nesting, and then use tools to convert the mib from nested structures into
flat tables for 'on-the-wire' usage.
I think that approach misses some important points.
1) it may not be very easy to "unroll" complex structures into flat tables
automatically, and then convert the flat tables back into nested structures
for agent processing;
2) extra layers of conversion can significantly impact the performance of
agents and applications;
3) operators have spoken out strongly against applications that have to do a
lot of "conversion" of the data stream to make it understandable, because
when they are debugging, they don't want to add yet another
potentially-buggy layer of interpretation between them and the raw data; and
4) SMIv3 will presumably have some conceptual richness that cannot be
converted back to SMIv2. I expect much of that richness to be in the ability
to nest structures.
Many people argued that C++ was nothing more than a superset of C, and they
tried to use it just as they would C. Others recognized that the
object-oriented nature of C++ was tremendously powerful, and that power was
only accessible to those who accepted the paradigm shift between
object-oriented and procedural thinking. Backwards compatibility with C
should be used primarily as a transition mechanism; C code really needs to
be restructured to capture the full power of C++. I think that if we
restructure existing mibs, then we're really changing the mib so much it
isn't the same thing anymore.
I don't want to lose all those objects that we have already standardized,
but I don't want our efforts to be constrained by them. Dave Perkins made an
interesting observation about one of the proposals (I think for XML) - the
apparent improvement was not the result of the language being used, it was
the result of the re-engineering given 20/20 hindsight.
I propose that in the move to SMIv3, we consider restructuring the useful
existing mibs to take advantage of the object-oriented conceptual power of
SMIv3. Since SMIv2 is purely data driven, and SMI3 is supposed to become
somewhat object-oriented, I expect that we might move data elements defined
in existing mibs into class-like structures. I propose a field in the data
definitions contained in our SMIv3 "class" definitions that provide a
reference back to the equivalent SMIv2 object OID. I think there would need
to be two types of references - a pointer and a derivation. For example
(forgive my notation; I'm only trying to present the concept),
// an SMIv3 structure to manage interfaces
smiv3InterfaceClass {
ifAdminStatus
derived-from { ifEntry 7 }
[or SMIv2-instance { ifEntry 7 } ]
:: = { smiv3InterfaceClass 4 }
}
The derived-from represents a unique instance of the object for each class
that is instantiated; the SMIv2-instance is a reference to the same instance
that would be used for an SMIv2 request.
Using something like this would allow us to re-engineer the existing mibs
and provide a transition mechanism between the paradigms.
dbh
> -----Original Message-----
> From: Frank Strauss [mailto:[email protected]]
> Sent: Wednesday, September 18, 2002 10:12 AM
> To: Harrington, David
> Cc: '[email protected]'
> Subject: Re: Nesting levels in existing mibs
>
>
> Hi!
>
> Thank you very much, David, for your response!
>
> David> I believe it is important for existing applications to be able
> David> to continue to work with the existing mibs. As a goal, the
> David> members of the meeting seemed happy with the approach that
> David> existing mibs do not get extended with the new functionality.
>
> I understand and agree to this position.
>
> David> If you add SMIv2-incompatible extensions to existing mibs, then
> David> they may not work properly unless the applications are
> David> modified; if they require modification to understand when n>1
> David> then they are no longer the existing applications.
>
> That's what I don't like about SMI-DS. I support a solution that
> allows to make use of new features like nested data structures without
> the need for an n>1 layering in the naming when data is transported.
> This would, e.g., allow to have an agent developed based on the new
> data structures communicating to a manager built with a traditional
> SMIv2 based toolkit. Generating the SMIv2 MIB from a MIB in the new
> format could be completely automated.
>
> David> Andy's proposal for OID indexing to n>1 levels was also found
> David> to be a reasonable approach by the members of the meeting. I
> David> don't know what you have in mind.
>
> If COPS support would still be one goal, then the current NMRG-based
> proposal is quite close to what I have in mind, and that's why there
> has not been the need to write something new down, so far.
>
> If we really drop COPS support from the charter, then I would migrate
> the OID naming back to the core of SMIng (and I would really like to
> have a single module again for a single target MIB). In this case, the
> process of flatting the n levels of contained structures to
> traditional tables could be based on an implied sequence of
> column-identifying sub-ids starting at 1 in the order given by the
> containment tree's pre-order. Problems occur when new attributes are
> added to contained structs. Then the ordering of columns in the
> containing flattened table must not change. This could probably be
> assured by recognizing the version's LAST-UPDATED clauses of the
> affected MIBs.
>
> David> I don't mind supporting such a thing if it would be not delay
> David> the development of SMIv3, and would be easy to understand for
> David> human mib readers and mib writers.
>
> David> I certainly see that mib-writers working on existing SMIv2 mibs
> David> could easily make a mistake of adding an SMIv3 feature to an
> David> SMIv2 mib and cause problems for existing applications. A
> David> solution as simple as "an SNMPv1 agent doesn't recognize
> David> Counter64 typed objects for an SNMPv1 request" would suit me.
>
> Then, what would the future look like in 5 year, assuming SMI-DS is
> the new successful SMIv3? I would expect that we would have a majority
> of, say, 80% SMIv2 MIBs (maybe they are labeled SMIv3 after a
> revision, but in fact they cannot make use of the SMIv3 features that
> would make them reusable, more readable, easier to understand and
> easier to implement) and 20% SMIv3 MIBs.
>
> David> But before I throw behind my support such a goal, I need to be
> David> convinced it is feasible; can you elaborate on your proposal of
> David> how to achieve it within the scope of Andy's OID nesting?.
>
> David> Can you explain how we can
> David> 1) use Andy's approach to OID nesting
> David> 2) add nesting levels to existing mibs
> David> 3) allow existing applications, without modifications, to
> David> continue to work with existing mibs that have been extended?
>
> First of all, when people design information models and when they
> derive data models thereof they usually don't think in OIDs. They
> think in class names and attribute names. Attributes can be simple
> types or in turn complex types (no matter whether we name them classes
> or structs or whatever at this point). The point where OIDs appear
> should - in my opinion - remain limited to the the protocol. Of course
> this requires that OIDs appear in the mapping from the data model
> to the protocol.
>
> How nesting would look like is described for example in
> draft-ietf-sming-inet-modules, where, e.g., class
> InetTransportEndpoint contains an attribute of class
> InetNetworkEndpoint and an attribute of type InetPortNumber. Mapping
> such classes to SNMP tables is described in draft-ietf-sming-snmp.txt.
>
> I assume, that we all don't really like to have a split of core
> definitions and SNMP mappings, but this is - as far as I can tell -
> the best approach to achieve the charter's goal to support SNMP as
> well as COPS-PR. Since it seems now quite obvious that the WG will
> drop COPS-PR support, I would remove the need for the SNMP mapping
> statements and integrate the necessary naming stuff as `oid'
> sub-statements to the class and classes' attribute statements. I know,
> a more detailed scheme is required here. But I think this is doable.
> I cannot come up with a concrete proposal, but I think it's more
> important to first make sure whether the WG prefers the new SMI-DS
> naming (as it looked like to me during the past months, hence I
> refrained from working on changes in the draft-ietf-sming-*
> documents).
>
>
> -frank
>
------_=_NextPart_001_01C25F32.6BF86674
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3DUS-ASCII">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2655.35">
<TITLE>RE: Nesting levels in existing mibs</TITLE>
</HEAD>
<BODY>
<P><FONT SIZE=3D2>Hi Frank,</FONT>
</P>
<P><FONT SIZE=3D2>I participate regularly in my company's mib =
committee, and in reviewing mibs for Bert. When we have an =
inexperienced mib writer develop a mib, we frequently have problems =
because the underlying implementation that is being instrumented by the =
mib is not designed as a bunch of flat tables. I think every modern =
programming language supports multiple-level nesting in one form or =
another. </FONT></P>
<P><FONT SIZE=3D2>By having a mib specification language that cannot =
properly represent the programming language constructs used in the =
actual implementation, we make it much harder for people to develop =
mibs. This shows up in the quality of the design of mibs.</FONT></P>
<P><FONT SIZE=3D2>I know your attitude is that we should design an SMI =
that allows for nesting, and then use tools to convert the mib from =
nested structures into flat tables for 'on-the-wire' usage.</FONT></P>
<P><FONT SIZE=3D2>I think that approach misses some important points. =
</FONT>
<BR><FONT SIZE=3D2>1) it may not be very easy to "unroll" =
complex structures into flat tables automatically, and then convert the =
flat tables back into nested structures for agent processing; =
</FONT></P>
<P><FONT SIZE=3D2>2) extra layers of conversion can significantly =
impact the performance of agents and applications; </FONT>
<BR><FONT SIZE=3D2>3) operators have spoken out strongly against =
applications that have to do a lot of "conversion" of the =
data stream to make it understandable, because when they are debugging, =
they don't want to add yet another potentially-buggy layer of =
interpretation between them and the raw data; and</FONT></P>
<P><FONT SIZE=3D2>4) SMIv3 will presumably have some conceptual =
richness that cannot be converted back to SMIv2. I expect much of that =
richness to be in the ability to nest structures. </FONT></P>
<P><FONT SIZE=3D2>Many people argued that C++ was nothing more than a =
superset of C, and they tried to use it just as they would C. Others =
recognized that the object-oriented nature of C++ was tremendously =
powerful, and that power was only accessible to those who accepted the =
paradigm shift between object-oriented and procedural thinking. =
Backwards compatibility with C should be used primarily as a transition =
mechanism; C code really needs to be restructured to capture the full =
power of C++. I think that if we restructure existing mibs, then we're =
really changing the mib so much it isn't the same thing =
anymore.</FONT></P>
<P><FONT SIZE=3D2>I don't want to lose all those objects that we have =
already standardized, but I don't want our efforts to be constrained by =
them. Dave Perkins made an interesting observation about one of the =
proposals (I think for XML) - the apparent improvement was not the =
result of the language being used, it was the result of the =
re-engineering given 20/20 hindsight.</FONT></P>
<P><FONT SIZE=3D2>I propose that in the move to SMIv3, we consider =
restructuring the useful existing mibs to take advantage of the =
object-oriented conceptual power of SMIv3. Since SMIv2 is purely data =
driven, and SMI3 is supposed to become somewhat object-oriented, I =
expect that we might move data elements defined in existing mibs into =
class-like structures. I propose a field in the data definitions =
contained in our SMIv3 "class" definitions that provide a =
reference back to the equivalent SMIv2 object OID. I think there would =
need to be two types of references - a pointer and a derivation. For =
example (forgive my notation; I'm only trying to present the concept), =
</FONT></P>
<P><FONT SIZE=3D2>// an SMIv3 structure to manage interfaces</FONT>
</P>
<P><FONT SIZE=3D2>smiv3InterfaceClass {</FONT>
<BR> <FONT =
SIZE=3D2>ifAdminStatus</FONT>
<BR> =
<FONT SIZE=3D2>derived-from =
{ ifEntry 7 }</FONT>
<BR> =
<FONT SIZE=3D2>[or =
SMIv2-instance { ifEntry 7 } ]</FONT>
<BR> <FONT SIZE=3D2>:: =3D { =
smiv3InterfaceClass 4 }</FONT>
<BR><FONT SIZE=3D2>} </FONT>
</P>
<P><FONT SIZE=3D2>The derived-from represents a unique instance of the =
object for each class that is instantiated; the SMIv2-instance is a =
reference to the same instance that would be used for an SMIv2 =
request.</FONT></P>
<P><FONT SIZE=3D2>Using something like this would allow us to =
re-engineer the existing mibs and provide a transition mechanism =
between the paradigms.</FONT></P>
<P><FONT SIZE=3D2>dbh</FONT>
</P>
<P><FONT SIZE=3D2>> -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>> From: Frank Strauss [<A =
HREF=3D"mailto:[email protected]">mailto:[email protected]</=
A>]</FONT>
<BR><FONT SIZE=3D2>> Sent: Wednesday, September 18, 2002 10:12 =
AM</FONT>
<BR><FONT SIZE=3D2>> To: Harrington, David</FONT>
<BR><FONT SIZE=3D2>> Cc: '[email protected]'</FONT>
<BR><FONT SIZE=3D2>> Subject: Re: Nesting levels in existing =
mibs</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> Hi!</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> Thank you very much, David, for your =
response!</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> David> I believe it is important for =
existing applications to be able</FONT>
<BR><FONT SIZE=3D2>> David> to continue to work with the existing =
mibs. As a goal, the</FONT>
<BR><FONT SIZE=3D2>> David> members of the meeting seemed happy =
with the approach that</FONT>
<BR><FONT SIZE=3D2>> David> existing mibs do not get extended =
with the new functionality.</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> I understand and agree to this position. =
</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> David> If you add SMIv2-incompatible =
extensions to existing mibs, then</FONT>
<BR><FONT SIZE=3D2>> David> they may not work properly unless the =
applications are</FONT>
<BR><FONT SIZE=3D2>> David> modified; if they require =
modification to understand when n>1</FONT>
<BR><FONT SIZE=3D2>> David> then they are no longer the existing =
applications.</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> That's what I don't like about SMI-DS. I =
support a solution that</FONT>
<BR><FONT SIZE=3D2>> allows to make use of new features like nested =
data structures without</FONT>
<BR><FONT SIZE=3D2>> the need for an n>1 layering in the naming =
when data is transported. </FONT>
<BR><FONT SIZE=3D2>> This would, e.g., allow to have an agent =
developed based on the new</FONT>
<BR><FONT SIZE=3D2>> data structures communicating to a manager =
built with a traditional</FONT>
<BR><FONT SIZE=3D2>> SMIv2 based toolkit. Generating the SMIv2 MIB =
from a MIB in the new</FONT>
<BR><FONT SIZE=3D2>> format could be completely automated.</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> David> Andy's proposal for OID indexing to =
n>1 levels was also found</FONT>
<BR><FONT SIZE=3D2>> David> to be a reasonable approach by the =
members of the meeting. I</FONT>
<BR><FONT SIZE=3D2>> David> don't know what you have in =
mind.</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> If COPS support would still be one goal, then =
the current NMRG-based</FONT>
<BR><FONT SIZE=3D2>> proposal is quite close to what I have in mind, =
and that's why there</FONT>
<BR><FONT SIZE=3D2>> has not been the need to write something new =
down, so far.</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> If we really drop COPS support from the =
charter, then I would migrate</FONT>
<BR><FONT SIZE=3D2>> the OID naming back to the core of SMIng (and I =
would really like to</FONT>
<BR><FONT SIZE=3D2>> have a single module again for a single target =
MIB). In this case, the</FONT>
<BR><FONT SIZE=3D2>> process of flatting the n levels of contained =
structures to</FONT>
<BR><FONT SIZE=3D2>> traditional tables could be based on an implied =
sequence of</FONT>
<BR><FONT SIZE=3D2>> column-identifying sub-ids starting at 1 in the =
order given by the</FONT>
<BR><FONT SIZE=3D2>> containment tree's pre-order. Problems occur =
when new attributes are</FONT>
<BR><FONT SIZE=3D2>> added to contained structs. Then the ordering =
of columns in the</FONT>
<BR><FONT SIZE=3D2>> containing flattened table must not change. =
This could probably be</FONT>
<BR><FONT SIZE=3D2>> assured by recognizing the version's =
LAST-UPDATED clauses of the</FONT>
<BR><FONT SIZE=3D2>> affected MIBs.</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> David> I don't mind supporting such a thing =
if it would be not delay</FONT>
<BR><FONT SIZE=3D2>> David> the development of SMIv3, and would =
be easy to understand for</FONT>
<BR><FONT SIZE=3D2>> David> human mib readers and mib =
writers.</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> David> I certainly see that mib-writers =
working on existing SMIv2 mibs</FONT>
<BR><FONT SIZE=3D2>> David> could easily make a mistake of adding =
an SMIv3 feature to an</FONT>
<BR><FONT SIZE=3D2>> David> SMIv2 mib and cause problems for =
existing applications. A</FONT>
<BR><FONT SIZE=3D2>> David> solution as simple as "an SNMPv1 =
agent doesn't recognize</FONT>
<BR><FONT SIZE=3D2>> David> Counter64 typed objects for an SNMPv1 =
request" would suit me.</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> Then, what would the future look like in 5 =
year, assuming SMI-DS is</FONT>
<BR><FONT SIZE=3D2>> the new successful SMIv3? I would expect that =
we would have a majority</FONT>
<BR><FONT SIZE=3D2>> of, say, 80% SMIv2 MIBs (maybe they are labeled =
SMIv3 after a</FONT>
<BR><FONT SIZE=3D2>> revision, but in fact they cannot make use of =
the SMIv3 features that</FONT>
<BR><FONT SIZE=3D2>> would make them reusable, more readable, easier =
to understand and</FONT>
<BR><FONT SIZE=3D2>> easier to implement) and 20% SMIv3 MIBs.</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> David> But before I throw behind my support =
such a goal, I need to be</FONT>
<BR><FONT SIZE=3D2>> David> convinced it is feasible; can you =
elaborate on your proposal of</FONT>
<BR><FONT SIZE=3D2>> David> how to achieve it within the scope of =
Andy's OID nesting?.</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> David> Can you explain how we can </FONT>
<BR><FONT SIZE=3D2>> David> 1) use Andy's approach to OID =
nesting</FONT>
<BR><FONT SIZE=3D2>> David> 2) add nesting levels to existing =
mibs</FONT>
<BR><FONT SIZE=3D2>> David> 3) allow existing applications, =
without modifications, to</FONT>
<BR><FONT SIZE=3D2>> David> continue to work =
with existing mibs that have been extended?</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> First of all, when people design information =
models and when they</FONT>
<BR><FONT SIZE=3D2>> derive data models thereof they usually don't =
think in OIDs. They</FONT>
<BR><FONT SIZE=3D2>> think in class names and attribute names. =
Attributes can be simple</FONT>
<BR><FONT SIZE=3D2>> types or in turn complex types (no matter =
whether we name them classes</FONT>
<BR><FONT SIZE=3D2>> or structs or whatever at this point). The =
point where OIDs appear</FONT>
<BR><FONT SIZE=3D2>> should - in my opinion - remain limited to the =
the protocol. Of course</FONT>
<BR><FONT SIZE=3D2>> this requires that OIDs appear in the mapping =
from the data model</FONT>
<BR><FONT SIZE=3D2>> to the protocol. </FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> How nesting would look like is described for =
example in</FONT>
<BR><FONT SIZE=3D2>> draft-ietf-sming-inet-modules, where, e.g., =
class</FONT>
<BR><FONT SIZE=3D2>> InetTransportEndpoint contains an attribute of =
class</FONT>
<BR><FONT SIZE=3D2>> InetNetworkEndpoint and an attribute of type =
InetPortNumber. Mapping</FONT>
<BR><FONT SIZE=3D2>> such classes to SNMP tables is described in =
draft-ietf-sming-snmp.txt.</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> I assume, that we all don't really like to have =
a split of core</FONT>
<BR><FONT SIZE=3D2>> definitions and SNMP mappings, but this is - as =
far as I can tell -</FONT>
<BR><FONT SIZE=3D2>> the best approach to achieve the charter's goal =
to support SNMP as</FONT>
<BR><FONT SIZE=3D2>> well as COPS-PR. Since it seems now quite =
obvious that the WG will</FONT>
<BR><FONT SIZE=3D2>> drop COPS-PR support, I would remove the need =
for the SNMP mapping</FONT>
<BR><FONT SIZE=3D2>> statements and integrate the necessary naming =
stuff as `oid'</FONT>
<BR><FONT SIZE=3D2>> sub-statements to the class and classes' =
attribute statements. I know,</FONT>
<BR><FONT SIZE=3D2>> a more detailed scheme is required here. But I =
think this is doable.</FONT>
<BR><FONT SIZE=3D2>> I cannot come up with a concrete proposal, but =
I think it's more</FONT>
<BR><FONT SIZE=3D2>> important to first make sure whether the WG =
prefers the new SMI-DS</FONT>
<BR><FONT SIZE=3D2>> naming (as it looked like to me during the past =
months, hence I</FONT>
<BR><FONT SIZE=3D2>> refrained from working on changes in the =
draft-ietf-sming-* </FONT>
<BR><FONT SIZE=3D2>> documents).</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> -frank</FONT>
<BR><FONT SIZE=3D2>> </FONT>
</P>
</BODY>
</HTML>
------_=_NextPart_001_01C25F32.6BF86674--