From ifmib-admin@ietf.org Fri Oct 5 07:21:24 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18594; Fri, 5 Oct 2001 07:21:24 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA04129; Fri, 5 Oct 2001 07:21:11 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA04101 for ; Fri, 5 Oct 2001 07:21:09 -0400 (EDT) Received: from hotmail.com (oe38.law12.hotmail.com [64.4.18.95]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18588 for ; Fri, 5 Oct 2001 07:21:08 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 5 Oct 2001 04:20:38 -0700 X-Originating-IP: [203.190.129.102] From: "Jassi" To: Date: Fri, 5 Oct 2001 16:59:31 +0530 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0023_01C14DBF.19CE3040" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Message-ID: X-OriginalArrivalTime: 05 Oct 2001 11:20:38.0966 (UTC) FILETIME=[C2F62D60:01C14D8F] Subject: [ifmib] RcvAddressTable in If-mib. Sender: ifmib-admin@ietf.org Errors-To: ifmib-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: IETF Interfaces MIB working group mailing list. X-BeenThere: ifmib@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_0023_01C14DBF.19CE3040 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello, I am implementing if-mib(rfc 2863) for my router. We have interfaces = like Gbit,Atm and DS3. I am getting a little confused about = RcvAddressTable. How is it implimented and what should be the enteries = in this. Are there any sample RcvAddressTables available on net. = ....which could help me understand it in better way. Please help me in = this regard. Thanks in advance, Regards, Jassi. ------=_NextPart_000_0023_01C14DBF.19CE3040 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hello,
 
I am implementing if-mib(rfc 2863) for = my router.=20 We have interfaces like Gbit,Atm and DS3. I am getting a little confused = about=20 RcvAddressTable. How is it implimented and what should be the enteries = in this.=20 Are there any sample RcvAddressTables available on net. ....which could = help me=20 understand it in better way. Please help me in this regard.
 
Thanks in advance,
 
Regards,
Jassi.
 
------=_NextPart_000_0023_01C14DBF.19CE3040-- _______________________________________________ ifmib mailing list ifmib@ietf.org http://www1.ietf.org/mailman/listinfo/ifmib From ifmib-admin@ietf.org Fri Oct 5 07:38:03 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18897; Fri, 5 Oct 2001 07:37:58 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA04818; Fri, 5 Oct 2001 07:37:38 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA04801 for ; Fri, 5 Oct 2001 07:37:37 -0400 (EDT) Received: from hotmail.com (oe17.law12.hotmail.com [64.4.18.121]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18891 for ; Fri, 5 Oct 2001 07:37:35 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 5 Oct 2001 04:37:06 -0700 X-Originating-IP: [203.190.129.102] From: "Jassi" To: Date: Fri, 5 Oct 2001 17:16:15 +0530 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_007C_01C14DC1.70491870" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Message-ID: X-OriginalArrivalTime: 05 Oct 2001 11:37:06.0685 (UTC) FILETIME=[0FB022D0:01C14D92] Subject: [ifmib] about the archive Sender: ifmib-admin@ietf.org Errors-To: ifmib-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: IETF Interfaces MIB working group mailing list. X-BeenThere: ifmib@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_007C_01C14DC1.70491870 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello, I am not able to view the archive = ftp://thumper.bellcore.com/pub/Group.archive/if-mib . Is it possible to = view the archive in any other way.? regards, Jassi. ------=_NextPart_000_007C_01C14DC1.70491870 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hello,
 
I am not able to view the archive = ftp://thumpe= r.bellcore.com/pub/Group.archive/if-mib=20 . Is it possible to view the archive in any other = way.?
 
regards,
Jassi.
 

 
------=_NextPart_000_007C_01C14DC1.70491870-- _______________________________________________ ifmib mailing list ifmib@ietf.org http://www1.ietf.org/mailman/listinfo/ifmib From ifmib-admin@ietf.org Fri Oct 5 15:27:42 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29660; Fri, 5 Oct 2001 15:27:42 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA20431; Fri, 5 Oct 2001 15:27:28 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA20411 for ; Fri, 5 Oct 2001 15:27:27 -0400 (EDT) Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29649 for ; Fri, 5 Oct 2001 15:27:23 -0400 (EDT) Received: from localhost (heard@localhost) by shell4.bayarea.net (8.9.3/8.9.3) with ESMTP id MAA16168; Fri, 5 Oct 2001 12:27:18 -0700 (envelope-from heard@pobox.com) X-Authentication-Warning: shell4.bayarea.net: heard owned process doing -bs Date: Fri, 5 Oct 2001 12:27:18 -0700 (PDT) From: "C. M. Heard" X-Sender: heard@shell4.bayarea.net To: Jassi cc: ifmib@ietf.org Subject: Re: [ifmib] about the archive In-Reply-To: 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-Mailman-Version: 1.0 Precedence: bulk List-Id: IETF Interfaces MIB working group mailing list. X-BeenThere: ifmib@ietf.org On Fri, 5 Oct 2001, Jassi wrote: > Hello, > > I am not able to view the archive > ftp://thumper.bellcore.com/pub/Group.archive/if-mib > Is it possible to view the archive in any other way.? ftp://ftp.ietf.org/ietf-mail-archive/ifmib //cmh _______________________________________________ ifmib mailing list ifmib@ietf.org http://www1.ietf.org/mailman/listinfo/ifmib From ifmib-admin@ietf.org Fri Oct 5 17:42:37 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02099; Fri, 5 Oct 2001 17:42:37 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA23739; Fri, 5 Oct 2001 17:40:44 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA23721 for ; Fri, 5 Oct 2001 17:40:43 -0400 (EDT) Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02058 for ; Fri, 5 Oct 2001 17:40:41 -0400 (EDT) Received: from shannon.research.telcordia.com (shannon [128.96.73.2]) by thumper.research.telcordia.com (8.10.1/8.10.1) with ESMTP id f95Le8C08433; Fri, 5 Oct 2001 17:40:09 -0400 (EDT) Received: from kaj-1.research.telcordia.com (nv-ktesink.cc.telcordia.com [128.96.82.9]) by shannon.research.telcordia.com (8.8.8/8.8.8) with ESMTP id RAA03785; Fri, 5 Oct 2001 17:40:07 -0400 (EDT) Message-Id: <4.3.2.7.2.20011005173819.00cba260@shannon.research.telcordia.com> X-Sender: kaj@shannon.research.telcordia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 05 Oct 2001 17:40:01 -0400 To: "C. M. Heard" , Jassi From: Kaj Tesink Subject: Re: [ifmib] about the archive Cc: ifmib@ietf.org In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Sender: ifmib-admin@ietf.org Errors-To: ifmib-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: IETF Interfaces MIB working group mailing list. X-BeenThere: ifmib@ietf.org At 12:27 PM 10/5/01 -0700, C. M. Heard wrote: >On Fri, 5 Oct 2001, Jassi wrote: > > > Hello, > > > > I am not able to view the archive > > ftp://thumper.bellcore.com/pub/Group.archive/if-mib that pointer on the ifmib charter page is outdated. ted/thomas/erik please correct kaj > > Is it possible to view the archive in any other way.? > >ftp://ftp.ietf.org/ietf-mail-archive/ifmib > >//cmh > > >_______________________________________________ >ifmib mailing list >ifmib@ietf.org >http://www1.ietf.org/mailman/listinfo/ifmib _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ Kaj Tesink Telcordia Technologies Email kaj@research.telcordia.com Tel 732.758.5254 Fax 732.758.2269 Postal 331 Newman Springs Rd Red Bank, NJ 07701 USA _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ _______________________________________________ ifmib mailing list ifmib@ietf.org http://www1.ietf.org/mailman/listinfo/ifmib From ifmib-admin@ietf.org Sun Oct 7 12:55:44 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24534; Sun, 7 Oct 2001 12:55:44 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA00181; Sun, 7 Oct 2001 12:55:25 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA00165 for ; Sun, 7 Oct 2001 12:55:24 -0400 (EDT) Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24530 for ; Sun, 7 Oct 2001 12:55:22 -0400 (EDT) Received: from localhost (heard@localhost) by shell4.bayarea.net (8.9.3/8.9.3) with ESMTP id JAA27455; Sun, 7 Oct 2001 09:55:23 -0700 (envelope-from heard@pobox.com) X-Authentication-Warning: shell4.bayarea.net: heard owned process doing -bs Date: Sun, 7 Oct 2001 09:55:23 -0700 (PDT) From: "C. M. Heard" X-Sender: heard@shell4.bayarea.net To: ifmib@ietf.org cc: atommib@research.telcordia.com Subject: Re: [ifmib] RcvAddressTable in If-mib. In-Reply-To: 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-Mailman-Version: 1.0 Precedence: bulk List-Id: IETF Interfaces MIB working group mailing list. X-BeenThere: ifmib@ietf.org On Fri, 5 Oct 2001, Jassi wrote: > > I am implementing if-mib(rfc 2863) for my router. We have interfaces > like Gbit,Atm and DS3. I am getting a little confused about > RcvAddressTable. How is it implimented and what should be the enteries > in this. Are there any sample RcvAddressTables available on net. > ....which could help me understand it in better way. Please help me in > this regard. RFC 2863 states that The media-specific MIB designer MUST specify the applicability of the ifRcvAddressTable. Thus, you need to look in RFC 2665 to see what to do with the ifRcvAddressTable for Gbit Ethernet interfaces, in RFC 2495 for DS1/E1 interfaces, in RFC 2496 for DS3/E3 interfaces, in RFC 2558 for SONET/SDH interfaces, and in RFC 2515 for ATM interfaces. RFC 2665 does contain explicit instructions on what to do with ifRcvAddressTable. However, ifRcvAddressTable is not mentioned in RFC 2495, RFC 2496, RFC 2558, or RFC 2515. From the description below "This table contains an entry for each address (broadcast, multicast, or uni-cast) for which the system will receive packets/frames on a particular interface [ ... ]" it obviously does not apply to DS1, DS3, or SONET interfaces, since these interfaces don't deal with packets. It's not as clear for ATM interfaces, since those interfaces may deal with signalling messages; but I'd say it does not, since ordinary data cells do not have any well-defined interface address in them. I'm cc'ing this message to the AToMMIB list, where issues relating to the DS1, DS3, SONET, and ATM documents are discussed. May I suggest to each of the document editors to add an action item to put in some text saying that ifRcvAddressTable does not apply to those interfaces? Please direct follow-up discussion on this issue to the atommib list. Regards, Mike _______________________________________________ ifmib mailing list ifmib@ietf.org http://www1.ietf.org/mailman/listinfo/ifmib From ifmib-admin@ietf.org Tue Oct 9 13:34:18 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09636; Tue, 9 Oct 2001 13:34:14 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA00043; Tue, 9 Oct 2001 13:28:54 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA00025 for ; Tue, 9 Oct 2001 13:28:45 -0400 (EDT) Received: from hotmail.com (f12.law11.hotmail.com [64.4.17.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09286 for ; Tue, 9 Oct 2001 13:28:41 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 9 Oct 2001 10:28:14 -0700 Received: from 216.103.88.23 by lw11fd.law11.hotmail.msn.com with HTTP; Tue, 09 Oct 2001 17:28:14 GMT X-Originating-IP: [216.103.88.23] From: "Faye Ly" To: heard@pobox.com, ifmib@ietf.org Cc: atommib@research.telcordia.com Subject: Re: [ifmib] RcvAddressTable in If-mib. Date: Tue, 09 Oct 2001 10:28:14 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 09 Oct 2001 17:28:14.0531 (UTC) FILETIME=[C6C15130:01C150E7] Sender: ifmib-admin@ietf.org Errors-To: ifmib-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: IETF Interfaces MIB working group mailing list. X-BeenThere: ifmib@ietf.org Mike, That sounds like a good idea. Will follow up the action items in the following editing of the RFC's. -faye >From: "C. M. Heard" >To: ifmib@ietf.org >CC: atommib@research.telcordia.com >Subject: Re: [ifmib] RcvAddressTable in If-mib. >Date: Sun, 7 Oct 2001 09:55:23 -0700 (PDT) > >On Fri, 5 Oct 2001, Jassi wrote: > > > > I am implementing if-mib(rfc 2863) for my router. We have interfaces > > like Gbit,Atm and DS3. I am getting a little confused about > > RcvAddressTable. How is it implimented and what should be the enteries > > in this. Are there any sample RcvAddressTables available on net. > > ....which could help me understand it in better way. Please help me in > > this regard. > >RFC 2863 states that > > The media-specific MIB designer MUST specify the applicability of > the ifRcvAddressTable. > >Thus, you need to look in RFC 2665 to see what to do with the >ifRcvAddressTable for Gbit Ethernet interfaces, in RFC 2495 for >DS1/E1 interfaces, in RFC 2496 for DS3/E3 interfaces, in RFC 2558 >for SONET/SDH interfaces, and in RFC 2515 for ATM interfaces. > >RFC 2665 does contain explicit instructions on what to do with >ifRcvAddressTable. > >However, ifRcvAddressTable is not mentioned in RFC 2495, RFC 2496, >RFC 2558, or RFC 2515. From the description below > > "This table contains an entry for each address (broadcast, > multicast, or uni-cast) for which the system will receive > packets/frames on a particular interface [ ... ]" > >it obviously does not apply to DS1, DS3, or SONET interfaces, since >these interfaces don't deal with packets. It's not as clear for >ATM interfaces, since those interfaces may deal with signalling >messages; but I'd say it does not, since ordinary data cells do not >have any well-defined interface address in them. > >I'm cc'ing this message to the AToMMIB list, where issues relating >to the DS1, DS3, SONET, and ATM documents are discussed. May I >suggest to each of the document editors to add an action item to >put in some text saying that ifRcvAddressTable does not apply to >those interfaces? Please direct follow-up discussion on this issue >to the atommib list. > >Regards, > >Mike > _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp _______________________________________________ ifmib mailing list ifmib@ietf.org http://www1.ietf.org/mailman/listinfo/ifmib From mailman-owner@ietf.org Wed Oct 24 15:16:19 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12170 for ; Wed, 24 Oct 2001 15:16:18 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA18611 for ; Wed, 24 Oct 2001 15:16:20 -0400 (EDT) Date: Wed, 24 Oct 2001 15:16:20 -0400 (EDT) Message-Id: <200110241916.PAA18611@optimus.ietf.org> From: mailman-owner@ietf.org Subject: ietf.org mailing list memberships reminder To: ifmib-archive@ietf.org X-No-Archive: yes Precedence: bulk X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol 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. If you have questions, problems, comments, etc, send them to mailman-owner@ietf.org. Thanks! Passwords for ifmib-archive@ietf.org: List Password // URL ---- -------- ifmib@ietf.org agzm http://www1.ietf.org/mailman/options/ifmib/ifmib-archive@ietf.org From ifmib-admin@ietf.org Thu Oct 25 10:41:44 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20657; Thu, 25 Oct 2001 10:41:44 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA08027; Thu, 25 Oct 2001 10:37:17 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA08010 for ; Thu, 25 Oct 2001 10:37:16 -0400 (EDT) Received: from dnsmx1rrc.telcordia.com (dnsmx1rrc.telcordia.com [128.96.20.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20535 for ; Thu, 25 Oct 2001 10:37:11 -0400 (EDT) Received: from notes800.cc.telcordia.com (notes800a.cc.telcordia.com [128.96.79.8]) by dnsmx1rrc.telcordia.com (8.9.3/8.9.3) with ESMTP id KAA17019 for ; Thu, 25 Oct 2001 10:31:37 -0400 (EDT) To: ifmib@ietf.org X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: "Miri Park" Date: Thu, 25 Oct 2001 10:31:37 -0400 X-MIMETrack: Serialize by Router on notes800/Telcordia(Release 5.0.6a |January 17, 2001) at 10/25/2001 10:31:38 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: [ifmib] read-write access in IF-MIB Sender: ifmib-admin@ietf.org Errors-To: ifmib-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: IETF Interfaces MIB working group mailing list. X-BeenThere: ifmib@ietf.org Hi, I'm designing the SNMP interface to manage the switch-routers. I need to configure the service through the NMS. For example, configuration of PPPoA on the OC12 port. However most objects in IF-MIB are read-only. (I believe this is for security reason) Then, How can the managing system set the object? Do I have to use CLI or define a new proprietary table to allow the managing system to set? Which is the more common way? Please give me an answer. Kind Regards Miri _______________________________________________ ifmib mailing list ifmib@ietf.org http://www1.ietf.org/mailman/listinfo/ifmib From ifmib-admin@ietf.org Thu Oct 25 20:56:59 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA03901; Thu, 25 Oct 2001 20:56:55 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA25834; Thu, 25 Oct 2001 20:56:39 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA25814 for ; Thu, 25 Oct 2001 20:56:38 -0400 (EDT) Received: from riverstonenet.com (mail.riverstonenet.com [63.113.148.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA03886 for ; Thu, 25 Oct 2001 20:56:32 -0400 (EDT) Received: from agile.yagosys.com by riverstonenet.com (8.9.3+Sun/SMI-SVR4-Yago) id RAA06974; Thu, 25 Oct 2001 17:56:05 -0700 (PDT) Received: from agile.yagosys.com (agile.yagosys.com [127.0.0.1]) by agile.yagosys.com (8.12.0/8.12.0) with ESMTP id f9Q0soxZ002199; Thu, 25 Oct 2001 17:54:50 -0700 Received: (from mrm@localhost) by agile.yagosys.com (8.12.0/8.12.0/Submit) id f9Q0snnc002198; Thu, 25 Oct 2001 17:54:49 -0700 Date: Thu, 25 Oct 2001 17:54:49 -0700 From: Michael MacFaden To: ifmib@ietf.org Subject: [ifmib] read-write access in IF-MIB Message-ID: <20011025175449.E2080@riverstonenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i X-Operating-System: GNU/Linux 2.4.12 Sender: ifmib-admin@ietf.org Errors-To: ifmib-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: IETF Interfaces MIB working group mailing list. X-BeenThere: ifmib@ietf.org >From: "Miri Park" >I'm designing the SNMP interface to manage the switch-routers. Great! NCON NGN-ESS lives? >I need to configure the service through the NMS. >For example, configuration of PPPoA on the OC12 port. >However most objects in IF-MIB are read-only. (I believe this is for >security reason) That would not be the right reason. Please read rfc2863 section 3. IP in general and the IF-MIB in specific do not really care about the details of the underlying network technology. As a result, the IF-MIB represents a decidedly abstract IP only view of the actual physical or logical sub-interfaces. >Then, How can the managing system set the object? One would use the technology specific MIB module located in either the standards space (MAU-MIB, SONET-MIB, ATM-MIB, DS1-MIB, etc) or a proprietary MIB module. A review of the current standard MIB modules one might find today in today's gear are located in this tutorial I did with Chris Elliot of Cisco at NANOG (www.nanog.org) a while back. http://www.nmops.org/download/understanding-snmp-counters.pdf This document has info on how to find a given MIB module if it exists in the standards space. >Do I have to use CLI or define a new proprietary table to allow the >managing system to set? >Which is the more common way? That really depends on the product, vendor and feature you want to configure. Here are my thoughts for Layer 2 and 3 configuration: For layer 2 devices(IEEE bridges), SNMP sets are very well supported and pretty simple to do and have been used to manage l2 gear since '93 (DEC giga-switches in MAEs deployments for example or their newer replacements. So operationally many GigE/Metro operators are still using SNMP sets without problems with gear from a number of vendors. The amount of configuration data that needs to be sent to any given brige is also pretty small. be warned: there is pretty great variability in how anybody does anything even if it is supposedly standard. Consider RFC 1493, the BRIDGE-MIB, a very mature and well done module: http://www.macfaden.com/ietf/bridge-test-results.txt There is a cool mechanism to determine at runtime a device's specific implementation of some MIB module without having to spend time guessing without a large amount of probing.. If the vendor provides an Agent Capablities MIB module for the product, you can quickly determine the implementation level for a given agent. As far as I know at least two switch-router vendors publish agent-caps for their devices and implement the sysORTable in their agents which you can ftp freely from their respective websites. RFC 1907 has the extensions to the system group which you will want to poll the sysORTable to obtain the OID for the agent-cap which can allow your application to determine what a given device supports and whether it is read-only or read-write. ---- For layer 3(IETF IP Routers), SNMP has not been sucessful as a configuration mechanism (but has been just dandy at monitoring it). I think this is for two reasons. One the underlying technology has not had a clean mgmt plane definition of the likes seen in the IEEE specs (just read the IP, OSPF (RFC1583)). There is no mgmt considerations section on what should be exposed to management in a standard way. So different routers make different weightings of their route types, direct, static, ospf, ospf-ase, etc. All very difficult to manage in any real dumb programmatic sense that scales. And from the operations side, if I heard Sean Doran correctly, he stated at at NANOG this week that he thought bgp peering with another company is about as difficult as using two different vendor's gear in one company. Ie it's doable, but really difficult. Two, some of the IETF/IP technology is really hard to manage since any mistake can have world wide impact. See the presentations this week at NANOG 23 from the research types. http://www.nanog.org/mtg-0110/agenda.html (beginning with Shining light on dark address space). Some organizations have actually ended up DDOSing themselves by announcing to general a prefix via ebgp... As a result, highly skilled operators sit carefully over their devices 24/7 staring at "looking glass" and at router logs and prefer to configure routers by building larger/better command line configuration text files of size ~200k containing access-control lists, route maps, igp/egp router configuration and misc sundry bits. In summary, for IP Routers/Layer 3, you have to use some vendor's CLI. For Layer 2, SNMP will work but not without knowing alot about the vendors snmp implementations. Lastly, If Kaj Tesink is still at Telcoridia, he wrote rfc2558 SONET-MIB (march 1999) and could probably help you out. Regards, Mike MacFaden PS, For one description of an SNMP agent implementation for a layer 2/3 switch-router see: http://www.nmops.org/download/rs-snmp-mgmt.pdf Appendix A and and B might be useful. _______________________________________________ ifmib mailing list ifmib@ietf.org http://www1.ietf.org/mailman/listinfo/ifmib From ifmib-admin@ietf.org Tue Oct 30 05:01:11 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA23594; Tue, 30 Oct 2001 05:01:10 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA24097; Tue, 30 Oct 2001 04:59:55 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA24076 for ; Tue, 30 Oct 2001 04:59:54 -0500 (EST) Received: from hotmail.com (oe29.law12.hotmail.com [64.4.18.86]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23546 for ; Tue, 30 Oct 2001 04:59:50 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 30 Oct 2001 01:59:23 -0800 X-Originating-IP: [203.190.129.102] From: "snmp2jassi" To: Date: Tue, 30 Oct 2001 15:38:50 +0530 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0069_01C16158.F8C3C380" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Message-ID: X-OriginalArrivalTime: 30 Oct 2001 09:59:23.0748 (UTC) FILETIME=[8D6EB240:01C16129] Subject: [ifmib] about LinkUp/LinkDown traps. Sender: ifmib-admin@ietf.org Errors-To: ifmib-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: IETF Interfaces MIB working group mailing list. X-BeenThere: ifmib@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_0069_01C16158.F8C3C380 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello, I am implementing rfc2863 and i am having problems in deciding about = "Link Up/Down Trap generation" in case of Interface going from up/down = state.=20 I am presently having ifEntry for PVC's, SVC's, PPP, Gbit, DS3. At = present i have implemented only 2 values for ifOperStatus for the = interfaces. Please guide me when all do i need to generate Link up/down = traps in my case. All the interfaces comes up with a default value of = "down". Do i need to generate a LinkDown trap at that time? Thanks in advance, Regards, Jassi. ------=_NextPart_000_0069_01C16158.F8C3C380 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hello,
 
I am implementing rfc2863 and i am = having problems=20 in deciding about "Link Up/Down Trap generation" in case of Interface = going from=20 up/down state.
 
I am presently having ifEntry for = PVC's, SVC's,=20 PPP, Gbit, DS3. At present i have implemented only 2 values for = ifOperStatus for=20 the interfaces. Please guide me when all do i need to generate Link = up/down=20 traps in my case. All the interfaces comes up with a default value of = "down". Do=20 i need to generate a LinkDown trap at that time?
 
Thanks in advance,
 
Regards,
Jassi.
 
------=_NextPart_000_0069_01C16158.F8C3C380-- _______________________________________________ ifmib mailing list ifmib@ietf.org http://www1.ietf.org/mailman/listinfo/ifmib From ifmib-admin@ietf.org Tue Oct 30 06:39:45 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA24368; Tue, 30 Oct 2001 06:39:45 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA26458; Tue, 30 Oct 2001 06:36:55 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA26437 for ; Tue, 30 Oct 2001 06:36:54 -0500 (EST) Received: from mail.nettasking.com ([203.126.164.226]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA24346 for ; Tue, 30 Oct 2001 06:36:49 -0500 (EST) Received: from LIAOJIAN ([192.168.2.72]) by mail.nettasking.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id V3HJ230R; Tue, 30 Oct 2001 19:42:08 +0800 Message-ID: <063301c161bd$c2cea3c0$4802a8c0@liaojian> From: "zhu ming" To: References: <200110261600.MAA01038@optimus.ietf.org> Date: Tue, 30 Oct 2001 19:40:17 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Subject: [ifmib] convert log to MIB in linux. Sender: ifmib-admin@ietf.org Errors-To: ifmib-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: IETF Interfaces MIB working group mailing list. X-BeenThere: ifmib@ietf.org Content-Transfer-Encoding: 7bit Hi, I want to convert some information of a log file into a MIB on linux. And then others can get the information by using remote SNMP query. The log file looks like this: time-stamp host-name device-name device-status E.g.: Oct 01 00:02 server1 SYS STATUS: UP, OK Oct 01 00:02 server2 PS0: UP, OK Pls give me a hand on this issue, i.e. the detail steps to do that or any useful documentation/url. Thank you in advance, zm. _______________________________________________ ifmib mailing list ifmib@ietf.org http://www1.ietf.org/mailman/listinfo/ifmib From ifmib-admin@ietf.org Tue Oct 30 11:38:03 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06405; Tue, 30 Oct 2001 11:38:03 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA08004; Tue, 30 Oct 2001 11:15:45 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA07983 for ; Tue, 30 Oct 2001 11:15:44 -0500 (EST) Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05559 for ; Tue, 30 Oct 2001 11:15:39 -0500 (EST) Received: from localhost (heard@localhost) by shell4.bayarea.net (8.9.3/8.9.3) with ESMTP id IAA19742; Tue, 30 Oct 2001 08:15:42 -0800 (envelope-from heard@pobox.com) X-Authentication-Warning: shell4.bayarea.net: heard owned process doing -bs Date: Tue, 30 Oct 2001 08:15:42 -0800 (PST) From: "C. M. Heard" X-Sender: heard@shell4.bayarea.net To: ifmib@ietf.org cc: snmp2jassi Subject: Re: [ifmib] about LinkUp/LinkDown traps. In-Reply-To: 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-Mailman-Version: 1.0 Precedence: bulk List-Id: IETF Interfaces MIB working group mailing list. X-BeenThere: ifmib@ietf.org On Tue, 30 Oct 2001, snmp2jassi (Jassi) wrote: > Content-Type: multipart/alternative; > boundary="----=_NextPart_000_0069_01C16158.F8C3C380" It would be considerate to turn off the HTML and set line wrap at or before column 76 when posting to IETF mailing lists. > I am implementing rfc2863 and i am having problems in deciding about "Link > Up/Down Trap generation" in case of Interface going from up/down state. > > I am presently having ifEntry for PVC's, SVC's, PPP, Gbit, DS3. At present > i have implemented only 2 values for ifOperStatus for the interfaces. > Please guide me when all do i need to generate Link up/down traps in my > case. All the interfaces comes up with a default value of "down". Do i > need to generate a LinkDown trap at that time? This is covered in RFC 2863 Section 3.1.15, "Traps". In particular, Therefore, this memo defines that LinkUp and linkDown traps are generated just after ifOperStatus leaves, or just before it enters, the down state, respectively; except that LinkUp and linkDown traps are never generated on transitions to/from the notPresent state. For the purpose of deciding when these traps occur, the lowerLayerDown state and the down state are considered to be equivalent, i.e., there is no trap on transition from lowerLayerDown into down, and there is a trap on transition from any other state except down (and notPresent) into lowerLayerDown. Since the trap is sent on the up-to-down transition, no trap is sent at startup time if the interface is initialized to the down state. Mike _______________________________________________ ifmib mailing list ifmib@ietf.org http://www1.ietf.org/mailman/listinfo/ifmib From ifmib-admin@ietf.org Tue Oct 30 14:03:38 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11483; Tue, 30 Oct 2001 14:03:34 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA14812; Tue, 30 Oct 2001 14:00:21 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA14796 for ; Tue, 30 Oct 2001 14:00:20 -0500 (EST) Received: from babbler.bmc.com (camaro.bmc.com [198.207.223.231]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11384 for ; Tue, 30 Oct 2001 14:00:16 -0500 (EST) From: rpresuhn-lists@dorothy.bmc.com Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id f9UJ1ix02716 for ; Tue, 30 Oct 2001 13:01:45 -0600 (CST) Received: from dorothy.bmc.com (dorothy.bmc.com [192.146.153.65]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with SMTP id KAA00974 for ; Tue, 30 Oct 2001 10:58:20 -0800 (PST) Date: Tue, 30 Oct 2001 10:58:20 -0800 (PST) Message-Id: <200110301858.KAA00974@dorothy.bmc.com> To: ifmib@ietf.org Subject: Re: [ifmib] convert log to MIB in linux. Sender: ifmib-admin@ietf.org Errors-To: ifmib-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: IETF Interfaces MIB working group mailing list. X-BeenThere: ifmib@ietf.org Hi - > Message-ID: <063301c161bd$c2cea3c0$4802a8c0@liaojian> > From: "zhu ming" > To: > References: <200110261600.MAA01038@optimus.ietf.org> > Date: Tue, 30 Oct 2001 19:40:17 -0800 .. > I want to convert some information of a log file into a MIB on linux. And > then others can get the information by using remote SNMP query. > > The log file looks like this: > time-stamp host-name device-name device-status > > E.g.: > > Oct 01 00:02 server1 SYS STATUS: UP, OK > Oct 01 00:02 server2 PS0: UP, OK > > Pls give me a hand on this issue, > i.e. the detail steps to do that or any useful documentation/url. .. Closely related work for logging of SNMP notifications has been done in the IETF disman working group. The working group charter is at http://www.ietf.org/html.charters/disman-charter.html In particular, you should review RFC 3014, as well as the current work in progress on alarm management. Additional relevant information on logging can be found at http://www.ietf.org/html.charters/syslog-charter.html ------------------------------------------------------ Randy Presuhn BMC Software, Inc. 1-3141 randy_presuhn@bmc.com 2141 North First Street Tel: +1 408 546-1006 San José, California 95131 USA ------------------------------------------------------ My opinions and BMC's are independent variables. ------------------------------------------------------ _______________________________________________ ifmib mailing list ifmib@ietf.org http://www1.ietf.org/mailman/listinfo/ifmib From ifmib-admin@ietf.org Tue Oct 30 16:24:47 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14793; Tue, 30 Oct 2001 16:24:47 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA19615; Tue, 30 Oct 2001 16:14:19 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA19595 for ; Tue, 30 Oct 2001 16:14:18 -0500 (EST) Received: from uniwest1.redstonecom.com ([65.194.140.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14457 for ; Tue, 30 Oct 2001 16:14:13 -0500 (EST) Received: by mailwest.unispherenetworks.com with Internet Mail Service (5.5.2653.19) id ; Tue, 30 Oct 2001 16:13:47 -0500 Message-ID: <49FF5C6DDBD8D311BBBD009027DE980C03613AAD@mailwest.unispherenetworks.com> From: "Perreault, Jason" To: "C. M. Heard" , ifmib@ietf.org Date: Tue, 30 Oct 2001 16:13:25 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [ifmib] lowerLayerDown == down for link trap generation (was RE: [ifmib] about LinkUp/LinkDown traps) Sender: ifmib-admin@ietf.org Errors-To: ifmib-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: IETF Interfaces MIB working group mailing list. X-BeenThere: ifmib@ietf.org In his reply to snmp2jassi re link traps, Mike says in part: > This is covered in RFC 2863 Section 3.1.15, "Traps". > In particular, > > Therefore, this memo defines that LinkUp and linkDown > traps are generated just after ifOperStatus leaves, or > just before it enters, the down state, respectively; > except that LinkUp and linkDown traps are never generated > on transitions to/from the notPresent state. FOR THE > PURPOSE OF DECIDING WHEN THESE TRAPS OCCUR, THE > lowerLayerDown STATE AND THE down STATE ARE CONSIDERED > TO BE EQUIVALENT, i.e., THERE IS NO TRAP ON TRANSITION > FROM lowerLayerDown INTO down, AND THERE IS A TRAP ON > TRANSITION FROM ANY OTHER STATE EXCEPT down (and > notPresent) INTO lowerLayerDown. [CAPS added by me for emphasis.] Does anyone else find this to be in conflict with 1) the interpretation of the corresponding section of RFC2233, which contains only the first of those two sentences; and 2) the DESCRIPTIONs of the linkUp/linkDown notifications themselves, which refer to "the" (not "a") down state? Had Mike not quoted this, I might never have noticed it. It is not among the changes described in RFC2863 Section 11, "Changes from RFC 2233". Because of the reference in that first sentence to "the" down state and similar language in the actual definitions of the link traps (all of which I took to be deliberate), I've always considered lowerLayerDown to be a pseudo-"up" state for purposes of link trap generation. This makes sense from the perspective of wanting to limit link trap generation to the lowest layer directly experiencing a fault. Affected higher layer interfaces (i.e. those in the lowerLayerDown state) could be identified by directed polling (e.g. ifInvStackTable). For what it's worth, the DESCRIPTIONs of ifOperStatus, linkUp, and linkDown are unchanged from RFC2233. If the behavior described in RFC2863 is truly intended, it's unfortunate the clarification was omitted from the MIB module itself. Jason Perreault Unisphere Networks _______________________________________________ ifmib mailing list ifmib@ietf.org http://www1.ietf.org/mailman/listinfo/ifmib From ifmib-admin@ietf.org Tue Oct 30 17:17:28 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15963; Tue, 30 Oct 2001 17:17:28 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA21209; Tue, 30 Oct 2001 17:11:16 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA21186 for ; Tue, 30 Oct 2001 17:11:15 -0500 (EST) Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15898 for ; Tue, 30 Oct 2001 17:11:09 -0500 (EST) Received: from localhost (heard@localhost) by shell4.bayarea.net (8.9.3/8.9.3) with ESMTP id OAA12253 for ; Tue, 30 Oct 2001 14:11:10 -0800 (envelope-from heard@pobox.com) X-Authentication-Warning: shell4.bayarea.net: heard owned process doing -bs Date: Tue, 30 Oct 2001 14:11:09 -0800 (PST) From: "C. M. Heard" X-Sender: heard@shell4.bayarea.net To: ifmib@ietf.org Subject: Re: [ifmib] lowerLayerDown == down for link trap generation In-Reply-To: <49FF5C6DDBD8D311BBBD009027DE980C03613AAD@mailwest.unispherenetworks.com> 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-Mailman-Version: 1.0 Precedence: bulk List-Id: IETF Interfaces MIB working group mailing list. X-BeenThere: ifmib@ietf.org On Tue, 30 Oct 2001, Perreault, Jason wrote: > In his reply to snmp2jassi re link traps, Mike says in part: > > > This is covered in RFC 2863 Section 3.1.15, "Traps". > > In particular, > > > > Therefore, this memo defines that LinkUp and linkDown > > traps are generated just after ifOperStatus leaves, or > > just before it enters, the down state, respectively; > > except that LinkUp and linkDown traps are never generated > > on transitions to/from the notPresent state. FOR THE > > PURPOSE OF DECIDING WHEN THESE TRAPS OCCUR, THE > > lowerLayerDown STATE AND THE down STATE ARE CONSIDERED > > TO BE EQUIVALENT, i.e., THERE IS NO TRAP ON TRANSITION > > FROM lowerLayerDown INTO down, AND THERE IS A TRAP ON > > TRANSITION FROM ANY OTHER STATE EXCEPT down (and > > notPresent) INTO lowerLayerDown. > > [CAPS added by me for emphasis.] > > Does anyone else find this to be in conflict with 1) the > interpretation of the corresponding section of RFC2233, which > contains only the first of those two sentences; and 2) the > DESCRIPTIONs of the linkUp/linkDown notifications themselves, > which refer to "the" (not "a") down state? I think this was intended to be a clarification of RFC 2233. My guess is that some of the interpretations varied, and this one was the "rough consensus" of the implementors. > Had Mike not quoted this, I might never have noticed it. > It is not among the changes described in RFC2863 Section 11, > "Changes from RFC 2233". It certainly should have been listed. > Because of the reference in that first sentence to "the" > down state and similar language in the actual definitions > of the link traps (all of which I took to be deliberate), > I've always considered lowerLayerDown to be a pseudo-"up" > state for purposes of link trap generation. > > This makes sense from the perspective of wanting to limit > link trap generation to the lowest layer directly experiencing > a fault. Affected higher layer interfaces (i.e. those in the > lowerLayerDown state) could be identified by directed polling > (e.g. ifInvStackTable). You have a point ... certainly it is common telecom practice (demanded, not just requested, by customers) to suppress all but "root cause" alarms. Not generating a trap on "lowerLayerDown" would be in keeping with that. Often this won't matter anyway -- in most of the MIB modules that use interface layering it is recommended that linkUpDownTrapEnable be set to false(2) when there is a lower layer (i.e., when the lowerLayerDown state applies). > For what it's worth, the DESCRIPTIONs of ifOperStatus, linkUp, > and linkDown are unchanged from RFC2233. If the behavior > described in RFC2863 is truly intended, it's unfortunate > the clarification was omitted from the MIB module itself. Well, there will be at least one more review before the IF-MIB goes to full standard. This issue should be raised at that time. Mike _______________________________________________ ifmib mailing list ifmib@ietf.org http://www1.ietf.org/mailman/listinfo/ifmib From ifmib-admin@ietf.org Tue Oct 30 20:20:15 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18193; Tue, 30 Oct 2001 20:20:14 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA24667; Tue, 30 Oct 2001 20:19:09 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA24644 for ; Tue, 30 Oct 2001 20:19:07 -0500 (EST) Received: from happy.omneon.local (omneon.com [216.216.222.85] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18178 for ; Tue, 30 Oct 2001 20:19:03 -0500 (EST) Received: from brunner2k ([10.1.1.13]) by happy.omneon.local with Microsoft SMTPSVC(5.0.2195.2966); Tue, 30 Oct 2001 17:14:17 -0800 Message-Id: <4.2.0.58.20011030170432.00aef348@happy> X-Sender: tbrunner@happy X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Tue, 30 Oct 2001 17:14:17 -0700 To: From: ted brunner Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 31 Oct 2001 01:14:18.0050 (UTC) FILETIME=[5CFC7220:01C161A9] Subject: [ifmib] (no subject) Sender: ifmib-admin@ietf.org Errors-To: ifmib-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: IETF Interfaces MIB working group mailing list. X-BeenThere: ifmib@ietf.org Due to repeated email bounces, suggesting that the accounts are gone, I will be deleting the following members from the ifmib mailing list unless I hear otherwise. faye@coppermountain.com jim.barnes@aptis.com gary@kentrox.com )jcurless@iol.unh.edu ted Ted Brunner tbrunner@Omneon.com Omneon Video Networks www.Omneon.com 15245 Greenbrier Pkwy (503) 533-0621x260 Beaverton OR 97006 (503) 533-5811 fax _______________________________________________ ifmib mailing list ifmib@ietf.org http://www1.ietf.org/mailman/listinfo/ifmib