SMIv3 Open Issues

1
SMIv3 Open Issues

• Andy Bierman ltabierman_at_cisco.comgt

2
SMIv3 Open Issue List

• NULL choice for UNION TYPEs
• OID naming for aggregates and sub-aggregates
• NOTIFICATION definitions in TYPEs
• Inline vs. by-reference TYPEs and VARs
• Descriptor naming issues for TYPEs
• Conformance section changes to support SMIv3
• Change control issues for VARs
• SMI syntax changes
• Migration of SMIv2 CLRs to SMIv3
• Support for Configuration
• Support for XML naming, XSD translation
• Support for COPS-PR

3
NULL choice for UNION TYPEs

• Allow UNION definitions to contain a special
  attribute (node) that would not result in any
  accessible sub-tree in a VAR declaration
• Details
• Named attribute (name could be reserved keyword
  like null or no different than other attribute
  descriptors)
• SYNTAX could be special keyword NULL
• MAX-ACCESS not-accessible
• Example use
• Create a template for a generic RMON control
  entry, in which some attributes are not present
  in specific functions e.g., entriesRequested/entr
  iesGranted pair used in host or matrix control
  entry, but not etherStats control entry.
• Issues
• How to document in VAR declaration that NULL is
  used
• How to document requirements in the Conformance
  section

4
OID naming for aggregates and sub-aggregates

• Want to allow for protocol operations on all or
  part of nested data structures
• Problem
• How to tell where static OID components end and
  instance identifier components begin
• Proposal from Interim
• First component from left with a value of zero
  marks end of static portion
• Only applies if number of static components
  present actually less than defined in MIB
  otherwise first zero component (if any) is
  interpreted as an instance component
• Issues
• Backward compatibility does this break any real
  implementations?
• Should this be handled in EOS (forget SNMPv3)?

5
NOTIFICATION definitions in TYPEs

• Proposal from NMRG to place notification
  definitions inside STRUCT, ARRAY or UNION TYPEs,
  instead of independent NOTIFICATION declaration
  (as we have now)
• Issues
• Multiple instances dont make sense What is the
  OID for a notification inside an ARRAY?
• Notifications not always tied to a single data
  structure
• What problem does this actually solve?

6
Inline vs. by-reference TYPEs and VARs

• Proposal to disallow inline constructs This
  forces all nested types to be previously declared
  as a named (reusable) type
• Issues
• Assumes all constructs will be reusable
• Creates complexity when adding new attributes to
  an existing data object
• Cant add attributes to a VAR declaration
• Have to add attributes to a TYPE definition, but
  the new objects may not be needed by every
  instance of that type
• Too disruptive to redefine VAR using a different
  TYPE
• Need to specify details of each VAR in the
  conformace section
• Can make MIBs harder to read by spreading out
  details

7
Descriptor naming issues for TYPEs

• Assumption that descriptors are unique within a
  module
• This is no longer true for descriptors in
  reusable types
• Not even desirable, since descriptor names are
  too hard to read with long prefix strings
• Issues
• Can the naming rules for descriptors be changed
• Longer maximum value (remove SHOULD be lt 32)
• Require uniqueness only within scope of the
  parent node
• Allow XML style names mixed case with hyphens

8
Conformance section changes to support SMIv3

• Existing MODULE-COMPLIANCE macro wont work for
  SMIv3 objects
• Descriptors are not unique within the module
• Existing problems with SMIv2 need to be fixed,
  like OBJECT clauses for INDEX objects
• Need to create a construct for each complex VAR
  declaration
• Could fully specify attribute names would be
  better to have a shorthand notation

9
Change control issues for VARs

• Need to be able to add new attributes to existing
  VAR, just as we add new columns to an existing
  table now
• Create new type which superset of old type and
  allow VAR SYNTAX to change
• Use conformance section for version
  identification
• Need to change SYNTAX of a VAR or TYPE attribute
  (inner node) to achieve the same affect as above
• Replace FooType with BarType, which is a superset
  of FooType

10
SMI syntax changes

• Many syntax changes proposed by SMING at last
  interim Need to decide, case by case
• IMPORTS
• LEAF, NODE, or ATTRIBUTE
• OBJECT-GROUP -gt GROUP
• NOTIFICATION-GROUP -gt GROUP
• Base type names
• Remove MODULE this module
• Comments
• More?

11
Migration of SMIv2 CLRs to SMIv3

• Need to determine which SMI rules and
  restrictions need to be kept, modified, or
  deleted
• 128 sub-identifier limit
• 32 character name limit
• Type name, counter name rules
• Need to raise MAX-ACCESS of objects
• Use MIN-ACCESS in conformance section for
  backward compatibility
• More
• Put the CLRs in a separate document (BCP)

12
Support for Configuration

• Need mechanism to distinguish object type
• Configuration (e.g., acl list, bgp peer,
  users/passwords)
• Control (e.g., per-session debug commands, reset
  card)
• State (e.g., ifOperStatus)
• Statistics (e.g., ifInOctets)
• Need mechanism to describe high-level
  configuration methods
• Could be purely for documentation
• Could be more, such as the minimum procedural
  requirements for a particular task
• Mechanism to describe what has to be created in
  initial PDU, what can be edited after creation,
  cascading deletion order, etc.

13
Support for XML naming, XSD translation

• Need to identify XML Namespace for MIB
• Optional XML-NAMESPACE ltURIgt clause in
  MODULE-IDENTITY, or use XML namespace as the
  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

14
Support for COPS-PR

• Need to map MIB objects to COPS-PR
• Forget the idea of supporting SPPI map SMIv3 MIB
  objects directly to COPS-PR (already decided to
  do this)
• Must be more things needed
• Need COPS-PR experts to work on the problem