The language developed will enable the modeling of network management information in a manner that provides the benefits of object-oriented design. To achieve this, the language must allow the design of highly reusable syntactic/semantic components (templates) that can be reused by multiple IETF working groups for convenience, consistency, and to maximize interoperability in device management. A registration mechanism will also be described for reusable components defined using the language so that their existence and purpose may be archived.
The language will provide for the definition of a transport-independent model so as to allow a variety of implementation-specific technologies to be derived from a single definition. To demonstrate this, the working group will define two technology specific transport mappings: one for SNMP, and one for COPS.
The language will also provide:
- syntax optimized for parseability, human readability, and non-redundancy
- conventions for representing inheritance and containment of defined data
- enhanced attribute-level and association-level constraints
- a maximal amount of machine-parseable syntax so that programmatic tools can aid in modeling and implementation
- a language extension capability
This working group will also define typical usage scenarios for the language and highlight its features. Finally, it will develop a framework by which reusable components specified using this language can be registered and made readily available for continued reuse and improvement.
The working group will not define models for specific technologies, except as required for illustrative examples. Specific models are to be developed by the subject matter experts using the SMIng in the appropriate technology specific WGs.
| Done | IRTF documents complete & submitted to IETF | |
| Done | Submit Revised I-Ds including requirements I-D | |
| Done | Meet at 50th IETF | |
| Done | Submit revised I-D for requirements document | |
| Done | WG Last Call on requirements document as Informational RFC | |
| Done | Submit revised I-D for Data Definition Language and Usage document | |
| Done | Meet at 51st IETF | |
| Sep 01 | WG Last Call on Data Definition Language (syntax) documents as PS | |
| Sep 01 | WG Last Call on Usage document as Informational RFC | |
| Oct 01 | Revised I-D for Mapping documents for SNMP and COPS | |
| Nov 01 | WG Last Call on Mapping documents for SNMP and COPS as PS | |
| Nov 01 | Registrar framework defined for reusable components as an I-D | |
| Dec 01 | Meet at 52nd IETF | |
| Feb 02 | Last call on Registrar Framework document as Informational RFC | |
| Mar 02 | Meet at 53rd IETF | |
| Mar 02 | Working Group closes |
Current Meeting Report
SMIng WG Meeting Minutes from the 52nd IETF:
Minutes Reported by: Ravi Sahita, Sharon Chisholm and David Durham
Chair: David Durham
SMIng wg first session minutes (Thursday - 3:30pm -5:30pm)
Minutes from Ravi Sahita.
* Agenda bashing, status
The chair presented the agenda for Thursday and Friday,
Thursday agenda - listed draft proposals docs under discussion and informed the wg that the requirements/objectives draft has completed last call to become an informational RFC.
The objective was to submit the proposals based on the objectives document, and the proposals are to be discussed at this IETF.
* Juergen -nmrg proposal, status update
Implementation attempts from France - sming front end parser has been written in java, and is available as downloadable code. It has an HTML generator backend, and is available at jsman.com.
Alexandros Zachos is extending libsmi, written in C, with SMIv2/SPPI back-ends, and a sming core front-end parser. A first prototype is working and it will be integrated into libsmi; he has sent some draft links on the mailing list which maps the DiffServ SMIng MIB - mapping that to the DiffServ MIB and PIB.
Juergen proceeds to discuss the sming's compliance with accepted objectives, objective by objective. Objectives not yet completely supported by SMIng:
* Accessibility - SMIng: SNMP uses non-accessible for index objects, while conceptually we don't need that - it causes confusion. Hence access state in sming is just readable or writable.
* Special char syntax has been an objective for chars in description clauses - it's not there but should not be hard to do.
* Namespace control - currently sming uses module names to make sure there are no collisions, but there is no namespace control in current sming proposal, we need to just say we need infrastructure (like IANA).
* Module conformance - will start on this after the other stuff gets stable.
* Discriminated Unions - have to work on this.
* Instance Pointers - not in proposals because when mapping to both SNMP and SPPI, the instance identification is a problem.
* Reusable vs. attribute groups - attribute groups that you want to mark as instantiateable vs. non-instantiateable data structures - we don't distinguish between these.
* Extension rules - we didn't consider these at this point of time.
* Deprecate IMPLIED - SNMP still has it, we haven't used it, probably we want to reformulate by adding text that you shouldn't use it etc. to remain backward compatible.
* Methods - didn't work.
* Ref Tagged rows - doesn't exist in the sming proposal.
* I18n - currently ASCII still.
Questions:
Chair asked the question - who uses IMPLIED in SNMP?
Ans: Notification Log MIB. 2573 applications MIB has implied, proxy MIB, target MIB, notification MIB has it as well.
Chair asked if the diffserv SMIng mapping takes advantage of sming features such as reuse & structured data. Juergen: yes.
* Andy Bierman discusses his SMI-DS proposal:
The SMI-DS design goals were to improve the data modeling capability, make MIBs easier to read and write, make set operations easy o implement, to provide better reuse of data definitions as well as the reuse of associated manager and agent code. SMI-DS optimizes the instance naming (different than SMIv2) for containment and SNMP get next. SMI-DS is SMIv2 with its naming changed to allow C-like data structures: array, struct and UNION are the 3 base types. You can nest these in arbitrary ways. SMI-DS naming allows arrays within arrays and other complex containment.
- Ease of use is a very important topic and should be the wg's design ideology... We are currently trying to optimize for the MIB compiler writers and that's wrong, we really need to decide: do we need these kinds of syntax elements like a semicolon after every statement. Also, remove redundant text which simply causes more mistakes. ASN1 sequence: mapping with syntax clause object causes errors, so removed sequence clause.
- Currently the SMI does not allow any thing other that scalars, we can use augments, sparse augments, shared indices and clones of shared indices but the relationship between these objects is not maintained. We should be able to map the natural, nested data structures we use every day to the data model. But we can't do this today. Eg. If they are writable objects, I have multiple row status, we have serious complications to deal with if they are collapsed back together.
- We want code reuse in the agents so SMI-DS maintains the object relationship in the naming. We want nested handlers - not just one handle. Today we simply don't give any capability for data nor code reuse.
- Also, SMI-DS extends the augment concept to data objects, because currently cut and paste is the only possibility to achieve reuse.
- For SMI-DS unions, only one item is returned. Which item is determined thru the naming, the oid is the discriminator (don't need extra type discriminator attributes as in SMIv2).
- Mapping smiv2 to smi-ds, aggregate types map to sequence, SCALARs map to scalar. There are corner cases that deal with limitation due to smiv2 hacks, but it is possible to create a smiv2 definition from the smi-ds... not the same naming, but same semantics, e.g. a sequence is an array in the reverse direction.
- SMI-DS does away with all those needless rules in the SMI that simply make it hard to use. BCPs should address potential misuse problems, not a huge number of language rules.
Open issues:
Descriptors for array index - there are none - since not accessible. Mapping to SPPI is not done. But it should be easy to map back to SPPI naming where anything is simply an integer index. There are going to need to be descriptors. For the array index there is no notion of by reference vs. by copy of. There is no uniqueness clause. There is no ABNF syntax.
Summary: We need to advance data modeling caps. But we should optimize for readers first, then writers, and last come the compiler writers. When there are tradeoffs between readability and parseability - we should lean towards readability. Finally, we need to provide trans to smiv2 for trans, but we should optimize for the features we want moving forward, just like we want fort smiv1 to v2. If you can never use the thing because its features are not in the old one, then that's no value. Yes we have a transition period, but not lose the value.
Questions:
randy - you can still get the reuse today - there is more than one way to do your code generation. Knowing there is a shared index, you can share code. It's the cloned index, which is a problem. Andy: the only way is to read the MIB at the agent.
randy - is the augment really applied globally or for that typedef, if used in 10 diff places? the aug will be inappropriate for one of the usages?
Andy-then you would need sparse augments. Does the augment apply to the typedef or usage to typedef? Andy-applies to the typedef.
dp - Are the current SNMP protocol operations supported? Yes - do you have ideas for new proto operations?
ab - smiv2 is totally untouched, since I don't believe it's broken, there is no need to change syntax things. In SNMP you do a get next on the table, it's only the accessible objects that is something you get/set, and also those same accessible objects that go in the module compliance we don't say not-accessible there.
dp-so the current protocol ops support this?
Ab - we need new protocol ops to support aggregate objects which is a transport change, but current protocol ops will still work even with the new naming scheme.
wes -Like it. Any effort to reduce the amount of text needed for reordering relationships?
ab-There are not that many places where reordering happens, but this would be a great optimization, right now what we do is another mapping and have other glue in the descriptions that says this is not the real obj that's that one.
rp - subid usage is unique, that's kind of neat. However, the order in which objects come out changes and vacm instance views are formulated with variable length indexing, for example, restrict access to an object with variable length indexing you wont be able do that with a simple vacm policy.
ab - haven't given enough thought to VACM.
js - The typedef is where you define the index which means you can't do reordering any more, since its associated with that typedef. Once you define the index as a,b, you cant re-define this complex type somewhere else where index is just a. That's why NMRG moved the indexing to the instantiation.
ab - But that seems to make it harder to use for humans, I don't want to go through the rest of the docs to understand things.
rp- There is a distinction between reuse of defined data type vs. the actual use of the data type in the identification of a variable in an actual object instance, this is where different network management models differ widely. At what stage do you put constraints on naming? In cmip object definition doesn't say anything since there is a separate name binding. In smi there is the other extreme where all naming is nailed down in the object definition. Therefore, cloning is the only way to get reuse in the smi. ab - The naming scheme is coupled with the data definition, I don't see the reason for separating the mapping. js - Instance naming in c is the memory address, the struct doesn't have define the instance naming scheme. ab-I think it'll be hard for humans to use it if the instance naming is defined somewhere else.
Randy is going to take his point on the mailing list about the issue 'to define the binding of the index information within the class definition' to the mailing list.
* ASN.1 for SMIng - A Triglia leads the discussion:
Believes ASN1 is a good base for a language like SMIng. The main concern was to meet the objectives that were stated for the SMIng. The design goals were to specify a new language that complies with the objectives, and enable mib writers to define complex data structures like combining arrays, structures, and unions in arbitrary ways. To separate the reusable classes, the ASN1 proposal has the concepts of entity class and entry instance. This proposal provides a flexible instance naming scheme, for smi flat tables and for more complex data structures. Proposal took into account all work that had been done in the other proposals. Proposing as an option two different naming schemes, traditional smi naming scheme (tabular), and then a hierarchical naming scheme. The last goal was to provide a data model for both SNMP and COPS-PR.
The first example (slide 2) shows this proposal hasn't changed much from the existing smi. There are slight diffs in specific cases, there are some braces but otherwise the meaning is the same. The biggest change is that there is no oid is associated with a definition. The last example is of the compliance statement the syntax is very similar to the old smi syntax without any additional macros.
The Proposal features separation between entity classes and entity instances. Types can be reused as multiple objects of the same constrained or unconstrained data types, and multiple complex data structures, where you define a structure and another where the previous one appears as a component. Entity classes names each subordinate components by relative oids, entry classes don't specify the instance names (subids) but do specify parts of the name. When instantiating a table as an object, every component below the base oid gets assigned the relative oids, SNMP will have visibility of only atomic data items, that are often leaf level components. cops-pr has visibility only of structures that consist entirely of atomic items.
Questions:
js - What is the diff between your hierarchical naming scheme and Andy's naming scheme?
at - for me extensibility is an option, then you have a zero, otherwise it is the same.
s1- The same SMI-DS problem with vacm would exist in this proposal then.
at- here you can choose what type of table you want: traditional or hierarchical.
dp: Do union elements have to be same of the same type? at: No.
* Jeff Case - Proposal SMIv3:
There are several kinds of changes we might make changes to the SMI and SPPI. 1. The required maintenance, this has a good cost vs. benefit ratio, so we should make changes only if there is a favorable c/b ratio. My proposal has some changes of additional data types and some things that SPPI/COPS-PR has.
2. Advancing the state of the art - some such changes may be controversial, may have poor c/b ratio. My favorites are - aggregate objects with multiple indices on table and all that implies. My prop to the list was misunderstood, there is much but not 100% overlap with smi-ds. Also we should be closely coupled with eos. I started looking at the c data structures in the protocol, while Andy was looking at adding them to the mib. In my proposal we don't have reordering of indices. Instead of a row identifier I have a chunk identifier, and a subchunk identifier. But I didn't put those changes in my proposal, so that we can base those changes on a cost benefit ratio
Jeff questions anything that the SPPI requires for compatibility that doesn't provide value to the SMI. Comparison with CMIP: the .1 row entry identifier that was put there in the SMI for compatibility with CMIP. And CMIP is not around in many places today. Don't want to repeat such quirks simply for the sake of compatibility.
Other issues: Should we merge SMI and SPPI to familiar look and feel, OR throw everything out? We should apply the state of art, take the good ideas from SPPI into smiv2, drop extra .1, but keep the same look and feel. We should not make changes for sake to it, only change if they make things better. When faced with conflicting requirements of readers, writers, toolers - we should get rid of all those CLRs (Crummy little rules). The docs and actions should follow good engineering principles. Also our work should be constrained on protocol and eos changes, the smi is the glue between the mib and the protocol, I believe these two parts have evolved together and should continue to do so.
SMIng - session two, minutes From: Sharon Chisholm
Minutes of panel discussion. Panel included representative authors of all proposals except Jeff Case. Panelists were Andy Bierman, Juergen Schoenwaelder, Alessandro Triglia. Chair David Durham.
Overview of discussion topics:
1) Differentiating the Proposals
2) Naming Space/OID Allocation
3) Look and Feel
4) Compliance Statements
5) Fix SMI a bit or a lot?
6) The SPPI Question
7) Mapping back to transport
8) Accessible Table Indices
9) Instance Naming
10) Partial vs. Total Data Retrieval
11) Case
12) Language Extensibility
13) Actions
14) Most Cited Objectives
1) Differentiating the Proposals
--------------------------------
Conclusion:
SMI-DS provides a hierarchical naming scheme, closely resembles the SMI, and ties instance naming to the data type definitions. The NMRG proposal changes the syntax to something more commonly familiar, and separates the data definitions from instance naming while preserving tables. Alessandro allows complies ASN.1 and allows the writer to choose their naming methodology. The action item was to investigate whether indexing needs to always be decoupled from data structure definitions to maximize reuse, or whether it can always be defined relative to data structure definitions for reasons of simplification.
Discussion:
ASN.1 Proposal's key features:
- The strongest feature is the full re-usability of every definition. Able the reuse any definition ... atomic types, unions, arrays to both define higher level structures as well as define instances of these things.
- For example, when we defined a row class .. entity class bases on a structure that will be used as a row ... we can then define two different row classes that use the same definition, but can use different indices.
- In response to yesterday's question about extensibility. I had said we did things similar to Andy's proposal ... somewhat true ... extra zero inserted ... but extensibility actually is implemented at the instance level, not at the class level. More similar to the NMRG proposal in this way.
- A table can be instantiated that is of a particular entity class.
Dave D - Andy, is there any structure you can't re-use?
Andy - No, in both Juergen's and my proposal you have full reuse.
Randy - The difference here is in the derivation process if the instance information is bound to the type. That is, if the index is bound to the struct or if it is bound to the next level of definition (how you decide to use the struct).
Alessandro - I would say that in Andy's proposal, when he defines an array, the definition of the two is inside the definition of the array, so he is going to have to redefine the definition of the array sometimes in order to reuse it.
2) Naming Space OID Allocation
------------------------------
Conclusion:
Continue to investigate the hierarchical OID space data structure naming concept. Look to see if there are any serious problems with the concept for existing implementations.
Discussion:
Dave - Another key differentiator is whether the name space nesting of data structures is also preserved in the OID mapping and, thus, over the wire.
Andy - Instance naming ordering is being preserved on the wire in SMI-DS, this has also been called adhoc hierarchical naming.
Dave - Does everyone understand the difference? We have either manually assigned OIDs or adhoc hierarchical naming. The advantage of what Juergen has done is it preserves the existing table concepts. Andy simplifies things by removing this level of indirection, allowing data structures to be expressed hierarchally in the oid space. Alessandro's proposal allows the writer to choose between these.
Randy - There are two aspects: Assignment of sub identifier and also the structure of the resulting OIDs. The asn.1 proposal allows you to choose how this is done.
Alex - the user can specify what naming structure they want. Either existing or complex. ASN.1 proposal allows both. Either traditional tables or the hierarchical one.
Sharon - Are non-manually assigned OIDs predictable?
Andy - Yes, they are predictable. Nothing ever renumbers even if people leave stuff out.
Dave - question to Alessandro who can do both ... when you do hierarchical naming, is it the same as in Andy's proposal?
Alex - Andy adds a zero before the attribute id ... I only add the id by default and the zero if optional. Otherwise the same.
Andy - How would an snmp engine know that it is getting an extended oid if the 0 is optional?
Alex - An agent will know this. It knows when there is an additional 0 because it should know the MIB.
Dave - Did Juergen want to add anything about SMIng that deals with naming?
Juergen - We started with the mapping SMI/SPPI and that is why we have a flat numbering scheme. At one point we had something more dynamic and people thought it might be difficult to define arrays (some question).
Dave - what concerns me about allowing both techniques, and the writer choosing either or, is that it adds complexity ...
Randy - I think the question is, whether it is really necessary to change how we change OID constructor methods in order to accomplish the varying data definition. It might not be necessary. The part that worries me is the two different ways of building OIDs in a runtime system. I'm saying that the specific mapping between the hierarchical naming and OID might not be the only way to do this.
Randy - A question, when you came up with the SMI-DS way ... why?
Andy - I wanted to be able to preserve the naming so imbedded objects would be named the same no matter how they were imbedded. I can then have cascading method routines because the naming is going to be the same for that structure, no matter where it appears.
Randy - In c++ you can overload the method, another way is that you have a container class that defines instances of the things it contains.
Andy - Engineering is about tradeoffs - flexibility vs. ease of use I think my proposal makes a good trade-off. Too much flexibility in standards is bad. It makes things more complicated. Ease of use and leveraging existing technologies is what I would like to achieve.
Dave - Should we move away from just tables into more hierarchical data structures?
General agreement from audience.
Dave - converse question ... who thinks bad?
Result is that this looks like something we should continue to look into.
3) Look and Feel
--------------
Conclusion:
Ease of use is the goal here. The priority order is that it should be easy for MIB readers to understand the syntax. Anything that can be done to improve ease of use should be the first objective. We should not try to fix things that aren't broken without good reason. It makes sense to merge the best features of each proposal into one.
Discussion:
Dave - Next question relates to the SMI look and feel. Jeff's proposal is the most like the existing SMI, then Andy is the next most similar. Andy, did you want to explain why you stayed with the basic SMI syntax?
Andy - I was trying to bring some of the basic concepts of c into SMI. I was not trying to make things look like C. I left out pointers ... we don't have pointers so there is no need for them. The data modeling concepts of C are well understood so we should bring them into the SMI. The typdef of a scalar is close to what we have, but there is a bit of extra stuff allowed. The struct and union thing is just a wrapper. They have a description clause that is extra. The protocol only allows us to get to accessible objects anyways.
Dave - Why did you want to preserve the SMI look and feel?
Andy - People (customers) are used to it.
Dave - Same question to Juergen: Why did you change from the SMI syntax?
Juergen - First thing to note is we have defined something new, conceptually different. People might get confused if we make it look like something we already did. There are also people who have not used what we already have.
Our syntax looks more like normal programming languages to get rid of learning curve for new people.
Dave - Alex, do you claim that the existing SMI is ASN.1 .. so that you have preserved the SMI syntax?
Alex - I tried to preserve as much as I could. Use the same arrangements. Example compliance statements. I introduced a few things. As far as the most important things are concerned ... definitions for new data models, I had to move away from the old. Wherever I could, I tried to keep the syntax the same. When you see differences '{' '|', that was done to make notation compatible with current SMI.
Dave - What are the benefits to using ASN.1?
Alex - I believe the main purpose was to create a SMIng language according to objects. We chose to do this in ASN.1 because we know ASN.1. One benefit is that the syntax of the language itself is standard and can be checked by freely available tools.
Dave p - So, I believe the approach you are trying to take is .. anytime you come up with new language, you can have tools to verify the language. But, once you said "here is what the syntax looks like" a compiler would have to do semantic checks. So verifying the language in comparison is just simply a bootstrap process.
Alex - yes. I was thinking of the scenario of possible implementations.
Randy - I'm going to start channeling Jeff. One of the items in this proposal ... understand whether you want to maintain look and feel of SMI or because ASN.1 forced you to do this ... We have a sequence and then the definitions. Yesterday Jeff went on about the problem with this distinction. Some MIB tables will have 20 or more columns. The only tie between them is positional. Was this for compatibility or because ASN.1 forced you to do this?
Alex - It is easy in ASN.1 to define a sequence. If you want to use this method, you have the power of re-using definitions. Why do you want to have a table with 50 attributes? In a traditional design, it's not meaningful. If you can nest the definitions, it's much better ... then you won't have 50 attributes.
Randy - My question is within a modern ASN.1 definition, would it be possible to do the attribute definitions in-line, instead of simply have it positional.
Andy - I find the ASN.1 proposal very difficult to read for this reason.
Randy - In C/C++ definitions are done inline.
Alex - This difficulty in ASN.1 is counter balanced by the fact that you already have an existing notation to define things. ... I don't have ready answer to your question, whether or not it is possible to do it differently.
Randy - Being able to do it inline would make the ASN.1 proposal much more attractive.
Alex - This was my first solution. It might be possible to it in line.
Dave - quick consensus poll
1. don't want to change from existing SMI.
2. fix and improve the SMI, don't change what is not broken.
3. move to something completely different (easier for new people).
Juergen - I believe we are all in the same group.
comment - I agree that all three proposals make changes for good reason.
Randy - discontinuity ... ASN.1 changes introduced are because it isn't ASN.1 as opposed to being required because something is broken in the existing SMI.
Juergen - Take SMIng ... remove extensive ... remove case changes .... ASN.1 uses scalars .... if you make these changes the core syntax looks remarkably the same. You just have to pick one.
Dave - Then the conclusion is that all of these prop are going in the right direction. I'd like to start merging these proposals taking the best features from each.
4) Compliance Statements
------------------------
Conclusion: Existing compliance statements are awkward and will likely need to change as a result of changes to the SMI.
Discussion:
Juergen - You need to change things, like the compliance statement.
Andy - Only accessible objects. Descriptors that are for accessible objects would be listed in compliance.
Randy - If you have something that is used two different places, the compliance needs to be able describe these two different objects' usage.
Andy - If I have type foo ... and I use it in another table?
Randy - If foo has an element named bar and bar is used in another table. If the usage is different, we need to be able to talk about both usages in compliance.
Andy - foo1.bar foo2.bar ... good point.
Randy - And this is a change to syntax.
Juergen - we generally talk about conformance of an instance. We probably want conformance on objects.
Randy - If something does not work in SMI, we may want to fix it. I've always found the conformance hard to use.
Andy - I agree ... compliance section is an issue.
5) Fix SMI a bit at a time or a lot at once?
----------------------------------------------
Conclusion: There was rough consensus to make one big change to the SMI instead of patching the existing SMI piece by piece (i.e. just adding Integer64 base type).
Discussion:
Dave P - There two ways to get the end result. There is the "let's go and put in maintenance stuff right now" vs. a full-blown SMIng. Maintenance includes support for additional base types.
Juergen - Addition of types is a protocol problem.
Randy - I disagree. Some of it could be considered a transport mapping. 64 bit integer. It's kludgy, but could work.
Andy - I do not want to have multiple roll outs. It is expensive to do (vendors will have to change everything anyway just to get a minor roll-out) and is fundamentally poor engineering practice. Also, ease of use is not just readability. It is also minimizing the number of ways there are to get things wrong. I find that just adding more knobs is not good engineering. Same with adding more rules.
Dave H - I think we have two problems to solve 1. maintenance But, people don't want to change and learn new tools. We need to do enough to make the changes worthwhile.
2. Marketing problem, people don't like SMI. I think we may need to change that. We hear from people that they don't like to have to read through this arcane language.
6) The SPPI Question
------------------
Conclusion: There was rough consensus that SMIng should be optimized for SMI and SNMP first, and extra complexity should not be added to the language to achieve compatibility.
Discussion:
Andy - I would be quite happy with the NMRG syntax. I like parts of their proposal, I like their augments. My issues with that document are with protocol mappings and complexity to deal with SPPI. I think if we relax the SPPI thing and optimize for SNMP, then I'd like that proposal. First I want to keep the SMI, but then my second choice is a language syntax like what people are already using.
Dave h - Optimizing for both COPS-PR and SNMP makes things more complex.
Dave - We said at last meeting that we would focus on mapping to SNMP.
Dave h - Separating the mapping makes it more complicated.
Dave - We need a SNMP mapping. I don't think anything should be done in the language itself to support others. So a new mapping should not affect the way the language looks. So, I assume you don't want to see things like the extra 1 added to the OID for mapping to CMIP?
Dave h - That's it.
Andy - When things are spread out it increases the chance of error. Self-contained definitions are a better approach. ASN.1 spreads it out a lot already. SMIng spreads it out more to deal with SPPI.
Juergen - There is a difference between defining data structure that can be reused and instances that can be used. SMIng did things the way it does not just because of SMI and SPPI, but to gain reuse of the data structures.
7) Mapping back to Transport
-------------------------
Conclusion: Just basing language on ASN.1 does not provide a ready mapping to SNMP. One could not simply use existing ASN.1 tools to do this.
Discussion:
Juergen - What ASN.1 is missing is a mapping back to SNMP.
Randy - At the BER level an asn.1 enumeration is different than an integer. A different tag at the protocol level. Juergen's point is between what the ASN.1 says and what would happen if you ran it through BER and what would have to happen at the protocol level.
Alex - I wanted to separate SMI issues from what the transport would do. It probably needs more text to describe it.
Andy - Juergen: Could the protocol mapping be put together with the thing it is a mapping off? Nothing to prevent that?
Juergen - No.
Andy - That would make things easier.
Randy - Actually, there is a little value to the sequence, it gives concise list of what is in the table.
8) Accessible Table Indices
-------------------------
Conclusion: Table indices in SMIng should be made accessible again.
Discussion:
Andy - Yes, we should put non-accessible things in conformance.
Sharon - But I had asked to make indices accessible again on the mailing list and people agreed.
Andy - True.
9) Instance Naming
---------------------
Conclusion: Keeping instance information on the right has value in that it will be easier for existing implementations to deal with it.
Discussion:
Andy - I had a long talk with Jeff about naming. He might have a trick to shoe horn things to get instance names all on the right, but we would require new protocol operations. We are chartered to use the existing SNMP.
Randy - The mapping to the transport is part of the SMI.
Andy - What Jeff was talking about would not be compatible with row pointers. What is in the MIB is not the same as what is in the wire.
Dave - Why did Jeff want to do this?
Andy - He wants to instance information that is not on the right.
Randy - If we allow instance information to be scattered, it would allow dynamic location of instance information and would make things difficult.
Randy - It's once you are in the sub-agent ... received request ... need to find method for this instance ... to find that method, you need to match up an OID against methods. If all the information is scattered in this OID, then this is trouble.
Andy - If they are all at the right, don't you need the MIB?
Randy - You don't need to crack the types until you get to the class. You do need to do a match on the OID to find the class.
Andy - There is always an object that is anchored. You can't just register a method routine at that point?
Randy - the difference is that instead of doing all of your level of nesting in one swoop, you need to do it all in the method.
Andy - agree we require some code changes to deal with numbering changes.
Randy - If contiguous, we don't need the changes ...
Andy - I disagree ... if you are defining data structures .... now we are diving into implementation choices.
Alex - I think what you have proposed can be done. It may work. You just lose the ability to reference the row. But, otherwise, you still have the ability to define complex data structures.
Alex - PL1 language does something similar.
Andy - Not stuck on naming scheme. If it's a show stopper, we can do something hacky to get things on the right.
Randy - What it does is pass data structures in platforms native data format.
Dave - Andy - you also have the option to map to table for transition?
Andy - yes, but there are some corner cases where the algorithm gets hard. It could expand to multiple tables ... most is straightforward. If everything is pushed to the right, then the translation becomes easier.
Randy - shoving to right has some appeal. It does not allow rows.
10) Partial vs. Total Data Retrieval
------------------------------------
Conclusion: There was consensus that even with the new data structures in SMI, we needed to be able to retrieve both all and part of the data, depending on the situation.
Discussion:
Sharon - 90 % of the time, you only want 30 % of the attributes.
Juergen - If you have complicated aggregate objects, you want the entire object instance together.
Andy - A well-established application is multiple interfaces statistic retrieval. In this case you want most of the object.
Andy - Just like when you can select columns to dive down on, now you can create instances to dive down into.
Randy - but if you are using getnext or getbulk, and an attribute has a table, you will get that if you want it or not.
Randy - had to provide developers with an API object, provide attributes and do the get bulk and fix things for them.
Juergen - Jeff wants to keep ordering as now, he wants to EOS to provide support for other ordering.
Randy - <describing API in product>
Sharon - I don't want to rely on magical APIs to overcome problems in the protocol & SMI.
Sharon - I appreciate being able to get entire object, but need either EOS or something to provide a way to retrieve all efficiently as well as a way to get partial information.
11) Case
---------------------
Conclusion: General consensus to keep case as it is in the SMI unless there is good reason to change.
Discussion:
Andy - I guess resolution on look and feel .. all in same category and any of the syntaxes could meet look and feel requirement. We are going to have to decide what the syntax looks like. I'd move towards Juergen's syntax. I like the derived classes, instead of augments. There will be a discontinuity. All the existing work won't disappear, so people coming into the field will still need to read all the MIBs.
Andy - If you look at making changes only when they are necessary. Why change the strings READ-ONLY?
Randy - I think that argument also applies to the capitalization rules. The visual impact needs to be respected. If we have cases where there is no technical reason to change something, some changes may not be worth making.
Andy - I agree.
Dave h - Is lower case more readable.
Randy - yes.
Dave h - Do we care?
Randy - We should not change it. Those keywords are upper case.
Dave P - if you say that keywords can be upper case, and then say that names can be the same as keywords ... this would make it difficult for reading and compilers.
Juergen - C doesn't have uppercase rules.
Dave P - I have no problem with upper case.
Juergen - Rather talk about language extensibility features. Case isn't a big issue.
Andy - Juergen, if you changed your keywords to upper, your innovations would not be lost.
12) Language Extensibility
-----------------------
Conclusion: Language extensibility will likely require something like the semicolon in the SMIng proposal. Many arguments were made against allowing language extensibility. Some people like the idea of an extensible SMI, some don't.
Discussion:
Andy - Juergen, people could get used to the ';' but why do we need it?
Juergen - It has to do with language extensibility. If we drop that objective, then they can go away.
Andy - I don't want to give MIB developers the ability to do their own SMI. Only want to working group to be able to add stuff.
Dave h - What benefit does the ';' give you.
Juergen - It allows you to skip well-formed statements that you don't understand.
Bert - If we keep the ';' and decide to use it in the future ....
Dave - Does anyone want extensibility?
Andy - I'm in favor of methods only if WG can use it.
Dave H - could be useful to write our keywords in upper case and not allow other people to use upper case, so we can reserve the name space.
Randy - do we want modification of the language to change the base SMI?
comment - does not think there is a way to extend it without preventing people from using it.
Andy - Then I'd like it taken out, and we can just update the SMI using the normal process.
Randy - when you are generating code from MIBs, you need some hints, the question arises as to whether you want to do those hints inline or with some separate stuff. MIB writers like to decorate their definitions with extra stuff. Need to separate hints from implementation specific MIB.
Extensibility to do hints, it is counterproductive.
Andy - At Cisco we had to undo importing unsigned 32 from a Cisco TC.
Dave - Other working groups could require new clauses. Bert ... what do you think. We want IETF to have this ability ... but then others can abuse it.
Bert - we will be limiting ourselves. Need to carefully evaluate.
Andy - need to differentiate between a MIB compiler to skip stuff versus people using the stuff where important information is not understandable.
The syntax is fine, but we miss the semantics.
Andy - Why don't we come up with an SMI that will last 10 years instead of making it extensible. Don't like making optimizations for unknown products.
Juergen - could provide a way to point to extra documents ... make things extensible.
comment - People will find a way to extend it even if don't have the ';'
Randy - boils down to a willingness to put a limit the grammar.
Dave H - I don't see the need to have the extensions.
Randy - Do we want to permit the addition of these additions without revving the SMI?
Andy - I don't want extensible mechanisms at all.
Dave - Take this discussion to the list. We don't want extensibility for vendors, but want to investigate whether we want to do it for the IETF.
13) Actions
-----------
Action Proposal Authors/Editors: Come up with integrated proposal that takes the best features of all the existing proposals.
14) Most Cited Objectives
--------------------------
* Composite/Nested Data Structures
* Reuse of Defined Data Structures
* Addition of new base data types (ie. Integer64)
Slides
Agenda
Proposal to SMIng
Structure of Management Information: Data Structures SMI-DS
SMIng NMRG Proposal Status Report
ASN.1 for SMIng