2.4.9 Next Generation Structure of Management Information (sming)

NOTE: This charter is a snapshot of the 49th IETF Meeting in San Diego, California. It may now be out-of-date. Last Modified: 21-Nov-00

Chair(s):

David Durham <David.Durham@intel.com>

Operations and Management Area Director(s):

Randy Bush <randy@psg.com>
Bert Wijnen <bwijnen@lucent.com>

Operations and Management Area Advisor:

Bert Wijnen <bwijnen@lucent.com>

Mailing Lists:

General Discussion:sming@ops.ietf.org
To Subscribe: sming-request@ops.ietf.org
In Body: (un)subscribe
Archive: ftp://ops.ietf.org/pub/lists/sming*

Description of Working Group:

This working group shall develop a standards-track specification for the next generation data definition language for specifying network management data. As a starting point, the WG will use the SMIng language developed in the IRTF Network Management Research Group. SMIng represents a superset of the SMIv2 (Structure of Management Information v2) and the SPPI (Structure of Policy Provisioning Information). The objective is to replace both the SMIv2 and the SPPI with a single, merged language as the data definition language for the monitoring, configuration, and provisioning of network devices.

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.

Goals and Milestones:

Nov 00

  

IRTF documents complete & submitted to IETF

Dec 00

  

First IETF WG meeting

Feb 01

  

Submit Revised I-Ds including requirements I-D

Mar 01

  

Meet at 50th IETF

Apr 01

  

Submit revised I-D for requirements document

May 01

  

WG Last Call on requirements document as Informational RFC

Jun 01

  

Submit revised I-D for Data Definition Language and Usage document

Aug 01

  

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

No Current Internet-Drafts
No Request For Comments

Current Meeting Report

Next Generation Structure of Management WG (sming) minutes from the 49th IETF
Wednesday, December 13 at 1530-1730; Thursday, December 14 at 0900-1130

Chair: David Durham David.Durham@intel.com
WG Charter: http://www.ietf.org/html.charters/sming-charter.html
49th IETF SMIng WG Agenda: http://www.ietf.org/ietf/00dec/sming-agenda.txt
Special thanks to the minute recorders: Aiko Pras, Priya Rajagopal, and Amol Kulkarni
Minutes reported by David Durham.

First day, 12/13/00 (Wednesday):

Chair read out the agenda.

-------------------
Bert Wijnen our Area Director spoke briefly:
-------------------
This is a WG, not a BOF. Mislabeled a BOF because approval came late. Came out of issues raised during the NIM BOF at Pittsburgh. A lot of people were concerned about the direction of SMI and SPPI. There also have been lots of requests to fix problems with SMI. NMRG meeting after IETF48 had discussions about the way forward. This WG is to try to get SPPI and SMI to merge together.

----------------------
Purpose of WG:
----------------------
Provide an improved DDL (Data Definition Language) for the IETF
Encourage convergence of DDL and modeling for in the IETF.

----------------------
WG Charter
----------------------
Develop a data definition language that provides reusable templates, is protocol independent, and includes the benefits of object-oriented design. Also define a registrar framework for reusable components developed using the language.

Goals and milestones
--------------------
First develop the requirements document, then complete the SMIng core language document, protocol mapping documents and finally establish a registrar framework.

Documents
------------------
nmrg-sming-04
sming-inet-modules-01
sming-modules-01
sming-snmp-01
TBD-
Requirements document
COPS-PR mapping

Should we do XML mapping?

------------------
Aiko Pras:
------------------
Aiko presents background for SMIng. Reasoning behind SMIng, and analysis of the alternatives.

History:
Developed by IRTF-NMRG:
- SNMP over TCP
- SNMP compression
- SNMP getSubTree
- XML DTD for SNMP MIBs
- SMIng

Why start SMIng?
* SMIv2 relies on 1988 version of ASN.1
* Tools for SMIv2 relatively complex & out-of-date
* Some obvious data types were missing - 64 bits
* Limited facilities to reuse definitions
* SMIv2 didn't allow for extensions
* New, possibly incompatible variants appeared
Hence, the challenge: create a common DDL independent of protocols.

Info model vs. data model: UML, PIB/MIB
Information model (at the level of the information, can use UML for a graphical representation). Under that you can have various flavors of a data models, ASCII text representations of data, and mappings of the data to the format over the wire.
Once we have a data model, we could map it to a 'transfer' protocol.
SMIng is to concentrate on the data model level, integrating the SPPI and SMI.
Need specific 'mappings' to different protocols.

Contest for the name of SMIng "MIB".

Currently there is a mapping for the SMIng to run over SNMP-BER or COPS-BER encodings.

-----------------
Andrea Westerinen
-----------------
Presentation of the SMIng Requirements.

Need to understand goals:
* Merge SMI and SPPI and add new capabilities.
* Try to be the ASCII representation for IETF info models.

We could make this the information model of the IETF. Described what is an information model. OO design concepts in the IETF? Wouldn't it be nice to design first before coding protocols? Nouns vs. verbs, information model describes the concepts. The MIBs and the PIBs are the data models that can be integrated. They describe the protocol specific implementation to a protocol.

An Information Model provides a description of key concepts. OO design is recommended for an info model. An info model is also protocol independent.

A Data Model, on the other hand, is implementation specific. It may include protocol specific optimizations. Eg: Diffserv. Diffserv started with a conceptual model - a plain English or informal model. An Information model would formalize this. MIBs and PIBs are examples of data models.

Requirements:
We need the ability to name classes. Instances need to be named relative to their protocol/data model. There needs to be the defn of basic data types including ptrs and references. A textual representation is required - ascii, graphical views are also helpful as a visualization technique. Also must have the ability to combine attributes into classes.

Class Information: A class has a name, list of attribs, and perhaps events. A class also has methods. Methods are not in the SMIng language today, however. They describe behavior and operations such as reset device and sync with 'foo'. They also provide return values (success, failure, etc).

Inheritance is the concept of moving from the general (abstract) to the specific. Single inheritance is all that is required. Inheritance organizes and gives semantics to concepts. It allows reuse of concepts. There may or may not need to be a single root for all derived classes.

Associations: Relations are a strength of OO... They describe relationships between classes. Associations can be modeled as a class with two (or more) pointers / reference attributes. They also describe the multiplicity (1-1, 1-many, etc) between class instances, something that is not in the SMIng language today.

Constraints: Constraints are required for attribute bounds and enumerations, describing whether an attribute is read/write, optional vs. required, etc.
Also there is a need for semantic constraints ... These are constraints for creating/deleting instances.

Requirements missing in SMIng proposal: Should SMIng describe info models?
Would need support for associations and support for methods.
Questions: Should SMIng be an information model? Should there be support for associations including cardinality?

--------------------
Juergen Schoenwaelder
--------------------
SMIng document overview:

The SMIng Core language provides a type system, class system, identities, model structure, syntax and language extensibility feature, and versioning and extension rules.

The Core data definitions defined by the SMIng include Internet data definitions and protocol mappings.

The SMIng Module contains related SMIng definitions. Modules are named and their names are globally unique. It is assumed that there is an implicit import of definitions in a module, where external definitions must be explicitly imported from other modules. The language doesn't allow forward references except in certain cases where there is no other choice.

Data types: new types can be derived from existing types. SMIng provides display formats and unit definitions which my optionally be used.

The SMIng class system encapsulates attributes and events. An attribute type contained by a class can be base, derived type or another class. The classes can be derived from one another using single inheritance. Also, classes can have associated events. The class's name scopes the names of the attributes and events within it

SMIng identities provide mechanism to identify constants w/o a central authority. Names are scoped by module names. A pointer base type can point to identities.

The SMIng syntax is programmer friendly. It has a look and feel similar to Java, C++. It uses a consistent structure for its statements, which makes it easy to memorize. It also provides for language extensibility. It also improves compactness in normal cases. Finally, the syntax is easy to implement and efficient to parse with no forward references where possible

With respect to versioning, there is a declaration of new statements, and unknown statements skipped. Once published, definitions can't be changed. Definition status can be -current, deprecated, or obsolete. Updated current definitions may not depend on deprecated or obsolete definitions. Module versions are identified by the time-stamp of the last revision. And extension rules allow for changes between revisions.

Core Internet data definitions: There is a set of historic type definitions. port #, proto #, etc. Some fundamental class definitions have also been included, n/w end pt and transport end pt, inet subnet, filter definitions, etc. Data Defns use Opaque to ship data types existing in the protocol.

Large set of fundamental data types. Other data definitions and types. IP filter definitions. Base type mapping. Interger64 maps to opaque. Naming: Instance naming node statement to build the OID tree and to assign OIDs to identities. Scalar and table statements to assign OIDs to class attributes. Notification statement to assign OIDs to events. Flattens out any contained class's attributes into a single flat table. Attributes of classes are mapped to scalars in a group.

Conformance defns: There are single group statements.

-------------------
Questions:
-------------------

Why do the document and the ABNF restrict the reference clause to 7-bit ASCII. We are not the only ones that use these tools.

Rob Price: What about the Integer 64 mapping issues... Why not put these aside until they are resolved?

??? Could not explain why pointers are used. Pointers are a type. They point to an identity or an attribute? What is the scope of pointers?
- OID. purpose of SMIng is data modeling not info modeling. We should not shy away from complex associations

??? Are there reverse mapping tools? Tools for mapping from MIBs and PIBs and regenerate them into SMIng. That would be a really good thing!

Bob Moore: If you have a SMIng module, and you are going down the COPS path, are you mapping it to a MIB or BER... Keith: Does SNMP MIBs go away? Yes, in the end game MIB/PIB go away.

??? MIB modules are used for more. Is it one of the goals to map a SMIng module into the SMI?

??? Shouldn't SMIng compilers be required to compile SMIv2 documents. Won't implementations choose the simplest? David: SMIv1 MIBs are still supported today; it all depends on what the customer wants.

??? Docs give attributions to inet technologies incorporated.

Randy: GDMO shows how to make relationships more granular i.e. a CIM association... Keith, perhaps pointer is the wrong name. There are distinguished name and relative distinguished name. Pointer is a way to realize an association in the information model. Juergen says should not try to do arbitrary associations.

Andy B: Some OIDs are pointers some OIDs are not.

Andrea: If we want the relations to be more. Andrea will be willing to try and do more.

Andy B: Why int32 in an info model what is the difference since it is also an int32 in the data model. Color and BW TV example (forward & backward mapping). There will be a lot of problems with the mappings. If there is a class contained in there and there are variable lengths in the INDEX, you can't get at the individual attributes. Juergen: Not really true, OID namespace is flattened out so there are still OIDs for each an every attribute contained or not. Steve: Foo.inet address there are individual elements. Interface number are also in the same data structure.

Andrea: Int32 are not different in the info model/data model. It is really making some additions and clarifications, not chaining basic data types.

David Perkins. Polymorphism is not mentioned? Andrea: Specifically for events, this is a good requirement to add. Polymorphism will also be important when dealing with methods.

MIB to PIB transformations are very important and should be a requirement. Andrea, it may not be 1:1 mapping. If the mapping is unreasonable it is not good to do. Juergen: Does not see a need to map each way. There may not be a reasonable way to get the mapping backwards from SMIv2 module to SMIng module. Information is lost.

Andy B: What I meant by my comment is there should still be a basic mapping, but it should still be as best as possible.

Steve Multon: Jeff Case wishes he could, but did not make it. I do not want to close the door on taking a smaller step to merge the SPPI & SMI. OO may be too much. In response Juergen says that there are those that want SMIng to do even more.

David Perkins. Thinks this is a good start. Appreciates the work. We need to move forward with this technology. Back to a question: Bags, there are two types, sets and sequences. Also needs discriminated unions. Andrea: Hadn't thought of everything, -Did include sequences. Andrea is interested in considering more. These things were not purposely omitted.

??? Methods in language level may not be enough. Then we'll need methods at the protocol level too. SNMPv4?
-(Jeurgen) At this time they do not exist, but there are four options:
1. No methods.
2. Methods in Data Definition language for SMIng.
3. Methods in DDL for SMIng and mechanisms to map operations in SMIv2.
4. Methods in DDL, and convince the SNMP WG to support it.

??? Specifying security requirements for objects in the language. This should be considered. Juergen: Haven't thought about at this time, but the language is extensible.

Randy? Possible solution to add to the examples. Log notifications with opaque types in their varbinds. Given a MIB with log notifications that contain opaque types. How does it happen in SMIng?

David Perkins. How will we track versions between different standards?
Missing slides: if these move forward with this work then what next?
Different WG will write different constructs. There will be independent mappings for different protocols from different modules. Need to have some process for how to use these definitions. Juergen: Definitions don't change and don't go away. Hasn't thought much about this but doesn't think it is a significant problem. Keith: Trying to understand, maybe split the documents.

??? Question on how to model a class with a bunch of attributes. Juergen: Not modeled in a protocol specific manner. It is just a mapping, assign the OIDs per attribute.

??? Is SMIng constrained by SNMP in ordering of names?

Shai: Named classes and so on are named differently in the SMI and may get different numbers as a result when the SMIng definition changes. Juergen: This is taking into consideration in the protocol mapping. Prevents the next generation from having a value in-between. Constraining the protocol mapping, not SMIng.

-------------------------------------------------------------------------------------

Day two 12/14/00 (Thursday)

----------------------------------
Keith presents some examples:
----------------------------------

While presenting the examples, many questions were raised...

Keith: SMIng starts the same as SMIv2 module statement block. Comments are two backslashes. Typedef statements define types. There is no status statement because absent means status current. Typedef has a size, format, description, and reference. Question on if there was a size whether or not it will parse correctly. Keith: No. Enumerations can also go in typedefs. Classes: One is the Interface. Attributes, access, units, and description per attribute per class. Bob: Where is MAX-ACCESS? Keith, now it is simply Access, has the same meaning. Glen: Where is the INDEX. Keith: we will see in a moment. ???: Is there multiple inheritance. Keith: No (not for the classes themselves anyway). Harrie: Is it necessary to define before you use so that there is not a forward reference. What if it is not possible to have a forward reference? Ans: Not possible with OIDs. Randy: Case in point, reverse index tables and are only lookup tables. Mostly no forward references. SNMP statement: Language extension. Extension snmp: oidStatements, nodeStatements, scalarStatements, tableStatement, notificationStatement, groupStatement, compliance Statement. Andy: Why insist on no forward references. Forward references are possibly not needed anymore (they were in a previous version). Some people felt that allowing forward references would not be difficult to implement.

There was discussion concerning whether the abnf part should be visible within the SMIng, or if it should be hidden within the parser: Randy: Pulling in BNF at processing time is much more difficult than forward references. Juergen: do not have to process it (the ABNF). David P. Agrees with Randy. Would implement this as a parser. Keith: If the parser comes across an unknown statement, it can ignore the statement. Randy: What that leaves us with is a compiler with the means of just adding some goop into the parser for when it comes across these statements. There is no advantage in having them as part of the language. If you do not process the ABNF then there is no way to ensure it is followed. Keith: Carries it along with the language. Juergen: Did not have an ABNF statement before. Now it is a documentation issue, separated from the description. More formal. Randy: Concerned that the modules with ABNF, people will expect that it be processed. Implementation cost vs. benefit issue in implementing it. Randy still was of the opinion that people could "abuse" the ABNF statement in modules by putting any kind of ABNF statement there, so it should not be there. Juergen: Example is XML where it is used all the time. Randy: Why are they there? Keith: Documentation reasons. David & Andy: Parsing does not provide anything. Randy: why not use XSL? Andy: Not clear if it is harmful or not to have these extensions.

Keith Continues... Scalars: Scalar group. Group name i.e. IP. Specifies the OID. Specifies object attributes. Object name for the particular attribute of a given class. Specifying that the MIB attribute must be specified for IP forwarding (in this example). Not everyone was convinced that partial implementation of a class (or partial inheritance; i.e. have multiple implements, but all the attributes within that class need not be used) is a good idea. It allows, however, different parts (documents) to move at different speeds along the standards track: David P. Table statement can have multiple implements (of classes). How do you specify an attribute of this class? Randy: Partial implementation of an imbedded class. Keith it is per attribute: Embedded in a class, potentially in another embedded class. When you import a class you implicitly import all the attributes within a class. Randy: Partial implementation of a class seems odd. There may be a semantic for the class that implies all the attributes are to be used. GDMO (CMIP's object definition language) supports multiple, not partial, inheritance. My point was that if attributes have been bundled in a class, there must be some underlying semantic that motivates this bundling. To then "partially inherit" from that class risks breaking whatever semantic it was that led to the creation of the class in the first place. Then there was a discussion on partial implementation of embedded classes that are subclassed. Ans was to specifically mention the individual attributes of the sub class and to import that class specifically.

Some people liked the possibility to associate oids to the objects within the implements part of the snmp statement. Not everyone thinks the term "implements" is well chosen, since it may be confusing for people from the CORBA / JAVA world: ??? When implementing the class. This is an instantiation of a class. Scalar is an instantiation of a class. Implements is usually used with regard to interfaces in RMI and CORBA. Randy: the point is that with regard to JAVA/CORBA there is a terminology problem. Keith: Would instantiates be better. Juergen: it is more of a mapping. Bob: this is the mapping part. Randy: Looks like the GDMO "derived from." Same thing as the multiple inheritance in CMIP.

There was discussion about implicit ordering of attributes. Randy felt that it was dangerous. This could happen when the OIDs of attributes change. So an explicit OID should be specified when "implementing" the class as a table. But the answer was that if numbering were done, then language would be hindered even if it were only the SNMP portion of language that was numbered. Another input was that implicit numbering was harmful if reversioning had to be accommodated and multiple implements were used (because the different classes would move independently): ???: what if there is an extension to an existing class after it is instantiated. There is a problem when there are multiple implements in that the different implements can change (revise) at different rates. Shai: this is my question from the last meeting. Randy: There is another option... Why not also provide the OID identifier (or just suffix) in this context? So why not simply explicitly provide the OID for all the mapped attributes? Andy: Implicit ordering is always dangerous, so always explicitly specify the OIDs. Keith: it is annoying to add something in the middle and add the OID statements. Jeff: For those who (don't?) write SNMP MIBs it is difficult to see how hard it is to write a MIB. Need something any engineer can use to write a MIB. The more explicit the harder it is to use, the more implicit stuff is easier, but it has a significant reversioning problem... Thinks we really need to make this explicit. Andy: There is another problem. There is no requirement that they (columnar OIDs) even have to be in order and without holes! Randy: Attributes in CMIP land, attributes have their own OIDs, attributes always have their same OIDs. Lots of things in the SNMP mapping will be driven by the way SNMP does things. Also in answer to a question, it was mentioned that there could be multiple implements of the same class as long as class was extended (inherited).

Table statement: Implements and oid, index, etc. Indexing alternatives: index {ifIndex} augument ifTable; extends ifTable (sparse); expands ifTable {ATM VclVpi, ATM VclVci}. Reorders ifStackTable {ifStackLower, ifStackHigher}. Andy: is it always true you want the derived classes to change their indexing. Keith: Current rule is being maintained that you can't change indexing without deprecating the whole table. Andy: this should only apply to stable MIBs, not MIBs that are still in development.

Dan: Can you define a table with different indexing? Randy: Index Iftype, then as long as there is a forward reference... Dan: Scope as in the entity MIBs. That's what the reorders is for. Wants another statement that is both expands and reorders.

Steve: Reorders... There will be another table. Do you need to implement a new set of implements? Has an interest in this, because would not like to duplicate this all over and over again. Complexity of the MIBs. Steve would like to go further. Jeff: Problem is that you need to be backwards compatible with SNMP. David P.: Points out that there is a savings because there is no duplicate description and therefore far less redundancy for that reason alone. Also, there are other indexing mechanisms. Glen: Avoiding redundancy is a very good thing! Andy: Problem with expands when using implied in the table being expanded.

There was a request to have in the table indexing something combining expands and reorders. Another thing is to have different indexes, without having to define different descriptions (in fact this is a request for stronger reusability).

Conformance groups. Etc.

There was a proposal to get rid of "implied": David: Can implied be removed? Kind of stuck with opaque, kind of stuck with implied for compatibility reasons. But can it be deprecated... We agreed that using it should be avoided as far as possible.

---------------------------------
Juergen presents some more complex examples:
---------------------------------

Provided an example based on RMON2, with lots of reuse.

Discussion on naming of objects within a table. Do we need "complete" names, like for example "addressMapControlStatus" instead of simply "status" (within the addressMapControlTable)? The current choice is based on backwards compatibility. It is important that the bits over the wire remain the same. Since names are not visible on the wire, some people liked to change them:

Andy: The descriptors are flattened out, so the contained classes are given OIDs at the same level as other attributes implemented in the table. Randy: Seems that the suffix, given a consistent naming scheme, don't need to repeat. Juergen: Old MIBs did not follow a consistent naming scheme, so it is hard to imply them all from the class and attribute names. Keith: But if you do that, you will need to map them backwards. Andy: Power of this is that RMON tools provide 20x as much code as needed. This is great because redundancy is not a problem here (with SMIng?). Randy: Agrees improved abstraction is a good thing, but could go even further. Juergen believes that scoping should be done by simply writing additional modules.

There were some differences in opinion on whether or not we could (should?) make SMIng look closer to SMIv2. Shai Herzog wanted to work on a proposal: Shai: What is the upwards side of the backwards compatibility: Juergen: take SMI MIBs and reformulate them in SMIng. Randy: Do we need to do round trip identifiers of the round trip from the wire and back to the new definitions? Juergen: For the migration phase, it would be useful. ASCII not binary. Andy: How to do the transition to COPS-PR if attributes are dependent on row status, which is not needed in COPS-PR. The protocol independence is an issue here. Shai: Backwards compatibility file to ensure that the history. The next generation output should be constrained by previous generation input. Make the transitional thing optional so we can take it away. Jeff: Have the SMIng language had a programmatic way for that language to map to SNMP. Create a way to bring in the existing SNMP MIB. This would be the preferred way to do the transition. Scott/Randy: If there were methods, would so many of the SNMP inconsistencies go away. Methods to more abstractly deal with operations in SNMP.

----------------------------------
Moving on to the requirements discussion led by Andrea:
----------------------------------

Should SMIng be an information model language? This question is an interesting question if you agree to the charter. Not everyone was happy with the current charter. However, the charter wanted to define something that is feasible, and the past discussion on NIM did not reach concrete results. That's why the scope of the charter is narrow. Also we need a solution now for current problems, like SPPI and SMIv2, improvements to the SMI, etc.

Do we need methods? There was a feeling that methods in an SNMP world could be implemented as a series of operations on traditional SMIv2 small objects. However, these small objects could, for example, be located in different tables. Some people really wanted methods to be in (Andrea). Or is there a need for method signatures? What are they?

Protocol dependent versus independent. Many people liked that idea, but some people had a concern that they had to do work on mappings they are not interested in. This is not a requirement, however. If you just want to monitor certain objects, you don't have to bother with a COPS mapping.

Discussion about whether Andrea's list was a list of requirements or list of issues to investigate. The comment was made that the language is extensible, and new "requirements" (for example an association class) can be added later. Comparison with GDMO and CIM. A concern was raised that modules should still be easy to read by humans.

Also, there was a request to have more examples, particularly the more complex ones.

Discussion follows...

Andrea: Can add some features to make SMIng into an information model language. Where data modeling begins and information modeling ends is blurry. An info model is a blank check. So "investigate the feasibility" to add associations, support for methods, sequence of, semantic constraints, ability to distinguish classes as abstract/very general vs. concrete/instantiable. Bert: Focus is important. The SMIng WG is to do a data modeling language. SNMP protocol improvements go elsewhere. This WG needs to focus on what is feasible today.

Keith: Methods... want to specify the semantics of operations. Can do this in SNMP today. Randy: Configure trap destination (high level operation). How many request/response exchanges. How many transactions does it take to make a trap destination set operation? Shai and Andrea agree. Randy: High-level create. Andy: Problem with the charter. Suppose I intend to write a MIB using SMIng, and then map it back to a COPS PIB, may require you to remove attributes & rewrite those classes... or we should be start over again. Randy: It means might have things that make sense for SNMP and not for COPS-PR, and if you think carefully then you might end up with something that might work with both. Andy: There is a need to simplify SNMP, why not just focus on that. The answer was that SMIng encompasses protocol independent and protocol dependent utility classes. There is much to be gained in sharing data definitions across protocols wherever possible. Furthermore, this is already blatantly obvious in the DiffServ MIB/PIB and the IPSec MIB/PIB. There is >90% overlap in their definitions. This is the reason why the charter included the text to integrate the SMI & SPPI. Nevertheless, the charter also speaks to significant upgrades to the SMI that will be very beneficial to SNMP regardless.

Randy: why not just use UML or an existing language that is out there. There are indirect mappings from MIBs to IDL. Randy: Why not just use GDMO? Answer: The mapping of GDMO for generating MIBs from UML was "ugly", so dismissed suggestion.

Bob mentioned that non specialists should be able to use SMIng. Randy mentioned that although SMIv2 and SPPI had the semantics for features like associations, no constructs are present. It seemed like the inherent complexity of the SMIng might make it harder to use. It was suggested that portions of the language NOT required should not be used. SMIng should not make it harder to construct MIBs/PIBs. Discussion was supposed to be taken to mailing list. Dave D. Some of these extensions can be modeled, and do not have to be primitives in the language.

David H. Question on method signatures. We've talked about Methods, what about method signatures, there is a distinction. Added SSIs (not APIs). ASIs are APIs, which are method signatures. His question was on how methods were mapped to protocol operations in SNMP. This question was modified to allow SMIng to have support for "METHOD SIGNATURES". Also Andrea mentioned that the method conveyed semantics and DID not specify internal interfaces (only conveyed in/out parameters). She mentioned that it goes into the protocol specific utility classes. Randy mentioned that setting of attributes to achieve a particular functionality was an example of a method. David D. mentioned that methods/operations could also be indirectly "modeled" using the language, with only a few additions to the language primitives (eg. in-out labeled attributes/parameters within a "method class"... Then control the operation itself using a rowstatus-like "go-button" attribute).

Andrea: We can learn from CIM. Further Bert decided that we would use only what's available currently (well-understood and feasible) and incorporate other new requirements after first specification.

David P. Does one slide. There is a one-letter issue. Between SMIng and smicng there is a one-letter difference. Would like to change the name. Bert: It is too late to change the name of the WG.

-------------------------
CONCLUSION
-------------------------
Is there a need for an interim meeting? Ans: Yes (approximately 15 people raised their hands for an interim meeting). If such meeting would be organized, specific proposals for solutions should be on the table in time. Such meeting could probably be held in February.

Slides

SMIng Agenda
Background of SMIng
SMIng Requirements
SMIng Overview