How To Apply for and Win SSA Disability Benefits

From owner-atommib@thumper.bellcore.com Wed Jan 6 16:41:45 1999 Received: from thumper.bellcore.com (thumper.bellcore.com [128.96.41.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id QAA10915 for ; Wed, 6 Jan 1999 16:41:45 -0500 (EST) Received: from gtcns.grade.com.tw (gtcns.grade.com.tw [203.75.104.34]) by thumper.bellcore.com (8.9.1a/8.9.1) with SMTP id QAA12319 for ; Wed, 6 Jan 1999 16:26:20 -0500 (EST) From: ssdwin@home.com Received: by gtcns.grade.com.tw id AA07533; Thu, 7 Jan 1999 05:08:34 +0800 Message-Id: <199901062108.AA07533@gtcns.grade.com.tw> Mime-Version: 1.0 Date: 01/06/99 4:16:10 PM Pacific Daylight Time Reply-To: ssdwin@home.com To: ssdwin@home.com Subject: How To Win SSA Disability Benefits: 4th, Millennium Edition Content-Type: multipart/mixed; boundary="------------51A269FA31DF" This is a multi-part message in MIME format. --------------51A269FA31DF Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit ___________________________________________________________ Our research told us there is a high probability that you would be interested in the following. If you wish to be removed from future mailings, please reply with the subject "Remove" and this software will automatically block you from future mailings. Announcing publication of the 4th, Millennium Edition of "How To Apply for And Win Social Security Administration Disability Benefits." Written by a practicing SSA Disability advocate who has medical training, this easy-to- understand guide explains how to greatly increase the chances of winning no matter what the medical problems are. You'll discover what medical standards are used to determine disability, how pain severely compromises the ability to work, what symptoms are important to SSA, forms for your doctors to complete on arthritis, fibromyalgia, low back pain, chronic fatigue syndrome, diabetes, lupus, multiple sclerosis, mental problems, mental impairments, stroke, and much more. For a complete explanation of the guide's contents, please go to www.ssdwin.com. Fred Johnson ssdwin@home.com --------------51A269FA31DF Content-Type: text/html; charset=iso-8859-1; name="index.htm" Content -Transfer - Encoding: quoted -printable Content-Disposition: inline; filename="index.htm" Content-Base: "file:///E|/HotDog4/HotDog4/Webpage5/index.htm" How To Apply for and Win SSA Disability Benefits

"I was very impressed with your ability to explain this program in a very straightforward way and give a lot of good, common sense advice to unrepresented people. I also liked Chapter 7: Simplifying the Listings ."

Meyer Silver, Esq.
Law Offices Silver & Silver;
Past President National Organization of Social Security Claimants' Representatives

How To Apply For And Win Social Security Administration Disability Benefits

Frederick A. Johnson

This is the 4th, Millennium edition of the only manual written for the non-attorney ever published. Written by a practicing SSA Disability advocate who has medical training, this easy-to-understand guide explains how to greatly increase the chances of winning no matter! what the medical problems are. It reveals the standards of judgment SSA uses to determine disability and tells exactly what must be done to make it easy for SSA to grant benefits. The manual comes complete with all the forms needed to apply and get through the process. Quickly find:

What medical standards are used to determine disability;
How pain severely compromises the ability to work;
How the side effects from prescribed drugs can help win;
How to appeal a case;
What symptoms are important to SSA;
Rules to ignore at your peril;

4th, Millennium Edition
! Newly Revised And Updat ed
book

"How to Apply For And Win Social Security Administration Disability Benefits far exceeded my expectations. Everything was well organized and in one place. This publication made the system and medical standards easy to understand and gave me the confidence I needed to act on my own."
Al Workinger
former Senior Financial Administrator
Whirlpool Corporation

"Its simplicity and clarity astounded me…a gold mine. It's the most helpful book I've seen. The others obscure the issues."
Calvin Minkler
Pottstown, PA

How t! o get the best statements needed from doctors;
What is needed to qualify;

How much the benefits will be;

How to prepare for the hearing;

How long it takes to get through the process.

Single symptoms which are disabling;

Click here for Table Of Contents and Ordering Information

e-mail: ssdwin@home.com
Related URLThe Social Security Administration

This page last updated Sunday, December 6, 1998

This site hosted by

--------------51A269FA31DF-- From owner-atommib@thumper.bellcore.com Thu Jan 7 02:36:05 1999 Received: from thumper.bellcore.com (thumper.bellcore.com [128.96.41.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id CAA24572 for ; Thu, 7 Jan 1999 02:36:04 -0500 (EST) Received: from heartsnd.server (1Cust171.tnt24.sfo3.da.uu.net [208.255.67.171]) by thumper.bellcore.com (8.9.1a/8.9.1) with SMTP id CAA07158; Thu, 7 Jan 1999 02:20:34 -0500 (EST) From: ji4481@yahoo.com Message-Id: <199901070720.CAA07158@thumper.bellcore.com> Subject: re your internet site Date: Thu, 31 Dec 1998 07:46:34 We'll Submit Your Site To Over 900 Search Engines, Directories, & Indices For A "One Time Cost" Of Only $ 39.95 *** 100% Money Back Guarantee *** *** Immediately Increase Your Sites Exposure *** For Less Than 4 Cents Each We Will Submit Your Web Site To Over 900 Of The Net's Hottest Search Engines, Directories & Indices. If your site isn't listed in the Search Engines, how can people find you to buy your products or services? For just $39.95 we'll take the work load off your back instead of you trying to do it manually which can take days to do. We're the professionals that are here to help you have a shot at having a successful marketing experience with the internet. You know as well as we that your time is best utilized managing your business and not sitting at some keyboard hours upon hours trying to save less than 4 cents for each submission. See how it's kind of crazy to try to tackle this on your own. It's just not cost effective to try to do this yourself to save just $39.95. See why thousands and thousands of businesses world wide both large and small have come to us to utilize our services. Hotels, Motels, On-Line Stores, Travel Agents, Colleges, Universities, Governments, Fortune 500 companies, Movie Studios, Chambers Of Commerce and many, many more. Shouldn't you give us a call now? To Learn More, Call Us At The Numbers Below. Call us toll free at (800) 771-2003 in the USA and Canada or outside the USA at (916) 771-4739 and we'll provide you with all the necessary information to get you submitted Right Away. To be removed from our mailing list, please respond with the word remove in the subject. From owner-atommib@thumper.bellcore.com Mon Jan 11 07:57:56 1999 Received: from thumper.bellcore.com (thumper.bellcore.com [128.96.41.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id HAA16004 for ; Mon, 11 Jan 1999 07:57:55 -0500 (EST) Received: from ns10.nokia.com (ns10.nokia.com [131.228.6.229]) by thumper.bellcore.com (8.9.1a/8.9.1) with ESMTP id HAA23534 for ; Mon, 11 Jan 1999 07:43:32 -0500 (EST) Received: from msgws02ntc.ntc.nokia.com (msgws02ntc.ntc.nokia.com [131.228.59.182]) by ns10.nokia.com (8.8.8/8.6.9) with ESMTP id OAA08562 for ; Mon, 11 Jan 1999 14:43:30 +0200 (EET) Message-Id: <199901111243.OAA08562@ns10.nokia.com> Received: by msgws02ntc.ntc.nokia.com with Internet Mail Service (5.5.2232.9) id ; Mon, 11 Jan 1999 14:41:16 +0200 From: "Lochum Christian (NTC/Dusseld)" To: AToMdiscus Subject: questions to RFC1695 Date: Mon, 11 Jan 1999 13:45:00 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain Hello, I am SW designer and I have some questions regarding the interpretation of the standard. I tryed to follow the archive, but even there I didn't find the answer. I tryed to look at existing implementation and I even thought they are wrong. It would be realy helpful, if you could find the time to answer these questions. So here are the question: 1) Do I have to create an entry in the atmVplTable, before I can create an entry in the atmVclTable with the same VPI value? For example, if I want to terminate a single VCC, which is transported inside a VPC, that also is terminated inside my node. Do I have to create an entry at the atmVclTable and atmVplTable? In the Simple Times from august 1994 Volume 3, Number 2 Kaj Tesink wrote: "This article illustrates [..] the configuration of a VCC between hostA and hostB through on ISS. It assumes that the underlying VPLs are established." But in the new draft-ietf-atommib-atm1ng-06.txt it is defined: atmVplTable OBJECT-TYPE SYNTAX SEQUENCE OF AtmVplEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The Virtual Path Link (VPL) table. A bi-directional VPL is modeled as one entry in this table. This table can be used for PVCs, SVCs and Soft PVCs. Entries are not present in this table for the VPIs used by entries in the atmVclTable." ::= { atmMIBObjects 6} I think the interpretation has changed and I will only create an Entry for the VCC. Is this right? But, if you model it this way. How do you give the traffic params for the VPL? 2) If an entry is created in the atmVplTable and it is not cross connected is has an adminStatus, but if I later cross- connect this entry to another Vpl the adminStatus vanishes. But how is than the operStatus be invluenced. Should it follow the adminStatus of the according atmVpCrossConnection? Best regards Christian van Lochum From owner-atommib@thumper.bellcore.com Mon Jan 11 11:56:54 1999 Received: from thumper.bellcore.com (thumper.bellcore.com [128.96.41.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id LAA21269 for ; Mon, 11 Jan 1999 11:56:53 -0500 (EST) Received: from tbird.cc.bellcore.com (tbird.cc.bellcore.com [128.96.96.114]) by thumper.bellcore.com (8.9.1a/8.9.1) with SMTP id LAA06852 for ; Mon, 11 Jan 1999 11:43:24 -0500 (EST) Received: from joker ([128.96.91.46]) by tbird.cc.bellcore.com with SMTP id AA04138 (5.67b/IDA-1.5 for ); Mon, 11 Jan 1999 11:41:28 -0500 Received: from kaj-1 (nv-ktesink.cc.bellcore.com) by joker (4.1/4.7) id AA03092; Mon, 11 Jan 99 11:43:56 EST X-Station-Sent-From: joker.bellcore.com Message-Id: <4.1.19990111163528.00d13d70@joker.bellcore.com> X-Sender: kaj@joker.bellcore.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Mon, 11 Jan 1999 16:43:06 +0000 To: "Lochum Christian (NTC/Dusseld)" , AToMdiscus From: Kaj Tesink Subject: Re: questions to RFC1695 In-Reply-To: <199901111243.OAA08562@ns10.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Christian, the short answers: 1) yes, the interpretation has changed 2) i'm confused on the question see annotations below kaj ------------------------------------------ At 01:45 PM 1/11/99 +0200, Lochum Christian (NTC/Dusseld) wrote: >Hello, > >I am SW designer and I have some questions regarding the interpretation of >the standard. I tryed to follow the archive, but even there I didn't find >the answer. I tryed to look at existing implementation and I even thought >they are wrong. > >It would be realy helpful, if you could find the time to answer these >questions. >So here are the question: > >1) Do I have to create an entry in the atmVplTable, before I can create an >entry in the atmVclTable with the same VPI value? >For example, if I want to terminate a single VCC, which is transported >inside a VPC, that also is terminated inside my node. >Do I have to create an entry at the atmVclTable and atmVplTable? > >In the Simple Times from august 1994 Volume 3, Number 2 Kaj Tesink wrote: >"This article illustrates [..] the configuration of a VCC between hostA and >hostB through on ISS. It assumes that the underlying VPLs are established." > >But in the new draft-ietf-atommib-atm1ng-06.txt it is defined: > > atmVplTable OBJECT-TYPE > SYNTAX SEQUENCE OF AtmVplEntry > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "The Virtual Path Link (VPL) table. A > bi-directional VPL is modeled as one entry > in this table. This table can be used for > PVCs, SVCs and Soft PVCs. > Entries are not present in this table for > the VPIs used by entries in the atmVclTable." > > ::= { atmMIBObjects 6} > >I think the interpretation has changed and I will only create an Entry for >the VCC. >Is this right? yes that is correct > >But, if you model it this way. How do you give the traffic params for the >VPL? you dont - it may be difficult to correlate separate traffic param sets for a VCC and for the underlying VPL anyway. however, if you really want to do this then you would have to configure separate VPL and VCL entries. > >2) If an entry is created in the atmVplTable and it is not cross connected >is has an adminStatus, but if I later cross- connect this entry to another >Vpl the adminStatus vanishes. >But how is than the operStatus be invluenced. Should it follow the >adminStatus of the according atmVpCrossConnection? my confusion is perhaps the relationship with 1) (if any). if you use the VPL to support a VCL that is crossconnected in the next node you can not also start crossconnecting that VPL in the same node. > >Best regards > >Christian van Lochum > _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ Kaj Tesink Bellcore Email kaj@bellcore.com Tel 732.758.5254 Fax 732.758.2269 Postal 331 Newman Springs Rd Red Bank, NJ 07701 USA _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ From owner-atommib@thumper.bellcore.com Tue Jan 12 03:22:33 1999 Received: from thumper.bellcore.com (thumper.bellcore.com [128.96.41.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id DAA09376 for ; Tue, 12 Jan 1999 03:22:32 -0500 (EST) Received: from tlvsdy.vim.tlt.alcatel.it (tlvsdy.vim.tlt.alcatel.it [151.98.8.244]) by thumper.bellcore.com (8.9.1a/8.9.1) with SMTP id DAA21719 for ; Tue, 12 Jan 1999 03:10:45 -0500 (EST) Received: from tlvsca by tlvsdy.vim.tlt.alcatel.it (SMI-8.6/SMI-SVR4) id JAA10943; Tue, 12 Jan 1999 09:07:37 +0100 Received: from tlvqc8 by tlvsca (SMI-8.6/SMI-SVR4) id JAA26582; Tue, 12 Jan 1999 09:21:39 +0100 Date: Tue, 12 Jan 1999 09:04:59 +0100 From: Italo Busi Subject: Soft-PVC establishment To: AToMdiscuss X-Mailer: Z-Mail Pro 6.2, NetManage Inc. [ZM62_16H] X-Priority: 3 (Normal) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=ISO-8859-1 Hi all, I would like to ask you something about soft-PVC establishment procedure. Reading the documentation (documents [1], [2], [3] and [4]) I have understood that soft-PVC establishment requires different procedures in the intermediate switches, in the originating switch and in the destination switch. We can consider for example the establishment of a soft-PVCC; the soft-PVPC case is analogous. 1) Intermediate Switch ---------------- | | NNI | Intermediate | NNI O-------------| |-------------O I/f a | Switch | I/f b | | ---------------- Figure 1: An intermediate switch of the soft-PVC Interfaces a and b are both NNI, as shown in Figure 1. We assume that the setup message comes in at I/f a and goes out at I/f b. According to documents [1] and [2] at least two tables have to be configured: - the VCL Table, to configure the VCLa in the i/f a and the VCLb in the i/f b - the SVCC Table, to configure the switched cross-connection between VCLa and VCLb. VCLa, VCLb and the cross-connection are configured by the switch itself during the call set-up process. VCLa is configured as "svcIncoming" VCLb is configured as "svcOutgoing" 2) Originating Switch ---------------- | | UNI | Originating | NNI O-------------| |-------------O I/f a | Switch | I/f b | | ---------------- Figure 2: Originating switch of the soft-PVC Interface a (the calling endpoint) is UNI and interface b is NNI, as shown in Figure 2. According to documents [1], [2] and [4] at least three tables have to be configured: - the VCL table, to configure the VCLa and the VCLb - the SVCC table, to configure the switched cross-connection; - the soft-PVCC table, to configure the soft-PVC parameters (destination i/f ATM address, VPI/VCI at the destination UNI, ...) The Network Manager (NM) configures the VCLa (in the VCL table) and the soft-PVC (in the soft-PVCC table). The switch by its own configures the VCLb (in the VCL table) and the cross-connection (in the SVCC table) during the setup procedures. VCLa is configured as "spvcInitiator" VCLb is configured as "svcOutgoing" 3) Destination Switch ---------------- | | NNI | Destination | UNI O-------------| |-------------O I/f a | Switch | I/f b | | ---------------- Figure 3: Destination switch of the soft-PVC Interface a is NNI and interface b (the called endpoint) is UNI, as shown in Figure 3. According to documents [1] and [2] at least two tables are needed: - the VCL table - the SVCC table We are sure that the switch on its own configures the VCLa (in the VCL table) and the cross-connection (in the SVCC table) during the setup procedure. VCLa is configured as "svcIncoming" VCLb is configured as "spvcTarget" It is not clear from the documentation WHO HAS TO CONFIGURE VCLb: the switch or the NM ? The NM has to send some kind of information to the destination switch in order to establish a soft-PVC ? References: [1] K. Tesink, "Definitions of Managed Objects for ATM Management" internet-draft (to replace RFC1695), draft-ietf-atommib-atm1ng-06 [2] F. Ly, "Definitions of Supplemental Managed Objects for ATM Management" internet-draft, draft-ietf-atommib-atm2-12 [3] ATM Forum, "PNNI 1.0", annex C "Soft-PVC Connection Procedures" af-pnni-0055.000 [4] ATM-Forum, "Soft-PVC MIB" af-pnni-0066.000 and the errata in the af-pnni-0081.000 Best Regards, Italo. ----------------------------------------------------------------- ---------------------- \ / Busi Italo \ / ALCATEL - TSD R&D \ / ADM System Group \ / \ / E-mail: Italo.Busi@tlt.alcatel.it \ / Tel. +39 039 686.9132 \ / Fax. +39 039 686.3590 \ / \ / Date 01/12/1999 \ / Time 08:40:05 \/ ----------------------------------------------------------------- From owner-atommib@thumper.bellcore.com Tue Jan 12 08:10:53 1999 Received: from thumper.bellcore.com (thumper.bellcore.com [128.96.41.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id IAA10901 for ; Tue, 12 Jan 1999 08:10:53 -0500 (EST) Received: from ns10.nokia.com (ns10.nokia.com [131.228.6.229]) by thumper.bellcore.com (8.9.1a/8.9.1) with ESMTP id HAA01198 for ; Tue, 12 Jan 1999 07:58:51 -0500 (EST) Received: from msgws02ntc.ntc.nokia.com (msgws02ntc.ntc.nokia.com [131.228.59.182]) by ns10.nokia.com (8.8.8/8.6.9) with ESMTP id OAA29496; Tue, 12 Jan 1999 14:58:43 +0200 (EET) Message-Id: <199901121258.OAA29496@ns10.nokia.com> Received: by msgws02ntc.ntc.nokia.com with Internet Mail Service (5.5.2232.9) id ; Tue, 12 Jan 1999 14:56:27 +0200 From: "Lochum Christian (NTC/Dusseld)" To: Kaj Tesink Cc: AToMdiscus Subject: Re: questions to RFC1695 Date: Tue, 12 Jan 1999 13:44:00 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Hello, thanks for the fast answer. see my remarks below Best regards Christian van Lochum ---------- >From: Kaj Tesink >To: Lochum Christian (NTC/Dusseld); AToMdiscus >Subject: Re: questions to RFC1695 >Date: Mon, Jan 11, 1999 6:43PM > >Christian, > >the short answers: >1) yes, the interpretation has changed >2) i'm confused on the question >see annotations below > >kaj > > ------------------------------------------ > >At 01:45 PM 1/11/99 +0200, Lochum Christian (NTC/Dusseld) wrote: >>Hello, >> >>I am SW designer and I have some questions regarding the interpretation of >>the standard. I tryed to follow the archive, but even there I didn't find >>the answer. I tryed to look at existing implementation and I even thought >>they are wrong. >> >>It would be realy helpful, if you could find the time to answer these >>questions. >>So here are the question: >> >>1) Do I have to create an entry in the atmVplTable, before I can create an >>entry in the atmVclTable with the same VPI value? >>For example, if I want to terminate a single VCC, which is transported >>inside a VPC, that also is terminated inside my node. >>Do I have to create an entry at the atmVclTable and atmVplTable? >> >>In the Simple Times from august 1994 Volume 3, Number 2 Kaj Tesink wrote: >>"This article illustrates [..] the configuration of a VCC between hostA and >>hostB through on ISS. It assumes that the underlying VPLs are established." >> >>But in the new draft-ietf-atommib-atm1ng-06.txt it is defined: >> >> atmVplTable OBJECT-TYPE >> SYNTAX SEQUENCE OF AtmVplEntry >> MAX-ACCESS not-accessible >> STATUS current >> DESCRIPTION >> "The Virtual Path Link (VPL) table. A >> bi-directional VPL is modeled as one entry >> in this table. This table can be used for >> PVCs, SVCs and Soft PVCs. >> Entries are not present in this table for >> the VPIs used by entries in the atmVclTable." >> >> ::= { atmMIBObjects 6} >> >>I think the interpretation has changed and I will only create an Entry for >>the VCC. >>Is this right? > >yes that is correct Okay thank you. > >> >>But, if you model it this way. How do you give the traffic params for the >>VPL? > >you dont - it may be difficult to correlate separate traffic param sets for a >VCC and for the underlying VPL anyway. however, if you really want to do >this then you would have to configure separate VPL and VCL entries. > >> >>2) If an entry is created in the atmVplTable and it is not cross connected >>is has an adminStatus, but if I later cross- connect this entry to another >>Vpl the adminStatus vanishes. >>But how is than the operStatus be invluenced. Should it follow the >>adminStatus of the according atmVpCrossConnection? > >my confusion is perhaps the relationship with 1) (if any). >if you use the VPL to support a VCL that is crossconnected in the next node >you can not also start crossconnecting that VPL in the same node. > There is no relationship, sorry. I try to make it clearer. As far as I understood the creation mechanism of the atmVplTable of the RFC1695, the operator will create entries in this table for Vpls, that terminate a Vpc and for Vpls, that are cross connected. When he creates one entry he knows what he wants to do with it, but he can not tell the table, therefor after creation the entries look equal, they have an atmVplAdminStatus and no atmVplCrossConnectIdentifier. If the Vpl represented by an entry is cross connected (used in the atmVplCrossConnectTable), the atmVplAdminStatus vanishes and the atmVplCrossConnectIdentifier pops up. But the question is now, what is the value of the atmVplOperStatus? Will it follow the atmVplCrossConnectAdminStatus? That means, if the operator sets the atmVplCrossConnectAdminStatus to up and the node is working and able to make it operational, will the atmVpCrossConnectL2HOperStatus, atmVpCrossConnectH2LOperStatus and the atmVplOperStatus of the cross connected Vpls go up? Another question: Is it not allowed to use an atmVplTalbeEntry with an atmVplAdminStatus = up in a cross connection, because putting the atmVplAdminStatus to up means in my understanding, that the operator want to terminate the Vpl and with this the Vpc? > >> >>Best regards >> >>Christian van Lochum >> > > > > >_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ > >Kaj Tesink >Bellcore >Email kaj@bellcore.com >Tel 732.758.5254 >Fax 732.758.2269 >Postal 331 Newman Springs Rd > Red Bank, NJ 07701 > USA > >_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ > > From owner-atommib@thumper.bellcore.com Tue Jan 12 13:46:57 1999 Received: from thumper.bellcore.com (thumper.bellcore.com [128.96.41.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id NAA21607 for ; Tue, 12 Jan 1999 13:46:55 -0500 (EST) Received: from foxhound.cisco.com (foxhound.cisco.com [171.69.192.161]) by thumper.bellcore.com (8.9.1a/8.9.1) with ESMTP id NAA20799 for ; Tue, 12 Jan 1999 13:37:58 -0500 (EST) Received: from localhost (mspiegel@localhost) by foxhound.cisco.com (8.8.4-Cisco.1/8.6.5) with SMTP id KAA16713; Tue, 12 Jan 1999 10:33:56 -0800 (PST) Message-Id: <199901121833.KAA16713@foxhound.cisco.com> To: Italo Busi cc: AToMdiscuss Subject: Re: Soft-PVC establishment In-reply-to: Your message of "Tue, 12 Jan 1999 09:04:59 +0100." Date: Tue, 12 Jan 1999 10:33:55 -0800 From: Mickey Spiegel Italo, See replies at the bottom. > I would like to ask you something about soft-PVC establishment procedure. > > Reading the documentation (documents [1], [2], [3] and [4]) I have understood that soft-PVC establishment requires different procedures in the intermediate switches, in the originating switch and in the destination switch. > We can consider for example the establishment of a soft-PVCC; the soft-PVPC case is analogous. > > 1) Intermediate Switch > > ---------------- > | | > NNI | Intermediate | NNI > O-------------| |-------------O > I/f a | Switch | I/f b > | | > ---------------- > > Figure 1: An intermediate switch of the soft-PVC > > Interfaces a and b are both NNI, as shown in Figure 1. We assume that the setup message comes in at I/f a and goes out at I/f b. > According to documents [1] and [2] at least two tables have to be configured: > - the VCL Table, to configure the VCLa in the i/f a and the VCLb in the i/f b > - the SVCC Table, to configure the switched cross-connection between VCLa and VCLb. > VCLa, VCLb and the cross-connection are configured by the switch itself during the call set-up process. > VCLa is configured as "svcIncoming" > VCLb is configured as "svcOutgoing" > > 2) Originating Switch > > ---------------- > | | > UNI | Originating | NNI > O-------------| |-------------O > I/f a | Switch | I/f b > | | > ---------------- > > Figure 2: Originating switch of the soft-PVC > > Interface a (the calling endpoint) is UNI and interface b is NNI, as shown in Figure 2. > According to documents [1], [2] and [4] at least three tables have to be configured: > - the VCL table, to configure the VCLa and the VCLb > - the SVCC table, to configure the switched cross-connection; > - the soft-PVCC table, to configure the soft-PVC parameters (destination i/f ATM address, VPI/VCI at the destination UNI, ...) > The Network Manager (NM) configures the VCLa (in the VCL table) and the soft-PVC (in the soft-PVCC table). The switch by its own configures the VCLb (in the VCL table) and the cross-connection (in the SVCC table) during the setup procedures. > VCLa is configured as "spvcInitiator" > VCLb is configured as "svcOutgoing" > > 3) Destination Switch > > ---------------- > | | > NNI | Destination | UNI > O-------------| |-------------O > I/f a | Switch | I/f b > | | > ---------------- > > Figure 3: Destination switch of the soft-PVC > > Interface a is NNI and interface b (the called endpoint) is UNI, as shown in Figure 3. > According to documents [1] and [2] at least two tables are needed: > - the VCL table > - the SVCC table > We are sure that the switch on its own configures the VCLa (in the VCL table) and the cross-connection (in the SVCC table) during the setup procedure. > VCLa is configured as "svcIncoming" > VCLb is configured as "spvcTarget" > > It is not clear from the documentation WHO HAS TO CONFIGURE VCLb: the switch or the NM ? [3] allows both behaviors. You can support either one or both. If it is done via NM beforehand, use [1] to create the connection leg and set the atmVclConnKind to spvcTarget. > The NM has to send some kind of information to the destination switch in order to establish a soft-PVC ? or it can be done automatically. > References: > > [1] K. Tesink, "Definitions of Managed Objects for ATM Management" > internet-draft (to replace RFC1695), draft-ietf-atommib-atm1ng-06 > [2] F. Ly, "Definitions of Supplemental Managed Objects for ATM Management" > internet-draft, draft-ietf-atommib-atm2-12 > [3] ATM Forum, "PNNI 1.0", annex C "Soft-PVC Connection Procedures" > af-pnni-0055.000 > [4] ATM-Forum, "Soft-PVC MIB" > af-pnni-0066.000 and the errata in the af-pnni-0081.000 > > Best Regards, Italo. > > ----------------------------------------------------------------- > > ---------------------- > \ / Busi Italo > \ / ALCATEL - TSD R&D > \ / ADM System Group > \ / > \ / E-mail: Italo.Busi@tlt.alcatel.it > \ / Tel. +39 039 686.9132 > \ / Fax. +39 039 686.3590 > \ / > \ / Date 01/12/1999 > \ / Time 08:40:05 > \/ > > ----------------------------------------------------------------- Mickey Spiegel From owner-atommib@thumper.bellcore.com Tue Jan 12 13:51:21 1999 Received: from thumper.bellcore.com (thumper.bellcore.com [128.96.41.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id NAA21741 for ; Tue, 12 Jan 1999 13:51:21 -0500 (EST) Received: from kentrox.kentrox.com (IDENT:3kR63e/6jP7w4oCx7yOdFlwXmsXzecpb@kentrox.kentrox.com [192.228.59.2]) by thumper.bellcore.com (8.9.1a/8.9.1) with ESMTP id NAA21114 for ; Tue, 12 Jan 1999 13:44:11 -0500 (EST) Received: from kentrox.com ([146.71.112.126]) by kentrox.kentrox.com (8.9.0/8.9.0) with SMTP id KAA19520; Tue, 12 Jan 1999 10:44:04 -0800 (PST) Received: from localhost by kentrox.com (4.1/SMI-4.1_KTX1.1) id AA16577; Tue, 12 Jan 99 10:44:02 PST Date: Tue, 12 Jan 1999 10:44:01 -0800 (PST) From: Gary Hanson To: Kaj Tesink , Mickey Spiegel Cc: atommib@thumper.bellcore.com Subject: Status of ATM2-MIB Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi Kaj and Mickey, There have been no changes to for just about 10 months now, and the ID technically has expired. So, what is the current status of the ATM2-MIB draft from your points of view? Has anybody expressed any desire to add more functionality to it, or to modify what is already there? If not, I would think that it would be worthwhile to have a WG Last-Call and have it go up to the IESG for quality review. Regards, Gary From owner-atommib@thumper.bellcore.com Wed Jan 13 01:54:41 1999 Received: from thumper.bellcore.com (thumper.bellcore.com [128.96.41.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id BAA01808 for ; Wed, 13 Jan 1999 01:54:40 -0500 (EST) From: owner-atommib@thumper.bellcore.com Received: from atalaia.transnet.com.br (atalaia.transnet.com.br [200.241.50.1]) by thumper.bellcore.com (8.9.1a/8.9.1) with SMTP id BAA17128; Wed, 13 Jan 1999 01:44:20 -0500 (EST) Received: from gamma (unverified [153.37.136.244]) by atalaia.transnet.com.br (EMWAC SMTPRS 0.83) with SMTP id ; Wed, 13 Jan 1999 02:42:09 -0300 Date: Wed, 13 Jan 1999 02:42:09 -0300 Message-ID: To: guy-99@usa.net Subject: Re: Information You Requested "NET-DETECTIVE-4.0" EASY WAY TO FIND OUT ANYTHING ABOUT ANYONE Net Detective Click http://www.eternitypc.com/netinfo/detective/index4.html To Visit Our Web Page WHAT IS "NET DETECTIVE"? It is an amazing tool that allows you to find EVERYTHING you ever wanted to know about your EMPLOYEES, FRIENDS, RELATIVES, SPOUSE, NEIGHBORS, even your BOSS! You can check out ANYONE, ANYTIME, ANYWHERE, right on the internet... You can even check out YOURSELF! Here are a few examples of uses for this wonderful tool: *Locate e-mail, telephone or addresses. Check for UNLISTED phone numbers! * FIND DEBTORS and locate HIDDEN ASSETS. * Locate old classmates, missing family member, or LONG LOST LOVE. * Investigate your family history, birth, death and SOC.SEC RECORDS! * Verify your own CREDIT REPORTS so you can correct WRONG information. * Check ADOPTION records, locate MISSING CHILDREN or relatives. * Check out your new LOVE INTEREST! * Discover EMPLOYMENT opportunities from AROUND THE WORLD! * Check EMPLOYEES BEFORE you hire. * Check your phones for wire taps. * Discover if the FBI has a file on YOU! AND get a COPY of your file. BE SURE to check your own credit reports so you can correct WRONG information that may be used against you to deny you credit. Net Detective is so EASY TO USE even computer novices find it a snap. WHAT DOES IT COST? JUST $25 total. We are so sure you will find Net Detective a useful tool it comes with an UNCONDITIONAL 100% GUARANTEE! HERE'S THE BEST PART: You can have this wonderful tool in your hands is just 60 seconds. Just follow the instructions below for INSTANT DELIVERY! FREE BONUS! You will also receive, as a special FREE BONUS, a copy of our INVESTIGATIVE SOURCES PROGRAM with its own Windows/Win95 interface. Used by investigators across the country. WAIT THERE'S MORE! Order now, and as a SECOND FREE BONUS we will include the latest-toughest industrial strength SECURITY ENCRYPTION SOFTWARE available. Now you can HIDE ANYTHING on your computer. Easy to use. Protects your privatefiles from children, spouses, friends, bosses. Perfect for home and business! Remember, Net Detective comes with an UNCONDITIONAL GUARANTEE. YOU CAN'T LOSE! HOW TO ORDER! Ordering is SAFE and EASY! For more info or to INSTANTLY RECEIVE this useful tool by e-mail within 60 SECONDS just go to our INSTANT-DELIVERY SECURE ORDER FORM at: Net Detective Click Here To Visit Our Web Page-Order Form OR use FAX-MAIL-ORDER FORM BELOW. ORDER NOW! WE GUARANTEE YOU'LL BE GLAD YOU DID! Thanks, Jean Rousseau, Rousseau Group, Security Software Developers ______________________________________ FAX OR MAIL ORDER FORM FAX TO: Rousseau Group, 1-904-736-3882 OR MAIL TO: Rousseau Group 700 Vassar Rd., #3 Deland, Fl., 32724 Hi: Here is my order for "NET-DETECTIVE-4.0" at $25 total, which is unconditionally guaranteed and will be deliver by EMAIL. Include my FREE BONUS copy of INVESTIGATIVE SOURCES--WINDOWS/WIN95, and CRYPTO-VAULT encryption software. ( )Send by EMAIL ASAP. ( )Make me a disk and send it to me. Add $10 to my charge for the cost. NAME:_______________________________________________ E-MAIL ADDRESS:_________________________________________________________ (VERY IMPORTANT: PLEASE double check your address and PRINT CLEARLY) MAIL ADDRESS (for disk):_______________________________________________ CITY, STATE & ZIP___________________________________________ PAYMENT METHOD (check one) ___ Credit card, ___ Check or Money Order Enclosed, ___ Fax Check (copy of check must be attached). To order by credit card fill out the following: CARD TYPE:___________ CARDNUMBER:_____________________________________ NAME ON CARD:_________________________ EXPIRATION DATE:______________ SIGNATURE:_____________________________________ Your order will be sent ASAP. Thanks again for ordering! Jean Rousseau Rousseau Group Security Software Developers ----------------------------- Reply to with REMOVE in the subject line to be removed thank you. ------------------------------ From owner-atommib@thumper.bellcore.com Wed Jan 13 13:51:34 1999 Received: from thumper.bellcore.com (thumper.bellcore.com [128.96.41.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id NAA15358 for ; Wed, 13 Jan 1999 13:51:31 -0500 (EST) Received: from kentrox.kentrox.com (IDENT:KtXDOaFjFrP23OEQ+8k/U/Bt4Lm2o70C@kentrox.kentrox.com [192.228.59.2]) by thumper.bellcore.com (8.9.1a/8.9.1) with ESMTP id NAA10462 for ; Wed, 13 Jan 1999 13:30:55 -0500 (EST) Received: from kentrox.com ([146.71.112.126]) by kentrox.kentrox.com (8.9.0/8.9.0) with SMTP id KAA05251 for ; Wed, 13 Jan 1999 10:30:53 -0800 (PST) Received: from localhost by kentrox.com (4.1/SMI-4.1_KTX1.1) id AA17028; Wed, 13 Jan 99 10:30:51 PST Date: Wed, 13 Jan 1999 10:30:51 -0800 (PST) From: Gary Hanson Reply-To: Gary Hanson To: atommib@thumper.bellcore.com Subject: Support for "split" unidirectional flows in ATM-MIBs Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi atommibers, David Horton's recent question about unidirectional connections reminded me about an issue that may be worth resolving in the ATM-MIB, ATM-TC-MIB, and ATM2-MIB, which is support for what I would call "split" unidirectional flows. One example of this is what I would call a "chained" connection. When a manager wants to configure a unidirectional connection from VCL1 on ATM interface 1 to VCL2 on ATM interface 2, and another from that same VCL2 on ATM interface 2 to VCL3 on ATM interface 3, how would the ATM-MIB be used to represent this type of "chained" VCC (i.e., one which goes from one ATM port to another, gets looped back in that second port, and then goes to a third port)? ____________________ | | | ATM Switch | | | VCL1 | I/F 1 I/F 2 | VCL2 O--->---|--->------------>---|--->---O | +----<---|---<---O | | | | v | | | I/F 3 | VCL3 | +---->---|--->---O | | |____________________| To justify the need for this type of chained connection, consider its usefulness during EMI testing, when a cell stream can flow out each ATM port in turn, travelling down and back one meter of cable attached to each port, all without external equipment attached. I have also heard of other cases where users have wanted to solve various topological problems in their networks by configuring one VCL (or VPL) that crossconnects to two different VCLs (or VPLs) in the ingress and egress directions. While these topologies may thus be useful, the ATM-MIB does not seem to support them, since there exists neither a way to indicate that a bidirectional VCL is to be used by two different cross-connects (one for ingress and one for egress), nor any way to indicate that an inherently bidirectional cross-connect uses only the ingress or the egress bandwidth (but not both) of a VCL. If others believe it important to support this kind of usage, one reasonable solution that comes to mind is to extend the ATM-MIB, ATM-TC-MIB, and ATM2-MIB as follows: (a) Add an object to the VPL and VCL table entries to indicate the identifier of an additional cross-connection that is supported by the VPL or VCL, so that a VPL or VCL can reference one OR two cross-connections. I would add the following objects to the ATM-MIB: atmVplCrossConnectIdentifier2 OBJECT-TYPE SYNTAX INTEGER (0..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "This object is instantiated only for a VPL which is cross-connected to other VPLs that belong to the same VPC. If the VPL belongs to a single VPC, this object has the same value (and semantics) as the atmVplCrossConnectIdentifier value in the same atmVplEntry. If the VPL belongs to two different VPCs (i.e., one flowing in the receive direction and one flowing in the transmit direction), then the atmVplCrossConnectIdentifier value refers to the VPC flowing in the receive direction of this VPL, and this object (i.e., the atmVplCrossConnectIdentifier2 value) refers to the VPC flowing in the transmit direction of this VPL." ::= { atmVplEntry 11 } atmVclCrossConnectIdentifier2 OBJECT-TYPE SYNTAX INTEGER (0..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "This object is instantiated only for a VCL which is cross-connected to other VCLs that belong to the same VCC. If the VCL belongs to a single VCC, this object has the same value (and semantics) as the atmVclCrossConnectIdentifier value in the same atmVclEntry. If the VCL belongs to two different VCCs (i.e., one flowing in the receive direction and one flowing in the transmit direction), then the atmVclCrossConnectIdentifier value refers to the VCC flowing in the receive direction of this VCL, and this object (i.e., the atmVclCrossConnectIdentifier2 value) refers to the VCC flowing in the transmit direction of this VCL." ::= { atmVclEntry 16 } (b) Add an object to the VP and VC cross-connection table entries to indicate whether the cross-connection is bidirectional, is unidirectional in the H2L direction or is unidirectional in the L2H direction. Such an object's default would presumably be bidirectional, to preserve interoperability with agents that don't support the other options. I would add the following TEXTUAL-CONVENTION to the ATM-TC-MIB: AtmConnFlowDirection ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The direction of flow for a given ATM crossconnect. bothDirections(1) The crossconnect allows bidirectional flow in the L2H (low-to-high) and the H2L (high-to-low) directions, unless unidirectional flow is specified for a virtual link entry on either the low or high side(s) of the crossconnect. onlyL2HDirection(2) The crossconnect allows unidirectional flow in the L2H direction only. onlyH2LDirection(3) The crossconnect allows unidirectional flow in the H2L direction only. SYNTAX INTEGER { bothDirections(1), onlyL2HDirection(2), onlyH2LDirection(3) } I would also add the following objects to the ATM-MIB: atmVpCrossConnectFlowDirection OBJECT-TYPE SYNTAX AtmConnFlowDirection MAX-ACCESS read-create STATUS current DESCRIPTION "The direction(s) of flow specifically allowed on this crossconnect. Note that bidirectional flow specified for the crossconnect is always superceded by unidirectional flow specified for either (or both) VPLs." DEFVAL { bothDirections } ::= { atmVpCrossConnectEntry 12 } atmVcCrossConnectFlowDirection OBJECT-TYPE SYNTAX AtmConnFlowDirection MAX-ACCESS read-create STATUS current DESCRIPTION "The direction(s) of flow specifically allowed on this crossconnect. Note that bidirectional flow specified for the crossconnect is always superceded by unidirectional flow specified for either (or both) VCLs." DEFVAL { bothDirections } ::= { atmVcCrossConnectEntry 14 } Finally, I would add the following objects to the ATM2-MIB: atmSvcVpCrossConnectFlowDirection OBJECT-TYPE SYNTAX AtmConnFlowDirection MAX-ACCESS read-create STATUS current DESCRIPTION "The direction(s) of flow specifically allowed on this crossconnect. Note that bidirectional flow specified for the crossconnect is always superceded by unidirectional flow specified for either (or both) VPLs." DEFVAL { bothDirections } ::= { atmSvcVpCrossConnectEntry 8 } atmSvcVcCrossConnectFlowDirection OBJECT-TYPE SYNTAX AtmConnFlowDirection MAX-ACCESS read-create STATUS current DESCRIPTION "The direction(s) of flow specifically allowed on this crossconnect. Note that bidirectional flow specified for the crossconnect is always superceded by unidirectional flow specified for either (or both) VCLs." DEFVAL { bothDirections } ::= { atmSvcVcCrossConnectEntry 10 } I know that the ATM-TC-MIB draft is in IESG review, but the ATM-MIB draft is back in Kaj's hands, and the ATM2-MIB is still wide open for comments. I'd also settle for any compromise short of getting a new TEXTUAL-CONVENTION put into the ATM-TC-MIB, in order to allow standard support of this capability. Comments? (Has anybody supported this capability differently?) Regards, Gary ______ | /// | TM Gary Hanson gary@kentrox.com | ADC|Kentrox 14375 NW Science Park Dr. 503-641-3321 (FAX) |______| Portland, Oregon 97229 800-733-5511 x6333 From owner-atommib@thumper.bellcore.com Thu Jan 14 02:40:18 1999 Received: from thumper.bellcore.com (thumper.bellcore.com [128.96.41.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id CAA04085 for ; Thu, 14 Jan 1999 02:40:18 -0500 (EST) Received: from twimers.server (1Cust169.tnt24.sfo3.da.uu.net [208.255.67.169]) by thumper.bellcore.com (8.9.1a/8.9.1) with SMTP id CAA07654; Thu, 14 Jan 1999 02:30:09 -0500 (EST) From: tare9400@yahoo.com Message-Id: <199901140730.CAA07654@thumper.bellcore.com> Subject: ...re your internet site Date: Thu, 7 Jan 1999 07:55:54 We'll Submit Your Site To Over 900 Search Engines, Directories, & Indices For A "One Time Cost" Of Only $ 39.95 *** 100% Money Back Guarantee *** *** Immediately Increase Your Sites Exposure *** For Less Than 4 Cents Each We Will Submit Your Web Site To Over 900 Of The Net's Hottest Search Engines, Directories & Indices. If your site isn't listed in the Search Engines, how can people find you to buy your products or services? For just $39.95 we'll take the work load off your back instead of you trying to do it manually which can take days to do. We're the professionals that are here to help you have a shot at having a successful marketing experience with the internet. You know as well as we that your time is best utilized managing your business and not sitting at some keyboard hours upon hours trying to save less than 4 cents for each submission. See how it's kind of crazy to try to tackle this on your own. It's just not cost effective to try to do this yourself to save just $39.95. See why thousands and thousands of businesses world wide both large and small have come to us to utilize our services. Hotels, Motels, On-Line Stores, Travel Agents, Colleges, Universities, Governments, Fortune 500 companies, Movie Studios, Chambers Of Commerce and many, many more. Shouldn't you give us a call now? To Learn More, Call Us At The Numbers Below. Call us toll free at (800) 771-2003 in the USA and Canada or outside the USA at (916) 771-4739 and we'll provide you with all the necessary information to get you submitted Right Away. To be removed from our mailing list, please respond with the word remove in the subject. From owner-atommib@thumper.bellcore.com Fri Jan 15 02:03:11 1999 Received: from thumper.bellcore.com (thumper.bellcore.com [128.96.41.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id CAA00715 for ; Fri, 15 Jan 1999 02:03:10 -0500 (EST) Received: from firewall.nec.com.au (firewall-user@firewall.nec.com.au [147.76.180.1]) by thumper.bellcore.com (8.9.1a/8.9.1) with ESMTP id BAA27177 for ; Fri, 15 Jan 1999 01:49:22 -0500 (EST) Received: by firewall.nec.com.au; id RAA03451; Fri, 15 Jan 1999 17:48:57 +1059 (EST) Received: from frodo.nec.com.au(147.76.52.2) via SMTP by mailhost.nec.com.au, id smtpd003445; Fri Jan 15 17:48:50 1999 Received: from necagmx.neca.nec.com.au (u6035.neca.nec.com.au [147.76.128.7]) by frodo.nec.com.au (8.8.8/8.8.8/Debian/GNU) with ESMTP id RAA15299 for ; Fri, 15 Jan 1999 17:49:09 +1100 Received: from warp.ssd.neca.nec.com.au (warp.ssd.neca.nec.com.au [147.76.48.65]) by necagmx.neca.nec.com.au (8.8.5/8.8.5) with ESMTP id RAA10012 for ; Fri, 15 Jan 1999 17:49:09 +1100 Received: from miracle.ssd.neca.nec.com.au (miracle.ssd.neca.nec.com.au [147.76.48.132]) by warp.ssd.neca.nec.com.au (8.8.3/8.6.12) with SMTP id RAA19757 for ; Fri, 15 Jan 1999 17:49:08 +1100 (EST) Reply-To: From: "Umberto Bonollo" To: Subject: RE: comments requested on http://www.ietf.org/internet-drafts/draft-ietf-atommib-atmhist-00.txt Date: Fri, 15 Jan 1999 17:49:05 +1100 Message-ID: <000001be4053$26086460$84304c93@miracle.ssd.neca.nec.com.au> 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.2106.4 In-Reply-To: <9812182108.AB12544@joker> Hi, I'd be interested in discussion and feedback on the following observations and questions: 1) The AToMMIB list seems to be leaning towards using the ATMF M4 MIB for ATM Performance Monitoring instead of the ATMHIST MIB. That's fine by me. 2) The ATM Test MIB is being looked at and relies on the IF Test MIB draft which expired but which was recently sent to everybody. The M4 MIB also has a table for carrying out tests. One question is do you think that ATM tests should be carried out using this M4 special purpose facility or should that portion of the M4 MIB not be implemented - replaced instead by the AToMMIB approach. 3) One of the things about the M4 MIB which I don't like is that it's not particularly modular. For example, the alarm tables and traps in M4 are modelled on TMN but are for ATM only whereas in the real TMN the alarm log structures are part of another separate generic model. 4) I have a list for implementing ATM management which looks something like this: ATM-MIB, AToMMIB Test MIB, M4 MIB, ATM2 MIB etc...My question here is how much of the M4 MIB should be implemented and how much should be left alone and dealt with by another standard MIB module such as those suggested in the AToMMIB WG? (of course, the ATM-MIB is imported and extended by the M4 MIB.) What list of MIB modules would be seen as being a consistent whole for ATM management? Regards, Umberto Bonollo (umberto@tsd.neca.nec.com.au) Senior Computer Scientist DSLAM Project Systems Software Department NEC Australia -----Original Message----- From: Kaj Tesink [mailto:kaj@bellcore.com] Sent: Saturday, 19 December 1998 8:07 To: atommib@thumper.bellcore.com Cc: kaj@joker.bellcore.com Subject: comments requested on http://www.ietf.org/internet-drafts/draft-ietf-atommib-atmhist-00.txt hi all, its time we decide on how to deal with draft-ietf-atommib-atmhist-00.txt. it has been posted for a long time and is about to expire. at the time, this spec was written to support work going on in the ATMF, but a status check revealed that currently: a) there is no ATMF MIB that uses the ATMHIST MIB (no IMPORTS or any other references) b) there is an ATMF MIB (M4) that covers similar functionality, but the ATMHIST has some stuff that M4 doesnot have (the oppposite is true too but that is not relevant for the question of what to do with the ATMHIST MIB). however, these extra functions are minor and could also be worked through an extension of the M4 MIB if the ATMF would determine the need. my own inclination is always to be suspicious about 'competing specs' since even if there are technical merits in the competing version you may only achieve market fragmentation or confusion by having both specs around. Gary Hanson produced an excellent detailed comparison that is attached below. my question to the list is whether there are folks who want to argue for retaining this spec and develop it further. in case of sufficient interest (and a volunteer editor) we should complete this soon. in the other case the draft will be expired. given off-line comments i got already i will interpret lack of comments as a vote to let the spec expire. any comments? kaj ----------------------------------------------------------------- Gary's analysis: In ATMHIST-MIB In ATM-FORUM-SNMP-M4-MIB -------------------------- ----------------------------------------- atmProtoCurrSuspect atmfM4CellProtoCurrSuspect (similar to above) atmfM4TcProtoCurrSuspect atmProtoCurrTimeElapsed atmfM4CellProtoCurrElapsedTime (similar) (similar to above) atmfM4TcProtoCurrElapsedTime (no equivalent) atmfM4CellProtoCurrSupprIntvls (also no equivalent) atmfM4TcProtoCurrSupprIntvls atmProtoCurrTotalCellIns (no equivalent) atmProtoCurrClp0CellIns (no equivalent) atmProtoCurrProtoErrors atmfM4CellProtoCurrProtoErrors (no equivalent) atmfM4CellProtoCurrInOAMCells atmProtoCurrDiscardHECViol atmfM4TcProtoCurrDiscardHECViol atmProtoHistIndex atmfM4CellProtoHistIndex (similar to above) atmfM4TcProtoHistIndex atmProtoHistEndTime atmfM4CellProtoHistElapsedTime (similar) (similar to above) atmfM4TcProtoHistElapsedTime atmProtoHistSuspect atmfM4CellProtoHistSuspect (similar to above) atmfM4TcProtoHistSuspect (no equivalent) atmfM4CellProtHistSupprIntvls (also no equivalent) atmfM4TcProtoHistSupprIntvls atmProtoHistTotalCellIns (no equivalent) atmProtoHistClp0CellIns (no equivalent) atmProtoHistProtoErrors atmfM4CellProtoHistProtoErrors (no equivalent) atmfM4CellProtoHistInOAMCells atmProtoHistDiscardHECViol atmfM4TcProtoHistDiscardHECViol atmVplCurrSuspect atmfM4VpUpcNpcCurrSuspect atmVplCurrTimeElapsed atmfM4VpUpcNpcCurrElapsedTime (similar) (no equivalent) atmfM4VpUpcNpcCurrSupprIntvls atmVplCurrTotalCellIns (= DiscardedCells + PassedCells) atmVplCurrClp0CellIns (= DiscardedClp0 + PassedClp0) atmVplCurrTotalDiscards atmfM4VpUpcNpcCurrDiscardedCells atmVplCurrClp0Discards atmfM4VpUpcNpcCurrDiscardedClp0 atmVplCurrTotalCellOuts atmfM4VpUpcNpcCurrPassedCells atmVplCurrClp0CellOuts atmfM4VpUpcNpcCurrPassedClp0 atmVplCurrTaggedOuts (no equivalent) atmVplHistIndex atmfM4VpUpcNpcHistIndex atmVplHistEndTime atmfM4VpUpcNpcHistElapsedTime (similar) atmVplHistSuspect atmfM4VpUpcNpcHistSuspect (no equivalent) atmfM4VpUpcNpcHistSupprIntvls atmVplHistTotalCellIns (= DiscardedCells + PassedCells) atmVplHistClp0CellIns (= DiscardedClp0 + PassedClp0) atmVplHistDiscardedCells atmfM4VpUpcHistDiscardedCells atmVplHistDiscardedClp0 atmfM4VpUpcHistDiscardedClp0 atmVplHistTotalCellOuts atmfM4VpUpcHistPassedCells atmVplHistClp0CellOuts atmfM4VpUpcHistPassedClp0 atmVplHistTaggedOuts (no equivalent) atmVclCurrSuspect atmfM4VcUpcNpcCurrSuspect atmVclCurrTimeElapsed atmfM4VcUpcNpcCurrElapsedTime (similar) (no equivalent) atmfM4VcUpcNpcCurrSupprIntvls atmVclCurrTotalCellIns (= DiscardedCells + PassedCells) atmVclCurrClp0CellIns (= DiscardedClp0 + PassedClp0) atmVclCurrTotalDiscards atmfM4VcUpcNpcCurrDiscardedCells atmVclCurrClp0Discards atmfM4VcUpcNpcCurrDiscardedClp0 atmVclCurrTotalCellOuts atmfM4VcUpcNpcCurrPassedCells atmVclCurrClp0CellOuts atmfM4VcUpcNpcCurrPassedClp0 atmVclCurrTaggedOuts (no equivalent) atmVclHistIndex atmfM4VcUpcNpcHistIndex atmVclHistEndTime atmfM4VcUpcNpcHistElapsedTime (similar) atmVclHistSuspect atmfM4VcUpcNpcHistSuspect (no equivalent) atmfM4VcUpcNpcHistSupprIntvls atmVclHistTotalCellIns (= DiscardedCells + PassedCells) atmVclHistClp0CellIns (= DiscardedClp0 + PassedClp0) atmVclHistDiscardedCells atmfM4VcUpcNpcHistDiscardedCells atmVclHistDiscardedClp0 atmfM4VcUpcNpcHistDiscardedClp0 atmVclHistTotalCellOuts atmfM4VcUpcNpcHistPassedCells atmVclHistClp0CellOuts atmfM4VcUpcNpcHistPassedClp0 atmVclHistTaggedOuts (no equivalent) _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ Kaj Tesink Bellcore Email kaj@bellcore.com Tel 732.758.5254 Fax 732.758.2269 Postal 331 Newman Springs Rd Red Bank, NJ 07701 USA _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ From owner-atommib@thumper.bellcore.com Sat Jan 16 06:10:41 1999 Received: from thumper.bellcore.com (thumper.bellcore.com [128.96.41.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id GAA14392 for ; Sat, 16 Jan 1999 06:10:40 -0500 (EST) Received: from mexnet01.mcsa.net.mx (mexnet01.mcsa.net.mx [200.33.47.216]) by thumper.bellcore.com (8.9.1a/8.9.1) with ESMTP id FAA17576 for ; Sat, 16 Jan 1999 05:58:13 -0500 (EST) From: mco6@mailcity.com Received: from mexpru.mcsa.net.mx ([200.33.47.221]) by mexnet01.mcsa.net.mx (8.8.5/SCO5) with ESMTP id EAA01505; Sat, 16 Jan 1999 04:57:08 -0600 (CST) Received: from jamie ([204.244.195.142]) by mexpru.mcsa.net.mx (8.8.5/SCO5) with SMTP id FAA16751; Sat, 16 Jan 1999 05:18:25 -0600 (CST) Date: Sat, 16 Jan 1999 05:18:25 -0600 (CST) Message-Id: <199901161118.FAA16751@mexpru.mcsa.net.mx> To: friend@exite.com Subject: Tyson vs Botha Wannna Bet! Feeling Lucky?? CASH IN ON thE FIGHT!!!! - http://209.67.19.99/want_to_bet/ TYSON V.s. BOTHA SATURDAY NIGHT JAN 16 9pm! REAL LIVE LAS VEGAS GAMBLING Place your bet online with up to the minute odds! Mike Tyson -750 Frans Botha +500 http://209.67.19.99/want_to_bet/ CLICK HERE to enter From owner-atommib@thumper.bellcore.com Fri Jan 22 00:00:15 1999 Received: from thumper.bellcore.com (thumper.bellcore.com [128.96.41.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id AAA07606 for ; Fri, 22 Jan 1999 00:00:15 -0500 (EST) From: owner-atommib@thumper.bellcore.com Received: from ns0.alter.it (ns0.alter.it [192.106.190.231]) by thumper.bellcore.com (8.9.1a/8.9.1) with ESMTP id XAA17880; Thu, 21 Jan 1999 23:46:11 -0500 (EST) Received: from gamma (1Cust222.tnt3.buffalo.ny.da.uu.net [153.34.91.222]) by ns0.alter.it (8.9.0/8.9.0) with SMTP id FAA27680; Fri, 22 Jan 1999 05:37:58 +0100 Date: Fri, 22 Jan 1999 05:37:58 +0100 Message-Id: <199901220437.FAA27680@ns0.alter.it> To: you989@usa.net Subject: Immediate Buy Alert! Thursday January 21st, Company Press Release African Resources, Inc. - Micro Cap - Ticker (AFRI) Company Litigating Against Nations's Third Largest Bank for Unauthorized Trading of Corporate Securities TORONTO--(BUSINESS WIRE)--Jan. 4, 1999--AFRICAN RESOURCES, INC. (OTC BB: AFRI) (AFRI) - a natural resource development company - with gold and diamond concessions located in the Republic of Guinea and gold mining operations in the State of Arizona - announced today, that it is preparing legal action against Chase Manhattan Bank - the nation's third largest bank for sustained damages as a result of unauthorized trading of the company's securities. On April 28, 1998, the company alleges that Chase Manhattan Bank engaged in unauthorized trading of 1,000,000 common shares of AFRI wherein the bank's securities division sold the stock into the open market within a 30 minute period - and depressed the trading value of the shares from $0.60/share to $0.01/share. At the time of the incident, the Company's tradable float was less than 600,000 common shares. The alleged unauthorized traded shares had been entrusted to the legal counsel of a credit facilitator that agreed to maintain the shares in escrow at Chase Manhattan Bank. The Bank allegedly executed the trade without receiving authorization from the account holder. Chase Manhattan Bank executives have failed to return the shares to the account holder, in spite of demands and refusal by the account holder to access the proceeds placed in the account from the sale of the 1,000,000 shares. Over 200 pages of supportive documentation, which the company and account holder believe clearly establishes the facts of this unauthorized transaction, have been reported to the Securities Exchange Commission. The account holder has made a formal demand for the return of the 1,000,000 shares. In the event of non-compliance by Chase Manhattan Bank, the account holder's attorneys intend to seek immediate relief from National Association of Securities Dealers (NASD) arbitration and the Initiation of a law suit against Chase Manhattan Bank. Mr. Rick Brodzik, president of AFRICAN RESOURCES, INC., stated: ``The Company and its shareholders have incurred severe harm by the alleged unauthorized trading action conducted by Chase Manhattan Bank and intends to file appropriate litigation in the courts - in support of the account holder - while seeking monetary restitution for loss of revenues and other damages caused by this irresponsible action.'' Mr. Brodzik went on to state, ``The Company's funding programs sustained a temporary set-back as a result of the trading price of the company's securities being plunged to an all-time low of $0.01/share. However, the Company is in the process of fiscal recovery via the completion of requisite funding programs to implement its gold and diamond mining operations - scheduled to go on-line in the near future. Contact: Newtrends International. Stuart Gray,- Canada & U.S. 1-888-990-9252 All other 250-712-9425 From owner-atommib@thumper.bellcore.com Fri Jan 22 12:21:42 1999 Received: from thumper.bellcore.com (thumper.bellcore.com [128.96.41.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id MAA23449 for ; Fri, 22 Jan 1999 12:21:41 -0500 (EST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by thumper.bellcore.com (8.9.1a/8.9.1) with ESMTP id MAA19595 for ; Fri, 22 Jan 1999 12:06:55 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id MAA23018; Fri, 22 Jan 1999 12:05:50 -0500 (EST) Message-Id: <199901221705.MAA23018@ietf.org> To: IETF-Announce: ; Cc: RFC Editor Cc: Internet Architecture Board Cc: atommib@thumper.bellcore.com From: The IESG Subject: Protocol Action: Definitions of Textual Conventions and OBJECT-IDENTITIES for ATM Management to Proposed Standard Date: Fri, 22 Jan 1999 12:05:50 -0500 Sender: scoya@ns.cnri.reston.va.us The IESG has approved the following Internet-Drafts for publication as Proposed Standards: o Definitions of Textual Conventions and OBJECT-IDENTITIES for ATM Management o Definitions of Managed Objects for ATM Management These documents are the product of the AToM MIB Working Group. The IESG contact person Jeffrey Burgan and Thomas Narten. Technical Summary draft-ietf-atommib-atm2TC-09.txt defines a set of Textual Conventions and OBJECT-IDENTITIES for MIB modules related to managing ATM-based interfaces, devices, networks and services. This document is expected to be used by MIB authors writing MIBs covering ATM-related technologies. draft-ietf-atommib-atm1ng-06.txt defines a MIB for managing ATM-based interfaces, devices, networks and services. This document updates and replaces RFC 1695. Working Group Summary There was consensus within the Working Group for this document and no issues were raised during the IETF Last Call. Protocol Quality This document was reviewed for the IESG by Keith McCloghrie. It has been further been reviewed by Bert Wijnen of the IESG. From owner-atommib@thumper.bellcore.com Fri Jan 22 12:27:46 1999 Received: from thumper.bellcore.com (thumper.bellcore.com [128.96.41.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id MAA23450 for ; Fri, 22 Jan 1999 12:21:42 -0500 (EST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by thumper.bellcore.com (8.9.1a/8.9.1) with ESMTP id MAA19695 for ; Fri, 22 Jan 1999 12:08:08 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id MAA23038; Fri, 22 Jan 1999 12:07:03 -0500 (EST) Message-Id: <199901221707.MAA23038@ietf.org> To: IETF-Announce: ; Cc: RFC Editor Cc: Internet Architecture Board Cc: atommib@thumper.bellcore.com From: The IESG Subject: Protocol Action: Accounting Information for ATM Networks to Proposed Standard Date: Fri, 22 Jan 1999 12:07:02 -0500 Sender: scoya@ns.cnri.reston.va.us The IESG has approved the following Internet-Drafts for publication as Proposed Standards: o Accounting Information for ATM Networks o Managed Objects for Controlling the Collection and Storage of Accounting Information for Connection-Oriented Networks These documents are the product of the AToM MIB Working Group. The IESG contact person Jeffrey Burgan and Thomas Narten. Technical Summary The document "Managed Objects for Controlling the Collection and Storage of Accounting Information for Connection-Oriented Networks" describes managed objects used for controlling the collection and storage of accounting information for connection-oriented networks such as ATM. Objects are defined in a manner that is independent of the specific type of network. The accounting data is collected into files for later retrieval via a file transfer protocol. The document "Accounting Information for ATM Networks" defines a set of ATM-specific accounting information which can be collected for connections on ATM networks. Working Group Summary The Working Group came to consensus and there were no significant changes as the result of the working group last call. Protocol Quality These documents were reviewed for the IESG by Kaj Tesink. They have been further been reviewed by Bert Wijnen, Jeffrey Burgan and Thomas Narten of the IESG. From owner-atommib@thumper.bellcore.com Wed Jan 27 04:32:03 1999 Received: from thumper.bellcore.com (thumper.bellcore.com [128.96.41.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id EAA21379 for ; Wed, 27 Jan 1999 04:32:03 -0500 (EST) Received: from static. ([192.215.160.85]) by thumper.bellcore.com (8.9.1a/8.9.1) with SMTP id EAA24688 for ; Wed, 27 Jan 1999 04:20:02 -0500 (EST) From: a2go@iw.net Received: from jamie by static. (SMI-8.6/SMI-SVR4) id BAA25122; Wed, 27 Jan 1999 01:24:47 -0800 Date: Wed, 27 Jan 1999 01:24:47 -0800 Message-Id: <199901270924.BAA25122@static.> To: user@aol.com Subject: Want to party Superbowl Sunday? Superbowl XXXIII - JANUARY 31, 1999 Dear Sports Fan, WIN BIG gives you the opportunity to make the game more exiting and profitable, with on line sportsbook. You can make a friendly wager on the SUPERBOWL or any other pro sporting event. Or play our many interactive casino games that come with our free sopftware package. Visa Mastercard and American Express accepted and for a limited time we are offering a complimentary 10% of your initial deposit added to your account upon sign-up ! Please visit our website for more info: http://209.67.19.98/casino_wow/ PLease contact casino_wow@yahoo.com if you have recieved this message in error. Thank you, and happy gaming! From owner-atommib@thumper.bellcore.com Fri Jan 29 01:23:16 1999 Received: from thumper.bellcore.com (thumper.bellcore.com [128.96.41.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id BAA16089 for ; Fri, 29 Jan 1999 01:23:15 -0500 (EST) Received: from static. ([192.215.160.85]) by thumper.bellcore.com (8.9.1a/8.9.1) with SMTP id BAA15159 for ; Fri, 29 Jan 1999 01:08:41 -0500 (EST) From: f5tw@hotmail.com Received: from jamie by static. (SMI-8.6/SMI-SVR4) id WAA08489; Thu, 28 Jan 1999 22:12:46 -0800 Date: Thu, 28 Jan 1999 22:12:46 -0800 Message-Id: <199901290612.WAA08489@static.> To: member@aol.com Subject: Cash in on Superbowl Sunday!! Superbowl XXXIII - JANUARY 31, 1999 Dear Sports Fan, WIN BIG gives you the opportunity to make the game more exiting and profitable, with our online sportsbook. You can make a friendly wager on the SUPERBOWL or any other pro sporting event. Or play our many interactive casino games that come with our free sopftware package. Visa Mastercard and American Express accepted and for a limited time we are offering a complimentary 10% of your initial deposit added to your account upon sign-up ! Please visit our website for more info: http://204.71.176.71/members6/game-online Please contact interrupt@hotmail.com if you have recieved this message in error. Thank you, and happy gaming! From owner-atommib@thumper.bellcore.com Fri Jan 29 10:19:00 1999 Received: from thumper.bellcore.com (thumper.bellcore.com [128.96.41.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id KAA29762 for ; Fri, 29 Jan 1999 10:18:59 -0500 (EST) Received: from srneris.server (1Cust37.tnt24.sfo3.da.uu.net [208.255.67.37]) by thumper.bellcore.com (8.9.1a/8.9.1) with SMTP id KAA08117; Fri, 29 Jan 1999 10:06:09 -0500 (EST) From: jun3728@yahoo.com Message-Id: <199901291506.KAA08117@thumper.bellcore.com> Subject: ..your web site Date: Fri, 22 Jan 1999 15:31:20 We'll Submit Your Site To Over 900 Search Engines, Directories, & Indices For A "One Time Cost" Of Only $ 39.95 *** 100% Money Back Guarantee *** *** Immediately Increase Your Sites Exposure *** For Less Than 4 Cents Each We Will Submit Your Web Site To Over 900 Of The Net's Hottest Search Engines, Directories & Indices. If your site isn't listed in the Search Engines, how can people find you to buy your products or services? For just $39.95 we'll take the work load off your back instead of you trying to do it manually which can take days to do. We're the professionals that are here to help you have a successful marketing experience with the internet. You know as well as we that your time is best utilized managing your business and not sitting at some keyboard hours upon hours trying to save less than 4 cents for each submission. it's alomst crazy to try to tackle this on your own. It's just not cost effective to try to do this yourself to save just $39.95. See why thousands of businesses from all over the world, both large and small, have come to us to utilize our services. Hotels, Motels, On-Line Stores, Travel Agents, Colleges, Universities, Governments, Fortune 500 companies, Movie Studios, Chambers Of Commerce and many, many more. Shouldn't you give us a call now? To Learn More, Visit Our Web Site By Double Clicking This Link: http://209.160.21.6/RESELLER.ASP?id=2017 Or call toll free in the USA/Canada (800) 771-2003 or outside the USA at (916) 771-4739. PLEASE MENTION AD# 2017 WHEN ORDERING. THANK YOU To be removed from our mailing list, please respond with the word remove in the subject. From owner-atommib@thumper.bellcore.com Fri Jan 29 11:44:05 1999 Received: from thumper.bellcore.com (thumper.bellcore.com [128.96.41.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id LAA02056 for ; Fri, 29 Jan 1999 11:44:05 -0500 (EST) Received: from tbird.cc.bellcore.com (tbird.cc.bellcore.com [128.96.96.114]) by thumper.bellcore.com (8.9.1a/8.9.1) with SMTP id LAA14098 for ; Fri, 29 Jan 1999 11:35:40 -0500 (EST) Received: from joker ([128.96.91.46]) by tbird.cc.bellcore.com with SMTP id AA27705 (5.67b/IDA-1.5 for ); Fri, 29 Jan 1999 11:28:16 -0500 Received: from kaj-1 (nv-ktesink.cc.bellcore.com) by joker (4.1/4.7) id AA08855; Fri, 29 Jan 99 11:30:48 EST X-Station-Sent-From: joker.bellcore.com Message-Id: <4.1.19990129162622.00f4b480@joker.bellcore.com> X-Sender: kaj@joker.bellcore.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Fri, 29 Jan 1999 16:29:54 +0000 To: atommib@thumper.bellcore.com, trunk-mib@external.cisco.com From: Kaj Tesink Subject: 15 Minute Counts and Continuous Counts Cc: WIJNEN@vnet.ibm.com, Harald@Alvestrand.no, narten@raleigh.ibm.com, kaj@bellcore.com, John Hawkinson Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Hi, During the Last Call process on the DS1/E1, DS3/E3 and SONET/SDH MIB I-Ds a comment was reiterated on whether the statistics in these MIBs can be represented through Counter32s (continuous counts). They are now all Gauge32s based on 15 minute measurements. While recognizing that these MIBs have historically used the 15 minute bucket approach the question was asked whether additional work on supplemental MIB(s) would be merited that would use Counter32s. The purpose of this message is to sollicit views on this issue. In particular: a) whether Supplemental MIB modules should support Counter32 statistics b) if the answer to a) would be yes, whether the conformance statement should mandate i) both approaches ii) either one of the approaches Kaj _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ Kaj Tesink Bellcore Email kaj@bellcore.com Tel 732.758.5254 Fax 732.758.2269 Postal 331 Newman Springs Rd Red Bank, NJ 07701 USA _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ From owner-atommib@thumper.bellcore.com Fri Jan 29 15:43:51 1999 Received: from thumper.bellcore.com (thumper.bellcore.com [128.96.41.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id PAA07732 for ; Fri, 29 Jan 1999 15:43:50 -0500 (EST) Received: from shultz.argon.com (shultz.argon.com [208.234.161.2]) by thumper.bellcore.com (8.9.1a/8.9.1) with ESMTP id PAA28777 for ; Fri, 29 Jan 1999 15:34:43 -0500 (EST) Received: from aruba (aruba.argon.com [208.234.161.60]) by shultz.argon.com (8.8.6/8.8.6) with SMTP id PAA14691; Fri, 29 Jan 1999 15:34:06 -0500 (EST) Message-Id: <3.0.32.19990129153300.009ea5f0@shultz.argon.com> X-Sender: kchapman@shultz.argon.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Fri, 29 Jan 1999 15:33:01 -0500 To: Kaj Tesink , atommib@thumper.bellcore.com, trunk-mib@external.cisco.com From: Ken Chapman Subject: Re: 15 Minute Counts and Continuous Counts Cc: WIJNEN@vnet.ibm.com, Harald@Alvestrand.no, narten@raleigh.ibm.com, kaj@bellcore.com, John Hawkinson Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" At 04:29 PM 1/29/99 +0000, Kaj Tesink wrote: >Hi, > >During the Last Call process on the DS1/E1, DS3/E3 and SONET/SDH MIB I-Ds >a comment was reiterated on whether the statistics in these MIBs can be >represented through Counter32s (continuous counts). >They are now all Gauge32s based on 15 minute measurements. >While recognizing that these MIBs have historically used the >15 minute bucket approach the question was asked whether additional work >on supplemental MIB(s) would be merited that would use Counter32s. > >The purpose of this message is to sollicit views on this issue. >In particular: >a) whether Supplemental MIB modules should support Counter32 statistics Yes >b) if the answer to a) would be yes, whether the conformance statement > should mandate > i) both approaches > ii) either one of the approaches ii One further thought: We should define a "generic" MIB for interval "gauges" that allows different intervals (e.g. 24 hours). It would then be able to provide interval histories for ANY well defined counter. Perhaps someone has already done some work on such a MIB? ================================================ Ken Chapman Argon Networks, Inc. tel: +1-978-486-0665 x146 25 Porter Road fax: +1-978-486-9379 Littleton, MA 01460 mailto:KChapman@Argon.com http://www.Argon.com ================================================ From owner-atommib@thumper.bellcore.com Fri Jan 29 20:24:22 1999 Received: from thumper.bellcore.com (thumper.bellcore.com [128.96.41.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id UAA14740 for ; Fri, 29 Jan 1999 20:24:22 -0500 (EST) Received: from webhost.withweb.com (IDENT:root@[210.120.50.128]) by thumper.bellcore.com (8.9.1a/8.9.1) with ESMTP id UAA13769 for ; Fri, 29 Jan 1999 20:16:29 -0500 (EST) Received: from t3host.com ([203.229.214.102]) by webhost.withweb.com (8.9.1a/8.9.1a) with SMTP id KAA20440 for ; Sat, 30 Jan 1999 10:19:09 +0900 Date: Sat, 30 Jan 1999 10:17:27 +0900 From: simple X-Mailer: The Bat! (v1.19) UNREG Reply-To: simple X-Priority: 3 (Normal) Message-ID: <6428.990130@clicks.co.kr> To: atommib@thumper.bellcore.com Subject: unsubscibe Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit unsubscribe From owner-atommib@thumper.bellcore.com Fri Jan 29 21:20:35 1999 Received: from thumper.bellcore.com (thumper.bellcore.com [128.96.41.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id VAA15446 for ; Fri, 29 Jan 1999 21:20:34 -0500 (EST) Received: from foxhound.cisco.com (foxhound.cisco.com [171.69.192.161]) by thumper.bellcore.com (8.9.1a/8.9.1) with ESMTP id VAA15869 for ; Fri, 29 Jan 1999 21:13:02 -0500 (EST) Received: (kzm@localhost) by foxhound.cisco.com (8.8.4-Cisco.1/8.6.5) id SAA23465; Fri, 29 Jan 1999 18:11:57 -0800 (PST) From: Keith McCloghrie Message-Id: <199901300211.SAA23465@foxhound.cisco.com> Subject: Re: 15 Minute Counts and Continuous Counts To: KChapman@Argon.com (Ken Chapman) Date: Fri, 29 Jan 1999 18:11:56 -0800 (PST) Cc: kaj@bellcore.com, atommib@thumper.bellcore.com, trunk-mib@external.cisco.com, WIJNEN@vnet.ibm.com, Harald@Alvestrand.no, narten@raleigh.ibm.com, jhawk@bbnplanet.com In-Reply-To: <3.0.32.19990129153300.009ea5f0@shultz.argon.com> from "Ken Chapman" at Jan 29, 99 03:33:01 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit > One further thought: We should define a "generic" MIB for interval "gauges" > that allows different intervals (e.g. 24 hours). It would then be able to > provide interval histories for ANY well defined counter. > Perhaps someone has already done some work on such a MIB? See the usrHistoryGroup in RFC 2021. Keith.