From mailman-admin@ietf.org Thu May 1 09:25:11 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08796 for ; Thu, 1 May 2003 09:25:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19BE5p-00016k-00 for ifmib-archive@ietf.org; Thu, 01 May 2003 09:27:21 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19BE5o-00016I-00 for ifmib-archive@ietf.org; Thu, 01 May 2003 09:27:20 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h41DVb827671 for ; Thu, 1 May 2003 09:31:37 -0400 Date: Thu, 01 May 2003 09:31:37 -0400 Message-ID: <20030501133137.17986.46408.Mailman@www1.ietf.org> Subject: ietf.org mailing list memberships reminder From: mailman-owner@www1.ietf.org To: ifmib-archive@ietf.org X-No-Archive: yes X-Ack: no Sender: mailman-admin@ietf.org Errors-To: mailman-admin@ietf.org X-BeenThere: mailman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, ifmib-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. *************************************************************************** Note Well All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to * the IETF plenary session, * any IETF working group or portion thereof, * the IESG, or any member thereof on behalf of the IESG, * the IAB or any member thereof on behalf of the IAB, * any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, * the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. *************************************************************************** If you have questions, problems, comments, etc, send them to mailman-owner@www1.ietf.org. Thanks! Passwords for ifmib-archive@ietf.org: List Password // URL ---- -------- ifmib@ietf.org agzm https://www1.ietf.org/mailman/options/ifmib/ifmib-archive%40ietf.org From ifmib-admin@ietf.org Thu May 1 17:58:50 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14020; Thu, 1 May 2003 17:58:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19BM6v-0007SP-00; Thu, 01 May 2003 18:01:01 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19BM6u-0007SL-00; Thu, 01 May 2003 18:01:00 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h41M24813558; Thu, 1 May 2003 18:02:04 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h41M1k813500 for ; Thu, 1 May 2003 18:01:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13706 for ; Thu, 1 May 2003 17:55:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19BM3E-0007O5-00 for ifmib@ietf.org; Thu, 01 May 2003 17:57:13 -0400 Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx with esmtp (Exim 4.12) id 19BM39-0007NY-00 for ifmib@ietf.org; Thu, 01 May 2003 17:57:07 -0400 Received: from INET-VRS-02.redmond.corp.microsoft.com ([157.54.8.110]) by mail2.microsoft.com with Microsoft SMTPSVC(5.0.2195.6624); Thu, 1 May 2003 14:56:42 -0700 Received: from 157.54.6.150 by INET-VRS-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 01 May 2003 14:56:42 -0700 Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-hub-05.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 1 May 2003 14:56:41 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 1 May 2003 14:56:41 -0700 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.82]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3788.0); Thu, 1 May 2003 14:56:41 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.6851.8 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 1 May 2003 14:56:40 -0700 Message-ID: Thread-Topic: FWD: Restart ifmib WG? Thread-Index: AcJu5Dijdg/UX7svT8KgqvKnDRgPAChPYagw From: "Dave Thaler" To: X-OriginalArrivalTime: 01 May 2003 21:56:41.0395 (UTC) FILETIME=[8C3D7830:01C3102C] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h41M1k813501 Subject: [ifmib] RE: FWD: Restart ifmib WG? Sender: ifmib-admin@ietf.org Errors-To: ifmib-admin@ietf.org X-BeenThere: ifmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF Interfaces MIB working group mailing list. List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit There's been a number of suggestions on this list for improvements that would be useful to add in a supplemental IF MIB module in a separate RFC. On this topic, I recently received some IF MIB feedback from folks here in Microsoft on things they considered to be missing: > I also see RFC to be inadequate in not being able > to report -not known- for -current- link state and > speed (and instead using maximum link speed) > Not having separate [objects] for xmit and > receive link speeds, not having an object for > permanent mac address, no support for power > management, etc. -Dave _______________________________________________ ifmib mailing list ifmib@ietf.org https://www1.ietf.org/mailman/listinfo/ifmib From ifmib-admin@ietf.org Fri May 2 13:55:56 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23104; Fri, 2 May 2003 13:55:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19BenE-00069O-00; Fri, 02 May 2003 13:57:56 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Bemj-00068r-00; Fri, 02 May 2003 13:57:25 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h42Hwb811203; Fri, 2 May 2003 13:58:37 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h42HvQ811084 for ; Fri, 2 May 2003 13:57:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22858 for ; Fri, 2 May 2003 13:50:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Behr-00066J-00 for ifmib@ietf.org; Fri, 02 May 2003 13:52:23 -0400 Received: from sj-core-2.cisco.com ([171.71.177.254]) by ietf-mx with esmtp (Exim 4.12) id 19BehW-00065n-00 for ifmib@ietf.org; Fri, 02 May 2003 13:52:02 -0400 Received: from cisco.com (cypher.cisco.com [171.69.11.143]) by sj-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h42HpvxI021765; Fri, 2 May 2003 10:51:58 -0700 (PDT) Received: (from kzm@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id KAA25909; Fri, 2 May 2003 10:51:57 -0700 (PDT) From: Keith McCloghrie Message-Id: <200305021751.KAA25909@cisco.com> Subject: Re: [ifmib] RE: FWD: Restart ifmib WG? To: dthaler@windows.microsoft.com (Dave Thaler) Date: Fri, 2 May 2003 10:51:57 -0700 (PDT) Cc: ifmib@ietf.org In-Reply-To: from "Dave Thaler" at May 01, 2003 02:56:40 PM X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ifmib-admin@ietf.org Errors-To: ifmib-admin@ietf.org X-BeenThere: ifmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF Interfaces MIB working group mailing list. List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Dave, > There's been a number of suggestions on this list > for improvements that would be useful to add in a > supplemental IF MIB module in a separate RFC. > On this topic, I recently received some IF MIB > feedback from folks here in Microsoft on things > they considered to be missing: > > I also see RFC to be inadequate in not being able > > to report -not known- for -current- link state and The value 'unknown' is already defined got ifOperStatus. > > speed (and instead using maximum link speed) > > Not having separate [objects] for xmit and > > receive link speeds, not having an object for The issue of link speed, both unknown speed and different speeds for xmit/rcv, has been discussed on several previous occasions, and on each such occasion the WG decided that any additional objects should be placed in media-specific MIBs. As I recall, the argument went something like this: we have done dozens (maybe even hundreds) of media-specific MIBs; what has changed now that didn't apply to all those we have already done, and if it didn't apply to all those we have already done, why is it needed now?? > > permanent mac address, no support for power > > management, etc. The number of interface types which have MAC addresses and support "power management" is certainly *less* than the number of interface types which don't. Thus, again, this is media-specific. Keith. _______________________________________________ ifmib mailing list ifmib@ietf.org https://www1.ietf.org/mailman/listinfo/ifmib From ifmib-admin@ietf.org Fri May 2 20:50:09 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08383; Fri, 2 May 2003 20:50:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19BlGE-0001L8-00; Fri, 02 May 2003 20:52:18 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19BlGD-0001Kx-00; Fri, 02 May 2003 20:52:17 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h430r9812076; Fri, 2 May 2003 20:53:09 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h430qJ812045 for ; Fri, 2 May 2003 20:52:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08337 for ; Fri, 2 May 2003 20:44:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19BlB3-0001Ji-00 for ifmib@ietf.org; Fri, 02 May 2003 20:46:57 -0400 Received: from shell4.bayarea.net ([209.128.82.1]) by ietf-mx with esmtp (Exim 4.12) id 19BlAx-0001JX-00 for ifmib@ietf.org; Fri, 02 May 2003 20:46:51 -0400 Received: from localhost (heard@localhost) by shell4.bayarea.net (8.11.6/8.11.6) with ESMTP id h430l2g12208; Fri, 2 May 2003 17:47:02 -0700 X-Authentication-Warning: shell4.bayarea.net: heard owned process doing -bs Date: Fri, 2 May 2003 17:47:00 -0700 (PDT) From: "C. M. Heard" X-Sender: heard@shell4.bayarea.net To: ifmib@ietf.org Subject: Re: [ifmib] RE: FWD: Restart ifmib WG? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ifmib-admin@ietf.org Errors-To: ifmib-admin@ietf.org X-BeenThere: ifmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF Interfaces MIB working group mailing list. List-Post: List-Help: List-Subscribe: , On Fri, 2 May 2003, Keith McCloghrie wrote: >[On Thu, 1 May 2003, Dave Thaler wrote:] > > There's been a number of suggestions on this list > > for improvements that would be useful to add in a > > supplemental IF MIB module in a separate RFC. > > On this topic, I recently received some IF MIB > > feedback from folks here in Microsoft on things > > they considered to be missing: > > > I also see RFC to be inadequate in not being able > > > to report -not known- for -current- link state and > > The value 'unknown' is already defined got ifOperStatus. Correct. > > > speed (and instead using maximum link speed) > > > Not having separate [objects] for xmit and > > > receive link speeds, not having an object for > > The issue of link speed, both unknown speed and different speeds for > xmit/rcv, has been discussed on several previous occasions, and on each > such occasion the WG decided that any additional objects should be > placed in media-specific MIBs. As I recall, the argument went > something like this: we have done dozens (maybe even hundreds) of > media-specific MIBs; what has changed now that didn't apply to all > those we have already done, and if it didn't apply to all those we > have already done, why is it needed now?? I agree with this. Allow me to point out that for 802.3 interfaces the media-specific MIB modules in fact already do take care of the "current" vs. "maximum" link speed issue. Specifically, the MAU-MIB object ifMauTypeListBits lists all the supported medium type / interface speed / duplex combinations, with current medium type / interface speed / duplex combination reported by ifMauType (see RFC 2668 or ). The EtherLike-MIB (see RFC 2665 or ) states that ifSpeed and ifHighSpeed report the _current_ speed. Standard behaviour for 802.3 interface types is that transmit and receive speeds are the same, so any implementation that supports running at different speeds is engaging in proprietary behaviour which I would expect to be managed by an enterprise MIB module. > > > permanent mac address, no support for power > > > management, etc. > > The number of interface types which have MAC addresses and support > "power management" is certainly *less* than the number of interface > types which don't. Thus, again, this is media-specific. In fairness, it should be pointed out that some media-specific things are managed in the IF-MIB, and MAC addresses are one such thing; however, "permanent" MAC address is something that probably belongs in a proprietary MIB module. Again using 802.3 interfaces as an example, MAC addresses are maintained in the IF-MIB objects ifPhysAddress and ifRcvAddressTable, with ifPhysAddress containing the unicast address used as the source address and ifRcvAddressTable contaning all unicast and multicast addresses for which the interface will accept traffic. Although the ifRcvAddressTable allows for non-volatile entries, no allowance is made for having a "permanent" but "inactive" unicast MAC address. On the other hand, the 802.3 standard does not provide for any such managed object either, so it is probably not unreasonable to expect it to be in a proprietary extension. As for power management, the MAU-MIB object ifMauStatus at least partially accomodates this function; see the definitions of the values standby(4) and shutdown(5). //cmh _______________________________________________ ifmib mailing list ifmib@ietf.org https://www1.ietf.org/mailman/listinfo/ifmib