RE: SMIng consensus issues restated, call for consensus ends Sept embe r 18, 2002
"Harrington, David" <[email protected]> Wed, 18 Sep 2002 09:26:33 -0400
| Newsgroups | gmane.ietf.sming |
|---|---|
| Message-ID | <6D745637A7E0F94DA070743C55CDA9BA0757F5@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_01C25F17.01B1AC58 Content-Type: text/plain Hi Frank, You asked for other peoples' reviews. My comments inline. [note: if anybody receives this in MIME/HTML format, please be assured that I have set every setting known to me, my IT department, and Ran Atkinson to send this in plain text. If you can't read it easily, turn off MIME interpretation in your client.] dbh > -----Original Message----- > From: Frank Strauss [mailto:[email protected]] [...] > What's the goal of SMING? - Sure, we want to come up a with a new > language that makes it > easier to express the model behind a device or service, so that it's > easier to generate better code skeletons for new agent > development, and > easier to generate better code stubs for new manager development. > > Up to this point, I think we agree. As I recall, we reached the conclusion at the meeting, and in a number of earlier meetings, that the goal of SMING is to make MIB development and use easier for humans, not necessarily for compiler writers. There are very few people who need to write code generators; there are lots and lots of people who need to be able to write and to read mibs. You seem to be of the impression that our goal is to make it easier for code generators. I don't agree that's the general goal. I don't think you'll find many that think that is the goal. > > Now, what I think the SMING should try to achieve is a future > situation that allows us to use not only totally new SMING MIBs to > develop new (parts of) agents and managers, but also to use updated > and annotated MIBs of those 100+ Standard MIBs (which will remain the > most important ones for many years) to easier develop new agents > talking to all (old and new) existing managers, easier develop new > managers talking to all (old and new) existing agents. > I responded to the existing discussion of this issue under a different sibject line. Note that during the meeting(s), I believe we concluded support for annotations (as guidance for compiler-based applications) was also not a goal because they could lead to issues of interoperability. If you want to debate whether annotations for compiler-usage are important, I suggest you raise it in a different thread with a narrower subject line. [DavidD - should this be explicitly listed in a consensus call?] > I believe that this kind of a compatible transition is a very > important > goal. And it requires to stick with what I called `semantics of what > is transported on the wire' in recent messages. > > Based on this thinking my opinions on the consensus issues posted by > David D. are as follows... > > DD> 2. That the sming take advantage of the hierarchical oid namespace > DD> to achieve consensus item number 1. That is, the naming scheme > DD> should map directly to the n-levels of nesting as is in Andy > DD> Bierman's smi-ds proposal. [See the 53rd IETF SMIng meeting > DD> minutes for more details] > > Due to my above reasonings I disagree that the naming scheme should > be changed. BTW, I did not see a proof that this is > necessary, although > I agree that it looks more intuitive to reflect the structure in the > naming. However, the consequences of such a change would > cause too severe > incompatibilities. I'm not sure what you have in mind that would add nesting to the existing OID hierarchy without changing it. dbh ------_=_NextPart_001_01C25F17.01B1AC58 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: SMIng consensus issues restated, call for consensus ends = Septembe r 18, 2002</TITLE> </HEAD> <BODY> <P><FONT SIZE=3D2>Hi Frank,</FONT> </P> <P><FONT SIZE=3D2>You asked for other peoples' reviews. My comments = inline.</FONT> </P> <P><FONT SIZE=3D2>[note: if anybody receives this in MIME/HTML format, = please be assured that I have set every setting known to me, my IT = department, and Ran Atkinson to send this in plain text. If you can't = read it easily, turn off MIME interpretation in your = client.]</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>[...] </FONT> <BR><FONT SIZE=3D2>> What's the goal of SMING? - Sure, we want to = come up a with a new</FONT> <BR><FONT SIZE=3D2>> language that makes it</FONT> <BR><FONT SIZE=3D2>> easier to express the model behind a = device or service, so that it's</FONT> <BR><FONT SIZE=3D2>> easier to generate better code skeletons = for new agent </FONT> <BR><FONT SIZE=3D2>> development, and</FONT> <BR><FONT SIZE=3D2>> easier to generate better code stubs for = new manager development.</FONT> <BR><FONT SIZE=3D2>> </FONT> <BR><FONT SIZE=3D2>> Up to this point, I think we agree.</FONT> </P> <P><FONT SIZE=3D2>As I recall, we reached the conclusion at the = meeting, and in a number of earlier meetings, that the goal of SMING is = to make MIB development and use easier for humans, not necessarily for = compiler writers. There are very few people who need to write code = generators; there are lots and lots of people who need to be able to = write and to read mibs.</FONT></P> <P><FONT SIZE=3D2>You seem to be of the impression that our goal is to = make it easier for code generators. I don't agree that's the general = goal. I don't think you'll find many that think that is the = goal.</FONT></P> <P><FONT SIZE=3D2>> </FONT> <BR><FONT SIZE=3D2>> Now, what I think the SMING should try to = achieve is a future</FONT> <BR><FONT SIZE=3D2>> situation that allows us to use not only = totally new SMING MIBs to</FONT> <BR><FONT SIZE=3D2>> develop new (parts of) agents and managers, but = also to use updated</FONT> <BR><FONT SIZE=3D2>> and annotated MIBs of those 100+ Standard MIBs = (which will remain the</FONT> <BR><FONT SIZE=3D2>> most important ones for many years) to easier = develop new agents</FONT> <BR><FONT SIZE=3D2>> talking to all (old and new) existing managers, = easier develop new</FONT> <BR><FONT SIZE=3D2>> managers talking to all (old and new) existing = agents.</FONT> <BR><FONT SIZE=3D2>> </FONT> </P> <P><FONT SIZE=3D2>I responded to the existing discussion of this issue = under a different sibject line. </FONT> </P> <P><FONT SIZE=3D2>Note that during the meeting(s), I believe we = concluded support for annotations (as guidance for compiler-based = applications) was also not a goal because they could lead to issues of = interoperability. If you want to debate whether annotations for = compiler-usage are important, I suggest you raise it in a different = thread with a narrower subject line.</FONT></P> <P><FONT SIZE=3D2>[DavidD - should this be explicitly listed in a = consensus call?]</FONT> </P> <P><FONT SIZE=3D2>> I believe that this kind of a compatible = transition is a very </FONT> <BR><FONT SIZE=3D2>> important</FONT> <BR><FONT SIZE=3D2>> goal. And it requires to stick with what = I called `semantics of what</FONT> <BR><FONT SIZE=3D2>> is transported on the wire' in recent = messages.</FONT> <BR><FONT SIZE=3D2>> </FONT> <BR><FONT SIZE=3D2>> Based on this thinking my opinions on the = consensus issues posted by</FONT> <BR><FONT SIZE=3D2>> David D. are as follows...</FONT> <BR><FONT SIZE=3D2>> </FONT> <BR><FONT SIZE=3D2>> DD> 2. That the sming take advantage of the = hierarchical oid namespace</FONT> <BR><FONT SIZE=3D2>> DD> to achieve consensus item number 1. That = is, the naming scheme</FONT> <BR><FONT SIZE=3D2>> DD> should map directly to the n-levels of = nesting as is in Andy</FONT> <BR><FONT SIZE=3D2>> DD> Bierman's smi-ds proposal. [See = the 53rd IETF SMIng meeting</FONT> <BR><FONT SIZE=3D2>> DD> minutes for more details]</FONT> <BR><FONT SIZE=3D2>> </FONT> <BR><FONT SIZE=3D2>> Due to my above reasonings I disagree that the = naming scheme should</FONT> <BR><FONT SIZE=3D2>> be changed. BTW, I did not see a proof that = this is </FONT> <BR><FONT SIZE=3D2>> necessary, although</FONT> <BR><FONT SIZE=3D2>> I agree that it looks more intuitive to reflect = the structure in the</FONT> <BR><FONT SIZE=3D2>> naming. However, the consequences of such a = change would </FONT> <BR><FONT SIZE=3D2>> cause too severe</FONT> <BR><FONT SIZE=3D2>> incompatibilities.</FONT> </P> <P><FONT SIZE=3D2>I'm not sure what you have in mind that would add = nesting to the existing OID hierarchy without changing it. </FONT> </P> <P><FONT SIZE=3D2>dbh</FONT> </P> </BODY> </HTML> ------_=_NextPart_001_01C25F17.01B1AC58--