Editor's note: These minutes have not been edited. Monday, June 24 1300-1500 Interfaces MIB draft-ietf-ifmib-mib-03.txt dated: 22 February 1996 Issues discussed and resolutions taken: (1) IANA:assignments/smi-numbers: g703-2mb marked obsolete. A message has been sent to IANA to properly edit the smi-assignments documents available on their server. The working group chair will get back to the WG as that is cleared up. Suggestion that a URL for the SNMP MIB Module, IANAifType-MIB stored at IANA be included in the RFC. Problem that URL is not permanent. Conclusion: a discription of how to reach IANA will be included in the RFC as a pointer. (2) downBecauseOfDependancy. General support for this functionality on list and in the group. Question of why is this not in an additional variable, since it is a sort of "hint" or "probable cause". Pursuing the probable cause notion was deemed too complex. Why in the ifOperStatus? The answer is that the definition of down is ifAdminStatus=up combined with ifOperStatus=down. Making a change anywhere else leaves interface explicitly in down state. Conclusion: Adopt the state. The name of the state is up to the documents editor. This state sends traps exactly as if it is the down state, so if ifLinkUpDownTrapEnable is on, the if will generate traps on transition to down or downBecause. This state is required. (3) ifIndex consistancy requirements. columnar failures and renumbering. what to do? This was a highly contentious issue. The working group felt that renumbering interfaces was an expensive operation and wanted to avoid it whenever possible. A common renumbering case was called out for attention: version (1) an interface card holds the counter values onboard; it breaks and is hot- swapped with another. version (2) a software interface module holds counter values in itself; it dies and a new instance is spawned. RFC 1573 states that when counter values are discontinuous the ifIndex must be changed. One observation is that modern interfaces are more complex than previous interfaces. Hot-swapping and layered software interfaces are especially difficult, since they can come and go. The notion of an interface sysUpTime was discussed extensively. (The name ifSysUpTime was used, though later, timeticks syntax was rejected in favor of a timestamp syntax object. I have named it ifCounterDisconTime here.) The issue of current practice was considered. It was asserted that many agents do not renumber interfaces when they are required, but simply restart counters. The point was made that ifCounterDisconTime is a "legalization" of this practice. When can an interface ifCounterDisconTime be reset? Conflict between managers if interface counters are reset at whim. Feeling in the group that reseting counters should only be allowed in circumstances beyond the agents control. Does this include reset by a human? Opposing positions: This use of ifCounterDisconTime does not eliminate interface renumbering. It only avoids it in some situations. The policy question was raised - what does the ifIndex value really mean. Is it the slot? is it the card? is it the WAN link to Chicago? Only ifAlias is constant and is operator supplied. So what is the point of keeping ifIndex values? What is the core of an interface? What can change about an interface before the ifIndex changes? The list was not fully determined. ifType? no. ifConnectorPresent? no. ifAlias, ifName, ifSpeed, ifPhyAddress? yes? The issue of obsoleting all interface mib counters was raised. Counters timestamped with ifCounterDisconTime seem a redefinition. Possibility of different base, with a timestamp syntax, for a counter is explicitly allowed in RFC 1902, but existing mibs do not specify - rather they assume sysUpTime. The WG chair observed that a change of this sort could keep the interfaces mib from progressing to draft and would force it to cycle at proposed. The NM Area director spoke about the delays which would be experienced by other mibs dependent on the interfaces mib and which are going to draft themselves. (Note: A draft mib cannot depend on a mib a proposed.) She also stressed the need to keep from obsoleting existing MIBs. An explicit poll was taken of members of the working group whether they support this change. Agent implementers speaking in favor of ifCounterDisconTime: RAD, Nexion, cisco, Shiva, Newbridge, DEC, IBM. Snmp engine vendors speaking in favor of ifCounterDisconTime: Peer. Network Management Station implementors spoke: IBM - the amount of data kept would be the same per counter, its just that the counter is assumed to be from sysUpTime. Cabletron - be sure there is a good migration strategy. Conclusion of the WG Chair up to this point: Because we explicitly discussed this and decided not to do it one year ago when we had the mib open for major surgery; Because this working group claimed it was just going to wrap up details in this meeting and WG members may not have attended, Because there was an RMON meeting running at the same time as interfaces mib and WG members may have been split; Because ifCounterDisconTime does not represent the consensus of the WG members present, notably absent from consensus are the WG chair and the document editor, The WG Chair decided that the WG as a whole must be better drawn into the discussion for this sort of change to move forward. (4) ifPhysAddress with MAX-ACCESS r/w and MIN-ACCESS r/o? Conclusion: No change. It was not felt that enough interfaces have writable phyAddresses to warrent inclusion as a standard. (5) ifSpeed and asymmetric interfaces (not one way). eg. ADSL, cable- modems. The ADSL interest group defined ifSpeed to be the outgoing speed of an interface, and defined two objects for incoming and outgoing speed in their proprietary interface. Conclusion: Do not change mib. Have asymmetric interfaces follow technique of ADSL. Wednesday, June 26 1930-2200 ============================ (3) ifIndex consistancy requirements. columnar failures and renumbering. what to do? Reconsidered. This was still a highly contentious issue. The WG chair asserted that the WG must make a choice between imperfect options: Option a) simply relax the renumbering requirement, without doing anything else. (a) was never even considered. It didn't fix anything. Option b) define ifCounterDisconTime, and put it in a separate document at proposed. Move the interfaces mib to draft. (b) was rejected as bureaucratic subterfuge, and the timestamp effectively changes the semantics of the existing counters. Option c) reuse ifLastChange for the purpose of this timestamp. (c) was rejected as overloading an existing object semantics. Option d) put a timestamp in the Enity Mib for logical and physical entities. (d) was considered. The feeling was that the mapping to the entity mib objects was too complex, and that it unfortunately mandated the implementation of the entity mib in order to use the interfaces mib. Option e) No! we can't make this change! (e) was proposed by the WG chair, but didn't catch on. The feeling emerged that if we were to design the interfaces counters all over again, we would use a technique such as this. This became an overwhelming arguement in favor of doing it now. Otherwise, the feeling went, we would make this same change a year from now, with far greater cost. Option f) define ifCounterDisconTime, and cycle the interfaces mib at proposed. Define all new counter OIDs. (f) was discussed at length, but modified. Are we "matching the specification to the implementation" by recasting the scope of renumbering? This was seen as pragmatic standards making. In contrast "codification of practice" had less support. A question of implementation was raised: several vendors said yes, they still have counters implemented that reset yet keep the same ifIndex value: cisco, Ascom, Newbridge. So the question became "is this really the best technical solution"? And by extension "is this the solution we want cloned in other mibs"? There were no dissenting opinions. Next question: "is this really a counter problem rather than and interfaces mib problem"? The answer was yes, this is a general counter problem. The Data Link Switching (DLSw) MIB was offered as an example where the circuits are, in effect, timestamped. The Hub MIB was another example of timestamping. It turns out that a timestamp per counter with a optional clause in the OBJECT-TYPE, was suggested during the SNMPV2 discussion. Called "Reference Time" it was abandoned in RFC 1902, because of the difficulty is specifying in ASN.1 which field of the indexing variables identifies the timestamp. Without such special clause, the only other place to identify the timestamp is in the discription clause. A poll of WG members present was taken. Who builds management applications? What do you think about counters that rely on a per interface timestamp? Expressing comfort with such a thing were: RAD, Ascom Timeplex. Expressing some concern was: Ascom Nexion. The WG Chair decided that it was necessary to poll the ifmib list for other management application builders who may be affected, in order to get their input. The issue of new OIDs for the interfaces counters was discussed. It was flatly held to be not acceptible. When asked if new OIDs are required by MIB rules, if the semantics of counters are bent to this degree, the working group effectively said "No we don't think so. The `evolution' of the interface values in RFC1573 did not require new OIDs, so this should not either." Issue of draft status was discussed. There is no interoperability experience with these sort of counters. Several vendors did not think this would be difficult to arrange however, since many counters reset now. The NM Area Director enjoined the WG to please be careful of the work of others. Several working groups will modify their mibs to follow this example. It should be noted that the document editor voiced several objections to such a change, and has raised some questions about the nature of an interface and a counter. Thus there may be need for clarifications on the mailing list; it may not be a simple matter of "understanding the edits." Finally it was felt that a note to the whole snmp list was in order. A warning should be sent to management applications builders about interface counters depending on a timestamp. (6) mechnism to assign ifIndex values. Clarify. Not discussed due to lack of time. (7) trap generation limits? what is wrong with 1573? Not discussed due to lack of time. (8) ifType of other, and ifSpecific? ifVendorType? Not discussed due to lack of time. Topic II: Test Mib Maria Greene presented the testmib, and reviewed its status. Possible New Topic: Dedicated Token Ring Interfaces MIB (IEEE 802.5) The WG chair was asked by Jim Carlo representing IEEE 802.5, and Dan Romascanu if work on the DTR MIB could be taken up in the IETF. Michelle Bitton of RAD made a presentation on the DTR MIB. The working group appreciated the effort on the part of the IEEE to work together, and thanked Michelle for a good job in presenting the MIB. Wider discussion on the best path forward ensued. The IEEE would like wider exposure of its MIB by publishing it as an RFC. It could be published as an Informational RFC, which would not require a working group to explicitly consider it. On the other hand, if the IEEE feels it must go through the IETF standards process, then the IETF reserves change control, and has been known to exercise it in unpredictable ways. The complication of differing versions of the mib, IEEE and IETF, was a concern. The previous process of taking an IEEE MIB into a working group was necessary because of the GDMO format. The DTR MIB is not in that format, so the process is not necessary now. The IEEE would like SNMP review of its MIB reviewed by the IETF community. This can be accomplished. Several volunteers were named: Matt Hecht at SNMP Research, and mib-police@cisco.com A note to Fred Baker, IESG Chair, advising him of this IEEE / IETF interaction would be appropriate.