Current Meeting Report
Slides
Jabber Logs


2.4.9 Next Generation Structure of Management Information (sming)

NOTE: This charter is a snapshot of the 55th IETF Meeting in Altanta, Georgia USA. It may now be out-of-date.

Last Modifield: 05/30/2002

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: http://ops.ietf.org/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:
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
Internet-Drafts:
  • - draft-ietf-sming-snmp-02.txt
  • - draft-ietf-sming-modules-02.txt
  • - draft-ietf-sming-02.txt
  • - draft-ietf-sming-inet-modules-02.txt
  • - draft-ietf-sming-copspr-01.txt
  • - draft-ietf-sming-compl-00.txt
  • - draft-ietf-sming-ds-00.txt
  • - draft-ietf-sming-caps-mib-00.txt
  • Request For Comments:
    RFCStatusTitle
    RFC3216 I SMIng Requirements

    Current Meeting Report

    SMIng Meeting Minutes from IETF55:
    
    TUESDAY, November 19, 2002 Time: 1930-2200
    Minute takers: Ravi Sahita
    Minutes reported by David Durham
    WG Chair: David Durham
    
    Issue: Updated documents have not been produced. We need volunteers to 
    progress the SMI-DS related document set. Need more participation on the 
    mailing list.
    
    Chair:
    
    Revisited Charter and Milestones. Updated charter was put on the mailing 
    list. No issues raised on the list, no issues raised at the meeting 
    either.  According to the charter milestones we are a year behind. The 
    original milestones assumed the nmrg documents which were complete, but the 
    wg chose to investigate the smi-ds route. We will still need a few 
    iterations on the smi-ds/v3 documents before they will be complete. The 
    current proposed list of documents in priority order is:
    
    -	1. SMIv3 Language Definition ANDY BIERMAN
    -	2. Capabilities MIB DONE
    -	3. SMIv3 Guidelines 
    -	4. Transition from SMIv2
    -	5. SMIv3 MIB Modules (core types)
    -	6. INET Modules (textual conventions)
    -	7. RFC 2580 Conformance Updates 
    
    We need volunteers for the documents or the wg will shut down, and the smi 
    will not progress. Previous volunteers for the guidelines and 
    transition documents are waiting for the language definition. In 
    principle, people support the smi-ds work, but we will need people to sign up 
    to get the work done. Likewise from the discussion at the wg meeting it 
    seems that there is a lot of waffling on how we proceed item by item 
    through the open issues listed below.  
    
    
    
    Wes Hardaker presented SMIng enhancements that would be useful to his OOPS 
    proposal:
    
    Nested data structures such as Subarrays in arrays (eg. where you can have 
    multiple interfaces and multiple addresses assigned to each 
    interface) make indexing subelements difficult. Wes proposes that 
    internal indices are given a local number. Advantage is that we have a 
    local index to it including external indexes. This enbables all 
    elements to be mapped to an OID.
    Something like:
    	INDEXS otherIndex
    	FROM otherTable ::=  {base 1}
    
    What does this have to do with the SMI: If you pick an augmentation 
    table.  Not a problem for previous SMI structures, but problematic to have 
    nested structures because need to go down to the index. 
    
    There was a lot of discussion whether or not this is useful. It 
    provides a way to separate the data instance index part of the oid from the 
    data type part of the oid. There was concern that this mechanism would 
    affect transpartent forward translations from SMIv2 MIBs, but this will 
    apprarently only affect new SMIv3 definitions where there is nesting and not 
    SMIv2 stuff. Andy made it clear we should only have one version of the SMI 
    and not create the need to continually support two versions. There was no 
    consensus in the room that Wes's proposal was a necessary or 
    appropriate language mechanism. Wes was to post to the list some cases 
    where this is valuable, removing oids where possible, to better support 
    compression because his new PDUs have a base root oid. 
    
    
    Next it was pointed out that external augmentations are a pain from the 
    protocol's perspective with multiple random OID assignments.  Any chance we 
    can fix this in SMIv3 via a forced local extension node?: Currently, if the 
    agent doesn't have the MIB definition locally, the agent needs to 
    interpret the oids without the MIB. One thing that makes 
    augmentation tables difficult is that if you don't know an agent 
    supports the table you wouldn't know to get it. It helps 
    understanding for those who are trying to query agents.  Andy pointed out 
    his original proposal fixed this by having a 0.enterprise ID where you 
    could augment right inline the oid hierarchy, but this went away when the 
    indices were all grouped back on the right of the oid to preserve 
    forward mapping of existing tables. Wes proposes that this is only for new 
    structures in SMIv3, but Andy believe we really need to go back to 
    understand the importance with the forward translation because we don't 
    want to have two versions of the smi going forward. The purpose is to make 
    the new oops protocol mappings work better with SMIv3 structures. 
    
    Again, there was no consensus in the room around this proposal. More 
    thought is needed to fully understand what the problem is before we add 
    more syntax to the smi, and Wes volunteered to elaborate on the problem on 
    the mailing list.
    
    
    Next, Wes suggests that smiv3 notifications should be able to contain 
    structs and possibly even arrays. Currently only support for single 
    objects.  Example: would like to be able to send all addresses 
    associated with linkup.  It would be nice to support new 
    notifications with more complex/complete data (like syslog). The limited 
    data that snmpv3 notifications support is a reason why operators use 
    prefer to use syslog instead of snmp. Wes is trying to define new PDUs to 
    make access to new more complete structures easier.  This affects smiv3 
    because notifications would now be able to support aggregate types 
    instead of just base types, but this would not be backwards with snmpv3. 
    There was more support in the room for this proposal over the rest, 
    however, enabling backward compatibility w/ snmpv3 requires more 
    thought. Others concluded that a similar result could be achieved if 
    strings are used and a standard syslog-like string format were 
    defined... No changes would be required to the language or snmpv3 to 
    accomplish this.
    
    Andy Bierman presents the SMIv3 Open issues:
    
    * NULL choice for union types:
    
    Like and SQL NULL value. Want to be able to create a template for a 
    generic table (eg. RMON control entry)... can create an instance of that 
    table and leave out stuff that you didn't need in your usage scenario. In 
    sming it was implements X and implements Y but not Z, which is like 
    partial inheritance.  Instead, he proposes the parent gets to tell you what 
    it can pick and choose, so it's not equivalent to partial 
    inheritance. Still, Andy is not convinced that this is worth the trouble it 
    might cause. 
    
    * Oid naming for aggresgates and sub-aggregates:
    
    How to tell you want to access row three down in the second nested array. It 
    was previously suggested having a zero to apply on the left to 
    distinguish the constant part from the instance identifier part. If have a 
    nested array want to get internal array now. Want more granularity to get 
    one object or get everything. This may be a moot point if the protocol 
    changes, and you don't get the support in SNMPv3 for it, so you only 
    support the fancy new aggregate new stuff with new protocol.  Also 
    weren't sure if adding .0's everywhere is backward compatible. Other 
    organizations have oids with 0's in them. For example, the IEEE 
    sometimes defines their own mibs, such as for the 802.1X protocol. The OID of 
    the IEEE 802.1 branch for mibs is { iso(1) std(0) iso8802(8802) 
    ieee802dot1(1) ieee802dot1mibs(1)}, so every mib put out by the IEEE 802.1 
    group will have a zero in the OID. The only rule currently is that the last 
    subidentifier per object can't be 0. 
    
    Andy would advocate doing new things with the new protocol and not trying to 
    retrofit into the existing SNMPv3 protocol. They should still work with 
    snmpv3, but they will be suboptimal there.
    
    The issue was raised that when you have multiple levels of nesting in your 
    oid, then your encoding rules either result in ambiguities or 
    undesirable behaviors in get next and get bulk. Andy believes that if you 
    are trying to get a leaf, and all the indices are on the right, there are no 
    ambiguities.  The suboptimal behavior of get next is the same bad 
    behavior that we already have today. The orders that we got were always 
    suboptimal. Getting rows would be correct, but we instead get the 
    columns. Still, the worst case and the specific issue was poor behavior 
    with unions, because the order is questionable. 
    
    The question was raised: Why not having a separate branch for all new 
    SMIv3 structures. Having naming that is helpful to us instead of being in 
    the way.  If you have only one layer of nesting then it falls out that the 
    indices are on the right, because they are in the right place anyway. 
    Bring this to the list, too complex to deal with now. Juergen 
    previously had objections to putting the new definitions under a new 
    branch, he thought it would break things. Others point out that 
    changing the root oid will make things much more complicated, eg. 
    dealing with all the enterprise-specific branches, users may get 
    confused about the differences between the branches, related 
    information appears under completely different branches, etc.
    
    * NOTIFICATION definitions in TYPEs:
    
    Proposal to move notifications into the types to be more OO-like. It is not 
    always true a notification can be tied to a specific set of data, 
    however.  Also not sure what problem this issue solves. Juergen 
    previously also wanted master NOTIFICATION (link up), and derived 
    NOTIFICATIONs. Suggestion was to take this to the list until we can 
    understand what Juergen wanted to do originally. Moving on...
    
    * Inline vs. by-reference TYPEs and VARs:
    
    Extend types by inline or by reference and only allow named types. 
    Interim decided that we only do it by reference, never inline. By 
    reference allows all constructs to be reusable. Adds some complexity in 
    terms of versioning.  We would never allow a type to be silently 
    extended, you would have to clone it. Another issue is it makes MIBs 
    harder to read because you have to search for type definitions. Some have 
    suggested that this makes things unreadable.  Turns out that people think 
    referencing things by type is an annoyance. Some things are simply not 
    meant to be reused. The MIB writer has to have some 
    responsibility with the freedom. Inline definitions should be allowed to aid 
    readability. *** The consensus in the room was to kill the proposal to 
    force all types to be reusable. ***
    
    * Descriptor naming issues for TYPEs. 
    
    BCP document would define what the limit is for different protocol 
    mappings, and the current limit that names are to be restricted to 
    <=32/64 will be eliminated. Hums agree.
    
    Require uniqueness only within the scope of the parent node. Can you have 
    descriptors that define the same data types. It needs to be fully 
    qualified.  It is important to distinguish between the name of the type 
    (eg. TC) and the name of an object (the oid). This discussion is 
    specifically around type descriptors.  You can use the module name 
    descriptor to find import name clashes.
    
    Finally, it was suggested we move to XML style names; mixed case with 
    hypens. Hums agreed this would be good to do.
    
    * Conformance section changes to support SMIv3. 
    
    Existing MODULE-COMPLIANCE macro won't work for SMIv3 objects. 
    Descriptors are not unique within the module. Existing problems with SMIv2 
    need to be fixed such as OBJECT clauses for INDEX objects. Need to create  a 
    construct for each complex VAR declaration... Could fully specify 
    attribute names; but it would be better to have a shorthand notation. Andy 
    suggests he will work on this offline, it's not an open issue, he just 
    needs to finish it. 
    
    * Change control issues for variables
    
    Need to be able to add new attributes to existing VARs, just as we add new 
    columns to an existing table now. We should be able to create a new type 
    which is a superset of an old type and allow VAR SYNTAX to change. Use 
    conformance section for version identification. Allow the writer to 
    replace FooType with BarType which is a superset of FooType. This could be 
    done with a Cut & paste operation, and can only add new definitions to the 
    end. If it is defining a subclass, need to increase the naming depth. It 
    would be useful to have an include clause since we want to be able to 
    compose new object definitions from the old definitions. This is 
    specifically for change control. Only semantics of fooType need to stay the 
    same, just need to add columns to a table in a radically new way. 
    
    * SMI syntax changes
    
    Many syntax changes proposed by at the last interim. Need to decide case by 
    case on the mailing list. Examples: Imports; LEAF, NODE or ATTRIBUTE; 
    OBJECT-GROUP ->GROUP; NOTIFICATION-GROUP -> GROUP; Base type names; 
    Remove MODULE - this module should be implied. There were no comments. 
    There was little support for syntax changes in the room.
    
    * Migration of SMIv2 CLRs to SMIv3
    
    Suggestion was to take them out of the SMI and put them into a separate 
    document particular to a protocol mapping. But we don't want to put the 
    sign that says no left on main and collect it with all other crappy 
    little road signs and put them in the same place. But, at the same time, we 
    need to make the language document somewhat future proof so when 
    protocols are upgraded, we don't have to update the full standard 
    document... Concensus in the room was to put these rules in a separate 
    informational document & thus easier to change. 
    
    * Support for Configuration:
    
    Need to distinguish between different types of objects: 
    Configuraton (acl list, bgp peer, users/passwords) vs. Control 
    (per-session debug commands, reset card) vs. State (ifOperStatus) vs. 
    Statistics (eg. ifInOctets). Need mechanism to describe high-level 
    configuration methods:Could be purely documentation, but they need to be 
    clearly specified in the MIB document... These could be more, such as the 
    minimum procedural requirements for a particular task. Don't call these 
    methods! Call them use cases or scenarios.  Specifically what is needed: 
    Mechanism to describe what has to be created in initial PDU, what can be 
    edited after creation, what is the cascading deletion order, etc. 
    
    * Support for XML naming , XSD translation.
     
    It would make the IETF more consistent if the SMI were to be the base 
    definition for everything, XML, COPS-PR etc. Would like to make sure there is 
    only one data definition, regardless of the number of protocols. Some 
    hints to make language definitions easier: Need to identify XML 
    Namespace for MIB; Add optional XML-NAMESPACE "<URI>" clause in 
    MODULE-IDENTITIY, or use XML namespace MODULE name; Need to identify XML 
    element names: Optional XML-NAME "string" clause in TYPE or VAR 
    constructs used to override descriptor as element name. Need to map ARRAY 
    population characteristics to minOccurs, maxOccurs attributes. 
    
    The question was raised, why so much emphasis on XML. Some question if it 
    was appropriate to put XML name mappings inline vs. in a separate XML 
    mapping document as there could be a separate sppi mappings document. 
    Given Andy's suggestions for support of XML naming, some expressed that 
    perhaps a better outcome of this wg effort would be to declare that 
    XMLSchema should replace the SMI.  
    

    Slides

    Agenda
    SMIv3 Open Issues
    EOS OOPS SMIng Issues