Nesting levels in existing mibs
"Harrington, David" <[email protected]> Wed, 18 Sep 2002 08:53:11 -0400
| Newsgroups | gmane.ietf.sming |
|---|---|
| Message-ID | <6D745637A7E0F94DA070743C55CDA9BA0757F4@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_01C25F12.57777C62 Content-Type: text/plain Hi Frank, I believe it is important for existing applications to be able to continue to work with the existing mibs. As a goal, the members of the meeting seemed happy with the approach that existing mibs do not get extended with the new functionality. If you add SMIv2-incompatible extensions to existing mibs, then they may not work properly unless the applications are modified; if they require modification to understand when n>1 then they are no longer the existing applications. Andy's proposal for OID indexing to n>1 levels was also found to be a reasonable approach by the members of the meeting. I don't know what you have in mind. I don't mind supporting such a thing if it would be not delay the development of SMIv3, and would be easy to understand for human mib readers and mib writers. I certainly see that mib-writers working on existing SMIv2 mibs could easily make a mistake of adding an SMIv3 feature to an SMIv2 mib and cause problems for existing applications. A solution as simple as "an SNMPv1 agent doesn't recognize Counter64 typed objects for an SNMPv1 request" would suit me. But before I throw behind my support such a goal, I need to be convinced it is feasible; can you elaborate on your proposal of how to achieve it within the scope of Andy's OID nesting?. Can you explain how we can 1) use Andy's approach to OID nesting 2) add nesting levels to existing mibs 3) allow existing applications, without modifications, to continue to work with existing mibs that have been extended? dbh > -----Original Message----- > From: Frank Strauss [mailto:[email protected]] > Sent: Wednesday, September 18, 2002 3:14 AM > To: Andy Bierman > Cc: '[email protected]'; Durham, David > Subject: Re: SMIng consensus issues restated, call for consensus ends > Septembe r 18, 2002 > > > Hi! > > I think we move in circles. The major point in which we have separate > opinions is that > > - you clearly separate between existing MIBs (that cannot benefit > from some new SMI-DS features when they are revised) and new MIBs, > while > > - I prefer a change from which both cases can benefit, but with the > disadvantage that the data structures at levels > 1 cannot be > addressed explicitly. > > Do you agree, Andy? > > I would also really appreciate comments on my reservations from other > WG members. > > -frank > ------_=_NextPart_001_01C25F12.57777C62 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>Nesting levels in existing mibs</TITLE> </HEAD> <BODY> <P><FONT SIZE=3D2>Hi Frank,</FONT> </P> <P><FONT SIZE=3D2>I believe it is important for existing applications = to be able to continue to work with the existing mibs. As a goal, the = members of the meeting seemed happy with the approach that existing = mibs do not get extended with the new functionality. </FONT></P> <P><FONT SIZE=3D2>If you add SMIv2-incompatible extensions to existing = mibs, then they may not work properly unless the applications are = modified; if they require modification to understand when n>1 then = they are no longer the existing applications.</FONT></P> <P><FONT SIZE=3D2>Andy's proposal for OID indexing to n>1 levels was = also found to be a reasonable approach by the members of the meeting. I = don't know what you have in mind. </FONT></P> <P><FONT SIZE=3D2>I don't mind supporting such a thing if it would be = not delay the development of SMIv3, and would be easy to understand for = human mib readers and mib writers. </FONT></P> <P><FONT SIZE=3D2>I certainly see that mib-writers working on existing = SMIv2 mibs could easily make a mistake of adding an SMIv3 feature to an = SMIv2 mib and cause problems for existing applications. A solution as = simple as "an SNMPv1 agent doesn't recognize Counter64 typed = objects for an SNMPv1 request" would suit me.</FONT></P> <P><FONT SIZE=3D2>But before I throw behind my support such a goal, I = need to be convinced it is feasible; can you elaborate on your proposal = of how to achieve it within the scope of Andy's OID = nesting?.</FONT></P> <P><FONT SIZE=3D2> </FONT> <BR><FONT SIZE=3D2>Can you explain how we can </FONT> <BR><FONT SIZE=3D2>1) use Andy's approach to OID nesting</FONT> <BR><FONT SIZE=3D2>2) add nesting levels to existing mibs</FONT> <BR><FONT SIZE=3D2>3) allow existing applications, without = modifications, to continue to work with existing mibs that have been = extended?</FONT> </P> <P><FONT SIZE=3D2>dbh</FONT> </P> <BR> <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 3:14 = AM</FONT> <BR><FONT SIZE=3D2>> To: Andy Bierman</FONT> <BR><FONT SIZE=3D2>> Cc: '[email protected]'; Durham, David</FONT> <BR><FONT SIZE=3D2>> Subject: Re: SMIng consensus issues restated, = call for consensus ends</FONT> <BR><FONT SIZE=3D2>> Septembe r 18, 2002</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>> I think we move in circles. The major point in = which we have separate</FONT> <BR><FONT SIZE=3D2>> opinions is that </FONT> <BR><FONT SIZE=3D2>> </FONT> <BR><FONT SIZE=3D2>> - you clearly separate between existing = MIBs (that cannot benefit</FONT> <BR><FONT SIZE=3D2>> from some new SMI-DS features = when they are revised) and new MIBs,</FONT> <BR><FONT SIZE=3D2>> while</FONT> <BR><FONT SIZE=3D2>> </FONT> <BR><FONT SIZE=3D2>> - I prefer a change from which both cases = can benefit, but with the</FONT> <BR><FONT SIZE=3D2>> disadvantage that the data = structures at levels > 1 cannot be</FONT> <BR><FONT SIZE=3D2>> addressed explicitly.</FONT> <BR><FONT SIZE=3D2>> </FONT> <BR><FONT SIZE=3D2>> Do you agree, Andy?</FONT> <BR><FONT SIZE=3D2>> </FONT> <BR><FONT SIZE=3D2>> I would also really appreciate comments on my = reservations from other</FONT> <BR><FONT SIZE=3D2>> WG members.</FONT> <BR><FONT SIZE=3D2>> </FONT> <BR><FONT SIZE=3D2>> -frank</FONT> <BR><FONT SIZE=3D2>> </FONT> </P> </BODY> </HTML> ------_=_NextPart_001_01C25F12.57777C62--