From owner-if-mib@padauk.vnd.tek.com Thu Jan 6 01:57:17 2000 Received: from fw1.tek.com (fw1.tek.com [192.65.17.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27337 for ; Thu, 6 Jan 2000 01:57:16 -0500 (EST) Received: from fw1.tek.com (root@localhost) by fw1.tek.com with ESMTP id WAA09284 for ; Wed, 5 Jan 2000 22:56:42 -0800 (PST) Received: from padauk.vnd.tek.com (padauk.vnd.tek.com [128.181.192.78]) by fw1.tek.com with ESMTP id WAA09277 for ; Wed, 5 Jan 2000 22:56:42 -0800 (PST) Received: (from majordomo@localhost) by padauk.vnd.tek.com (8.7.5/8.7.3) id WAA05895 for if-mib-outgoing; Wed, 5 Jan 2000 22:53:56 -0800 (PST) X-Authentication-Warning: padauk.vnd.tek.com: majordomo set sender to owner-if-mib@domo.vnd.tek.com using -f Message-ID: <38743D58.567BCB5A@teleport.com> Date: Wed, 05 Jan 2000 22:59:36 -0800 From: ted brunner X-Mailer: Mozilla 4.61 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: if-mib@vnd.tek.com, tbrunner@omneon.com Subject: new majordomo site Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-if-mib@vnd.tek.com Precedence: bulk Content-Transfer-Encoding: 7bit The if-mib list has been hosted by tektronix for a while, but now it must be re-sited. This has been precipitated by my moving to another company (Omneon). Is there a company which would like to volunteer to be the site, and have me continue to be the administrator? I'm trying to find some options. From the point of view of the hosting company, the traffic level is light. There are about 100 list members. I have been using majordomo, and would prefer to continue with that. Please consider it, and let me know if you could be a host site. Thank you. ted brunner tbrunner@omneon.com From owner-if-mib@padauk.vnd.tek.com Thu Jan 6 18:30:56 2000 Received: from fw1.tek.com (fw1.tek.com [192.65.17.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25041 for ; Thu, 6 Jan 2000 18:30:52 -0500 (EST) Received: from fw1.tek.com (root@localhost) by fw1.tek.com with ESMTP id PAA05079 for ; Thu, 6 Jan 2000 15:30:11 -0800 (PST) Received: from padauk.vnd.tek.com (padauk.vnd.tek.com [128.181.192.78]) by fw1.tek.com with ESMTP id PAA05070 for ; Thu, 6 Jan 2000 15:30:11 -0800 (PST) Received: (from majordomo@localhost) by padauk.vnd.tek.com (8.7.5/8.7.3) id PAA27626 for if-mib-outgoing; Thu, 6 Jan 2000 15:27:56 -0800 (PST) X-Authentication-Warning: padauk.vnd.tek.com: majordomo set sender to owner-if-mib@domo.vnd.tek.com using -f From: "Carl W. Kalbfleisch" To: Subject: unique naming without ifName Date: Thu, 6 Jan 2000 17:23:50 -0600 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-if-mib@vnd.tek.com Precedence: bulk Content-Transfer-Encoding: 7bit http://www.ietf.org/internet-drafts/draft-ietf-ifmib-ifmib2-01.txt describes the use of a new attribute ifName to work around the lack of unique naming of interfaces. If a management application needs to provide unique naming and does not want to suffer from the legacy problems of changing ifIndex, what is considered the best practice? It would seem like the application could do the following in order: 1) use ifName if it exists 2) use ifDescr if it is unique 3) use some other scheme Is there a best practice for (3) except to use ifIndex? Carl -- Carl W. Kalbfleisch Manager NMS Development www.verio.net From owner-if-mib@padauk.vnd.tek.com Fri Jan 7 02:27:46 2000 Received: from fw1.tek.com (fw1.tek.com [192.65.17.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12620 for ; Fri, 7 Jan 2000 02:27:45 -0500 (EST) Received: from fw1.tek.com (root@localhost) by fw1.tek.com with ESMTP id XAA28343 for ; Thu, 6 Jan 2000 23:27:15 -0800 (PST) Received: from padauk.vnd.tek.com (padauk.vnd.tek.com [128.181.192.78]) by fw1.tek.com with ESMTP id XAA28337 for ; Thu, 6 Jan 2000 23:27:15 -0800 (PST) Received: (from majordomo@localhost) by padauk.vnd.tek.com (8.7.5/8.7.3) id XAA09313 for if-mib-outgoing; Thu, 6 Jan 2000 23:17:33 -0800 (PST) X-Authentication-Warning: padauk.vnd.tek.com: majordomo set sender to owner-if-mib@domo.vnd.tek.com using -f Message-ID: <387594E1.86C8FEF5@teleport.com> Date: Thu, 06 Jan 2000 23:25:21 -0800 From: ted brunner X-Mailer: Mozilla 4.61 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: gary_hanson@adc.com CC: "C. M. Heard/VVNET, Inc." , "Chapman, Ken" , if-mib@vnd.tek.com, kzm@cisco.com Subject: Re: Last Call: The Interfaces Group MIB to Draft Standard References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-if-mib@vnd.tek.com Precedence: bulk Content-Transfer-Encoding: 7bit It sounds to me like we have reached a consensus on this point, and unless I hear some quick disagreement, I will conclude this topic. So we shall respin the ifmib, with this change. Given that the IESG last call was on Dec.7 with the call for comments to conclude on Dec.20, I think we can say that this is the last change. Ted Brunner gary_hanson@adc.com wrote: > That sounds like a reasonable argument to me. I can certainly > go along with making ifCounterDiscontinuityTime conditionally > mandatory along the lines you proposed. It sounds like a minor > change to any fielded implementations to remove the object from > those ifTable entries that don't include counters, and I would > guess that no management station would crash upon encountering > an entry that included it when it no longer should, since after > all it WAS required under RFC 2233. > > I also agree with you that it makes sense to NOT fiddle with the > other unconditionally mandatory objects that are already in the > ifGeneralInformationGroup. > > Gary > > On Sat, 25 Dec 1999, C. M. Heard/VVNET, Inc. wrote: > > > On Fri, Dec 17 Gary Hanson wrote: > > > > > It seems to me that the same argument could be made about the > > > ifPhysAddress, ifSpeed, and ifHighSpeed objects, all of which > > > are mandatory objects at present, but which are certainly less > > > than meaningful for a number of interface types. Do you feel > > > as strongly about those objects being pure dead weight as you > > > do about the more recently defined ifCounterDiscontinuityTime > > > object? > > > > No. > > > > > If so, do you feel we should make those objects non-mandatory > > > now as well? And, if not, why not? > > > > The conformance statements for a generic MIB module such as IF-MIB can > > provide only a finite level of granularity. The design provides for six > > disinct types of interfaces: bit-oriented, fixed-length, high capacity > > fixed-length, packet, high capacity packet, very high capacity packet. All > > of the unconditionally mandatory objects except ifCounterDiscontinuityTime > > -- i.e., all of the objects in the ifGeneralInformationGroup -- are at > > least potentially applicable to every one of those interface types. Now if > > we were to make some objects now in the ifGeneralInformationGroup optional, > > that would have the effect of adding more categories of interfaces for > > management stations to support. That would arguably make life more > > difficult for management stations. So there is some positive benefit in > > having the objects in the ifGeneralInformationGroup remain unconditionally > > mandatory. That is not true, however, for ifCounterDiscontinuityTime. > > Making it conditionally mandatory does not require major revision of the > > text, and given that the object is (according to the implementation reports) > > not universally implemented, should not obsolete fielded implementations. > > It won't cost us much, so let's get this right while we still can. > > > > Mike > > -- > > C. M. Heard/VVNET, Inc. > > heard@vvnet.com > > From owner-if-mib@padauk.vnd.tek.com Fri Jan 7 08:04:19 2000 Received: from fw1.tek.com (fw1.tek.com [192.65.17.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16341 for ; Fri, 7 Jan 2000 08:04:18 -0500 (EST) Received: from fw1.tek.com (root@localhost) by fw1.tek.com with ESMTP id FAA01286 for ; Fri, 7 Jan 2000 05:03:47 -0800 (PST) Received: from padauk.vnd.tek.com (padauk.vnd.tek.com [128.181.192.78]) by fw1.tek.com with ESMTP id FAA01278 for ; Fri, 7 Jan 2000 05:03:47 -0800 (PST) Received: (from majordomo@localhost) by padauk.vnd.tek.com (8.7.5/8.7.3) id FAA15060 for if-mib-outgoing; Fri, 7 Jan 2000 05:01:54 -0800 (PST) X-Authentication-Warning: padauk.vnd.tek.com: majordomo set sender to owner-if-mib@domo.vnd.tek.com using -f Message-ID: <3875E319.36618F58@mediaone.net> Date: Fri, 07 Jan 2000 07:59:04 -0500 From: Jon Saperia X-Mailer: Mozilla 4.7 (Macintosh; U; PPC) X-Accept-Language: en MIME-Version: 1.0 To: "Carl W. Kalbfleisch" CC: if-mib@vnd.tek.com Subject: Re: unique naming without ifName References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-if-mib@vnd.tek.com Precedence: bulk Content-Transfer-Encoding: 7bit To the best of what I know, there is not consistent answer for your 'use some other scheme'. In fact different pieces of management software have used different combinations based on a number of factors in the past. Some that I am aware of include mac address (when that is available) in combination with other items. Many times private MIB objects can also be use. If the object gives information about chassis or slot number that can also be helpful in reducing ambiguity about if an interface has changed or not. Previous practices which used things like IP address are no longer helpful in DHCP type of environments. /jon From owner-if-mib@padauk.vnd.tek.com Fri Jan 7 15:24:23 2000 Received: from fw1.tek.com (fw1.tek.com [192.65.17.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26551 for ; Fri, 7 Jan 2000 15:24:22 -0500 (EST) Received: from fw1.tek.com (root@localhost) by fw1.tek.com with ESMTP id MAA07258 for ; Fri, 7 Jan 2000 12:23:52 -0800 (PST) Received: from padauk.vnd.tek.com (padauk.vnd.tek.com [128.181.192.78]) by fw1.tek.com with ESMTP id MAA07247 for ; Fri, 7 Jan 2000 12:23:52 -0800 (PST) Received: (from majordomo@localhost) by padauk.vnd.tek.com (8.7.5/8.7.3) id MAA25860 for if-mib-outgoing; Fri, 7 Jan 2000 12:21:58 -0800 (PST) X-Authentication-Warning: padauk.vnd.tek.com: majordomo set sender to owner-if-mib@domo.vnd.tek.com using -f Message-Id: <4.2.0.58.20000107121958.00a8fc00@flipper.cisco.com> X-Sender: sdurham@flipper.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Fri, 07 Jan 2000 12:21:51 -0800 To: "Carl W. Kalbfleisch" , From: "Sandra C. Durham" Subject: Re: unique naming without ifName In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-if-mib@vnd.tek.com Precedence: bulk i rather thought ifAlias was proposed as the unique handle. Note that ifName is not unique to an interface, as is shown in the example given in rfc2233, and this draft. The one problem w/ ifAlias is it is not automagically populated. So the nms has to write to this object. It is then supposed to remain over a reboot (and thus be a constant unique way to identify the interface). sandra At 05:23 PM 1/6/00 -0600, Carl W. Kalbfleisch wrote: >http://www.ietf.org/internet-drafts/draft-ietf-ifmib-ifmib2-01.txt describes >the use of a new attribute ifName to work around the lack of unique naming >of interfaces. If a management application needs to provide unique naming >and does not want to suffer from the legacy problems of changing ifIndex, >what is considered the best practice? It would seem like the application >could do the following in order: > >1) use ifName if it exists >2) use ifDescr if it is unique >3) use some other scheme > >Is there a best practice for (3) except to use ifIndex? > >Carl > >-- >Carl W. Kalbfleisch >Manager NMS Development >www.verio.net > From owner-if-mib@padauk.vnd.tek.com Sun Jan 9 15:10:38 2000 Received: from fw1.tek.com (fw1.tek.com [192.65.17.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09986 for ; Sun, 9 Jan 2000 15:10:37 -0500 (EST) Received: from fw1.tek.com (root@localhost) by fw1.tek.com with ESMTP id MAA01607 for ; Sun, 9 Jan 2000 12:10:09 -0800 (PST) Received: from padauk.vnd.tek.com (padauk.vnd.tek.com [128.181.192.78]) by fw1.tek.com with ESMTP id MAA01600 for ; Sun, 9 Jan 2000 12:10:09 -0800 (PST) Received: (from majordomo@localhost) by padauk.vnd.tek.com (8.7.5/8.7.3) id MAA13014 for if-mib-outgoing; Sun, 9 Jan 2000 12:06:03 -0800 (PST) X-Authentication-Warning: padauk.vnd.tek.com: majordomo set sender to owner-if-mib@domo.vnd.tek.com using -f Reply-To: From: "David Fowler" To: "Sandra C. Durham" , "Carl W. Kalbfleisch" , Subject: RE: unique naming without ifName Date: Sun, 9 Jan 2000 14:58:42 -0500 Message-ID: <000701bf5adb$ee1bcc00$840fa8c0@BEETLE> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal X-Mimeole: Produced By Microsoft MimeOLE V4.72.3155.0 In-Reply-To: <4.2.0.58.20000107121958.00a8fc00@flipper.cisco.com> Sender: owner-if-mib@vnd.tek.com Precedence: bulk Content-Transfer-Encoding: 7bit Nothing in the definition of ifAlias requires it to be unique, although the discussion of the object in the front of the MIB suggests that this is a possible constraint an NMS may apply to values written to ifAlias. I would not expect use of ifAlias for unique naming to be a common practice. Is anyone on the list current using ifAlias as a unique identifier? David > -----Original Message----- > From: owner-if-mib@vnd.tek.com [mailto:owner-if-mib@vnd.tek.com]On > Behalf Of Sandra C. Durham > Sent: Friday, January 07, 2000 3:22 PM > To: Carl W. Kalbfleisch; if-mib@vnd.tek.com > Subject: Re: unique naming without ifName > > > i rather thought ifAlias was proposed as the unique handle. Note that > ifName is not unique to an interface, as is shown in the example given in > rfc2233, and this draft. > > The one problem w/ ifAlias is it is not automagically populated. So the > nms has to write to this object. It is then supposed to remain over a > reboot (and thus be a constant unique way to identify the interface). > > sandra > > At 05:23 PM 1/6/00 -0600, Carl W. Kalbfleisch wrote: > >http://www.ietf.org/internet-drafts/draft-ietf-ifmib-ifmib2-01.txt describes >the use of a new attribute ifName to work around the lack of unique naming >of interfaces. If a management application needs to provide unique naming >and does not want to suffer from the legacy problems of changing ifIndex, >what is considered the best practice? It would seem like the application >could do the following in order: > >1) use ifName if it exists >2) use ifDescr if it is unique >3) use some other scheme > >Is there a best practice for (3) except to use ifIndex? > >Carl > >-- >Carl W. Kalbfleisch >Manager NMS Development >www.verio.net >