NOTE: This charter is a snapshot of the 50th IETF Meeting in Minneapolis, Minnesota. It may now be out-of-date. Last Modified: 14-Mar-01
David Durham <David.Durham@intel.com>
Randy Bush <firstname.lastname@example.org>
Bert Wijnen <email@example.com>
Bert Wijnen <firstname.lastname@example.org>
To Subscribe: email@example.com
In Body: (un)subscribe
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.
IRTF documents complete & submitted to IETF
Submit Revised I-Ds including requirements I-D
Meet at 50th IETF
Submit revised I-D for requirements document
WG Last Call on requirements document as Informational RFC
Submit revised I-D for Data Definition Language and Usage document
Meet at 51st IETF
WG Last Call on Data Definition Language (syntax) documents as PS
WG Last Call on Usage document as Informational RFC
Revised I-D for Mapping documents for SNMP and COPS
WG Last Call on Mapping documents for SNMP and COPS as PS
Registrar framework defined for reusable components as an I-D
Meet at 52nd IETF
Last call on Registrar Framework document as Informational RFC
Meet at 53rd IETF
Working Group closes
SMIng Meeting Minutes from the 50th IETF in Minneapolis MN.
Chairperson: David Durham
Thanks to the minute takers: Ravi Sahita, Amol Kulkarni, & Jamie Jason.
First Session: Tuesday March 20th 15:45-15:45
1. Chair Describes the WG status.
Currently, all chartered documents have been submitted as specified in the WG's milestones. These documents are: Requirements, SMIng, SMIng Core Modules, SMIng Internet Modules, SMIng to SNMP Mapping and the SMIng to COPS-PR Mapping. An interim meeting simply did not materialize as expected after the 49th IETF.
2. Andrea Westerinen presents a list of high-level assumptions about the requirements document.
Andrea did not present the requirements themselves, but specified the assumptions that were made in creating the requirements document. The assumed scope is that this work is to focus on merging the SMI/SPPI along with repairs and fixes that are over due for the SMI. Any improvements that are to become requirements need to be justified e.g. in terms of improving ease of use/operational problems, reduced size of code, or clarity. Also, the requirements are being identified as basic (part of the SMI/SPPI), necessary to fix, good to fix, or new.
Another assumption is that the mapping to a protocol can be separate from the definition of the data. This implies that it is possible to distinguish what attributes may be specific to a particular protocol, from the attributes simply describing the data itself. The work TBD is to determine how complex the WG wants the mappings to be as there is a tradeoff in terms of achieving protocol independence, as some defined data may only be relevant to a particular protocol.
The requirements are assuming that the SMIng can map to the SNMP/COPS protocols directly, and is not simply an intermediary translating to SMIv2 or SPPI. This would reduce the number of data definition languages people have to worry about moving forward. The discussion that followed revealed that while mapping to the protocols is a good thing in terms of improving the status quo, there nonetheless should be a requirement that SMIng is indeed translatable back into the SMIv2. This is simply a pragmatic requirement as the SMIv2 isn't going to disappear overnight.
There is the assumption that SMIng can extend, fix or even remove certain things that are already in the SMIv2/SPPI. These are exceptions that need to be listed separately, however. E.g. It may be beneficial to stop use of IMPLIED as defined in the SMIv2 because it is confusing. Likewise, the lack of 64 bit integers in the SMIv2 should not prevent SMIng from supporting them.
Instance identification may need to be generalized somewhat in SMIng simply because COPS and SNMP identify instances of data differently. Moreover, SNMP itself may change INDEX ordering across different tables. What SMIng can do is describe what attributes are suitable for use within an INDEX statement, and leave it up to the protocol mapping to actually determine how a particular table is to be indexed.
The requirements assume some amount of constraint expressions are necessary. SMIv2 and SPPI already express constraints on attributes. SMIng could go farther and add existence constraints, ordering constraints, etc. It is probably too much to ask for a general-purpose constraint language, however.
Sophisticated relation mechanisms such as associations are currently mentioned in the document. There was some discussion around why associations need to be part of the language at all, as they can simply be modeled with two pointers within a table.
Methods were discussed as well. They were motivated in terms of describing actions/behaviors, parameters, and return codes. Unfortunately, there still hasn't been a clear proposal as to how methods can be mapped to SNMP as it exists today.
The next steps were then described. The WG should continue to look at the existing requirements and add any that haven't been specified, and motivate those that are not clearly defined. Any additional undesirable features that are currently in the SMIv2/SPPI should also be exposed as required to be removed. The Requirements team will review additional input from the mailing list and then work to finalize a set of well-understood, and properly motivated requirements for the document to go to last call in may.
An issue was raised around versioning and how to make versioning intelligent. This issue then became whether or not there are bounds on the most basic types, as ANS has no bounds but MIB compliers don't allow unbounded values. We should learn from past mistakes. Basically, we should not be bound by current implementation issues at the highest level of abstraction, the mappings should worry about it. Counters are an example, 32 bit counters were good when the state of the art was T1, but today, 32 bit counters are a serious limitation. Versioning is a symptom of this issue, and how to loosen constraints as technology advances.
Second Session: Thursday March 22nd 13:00-15:00.
1. Frank Strauss starts by explaining the current SMIng draft's status with respect to the requirements. Classes of attributes are currently supported, class extensions via inheritance, etc. Methods, associations and various advanced constraints are among those features that are not supported. Motivation is also lacking for support of such features in the requirements document itself.
2. David Harrington next presents an itemized list of requirements. The requirements list was taken from the requirements document and put in a form more convenient for the WG to discuss, requirement by requirement. The feature list lists the proposed requirements by name, describes their status, provides a description, and specifies the motivation where there is one.
The following is the requirements list as presented by David Harrington focusing on those proposed requirements that elicited discussion. The meaning of status: basic - already in either SMI or SPPI; alignment - feature supported in different ways in SMI and SPPI and must be aligned; must fix - requirement/feature is considered a fix to a proven problem in SMIv2/SPPI (64-bit integer example); should fix - feature modifies something that is often misused and would be nice to have if it can be done easily and does not cause additional complexity of delay; new feature - means that the issue is considered a new feature which is not required in SMIng, but could be added.
Note: the proposed requirements are not listed in any particular order.
* Textual representation (basic)
* Human readability (basic)
* Machine readability (basic)
* Naming (basic)
* Namespace control (basic)
* Modules (basic)
* Protocol Mapping (basic)
The protocol mapping requirement specifies that SMIng must be able to map directly to the SNMP/COPS protocols. It doesn't *have* to map back to the existing SMIv2/SPPI inorder to do this. This doesn't mean that it can't, however. Rather there should be a requirement that the SMIng can translate back to the SMIv2/SPPI as well, so that existing tools will not be made instantly obsolete. What the charter is describing is a long term goal of reducing the number of data definition languages that will need to be supported in the future. Ideally, people will migrate to the SMIng and translations can be performed for the existing SMIv2 just as they are for SMIv2->SMIv1. There will be limits to what can be mapped, however, the SMIng should be able to evolve, and support new features that are not part of the SMI today.
* Instance naming (align)
It was pointed out that Instance naming has different requirements at the protocol independent level vs the protocol mapping. There is some benefit to using the same data with different indexing, eg. Reordering tables.
* Base data types (basic)
These are Integer32, Unsigned32, Integer64, Unsigned64, Enumeration, Bits,
* Extended data types (align)
Allow mechanism to allow base types to be defined as new types which provide additional semantics ; Counters, Gauges, Strings, etc. SMI uses application types and textual conventions. SPPI uses derived types. This is essentially the ability to derive TCs from TCs.
* Instance pointers (basic)
Must allow specifying pointers from one instance to another.
* Row pointers (align)
* Base type set (basic)
Support fixed set of base types of fixed size and precision. List should be extensible.
* Accessibility (align)
Attribute definitions must indicate read/write/created/deleted and whether are accessible for notifications or are non-accessible Align PIC-ACCESS and MAX-ACCESS, and PIB-MIN-ACCESS and MIN-ACCESS
* Derived types (basic)
* Enumerations (basic)
* Events (basic)
Provide mechanisms to provide events which identify significant state changes. Some discussion on this point - in SMI notification types are telling you message types. Could be events or something else - should split in two? One is a state change and one is indicating data to pass on - don't want this group to do what disman group is doing with alarm notifications.
* Creation/deletion (basic)
Define creation/deletion operators
* Range and size constraints (basic)
* Constraints on pointers (basic)
Allow specifying the types of objects to which a pointer may point to (type checking). Also may effectively determine existence constraints between rows.
* Uniqueness (basic)
Allow specifying uniqueness constraints on attributes. Useful for determining which attributes are appropriate for indexing.
* Tables (basic)
* Table relationships (basic)
Support INDEX, AUGMENTS, EXTENDS.
* Extension rules (basic)
Provide clear rules how one can extend SMIng modules without causing interoperability problems "over the wire".
* Categories (basic)
Group definitions into subject categories. Concrete instances may only exist in the scope of the given subject category or context
* Agent capabilities (basic)
Provide mechanisms to describe implementation.
* Remove implied (good to fix)
SMIng SNMP mapping should remove the IMPLIED indexing schema. IMPLIED is confusing and most people don't understand it. It may be good to get rid of even if the motivation is wrong. If the problem (the Fred/Barney problem) that IMPLIED is not deemed worth solving than IMPLIED should be removed. The argument of simplicity is a stronger motivation for removing IMPLIED.
* No redundancy (good to fix)
Avoid redundancy. Get rid of textual redundancy for things like table entries and SEQUENCE definitions.
* Discriminated unions (good to fix)
Support standard format for discriminated unions to group related attributes together (for example InetAddressType, InetAddress)
* Classes of attributes (new)
Provide mechanism for reuse of non-divisible, extensible attribute groupings. Required to map same grouping of attributes into SNMP and COPS-PR tables. Allows to group related attributes together. Ie. InetAddressType and InetAddress typically go together. It was suggested to rename this to classes or attributes or structs as they do not involve methods (as the name class may imply)
* Inhertiance (new)
Provide mechanism to extend aforementioned attribute groupings (classes of attributes).
* Abstract vs. concrete classes (new)
Should provide way to differentiate? Motivation is not clear.
* Relationships (new)
Ability to depict existence dependency between attributes/grouping of attributes. Ability to depict value dependency between attributes/grouping of attributes. Ability to depict aggregation between attributes/grouping of attributes. Ability to depict containment between attributes/grouping of attributes. Ability to depict other relationships between attributes/grouping of attributes. It was pointed out that this requirement may be too general to be listed as one item: typed pointers, row pointers, associations, and constraints all seem to be part of this one list item.
* Methods (new)
Support mechanism to define method signatures (parameters, return values, exceptions) that are implemented on agents. It was pointed out that there is no clear way how to map methods to SNMP. The motivation of this requirement is also unclear with respect to SNMP's memory mapped model.
* Procedures (new)
Support mechanism to formally define procedures that are used by managers when interacting with an agent. There was confusion as to what is difference between this and a method. - what are you defining about how a manager and agent interact [Juergen Schoenwaelder] - alleviate confusion between where the method is implemented (methods are on agent, whereas procedure runs on manager side) - alter following attributes in following order in order to reach this goal? [Juergen Schoenwaelder] - correct [??] - you are now specifying how to write the manager.
* Arrays (new)
Allow definition of arrays of attributes. It was not clear how arrays are mapped to fixed tables. Indexing and atomic access is also unresolved.
* Composition (new)
Provide support for composition of new compound types from more basic (potentially compound) types. E.g. Reuse a compound class of Inetaddress and InetAddressType within a filter class that filters on a source and destination address. This is different from a derived type in that previous constructs are reused, just like structs in structs. A (x,y) point struct can be reused in a rectangle struct containing four points for four corners (P1,P2,P3,P4).
* Existence constraints (new)
Provide mechanism to formally express existence constraints. Already embedded in SMIv2 INDEX clauses and DESCRIPTION clauses. Constraints on pointers may also be used to imply existence constraints (pointing at another instance implies that it should exist).
* Ordering constraints (new)
Provide mechanism to formally express ordering constraints - ordering constraints related to sets, you have to set this first, then do that, then do that, etc. You may have to do things in a specific order so that the agent works right. Don't want to just hide in description clause. Some discussion on how this is different than procedures.
* Attribute transaction constraints (new)
Provide a mechanism to formally express that certain sets of attributes can only be modified in combination. COPS-PR always does operations on table rows in a single transaction. There are SMIv2 attribute combinations that need to be modified together (such as InetAddressType, InetAddress). These constraints may be implied by classes of attributes implicitly assuming that attributes grouped together logically are manipulated together. - assuming you are using a tool to do this, you could make sure that InetType and InetAddress end up in the same request, for example. Could be in the specification and tool could make sure that ASN.1 could be written correctly to ensure this. - can formally specify and tools can make check to do the right thing.
* Attribute value constraints (new)
Provide mechanisms to formally specify constraints between values of multiple attributes.
* Associations (new)
Provide mechanisms to explicitly specify associations? Discussion around why this is needed to be explicitly specified in the language, as one can model associations as a table with two pointers. There was also the question about how associations are any different than the relations requirement. [David Harrington] - relationships can be embedded directly in class, while association tend to be separate classes. Fundamental language requirement appears to be that pointers can be specified. Relations/pointers and associations all seem to achieve the same thing with associations being a less efficient representation of a relationship. It is unclear why any language would need to have a special primitive for associations. UML represents associations as association classes, not as language primitives.
* Association cardinalities (new)
Cardinalities between associations should be formally defined (assuming associations).
* Method (parameters) constraints (new)
Provide constraints on method parameters (assuming methods).
* Table relationships (new)
Support REORDER (swap index order) and EXPANDS (nest tables) clause. EXPANDS is different than AUGMENTS because [Juergen Schoenwaelder] - AUGMENTS means every row in table B has a row in table A (1-to-1), EXTENDS is sparse augmentation (1-to-[0,1]), EXPANDS means a row in B may have many rows in A (1-to-N). Could be used to emulate arrays by using creative indexing.
* Machine readability (new)
Complete ABNF specification of grammar is desirable. SMIv2 has none. This should be renamed to ABNF specification requirement.
* Float data types (new)
Support Float32, Float64, Float128 - IEEE defines float 128, is there really a requirement for 128? [David Harrington] - requirements is really a wish list, looking to see which proposed requirements are controversial and why.
This list of requirements came from the current requirements document, only broken down item by item. After the proposed requirements were presented, it was asked how new requirements can be added. The mailing list is the right place to put forth any additional requirements, clarify existing requirements, or provide motivation. Since the charter assumes the same functionality that is already in the SMIv2 and SPPI, it is not necessary to list such existing features item by item. Some of the more interesting or misaligned features of the SMI and SPPI have been shown in this list simply to emphasize their existence. If features already in the SMIv2 or SPPI are deemed unnecessary, complex or otherwise broken, there needs to be a specific requirement to remove that feature (since all existing features will not be specified individually, but assumed a requirement nonetheless). Fundamentally, the proposed requirements will not become real requirements unless their existence can be motivated by the WG. This process is also to be carried out on the mailing list. Newly proposed or even existing requirements that lack proper motivation will not be part of the final Requirements document. For new requirements, it would also be useful to specify how they may be implemented, since requirements that cannot be implemented given the current protocols are not valid for this WG. Not asking for the final proposal (implementation), just some evidence that the requirement is pragmatic.
The final step will be to prune the requirements down into a list of well-understood and well motivated language features that can be implemented with the existing protocols. The current list shows many nice to have features so we can be intelligent about what to keep and what not to keep. It is not expected that the final requirements document will have them all.
It was asked that a translation mechanism from the SMIng to SMIv2 be provided which segued into David Perkins presentation.
3. Translation to SMIv2 Format presentation by David Perkins:
SMIng mapping to SNMP1/2c/3 - rules for defining how elements of SMIng modules are mapped to "varBinds" in the SNMPv1/2c/3 protocols.
SMIng translates to SMIv2 - rules to defining how elements of SMIng are translated to SMIv2 MIB modules.
Translation Usage Model: Core SMIv2 modules will be converted to SMIng modules (SNMPv2-SMI, etc). For each existing SMIv2 MIB module: 1. will be converted to one ore more SMIng modules 2. reverse mapping will be applied to create an SMIv2 MIB module 3. module will be placed in SMIv2 repository. Likewise, each new SMIng module will be translated and added to the SMIv2 repository.
Forward translation, we MUST be able to convert all correct SMIv2 MIB modules to one or more SMIng modules. This SHOULD be minimal amount of effort, and initial pass SHOULD be assisted by automation. This will require intelligent decisions by the person(s) doing the conversion and there w ill be many choices
Observation: it appears SMIng will result in many more direct dependencies than found in SMIv2. The tradeoff is fewer items defined and "elimination" of "cut-paste-and-adapt". This is a property of an OO design. Requires much more initial analysis to get the base class definitions "right", however.
Backwards translation, we MUST be able to convert SMIng modules, which were originally in SMIv2 format back to SMIv2 MIB modules without loss of information. Don't forget about compliances and capabilities.
Standards Process Considerations, we don't want to recycle when update is to only to convert the format. This wasn't given enough attention with SMIv2.
Data type issues, we MUST solve issue of support for new data types in SMIng that don't exist in SMIv2. I.e. Ineger64, Unsigned64, Float32/64/128, Other (Union).
Some were of the opinion that a reverse translation from SMIng to SMIv2 should not be a requirement. It was also noted that not everything will be translatable. Such things will either require workarounds, or no translation is provided for such things at all. It was noted that SMIv2->SMIv1 translators are not perfect. The conclusion was that the WG members interested in a requirement for providing a translation mechanism from SMIng to SMIv2 put up some text on the mailing list that precisely conveys their desires.
Requirements: Translation to SMIv2 Format