1. abierman-sming-nov02 1 SMIv3 Open Issues Andy Bierman

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

3. abierman-sming-nov02 3 NULL choice for UNION TYPEs l Allow UNION definitions to contain a special attribute (node) that would not result in any accessible sub-tree in a VAR declaration l 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 l 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. l Issues »How to document in VAR declaration that NULL is used »How to document requirements in the Conformance section

4. abierman-sming-nov02 4 OID naming for aggregates and sub- aggregates l Want to allow for protocol operations on all or part of nested data structures l Problem: »How to tell where static OID components end and instance identifier components begin l 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 l Issues »Backward compatibility: does this break any real implementations? »Should this be handled in EOS (forget SNMPv3)?

5. abierman-sming-nov02 5 NOTIFICATION definitions in TYPEs l Proposal from NMRG to place notification definitions inside STRUCT, ARRAY or UNION TYPEs, instead of independent NOTIFICATION declaration (as we have now) l 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. abierman-sming-nov02 6 Inline vs. by-reference TYPEs and VARs l Proposal to disallow inline constructs; This forces all nested types to be previously declared as a named (reusable) type l 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. abierman-sming-nov02 7 Descriptor naming issues for TYPEs l 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 l 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. abierman-sming-nov02 8 Conformance section changes to support SMIv3 l 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. abierman-sming-nov02 9 Change control issues for VARs l 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 l 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. abierman-sming-nov02 10 SMI syntax changes l 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. abierman-sming-nov02 11 Migration of SMIv2 CLRs to SMIv3 l 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… l Put the CLRs in a separate document (BCP)

12. abierman-sming-nov02 12 Support for Configuration l 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) l 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 l Mechanism to describe what has to be created in initial PDU, what can be edited after creation, cascading deletion order, etc.

13. abierman-sming-nov02 13 Support for XML naming, XSD translation l Need to identify XML Namespace for MIB »Optional XML-NAMESPACE “ ” clause in MODULE-IDENTITY, or use XML namespace as the MODULE name l Need to identify XML element names »Optional XML-NAME “string” clause in TYPE or VAR constructs –Used to override descriptor as element name l Need to map ARRAY population characteristics to minOccurs, maxOccurs attributes

14. abierman-sming-nov02 14 Support for COPS-PR l 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) l Must be more things needed… »Need COPS-PR experts to work on the problem