SMIv3 Open Issues

1. SMIv3 Open Issues Andy Bierman <abierman@cisco.com>

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/entriesGranted 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 don’t 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 • Can’t 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 <= 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 won’t 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 o;ld 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 -> GROUP • NOTIFICATION-GROUP -> 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 “<URI>” 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