2.4.11 Next Generation Structure of Management Information (sming)

NOTE: This charter is a snapshot of the 51st IETF Meeting in London, England. It may now be out-of-date. Last Modified: 31-Jul-01


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:



IRTF documents complete & submitted to IETF

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 Request For Comments

Current Meeting Report

SMING meeting minutes 8/6/2001

Chair: David Durham
Reported by: David Durham
Special thanks to Steve Moulton and David Harrington for taking minutes during the meeting.

The SMIng working group meeting took place on Monday, August 6, 2001 at the 51st IETF (London). The meeting was chaired by David Durham. Steve Moulton and David Harrington were the minute takers.

The agenda consisted of the usual agenda bashing, a document status review, review document changes since last call on the requirements I-D, and reviewing conformance of the current documents to the requirements document. There were no calls to change the agenda as proposed.

An interim meeting was held in Seattle in May, 2001, in conjunction with the IM2001 meeting held the same week. This meeting dealt primarily with the requirements document. This document has since gone through working group last call.

There are six documents in progress.


All documents except the SMIng mappings to COPS-PR (01) and SMIng requirement (03) are at second revision. The requirements document will soon be available as revision 04.

Note also the requirements document that resulted from the operations and management interim meeting held in conjunction with NANOG: draft-ops-operator-req-mgmt-00.txt

Summary of issues brought up during the last call period:

. Too many requirements
. Avoid egregious syntax changes
. Map directly to protocols, v.s. to SMIv2
. Why address COPS-PR at all?
. Why isn't there better collaboration with EOS?

Jamie Jason reviews list of changes incorporated since last call was issued. See the slides for the complete list.

A lively discussion followed.

A query was made from the floor regarding the state of internationalization in the SMIng effort. Bert Wijnen responded that you would not be allowed to write a standards track MIB using a national language, as English is the defined language for IETF documents. However, there is no limitation on writing enterprise specific MIBs or MIBs in other organizations in other languages than English.

Joel Halpern noted that the requirements as written imply that the goal of merging SMI and SPPI and the goal of a more expressive language are somewhat inconsistent. Either we are trying to improve the state of the art, or we are trying build the smallest possible superset of SPPI or SMI that will deploy easily. It is difficult to have it both ways. He would prefer to focus on advancing the state of the art.

David Durham asked for a discussion of the WG priorities. Should our primary task be improvements for SNMP/SMI, with a secondary goal usability for COPS/PR? The room consensus, as described later was clearly in favor of prioritizing advancing the state of the art first.

AD: The goal is to address some of the issues we have had in SMI for some time (Integer64, etc), and get SMI and SPPI converging, and to advance the language to make it more usable. Those are the three goals. What should be avoided is evolving requirements that are not reasonably achievable. Feedback from Andy Bierman is that we need to evaluate the costs of meeting these requirements vs. the benefits.

There was a specific objection to requirement 43 (changing the instance naming so that SMI and SPPI would be similar). Redoing instance naming is a change that would be detrimental to both SNMP and COPS and doesn't seem productive. Low hanging fruit (UNIQUENESS, etc) are reasonable. Instance naming, and separating protocol dependent and independent parts are hard. In requirement 45, split those things out that are bad. Andy Bierman would like to remove requirements 43 and 45.

On the other hand, Walter Weiss stated that he is a little puzzled by the justification for removing arrays, since they can be done in both MIBs and PIBs. Yet they're awkward to do currently. He'd like to make their use more elegant in sming. It was responded that the requirement for arrays was somewhat unclear, e.g. whether or not you could get atomic access to arrays was not clearly stated. Walter stated that this would be an area ripe for improvement, and Dave noted that arrays are still currently listed as "nice to have" in the requirements I-D.

Mike Ayers asked what art are we trying to advance here. Many of the requirements have nothing to do with consolidating SPPI and SMI. He can't tell if the requirements are good without more justification. He asked that if he goes in and reads the charter, if a requirement is not in the charter, should it not be in the requirements? The answer was that advancing the state of the art is a goal of the charter, and the primary goal of the WG given the consensus of the room. The requirements document is simply a very detailed listing of items that achieve the goals of the charter. A cost vs. benefits analysis will need to be carried-out when proposals are evaluated.

It was noted that the requirements posted by the operators in the Scottsdale meeting were very interesting in seeing what they want to do. There were no requirements for improved MIB readability or even use of MIBs at all. Bert observed that while we should all be concerned about the operators' document, it doesn't represent everyone. Joel also commented that the operators who expressed their opinions were very clear, but there was a question of whether they represented a representative set of operators. Walter Weiss noted that their point in that document is that they had to be able to work directly with a device sooner or later. The ones who were there were very clear about where and how they wanted to function.

Joel Halpern said that we have a number of requirements that are not directed towards unification and are very protocol specific. He can't get a handle about what is sensible to include. Dave Durham responded that there are those who think Integer64 and a few other needed fixes are advancing the art and that the requirements are likewise very detailed listing each of these prescribed fixes as well.

Jeff Case addressed requirements 3, 4, and 45 (human readability, machine parsability, and SMIng not assigning OIDs). He stated that he had made a general comment on the list that 45 requirements are too many to focus on. Having that many requirements is the antithesis of finishing in finite time. He went on to note that requirement 45 conflicts with requirement 4, and requirement 3 also conflicts with requirement 4. Making it easier for humans to read and write MIBs conflicts with making parsers easier to write. These three goals show that you cannot optimize 45 goals simultaneously.

Addressing the machine parsability requirement, Walter Weiss stated that we want to make sure that the grammar generated is unambiguous, and that we don't allow it to be ambiguous in the future. Randy Presuhn agreed, stating that it is much more important that the grammar be rigorously defined than easy to parse, since few will be writing parsers, but the language must be clear.

The point was also raised that it must be easy to distinguish objects that have security implications.

Dave Durham asked if it would it be OK to replace the requirement that states the syntax is to be easy to parse and replace it with a requirement for a rigorously defined syntax? This seemed to ease frustration with the requirement, though Jeff Case favors human readability over ease of machine parseability in any case. It was pointed out that making both machine & human readability objectives will force the WG to balance the two appropriately.

Another speaker observed that he finds this whole conflicting requirements discussion a bit baffling. It would be sufficient to require that the language be written in LALR(1). This it makes it easy to write parsers. There is plenty of room to work with the resulting syntax to make it human readable. So what's the conflict? There was no further discussion on this point.

The chair attempted to determine if there was sufficient consensus that the requirements are good enough. To this some express that they think we have enjoyed the requirements document about as much as we can. Being torn between "good enough, ship it" and "we need to work on this thing some more, as we are going to use it to guide our future work". Jeff for one doesn't completely agree with it, but he doesn't want to work on it any more. He'd like to move on.

David Harrington said that he made the suggestion after we originally did the requirements that the goals are not laid out. We have two different problems and sets of requirements (advancing state of the art, and SMI/SPPI merge), and we ought to be looking at it as such.

Dave Durham asked the question: Should we move the requirements document forward as an informational RFC? The room consensus was that we should.

Wes Hardaker stated that in Seattle, we started with 75 requirements. After 10 hours of not eating, we whittled it down to 45. It is clear that there are a lot of people that want these 45. Now, if we stamp this an informational RFC, then it seems like we need to meet all of the requirements. At this point, we need to solicit proposals to meet these requirements. We ought to put words at the top of the requirements to translate "requirement" to SHOULD, not MUST. This moves the document from list of requirements to a list of features.

Room consensus is to change from 'requirements' to 'objectives' to address this point, and also to recognize that a costs vs. benefits analysis will need to be applied to the objectives once we get to looking at proposals.

The minutes of the discussion that follows was specifically to determine the priority order of the different WG's tasks as specified by the charter (merge the SMI/SPPI and advancing the state of the art).

Dave Durham's suggestion is to focus on one goal or the other first, and thus avoid any conflicts between the two. The requirements don't change if you do one or the other, you just address the relevant requirements for the primary goal first.

It was noted that we can roll 64 bit integers into the SPPI/SMI merge requirement, as it is in the SPPI and also improves the state of the art.

Andy Bierman noted that he is all for merging things where the result is an advancement. He is much more interested in using the new class definitions rather than some of the constructs that seem less interesting out of the SPPI. We don't want to spend a lot of time nailing the requirements, because that implies that we know exactly what we are going to do before we can do a cost vs. benefits analysis given a proposal. The requirements are specified well enough for us to continue. He is much more concerned about changing instancing than about changing upper vs. lower case. Andy is in favor of advancement, with the proviso that we instruct the EOS working group not to hack it.

Glenn Waters said that SMING is constrained and EOS is constrained to the current framework. We should change both of the charters to deal with this, or say we are going to do something simple or quick.

The issue of goals of the WG was then readdressed. Bert Wijnen said that we want to advance the state of the art within bounds. Once we get this language, he doesn't want working groups to have to write both MIBS and PIBS. So this stays in the charter.

Steve Waldbusser noted that there are some move forward things that he would call required maintenance. Advancing the state of the art in network management may not involve advancing the state of the art of SMI. One of the things that we feel pain over is that people are not using SNMP for configuration. The reason that vendors don't use the tools we create is that it is hard to do so. Adding more state of the art may make it harder. We need to be careful and balance these things. Again, a costs vs. benefits analysis will be in order.

So Dave Durham called the question: Do we want as the primary goal to advance the state of the art of this language or simply merge SMI/SPPI? The room consensus was clearly in favor of advancing the state of the art of the SMI as the primary goal of the WG.

Dave Durham stated that the work product from the NMRG has been put forward as a proposed syntax for SMIng. He asked what other syntax proposals people have for the next generation SMI.

Harrie Hazewinkel noted that the NMRG syntax has been worked on for a long time. Do you expect a proposal to be of similar quality?

Dave Durham said that there are already several popular syntaxes that exist to choose from. So no one should be inventing something completely new. ASN.1, NMRG, and a possible XML proposal were all proposed. There would be a syntax comparison between proposals.

Several questions and statements arose around the process, such as

. What is the time frame for these grammar proposals?
(Chair: at least one month from the time an announcement is made on the mailing list.)

. Does the language have to be written in ABNF?
(Chair: The proposal is for a "rigorous grammar".)

. Juergen observed that the grammar isn't the issue. The interesting part is what we do with the data that comes out. Andy agreed; he didn't want to have the discussions about the minutiae, but wanted get on with what the constructs are. The chair commented that it's the results of what you achieve, not the grammar.

. Is it in the charter to consider existing technologies such as SOAP?
(Chair: We are considering data description, not communication protocols. Or goal is to advance the SMI.)

. Randy Presuhn observed that some of us remember a number of other information models; To what extent are we interested in revisiting some of these concepts?
(Answer: We are only interested in the concepts that were considered during the requirements process, some of which were derived from these models as well, e.g. DMI->CIM, GDMO etc.)

Chair: The chair will address on the mailing list what is the exact mechanism and time frame for submitting proposals.

Meeting was closed at 5:30 PM.


SMIng Requirements Review