CURRENT_MEETING_REPORT_ Reported by Jeff Case/U-Tenn Minutes of the FDDI MIB Working Group June 12, 1990 These minutes were mistakenly not included in the last proceedings. The FDDI MIB Working Group last met on June 12, 1990. The meeting was held between the IETF plenaries, in conjunction with the INTEROP 90 SNMP Demo and FDDI Demo planing meetings at the Grand Kempinski Hotel in the Dallas - Fort Worth area. Goals Since there were several attendees who were new to the work, the goals of the group were reviewed. The primary goal is to define an SNMP compliant MIB for FDDI devices with objects which are based on those defined in the ANSI FDDI specifications. It is hoped that initial implementations can be completed in time for demonstration in early October. The text of the current document draft was distributed and discussed. The majority of the current text comes from the pertinent sections of the ANSI FDDI SMT specification. That text has been recast to align with RFC conventions and to comply with the requirements of the SNMP, MIB, and SMI specifications. Only the minimal required changes to the variables have been made and only the SMT variables which were "required" have been retained. The intent is have as close a relationship between the SNMP and SMT management variables as is technically possible. In general, corresponding objects will have the same semantics although they will necessarily have different syntaxes. Several issues were discussed and some were resolved. OBJECT NAMING: A leaf of the Experimental portion of the Internet tree has been allocated to FDDI: fddi := { experimental 8 } One issue with respect to naming is with respect to the object descriptors to be associated with each object. It is desirable that all identical objects have identical object descriptors. On the other hand, it is desirable that all no two different objects have the same object 1 descriptor. While there are no guarantees that object descriptors are globally unique as object identifiers are, it is desirable for user interfaces that the mappings be both convenient and unambiguous. Two extreme positions are to: o adopt the object descriptors from SMT without change, even when the semantics and syntax of the underlying objects differ o adopt an entirely new set of object descriptors A compromise position was suggested -- to use the SMT object descriptors as much as possible, prefixing each with a standard prefix, and using different object descriptors on those objects which are different from their SMT counterparts. It was brought up that other experimental MIBs (such as 802.3 and 802.5) must also be experiencing this problem and that it should be resolved in a consistent fashion for all MIBs. Another issue with respect to object naming is with regard to the assignment of object identifiers. The SNMP FDDI MIB is a subset of the SMT MIB at this time, with gaps in the tree for the objects which have not been included. It was agreed that whenever reasonably possible that the trailing portions of the object identifiers would be assigned such that if it is ever decided to include some of the optional SMT objects in the SNMP MIB that they can be assigned in a parallel fashion. That is, the numbers will be assigned in a sparse manner. It costs little or nothing to do so. Any gaps in the numbering will reserved for future use. bf PTIONAL SMT VARIABLES Several minutes were spent discussing the inclusion of variables which are labeled as optional in the ANSI document as optional in the SNMP FDDI MIB. Discussion centered around the meaning of the word "optional". In the SMT specification, there are two kinds of optional variables. Some are defined as optional because they pertain to an optional feature, and others which are completely optional, independent of any FDDI feature or function. Optional in the Internet MIB pertains only to optional functions. If a function is implemented, all its MIB variables must also be implemented. There were two points of view in the room -- one that SNMP should only use the mandatory variables, and second, that the entire SMT MIB should 2 be carried over into the SNMP MIB and let users decide which variables are useful. The current draft includes only the variables that are listed as mandatory in the SMT 6.2 MIB. INSTANCE IDENTIFICATION Instance Identifiers for MACs, PORTs, PATHs and ATTACHMENTs need to be defined. MAC instance identifiers are defined correctly in version 0.2 of the document. PORT instance identifiers are similar to MACs. They index into the port table, starting at 1 up to fddiSMTMaster-Ct + fddiSMTNon-Master-Ct. PATHs are organized as two tables, the PATHCLASS table and the NON-LOCAL PATH table. The PATHCLASS table has a maximum of two entries, one for local paths and one for non-local paths. They are indexed 1 and 2. The NON-LOCAL PATH table has a maximum of two entries, one for the primary path and one for the secondary path. They are indexed 1 and 2. ATTACHMENT instance ids are identical to PORT ids. In the case of a dual attach ATTACHMENT, indexing the ATTACHMENT table with the PORT index for either PORT of the dual attachment will return the same entry of the ATTACHMENT table. The entry will NOT be returned twice with a powerful getnext. PROXY ADDRESSING The proper mechanism(s) for addressing a particular SMT device via an SNMP to SMT proxy were discussed. This problem is very similar to previous work with other MAC layer devices such as bridges. Two possible solutions have been used in those applications: o designate the target node through information contained in the community field o designate the target node through information contained in the instance portion of the object name for each object Overloading the Community Field implies that every variable in the PDU is for the same destination FDDI station. Thus the station is viewed as the system from SNMP's perspective. Appending to the instance identifier means that variables within a single PDU can be directed at multiple stations within the LAN. Thus, the LAN is the system and stations are part of that system. The latter mechanism would have an effect on direct SNMP management of FDDI, since all variables would need the appended addressing information. We could use a convention of an appended 0 to mean the 3 local SMT to the SNMP Agent. Appending to each id can result in lots of redundant addressing information when when variables are all intended for the same station. It also makes the powerful getnext request complex for the proxy when it needs to locate the next lexicographically increasing MAC address currently on the LAN. This issue was left unresolved. The chair will consult with other SNMP experts about the issue and make an appropriate decision. fddiSMTSetCounter AND fddiSMTSetTimeStamp The variables fddiSMTSetCounter and fddiSMTSet TimeStamp were recombined to make fddiSMTSetCount. It is defined as OCTET STRING SIZE(12). This allows the full set count to be accessed as a single variable to maintain consistency between the counter and the timestamp. This change will be reflected in the next draft. ACTIONS AND EVENTS Much work remains to be done on the mapping of SMT actions and events into their SNMP counterparts. This will be pursued in future versions of the draft MIB. NEXT MEETING: The next meeting of the FDDI MIB Working Group will be held in conjunction with the IETF plenary to be held at the University of British Columbia, July 31 - August 3, 1990. ACKNOWLEDGEMENT The chair wishes to express gratitude to Nelson Ronkin, Synernetics, for taking extensive notes which formed the basis for these minutes. 4