OPS Area ENTMIB WG Meeting Minutes 43rd IETF Orlando, FL USA December 7, 1998 WG Chair: Keith McCloghrie Minutes: Andy Bierman Summary ------- The Entity WG met to advance progress on the following work-in-progress: [1] Entity MIB using SMIv2 (Version 2) Agenda ------ Advancement of draft-ietf-entmib-v2-01.txt: - review comments from WG mailing list - any other comments from the WG? - is the MIB ready for WG Last Call? Minutes ------- 1) Review comments from WG mailing list ---------------------------------------- The issues raised in an email (dated 14-nov-98) from Cliff Sojourner were discussed at length. E1: asset information is only needed for FRU components. All the zero-length strings in the entPhysicalTable are just polling overhead. Proposal 1: put the asset information in a separate table. There was no WG consensus for special restrictions on which physical entity types may contain asset information. There was also no agreement on the exact definition of the term, "field-replaceable unit" (FRU). The definition of FRU can change over time for a given product, and not all components are field replaceable at the same level of expertise. There was no WG consensus to move objects to a new 'SPARSE-AUGMENTS' table. Resolution: Proposal 1 rejected. E1-Addendum: Need some generic way to identity FRUs Proposal 2: Add an flag to identify Field Replaceable Units Add a TruthValue r/o column to the entPhysicalTable called 'entPhysicalIsFRU'. The new 'entPhysicalIsFRU' object is needed because not all removable components are considered field replaceable units by the vendor. [Ed., A similar object was proposed by the WG Editor in a very early version of the Entity MIB, but it was removed before RFC 2037 was published. The entPhysicalIsRemovable object could be derived from the parent entity (i.e., if the parent's entPhysicalClass is 'container(5)', then the child entity is removable.)] The WG could not agree on the definition of a FRU, but did agree it was useful to identify them in the entPhysicalTable. There were no arguments against adding this object. Resolution: Proposal 2 accepted E2: entPhysicalModelName semantics are unclear. There is a need to differentiate between "orderable part number" and "manufacturing assembly number", and the object DESCRIPTION clause is unclear on which string to use. Proposal 3: Specify that the entPhysicalModelName string is the customer-visible "orderable part number". The WG did not agree on the need to for a new string object, but did agree this string should represent the orderable part number. Resolution: Proposal 3 accepted. Proposal 4: Add a new NV-stored SnmpAdminString to contain the manufacturing assembly number. This object is only instantiated if entPhysicalIsFRU is true. There was no WG consensus that this object was needed. The NV-storage requirement is too high, and enough information is available to uniquely identify a component (e.g., entPhysicalModelName and entPhysicalHardwareRev strings). Resolution: Proposal 4 rejected. Proposal 5: entPhysicalMfgName clarification Revise the entPhysicalMfgName DESCRIPTION to be clear that the other asset objects (sw/fw/hw revision, serial number, orderable part number, mfg ass'y number) only make sense in the context of that manufacturer. In other words, don't compare or collate these objects when they are from different manufacturers. There were no objections from the WG. Resolution: Proposal 5 accepted E3: entPhysicalTable has no way to represent double-high modules The entPhysicalContainedIn object allows one parent container entity to be identified, but some modules occupy more than one container. Proposal 6: Model this information in the entPhysicalContainsTable. Add text to the entPhysicalContainedIn object requiring the lowest numbered (value of entPhysicalIndex) entPhysicalEntry be used, in the event more than one parent entity exists. The entPhysicalContainsTable DESCRIPTION clause will also be clarified to encourage implementors to model all 'contained-in' relationships, for child entities which have more than one parent container entity. There were no objections from the WG. Resolution: Proposal 6 accepted E4: implementation of user-writable objects is problematic Proposal 7: entPhysicalAlias should be removed. This object correctly lies in the asset/spares/inventory management application. There was no WG consensus to change or remove entPhysicalAlias. This object is needed to support the PTOPO Chassis Identifier attribute, and it is writable to allow an NMS to insure all chassis identifiers are unique within an administrative domain. Resolution: Proposal 7 rejected E5: specify the MIBs that are expected to populate logical entries Proposal 8: list at least some standard MIBs that are expected to use the Entity MIB. There was no WG consensus that this change was needed, or that the Entity MIB was the proper document to specify such behavior (e.g., the Bridge MIB WG should specify in the Bridge MIB, how the Entity MIB relates to multiple instances of the Bridge MIB). Resolution: Proposal 8 rejected E6: make entPhysicalIndex MAX-ACCESS accessible-for-notify Proposal 9: change the INDEX object from not-accessible to accessible-for-notify, so it may be included as a varbind in notifications. There was no WG consensus that this change was needed or even desirable. This change would set a precedent for all INDEX clauses, without good cause. The entPhysicalClass object is accessible, an instance of entPhysicalClass already identifies the entPhysicalIndex value, and it contains the same number of 'bits on the wire' as the proposed change. Resolution: Proposal 9 rejected E7: Need to define FRU Proposal 10: Define "FRU" early in the draft and use the term, then MIB object descriptions won't have circumlocutions like "Physical entities which are permanently 'contained in' another physical entity (e.g., the repeater ports within a repeater module)". The WG could not agree on the need to define a FRU, or the definition of a FRU, but did recognize that this is a different issue than simply identifying a FRU (see Proposal 2). Resolution: Proposal 10 rejected E8 and E9: Errata and Typos - 4.10 says "Most of the MIB objects defined in this MIB have at most a read-only MAX-ACCESS clause, i.e., none are write-able." Yet there are two read-write objects in this draft. The old (obsolete) text will be removed. - typos in section 6.1, remaining from RFC 2037: These bugs will be fixed in the next draft. E10: SnmpAdminString size range semantics unclear Are multi-byte UTF-8 characters counted as 1 'unit' in INDEX sub-ranges, or does each byte count as 1 'unit'. This issue has already been resolved in the SNMPv3 WG. The sub-range limits refer to the number of octets used to encode all the UTF-8 characters, not the number of UTF-8 characters. 2) Any other WG comments on the I-D ----------------------------------- The WG chair then opened the floor to discussion of any issues not already covered in the previous section. F1: Trap Throttling The entPhysicalChange trap must be throttled by the agent to insure that only one trap event is generated in a five second interval. There were several WG members who had issues with various portions of the text which defines this behavior. The WG considered adding a MIB object to specify the mandatory throttling interval (including none) the agent must implement. This idea was eventually rejected in favor of a simpler approach. Proposal 11: Relax the restrictive text in the entConfigChange NOTIFICATION-TYPE description from a "must throttle" to a "should throttle", and make the five second throttling period a suggested default, instead of a mandatory value. The WG did not reach full resolution on this issue before the meeting concluded, but there seemed to be strong WG consensus that this was a good way to resolve the issue. Resolution: Proposal 11 accepted F2: EntConfigChange clarifying text The entConfigChange DESCRIPTION clause text will be changed to indicate the throttling requirement applies to the lower level throttling entity, in a sub-agent environment, rather than the upper level SNMPv3 Notification Originator application, as defined in RFC 2271. If sub-agents are used, the throttling period applies to the entire set of Entity MIB sub-agents. The term 'trap' will be replaced with the term 'notification'. The term 'send' will be replaced with the term 'emit'. 3) Is the MIB ready for WG Last Call? ------------------------------------- The WG Chair outlined a schedule for completion of the current charter. There were no objections from the WG. A 4 week WG Last Call will be issued when the next version of the Entity MIB draft is published. A new draft is expected before January 1999.