open issues list

[Juergen Schoenwaelder <schoenw@ibr.cs.tu-bs.de>]

We (Frank and Juergen) compiled a list of open issues to discuss
during the SMIng WG meeting in London. Since we were once again
beating objectives in London, we did not really get to discuss any of
these issues. I am posting this list here now to keep people informed
where we are and to solicit comments.

SMIng Open Issues
-----------------

* 4.1.6 Accessibility

  - Need to distinguish between max/min access of the modelled
    attribute and whether the protocol allows direct access to
    it. (INDEX objects are usually not-accessible even though you can
    read the value.) SMIv2 currently has inconsistent rules which
    leads to the fact that one can't define compliance statements.

* 4.1.10 Namespace Control

  SMI module names must be globally unique.

  Right now, SMIng does not address this issue directly. The idea is
  to delegate this issue to a guidelines document which should
  establish rules that minimize the risk of name clashes and to not
  add new syntax to module names.

* 4.1.19 Discriminated Unions
* 4.2.2 Unions

  Some MIBs (DISMAN) seriously need discriminated unions of the SMI
  base types (CHOICE for ASN.1 folks). 

  - InetAddress, TAddress are actually unions of the various address
    types that all map to the same base type.

  - InetAddress requires to have a separate InetAddressType attribute
    which serves as the discriminator. The registration order is used
    to identify the InetAddressType for a given InetAddress. There
    could be a language construct which explicitly identifies the
    discriminator.

  - <draft-perkins-smi-addition-00.txt> proposes a discriminated union
    where the discriminator is part of the type itself. Access to the
    union and the discriminator is always atomic. Some interesting
    constructions are necessary to make it work in DISMAN MIBs.

  We can either (a) add a union type and a language construct to define
  the discriminator for the union or (b) adopt an approach where the
  discriminator is part of the union type itself.

* 4.1.16 Translation to Other Data Definition Languages

  - Not yet defined - who is going to work on this?

* 4.1.30 Single Inheritance

  - SMIng supports inheritance although it is questionable when this
    is actually useful and when to use inheritance and when augmentation.

  - There is a risk to mis-use inheritance (extending the ifEntry with
    an Ethernet specific attribute and instantiating the whole thing
    in a separate table).

  - Is it possible to restrict inheritance somehow to the "useful"
    cases?

  - Is inheritance needed for information modeling or is it just a
    useful tool for doing protocol mappings?

* 4.1.31 Reusable vs. Final Attribute Groups

  - Classifying attributes as final or reusable allows to constrain
    how others can reuse definitions. Currently there are no language
    constructs for this in SMIng.

* 4.1.33 Creation/Deletion

  - How to specify "create" and "delete" access? This is to some
    degree related to the EOS work on row operations. Also, SPPI
    introduces the concept of INSTALL-ERRORS which must be supported.
    
  - SMIng currently has no constructs to define "constructors" or
    "destructors".

* 4.1.39 Compliance and Conformance

  - Currently only in the protocol mappings. Needs to be extended to
    also cover the protocol independent definitions.

* 4.1.43 Instance Naming

  - SPPI requires that all instances are identified by a small unique
    integer while SMI allows complex instance identifier.

  - The simplest approach would be to allow assume complex instance
    identifier as COPS-PR uses OIDs and thus should be happy with it.

  - The alternative would be to handle differences in the instance
    naming in the protocol mapping, which however adds some complexity
    especially for attributes that are pointers.

* 4.2.1 Methods

  - SMIng does currently not allow to define methods as this requires
    protocol support.

* 4.2.5 Referencing Tagged Rows

  - Example how things work for SPPI:


          +-------------------------------+  (PIB-TAG)
          v                               |

   |...| <A> | ...|                |...| <B> |...|
   ================                ===============
 o |   |  2  |    |                |   |  2  |   |
 o |   |  2  |    |                ---------------
   |   |  3  |    |                       ^
   ----------------                       TagReferenceId 
          ^
          TagId

  - The SNMP world has similar types (SnmpTagList, SnmpTagValue) but
    no way to express the association between the columns.

  - SMIng currently has no language support for defining tag
    relationships.

* 4.2.6 Arrays

  - SMIng does not provide arrays (SEQUENCE OF for ASN.1
    folks). Several issues:

  - Is access to arrays atomic or do arrays map to additional tables
    in the protocol mappings?

  - Are arrays size limited or of arbitrary size?

/js