CURRENT MEETING REPORT Reported by Fred Baker, Cisco Minutes of the Trunk MIB Working Group Goal: The editor will generate updated internet drafts for the middle of January. At that time the working group will issue last call. It is expected that the drafts will be sent to the IESG in February. The following issues previously identified as open on the mailing list were discussed: 3 & 4) ds0 ifType and the dsx1FracTable The dsx1FractTable will be made obsolete. The editor will create a new internet draft with managed objects for ds0s and ds0Bundles. Each of these will be new interface types. The ISDN MIBs may have defined a B-channel type interface and if so, this type will be used for all ds0 and the type string updated if appropriate. The layering of the types will be ds0Bundle on ds0s on ds1. Services such as frameRelay will layer on the ds0Bundle or the ds0 directly if the bundle is not required. ISDN neighbours will point to either a ds0Bundle or a ds0, whichever is appropriate. The new internet draft will also describe a table for bonding which will be used for general ds0 bonding as well as ISDN bonding for PRI and probably BRI. 8) Per-Circuit (ds0) configuration In the new ds0 MIB, there will be a ds0ConfigTable. It will include at least the ability to configure RBS on/off per ds0. Additional items may be put to the mailing list. Other items discussed were: bitmap for which bits are used, idle/siezed codes, other "service" level items. If there is interest in these items, they will be added. 9) Invalid Intervals The use of the TotalTable with regards to missing intervals in the interval table was discussed. The following decisions were made. For each item, an example value is given below. The values are clarified for the case where the IntervalTable is full of good data and then a missing interval occurs causing interval 1 to have bad data: dsx1NumValidIntervals is the maximum interval number for which there is valid data. (The value is 96) noSuchName will be returned for items in intervals for which there is no valid data. (For interval 1 in this case) A new item will be added to the intervaltable which will indicate the validity of data for each that interval. (interval 1 has bad data flag set) The TotalTable will be the total of all valid intervals. (rows 2 through 96) A new item in dsx1ConfigTable will be added to store the number of intervals with lost data for that interface. (The value is 1) 16) DS2 additions The proposal previously submitted to the list by Mr Hato will be adopted. Metrodata has volunteered to submit an E2 proposal by the end of December 17) dsx1LineStatus George Mouradian had asked for extra bits, but has not put the specifics to the mailing list. Fred Baker has taken the action to contact George to verify no bits are required. 19) dsx1LineStatus The issues was that bit 4 and bit 32 seem to have to occur at the same time. The WG resolved that the bits are different. It is possible that they will occur independently. 21) Are linkUp/linkDown traps sufficient or is a trap required for dsxLineStatus changes? Wedge Green has taken the action item to determine if these traps are required. 22) dsx1LineLength An item will be added to the dsx1ConfigTable for line length in meters. The maximum value will be 64000m. 23) stats for ds1/e1 interface running transparent A conformance group for these interfaces will be added The following item previously considered closed was brought up on the mailing list and discussed in the meeting Unavailable Seconds The UAS fixup item for all MIBs was discussed. The fixup will be clarified that when the unavailable state is entered, SES is reduced by 10 and UAS is increased by 10. The linkDown trap is sent out at the start of the unavailable period, but the time will be the time of the first UAS, (i.e. 10 seconds earlier) An implementation note will be added to indicate one could achieve the UAS effect using a delayed approach as described in the mail on the list. It is an alternative to the fixup. The new internet drafts were discussed. The only additional comment not seen on the list was that dsx1LineIndex will not be deprecated as this requires the entire table to be deprecated. Instead, the description of dsx1LineStats will be modified to indicate that the value should be the same as ifIndex. The benefits of doing so is the use of the ifStackTable and new ds0 and ds0Bundle types. dsx1IfIndex continues to be deprecated.