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, doesn't need issue 4, grandfathering hyphens 7.9 DEFVAL, is it okay for Read-Only (yes it is). There was some minor discussion about how DEFVAL 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 use the notify space rather than the trap space 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.