The Minutes below should be considered a rough draft - 3/26/92 Megan The minutes of the Trunk-MIB Working Group IETF Meeting 3/16/92 San Diego, CA Mailing List o General Discussion: trunk-mib@acc.com o To subscriber: trunk-mib-request@acc.com o Archive: saffron.acc.com Chairs Fred Baker: fbaker@acc.com Tracy A. Cox: tacox@sabre.bellcore.com Description and Charter This working group will consider revisions to the DS1 and DS3 MIBs (currently published as Proposed Stds in RFC 1232 and RFC 1233) in preparation for their consideration as Draft Standards. Consistent with the IETF standards process, the working group is chartered to consider only those changes to the DS1 and DS3 MIBs that are based on implementation experience or on the need to align with relevant ANSI T1M1 standards. In this context, the working group will thoroughly document the implementation or alignment rationale for each considered change. All changes made by the working group will be consistent with the existing SNMP framework and standards --- in particular, those provisions of RFC 1155 regarding addition and deprecation of objects in standard SNMP MIBs. This working group will be a short-lived activity, involving a single meeting, and will conclude its business no later than June 1992. Goals and Milestones o Jan 1992: Distribute draft of proposed revisions to DS1 and DS3 MIBs together with documentation of supporting implementation experience o Mar 1992: A one-time only working group meeting as part of IETF meeting to review and discuss documents and formulate recommendation to IESG o Apr 1992: Deposit final document text as Internet Drafts for final review by WG membership and consideration by IESG Agenda o Get feedback on implementation experience o Review RFC1232 and RFC1233 comments - Review ds1LineIndex and ds1Index email discussions - Review the need for farEndTables - Review the need for added configuration information - Review new objects: ds1Loopback and ds1AlarmState - Removal of CSSs from RFC1233 - Additional otherCVs count in RFC1233 Feedback o Add Far End Information -- as optional tables o Add more alarm information -- ds1AlarmState o Consistency with standards -- updated Terminology section o Can't "CSU" MIB be used to manage other DS1 interfaces? Implementation experience was received on RFC1232 and RFC1233. Vendors wanted the definitions of the counters to be consistent with T1M1 standards. The working group agreed that the definitions should be updated. However, if the documents should conflict, vendors should follow the definitions in the Internet DS1 and DS3 MIBs. Text was added to the internet-drafts to reflect this consensus. Next, the need for far end information was discussed. Vendors requested that the far end information received from the DS1 and DS3 signal be collected in the MIBs. The working group agreed that this information should be added as an optional group. The working group agreed to structure the MIBs into two groups, the: -- DS* Near End Group which is mandatory and -- DS* Far End Group which is optional. The Near End Group contains Configuration, Interval, Current, and Total tables. The Far End Group contains Configuration, Interval, Current, and Total tables. The working group also reviewed the request from a vendor that more configuration information be added to the Configuration Table. The working group agreed that this information is important; however, it should not be contained on the SNMP agent on the device. The Network Management Station should have this information in its database. Therefore, the configuration information will not be added to the MIBs. This is only true for the Near End Group. Since, the configuration information from the Far End is received from the incoming signal, the Far End Configuration Table does contain this information. Therefore, the Far End Group does contain configuration information. Only the circuitID object is contained in the Near End Configuration Table. Based on vendor requests and consistency with T1M1 standard, some objects were deprecated, and new objects were added. This is true for both DS1 and DS3 MIBs. -- ds*Loopback has been deprecated. -- A new object has been added called ds*NewLoopback, which better describes the loopback capabilities of a DS* interface on a device. -- ds*YellowAlarm has been deprecated. -- ds*RedAlarm has been deprecated. -- A new object has been added called ds*LineStatus. This object better describes the status (e.g., alarm state and loopback state) of a DS* interface. -- Only the ds3IntervalCSSs, ds3CurrentCSSs, and ds3TotalCSSs have been deprecated, because these counts are not collected on DS3 interfaces. They are retained in the DS1 MIB. -- Additional objects and status are necessary to fully support E1; NewBridge will supply details, to be edited into the DS1 MIB. The internet draft will reflect these changes. Also, vendors requested that the DS1 and DS3 MIBs be used to manage other devices other than CSUs. Therefore, the MIBs are updated to reflect this request. The MIB manages DS1/DS3 interfaces. The following objects have been changed to reflect this request: -- ds*CSUIndex has been renamed ds*LineIndex. This object is the identifier of a DS* Interface on a device. If there is at least one ifEntry directly associated with the DS* interface (eg, if the DS* interface is used to communicate with the Network Layer), it should have the same value as ifIndex. Otherwise, its value should exceed ifNumber. -- ds*Index has been renamed ds*IfIndex. This value for this object is equal to the value of ifIndex from the Interfaces table of MIB II (RFC 1213). The utility of this object is under discussion. The fractional table was deprecated from the DS1 MIB, because no one implemented it or wanted it. Since the changes to RFC1232 and RFC1233 were on the borderline of being "too much", the group agreed to cycle at the Proposed Standard status. This implies that the Working Group will have a longer life cycle than intended, probably on the order of a year. New internet drafts reflecting these changes will be sent to the trunk-mib mailing list and posted in the internet-drafts directories; when consensus is achieved on the mailing list, they will be forwarded to the IESG.