[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

issues list


-- 
---
David Harrington            Network Management Standards Architect
dbh@enterasys.com           Office of the CTO
+1 603 337 2614 - voice     Enterasys Networks
+1 603 332 1524 - fax       Rochester NH, USA
Title: SMIng Working Group Requirements Page

 

 

SMIng Requirements List:

This list is incomplete, but provides a start for a list of the requirements, showing the format the editors plan to use to specify and justify the requirements of the SMIng language.

The meaning of the status values is as follows:
    • basic means that the feature is already contained in either the SMI or the SPPI.
    • alignment means that this feature is supported in different ways in SMI and SPPI, and they must be aligned
    • must fix means that the requirement/feature is considered a fix for a proven problem in the SMIv2/SPPI
    • should fix means that the feature modifies something that is often misused, and would be nice to have if it can be done easily and does not cause additional complexity or delay
    • new feature means that the issue is considered a new feature which is not required in SMIng, but could be added if WG consensus to do so is reached.
 

Documentation Requirements
 

textual representations
From: IESG
Status: Basic
SMIng definitions must be represented in a textual format.
Motivation: IESG ;-)
Consensus:

#2

 human readability
From: IESG, WG
Status: Basic
The syntax should make it possible for humans to read and write SMIng modules.
It should be possible to read and write SMIng modules with text processing tools.
Motivation: The syntax should make it easy for humans to read and write SMIng modules.
Consensus:

#3

 machine readability
From: SMI, SPPI
Status: basic
The syntax should make it easy to implement parsers. Furthermore, the language should forbid things like forward references unless they are unavoidable.
Motivation:
Consensus:

#4

 naming
From: SMI, SPPI
Status: basic
SMIng should provide mechanisms to uniquely identify attributes, groups of attributes, and events. It is necessary to specify how name collisions are handled.
Motivation:
Consensus:

#5

 namespace control
From: SMI, SPPI
Status: basic
There should be a centrally controlled namespace for standard named items.
A distributed namespace should be supported to allow vendor-specific naming.
Motivation:
Consensus:

#6

 modules
From: SMI, SPPI
Status: basic
SMIng must provide a mechanism for uniquely identifying a module, and specifying the status of a module, the contact person for a module, the revision information for a module, and the purpose of a module.
SMIng must provide mechanisms to group definitions into modules and it must provide rules to reference definitions from other modules.
SMIng must provide mechanisms to detail the minimum requirements implementors must meet to claim conformance to a standard based on the module.
Motivation: Modularity, namespace scoping, and independent advancement of documents.
Consensus:
 

Mappings and Translations

encoding protocol independence
From: Charter
Status: basic
SMIng must define protocol independent data definitions
Motivation: so they can be used with multiple protocols
Consensus:

 encoding protocol mapping
From: Charter
Status: basic
SMIng MUST define mappings of protocol independent data definitions to the SNMP and COPS-PR protocols.
Motivation: SMIng working group charter.
Consensus:

 datadat translate to other data definition languages
From: Charter
Status: basic

SMIng language constructs SHOULD be mappable to MIBs and PIBs and allow mappings to other definitional languages (such as LDAP schemas).

Motivation: backwards compatibility with existing tools
Consensus:

 encoding protocol mapping
From: Charter
Status: basic

permit a more expressive and complete representation of the modeled information

Motivation: SMIng working group charter.
Consensus:
 
 

#8

 instance naming
From: SMI, SPPI
Status: align
Instance naming is subject of the protocol mappings and not part of the protocol neutral model.
INDEX, PIB-INDEX must be accommodated.
Motivation: COPS-PR and SNMP have different instance identification schemes that must be aligned in the protocol specific mappings.
Consensus:


 

#9

 base data types
From: SMI, SPPI
Status: basic
SMIng must support the base data types Integer32, Unsigned32, Integer64, Unsigned64, Enumeration, Bits, OctetString.
Motivation: Most are already common. Unisgned 64 and Integer64 are in SPPI, must fix in SMI.
Consensus:

#10

 extended data types
From: SMI, SPPI
Status: align
SMIng must allow a mechanism to allow base types to be defined as new types which provide additional semantics. Counters, Gauges, Strings, etc.
Motivation: SMI uses application types and textual conventions. SPPI uses derived types.
Consensus:

#11

 instance pointers
From: SPPI
Status: basic
SMIng must allow specifying pointers to instances.
Motivation:
Consensus:

#12

 row pointers
From: SMI, SPPI
Status: align
SMIng must allow specifying pointers to rows.
Motivation: RowPointer, PIB-REFERENCES
Consensus:

#13

 base type set
From: SMI, SPPI
Status: basic
SMIng must support a fixed set of base types of fixed size and precision.
The list of base types should not be extensible.
Motivation: interoperability
Consensus:

#14

 accessibility
From: SMI, SPPI
Status: align
Attribute definitions must indicate whether attributes can be read, written, created, deleted, and whether they are accessible for notifications, or are non-accessible.
Align PIB-ACCESS and MAX-ACCESS, and PIB-MIN-ACCESS and MIN-ACCESS.
Motivation: interoperability
Consensus:

#15

 derived types
From: SMI, SPPI
Status: basic
SMIng must allow a mechanism to allow base types to be defined as new types which provide additional semantics. It may be desirable to also allow the derivation of new types from derived types.
Motivation: Textual Conventions permit this in SMIv2. Derived types permit this in SPPI.
Consensus:

#16

 enumerations
From: SMI, SPPI
Status: basic
SMIng should provide support for enumerations.
Motivation: SMIv2 and SPPI already have enumerated numbers.
Consensus:

#17

 events
From: SMI, SPPI
Status: basic
SMIng must provide mechanisms to define events which identify significant state changes.
Motivation: These represent SMI notifications or SPPI reports.
Consensus:

#18

 creation/deletion
From: SMI, SPPI
Status: basic
SMIng should support a mechanism to define creation/deletion operations for instances.
Specific creation/deletion errors, such as INSTALL-ERRORS, must be supported.
Motivation: Available for row creation in SMI, and available in SPPI.
Consensus:

#19

 range and size constraints
From: SMI, SPPI
Status: basic
SMIng must allow specifying range and size constraints where applicable.
Motivation:
Consensus:
 

#20

 constraints on pointers
From: SPPI
Status: basic
SMIng must allow specifying the types of objects to which a pointer may point.
Motivation:
Consensus:

#21

 uniqueness
From: SPPI
Status: basic
SMIng should allow to specify uniqueness constraints on attributes.
Motivation:
Consensus:

#22

 tables
From: SMI, SPPI
Status: basic
SMIng should provide a mechanism for grouping attribute as tables.
Motivation:
Consensus:

#23

 table relationships
From: SMI, SPPI
Status: basic
SMIng should support INDEX, AUGMENTS, and EXTENDS.
Motivation:
Consensus:

#24

 extension rules
From: SMI
Status: basic
SMIng must provide clear rules how one can extend SMIng modules without causing interoperability problems "over the wire".
Motivation: SMIv2 and SPPI have extension rules.
Consensus:

#25

 categories
From: SPPI
Status: basic
SMIng must provide mechanisms group definitions into subject categories. Concrete instances may only exist in the scope of a given subject category or context.
Motivation: To scope the categories to which a module applies. In SPPI this is used to allow a division of labor between multiple client types.
Consensus:

#26

 agent capabilities
From: SMI
Status: basic
SMIng must provide mechanisms to describe implementation.
Motivation: To permit manager to determine variations from the standard for an implementation.
Consensus:

#27

 remove implied
From: SMI
Status: good to fix
SMIng SNMP mapping should remove the IMPLIED indexing schema.
Motivation: It is impossible to extend tables which contain IMPLIED indexes.
Consensus:

#28

 no redundancy
From: SMI
Status: good to fix
The SMIng language should avoid redundancy.
Motivation: Gets rid of textual redundancy for things like table entries and SEQUENCE definitions.
Consensus:

#29

 discriminated unions
From: SMI
Status: good to fix
SMIng should support a standard format for discriminated unions.
Motivation: Allows to group related attributes together, such as InetAddressType, InetAddress.
Consensus:

#30

 classes
From: SMIng
Status: new
SMIng should provide a mechanism for reuse of non-divisible, extensible attribute groupings.
Motivation: Required to map the same grouping of attributes into SNMP and COPS-PR tables. Allows to do index reordering without having to redefine the grouping of attributes. Allows to group related attributes together (InetAddressType, InetAddress).
Consensus:

#31

 inheritance
From: SMIng
Status: new
SMIng should provide support for mechanisms to extend attribute groupings (inheritance).
Motivation: Allows to extend grouping of attributes, like a generic DiffServ scheduler, with attributes for a specific scheduler, without cut&paste.
Consensus:

#32

 abstract vs concrete classes
From: SMIng
Status: new
SMIng should differentiate between abstract and concrete grouping of attributes.
Motivation:
Consensus:

#33

 relationships
From: SMIng
Status: new
Ability to formally depict existence dependency between attributes or grouping of attributes.
Ability to formally depict value dependency between attributes or grouping of attributes.
Ability to formally depict aggregation between attributes or grouping of attributes.
Ability to formally depict containment between attributes or grouping of attributes.
Ability to formally depict other relationships between attributes or grouping of attributes.
Motivation:
Consensus:

#34

 methods
From: SMIng
Status: new
SMIng should support a mechanism to define method signatures (parameters, return values, exception) that are implemented on agents.
Motivation:
Consensus:

#35

 procedures
From: SMIng
Status: new
SMIng should support a mechanism to formally define procedures that are used by managers when interacting with an agent.
Motivation:
Consensus:

#36

 arrays
From: SMIng
Status: new
SMIng should allow the definition of arrays of attributes.
Motivation:
Consensus:

#37

 composition
From: SMIng
Status: new
SMIng must provide support for the composition of new compound types from more basic (potentially compound) types.
Motivation: Simplifies the reuse attribute combination such as InetAddressType and InetAddress pairs.
Consensus:

#38

 existance constraints
From: SMIng
Status: new
SMIng must provide a mechanism to formally express existance constraints.
Motivation: Existance constraints are already embedded in SMIv2 INDEX clauses and DESCRIPTION clauses.
Consensus:

#39

 ordering constraints
From: SMIng
Status: new
SMIng must provide a mechanism to formally express ordering constraints.
Motivation:
Consensus:

#40

 attribute transaction constraints
From: SMIng
Status: new
SMIng must provide a mechanism to formally express that certain sets of attributes can only be modified in combination.
Motivation: COPS-PR always does operations on table rows in a single transaction. There are SMIv2 attribute combinations which need to be modified together (such as InetAddressType, InetAddress).
Consensus:

#41

 attribute value constraints
From: SMIng
Status: new feature
SMIng must provide mechanisms to formally specify constraints between values of multiple attributes.
Motivation:
Consensus:

#42

 associations
From: SMIng
Status: new feature
SMIng should provide mechanisms to explicitly specify associations.
Motivation:
Consensus:

#43

 association cardinalities
From: SMIng
Status: new feature
Cardinalities between associations should be formally defined.
Motivation:
Consensus:

#44

 method constraints
From: SMIng
Status: new feature
Method definitions must provide constraints on parameters.
Motivation:
Consensus:

#45

 table relationships
From: SMIng
Status: new
SMIng should support  REORDER and EXPANDS clauses.
Motivation:
Consensus:

#46

 machine readability
From: SMIng
Status: new
The syntax should make it easy to implement parsers. A complete ABNF specification of the grammar is desirable.
Motivation:
Consensus:

#47

 float data types
From: SMIng
Status: new
SMIng must support the base data types Float32, Float64, Float128.
Motivation:
Consensus: