Updated SMIng Meeting Minutes...

["Durham, David" <david.durham@intel.com>]

Any final comments before I submit these on Friday?
-Dave

SMIng Meeting Minutes from the 50th IETF in Minneapolis MN.
Chairperson: David Durham

Thanks to the minute takers: Ravi Sahita, Amol Kulkarni, & Jamie Jason.

First Session: Tuesday March 20th 15:45-15:45 

1. Chair Describes the WG status. 

Currently, all chartered documents have been submitted as specified in the
WG's milestones. These documents are: Requirements, SMIng, SMIng Core
Modules, SMIng Internet Modules, SMIng to SNMP Mapping and the SMIng to
COPS-PR Mapping. An interim meeting simply did not materialize as expected
after the 49th IETF. 


2. Andrea presents a list of high-level assumptions about the requirements
document.

Andrea did not present the requirements themselves, but specified the
assumptions that were made in creating the requirements document. The
assumed scope is that this work is to focus on merging the SMI/SPPI along
with repairs and fixes that are over due for the SMI. Any improvements that
are to become requirements need to be justified e.g. in terms of improving
ease of use/operational problems, reduced size of code, or clarity. Also,
the requirements are being identified as basic (part of the SMI/SPPI),
necessary to fix, good to fix, or new.

Another assumption is that the mapping to a protocol can be separate from
the definition of the data. This implies that it is possible to distinguish
what attributes may be specific to a particular protocol, for the attributes
simply describing the data itself. The work TBD is to determine how complex
the WG wants the mappings to be as there is a tradeoff in terms of achieving
protocol independence, as some defined data may only be relevant to a
particular protocol. 

The requirements are assuming that the SMIng can map to the SNMP/COPS
protocols directly, and is not simply an intermediary translating to SMIv2
or SPPI. This would reduce the of number of data definition languages people
have to worry about moving forward. The discussion that followed revealed
that while mapping to the protocols is a good thing in terms of improving
the status quo, there nonetheless must be a requirement that SMIng is indeed
translatable back into the SMIv2. This is simply a pragmatic requirement as
the SMIv2 isn't going to disappear overnight. 

There is the assumption that SMIng can extend, fix or even remove certain
thigs that are already in the SMIv2/SPPI. These are exceptions that need to
be listed separately, however. E.g. It may be beneficial to stop use of
IMPLIED as defined in the SMIv2 because it is confusing. Likewise, the lack
of 64 bit integers in the SMIv2 should not prevent the SMIng from supporting
them.

Instance identification may need to be generalized somewhat in SMIng simply
because COPS and SNMP identify instances of data differently. Moreover, SNMP
itself may change INDEX ordering across different tables. What SMIng can do
is describe what attributes are suitable use within an INDEX, and leave it
up to the protocol mapping to actually determine how a particular table is
to be indexed. 

The requirements assume some amount of constraint expressions are necessary.
SMIv2 and SPPI already express constraints on attributes. SMIng could go
farther and add existence constraints, ordering constraints, etc. It is
probably too much to ask for a general-purpose constraint language, however.

Sophisticated relation mechanisms such as associations are currently
mentioned in the document. There was some discussion around why associations
need to be part of the language at all, as they can simply be modeled with
two pointers within a table. 

Methods were discussed as well. They were motivated in terms of describing
actions/behaviors, parameters, and return codes. Unfortunately, there still
hasn't been a clear proposal as to how methods can be mapped to SNMP as it
exists today.

The next steps were then described. The WG should continue to look at the
existing requirements and add any that haven't been specified, and motivate
those that are not clearly defined. Any additional undesirable features that
are currently in the SMIv2/SPPI should also be exposed as required to be
removed. The Requirements team will review additional input from the mailing
list and then work to finalize a set of well-understood, and properly
motivated requirements for the document to go to last called in may. 

An issue was raised around versioning and how to make versioning
intelligent. This issue then became whether or not there are bounds on the
most basic types, as ANS has no bounds but MIB compliers don't allow
unbounded values. We should learn from past mistakes. Basically, we should
not be bound by current implementation issues at the highest level of
abstraction, the mappings should worry about it. Counters are an example, 32
bit counters were good when the state of the art was T1, but today, 32 bit
counters are a serious limitation. Versioning is a symptom of this issue,
and how to expand constraints as technology advances. 

Second Session: Thursday March 22nd 13:00-15:00.


1. Frank Strauss starts by explaining the current SMIng draft's status with
respect to the requirements. Classes of attributes are currently supported,
class extensions via inheritance, etc. Methods, associations and various
advanced constraints are among those features that are not supported.
Motivation is also lacking for support of such features.

2. David Harrington Next presents an itemized list of requirements. The
requirements list was taken from the requirements document and put in a form
more convenient for the WG to address, requirement by requirement. The
feature list lists the proposed requirements by name, describes the status,
provides a description, and specifies the motivation where there is one.  

The following is the requirements list as presented by David Harrington
focusing on those proposed requirements that elicited discussion including
(status):

Note: the proposed requirements are not listed in any particular order.
* Textual representation (basic)
* Human readability (basic)
* Machine readability (basic)
* Naming (basic)
* Namespace control (basic)
* Modules (basic)
* Protocol Mapping (basic)
	The protocol mapping requirement specifies that SMIng must be able
to map directly to the SNMP/COPS protocols. It doesn't *have* to map back to
the existing SMIv2/SPPI inorder to do this. This doesn't mean that it can't,
however, rather there should be a requirement that the SMIng can translate
back to the SMIv2/SPPI as well, so that existing tools will not be made
instantly obsolete. What the charter is describing is a long term goal of
reducing the number of data definition languages that will need to be
supported in the future. Ideally, people will migrate to the SMIng and
translations can be performed for the existing SMIv2 just as they are for
SMIv2->SMIv1. There will be limits to the mappings, however, the SMIng
should be able to evolve, and support features that are not part of the SMI
today. 
* Instance naming (align)
	It was pointed out that Instance naming has different requirements
at the protocol independent level vs the protocol mapping. There is some
benefit to using the same data with different indexing, eg. Reordering
tables.
* Base data types (basic)
These are Integer32, Unsigned32, Integer64, Unsigned64, Enumeration, Bits,
OctetString.
* Extended data types (align)
Allow mechanism to allow base types to be defined as newe types which
provide additional semantics ; Counters, Gauges, Strings, etc. SMI uses
application types and textual conventions.  SPPI uses derived types. This is
essentially the ability to derive TCs from TCs. 
* Instance pointers (basic)
Must allow specifying pointers from one instance to another.
* Row pointers (align)
* Base type set (basic)
Support fixed set of base types of fixed size and precision.  List should be
extensible.
* Accessibility (align)
Attribute definitions must indicate read/write/created/deleted and whether
are accessible for notifications or are non-accessible Align PIC-ACCESS and
MAX-ACCESS, and PIB-MIN-ACCESS and MIN-ACCESS
* Derived types (basic)
* Enumerations (basic)
* Events (basic)
Provide mechanisms to provide events which identify significant state
changes. - in SMI notification types are telling you message types.  Could
be events or something else - should split in two?  One is a state change
and one is indicating data to pass on - don't want this group to do what
disman group is doing with alarm notifications.
* Creation/deletion (basic)
Define creation/deletion operators
* Range and size constraints (basic)
* Constraints on pointers (basic)
Allow specifying the types of objects to which a pointer may point to (type
checking). Also may effectively provide existence constraints between rows.
* Uniqueness (basic)
Allow specifying uniqueness constraints on attributes. Useful for
determining which attributes are appropriate for indexing.
* Tables (basic)
* Table relationships (basic)
Support INDEX, AUGMENTS, EXTENDS.
* Extension rules (basic)
Provide clear rules how one can extend SMIng modules without causing
interoperability problems "over the wire".
* Categories (basic)
Group definitions into subject categories.  Concrete instances may only
exist in the scope of the given subject category or context
* Agent capabilities (basic)
Provide mechanisms to describe implementation
* Remove implied (good to fix)
SMIng SNMP mapping should remove the IMPLIED indexing schema. IMPLIED is
confusing and most people don't understand it.  It may be good to get rid of
even if the motivation is wrong.  If the problem (the Fred/Barney problem)
that IMPLIED is not deemed worth solving than IMPLIED should be removed. The
argument of simplicity is a stronger motivation for removing IMPLIED.
* No redundancy (good to fix)
Avoid redundancy. Get rid of textual redundancy for things like table
entries and SEQUENCE definitions.
* Discriminated unions (good to fix)
Support standard format for discriminated unions to group related attributes
together (for example InetAddressType, InetAddress)
* Classes of attributes (new)
Provide mechanism for reuse of non-divisible, extensible attribute
groupings. Required to map same grouping of attributes into SNMP and COPS-PR
tables.   Allows to group related attributes together.  Ie. InetAddressType
and InetAddress typically go together. It was suggested to rename this to
classes or attributes or structs as they do not involve methods (as the name
class may imply)
* Inhertiance (new)
Provide mechanism to extend aforementioned attribute groupings (classes of
attributes).
* Abstract vs. concrete classes (new)
Should provide way to differentiate? Motivation is not clear.
* Relationships (new)
Ability to depict existence dependency between attributes/grouping of
attributes. Ability to depict value dependency between attributes/grouping
of attributes. Ability to depict aggregation between attributes/grouping of
attributes. Ability to depict containment between attributes/grouping of
attributes. Ability to depict other relationships between
attributes/grouping of attributes. 
* Methods (new)
Support mechanism to define method signatures (parameters, return values,
exceptions) that are implemented on agents. It was pointed out that there is
no clear way how to map methods to SNMP. The motivation of this requirement
is also unclear with respect to SNMP's memory mapped model. 
* Procedures (new)
Support mechanism to formally define procedures that are used by managers
when interacting with an agent. There was confusion as to what is difference
between this and method. - what are you defining about how a manager and
agent interact [Juergen Schoenwaelder] - alleviate confusion between where
the method is implemented (methods are on agent, whereas procedure runs on
manager side) - alter following attributes in following order in order to
reach this goal? [Juergen Schoenwaelder] - correct [??] - now specifying how
to write manager.
* Arrays (new)
Allow definition of arrays of attributes. It was not clear how arrays are
mapped to fixed tables. Indexing and atomic access is also unresolved.
* Composition (new)
Provide support for composition of new compound types from more basic
(potentially compound) types. E.g. Reuse a compound class of Inetaddress and
InetAddressType within a filter class that filters on a source and
destination address. This is different from a derived type in that previous
constructs are reused, just like structs in structs. A (x,y) point struct
can be reused in a square struct containing four points for four corners
(P1,P2,P3,P4). 
* Existence constraints (new)
Provide mechanism to formally express existence constraints. Already
embedded in SMIv2 INDEX clauses and DESCRIPTION clauses. Constraints on
pointers may also be used to imply existence constraints (pointing at
another instance implies that it should exist).
* Ordering constraints (new)
Provide mechanism to formally express ordering constraints - ordering
constraints related to sets, you have to set this first, then do that, then
do that, etc.  You may have to do things in a specific order so that the
agent works right.  Don't want to just hide in description clause. Some
discussion on how this is different than procedures.
* Attribute transaction constraints (new)
Provide a mechanism to formally express that certain sets of attributes can
only be modified in combination. COPS-PR always does operations on table
rows in a single transaction.  There are SMIv2 attribute combinations that
need to be modified together (such as InetAddressType, InetAddress). These
constraints may be implied by classes of attributes implicitly assuming that
attributes grouped together logically are manipulated together. - assuming
you are using a tool to do this, you could make sure that InetType and
InetAddress end up in the same request, for example.  Could be in the
specification and tool could make sure that ASN.1 could be written correctly
to ensure this. - can formally specify and tools can make check to do the
right thing.
* Attribute value constraints (new)
Provide mechanisms to formally specify constraints between values of
multiple attributes.
* Associations (new)
Provide mechanisms to explicitly specify associations? Discussion around why
this is needed to be explicitly specified in the language, as one can model
associations as a table with two pointers. There was also the question about
how is associations are any different than the relations requirement. [David
Harrington] - relationships can be embedded directly in class, while
association tend to be separate classes. Fundamental language requirement
appears to be that pointers can be specified. Relations/pointers and
associations all seem to achieve the same thing with associations being a
less efficient representation of a relationship. It is unclear why any
language would need to have a special primitive for associations. UML has
associations as association classes, not as language primitives.
* Association cardinalities (new)
Cardinalities between associations should be formally defined (assuming
associations).
* Method (parameters) constraints (new)
Provide constraints on method parameters (assuming methods).
* Table relationships (new)
Support REORDER (swap index order) and EXPANDS (nest tables) clause. EXPANDS
is different than AUGMENTS because [Juergen Schoenwaelder] - AUGMENTS means
every row in B has a row in A (1-to-1), EXTENDS is sparse augmentation
(1-to-[0,1]), EXPANDS means a row in B may have many rows in A (1-to-N).
Could be used to emulate arrays by using creative indexing.
* Machine readability (new)
Complete ABNF specification of grammar is desirable. SMIv2 has none. This
should be renamed to ABNF specification requirement.
* Float data types (new)
Support Float32, Float64, Float128 - IEEE defines float 128, is there really
a requirement for 128? [David Harrington] - requirements is really a wish
list, looking to see which proposed requirements are controversial and why. 

This list of requirements came from the current requirements document, only
broken down item by item. After the proposed requirements were presented, it
was asked how requirements can be added. The mailing list is the right place
to put forth any additional requirements, clarify existing requirements, or
provide motivation. Since the charter assumes the same functionality that is
already in the SMIv2 and SPPI, it is not necessary to list such existing
features item by item. Some of the more interesting features of the SMI and
SPPI have been shown in this list simply to emphasize their existence. If
features already in the SMIv2 or SPPI are deemed unnecessary, complex or
otherwise broken, there needs to be a specific requirement to remove that
feature (since all existing features will not be specified individually.
Fundamentally, the proposed requirements will not become real requirements
unless their existence can be motivated by the WG. This process will also be
carried out on the mailing list. New proposed requirements that lack proper
motivation will not be part of the final Requirements document. For new
requirements, it would also be useful to specify how they may be
implemented, since requirements that cannot be implemented given the current
protocols are not valid for this WG. Not asking for the final proposal,
though, just some evidence that the requirement is pragmatic.

The final step will be to prune the requirements down into a list of
well-understood and well motivated language features that can be implemented
with the existing protocols. The current list shows many nice to have
features so we can be intelligent about what to keep and what not to keep.
It is not expected that the final requirements document will have them all.

It was asked that a translation mechanism from the SMIng to SMIv2 be
provided which segued into David Perkins presentation.

3. Translation to SMIv2 Format presentation by David Perkins:

SMIng mapping to SNMP1/2c/3 - rules for defining how elements of SMIng
modules are mapped to "varBinds" in the SNMPv1/2c/3 protocols.

SMIng translates to SMIv2 - rules to defining how elements of SMIng are
translated to SMIv2 MIB modules.

Translation Usage Model: Core SMIv2 modules will be converted to SMIng
modules (SNMPv2-SMI, etc). For each existing SMIv2 MIB module: 1. will be
converted to one ore more SMIng modules 2. reverse mapping will be applied
to create an SMIv2 MIB module 3. module will be placed in SMIv2 repository.
Likewise, each new SMIng module will be translated and added to the SMIv2
repository.

Forward translation, we MUST be able to convert all correct SMIv2 MIB
modules to one or more SMIng modules. This SHOULD be minimal amount of
effort, and initial pass SHOULD be assisted by automation. This will require
intelligent decisions by the person(s) doing the conversion and there w ill
be many choices
Observation: it appears SMIng will result in many more direct dependencies
than found in SMIv2. The	tradeoff is fewer items defined and
"elimination" of "cut-paste-and-adapt". This is a property of an OO design.
Requires much more initial analysis to get the base class definitions
"right", however.

Backwards translation, we MUST be able to convert SMIng modules, which were
originally in SMIv2 format back to SMIv2 MIB modules without loss of
information. Don't forget about compliances and capabilities.

Standards Process Considerations, we don't want to recycle when update is to
only to convert the format. This wasn't given enough attention with SMIv2.

Data type issues, we MUST solve issue of support for new data types in SMIng
that don't exist in SMIv2. I.e. Ineger64, Unsigned64, Float32/64/128, Other
(Union).

Some were of the opinion that a reverse translation from SMIng to SMIv2
should not be a requirement. It was also noted that not everything will be
translatable. Such things will either require workarounds, or no translation
is provided for such things at all. It was noted that SMIv2->SMIv1
translators are not perfect. The conclusion was that the WG members
interested in a requirement for providing a translation mechanism from SMIng
to SMIv2 put up some text on the mailing list that precisely conveys their
desires.