CURRENT MEETING REPORT Reported by Dallas Dec 8 1995 Minutes of the meeting: which combine the agenda, new issues, and the resolution of issues. Draft discussed: draft-ietf-ifmib-mib-01.txt. -Provide an online home for the IANAifType module. Currently isi has an ftp and a web server. See this URL http://www.isi.edu/in-notes/iana/assignments/smi-numbers/ I received initial feedback from Joyce Reynolds that hosting the IANAifType module was possible. One possible issue is the traffic level expected by ISI. Action A web server is a good thing. Traffic should not be a problem. Manager stations will not download a MIB module when booting up; vendors will download it, and send it with software releases. The wg chair will contact ISI and establish a location for the IANAifType mib module. The following are Textual Clarification Issues. This issues were brought up in Stockholm and text has been added to the draft to satisfy the need. -ifIndex > ifNumber will break some apps. Admitted on pg.13 -reuse ifTable OIDs Justified on pg.13 -always have explicit top and bottom ifStack layers Explained on pg.43 -ifName Usage explained on pg.37 -noSuchInstance before columns are known Usage required on pg.23 -ifIndex unique in context Explained on pg.14 Action The Working Group chair will ensure that the draft reflects the best phrase for "community/context" in the current SNMP standards environment. -A spelling question arose. Is "instanciated" the british spelling of "instantiated"? The following are changes to the definition of objects, and reflect decisions that were made in Stockholm. -ifStackTable was made read/create. See pg.44 Action The text should capture why the ifTable should NOT be made read/create. (1) There may be more information needed to create an interface than contained in ifTable. Therefor the appropriate place to create a row is in the Media Specific Mib, where such information is known. (2) In some situations the agent should choose the value for ifIndex, rather than the manager. -ifTestTable deprecated See pg.54 Also see further discussion of the ifTestTable below. The following are objects added to the mib, and reflect decisions that were made in Stockholm. -ifTableLastChange aka the "all bets are off" object Defined on pg.28 Indicates that the ifTable has changed, but doesn't indicate how many additions or deletions. Thus the management station must re-load the entire table. -ifStackLastChange aka yet another "all bets are off" object Defined on pg.45 Action Why is this object on each row? Seems like it should be used the same as ifTableLastChange, where a new value indicates the management station must re-load the table. Wg chair will talk to the editor about intent of the object, and report back to wg. -ifAlias Defined on pg.42 Editor's proposal that ifAlias become "the if handle" +NMS puts handle there +handle stays with the ifIndex +persistant across reboots +have limit on memory usage Policy issue as to what is persistant across reboots/hot-swaps/brain-swaps. Note- The "Cisco Summit" yielded no technical solution. Its policy. Both in Stockholm and in Dallas, this object was much discussed. It was established that most management station implementors (present) do not need to assume ifIndex remain consistant across reboots, and can/will deal with the reload/reindex. An operator observed that they commonly do box swaps and no re-indexing by a box can avoid management station renumbering. Similarly with controller card swap on a box. There are three "levels" of interface naming going on here: (1) logging/stats at the management station, (2) the ifIndex number, (3) the physical card/port if present. There needs to be a mapping between each level. Consistancy between the logging level and ifIndex is handled by the management station, whereas mapping between ifIndex and the physical card/port should be on the agent. It was agreed that the Entity Mib, not the Interfaces Mib, should provide the ifindex to physical mapping capability: (a previous draft of) the Entity Mib had an ifIndex to physical port mapping table. This is quite useful for interfaces for which the ifConnectorPresent object is positive, and shouldn't be there otherwise. Action The WG chair will send a note to the Entity Mib expressing a desire for this functionality, and a pointer to the interface mib describing its use. (Note that Andy Bierman, an entity mib editor, attended this ifmib meeting.) Action The ifmib should clarify what sorts of information to put into ifAlias as compared to ifName and ifDescr. The wg felt that the text on agent space limitations on the length of ifAlias were sufficient, that more mechanistic specifications were not useful. The wg did feel that there was sufficient utility in this object to warrent its inclusion in the Mib, knowing that it incurs an NVRAM cost. Issues from the List that were discussed and resolved. -A new state for ifOper/ifAdmin had been suggested: downBecauseDependency. It is intended to flag configuration issues, while dormant implies waiting for work. Action We do not need this object, but we do need to specify how a lower layer interface's state percolates up to upper layer interfaces. Craft language something like this: "For an interface, While all lower interfaces are either down, unknown, testing, it is down. While all other lower interfaces are either down, unknown, testing, if at least one lower interface is dormant, it is dormant. While all other lower interfaces are either down, unknown, testing or dormant, if at least one lower interface is up, it is up. -A new state called "notPresent" was suggested. It indicates that a card/port which had been located in that spot has been removed. It is vendor specific as to whether (a) the counter etc resources are reclaimed immediately, and the values are lost, in which case the agent immediately "transitions" the interface through the notPresent state and removes the row, or (b) the counter etc resources are reclaimed at a later time, and the values retained for that period of time, and made available to management stations. After that time, the interface "transitions" to non-existance. The duration of time is vendor specific. The meaning of the notPresent state percolates up as follows: While all lower interfaces are either down, unknown, testing, or notPresent it is down. -The 100VG initialization/training state is not quite testing, yet section 3.1.12 enumeration 5, page 21 suggests it should be considered testing. A state characterization of testing would yeild many traps as the interface goes through its initialization. Action Want to call such initialization states down. Need to revise the text to support this interpretation. -ifName usage. Some proxy systems used in large WAN switches could benefit from specifying a routing string on a per interface basis. If they could, the ifName is the appropriate place to put this string. Action Dave Fowler of newbridge will supply text to this effect. -The ifStackTable is implementable if have embedded system, single developer, source code knowlege/control. No implementation experience from open systems with 3rd party developers. Furthermore not all proxy agent implementations/architectures have sufficient visibility to support the ifStackTable. While the WG has sympathy for the implemention problems of open platforms it feels that the ifStackTable has real utility. While the WG acknowleges this utility is most needed on "WAN boxes" it felt this utility overrides implementation problems on certain platforms. There is precedent for this. At other times the implementation difficulties of eg UNIX were not deemed sufficient to quash an object of demonstrable utility. Action The ifStackTable is manditory. If an implementation cannot determine the ifStackTable internally, it must not fake it, by returning a misleading table which indicates no stacking or something else inaccurate. This was considered akin to returning a count of zero when the counter is not implemented. Text forbidding this usage shall be added to the draft. The wg also wants to send a request to the Agentx wg that the capability to support the ifStackTable in a proxy agent environment be a requirement of the extensible agent design. -Kaj's ifTestTable The Atom mib wg is developing tests. It would like a standard way of defining them. The wg felt that it would be good to incorporate tests that included elements other than the interface, eg system self test. Action A new work item is spun off. The Test table will be a separate document. If it is successful, its first stop will be proposed standard. Its task is to distill a general set of test functions that are applicable across various media, and general systems. This will allow mibs to specify code points only, not mechanims. It is the job of the design team use good judgement as to whether multiple simultaneous tests on an interface is worth the implementation complexity it entails. It is also their job to decide whether a "single table" or "dual table" approach is preferable.