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:strauss@ibr.cs.tu-bs.de]
[...]
> 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