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 "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;
|
e-mail: ssdwin@home.com
Related URLThe Social Security Administration
This page last updated Sunday, December 6, 1998
This site hosted by
©1997-1998 March 3rd Books., All rightsreserved.
--------------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.