From owner-disman@dorothy.bmc.com  Wed Nov  1 12:30:44 2000
Received: from tattler.bmc.com (fw-us-hou-2.bmc.com [198.207.223.251])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA02752
	for <disman-archive@odin.ietf.org>; Wed, 1 Nov 2000 12:30:43 -0500 (EST)
Received: from dorothy.bmc.com (localhost [127.0.0.1])
	by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id eA1HQW919990;
	Wed, 1 Nov 2000 11:26:32 -0600 (CST)
Received: (from root@localhost)
	by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id JAA07722
	for disman-list; Wed, 1 Nov 2000 09:24:31 -0800 (PST)
Received: from creeper.bmc.com (creeper.bmc.com [172.17.1.166])
	by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id JAA07717
	for <disman@dorothy.peer.com>; Wed, 1 Nov 2000 09:24:27 -0800 (PST)
Received: from ec03-hou.bmc.com (localhost [127.0.0.1])
	by creeper.bmc.com (8.10.2/8.8.6) with ESMTP id eA1HP5Q08534;
	Wed, 1 Nov 2000 11:25:05 -0600 (CST)
Received: by ec03-hou.bmc.com with Internet Mail Service (5.5.2650.21)
	id <VJ74293L>; Wed, 1 Nov 2000 11:25:43 -0600
Message-ID: <F7E4D46ABD8FD211928E00A0C9EBD1D603E0EA0D@es01-sjc.bmc.com>
From: "Ayers, Mike" <Mike_Ayers@bmc.com>
To: "'Sharon Chisholm'" <schishol@nortelnetworks.com>
Cc: disman@dorothy.bmc.com
Subject: RE: draft-chisholm-disman-active-alarm-01.txt
Date: Wed, 1 Nov 2000 11:27:15 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-disman@dorothy.bmc.com
Precedence: bulk
List-Id: IETF disman Working Group mailing list <disman@dorothy.bmc.com>



> From: Sharon Chisholm [mailto:schishol@nortelnetworks.com]
>
> hi
>
> I start holidays tomorrow, so I will be reading any other
> comments and suggestions when I get back November 26th.
> Please do reply though.
>
> I can certainly incorporate the corrections, but I have a
> question about the security information.  From my copy of
> X.736:
>
> Security alarm detector - This parameter identifies the detector
> of the security alarm.
>
> Service user - This parameter identifies the service-user whose
> request for service led to the generation of the security alarm.
>
> Service provider - This parameter identifies the intended service-provider

> of the service that led to the generation of the security alarm.

	I get the same readings.

> These seem to apply to only a small subset of alarms.  Wouldn't it
> then be better to go with the option you also suggested of just
> having them as varbinds in the trap, and therefore present in the
> alarmActiveVariablesTable?

	Actually, I think they apply to about half the alarms, since my copy
of X.736 states that they are mandatory for all security alarms.  Does yours
read the same (mine is not a final copy, unfortunately)?

	I don't object to these objects being in the
alarmActiveVariablesTable, but I do think that there should be objects
defined specifically for them somewhere in the Active Alarm MIB so that they
can be identified as such.

> Also, are there any security implications of making this available in
> a MIB?  I know a lot of systems have a way of turning off the SNMP
> authentication failure trap for this reason.

	I'll look into this, but I suspect that there would not be a
problem, assuming the use of SNMPv3.  However, now that you mention it,
section 9 might wish to mention that if unauthenticated or unencrypted
access to the MIB is permitted, intruders may be able to discover current
weak points in the system, since such MIBs are often used to monitor
computer networks.

> thanks,
>
> Sharon
>
> PS.  I send explicitly as plain text, it just arrive as html. Network
>      Gremlins.
>

	Some network admin is doing us a "favor", isn't that sweet?


/|/|ike


From owner-disman@dorothy.bmc.com  Thu Nov  2 14:30:09 2000
Received: from tattler.bmc.com (fw-us-hou-2.bmc.com [198.207.223.251])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA27523
	for <disman-archive@odin.ietf.org>; Thu, 2 Nov 2000 14:30:09 -0500 (EST)
Received: from dorothy.bmc.com (localhost [127.0.0.1])
	by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id eA2JOcq28626;
	Thu, 2 Nov 2000 13:24:39 -0600 (CST)
Received: (from root@localhost)
	by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id LAA11719
	for disman-list; Thu, 2 Nov 2000 11:24:28 -0800 (PST)
Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117])
	by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id LAA11714
	for <disman@dorothy.bmc.com>; Thu, 2 Nov 2000 11:24:24 -0800 (PST)
Received: from fw-us-hou2.bmc.com (localhost [127.0.0.1])
	by tattler.bmc.com (8.10.2/8.10.2) with SMTP id eA2JNpw28461
	for <disman@dorothy.bmc.com>; Thu, 2 Nov 2000 13:23:52 -0600 (CST)
Received: from ISI.EDU (jet.isi.edu [128.9.160.87])
	by boreas.isi.edu (8.9.3/8.9.3) with ESMTP id LAA24864;
	Thu, 2 Nov 2000 11:21:50 -0800 (PST)
Message-Id: <200011021921.LAA24864@boreas.isi.edu>
To: IETF-Announce: ;
Subject: RFC 2981 on Event MIB
Cc: rfc-ed@ISI.EDU, disman@dorothy.bmc.com
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Thu, 02 Nov 2000 11:21:49 -0800
From: RFC Editor <rfc-ed@ISI.EDU>
Sender: owner-disman@dorothy.bmc.com
Precedence: bulk
List-Id: IETF disman Working Group mailing list <disman@dorothy.bmc.com>



--NextPart


A new Request for Comments is now available in online RFC libraries.


        RFC 2981

        Title:	    Event MIB
        Author(s):  R. Kavasseri (Editor of this version)
                    B. Stewart (Author of previous version)
        Status:     Standards Track
	Date:       October 2000
        Mailbox:    ramk@cisco.com
        Pages:      50
        Characters: 98248
        Updates/Obsoletes/SeeAlso:  None

        I-D Tag:    draft-ietf-disman-event-mib-10.txt

        URL:        ftp://ftp.isi.edu/in-notes/rfc2981.txt


This memo defines a portion of the Management Information
Base (MIB) for use with network management protocols in the Internet
community.  In particular, it describes managed objects that can be
used to manage and monitor MIB objects and take action through
events. 
 
The Event MIB provides the ability to monitor MIB objects on the local
system or on a remote system and take simple action when a trigger
condition is met.

This document is a product of the Distributed Management Working Group
of the IETF.

This is now a Proposed Standard Protocol.

This document specifies an Internet standards track protocol for
the Internet community, and requests discussion and suggestions
for improvements.  Please refer to the current edition of the
"Internet Official Protocol Standards" (STD 1) for the
standardization state and status of this protocol.  Distribution
of this memo is unlimited.

This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST@IETF.ORG.  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG.

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body 
help: ways_to_get_rfcs.  For example:

        To: rfc-info@RFC-EDITOR.ORG
        Subject: getting rfcs

        help: ways_to_get_rfcs

Requests for special distribution should be addressed to either the
author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.echo 
Submissions for Requests for Comments should be sent to
RFC-EDITOR@RFC-EDITOR.ORG.  Please consult RFC 2223, Instructions to RFC
Authors, for further information.


Joyce K. Reynolds and Sandy Ginoza
USC/Information Sciences Institute

...

Below is the data which will enable a MIME compliant Mail Reader 
implementation to automatically retrieve the ASCII version
of the RFCs.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type:  Message/External-body;
        access-type="mail-server";
        server="RFC-INFO@RFC-EDITOR.ORG"

Content-Type: text/plain
Content-ID: <001102111947.RFC@RFC-EDITOR.ORG>

RETRIEVE: rfc
DOC-ID: rfc2981

--OtherAccess
Content-Type:   Message/External-body;
        name="rfc2981.txt";
        site="ftp.isi.edu";
        access-type="anon-ftp";
        directory="in-notes"

Content-Type: text/plain
Content-ID: <001102111947.RFC@RFC-EDITOR.ORG>

--OtherAccess--
--NextPart--


From owner-disman@dorothy.bmc.com  Thu Nov  2 14:32:40 2000
Received: from tattler.bmc.com (fw-us-hou-2.bmc.com [198.207.223.251])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA28115
	for <disman-archive@odin.ietf.org>; Thu, 2 Nov 2000 14:32:40 -0500 (EST)
Received: from dorothy.bmc.com (localhost [127.0.0.1])
	by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id eA2JOZj28619;
	Thu, 2 Nov 2000 13:24:36 -0600 (CST)
Received: (from root@localhost)
	by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id LAA11708
	for disman-list; Thu, 2 Nov 2000 11:21:53 -0800 (PST)
Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117])
	by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id LAA11702
	for <disman@dorothy.bmc.com>; Thu, 2 Nov 2000 11:21:48 -0800 (PST)
Received: from fw-us-hou2.bmc.com (localhost [127.0.0.1])
	by tattler.bmc.com (8.10.2/8.10.2) with SMTP id eA2JLFa27817
	for <disman@dorothy.bmc.com>; Thu, 2 Nov 2000 13:21:16 -0600 (CST)
Received: from ISI.EDU (jet.isi.edu [128.9.160.87])
	by boreas.isi.edu (8.9.3/8.9.3) with ESMTP id LAA24340;
	Thu, 2 Nov 2000 11:19:11 -0800 (PST)
Message-Id: <200011021919.LAA24340@boreas.isi.edu>
To: IETF-Announce: ;
Subject: RFC 2982 on Distributed Management Expression MIB
Cc: rfc-ed@ISI.EDU, disman@dorothy.bmc.com
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Thu, 02 Nov 2000 11:19:11 -0800
From: RFC Editor <rfc-ed@ISI.EDU>
Sender: owner-disman@dorothy.bmc.com
Precedence: bulk
List-Id: IETF disman Working Group mailing list <disman@dorothy.bmc.com>



--NextPart


A new Request for Comments is now available in online RFC libraries.


        RFC 2982

        Title:	    Distributed Management Expression MIB
        Author(s):  R. Kavasseri (Editor of this version)
                    B. Stewart (Author of previous version)
        Status:     Standards Track
	Date:       October 2000
        Mailbox:    ramk@cisco.com
        Pages:      41
        Characters: 81371
        Updates/Obsoletes/SeeAlso:  None

        I-D Tag:    draft-ietf-disman-express-mib-12.txt

        URL:        ftp://ftp.isi.edu/in-notes/rfc2982.txt


This memo defines a portion of the Management Information Base (MIB)
for use with network management protocols in the Internet community.
In particular, it describes managed objects used for managing
expressions of MIB objects.  The results of these expressions become
MIB objects usable like any other MIB object, such as for the test
condition for declaring an event.

This document is a product of the Distributed Management Working Group
of the IETF.

This is now a Proposed Standard Protocol.

This document specifies an Internet standards track protocol for
the Internet community, and requests discussion and suggestions
for improvements.  Please refer to the current edition of the
"Internet Official Protocol Standards" (STD 1) for the
standardization state and status of this protocol.  Distribution
of this memo is unlimited.

This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST@IETF.ORG.  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG.

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body 
help: ways_to_get_rfcs.  For example:

        To: rfc-info@RFC-EDITOR.ORG
        Subject: getting rfcs

        help: ways_to_get_rfcs

Requests for special distribution should be addressed to either the
author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.echo 
Submissions for Requests for Comments should be sent to
RFC-EDITOR@RFC-EDITOR.ORG.  Please consult RFC 2223, Instructions to RFC
Authors, for further information.


Joyce K. Reynolds and Sandy Ginoza
USC/Information Sciences Institute

...

Below is the data which will enable a MIME compliant Mail Reader 
implementation to automatically retrieve the ASCII version
of the RFCs.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type:  Message/External-body;
        access-type="mail-server";
        server="RFC-INFO@RFC-EDITOR.ORG"

Content-Type: text/plain
Content-ID: <001102093512.RFC@RFC-EDITOR.ORG>

RETRIEVE: rfc
DOC-ID: rfc2982

--OtherAccess
Content-Type:   Message/External-body;
        name="rfc2982.txt";
        site="ftp.isi.edu";
        access-type="anon-ftp";
        directory="in-notes"

Content-Type: text/plain
Content-ID: <001102093512.RFC@RFC-EDITOR.ORG>

--OtherAccess--
--NextPart--


From owner-disman@dorothy.bmc.com  Thu Nov  2 15:02:33 2000
Received: from tattler.bmc.com (fw-us-hou-1.bmc.com [198.207.223.250])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA04967
	for <disman-archive@odin.ietf.org>; Thu, 2 Nov 2000 15:02:32 -0500 (EST)
Received: from dorothy.bmc.com (localhost [127.0.0.1])
	by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id eA2JtZs05169;
	Thu, 2 Nov 2000 13:55:35 -0600 (CST)
Received: (from root@localhost)
	by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id LAA12351
	for disman-list; Thu, 2 Nov 2000 11:55:45 -0800 (PST)
Received: (from rpresuhn@localhost)
	by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id LAA12345
	for disman@dorothy.bmc.com; Thu, 2 Nov 2000 11:55:42 -0800 (PST)
Date: Thu, 2 Nov 2000 11:55:42 -0800 (PST)
From: Randy Presuhn <rpresuhn@dorothy.bmc.com>
Message-Id: <200011021955.LAA12345@dorothy.bmc.com>
To: disman@dorothy.bmc.com
Subject: Re:  RFC 2982 on Distributed Management Expression MIB
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-disman@dorothy.bmc.com
Precedence: bulk
List-Id: IETF disman Working Group mailing list <disman@dorothy.bmc.com>
X-MIME-Autoconverted: from 8bit to quoted-printable by tattler.bmc.com id eA2JtZs05169
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id PAA04967


Hi -

...
> A new Request for Comments is now available in online RFC libraries.
> 
> 
>         RFC 2982
> 
>         Title:	    Distributed Management Expression MIB
>         Author(s):  R. Kavasseri (Editor of this version)
>                     B. Stewart (Author of previous version)
>         Status:     Standards Track
...

A big HOORAY for Ram and the entire WG for getting this finished!

 -------------------------------------------------------
 Randy Presuhn           randy_presuhn@bmc.com
 Voice: +1 408 546-1006  BMC Software, Inc.  1-3141
 Fax:   +1 408 965-0359  2141 North First Street
 http://www.bmc.com/     San José, California 95131  USA
 -------------------------------------------------------
 My opinions and BMC's are independent variables.
 -------------------------------------------------------


From owner-disman@dorothy.bmc.com  Thu Nov  2 15:05:00 2000
Received: from tattler.bmc.com (fw-us-hou-1.bmc.com [198.207.223.250])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA05533
	for <disman-archive@odin.ietf.org>; Thu, 2 Nov 2000 15:04:58 -0500 (EST)
Received: from dorothy.bmc.com (localhost [127.0.0.1])
	by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id eA2JvXW05507;
	Thu, 2 Nov 2000 13:57:33 -0600 (CST)
Received: (from root@localhost)
	by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id LAA12385
	for disman-list; Thu, 2 Nov 2000 11:57:51 -0800 (PST)
Received: (from rpresuhn@localhost)
	by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id LAA12379
	for disman@dorothy.bmc.com; Thu, 2 Nov 2000 11:57:48 -0800 (PST)
Date: Thu, 2 Nov 2000 11:57:48 -0800 (PST)
From: Randy Presuhn <rpresuhn@dorothy.bmc.com>
Message-Id: <200011021957.LAA12379@dorothy.bmc.com>
To: disman@dorothy.bmc.com
Subject: Re:  RFC 2981 on Event MIB
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-disman@dorothy.bmc.com
Precedence: bulk
List-Id: IETF disman Working Group mailing list <disman@dorothy.bmc.com>
X-MIME-Autoconverted: from 8bit to quoted-printable by tattler.bmc.com id eA2JvXW05507
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id PAA05533


Hi -

...
>        RFC 2981
>
>        Title:      Event MIB
>        Author(s):  R. Kavasseri (Editor of this version)
>                    B. Stewart (Author of previous version)
>        Status:     Standards Track
>        Date:       October 2000
...

When it rains, it pours!

 -------------------------------------------------------
 Randy Presuhn           randy_presuhn@bmc.com
 Voice: +1 408 546-1006  BMC Software, Inc.  1-3141
 Fax:   +1 408 965-0359  2141 North First Street
 http://www.bmc.com/     San José, California 95131  USA
 -------------------------------------------------------
 My opinions and BMC's are independent variables.
 -------------------------------------------------------


From owner-disman@dorothy.bmc.com  Sat Nov  4 05:15:44 2000
Received: from tattler.bmc.com (fw-us-hou-2.bmc.com [198.207.223.251])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA07111
	for <disman-archive@odin.ietf.org>; Sat, 4 Nov 2000 05:15:44 -0500 (EST)
Received: from dorothy.bmc.com (localhost [127.0.0.1])
	by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id eA4AAum16100;
	Sat, 4 Nov 2000 04:10:56 -0600 (CST)
Received: (from root@localhost)
	by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id CAA19772
	for disman-list; Sat, 4 Nov 2000 02:09:18 -0800 (PST)
Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117])
	by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id CAA19767
	for <disman@dorothy.bmc.com>; Sat, 4 Nov 2000 02:09:14 -0800 (PST)
Received: from fw-us-hou1.bmc.com (localhost [127.0.0.1])
	by tattler.bmc.com (8.10.2/8.10.2) with SMTP id eA4A8c915908
	for <disman@dorothy.bmc.com>; Sat, 4 Nov 2000 04:08:41 -0600 (CST)
Received: from hansa.ibr.cs.tu-bs.de (IDENT:root@hansa [134.169.34.137])
	by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) with ESMTP id LAA08103;
	Sat, 4 Nov 2000 11:09:49 +0100 (MET)
Received: (from strauss@localhost)
	by hansa.ibr.cs.tu-bs.de (8.9.3/8.9.3) id LAA14950;
	Sat, 4 Nov 2000 11:09:49 +0100
X-Authentication-Warning: hansa.ibr.cs.tu-bs.de: strauss set sender to strauss@ibr.cs.tu-bs.de using -f
From: Frank Strauss <strauss@ibr.cs.tu-bs.de>
To: disman@dorothy.bmc.com
Subject: Re: RFC 2982 on Distributed Management Expression MIB
References: <200011021955.LAA12345@dorothy.bmc.com>
Date: 04 Nov 2000 11:09:49 +0100
In-Reply-To: Randy Presuhn's message of "2 Nov 2000 20:57:54 +0100"
Message-ID: <ypwsnp8qc9e.fsf@hansa.ibr.cs.tu-bs.de>
Lines: 21
User-Agent: Gnus/5.0803 (Gnus v5.8.3) Emacs/20.7
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-disman@dorothy.bmc.com
Precedence: bulk
List-Id: IETF disman Working Group mailing list <disman@dorothy.bmc.com>


An early issue for the next cycle ;-). Sorry, that I did not recognize
this earlier.

  expValueOctetStringVal OBJECT-TYPE
      SYNTAX      OCTET STRING (SIZE (0..65536))
      MAX-ACCESS  read-only
      STATUS      current
      DESCRIPTION
       "The value when expExpressionValueType is 'octetString'."
      ::= { expValueEntry 7 }

The size restriction violates SMIv2:

  7.1.2.  OCTET STRING
  
     The OCTET STRING type represents arbitrary binary or textual data.
     Although the SMI-specified size limitation for this type is 65535
     octets, MIB designers should realize that there may be implementation
     and interoperability limitations for sizes in excess of 255 octets.

The size restriction should be removed or the upper limit reduced by one.


From owner-disman@dorothy.bmc.com  Sat Nov  4 06:06:10 2000
Received: from tattler.bmc.com (fw-us-hou-1.bmc.com [198.207.223.250])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA23052
	for <disman-archive@odin.ietf.org>; Sat, 4 Nov 2000 06:06:09 -0500 (EST)
Received: from dorothy.bmc.com (localhost [127.0.0.1])
	by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id eA4B3XG20144;
	Sat, 4 Nov 2000 05:03:34 -0600 (CST)
Received: (from root@localhost)
	by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id DAA19848
	for disman-list; Sat, 4 Nov 2000 03:03:48 -0800 (PST)
Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117])
	by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id DAA19841
	for <disman@dorothy.bmc.com>; Sat, 4 Nov 2000 03:03:34 -0800 (PST)
Received: from fw-us-hou1.bmc.com (localhost [127.0.0.1])
	by tattler.bmc.com (8.10.2/8.10.2) with SMTP id eA4B31u20100
	for <disman@dorothy.bmc.com>; Sat, 4 Nov 2000 05:03:01 -0600 (CST)
Received: from auemail2.firewall.lucent.com (localhost [127.0.0.1])
	by auemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id GAA15341
	for <disman@dorothy.bmc.com>; Sat, 4 Nov 2000 06:04:22 -0500 (EST)
Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62])
	by auemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id GAA15334
	for <disman@dorothy.bmc.com>; Sat, 4 Nov 2000 06:04:21 -0500 (EST)
Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2650.21)
	id <V0R8CQ6M>; Sat, 4 Nov 2000 12:04:16 +0100
Message-ID: <2413FED0DFE6D111B3F90008C7FA61FB09F87C04@nl0006exch002u.nl.lucent.com>
From: "Wijnen, Bert (Bert)" <bwijnen@lucent.com>
To: disman@dorothy.bmc.com, Frank Strauss <strauss@ibr.cs.tu-bs.de>
Subject: RE: RFC 2982 on Distributed Management Expression MIB
Date: Sat, 4 Nov 2000 12:04:15 +0100 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain
Sender: owner-disman@dorothy.bmc.com
Precedence: bulk
List-Id: IETF disman Working Group mailing list <disman@dorothy.bmc.com>


Probably best to just remove the SIZE all together.

Kam, will you take note?

Bert

> ----------
> From: 	Frank Strauss[SMTP:strauss@ibr.cs.tu-bs.de]
> Sent: 	Saturday, November 04, 2000 11:09 AM
> To: 	disman@dorothy.bmc.com
> Subject: 	Re: RFC 2982 on Distributed Management Expression MIB
> 
> 
> An early issue for the next cycle ;-). Sorry, that I did not recognize
> this earlier.
> 
>   expValueOctetStringVal OBJECT-TYPE
>       SYNTAX      OCTET STRING (SIZE (0..65536))
>       MAX-ACCESS  read-only
>       STATUS      current
>       DESCRIPTION
>        "The value when expExpressionValueType is 'octetString'."
>       ::= { expValueEntry 7 }
> 
> The size restriction violates SMIv2:
> 
>   7.1.2.  OCTET STRING
>   
>      The OCTET STRING type represents arbitrary binary or textual data.
>      Although the SMI-specified size limitation for this type is 65535
>      octets, MIB designers should realize that there may be implementation
>      and interoperability limitations for sizes in excess of 255 octets.
> 
> The size restriction should be removed or the upper limit reduced by one.
> 


From owner-disman@dorothy.bmc.com  Sat Nov  4 18:10:41 2000
Received: from tattler.bmc.com (fw-us-hou-2.bmc.com [198.207.223.251])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA28996
	for <disman-archive@odin.ietf.org>; Sat, 4 Nov 2000 18:10:40 -0500 (EST)
Received: from dorothy.bmc.com (localhost [127.0.0.1])
	by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id eA4N6Xk10346;
	Sat, 4 Nov 2000 17:06:33 -0600 (CST)
Received: (from root@localhost)
	by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id PAA20850
	for disman-list; Sat, 4 Nov 2000 15:04:28 -0800 (PST)
Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117])
	by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id PAA20845
	for <disman@dorothy.bmc.com>; Sat, 4 Nov 2000 15:04:24 -0800 (PST)
Received: from fw-us-hou1.bmc.com (localhost [127.0.0.1])
	by tattler.bmc.com (8.10.2/8.10.2) with SMTP id eA4N3oe09675
	for <disman@dorothy.bmc.com>; Sat, 4 Nov 2000 17:03:50 -0600 (CST)
Received: from alemail1.firewall.lucent.com (localhost [127.0.0.1])
	by alemail1.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id SAA14444
	for <disman@dorothy.bmc.com>; Sat, 4 Nov 2000 18:05:12 -0500 (EST)
Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62])
	by alemail1.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id SAA14414
	for <disman@dorothy.bmc.com>; Sat, 4 Nov 2000 18:05:11 -0500 (EST)
Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2650.21)
	id <V0R8CV3Q>; Sun, 5 Nov 2000 00:05:00 +0100
Message-ID: <2413FED0DFE6D111B3F90008C7FA61FB09F87C93@nl0006exch002u.nl.lucent.com>
From: "Wijnen, Bert (Bert)" <bwijnen@lucent.com>
To: disman@dorothy.bmc.com
Cc: ramk@cisco.com
Subject: RE: RFC 2982 on Distributed Management Expression MIB
Date: Sun, 5 Nov 2000 00:04:59 +0100 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain
Sender: owner-disman@dorothy.bmc.com
Precedence: bulk
List-Id: IETF disman Working Group mailing list <disman@dorothy.bmc.com>


Sorry I meant: Ram will you take note.

Bert

> ----------
> From: 	Wijnen, Bert (Bert)[SMTP:bwijnen@lucent.com]
> Sent: 	Saturday, November 04, 2000 12:04 PM
> To: 	disman@dorothy.bmc.com; Frank Strauss
> Subject: 	RE: RFC 2982 on Distributed Management Expression MIB
> 
> 
> Probably best to just remove the SIZE all together.
> 
> Kam, will you take note?
> 
> Bert
> 
> > ----------
> > From: 	Frank Strauss[SMTP:strauss@ibr.cs.tu-bs.de]
> > Sent: 	Saturday, November 04, 2000 11:09 AM
> > To: 	disman@dorothy.bmc.com
> > Subject: 	Re: RFC 2982 on Distributed Management Expression MIB
> > 
> > 
> > An early issue for the next cycle ;-). Sorry, that I did not recognize
> > this earlier.
> > 
> >   expValueOctetStringVal OBJECT-TYPE
> >       SYNTAX      OCTET STRING (SIZE (0..65536))
> >       MAX-ACCESS  read-only
> >       STATUS      current
> >       DESCRIPTION
> >        "The value when expExpressionValueType is 'octetString'."
> >       ::= { expValueEntry 7 }
> > 
> > The size restriction violates SMIv2:
> > 
> >   7.1.2.  OCTET STRING
> >   
> >      The OCTET STRING type represents arbitrary binary or textual data.
> >      Although the SMI-specified size limitation for this type is 65535
> >      octets, MIB designers should realize that there may be
> implementation
> >      and interoperability limitations for sizes in excess of 255 octets.
> > 
> > The size restriction should be removed or the upper limit reduced by
> one.
> > 
> 


From owner-disman@dorothy.bmc.com  Sat Nov 11 01:55:29 2000
Received: from tattler.bmc.com ([198.207.223.251])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA24843
	for <disman-archive@odin.ietf.org>; Sat, 11 Nov 2000 01:55:28 -0500 (EST)
Received: from dorothy.bmc.com (localhost [127.0.0.1])
	by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id eAB6ok723941;
	Sat, 11 Nov 2000 00:50:46 -0600 (CST)
Received: (from root@localhost)
	by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id WAA08754
	for disman-list; Fri, 10 Nov 2000 22:34:56 -0800 (PST)
Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117])
	by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id WAA08749
	for <disman@dorothy.bmc.com>; Fri, 10 Nov 2000 22:34:45 -0800 (PST)
Received: from fw-us-hou1.bmc.com (localhost [127.0.0.1])
	by tattler.bmc.com (8.10.2/8.10.2) with SMTP id eAB6Y7v22703
	for <disman@dorothy.bmc.com>; Sat, 11 Nov 2000 00:34:08 -0600 (CST)
Received: from [129.250.38.56] (helo=dfw-corpmmp1.email.verio.net)
	by dfw-smtpout4.email.verio.net with esmtp (Exim 3.12 #7)
	id 13uUGG-0005pj-00; Sat, 11 Nov 2000 06:35:36 +0000
Received: from [206.176.136.115] (helo=cwk)
	by dfw-corpmmp1.email.verio.net with smtp  
	id 13uUGB-0006Zx-00; Sat, 11 Nov 2000 06:35:31 +0000
From: "Carl W. Kalbfleisch" <cwk@verio.net>
To: "Sharon Chisholm" <schishol@nortelnetworks.com>
Cc: <disman@dorothy.bmc.com>
Subject: RE: draft-chisholm-disman-active-alarm-01.txt
Date: Sat, 11 Nov 2000 00:39:04 -0600
Message-ID: <NDBBLANGKLMBKIHPCGAMOEABIDAA.cwk@verio.net>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_003E_01C04B77.CAF948A0"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <6DDA62170439D31185750000F80826AC041EDA9D@zmerd004.ca.nortel.com>
Sender: owner-disman@dorothy.bmc.com
Precedence: bulk
List-Id: IETF disman Working Group mailing list <disman@dorothy.bmc.com>


This is a multi-part message in MIME format.

------=_NextPart_000_003E_01C04B77.CAF948A0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

draft-chisholm-disman-active-alarm-01.txt
Sharon,

I finally had a chance to read over your MIB. Several questions/comments:

1) In your example you show that the widget normal trap clears the widget
critical trap. How does the agent implementing this MIB know about that
correlation? Should that be configurable someplace in the MIB?

2) You state age out is out of scope of the MIB. I suggest at minimum adding
a variable to indicate what the age out time is. I think a read-write
variable to control that would make sense.

3) It would be useful to add a row status to allow deletion of alarms. For
instance what if a link down trap is received, but the corresponding link up
is never received. With a row status the management station could delete the
entry.

Carl
  -----Original Message-----
  From: owner-disman@dorothy.bmc.com [mailto:owner-disman@dorothy.bmc.com]On
Behalf Of Sharon Chisholm
  Sent: Monday, October 23, 2000 7:10 AM
  To: internet-drafts@ietf.org
  Cc: disman@dorothy.bmc.com
  Subject: draft-chisholm-disman-active-alarm-01.txt


  hi

  8. Example

          Define the following Object:
            acmeWidgetIndex OBJECT-TYPE
              SYNTAX  Integer32
              MAX-ACCESS read-only
              STATUS   current
              DESCRIPTION
                "A unique number which identifies a particular Widget."
            ::= { acmeWidgetEntry 1 }

          Define the following three traps:
            acmeWidgetTemperatureCritical NOTIFICATION-TYPE
              OBJECTS { acmeWidgetIndex }
              STATUS      current
              DESCRIPTION
                "This trap indicates that the indicated




  Expires 22 April 2001                                          [Page 17]






  Internet Draft                 Alarm MIB                22 October 2000



                  widget has reached a critical temperature."
            ::= { acmeWidgetTraps 1 }

            acmeWidgetTemperatureNormal NOTIFICATION-TYPE
              OBJECTS { acmeWidgetIndex }
              STATUS      current
              DESCRIPTION
                "This trap indicates that the indicated widget has
                  reached a normal temperature."
            ::= { acmeWidgetTraps 2 }

            bgpBackwardTransition NOTIFICATION-TYPE
              OBJECTS { bgpPeerLastError,
                        bgpPeerState      }
              STATUS  current
              DESCRIPTION
                 "The BGPBackwardTransition Event is generated
                 when the BGP FSM moves from a higher numbered
                 state to a lower numbered state."
             ::= { bgpTraps 2 }

          0. Active alarm table empty and nothing in notification log
                   ___________________________      _____________________
                  | alarmActiveTable          |    | nlmLogTable         |
                  |---------------------------|    |---------------------|
                  | alarmActiveIndex |  alarm |    | nlmLogIndex | alarm |
                  |---------------------------|    |---------------------|
                  |___________________________|    |_____________________|

          1. Temperature of widget 2 goes critical
                   __________________________________________________
                  | alarmActiveTable                                 |
                  |--------------------------------------------------|
                  | alarmActiveIndex |  alarm                        |
                  |--------------------------------------------------|
                  |        1         | acmeWidgetTemperatureCritical |
                  |__________________________________________________|

                   _____________________________________________
                  | nlmLogTable                                 |
                  |---------------------------------------------|
                  | nlmLogIndex |  alarm                        |
                  |---------------------------------------------|
                  |      1      | acmeWidgetTemperatureCritical |
                  |_____________________________________________|



          2. BGP peering session transitions from a state of established




  Expires 22 April 2001                                          [Page 18]






  Internet Draft                 Alarm MIB                22 October 2000



             to opensent
                   __________________________________________________
                  | alarmActiveTable                                 |
                  |--------------------------------------------------|
                  | alarmActiveIndex |  alarm                        |
                  |--------------------------------------------------|
                  |        1         | acmeWidgetTemperatureCritical |
                  |        2         | bgpBackwardTransition         |
                  |__________________________________________________|

                   _____________________________________________
                  | nlmLogTable                                 |
                  |---------------------------------------------|
                  | nlmLogIndex |  alarm                        |
                  |---------------------------------------------|
                  |      1      | acmeWidgetTemperatureCritical |
                  |      2      | bgpBackwardTransition         |
                  |_____________________________________________|



          3. Temperature of widget 2 goes back to normal
                   __________________________________________________
                  | alarmActiveTable                                 |
                  |--------------------------------------------------|
                  | alarmActiveIndex |  alarm                        |
                  |--------------------------------------------------|
                  |        2         | bgpBackwardTransition         |
                  |__________________________________________________|

                   _____________________________________________
                  | nlmLogTable                                 |
                  |---------------------------------------------|
                  | nlmLogIndex |  alarm                        |
                  |---------------------------------------------|
                  |      1      | acmeWidgetTemperatureCritical |
                  |      2      | bgpBackwardTransition         |
                  |      3      | acmeWidgetTemperatureNormal   |
                  |_____________________________________________|



          4. Time passes .... BGP alarm ages out.

                   __________________________________________________
                  | alarmActiveTable                                 |
                  |--------------------------------------------------|
                  | alarmActiveIndex |  alarm                        |
                  |--------------------------------------------------|
                  |__________________________________________________|




------=_NextPart_000_003E_01C04B77.CAF948A0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>draft-chisholm-disman-active-alarm-01.txt</TITLE>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2614.3500" name=3DGENERATOR></HEAD>
<BODY>
<DIV>&nbsp;</DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D560425319-10112000>Sharon,</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D560425319-10112000></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D560425319-10112000>I=20
finally had a chance to read over your MIB. Several=20
questions/comments:</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D560425319-10112000></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D560425319-10112000>1) In=20
your example you show that the widget normal trap clears the widget =
critical=20
trap. How does the agent implementing this MIB know about that =
correlation?=20
Should that be configurable someplace in the MIB?</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D560425319-10112000></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D560425319-10112000>2) You=20
state age out is out of scope of the MIB. I suggest at minimum adding a =
variable=20
to indicate what the age out time is. I think a read-write variable to =
control=20
that would make&nbsp;sense.</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D560425319-10112000></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D560425319-10112000>3) It=20
would be useful to add a row status to allow deletion of alarms. For =
instance=20
what if a link down trap is received, but the corresponding link up is =
never=20
received. With a row status the management station could delete the=20
entry.</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D560425319-10112000></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D560425319-10112000>Carl</SPAN></FONT></DIV>
<BLOCKQUOTE=20
style=3D"BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT: 5px; PADDING-LEFT: =
5px">
  <DIV align=3Dleft class=3DOutlookMessageHeader dir=3Dltr><FONT =
face=3DTahoma=20
  size=3D2>-----Original Message-----<BR><B>From:</B> =
owner-disman@dorothy.bmc.com=20
  [mailto:owner-disman@dorothy.bmc.com]<B>On Behalf Of </B>Sharon=20
  Chisholm<BR><B>Sent:</B> Monday, October 23, 2000 7:10 =
AM<BR><B>To:</B>=20
  internet-drafts@ietf.org<BR><B>Cc:</B>=20
  disman@dorothy.bmc.com<BR><B>Subject:</B>=20
  draft-chisholm-disman-active-alarm-01.txt<BR><BR></DIV></FONT>
  <P><FONT size=3D2>hi</FONT> </P>
  <P><FONT size=3D2>8. Example</FONT> </P>
  <P><FONT size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Define =
the=20
  following Object:</FONT> <BR><FONT=20
  size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
acmeWidgetIndex=20
  OBJECT-TYPE</FONT> <BR><FONT=20
  =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;=20
  SYNTAX&nbsp; Integer32</FONT> <BR><FONT=20
  =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;=20
  MAX-ACCESS read-only</FONT> <BR><FONT=20
  =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;=20
  STATUS&nbsp;&nbsp; current</FONT> <BR><FONT=20
  =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;=20
  DESCRIPTION</FONT> <BR><FONT=20
  =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;=20
  "A unique number which identifies a particular Widget."</FONT> =
<BR><FONT=20
  size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ::=3D =
{=20
  acmeWidgetEntry 1 }</FONT> </P>
  <P><FONT size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Define =
the=20
  following three traps:</FONT> <BR><FONT=20
  size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  acmeWidgetTemperatureCritical NOTIFICATION-TYPE</FONT> <BR><FONT=20
  =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;=20
  OBJECTS { acmeWidgetIndex }</FONT> <BR><FONT=20
  =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;=20
  STATUS&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; current</FONT> <BR><FONT=20
  =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;=20
  DESCRIPTION</FONT> <BR><FONT=20
  =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;=20
  "This trap indicates that the indicated</FONT> </P><BR><BR>
  <P><FONT size=3D2>Expires 22 April=20
  =
2001&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  [Page 17]</FONT> </P><BR><BR><BR><BR>
  <P><FONT size=3D2>Internet=20
  =
Draft&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  Alarm=20
  =
MIB&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;=20
  22 October 2000</FONT> </P><BR>
  <P><FONT=20
  =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;=20
  widget has reached a critical temperature."</FONT> <BR><FONT=20
  size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ::=3D =
{=20
  acmeWidgetTraps 1 }</FONT> </P>
  <P><FONT =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  acmeWidgetTemperatureNormal NOTIFICATION-TYPE</FONT> <BR><FONT=20
  =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;=20
  OBJECTS { acmeWidgetIndex }</FONT> <BR><FONT=20
  =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;=20
  STATUS&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; current</FONT> <BR><FONT=20
  =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;=20
  DESCRIPTION</FONT> <BR><FONT=20
  =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;=20
  "This trap indicates that the indicated widget has</FONT> <BR><FONT=20
  =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;=20
  reached a normal temperature."</FONT> <BR><FONT=20
  size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ::=3D =
{=20
  acmeWidgetTraps 2 }</FONT> </P>
  <P><FONT =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  bgpBackwardTransition NOTIFICATION-TYPE</FONT> <BR><FONT=20
  =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;=20
  OBJECTS { bgpPeerLastError,</FONT> <BR><FONT=20
  =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  bgpPeerState&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; }</FONT> <BR><FONT=20
  =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;=20
  STATUS&nbsp; current</FONT> <BR><FONT=20
  =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;=20
  DESCRIPTION</FONT> <BR><FONT=20
  =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;=20
  "The BGPBackwardTransition Event is generated</FONT> <BR><FONT=20
  =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;=20
  when the BGP FSM moves from a higher numbered</FONT> <BR><FONT=20
  =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;=20
  state to a lower numbered state."</FONT> <BR><FONT=20
  size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
::=3D {=20
  bgpTraps 2 }</FONT> </P>
  <P><FONT size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0. Active =
alarm=20
  table empty and nothing in notification log</FONT> <BR><FONT=20
  =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  ___________________________&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  _____________________</FONT> <BR><FONT=20
  =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;=20
  | =
alarmActiveTable&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  |&nbsp;&nbsp;&nbsp; |=20
  nlmLogTable&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |</FONT> =
<BR><FONT=20
  =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;=20
  |---------------------------|&nbsp;&nbsp;&nbsp; =
|---------------------|</FONT>=20
  <BR><FONT=20
  =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;=20
  | alarmActiveIndex |&nbsp; alarm |&nbsp;&nbsp;&nbsp; | nlmLogIndex | =
alarm=20
  |</FONT> <BR><FONT=20
  =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;=20
  |---------------------------|&nbsp;&nbsp;&nbsp; =
|---------------------|</FONT>=20
  <BR><FONT=20
  =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;=20
  |___________________________|&nbsp;&nbsp;&nbsp; =
|_____________________|</FONT>=20
  </P>
  <P><FONT size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 1. =
Temperature of=20
  widget 2 goes critical</FONT> <BR><FONT=20
  =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  __________________________________________________</FONT> <BR><FONT=20
  =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;=20
  |=20
  =
alarmActiveTable&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  |</FONT> <BR><FONT=20
  =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;=20
  |--------------------------------------------------|</FONT> <BR><FONT=20
  =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;=20
  | alarmActiveIndex |&nbsp;=20
  =
alarm&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  |</FONT> <BR><FONT=20
  =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;=20
  |--------------------------------------------------|</FONT> <BR><FONT=20
  =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;=20
  |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |=20
  acmeWidgetTemperatureCritical |</FONT> <BR><FONT=20
  =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;=20
  |__________________________________________________|</FONT> </P>
  <P><FONT=20
  =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  _____________________________________________</FONT> <BR><FONT=20
  =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;=20
  |=20
  =
nlmLogTable&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  |</FONT> <BR><FONT=20
  =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;=20
  |---------------------------------------------|</FONT> <BR><FONT=20
  =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;=20
  | nlmLogIndex |&nbsp;=20
  =
alarm&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  |</FONT> <BR><FONT=20
  =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;=20
  |---------------------------------------------|</FONT> <BR><FONT=20
  =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;=20
  |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |=20
  acmeWidgetTemperatureCritical |</FONT> <BR><FONT=20
  =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;=20
  |_____________________________________________|</FONT> </P><BR>
  <P><FONT size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 2. BGP =
peering=20
  session transitions from a state of established</FONT> </P><BR><BR>
  <P><FONT size=3D2>Expires 22 April=20
  =
2001&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  [Page 18]</FONT> </P><BR><BR><BR><BR>
  <P><FONT size=3D2>Internet=20
  =
Draft&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  Alarm=20
  =
MIB&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;=20
  22 October 2000</FONT> </P><BR>
  <P><FONT =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  to opensent</FONT> <BR><FONT=20
  =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  __________________________________________________</FONT> <BR><FONT=20
  =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;=20
  |=20
  =
alarmActiveTable&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  |</FONT> <BR><FONT=20
  =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;=20
  |--------------------------------------------------|</FONT> <BR><FONT=20
  =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;=20
  | alarmActiveIndex |&nbsp;=20
  =
alarm&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  |</FONT> <BR><FONT=20
  =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;=20
  |--------------------------------------------------|</FONT> <BR><FONT=20
  =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;=20
  |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |=20
  acmeWidgetTemperatureCritical |</FONT> <BR><FONT=20
  =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;=20
  |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |=20
  bgpBackwardTransition&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
|</FONT>=20
  <BR><FONT=20
  =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;=20
  |__________________________________________________|</FONT> </P>
  <P><FONT=20
  =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  _____________________________________________</FONT> <BR><FONT=20
  =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;=20
  |=20
  =
nlmLogTable&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  |</FONT> <BR><FONT=20
  =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;=20
  |---------------------------------------------|</FONT> <BR><FONT=20
  =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;=20
  | nlmLogIndex |&nbsp;=20
  =
alarm&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  |</FONT> <BR><FONT=20
  =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;=20
  |---------------------------------------------|</FONT> <BR><FONT=20
  =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;=20
  |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |=20
  acmeWidgetTemperatureCritical |</FONT> <BR><FONT=20
  =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;=20
  |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |=20
  bgpBackwardTransition&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
|</FONT>=20
  <BR><FONT=20
  =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;=20
  |_____________________________________________|</FONT> </P><BR>
  <P><FONT size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 3. =
Temperature of=20
  widget 2 goes back to normal</FONT> <BR><FONT=20
  =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  __________________________________________________</FONT> <BR><FONT=20
  =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;=20
  |=20
  =
alarmActiveTable&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  |</FONT> <BR><FONT=20
  =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;=20
  |--------------------------------------------------|</FONT> <BR><FONT=20
  =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;=20
  | alarmActiveIndex |&nbsp;=20
  =
alarm&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  |</FONT> <BR><FONT=20
  =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;=20
  |--------------------------------------------------|</FONT> <BR><FONT=20
  =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;=20
  |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |=20
  bgpBackwardTransition&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
|</FONT>=20
  <BR><FONT=20
  =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;=20
  |__________________________________________________|</FONT> </P>
  <P><FONT=20
  =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  _____________________________________________</FONT> <BR><FONT=20
  =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;=20
  |=20
  =
nlmLogTable&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  |</FONT> <BR><FONT=20
  =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;=20
  |---------------------------------------------|</FONT> <BR><FONT=20
  =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;=20
  | nlmLogIndex |&nbsp;=20
  =
alarm&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  |</FONT> <BR><FONT=20
  =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;=20
  |---------------------------------------------|</FONT> <BR><FONT=20
  =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;=20
  |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |=20
  acmeWidgetTemperatureCritical |</FONT> <BR><FONT=20
  =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;=20
  |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |=20
  bgpBackwardTransition&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
|</FONT>=20
  <BR><FONT=20
  =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;=20
  |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 3&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |=20
  acmeWidgetTemperatureNormal&nbsp;&nbsp; |</FONT> <BR><FONT=20
  =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;=20
  |_____________________________________________|</FONT> </P><BR>
  <P><FONT size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 4. Time =
passes ....=20
  BGP alarm ages out.</FONT> </P>
  <P><FONT=20
  =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  __________________________________________________</FONT> <BR><FONT=20
  =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;=20
  |=20
  =
alarmActiveTable&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  |</FONT> <BR><FONT=20
  =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;=20
  |--------------------------------------------------|</FONT> <BR><FONT=20
  =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;=20
  | alarmActiveIndex |&nbsp;=20
  =
alarm&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  |</FONT> <BR><FONT=20
  =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;=20
  |--------------------------------------------------|</FONT> <BR><FONT=20
  =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;=20
  |__________________________________________________|</FONT>=20
</P><BR></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_003E_01C04B77.CAF948A0--



From owner-disman@dorothy.bmc.com  Fri Nov 17 15:50:17 2000
Received: from tattler.bmc.com (fw-us-hou-1.bmc.com [198.207.223.250])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA09672
	for <disman-archive@odin.ietf.org>; Fri, 17 Nov 2000 15:50:17 -0500 (EST)
Received: from dorothy.bmc.com (localhost [127.0.0.1])
	by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id eAHKimT17092;
	Fri, 17 Nov 2000 14:44:48 -0600 (CST)
Received: (from root@localhost)
	by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id MAA02505
	for disman-list; Fri, 17 Nov 2000 12:39:42 -0800 (PST)
Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117])
	by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id MAA02500
	for <disman@dorothy.bmc.com>; Fri, 17 Nov 2000 12:39:38 -0800 (PST)
Received: from fw-us-hou1.bmc.com (localhost [127.0.0.1])
	by tattler.bmc.com (8.10.2/8.10.2) with SMTP id eAHKcuv15936
	for <disman@dorothy.bmc.com>; Fri, 17 Nov 2000 14:38:56 -0600 (CST)
Received: from cisco.com (dhcp-171-69-66-169.cisco.com [171.69.66.169])
	by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id MAA03331;
	Fri, 17 Nov 2000 12:40:22 -0800 (PST)
Message-ID: <3A159842.6E13CA6F@cisco.com>
Date: Fri, 17 Nov 2000 12:42:42 -0800
From: Ramanathan Kavasseri <ramk@cisco.com>
Reply-To: ramk@cisco.com
X-Mailer: Mozilla 4.73 [en]C-CCK-MCD   (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "Wijnen, Bert (Bert)" <bwijnen@lucent.com>
CC: disman@dorothy.bmc.com
Subject: Re: RFC 2982 on Distributed Management Expression MIB
References: <2413FED0DFE6D111B3F90008C7FA61FB09F87C93@nl0006exch002u.nl.lucent.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-disman@dorothy.bmc.com
Precedence: bulk
List-Id: IETF disman Working Group mailing list <disman@dorothy.bmc.com>
Content-Transfer-Encoding: 7bit


Noted. 

Ram

"Wijnen, Bert (Bert)" wrote:
> 
> Sorry I meant: Ram will you take note.
> 
> Bert
> 
> > ----------
> > From:         Wijnen, Bert (Bert)[SMTP:bwijnen@lucent.com]
> > Sent:         Saturday, November 04, 2000 12:04 PM
> > To:   disman@dorothy.bmc.com; Frank Strauss
> > Subject:      RE: RFC 2982 on Distributed Management Expression MIB
> >
> >
> > Probably best to just remove the SIZE all together.
> >
> > Kam, will you take note?
> >
> > Bert
> >
> > > ----------
> > > From:       Frank Strauss[SMTP:strauss@ibr.cs.tu-bs.de]
> > > Sent:       Saturday, November 04, 2000 11:09 AM
> > > To:         disman@dorothy.bmc.com
> > > Subject:    Re: RFC 2982 on Distributed Management Expression MIB
> > >
> > >
> > > An early issue for the next cycle ;-). Sorry, that I did not recognize
> > > this earlier.
> > >
> > >   expValueOctetStringVal OBJECT-TYPE
> > >       SYNTAX      OCTET STRING (SIZE (0..65536))
> > >       MAX-ACCESS  read-only
> > >       STATUS      current
> > >       DESCRIPTION
> > >        "The value when expExpressionValueType is 'octetString'."
> > >       ::= { expValueEntry 7 }
> > >
> > > The size restriction violates SMIv2:
> > >
> > >   7.1.2.  OCTET STRING
> > >
> > >      The OCTET STRING type represents arbitrary binary or textual data.
> > >      Although the SMI-specified size limitation for this type is 65535
> > >      octets, MIB designers should realize that there may be
> > implementation
> > >      and interoperability limitations for sizes in excess of 255 octets.
> > >
> > > The size restriction should be removed or the upper limit reduced by
> > one.
> > >
> >


From owner-disman@dorothy.bmc.com  Tue Nov 21 19:41:52 2000
Received: from tattler.bmc.com (fw-us-hou-1.bmc.com [198.207.223.250])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA03776
	for <disman-archive@odin.ietf.org>; Tue, 21 Nov 2000 19:41:52 -0500 (EST)
Received: from dorothy.bmc.com (localhost [127.0.0.1])
	by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id eAM0YVU03717;
	Tue, 21 Nov 2000 18:34:31 -0600 (CST)
Received: (from root@localhost)
	by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id QAA17433
	for disman-list; Tue, 21 Nov 2000 16:32:44 -0800 (PST)
Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117])
	by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id QAA17428
	for <disman@dorothy.bmc.com>; Tue, 21 Nov 2000 16:32:40 -0800 (PST)
Received: from fw-us-hou1.bmc.com (localhost [127.0.0.1])
	by tattler.bmc.com (8.10.2/8.10.2) with SMTP id eAM0VwT03420
	for <disman@dorothy.bmc.com>; Tue, 21 Nov 2000 18:31:58 -0600 (CST)
Received: from cisco.com ([10.19.193.44])
	by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id QAA15464
	for <disman@dorothy.bmc.com>; Tue, 21 Nov 2000 16:33:33 -0800 (PST)
Message-ID: <3A1B14E5.9364CBC6@cisco.com>
Date: Tue, 21 Nov 2000 16:35:49 -0800
From: Ramanathan Kavasseri <ramk@cisco.com>
Reply-To: ramk@cisco.com
X-Mailer: Mozilla 4.73 [en]C-CCK-MCD   (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
To: disman@dorothy.bmc.com
Subject: Will there be a DISMAN slot at the IETF Mtg in San Diego?
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-disman@dorothy.bmc.com
Precedence: bulk
List-Id: IETF disman Working Group mailing list <disman@dorothy.bmc.com>
Content-Transfer-Encoding: 7bit



TIA,

Ram


From owner-disman@dorothy.bmc.com  Mon Nov 27 14:49:14 2000
Received: from tattler.bmc.com (fw-us-hou-1.bmc.com [198.207.223.250])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA15975
	for <disman-archive@odin.ietf.org>; Mon, 27 Nov 2000 14:49:12 -0500 (EST)
Received: from dorothy.bmc.com (localhost [127.0.0.1])
	by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id eARJhXe18655;
	Mon, 27 Nov 2000 13:43:33 -0600 (CST)
Received: (from root@localhost)
	by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id LAA00259
	for disman-list; Mon, 27 Nov 2000 11:40:50 -0800 (PST)
Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117])
	by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id LAA00254
	for <disman@dorothy.bmc.com>; Mon, 27 Nov 2000 11:40:45 -0800 (PST)
Received: from fw-us-hou2.bmc.com (localhost [127.0.0.1])
	by tattler.bmc.com (8.10.2/8.10.2) with SMTP id eARJdxR17537
	for <disman@dorothy.bmc.com>; Mon, 27 Nov 2000 13:39:59 -0600 (CST)
Received: from zrchb213.us.nortel.com (actually zrchb213) 
          by smtprch2.nortel.com; Mon, 27 Nov 2000 13:31:35 -0600
Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2652.35) 
          id <XNC4F3FX>; Mon, 27 Nov 2000 13:35:51 -0600
Message-ID: <6DDA62170439D31185750000F80826AC048640BF@zmerd004.ca.nortel.com>
From: "Sharon Chisholm" <schishol@nortelnetworks.com>
To: disman@dorothy.bmc.com, ramk@cisco.com
Subject: RE: Will there be a DISMAN slot at the IETF Mtg in San Diego?
Date: Mon, 27 Nov 2000 13:35:48 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.35)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C058A9.3E14C600"
X-Orig: <schishol@americasm01.nt.com>
Sender: owner-disman@dorothy.bmc.com
Precedence: bulk
List-Id: IETF disman Working Group mailing list <disman@dorothy.bmc.com>


This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C058A9.3E14C600
Content-Type: text/plain;
	charset="iso-8859-1"

hi

I'd certainly be interested in meeting.  I'd like to discuss
the Alarm MIB and whether or not it should be added to the
charter.

Sharon.

-----Original Message-----
From: Ramanathan Kavasseri [mailto:ramk@cisco.com]
Sent: Tuesday, November 21, 2000 7:36 PM
To: disman@dorothy.bmc.com
Subject: Will there be a DISMAN slot at the IETF Mtg in San Diego?




TIA,

Ram

------_=_NextPart_001_01C058A9.3E14C600
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2652.35">
<TITLE>RE: Will there be a DISMAN slot at the IETF Mtg in San Diego?</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>hi</FONT>
</P>

<P><FONT SIZE=2>I'd certainly be interested in meeting.&nbsp; I'd like to discuss</FONT>
<BR><FONT SIZE=2>the Alarm MIB and whether or not it should be added to the</FONT>
<BR><FONT SIZE=2>charter.</FONT>
</P>

<P><FONT SIZE=2>Sharon.</FONT>
</P>

<P><FONT SIZE=2>-----Original Message-----</FONT>
<BR><FONT SIZE=2>From: Ramanathan Kavasseri [<A HREF="mailto:ramk@cisco.com">mailto:ramk@cisco.com</A>]</FONT>
<BR><FONT SIZE=2>Sent: Tuesday, November 21, 2000 7:36 PM</FONT>
<BR><FONT SIZE=2>To: disman@dorothy.bmc.com</FONT>
<BR><FONT SIZE=2>Subject: Will there be a DISMAN slot at the IETF Mtg in San Diego?</FONT>
</P>
<BR>
<BR>
<BR>

<P><FONT SIZE=2>TIA,</FONT>
</P>

<P><FONT SIZE=2>Ram</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C058A9.3E14C600--


From owner-disman@dorothy.bmc.com  Tue Nov 28 10:28:39 2000
Received: from tattler.bmc.com (fw-us-hou-1.bmc.com [198.207.223.250])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA21342
	for <disman-archive@odin.ietf.org>; Tue, 28 Nov 2000 10:28:38 -0500 (EST)
Received: from dorothy.bmc.com (localhost [127.0.0.1])
	by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id eASFMk420095;
	Tue, 28 Nov 2000 09:22:46 -0600 (CST)
Received: (from root@localhost)
	by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id HAA04425
	for disman-list; Tue, 28 Nov 2000 07:22:24 -0800 (PST)
Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117])
	by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id HAA04420
	for <disman@dorothy.bmc.com>; Tue, 28 Nov 2000 07:22:20 -0800 (PST)
Received: from fw-us-hou1.bmc.com (localhost [127.0.0.1])
	by tattler.bmc.com (8.10.2/8.10.2) with SMTP id eASFLWw19771
	for <disman@dorothy.bmc.com>; Tue, 28 Nov 2000 09:21:32 -0600 (CST)
Received: from zrtpd004.us.nortel.com (actually zrtpd004) 
          by ertpg14e1.nortelnetworks.com; Tue, 28 Nov 2000 10:13:13 -0500
Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2652.35) 
          id <XV2YF7Y3>; Tue, 28 Nov 2000 10:08:00 -0500
Message-ID: <6DDA62170439D31185750000F80826AC0489F2EA@zmerd004.ca.nortel.com>
From: "Sharon Chisholm" <schishol@nortelnetworks.com>
To: disman@dorothy.bmc.com, "Ayers, Mike" <Mike_Ayers@bmc.com>
Subject: RE: draft-chisholm-disman-active-alarm-01.txt
Date: Tue, 28 Nov 2000 10:07:52 -0500
X-Mailer: Internet Mail Service (5.5.2652.35)
Sender: owner-disman@dorothy.bmc.com
Precedence: bulk
List-Id: IETF disman Working Group mailing list <disman@dorothy.bmc.com>


hi

Comments in-line.

Sharon


>-----Original Message-----
>From: Ayers, Mike [mailto:Mike_Ayers@bmc.com]
>
>> From: Sharon Chisholm [mailto:schishol@nortelnetworks.com]
>>
>> These seem to apply to only a small subset of alarms.  Wouldn't it
>> then be better to go with the option you also suggested of just
>> having them as varbinds in the trap, and therefore present in the
>> alarmActiveVariablesTable?
>
>	Actually, I think they apply to about half the alarms, since my copy
>of X.736 states that they are mandatory for all security alarms.  Does
yours
>read the same (mine is not a final copy, unfortunately)?

That is how mine reads, but I would think that security alarms would not be
that big of a percentage of the alarms a system has.  Do you really see it
being as much as half?  I was thinking closer to 5%.
>
>	I don't object to these objects being in the
>alarmActiveVariablesTable, but I do think that there should be objects
>defined specifically for them somewhere in the Active Alarm MIB so that
they
>can be identified as such.
Maybe, I think this depends on the percentage of traps that would actually
use these parameters.

>
>> Also, are there any security implications of making this available in
>> a MIB?  I know a lot of systems have a way of turning off the SNMP
>> authentication failure trap for this reason.
>
>	I'll look into this, but I suspect that there would not be a
>problem, assuming the use of SNMPv3.  However, now that you mention it,
>section 9 might wish to mention that if unauthenticated or unencrypted
>access to the MIB is permitted, intruders may be able to discover current
>weak points in the system, since such MIBs are often used to monitor
>computer networks.
>
Good point.

>> PS.  I send explicitly as plain text, it just arrive as html. Network
>>      Gremlins.
>>
>
>	Some network admin is doing us a "favor", isn't that sweet?
>
I'm trying something new.  Let me know if it's better or worse.




From owner-disman@dorothy.bmc.com  Tue Nov 28 11:05:01 2000
Received: from tattler.bmc.com (fw-us-hou-1.bmc.com [198.207.223.250])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA06736
	for <disman-archive@odin.ietf.org>; Tue, 28 Nov 2000 11:05:00 -0500 (EST)
Received: from dorothy.bmc.com (localhost [127.0.0.1])
	by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id eASFmWO28084;
	Tue, 28 Nov 2000 09:48:32 -0600 (CST)
Received: (from root@localhost)
	by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id HAA04480
	for disman-list; Tue, 28 Nov 2000 07:48:46 -0800 (PST)
Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117])
	by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id HAA04475
	for <disman@dorothy.bmc.com>; Tue, 28 Nov 2000 07:48:41 -0800 (PST)
Received: from fw-us-hou1.bmc.com (localhost [127.0.0.1])
	by tattler.bmc.com (8.10.2/8.10.2) with SMTP id eASFlqx27837
	for <disman@dorothy.bmc.com>; Tue, 28 Nov 2000 09:47:52 -0600 (CST)
Received: from zrtpd004.us.nortel.com by zrtps06s.us.nortel.com;
          Tue, 28 Nov 2000 10:44:42 -0500
Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2652.35) 
          id <XV2YF0BJ>; Tue, 28 Nov 2000 10:44:37 -0500
Message-ID: <6DDA62170439D31185750000F80826AC0489F3F8@zmerd004.ca.nortel.com>
From: "Sharon Chisholm" <schishol@nortelnetworks.com>
To: disman <disman@dorothy.bmc.com>, "Carl W. Kalbfleisch" <cwk@verio.net>
Subject: RE: draft-chisholm-disman-active-alarm-01.txt
Date: Tue, 28 Nov 2000 10:44:16 -0500
X-Mailer: Internet Mail Service (5.5.2652.35)
X-Orig: <schishol@americasm01.nt.com>
Sender: owner-disman@dorothy.bmc.com
Precedence: bulk
List-Id: IETF disman Working Group mailing list <disman@dorothy.bmc.com>


hi

Comments in-line.

thanks,

Sharon

>-----Original Message-----
>From: Carl W. Kalbfleisch [mailto:cwk@verio.net]
> 
>1) In your example you show that the widget normal trap clears the widget
critical
> trap. How does the agent implementing this MIB know about that
correlation? Should
> that be configurable someplace in the MIB?
I've attempted to describe this relationship in the alarmDetailsTable with
the
alarmDetailsClearNotificationId object. The system originating the alarm
needs
to define this relationship and fill in the object. It's not configurable
though. 
I don't know if I like the idea of it being configurable.  It makes things
more difficult for the manager. I'd rather just read the table on discovery
instead
of having to monitor the table to see if it's changed and then try and
figure
out what to do with my active alarms if it does. Do you see a need for this 
relationship to change during run-time?

> 
> 2) You state age out is out of scope of the MIB. I suggest at minimum
adding a 
> variable to indicate what the age out time is. I think a read-write
variable to
> control that would make sense.
I thought about this but didn't since I am really trying to push the
raise/clear
model. It would be useful for a manager to know what this interval is
though.  Would
we be able to get away with one variable for the entire system?  

> 
>3) It would be useful to add a row status to allow deletion of alarms. For
instance
> what if a link down trap is received, but the corresponding link up is
never 
> received. With a row status the management station could delete the entry.
I'm not really comfortable with management stations clearing alarms on
devices.
I think that if the problem still exists, then it should show up in the
active alarm
table on the device.  A distributed manager might fail to receive the linkUp
trap,
but it could have a method to ensure consistency that does not require a row
status
object.
 

-----Original Message-----
From: owner-disman@dorothy.bmc.com [mailto:owner-disman@dorothy.bmc.com]On
Behalf Of Sharon Chisholm
Sent: Monday, October 23, 2000 7:10 AM
To: internet-drafts@ietf.org
Cc: disman@dorothy.bmc.com
Subject: draft-chisholm-disman-active-alarm-01.txt


hi 
8. Example 
        Define the following Object: 
          acmeWidgetIndex OBJECT-TYPE 
            SYNTAX  Integer32 
            MAX-ACCESS read-only 
            STATUS   current 
            DESCRIPTION 
              "A unique number which identifies a particular Widget." 
          ::= { acmeWidgetEntry 1 } 
        Define the following three traps: 
          acmeWidgetTemperatureCritical NOTIFICATION-TYPE 
            OBJECTS { acmeWidgetIndex } 
            STATUS      current 
            DESCRIPTION 
              "This trap indicates that the indicated 



Expires 22 April 2001                                          [Page 17] 





Internet Draft                 Alarm MIB                22 October 2000 


                widget has reached a critical temperature." 
          ::= { acmeWidgetTraps 1 } 
          acmeWidgetTemperatureNormal NOTIFICATION-TYPE 
            OBJECTS { acmeWidgetIndex } 
            STATUS      current 
            DESCRIPTION 
              "This trap indicates that the indicated widget has 
                reached a normal temperature." 
          ::= { acmeWidgetTraps 2 } 
          bgpBackwardTransition NOTIFICATION-TYPE 
            OBJECTS { bgpPeerLastError, 
                      bgpPeerState      } 
            STATUS  current 
            DESCRIPTION 
               "The BGPBackwardTransition Event is generated 
               when the BGP FSM moves from a higher numbered 
               state to a lower numbered state." 
           ::= { bgpTraps 2 } 
        0. Active alarm table empty and nothing in notification log 
                 ___________________________      _____________________ 
                | alarmActiveTable          |    | nlmLogTable         | 
                |---------------------------|    |---------------------| 
                | alarmActiveIndex |  alarm |    | nlmLogIndex | alarm | 
                |---------------------------|    |---------------------| 
                |___________________________|    |_____________________| 
        1. Temperature of widget 2 goes critical 
                 __________________________________________________ 
                | alarmActiveTable                                 | 
                |--------------------------------------------------| 
                | alarmActiveIndex |  alarm                        | 
                |--------------------------------------------------| 
                |        1         | acmeWidgetTemperatureCritical | 
                |__________________________________________________| 
                 _____________________________________________ 
                | nlmLogTable                                 | 
                |---------------------------------------------| 
                | nlmLogIndex |  alarm                        | 
                |---------------------------------------------| 
                |      1      | acmeWidgetTemperatureCritical | 
                |_____________________________________________| 


        2. BGP peering session transitions from a state of established 



Expires 22 April 2001                                          [Page 18] 





Internet Draft                 Alarm MIB                22 October 2000 


           to opensent 
                 __________________________________________________ 
                | alarmActiveTable                                 | 
                |--------------------------------------------------| 
                | alarmActiveIndex |  alarm                        | 
                |--------------------------------------------------| 
                |        1         | acmeWidgetTemperatureCritical | 
                |        2         | bgpBackwardTransition         | 
                |__________________________________________________| 
                 _____________________________________________ 
                | nlmLogTable                                 | 
                |---------------------------------------------| 
                | nlmLogIndex |  alarm                        | 
                |---------------------------------------------| 
                |      1      | acmeWidgetTemperatureCritical | 
                |      2      | bgpBackwardTransition         | 
                |_____________________________________________| 


        3. Temperature of widget 2 goes back to normal 
                 __________________________________________________ 
                | alarmActiveTable                                 | 
                |--------------------------------------------------| 
                | alarmActiveIndex |  alarm                        | 
                |--------------------------------------------------| 
                |        2         | bgpBackwardTransition         | 
                |__________________________________________________| 
                 _____________________________________________ 
                | nlmLogTable                                 | 
                |---------------------------------------------| 
                | nlmLogIndex |  alarm                        | 
                |---------------------------------------------| 
                |      1      | acmeWidgetTemperatureCritical | 
                |      2      | bgpBackwardTransition         | 
                |      3      | acmeWidgetTemperatureNormal   | 
                |_____________________________________________| 


        4. Time passes .... BGP alarm ages out. 
                 __________________________________________________ 
                | alarmActiveTable                                 | 
                |--------------------------------------------------| 
                | alarmActiveIndex |  alarm                        | 
                |--------------------------------------------------| 
                |__________________________________________________| 


From owner-disman@dorothy.bmc.com  Wed Nov 29 13:08:49 2000
Received: from tattler.bmc.com (fw-us-hou-2.bmc.com [198.207.223.251])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA05199
	for <disman-archive@odin.ietf.org>; Wed, 29 Nov 2000 13:08:48 -0500 (EST)
Received: from dorothy.bmc.com (localhost [127.0.0.1])
	by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id eATHtIL20278;
	Wed, 29 Nov 2000 11:55:19 -0600 (CST)
Received: (from root@localhost)
	by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id JAA08483
	for disman-list; Wed, 29 Nov 2000 09:50:34 -0800 (PST)
Received: (from rpresuhn@localhost)
	by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id JAA08477
	for disman@dorothy.bmc.com; Wed, 29 Nov 2000 09:50:31 -0800 (PST)
Date: Wed, 29 Nov 2000 09:50:31 -0800 (PST)
From: Randy Presuhn <rpresuhn@dorothy.bmc.com>
Message-Id: <200011291750.JAA08477@dorothy.bmc.com>
To: disman@dorothy.bmc.com
Subject: RE: Will there be a DISMAN slot at the IETF Mtg in San Diego?
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-disman@dorothy.bmc.com
Precedence: bulk
List-Id: IETF disman Working Group mailing list <disman@dorothy.bmc.com>
X-MIME-Autoconverted: from 8bit to quoted-printable by tattler.bmc.com id eATHtIL20278
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id NAA05199


Hi -

There is no scheduled disman meeting in San Diego.

The deadline for requesting meeting slots is long past.
There were no requests for a meeting prior to the deadline.
As for the items currently on our plate, if we can't handle
them by email, we should simply go dormant.

 -------------------------------------------------------
 Randy Presuhn           randy_presuhn@bmc.com
 Voice: +1 408 546-1006  BMC Software, Inc.  1-3141
 Fax:   +1 408 965-0359  2141 North First Street
 http://www.bmc.com/     San José, California 95131  USA
 -------------------------------------------------------
 My opinions and BMC's are independent variables.
 -------------------------------------------------------


From owner-disman@dorothy.bmc.com  Wed Nov 29 15:10:48 2000
Received: from tattler.bmc.com (fw-us-hou-2.bmc.com [198.207.223.251])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA16209
	for <disman-archive@odin.ietf.org>; Wed, 29 Nov 2000 15:10:47 -0500 (EST)
Received: from dorothy.bmc.com (localhost [127.0.0.1])
	by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id eATK5Yk25708;
	Wed, 29 Nov 2000 14:05:35 -0600 (CST)
Received: (from root@localhost)
	by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id MAA09165
	for disman-list; Wed, 29 Nov 2000 12:05:01 -0800 (PST)
Received: (from rpresuhn@localhost)
	by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id MAA09159
	for disman@dorothy.bmc.com; Wed, 29 Nov 2000 12:04:58 -0800 (PST)
Date: Wed, 29 Nov 2000 12:04:58 -0800 (PST)
From: Randy Presuhn <rpresuhn@dorothy.bmc.com>
Message-Id: <200011292004.MAA09159@dorothy.bmc.com>
To: disman@dorothy.bmc.com
Subject: Proposed disman charter addition: alarm tracking
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-disman@dorothy.bmc.com
Precedence: bulk
List-Id: IETF disman Working Group mailing list <disman@dorothy.bmc.com>
X-MIME-Autoconverted: from 8bit to quoted-printable by tattler.bmc.com id eATK5Yk25708
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id PAA16209


Hi -

Several people have read Sharon's draft and made substantive
comments to this list.  As working group chair, I'd like to
determine whether we have a consensus to request of our ADs
that this deliverable be added to our charter.  (The work
falls squarely within the existing scope of the charter,
in my opinion, so the only real question in my mind is
whether we have sufficient commitment in the group to
deliver a standards-track document.)

We should have one-or-two line description of the deliverables
and dates.  Here's a strawman, pulled out of the air:

   April, 2001: WG last call on Alarm Management MIB

   May, 2001: Alarm Management MIB delivered to IESG for
              consideration as proposed standard.

Sharon would be my choice as the document's editor.

Are these dates reasonable?  For example, should the scope
be expanded to include interworking with some non-SNMP
technologies?

 -------------------------------------------------------
 Randy Presuhn           randy_presuhn@bmc.com
 Voice: +1 408 546-1006  BMC Software, Inc.  1-3141
 Fax:   +1 408 965-0359  2141 North First Street
 http://www.bmc.com/     San José, California 95131  USA
 -------------------------------------------------------
 My opinions and BMC's are independent variables.
 -------------------------------------------------------


From owner-disman@dorothy.bmc.com  Wed Nov 29 15:31:26 2000
Received: from tattler.bmc.com (fw-us-hou-1.bmc.com [198.207.223.250])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA22166
	for <disman-archive@odin.ietf.org>; Wed, 29 Nov 2000 15:31:21 -0500 (EST)
Received: from dorothy.bmc.com (localhost [127.0.0.1])
	by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id eATKRrN01419;
	Wed, 29 Nov 2000 14:27:53 -0600 (CST)
Received: (from root@localhost)
	by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id MAA09411
	for disman-list; Wed, 29 Nov 2000 12:28:18 -0800 (PST)
Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117])
	by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id MAA09405;
	Wed, 29 Nov 2000 12:28:14 -0800 (PST)
Received: from fw-us-hou1.bmc.com (localhost [127.0.0.1])
	by tattler.bmc.com (8.10.2/8.10.2) with SMTP id eATKROS01273;
	Wed, 29 Nov 2000 14:27:24 -0600 (CST)
Received: from [129.250.38.56] (helo=dfw-corpmmp1.email.verio.net)
	by dfw-smtpout1.email.verio.net with esmtp
	id 141DqY-0007FB-00; Wed, 29 Nov 2000 20:28:54 +0000
Received: from [216.35.168.254] (helo=cwk)
	by dfw-corpmmp1.email.verio.net with smtp
	id 141DqY-0004Da-00; Wed, 29 Nov 2000 20:28:54 +0000
From: "Carl W. Kalbfleisch" <cwk@verio.net>
To: "Randy Presuhn" <rpresuhn@dorothy.bmc.com>, <disman@dorothy.bmc.com>
Subject: RE: Proposed disman charter addition: alarm tracking
Date: Wed, 29 Nov 2000 14:34:44 -0600
Message-ID: <NDBBLANGKLMBKIHPCGAMMEPEIEAA.cwk@verio.net>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <200011292004.MAA09159@dorothy.bmc.com>
Sender: owner-disman@dorothy.bmc.com
Precedence: bulk
List-Id: IETF disman Working Group mailing list <disman@dorothy.bmc.com>
X-MIME-Autoconverted: from 8bit to quoted-printable by tattler.bmc.com id eATKRrN01419
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id PAA22166



Sounds reasonable to me. Does this mean disman would meet in March to review
this document?

Carl

> -----Original Message-----
> From: owner-disman@dorothy.bmc.com
> [mailto:owner-disman@dorothy.bmc.com]On Behalf Of Randy Presuhn
> Sent: Wednesday, November 29, 2000 2:05 PM
> To: disman@dorothy.bmc.com
> Subject: Proposed disman charter addition: alarm tracking
>
>
>
> Hi -
>
> Several people have read Sharon's draft and made substantive
> comments to this list.  As working group chair, I'd like to
> determine whether we have a consensus to request of our ADs
> that this deliverable be added to our charter.  (The work
> falls squarely within the existing scope of the charter,
> in my opinion, so the only real question in my mind is
> whether we have sufficient commitment in the group to
> deliver a standards-track document.)
>
> We should have one-or-two line description of the deliverables
> and dates.  Here's a strawman, pulled out of the air:
>
>    April, 2001: WG last call on Alarm Management MIB
>
>    May, 2001: Alarm Management MIB delivered to IESG for
>               consideration as proposed standard.
>
> Sharon would be my choice as the document's editor.
>
> Are these dates reasonable?  For example, should the scope
> be expanded to include interworking with some non-SNMP
> technologies?
>
>  -------------------------------------------------------
>  Randy Presuhn           randy_presuhn@bmc.com
>  Voice: +1 408 546-1006  BMC Software, Inc.  1-3141
>  Fax:   +1 408 965-0359  2141 North First Street
>  http://www.bmc.com/     San José, California 95131  USA
>  -------------------------------------------------------
>  My opinions and BMC's are independent variables.
>  -------------------------------------------------------



From owner-disman@dorothy.bmc.com  Wed Nov 29 16:08:18 2000
Received: from tattler.bmc.com (fw-us-hou-1.bmc.com [198.207.223.250])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA05372
	for <disman-archive@odin.ietf.org>; Wed, 29 Nov 2000 16:08:17 -0500 (EST)
Received: from dorothy.bmc.com (localhost [127.0.0.1])
	by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id eATL4HW10809;
	Wed, 29 Nov 2000 15:04:17 -0600 (CST)
Received: (from root@localhost)
	by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id NAA09550
	for disman-list; Wed, 29 Nov 2000 13:04:39 -0800 (PST)
Received: (from rpresuhn@localhost)
	by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id NAA09533
	for disman@dorothy.bmc.com; Wed, 29 Nov 2000 13:04:35 -0800 (PST)
Date: Wed, 29 Nov 2000 13:04:35 -0800 (PST)
From: Randy Presuhn <rpresuhn@dorothy.bmc.com>
Message-Id: <200011292104.NAA09533@dorothy.bmc.com>
To: disman@dorothy.bmc.com
Subject: RE: Proposed disman charter addition: alarm tracking
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-disman@dorothy.bmc.com
Precedence: bulk
List-Id: IETF disman Working Group mailing list <disman@dorothy.bmc.com>
X-MIME-Autoconverted: from 8bit to quoted-printable by tattler.bmc.com id eATL4HW10809
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id QAA05372


Hi -

> From: "Carl W. Kalbfleisch" <cwk@verio.net>
> To: "Randy Presuhn" <rpresuhn@dorothy.bmc.com>, <disman@dorothy.bmc.com>
> Subject: RE: Proposed disman charter addition: alarm tracking
> Date: Wed, 29 Nov 2000 14:34:44 -0600
> Message-ID: <NDBBLANGKLMBKIHPCGAMMEPEIEAA.cwk@verio.net>
> In-Reply-To: <200011292004.MAA09159@dorothy.bmc.com>
> 
> 
> Sounds reasonable to me. Does this mean disman would meet in March to review
> this document?
> 
> Carl
...

If necessary.  I would hope that we'd have everything agreed
on the mailing list before then.

 -------------------------------------------------------
 Randy Presuhn           randy_presuhn@bmc.com
 Voice: +1 408 546-1006  BMC Software, Inc.  1-3141
 Fax:   +1 408 965-0359  2141 North First Street
 http://www.bmc.com/     San José, California 95131  USA
 -------------------------------------------------------
 My opinions and BMC's are independent variables.
 -------------------------------------------------------


From owner-disman@dorothy.bmc.com  Wed Nov 29 19:25:43 2000
Received: from tattler.bmc.com (fw-us-hou-1.bmc.com [198.207.223.250])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA13532
	for <disman-archive@odin.ietf.org>; Wed, 29 Nov 2000 19:25:42 -0500 (EST)
Received: from dorothy.bmc.com (localhost [127.0.0.1])
	by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id eAU0LZB28534;
	Wed, 29 Nov 2000 18:21:35 -0600 (CST)
Received: (from root@localhost)
	by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id QAA10042
	for disman-list; Wed, 29 Nov 2000 16:21:02 -0800 (PST)
Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117])
	by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id QAA10034;
	Wed, 29 Nov 2000 16:20:58 -0800 (PST)
Received: from fw-us-hou1.bmc.com (localhost [127.0.0.1])
	by tattler.bmc.com (8.10.2/8.10.2) with SMTP id eAU0Jru28062;
	Wed, 29 Nov 2000 18:20:08 -0600 (CST)
Received: from dperkins-nb1 ([24.15.219.251]) by femail7.sdc1.sfba.home.com
          (InterMail vM.4.01.03.00 201-229-121) with SMTP
          id <20001130002116.CEYE13245.femail7.sdc1.sfba.home.com@dperkins-nb1>;
          Wed, 29 Nov 2000 16:21:16 -0800
Message-Id: <4.1.20001129153932.00be6a10@mail.scruznet.com>
X-Sender: dperkins@mail.scruznet.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Wed, 29 Nov 2000 16:20:37 -0800
To: Randy Presuhn <rpresuhn@dorothy.bmc.com>, disman@dorothy.bmc.com
From: "David T. Perkins" <dperkins@dsperkins.com>
Subject: Re: Proposed disman charter addition: alarm tracking
In-Reply-To: <200011292004.MAA09159@dorothy.bmc.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-disman@dorothy.bmc.com
Precedence: bulk
List-Id: IETF disman Working Group mailing list <disman@dorothy.bmc.com>


HI,

On one hand, the need for a MIB covering this subject area is great
and is a topic that is reoccuring on several of the SNMP mailing
lists and the SNMP news group. On the other hand, I believe the
ITU-T documents on which the Sharon's MIB is a based are "fatally flawed",
and these flaws are carried forward in Sharon's document.
Additionally, the approach that is used to implement a union,
which is a reuse of a design pattern used in other disman MIB
modules, has very bad performance characteristics for bulk
retrieval. I believe that after an IETF standards track alarm
MIB module is defined (and the definition allows highly efficient
implementation on an agent system AND low cost useage by management
applications), then this will be the most useful and widely
implemented set of objects!

Thus, I support adding an Alarm MIB module as a work item for
the DISMAN group, but do not support using the contribution
by Sharon without extensive modification. Before the MIB module
should be written, the model needs to be described, which
has not been done in the contribution. This is really needed
due to differing uses of the "alarm" (and associated) terminology
and differing alarm models by vendors. 

The suggested schedule looks too agressive to me. I believe
that it should be extended by a 3 months and that time used
to develop a separate document that describes the model
(or include the description in the MIB module document).

Regards,
/david t. perkins

At 12:04 PM 11/29/2000 -0800, Randy Presuhn wrote:
>
>Hi -
>
>Several people have read Sharon's draft and made substantive
>comments to this list.  As working group chair, I'd like to
>determine whether we have a consensus to request of our ADs
>that this deliverable be added to our charter.  (The work
>falls squarely within the existing scope of the charter,
>in my opinion, so the only real question in my mind is
>whether we have sufficient commitment in the group to
>deliver a standards-track document.)
>
>We should have one-or-two line description of the deliverables
>and dates.  Here's a strawman, pulled out of the air:
>
>   April, 2001: WG last call on Alarm Management MIB
>
>   May, 2001: Alarm Management MIB delivered to IESG for
>              consideration as proposed standard.
>
>Sharon would be my choice as the document's editor.
>
>Are these dates reasonable?  For example, should the scope
>be expanded to include interworking with some non-SNMP
>technologies?
>
> -------------------------------------------------------
> Randy Presuhn           randy_presuhn@bmc.com



From owner-disman@dorothy.bmc.com  Thu Nov 30 00:23:20 2000
Received: from tattler.bmc.com (fw-us-hou-1.bmc.com [198.207.223.250])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA27614
	for <disman-archive@odin.ietf.org>; Thu, 30 Nov 2000 00:23:20 -0500 (EST)
Received: from dorothy.bmc.com (localhost [127.0.0.1])
	by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id eAU5FU911607;
	Wed, 29 Nov 2000 23:15:30 -0600 (CST)
Received: (from root@localhost)
	by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id VAA10575
	for disman-list; Wed, 29 Nov 2000 21:15:28 -0800 (PST)
Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117])
	by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id VAA10570
	for <disman@dorothy.bmc.com>; Wed, 29 Nov 2000 21:15:23 -0800 (PST)
Received: from fw-us-hou1.bmc.com (localhost [127.0.0.1])
	by tattler.bmc.com (8.10.2/8.10.2) with SMTP id eAU5EZ011453
	for <disman@dorothy.bmc.com>; Wed, 29 Nov 2000 23:14:35 -0600 (CST)
Received: from bnatale.acecomm.com (dhcppm12.acec.com [38.249.211.234])
	by relay1.acec.com (8.9.3/8.9.3) with ESMTP id AAA19310;
	Thu, 30 Nov 2000 00:15:43 -0500 (EST)
Message-Id: <5.0.1.4.2.20001130001644.01e2ee90@plymouth.acec.com>
X-Sender: bnatale@plymouth.acec.com
X-Mailer: QUALCOMM Windows Eudora Version 5.0.1
Date: Thu, 30 Nov 2000 00:19:00 -0500
To: "David T. Perkins" <dperkins@dsperkins.com>
From: Bob Natale <bnatale@acecomm.com>
Subject: Re: Proposed disman charter addition: alarm tracking
Cc: disman@dorothy.bmc.com
In-Reply-To: <4.1.20001129153932.00be6a10@mail.scruznet.com>
References: <200011292004.MAA09159@dorothy.bmc.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-disman@dorothy.bmc.com
Precedence: bulk
List-Id: IETF disman Working Group mailing list <disman@dorothy.bmc.com>


At 11/29/2000:07:20 PM, David T. Perkins wrote:

Hi Dave,

>On one hand, the need for a MIB covering this subject area is great

I agree.

><...>
>On the other hand, I believe the ITU-T documents on which the Sharon's
>MIB is a based are "fatally flawed", and these flaws are carried forward
>in Sharon's document.

Could you please outline those fatal flaws...?

Thanks,

BobN



From owner-disman@dorothy.bmc.com  Thu Nov 30 02:34:58 2000
Received: from tattler.bmc.com (fw-us-hou-1.bmc.com [198.207.223.250])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA15292
	for <disman-archive@odin.ietf.org>; Thu, 30 Nov 2000 02:34:57 -0500 (EST)
Received: from dorothy.bmc.com (localhost [127.0.0.1])
	by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id eAU7RT100377;
	Thu, 30 Nov 2000 01:27:29 -0600 (CST)
Received: (from root@localhost)
	by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id XAA10797
	for disman-list; Wed, 29 Nov 2000 23:26:49 -0800 (PST)
Received: (from rpresuhn@localhost)
	by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id XAA10791
	for disman@dorothy.bmc.com; Wed, 29 Nov 2000 23:26:46 -0800 (PST)
Date: Wed, 29 Nov 2000 23:26:46 -0800 (PST)
From: Randy Presuhn <rpresuhn@dorothy.bmc.com>
Message-Id: <200011300726.XAA10791@dorothy.bmc.com>
To: disman@dorothy.bmc.com
Subject: Re: Proposed disman charter addition: alarm tracking
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-disman@dorothy.bmc.com
Precedence: bulk
List-Id: IETF disman Working Group mailing list <disman@dorothy.bmc.com>
X-MIME-Autoconverted: from 8bit to quoted-printable by tattler.bmc.com id eAU7RT100377
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id CAA15292


Hi -

> Message-Id: <5.0.1.4.2.20001130001644.01e2ee90@plymouth.acec.com>
> Date: Thu, 30 Nov 2000 00:19:00 -0500
> To: "David T. Perkins" <dperkins@dsperkins.com>
> From: Bob Natale <bnatale@acecomm.com>
> Subject: Re: Proposed disman charter addition: alarm tracking
> Cc: disman@dorothy.bmc.com
> In-Reply-To: <4.1.20001129153932.00be6a10@mail.scruznet.com>
> References: <200011292004.MAA09159@dorothy.bmc.com>
... 
> At 11/29/2000:07:20 PM, David T. Perkins wrote:
...
> >On the other hand, I believe the ITU-T documents on which the Sharon's
> >MIB is a based are "fatally flawed", and these flaws are carried forward
> >in Sharon's document.
> 
> Could you please outline those fatal flaws...?
...

Indeed, that would be useful.  I'd be happy to forward the
information to the folks in NCITS T3 who handle the US part
in the maintenance of these ITU-T recommendations.

 -------------------------------------------------------
 Randy Presuhn           randy_presuhn@bmc.com
 Voice: +1 408 546-1006  BMC Software, Inc.  1-3141
 Fax:   +1 408 965-0359  2141 North First Street
 http://www.bmc.com/     San José, California 95131  USA
 -------------------------------------------------------
 My opinions and BMC's are independent variables.
 -------------------------------------------------------


From owner-disman@dorothy.bmc.com  Thu Nov 30 05:00:25 2000
Received: from tattler.bmc.com (fw-us-hou-1.bmc.com [198.207.223.250])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA08455
	for <disman-archive@odin.ietf.org>; Thu, 30 Nov 2000 05:00:24 -0500 (EST)
Received: from dorothy.bmc.com (localhost [127.0.0.1])
	by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id eAU9tlI26963;
	Thu, 30 Nov 2000 03:55:48 -0600 (CST)
Received: (from root@localhost)
	by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id BAA11006
	for disman-list; Thu, 30 Nov 2000 01:55:25 -0800 (PST)
Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117])
	by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id BAA11000;
	Thu, 30 Nov 2000 01:55:21 -0800 (PST)
Received: from fw-us-hou1.bmc.com (localhost [127.0.0.1])
	by tattler.bmc.com (8.10.2/8.10.2) with SMTP id eAU9sXm26756;
	Thu, 30 Nov 2000 03:54:33 -0600 (CST)
Received: from henkell.ibr.cs.tu-bs.de (schoenw@henkell [134.169.34.191])
	by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) with ESMTP id KAA24499;
	Thu, 30 Nov 2000 10:56:12 +0100 (MET)
Received: from schoenw@localhost by henkell.ibr.cs.tu-bs.de (8.7.6/tubsibr) id KAA18814; Thu, 30 Nov 2000 10:56:12 +0100
Date: Thu, 30 Nov 2000 10:56:12 +0100
Message-Id: <200011300956.KAA18814@henkell.ibr.cs.tu-bs.de>
From: Juergen Schoenwaelder <schoenw@ibr.cs.tu-bs.de>
To: rpresuhn@dorothy.bmc.com
CC: disman@dorothy.bmc.com
In-reply-to: <200011292004.MAA09159@dorothy.bmc.com> (message from Randy
	Presuhn on Wed, 29 Nov 2000 12:04:58 -0800 (PST))
Subject: Re: Proposed disman charter addition: alarm tracking
References:  <200011292004.MAA09159@dorothy.bmc.com>
Sender: owner-disman@dorothy.bmc.com
Precedence: bulk
List-Id: IETF disman Working Group mailing list <disman@dorothy.bmc.com>



>>>>> Randy Presuhn writes:

Randy> Several people have read Sharon's draft and made substantive
Randy> comments to this list.  As working group chair, I'd like to
Randy> determine whether we have a consensus to request of our ADs
Randy> that this deliverable be added to our charter.

As I said earlier, I believe that this is an important missing piece.
However, I previously aired concerns about the model used in Sharon's
draft to define what an alarm really is.

Regarding the ITU alarm work, I think it is worthwhile to align this
piece of work as much as possible with the ITU alarm models since I
believe that the ITU alarm model has seen quite a bit of usage in the
telco world. In fact, I have been talking to several operators that
require to translate notifications into ITU alarms - which is not
always nice an easy to do. Working out an alarm model for the SNMP
community should make such mappings simpler and more consistent.

Summary: I believe this work should be done (in this WG or elsewhere)
and Sharon's draft is just a starting point. I have doubts that this
can be finished by the next IETF if we want to get it right. I also
think it is crucial to get the right group of knowledgeable people
together to do this in a timely manner.

/js

-- 
Juergen Schoenwaelder      Technical University Braunschweig
<schoenw@ibr.cs.tu-bs.de>  Dept. Operating Systems & Computer Networks
Phone: +49 531 391 3289    Bueltenweg 74/75, 38106 Braunschweig, Germany
Fax:   +49 531 391 5936    <URL:http://www.ibr.cs.tu-bs.de/~schoenw/>




From owner-disman@dorothy.bmc.com  Thu Nov 30 08:54:46 2000
Received: from tattler.bmc.com (fw-us-hou-1.bmc.com [198.207.223.250])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA11725
	for <disman-archive@odin.ietf.org>; Thu, 30 Nov 2000 08:54:46 -0500 (EST)
Received: from dorothy.bmc.com (localhost [127.0.0.1])
	by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id eAUDo6l07007;
	Thu, 30 Nov 2000 07:50:06 -0600 (CST)
Received: (from root@localhost)
	by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id FAA11499
	for disman-list; Thu, 30 Nov 2000 05:48:11 -0800 (PST)
Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117])
	by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id FAA11493;
	Thu, 30 Nov 2000 05:48:07 -0800 (PST)
Received: from fw-us-hou1.bmc.com (localhost [127.0.0.1])
	by tattler.bmc.com (8.10.2/8.10.2) with SMTP id eAUDlJ006536;
	Thu, 30 Nov 2000 07:47:19 -0600 (CST)
Received: by itc-eml2.lannet.com with Internet Mail Service (5.5.2650.21)
	id <XMMDZ7PA>; Thu, 30 Nov 2000 09:56:13 +0200
Message-ID: <15F58915DF84D311AC7D0090279AA614234193@itc-eml2.lannet.com>
From: Dan Romascanu <dromasca@avaya.com>
To: "'Randy Presuhn'" <rpresuhn@dorothy.bmc.com>, disman@dorothy.bmc.com
Subject: RE: Proposed disman charter addition: alarm tracking
Date: Thu, 30 Nov 2000 09:56:12 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
X-MIME-Autoconverted: from quoted-printable to 8bit by dorothy.bmc.com id FAA11494
Sender: owner-disman@dorothy.bmc.com
Precedence: bulk
List-Id: IETF disman Working Group mailing list <disman@dorothy.bmc.com>
X-MIME-Autoconverted: from 8bit to quoted-printable by tattler.bmc.com id eAUDo6l07007
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id IAA11725


	Randy,

	I support the proposal for inclusion of this deliverable in the
DISMAN Charter, and I commit some of my few remaining cycles to work on
this.

	I tend to agree with Dave Perkins that the dates are too aggressive,
especially as we missed the opportunity to meet in San Diego and work on
this proposal. I suggest to move the dates for Last Call and IESG delivery
for after the summer IETF meeting.

	Regards,

	Dan
	 
> Hi -
> 
> Several people have read Sharon's draft and made substantive
> comments to this list.  As working group chair, I'd like to
> determine whether we have a consensus to request of our ADs
> that this deliverable be added to our charter.  (The work
> falls squarely within the existing scope of the charter,
> in my opinion, so the only real question in my mind is
> whether we have sufficient commitment in the group to
> deliver a standards-track document.)
> 
> We should have one-or-two line description of the deliverables
> and dates.  Here's a strawman, pulled out of the air:
> 
>    April, 2001: WG last call on Alarm Management MIB
> 
>    May, 2001: Alarm Management MIB delivered to IESG for
>               consideration as proposed standard.
> 
> Sharon would be my choice as the document's editor.
> 
> Are these dates reasonable?  For example, should the scope
> be expanded to include interworking with some non-SNMP
> technologies?
> 
>  -------------------------------------------------------
>  Randy Presuhn           randy_presuhn@bmc.com
>  Voice: +1 408 546-1006  BMC Software, Inc.  1-3141
>  Fax:   +1 408 965-0359  2141 North First Street
>  http://www.bmc.com/     San José, California 95131  USA
>  -------------------------------------------------------
>  My opinions and BMC's are independent variables.
>  -------------------------------------------------------


From owner-disman@dorothy.bmc.com  Thu Nov 30 08:54:50 2000
Received: from tattler.bmc.com (fw-us-hou-1.bmc.com [198.207.223.250])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA11774
	for <disman-archive@odin.ietf.org>; Thu, 30 Nov 2000 08:54:49 -0500 (EST)
Received: from dorothy.bmc.com (localhost [127.0.0.1])
	by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id eAUDo6g07008;
	Thu, 30 Nov 2000 07:50:06 -0600 (CST)
Received: (from root@localhost)
	by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id FAA11507
	for disman-list; Thu, 30 Nov 2000 05:48:16 -0800 (PST)
Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117])
	by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id FAA11501;
	Thu, 30 Nov 2000 05:48:12 -0800 (PST)
Received: from fw-us-hou1.bmc.com (localhost [127.0.0.1])
	by tattler.bmc.com (8.10.2/8.10.2) with SMTP id eAUDlMm06559;
	Thu, 30 Nov 2000 07:47:22 -0600 (CST)
Received: by itc-eml2.lannet.com with Internet Mail Service (5.5.2650.21)
	id <XMMDZ7PB>; Thu, 30 Nov 2000 10:04:38 +0200
Message-ID: <15F58915DF84D311AC7D0090279AA614234194@itc-eml2.lannet.com>
From: Dan Romascanu <dromasca@avaya.com>
To: "'Randy Presuhn'" <rpresuhn@dorothy.bmc.com>, disman@dorothy.bmc.com
Subject: RE: Proposed disman charter addition: alarm tracking
Date: Thu, 30 Nov 2000 10:04:37 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain
Sender: owner-disman@dorothy.bmc.com
Precedence: bulk
List-Id: IETF disman Working Group mailing list <disman@dorothy.bmc.com>


> > >On the other hand, I believe the ITU-T documents on which the Sharon's
> > >MIB is a based are "fatally flawed", and these flaws are carried
> forward
> > >in Sharon's document.
> > 
> > Could you please outline those fatal flaws...?
> ...
> 
> Indeed, that would be useful.  I'd be happy to forward the
> information to the folks in NCITS T3 who handle the US part
> in the maintenance of these ITU-T recommendations.
> 
>  Randy, 
> 
	Do you intent to include the reference to these ITU-T documents in
the Charter? I am not yet convinced whether this would be a good thing or a
bad thing. On one side, I know where Sharon comes from when she tries to be
close to these requirements. On the other side if there are serious flaws as
Dave seems to try to prove - maybe we should avoid committing to any
specific architecture at this stage, with the exception of course of the
SNMP framework and other work within DISMAN.

	Regards,

	Dan
>  


From owner-disman@dorothy.bmc.com  Thu Nov 30 10:15:56 2000
Received: from tattler.bmc.com (fw-us-hou-1.bmc.com [198.207.223.250])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA16522
	for <disman-archive@odin.ietf.org>; Thu, 30 Nov 2000 10:15:56 -0500 (EST)
Received: from dorothy.bmc.com (localhost [127.0.0.1])
	by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id eAUF4SK25453;
	Thu, 30 Nov 2000 09:04:28 -0600 (CST)
Received: (from root@localhost)
	by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id HAA11655
	for disman-list; Thu, 30 Nov 2000 07:03:01 -0800 (PST)
Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117])
	by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id HAA11648
	for <disman@dorothy.bmc.com>; Thu, 30 Nov 2000 07:02:57 -0800 (PST)
Received: from fw-us-hou1.bmc.com (localhost [127.0.0.1])
	by tattler.bmc.com (8.10.2/8.10.2) with SMTP id eAUF29S24925
	for <disman@dorothy.bmc.com>; Thu, 30 Nov 2000 09:02:09 -0600 (CST)
Received: from hansa.ibr.cs.tu-bs.de (IDENT:root@hansa [134.169.34.137])
	by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) with ESMTP id QAA18025;
	Thu, 30 Nov 2000 16:03:41 +0100 (MET)
Received: (from strauss@localhost)
	by hansa.ibr.cs.tu-bs.de (8.9.3/8.9.3) id QAA20470;
	Thu, 30 Nov 2000 16:03:40 +0100
X-Authentication-Warning: hansa.ibr.cs.tu-bs.de: strauss set sender to strauss@ibr.cs.tu-bs.de using -f
From: Frank Strauss <strauss@ibr.cs.tu-bs.de>
To: disman@dorothy.bmc.com
Subject: Comments on RFC 2591
Date: 30 Nov 2000 16:03:40 +0100
Message-ID: <ypwy9y1ec37.fsf@hansa.ibr.cs.tu-bs.de>
Lines: 28
User-Agent: Gnus/5.0803 (Gnus v5.8.3) Emacs/20.7
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-disman@dorothy.bmc.com
Precedence: bulk
List-Id: IETF disman Working Group mailing list <disman@dorothy.bmc.com>


Hi!

Reading RFC 2591 (Schedule MIB) I came up with the following questions
and comments.

1. When an action is raised, does this mean that an SNMP Set message is
   sent to the local agent or is the Set operation expected to be handled
   internally? I assume the latter, because isAccessAllowed() is mentioned
   in the schedValue description and in the security considerations.
   However, it should also be possible to send a SNMP Set message to the
   local agent and don't care about the access control issues. Maybe,
   a note should be added to clarify this.

2. When schedFailures are counted, does this count each failed action
   once or are multiple retries of a single action counted as well
   (which could probably happen if we would use SNMP)? I guess only the
   number of failed actions should be counted.

3. 5.2. explains a oneshot schedule. The last sentence bofore the list of
   varbinds should say `on the next Friday' instead of `on every Friday'.

4. The description of schedType says `Changing a schedule's type is
   equivalent to deleting the old-type schedule and creating a
   new-type one.' Does this mean that setting a schedType object to an
   already current value does not reset the schedFail* objects, while
   setting it to a different value does reset them?

 Frank


From owner-disman@dorothy.bmc.com  Thu Nov 30 10:52:57 2000
Received: from tattler.bmc.com (fw-us-hou-1.bmc.com [198.207.223.250])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA02392
	for <disman-archive@odin.ietf.org>; Thu, 30 Nov 2000 10:52:56 -0500 (EST)
Received: from dorothy.bmc.com (localhost [127.0.0.1])
	by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id eAUFfYJ05540;
	Thu, 30 Nov 2000 09:41:34 -0600 (CST)
Received: (from root@localhost)
	by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id HAA11735
	for disman-list; Thu, 30 Nov 2000 07:39:59 -0800 (PST)
Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117])
	by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id HAA11730
	for <disman@dorothy.bmc.com>; Thu, 30 Nov 2000 07:39:55 -0800 (PST)
Received: from fw-us-hou1.bmc.com (localhost [127.0.0.1])
	by tattler.bmc.com (8.10.2/8.10.2) with SMTP id eAUFd1k04898
	for <disman@dorothy.bmc.com>; Thu, 30 Nov 2000 09:39:01 -0600 (CST)
Received: from henkell.ibr.cs.tu-bs.de (schoenw@henkell [134.169.34.191])
	by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) with ESMTP id QAA20573;
	Thu, 30 Nov 2000 16:40:39 +0100 (MET)
Received: from schoenw@localhost by henkell.ibr.cs.tu-bs.de (8.7.6/tubsibr) id QAA21789; Thu, 30 Nov 2000 16:40:39 +0100
Date: Thu, 30 Nov 2000 16:40:39 +0100
Message-Id: <200011301540.QAA21789@henkell.ibr.cs.tu-bs.de>
From: Juergen Schoenwaelder <schoenw@ibr.cs.tu-bs.de>
To: strauss@ibr.cs.tu-bs.de
CC: disman@dorothy.bmc.com
In-reply-to: <ypwy9y1ec37.fsf@hansa.ibr.cs.tu-bs.de> (message from Frank
	Strauss on 30 Nov 2000 16:03:40 +0100)
Subject: Re: Comments on RFC 2591
References:  <ypwy9y1ec37.fsf@hansa.ibr.cs.tu-bs.de>
Sender: owner-disman@dorothy.bmc.com
Precedence: bulk
List-Id: IETF disman Working Group mailing list <disman@dorothy.bmc.com>



>>>>> Frank Strauss writes:

Frank> Reading RFC 2591 (Schedule MIB) I came up with the following
Frank> questions and comments.

Frank> 1. When an action is raised, does this mean that an SNMP Set
Frank> message is sent to the local agent or is the Set operation
Frank> expected to be handled internally? I assume the latter, because
Frank> isAccessAllowed() is mentioned in the schedValue description
Frank> and in the security considerations.  However, it should also be
Frank> possible to send a SNMP Set message to the local agent and
Frank> don't care about the access control issues. Maybe, a note
Frank> should be added to clarify this.

RFC 2591 only requires that the set operation goes through access
control. How you realize this is up to the implementor. With some
toolkits, one may do it via internal function calls. With other
toolkits, one may do it by injecting an SNMP message back into the
engine (which then will also apply access control).

Do you suggest that we say explicitely that there are different ways
to implement this? (Note that this is true for many things.) Do you
have a concrete proposal?

Frank> 2. When schedFailures are counted, does this count each failed
Frank> action once or are multiple retries of a single action counted
Frank> as well (which could probably happen if we would use SNMP)? I
Frank> guess only the number of failed actions should be counted.

The intention is that schedFailures is only incremented once per
triggered action, regardless whether the implementation internally
retries set operations (which is in most cases problematic anyway).
Does the following clarification help?

      "This variable counts the number of failures while invoking
       the scheduled action. This counter at most increments once
       for a triggered action."

Frank> 3. 5.2. explains a oneshot schedule. The last sentence bofore
Frank> the list of varbinds should say `on the next Friday' instead of
Frank> `on every Friday'.

Thanks. Fixed.

Frank> 4. The description of schedType says `Changing a schedule's
Frank> type is equivalent to deleting the old-type schedule and
Frank> creating a new-type one.' Does this mean that setting a
Frank> schedType object to an already current value does not reset the
Frank> schedFail* objects, while setting it to a different value does
Frank> reset them?

Yes, the text is not really precise. How about this:

      Changing a schedule's type is equivalent to deleting the
      old-type schedule and creating a new-type one, except that
      failure objects (schedFailures, schedLastFailure, and
      schedLastFailed) will keep their values.

/js

-- 
Juergen Schoenwaelder      Technical University Braunschweig
<schoenw@ibr.cs.tu-bs.de>  Dept. Operating Systems & Computer Networks
Phone: +49 531 391 3289    Bueltenweg 74/75, 38106 Braunschweig, Germany
Fax:   +49 531 391 5936    <URL:http://www.ibr.cs.tu-bs.de/~schoenw/>




From owner-disman@dorothy.bmc.com  Thu Nov 30 11:26:26 2000
Received: from tattler.bmc.com (fw-us-hou-1.bmc.com [198.207.223.250])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA19578
	for <disman-archive@odin.ietf.org>; Thu, 30 Nov 2000 11:26:21 -0500 (EST)
Received: from dorothy.bmc.com (localhost [127.0.0.1])
	by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id eAUGJ7T16991;
	Thu, 30 Nov 2000 10:19:07 -0600 (CST)
Received: (from root@localhost)
	by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id IAA11854
	for disman-list; Thu, 30 Nov 2000 08:18:30 -0800 (PST)
Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117])
	by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id IAA11849
	for <disman@dorothy.bmc.com>; Thu, 30 Nov 2000 08:18:26 -0800 (PST)
Received: from fw-us-hou1.bmc.com (localhost [127.0.0.1])
	by tattler.bmc.com (8.10.2/8.10.2) with SMTP id eAUGHX716521
	for <disman@dorothy.bmc.com>; Thu, 30 Nov 2000 10:17:35 -0600 (CST)
Received: from hansa.ibr.cs.tu-bs.de (IDENT:root@hansa [134.169.34.137])
	by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) with ESMTP id RAA23659;
	Thu, 30 Nov 2000 17:19:05 +0100 (MET)
Received: (from strauss@localhost)
	by hansa.ibr.cs.tu-bs.de (8.9.3/8.9.3) id RAA26068;
	Thu, 30 Nov 2000 17:19:05 +0100
X-Authentication-Warning: hansa.ibr.cs.tu-bs.de: strauss set sender to strauss@ibr.cs.tu-bs.de using -f
From: Frank Strauss <strauss@ibr.cs.tu-bs.de>
To: Juergen Schoenwaelder <schoenw@ibr.cs.tu-bs.de>
Cc: disman@dorothy.bmc.com
Subject: Re: Comments on RFC 2591
References: <ypwy9y1ec37.fsf@hansa.ibr.cs.tu-bs.de> <200011301540.QAA21789@henkell.ibr.cs.tu-bs.de>
Date: 30 Nov 2000 17:19:04 +0100
In-Reply-To: Juergen Schoenwaelder's message of "Thu, 30 Nov 2000 16:40:39 +0100"
Message-ID: <ypwitp5e8lj.fsf@hansa.ibr.cs.tu-bs.de>
Lines: 95
User-Agent: Gnus/5.0803 (Gnus v5.8.3) Emacs/20.7
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-disman@dorothy.bmc.com
Precedence: bulk
List-Id: IETF disman Working Group mailing list <disman@dorothy.bmc.com>


Frank> Reading RFC 2591 (Schedule MIB) I came up with the following
Frank> questions and comments.

Frank> 1. When an action is raised, does this mean that an SNMP Set
Frank> message is sent to the local agent or is the Set operation
Frank> expected to be handled internally? I assume the latter, because
Frank> isAccessAllowed() is mentioned in the schedValue description
Frank> and in the security considerations.  However, it should also be
Frank> possible to send a SNMP Set message to the local agent and
Frank> don't care about the access control issues. Maybe, a note
Frank> should be added to clarify this.

Juergen> RFC 2591 only requires that the set operation goes through access
Juergen> control. How you realize this is up to the implementor. With some
Juergen> toolkits, one may do it via internal function calls. With other
Juergen> toolkits, one may do it by injecting an SNMP message back into the
Juergen> engine (which then will also apply access control).

Juergen> Do you suggest that we say explicitely that there are different ways
Juergen> to implement this? (Note that this is true for many things.) Do you
Juergen> have a concrete proposal?

I suggest to change the description of schedValue from

            "The value which is written to the MIB object pointed to by
             schedVariable when the scheduler invokes an action. The
             implementation shall enforce the use of access control
             rules when performing the set operation on schedVariable.
             This is accomplished by calling the isAccessAllowed abstract
             service interface as defined in RFC 2271."

to something like

            "The value which is written to the MIB object pointed to
             by schedVariable when the scheduler invokes an action. If
             the implementation forwards the set operation internally
             for execution, it shall enforce the use of access control
             rules. This is accomplished by calling the
             isAccessAllowed abstract service interface as defined in
             RFC 2271. Alternatively, the implementation may choose to
             issue an SNMP Set message and leave the access control
             decision to the local agent's message processing."

Furthermore, the Security Considerations would have be changed to some
extent.

Frank> 2. When schedFailures are counted, does this count each failed
Frank> action once or are multiple retries of a single action counted
Frank> as well (which could probably happen if we would use SNMP)? I
Frank> guess only the number of failed actions should be counted.

Juergen> The intention is that schedFailures is only incremented once per
Juergen> triggered action, regardless whether the implementation internally
Juergen> retries set operations (which is in most cases problematic anyway).
Juergen> Does the following clarification help?

Juergen>       "This variable counts the number of failures while invoking
Juergen>        the scheduled action. This counter at most increments once
Juergen>        for a triggered action."

Fine with me.

Frank> 4. The description of schedType says `Changing a schedule's
Frank> type is equivalent to deleting the old-type schedule and
Frank> creating a new-type one.' Does this mean that setting a
Frank> schedType object to an already current value does not reset the
Frank> schedFail* objects, while setting it to a different value does
Frank> reset them?

Juergen> Yes, the text is not really precise. How about this:

Juergen>       Changing a schedule's type is equivalent to deleting the
Juergen>       old-type schedule and creating a new-type one, except that
Juergen>       failure objects (schedFailures, schedLastFailure, and
Juergen>       schedLastFailed) will keep their values.

Aha. This changes my understanding. ;-) My question was more concerned
about the word `changing' (in contrast to `writing' to a schedType
object). In other words: The things that happen and behave like
deleting the old entry and creating a new entry do only happen when I
write a value that differs from the current value. And they do not
happen if I write the current value again.  Is this right?

After all, I suggest to describe the behaviour explicitly instead of
in an `as if ... but ...' notation. How about

             When this object is written, any pending activations for
             this schedule are removed and re-calculated."

or what else is meant by `equivalent to deleting the old-type schedule
and creating a new-type one'?

Furthermore, a sentence like this should be added to the descriptions
of schedInterval, schedWeekDay, schedMonth, schedDay, schedHour, and
schedMinute, I guess.