Current Meeting Report
Slides


2.4.9 Next Generation Structure of Management Information (sming)

NOTE: This charter is a snapshot of the 54th IETF Meeting in Yokohama, Japan. 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 interim meeting in Washington DC June 6-8 2002

    Minutes reported by David Durham.
    Special thanks to those who recorded the minutes: Juergen Schoenwaelder &
    Steve Waldbusser.


    Attendees:
    Joel Halpern
    Andy Bierman
    Bert Wijnen
    Randy Presuhn
    David Harrington
    Steve Waldbusser
    Juergen Schoenwaelder
    Chris Elliott
    Glenn Waters
    David Durham
    Wes Hardaker
    Rob Fry

    June 6, 2002:

    * Status and Update:
    o Where are the sming documents? They had expired (this is fixed).
    o Jeff withdrew smiv3 proposal, supports smi-ds.
    o Andreas is not pursing asn1 proposal.
    o Latest smi-ds version 00 on web page (actually third revision from Andy)
    o Consensus recap from last IETF meeting:
    * N-levels of nesting: Yes
    * Hierarchical instance naming: Yes
    * Continue using SMI syntax as much as possible: Yes (for the time being)

    Juergen presented for discussion questions related to high-level goals in an
    attempt to better understand consensus. Clearly we desire a more powerful
    language so that 1. Human readers can understand data models more easily and 2.
    Human writers can express their models in a better way. But do we want to
    support more than the current SNMP technology? The consensus was that more is
    fine, but the primary target is SNMP technology, for both monitoring and
    configuration. So retaining compatibility with current SNMP technology is
    desired. Attendees wanted the ability to convert from SMIv2 to SMIng (a
    requirement), and converting SMIng to SMIv2 only where possible (not a
    requirement). The other question concerned the SPPI. As this topic has been
    addressed in the past, the chair repeated that this working group will not be
    constrained or concerned with backward compatibility with SPPI. COPS-PR
    supporters are responsible for writing a translation if they desire it.

    Juergen went on to explain why Frank and himself had reservations to the SMI-DS
    approach. People want to improve the SNMP technology for both monitoring too.
    SNMP technology is even worse for configuration management. Frank/Juergen
    believe that we should not change the things that are working well enough.
    Specifically, they believe changing instance naming will break many
    applications. The other attendees did not agree. No one who had applications
    thought that they would be adversely affected by the SMI-DS naming scheme. MIB
    walks will still work, and the advice was not to use old tools to view new
    structures anyway. Ideally there shouldn't be any changes that result the wire
    protocol, but adding new base types is clearly an exception. Juergen ended by
    suggesting that it was the lack of high-level operations that was the main
    problem, and using an RPC mechanism would be a good thing. Andy agrees that
    having clear elements of procedure/use cases for those things people typically
    do would be beneficial. Overall, people wanted to improve readability and
    clarify the syntax of the language. Two clear non-requirements was the idea of
    making it easier on the tool writers (who are a minority) as well as providing
    annotations to the language. It was felt the latter would be best handled by
    separate documents, not inline with the standards (overall, making it hard to
    add new a syntax clause was considered a feature and not a bug).

    Finally, Juergen strongly believes that the language should be familiar to the
    majority of people out there. There is no language out there that has the
    concept of a leaf. Randy agrees that what we do in the smi is different than
    what most cs students are familiar with since we use different terminology. Andy
    doesn't believe that SYNTAX or MAX-ACCESS is the problem, it is the lack of data
    modeling and data structure. Clearly, however, OBJECT in the smi is not what
    people think it is.

    * Terminology:

    o Continue to use SMI terminology? Don't change what isn't broken, if it is, at
    least take pains to explain why when changing terminology.

    o Define delta's from existing SMI terminology for use this week:
    * SMIv3 will be the output of this working group.
    * Base Types = {Integer, OctetString...}
    * Derived Types = Refined Types: TCs. Smi-ds does not have a mechanism to extend
    existing structs in the OO sense. Sming has a mechanism to derive complex types
    from other complex types.
    * Scalar Types = Leaf nodes. Anything that is not an aggregate. Can even be a
    pointer.
    * Attribute=property=subelement(in XML)=node(smi-ds): The namable elements.
    Lot's of discussion, consensus toward the word attribute (aggregates can also be
    attributes).
    * Structure: Defines a set of attributes.
    * Class: Essentially a structure with methods. Neither smi-ds or sming have
    classes containing methods.
    * Object: ? Will not use this term moving forward, too much baggage.
    * N-levels of nesting (tables in tables, arrays in arrays...)=Aggregate types:
    Complex data types can be comprised of other complex data types, including
    arrays.
    * Hierarchical Instance Naming: using oids to name hierarchical instance data.
    * Unions: Choice.
    * Index: Instance identifier.
    * Row pointer:
    * Instance pointer
    * Typed Pointers=Constrained Pointers:
    * Intermediate Type Definitions
    * Name Spaces: Constrained/Scoped universe of identifier names.
    * Constraints: Clause that constrains the values an attribute may take.
    * Reusable (abstract) Definitions = type definitions
    * Leaf Nodes : node which does not contain other nodes. Attribute which does not
    contain any other aggregate type. Consensus was to change term to something more
    understandable.
    * Aggregated Data Object: This term refers to any data object which provides
    some sort of containment for other data objects, which is any variable construct
    other than LEAF (e.g., ARRAY, UNION, or STRUCT).
    * Data Object: This term refers to any SMI Data Structure variable declaration,
    at any level of containment.
    * MIB Object: This term generically refers to a SMIv2 OBJECT-TYPE macro
    definition. It may also refer to an SMI Data Structure definition.
    * OID: This is a shorthand term for 'OBJECT IDENTIFIER'.
    * LEAF: This term refers to any accessible data object with a syntax that
    resolves to a SMI base type.
    * Method is basically Elements of Procedure as can be determined from a Use
    case.

    Next was a discussion about the merits of having a hierarchical oid namespace.
    Hierarchical oids provide aggregates and aggregate information even at a
    protocol level. They also enable the individual items of the aggregate to be
    addressable. The difference between SMI-DS and SMIng documents is at what stage
    during the definition process are the oids associated with the datastructure.
    Consensus is that we want to explicitly assign oids within the data structures
    and not have map them or define arbitrarily later. Smi-ds provides for reuse of
    the suboid number as well as reuse of the data structures themselves, removing
    at least one level of indirection. Consensus was to preserve the hierarchical
    aggregations on the wire was a valuable thing to do (and not to strictly depend
    on the syntax definition).

    What followed was a discussion about indexing. SMI-DS keeps the index portion of
    the sub-oid on the right. The reason for this is that oid pointers (eg. Row
    pointers) expect indices on the right. If they are not, then old mib definitions
    will not be able to effectively reference new smiv3 mib definitions. Keeping the
    index on the right does have the side affect of making the getnext behavior look
    even stranger. It was noted that the protocol will not allow aggregates to be
    hidden, so you can only skip over hidden data. Given these issues, there was a
    suggestion for having two oid spaces, one with indexing on the right, another
    with indexing inline, adjacent to the current level of aggregation.

    Randy brought up the issue of unions and getnext. There is a problem with
    getting next lexical ordered element with a union because get next may skip over
    the union because the index is on the right. It wasn't clear how bad this
    problem would actually be, it simply would require the manager to try and get
    the possible union values directly. A possible solution would be to put the
    union discriminator on the end of the oid, but this will then mess up the
    lexical ordering.


    June 7, 2002

    Indexing was further discussed with Andy's (corrected) slides showing conceptual
    mib walk with smi-ds mibs. The main issue was how to determine where the prefix
    oid stopped and when the index portion began w/o requiring the smi-ds mib (some
    intermediate layers of the snmp stack may need to know this information, but
    won't have access to the definitions). It was suggested to use a .0 between the
    prefix and index portions to understand where the break point is. Since .0 is
    not allowed in mibs today, it could be used for this purpose. Another suggestion
    was to simply use meta data that specified where the prefix and index were for
    any given oid. Conclusion was there needs to be sufficient meta data available
    to figure out where each of the indicies are. But we should keep the naming the
    same as it is today. It was also suggested to use the meta data to encode the
    oid textual name, and other mib information so that mibs can be more
    self-describing (like XML documents). Other more radical suggestions were to
    move away from oids altogther, being that they seem to be the root of all evil.
    Needless to say, such a radical step would break backward compatibility. In
    which case, it would probably be better just to adopt XML or something else, and
    not invent yet another mechanism for network management.

    Next Steve presented the TRANSACTION clause concept to let implementations know
    what attributes are expected to be part of a transaction. CREATE-TRANSACTION
    {ipAddressData, ipAddressFlow, ...}. Needs to create transaction for an entire
    row, in the specified order. CREATE-OPTIONAL ... provides a list of optional
    transactional parameters. Most had an issue with forcing ordering. They believed
    that create and go is sufficient to perform this functionality w/o ordering
    constraint. The consensus was that it wasn't the ordering that matters, its
    dribbling out the objects over multiple atomic sets that is the problem
    currently. Some also had an issue with forcing some implementations to deal a
    "must not use" object in the transaction. The transaction clause appears to be
    useful vs. defval because there may be the need to combine variables across
    tables as part of the same transaction.

    Andy would like per high level object, elements of procedure. He just wants it
    clearly specified, it doesn't have to be in machine readable clause, could be in
    a description clause. Elements of procedure simply need to deal with the 90%
    cases, clearly describing the steps required to achieve a desired result.

    Next was a discussion on conformance. Much of the discussion related to
    enforcing conformance. DavidH suggested that we write a conformance test script
    at the end of every MIB (coincidently, scripts can be related to, or used to
    define, a use case as well).

    When applied to different levels of nesting there is an issue with status. What
    if deprecated objects exist in a type def? If its use as a variable is
    deprecated. What if it is deprecated as a type definition but its use is still
    current by some variable? ... The consensus was that this should simply cause a
    compiler to issue a warning.

    With respect to ACCESS, group consensus was that the equivalent of a MAX-ACCESS
    goes in a type definition that can be further constrained in the variable
    definition. Where as the C semantic only goes from the first level down, we want
    it to apply through all levels of nesting.

    There was some discussion on the scope of reuse/amount of reuse. The old smiv2
    pointers don't allow you to point at a particular instance of an aggregate. How
    to distinguish between high-level object pointer vs. low-level instance pointer.
    Oid based id's currently point at first accessible column. In an aggregate
    composition, it is difficult to define what the first "column is", so we should
    define smiv3 pointers in a new TC. Terminating the object tree with a "0" will
    help describe where the base oid ends and the index portion starts. Bert
    mentioned he has seen zero's in the prefix before, but this is not allowed, so
    we shouldn't be overly concerned. This would help to define aggregate pointers.
    There is value keeping the oid structure because we can remain backward
    compatible with the SMI, and old mibs can point to leafs of new data structures.
    Though when getting to aggregate data types, vacm becomes a problem.

    Long discussion that the constraints imposed by the current protocol and charter
    dilute the possible solutions. David Harrington presented removing UDP
    limitation, port 161 restriction, 484 byte limitation, ASN.1, Security
    restrictions, Get/Set/oids, no meta objects, no rpcs, no create/edit/delete.
    There is the belief that OIDs are a big problem.

    For now we can move forward with data aggregation and aggregated instance
    naming. Preserve SMI compatible naming and we would like to get an SMI out the
    door that will still work with SNMPv3 & v1. Finally, we can add features into
    the language that would be useful for future protocol extensions. We just need
    to write guidelines that specify when these features will actually be used. Some
    things people would like:

    * Getting away from global descriptors that have to be less than 64 bytes long.
    * Indices can be longer than they are today
    * Allow multiple sets of indices
    * Introduce methods and/or elements of procedure
    * Support for transactions
    * A uniqueness clause that is different from indices
    * Remove those annoying little rules: what you are allowed to create, what you
    are allowed to change (revisit these). Eg. New conformance mib, once you
    identify the version at run time, no need to deprecate a mib. Not allowed to
    extend the range of an integer but you can extend enumerations.

    June 8, 2002

    There was a discussion about allowing anonymous types for adding columns. People
    were comfortable with removing anonymous types IF one can add columns to the
    named types. Then you have a short binding after the type declarations. Randy
    cautioned that it can lead to readability problems, but the group consensus was
    that using a type means you will have to know what the type is.


    Next, Juergen lead a detailed discussion about how to merge the documents and
    key issues still to be addressed:

    General Issues:
    ===============

    - Should we change name of the converged version to SMIv3? The Group consensus
    was yes.

    - The agreed set of documents & authors:

    1. SMIv3 Language Definition: Andy, Juergen, Frank
    2. SMIv3 MIB Modules(core types): Juergen by July 1st.
    3. SMIv3 Guidelines : Andy
    4. Transition from SMIv2 : Andy, Chris
    5. Capabilities MIB : Andy, by June 24th.

    6. INET Modules (textual conventions) ?

    IETF deadline: July 1st for revised documents, June 24th for new documents.

    The list of specific items below were addressed during the meeting and the group
    consensus is reflected therein. Any specific objections to the group consensus
    items listed below must be sent to the sming mailing list. Keep objections
    specific.


    draft-ietf-sming-0x.txt:
    ========================

    - Changed the data format from ASN.1 ExtUTCTime to the format `YYYY-MM-DD HH:MM'
    or `YYYY-MM-DD'. The group consensus was this is fine, but should clarify that
    this is UTC time. Reason for changing: The current smiv2 format is unreadable to
    most people.

    - The set of SMIng base types is not identical to the set of tagged types used
    in the SNMP protocol. SMIng base types:

    Integer32, Unsigned32, Integer64, Unsigned64, OctetString, ObjectIdentifier,
    Bits, Enumeration, Float*

    Consensus was this is OK and base types should not be imported. While derived
    types must be imported. The reason for the change: Make the type system
    consistent with up-to-date languages, also there should be no spaces in keywords
    because they make parsing a pain, and finally this gives us a consistent syntax
    for types.

    - [1] OctetString vs OCTET STRING and [2] (SIZE (1..20)) vs (1..20) and [3]
    '0a0f'h vs 0x0a0f. Group consensus was:

    1. Use OctetString? OK
    2. Use SIZE and RANGE? NO
    2a. Use no SIZE and no RANGE? NO
    2b. Use what we have now? OK (not consistent, but not worth fixing)
    3. Stay with '0a0f'h : OK (because it is meaningful to BER encodings to have
    module 8, where as with c the encoding is fixed/same size.

    - Pointer as a base type rather than OBJECT IDENTIFIER. Syntax of Pointer
    restrictions. The room consensus was that Pointer should be a derived type so
    one has the flexibility to change it later.

    Distinction between Pointer and Identifier? (Examples are RowPointer and
    TDomain.) Group consensus was YES.

    Call Pointer Reference? No agreement. Pointer aligns with RowPointer,
    InstancePointer and does not clash with REFERENCE. Consensus was to go with the
    word "Pointer"

    - [1] ObjectIdentifier vs OBJECT IDENTIFIER and [2] dotted notation for OID
    values (including/excluding hexadecimal values) and module namespace separator.
    The group consensus was:

    1. Use ObjectIdentifier keeping with reasoning discussed for types above.
    2. Should we add even more stringified versions of these oid numbers?
    Rationale: Cut & paste between MIBs and SNMP implementations.
    Keep in addition the { ifIndex 1 }?
    Some confusion between { iso foo(2) 3 } and { iso 2 3 } and { iso foo 3 } ...

    No conclusions on point 2.

    - Hexadecimal Integer32/Integer64/Unsigned32/Unsigned64 constants ('0a0f'h vs
    0x0a0f). The group was to keep using the quoted ''[hH] format.

    - Float32/Float64/Float128.

    People wanted to know why so many versions, why not just Float64?
    Objectives document says some kind of floating type support is required.

    - Enumeration vs INTEGER and syntax of enumerated values. What about things that
    have been coming up such as status for enumerated values or descriptions for
    enumerated values? Group consensus that using Enumeration is OK but do not add
    more stuff for named numbers.

    - Bits vs BITS and format of Bits named numbers. The group consensus was to use
    the smiv2 { ... } format. This is not broken.

    - Display formats are similar to SMIv2. There were however some comments some
    months ago to change them. The group consensus was to keep them as they are -
    though the usefulness of display hints is questionable - so keep it as is unless
    someone comes up with good proposals on the mailing list.

    - Comments. Allow // or keep the current -- with the arcane ASN.1 rules? Group
    consensus was mixed, rough consensus was to change to // because the reasoning
    was that more people are familiar with it (DavidH says -- comments often confuse
    readers). Others suggested using # for comments though this would confuse
    preprocessors. Given the varied differences of opinion, it is probably best to
    leave comments unchanged from the smiv2 style, possibly with the exception of
    just making them continue to the end of the line.

    - CAPITALIZE all KEYWORDS for improved SMIv2 look & feel? The group consensus
    was yes, keeps things similar to smiv2 look & feel.

    - Use a consistent syntactic structure "<keyword> <identifier> ..."? Juergen
    thinks SMI-DS also has changed into this direction. The group consensus was yes.


    - Where to anchor module meta information? Removed the LAST-UPDATED clause - use
    data of last REVISION instead. The group consensus was yes, remove the clause.

    - Multiple import statements?

    IMPORT IANAifType
    FROM IANAifType-MIB

    IMPORT mib-2
    FROM SMIv3

    IMPORT AutonomousType, Counter32, Counter64, DisplayString255, Gauge32,
    PhysAddress, RowStatus, TestAndIncr, TimeStamp, TimeTicks,
    TruthValue
    FROM SMIv3-TYPES

    IMPORT snmpTraps
    FROM SNMPv2-MIB

    With or without semicolons? The group consensus was to get rid of the semicolon.
    The group was also comfortable with having an IMPORT for every module. This
    makes cut-copy-paste operations easier.

    - Remove the extension statement? The group consensus was YES.

    - Change typedef to TYPE? SMIng allows DEFAULT clauses in TYPE definitions
    (which can be overwritten in ATTRIBUTE definitions). Do people feel comfortable
    with that? The group consensus was YES.

    - Change 'type' back to SYNTAX for improved SMIv2 compatibility? Group consensus
    was YES.

    - OBJECT-IDENTITY vs IDENTITY and late OID assignment.

    Change: foo OBJECT-IDENTITY ... => IDENTITY foo ...

    The group consensus was this change is OK, it is less verbose.

    - CLASS vs. STRUCT? The group consensus was to use STRUCT.

    - Should notifications be bound to aggregate types? There was much discussion,
    and other worlds have generic notifications such as a status change which can be
    applied to various objects (interfaces, physical entities, ...). People wanted
    to see the syntax to understand the usefulness of reuse here:

    STRUCT Status {
    ATTRIBUTE adminStatus
    ATTRIBUTE operStatus
    EVENT statusChange
    }

    STRUCT Interface {
    ATTRIBUTE status { SYNTAX Status }
    ...
    }

    NOTIFICATION Status.statusChange {} = base.32

    Reuse might be useful, but details need to be worked out.

    - Discriminated Unions need to be added. The group consensus was strongly YES,
    as seen in the smi-ds proposal.

    - Arrays need to be added. The group consensus was YES, again as in the smi-ds
    proposal.

    - Remove inheritance? The group consensus was YES. Reason, adding
    aggregate/structured data is sufficient. Inheritance adds unwelcome complexity.

    - Implicit export of everything vs. "static" definitions? No agreement, this
    needs to go to the list because it is unclear what the benefit is outside of
    code modules.


    draft-ietf-sming-modules-0x.txt: ================================

    - Modules need to be adapted to reflect the syntactic changes. The group
    consensus was yes.

    - 'nil' vs. 'zeroDotZero'. The group consensus was to go with what we have.

    - Merge contents of IETF-SMING-SNMP from draft-ietf-sming-snmp-0x.txt back into
    SMIV3-TYPES. The group consensus was yes.


    draft-ietf-sming-snmp-0x.txt:
    =============================

    - TABLE vs. VAR ARRAY and SCALAR vs. VAR STRUCT?

    VAR would be enough in both cases since the presence of an INDEX in an aggregate
    allows to distinguish both cases.

    1. TABLE vs. ARRAY - The group consensus was to use the word ARRAY because table
    already has a different meaning in DB land.
    2. INDEX clauses might not always be bound to the aggregate type to allow index
    swapping. - the group consensus was yes.
    3. VAR ARRAY vs. VAR UNION vs. VAR ... even though the second keyword is not
    really needed? The group consensus was that it may help the reader to see the
    second keyword.

    Side step: What is a VAR UNION?

    UNION Foo {
    ATTRIBUTE a { ... INDEX {} ... }
    ATTRIBUTE b
    }

    VAR UNION c { SYNTAX Foo INDEX {b} }

    This probably needs more thought.

    The group consensus was to syntactically go with the VAR <aggtype> notation for
    now. Also INDEX clauses (and similar beasts) are only allowed in ARRAYs.

    - Allow anonymous aggregated types? The group consensus was No.

    - Move revised version of introduction text from this document back into the
    main SMIng document. The group consensus was YES.

    - Other text needs also to be merged. Everything needs to be merged.

    YES

    - Define the rules for legal OID values? There has been ongoing confusion what
    the restrictions on the first two subidentifier are. The group consensus was
    YES, people wanted to cut & place into applications, define what is a legal
    subid. Should also clarify we are not using ASN.1 notation here.

    - Move mapping to today's SNMPv3 back to the main SMIng document. The group
    consensus was YES.

    - The notification statement probably needs some work (see above).

    Yes, see above.

    - SMIng does not distinguish anymore between OBJECT-GROUPs and
    NOTIFICATION-GROUPs. They are just GROUPs. Is this useful? The group consensus
    was that the distinction is not useful.

    - SMIng removes the common

    MODULE -- this module

    construction as the same effect can be achieved in other ways.

    Seems to be an odd construction, the group consensus was to either require the
    module name or get rid of it, making it optional helps nothing.

    - Would be nice to be able to define GROUPs for foreign definitions imported
    from other modules.

    - Would be nice to have simpler compliance statements. The group consensus was
    yes, this would be nice, but someone has to provide proposals.

    - The keywords EXTENDS and EXPANDS sound too similar and are thus a bit
    confusing.

    Use SPARSE-AUGMENTS since CISCO uses it in comments.

    SMI-DS does not provide EXTENDS anymore. Need to think about it.


    draft-ietf-sming-inet-modules-0x.txt:
    =====================================

    - Definitions need to be adapted to new syntax. Yes.

    - Definitions must be aligned with recent changes in other MIBs. Perhaps the
    INET-ADDRESS stuff should not be done here but rather in a revision of the
    INET-ADDRESS-MIB since this is now actually being used? Yes.



    Slides

    SMI-DS Issues