Here are the minutes from the SMI BOF that was held during the Chicago IETF.
chair: Bert Wijnen
notetaker: Shawn A. Routhier
SMI BOF 8/26/98 Chicago IETF
The opening comments described why the community had used a design team (no
current working group - the snmpv3 group was deemed to be inappropriate, creating a
new wg would take too long). The design team accepted submissions and then attempted
to decide what to do with each submission: accept it - and then update the document
accordingly (pending community approval), reject it, or defer it to the community if
they couldn't come to a conclusion. Of 75 issues most all but two were resolved. Sadly
the design group was left with a single open issue that they could not resovle and so the
Internet-drafts were released under Keith's name rather than as output of the design team.
The design team then did its presentation. Their overall strategy was had as a goal to get
the SMI to a status of FULL. To do this they decided to: defer new features, add
clarifications wherever useful, add changes only where needed and require that there be
no on the wire incompatible changes. They also decided that there should be no references
to MIB compilers.
They proceeded to go through the entire issue list (all 75 items). This is available at
http://www.ibr.cs.tu-bs.de/projects/smi-dt/ There was not much discussion about most
of the issues.
The BOF then discussed the two unresolved issues.
Issue 1: Should Agent Capabilities be removed?
The design team identified the following reasons for removing this feature: the community
has insufficient experience with ACs to go to full standard, they cannot fully describe an
agent's behaviour, and they are useless if the macros have bugs as they are published.
The design team identified the following reasons for keeping this feature: mulitple vendors
have used ACs, there is a problem that they are attempting to solve and many mibs already
import the macro from SNMPv2-Conf so removing them or moving them to another
document would be a problem.
Several vendors stated that they were (or at previous jobs) had used the AC macro and
found it to be useful, especially for describing what they have or haven't implemented to
their customers. One has customers that are interested in having machine parseable
versions of this information. One person found the ACs useful but thought that they
could be made more useful by cleaning up the macro. The design team hadn't discussed
any problems with the current macro only if it should be kept or removed.
The consnesus of the BOF was to keep the ACs
Issue 2: Restrictions in choice of auxiliary objects
Which of the following objects (and collections of objects) should be allowed as part of
an index: a scalar, same object more than once, non-auxiliary object from another table,
auxiliary object from another table. There are two extreme positions: have no restrictions
or require each auxiliary object to be in the same table. While using the same object
twice has special semantics so does using an object from another table. Either of these
options as well as all points in between will work and any choice is somewhat arbitrary,
though the design team didn't feel that alling scalars was very useful.
A compromise that would have allowed objects from another table but disallow scalars
and the same object more than once almost but didn't quite generate consensus in the
design team.
One particular sticking point in disallowing using the same object more than once is the
fact that this construct is being used in RMON2 and disallowing it would break the
currently deployed mib.
There was a large amount of discussion about this issue. The discussion included the
following points.
A specific index may be used in order to represent a relationship between the table and
the index (or other table) rather than just to get the datatype of the index and put any
relationship information into the description clause. The RMON2 mib was an example
of using the same object multiple times while the ifStackTable is an example of having
multiple relationships without using the same object multiple times. It was also pointed
out that when RMON2 was being written this issue was discussed, no major problems
were found and this was thought to be an elegant solution.
Adding certain restrictions on the indexing makes mib compiler code generation much
easier - scalars were viewed as the worst with multiple indexes as being in the middle
and single indexes as relatively easy.
Finally there was some discussion about what (if any) restrictions the current document
contains. After the community decides what it wants we can correct the documents if
necessary.
The final consensus was: to disallow scalars, to allow objects from another table and to
allow but strongly discourage (SHOULD NOT) using the same object more than once.
This consensus was reached after much discussion and several attempts by the chair to
a) specify options for consensus, b) point out that without consensus the specifications
would not be able to progress to full standard and c) determining that there was no strong
objections left.
Other issues that were brought up in the open mike part of the session.
There was some discussion about how the community should refer to the language used
to write MIB modules and its relationship to ASN.1. After much discussion and several
attempts to find consensus and to determine that there were no strong objections we
finally reached the consensus thet there was no problem with what we were currently
calling the Structure of Management Information (SMI) and that no clarification was
required. Also that the lanaguage was "an adapted subset of ASN.1 (1988)" and
references to ASN.1 should be updated to use this term. At one point the list of
differences between what the SMI uses and ASN.1 (1988) was given.
Several minor comments were made and agreed with:
7.1.4 BITS construct, as the BITS construct was created after hyphens were outlawed it
doesn't need issue 4 to grandfather old hyphens.
7.9 DEFVAL, is it okay for Read-Only (yes it is). There was some minor discussion about
how EFVAL should be used. Is it for use when creating a new row in a table or can it be
used when a scalar variable is created? (As an example a scalar might be created when
some feature is enabled possible due to a set request). The BOF decided that the DEFVAL
clause should be thought of as a hint to the implementor.
7.11 table example, evalslot is an inproper type and evalindex should have a range
8.6 notification example, should show defining a notification with fooTraps.0.x rather
than using the fooTraps.x style as new notifies should use the former.
8.1 mapping of notification objects clause, clarification that additional objects are allowed
RowStatus textual convention notes 2 & 3, clarification that additional columns must be
valid before transitioning the row status column
The discontinuity indicator generated more discussion. The current specs included text
that required a discontinuity indicators get reset when the sysUptime object wrapped to
zero. This is a change from the current docs and presents difficulties for some systems
which may not be able to reset their discontinuity indicators. This new text is attempting
to fix the oddity that timestmaps become ambiguous some 496 days after the event occurs.
It was also pointed out that MIBs might want to use TCs other than TIMESTAMP, such
as a date and time indication, in order to avoid this ambiguity.
The consensus was to remove the new text and to return to the older version but to add
some new text to clarify the fact that timestamps will become ambiguous 496 days after
the event occurs.
Deadlines for next revision of docuemnts and call for submission for any more comments
and discussion of issues
Date for submission of issues Sept 15
Date for resolution of issues Sept 29
New docuemnts Middle of October
Finally there was a general consensus that, while there is still work to be done, the specs
are in the area of being able to move to full standard.
None received.