Subject: FW: ARC MIB contribution for IETF disman WG

From: Randy Presuhn <[email-masked]>
Date: Fri, 23 Feb 2001 13:50:54 -0800 (PST)

Hi -

I'm forwarding another contribution for the disman WG.

|From [email-masked] Fri Feb 23 13:49:22 PST 2001
|Message-ID: <[email-masked]>
|From: "Huynh, An-Ni (Anni)" <[email-masked]>
|To: "[email-masked]'" <[email-masked]>
|Subject: FW: ARC MIB contribution for IETF disman WG
|Date: Fri, 23 Feb 2001 16:24:21 -0500
|
|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_000_01C09DDE.FCA5F8D0
|Content-Type: text/plain
|
|Randy:
|
|Just to make sure that my collegue sent it to the correct address.
|Thanks.
|
|Anni
|
|> -----Original Message-----
|> From: 	Lam, Hing-Kam (Kam)
|> Sent:	Friday, February 23, 2001 1:44 PM
|> To:	[email-masked]'
|> Cc:	'Randy Presuhn'
|> Subject:	ARC MIB contribution for IETF disman WG
|>
|> Attached is a contribution for the disman WG for the March IETF meeting.
|>
|> Title: Alarm Reporting Control MIB
|> File: draft-lam-disman-arcmib-00.txt
|> Authors: Kam Lam & An-ni Huynh (Lucent Technologies)
|>
|> Thank you for your consideration.
|>
|>  <<draft-lam-disman-arcmib-00.txt>>
|>
|> Regards,
|> Kam Lam
|> Lucent Technologies
|> 1 732-615-4118
|>
|
|
|------_=_NextPart_000_01C09DDE.FCA5F8D0
|Content-Type: text/plain;
|	name="draft-lam-disman-arcmib-00.txt"
|Content-Transfer-Encoding: 8bit
|Content-Disposition: attachment;
|	filename="draft-lam-disman-arcmib-00.txt"
|
|Disman Working Group                                             Kam Lam
|Expires August 23, 2001              ARC MIB                 An-ni Huynh
|Internet Draft                                       Lucent Technologies
|                                                       February 23, 2001
|
|
|
|
|
|
|                          Alarm Reporting Control MIB
|
|
|                         draft-lam-disman-arcMIB-00.txt
|
|
|Status of this Memo
|
|    This document is an Internet-Draft and is in full conformance with
|    all provisions of Section 10 of RFC2026 [RFC2026].
|
|    Internet-Drafts are working documents of the Internet Engineering
|    Task Force (IETF), its areas, and its working groups. Note that
|    other groups may also distribute working documents as
|    Internet-Drafts.
|
|    Internet-Drafts are draft documents valid for a maximum of six
|    months and may be updated, replaced, or obsoleted by other documents
|    at any time. It is inappropriate to use Internet-Drafts as reference
|    material or to cite them other than as "work in progress."
|
|    The list of current Internet-Drafts can be accessed at
|    http://www.ietf.org/ietf/1id-abstracts.txt.
|
|    The list of Internet-Draft Shadow Directories can be accessed at
|    http://www.ietf.org/shadow.html.
|
|
|Copyright Notice
|
|   Copyright (C) The Internet Society (2000).  All Rights Reserved.
|
|1.  Abstract
|
|   This memo defines a portion of the Management Information Base (MIB)
|   for use with network management protocols in TCP/IP-based internets.
|   In particular, it defines objects for controlling the reporting of
|   alarm conditions of a network device.
|
|   Textual Conventions used in this MIB are defined in [RFC2579].
|
|
|Table of Contents
|
|   1 Abstract ..............................................    1
|   2 The SNMP Network Management Framework .................    2
|   3 Overview   ............................................    2
|   3.1 ARC Terminology and Definition ......................    3
|   4 Object Definitions ....................................    4
|   5 Example Application   .................................    7
|   6 Security Considerations ...............................    7
|   7 Acknowledgments........................................    8
|   8 References ............................................    8
|   9 Author's Address ......................................    9
|   10 Intellectual Property ................................   10
|   Full Copyright Statement ................................   10
|
|2.  The SNMP Network Management Framework
|
|   The SNMP Management Framework presently consists of five major
|   components:
|
|   0    An overall architecture, described in RFC 2571 [RFC2571].
|
|   0    Mechanisms for describing and naming objects and events for the
|        purpose of management.  The first version of this Structure of
|        Management Information (SMI) is called SMIv1 and described in
|        STD 16, RFC 1155 [RFC1155], STD 16, RFC 1212 [RFC1212] and RFC
|        1215 [RFC1215].  The second version, called SMIv2, is described
|        in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and
|        STD 58, RFC 2580 [RFC2580].
|
|   0    Message protocols for transferring management information.  The
|        first version of the SNMP message protocol is called SNMPv1 and
|        described in STD 15, RFC 1157 [RFC1157].  A second version of
|        the SNMP message protocol, which is not an Internet standards
|        track protocol, is called SNMPv2c and described in RFC 1901
|        [RFC1901] and RFC 1906 [RFC1906].  The third version of the
|        message protocol is called SNMPv3 and described in RFC 1906
|        [RFC1906], RFC 2572 [RFC2572] and RFC 2574 [RFC2574].
|
|   0    Protocol operations for accessing management information.  The
|        first set of protocol operations and associated PDU formats is
|        described in STD 15, RFC 1157 [RFC1157].  A second set of
|        protocol operations and associated PDU formats is described in
|        RFC 1905 [RFC1905].
|
|   o   A set of fundamental applications described in RFC 2573
|        [RFC2573] and the view-based access control mechanism described
|        in RFC 2575 [RFC2575].
|
|   A more detailed introduction to the current SNMP Management Framework
|   can be found in RFC 2570 [RFC2570].
|
|   Managed objects are accessed via a virtual information store, termed
|   the Management Information Base or MIB.  Objects in the MIB are
|   defined using the mechanisms defined in the SMI.
|
|   This memo specifies a MIB module that is compliant to the SMIv2.  A
|   MIB conforming to the SMIv1 can be produced through the appropriate
|   translations.  The resulting translated MIB must be semantically
|   equivalent, except where objects or events are omitted because no
|   translation is possible (e.g., use of Counter64).  Some machine readable
|   information in SMIv2 will be converted into textual descriptions in
|   SMIv1 during the translation process.  However, this loss of machine
|   readable information is not considered to change the semantics of the
|   MIB.
|
| 3. Overview
|
|   There is a need to provide a mechanism for controlling the reporting of
|   alarm conditions of resources in a network device. For examples,
|   (a) inhibiting the reporting of alarm conditions of a resource until
|   the resource is problem-free, (b) inhibiting the reporting of alarm
|   conditions of a resource for a specified time period, or (c) inhibiting
|   the reporting of alarm conditions of a resource until explicitly allowed
|   later on by the managing system.
|
|   The alarm reporting control (ARC) feature provides an automatic in-service
|   provisioning capability. It allows sufficient time for service setup,
|   customer testing, and other maintenance activities in an "alarm-free" state.
|   Once a resource is "problem-free", alarm reporting is automatically
|   (or manually) turned on (i.e., allowed).
|
|   By putting a network resource in ARC mode, the technicians and managing
|   systems will not be flooded with unnecessary work items during operations
|   activities such as service provisioning and network setup/teardown.
|   This will reduce maintenance costs and improve the operation and maintenance
|   of these systems.
|
|   ITU-T Recommendation M.3100 Amendment 3 [M.3100 Amd3] provides the business
|   requirements, analysis, and design of the Alarm Reporting Control Feature.
|
|   This MIB module defines the SNMP objects to support a subset of the ARC
|   functions described in M.3100 Amd3. In particular, it defines a table that
|   contains the ARC setting for the resources in a system.
|
|   Management objects for defining and storing alarms, including active and
|   history alarms, standing and transient alarms, are described in the Alarm
|   MIB, ITU Alarm MIB, and Condition MIB.
|
|
|3.1 ARC Terminology and Definition
|
|   Alarm Reporting Control (ARC) - M.3100 Amd3
|	Alarm Report Control is a feature that provides an automatic in-service
|	provisioning capability.  Alarm reporting is turned off on a
|	per-resource basis for a selective set of alarm types (i.e.,
|	potential alarm conditions) to allow sufficient time for customer
|	testing and other maintenance activities in an "alarm free" state.
|	Once a resource is ready for service , alarm reporting
|	is automatically (or manually) turned on.
|
|   ARC State
|	The ARC feature provides the following states for a resource:
|
|	ALM:     	Alarm reporting is turned on (i.e., is allowed).
|	NALM:    	Alarm reporting is turned off.
|	NALM-TI: 	Alarm reporting is turned off for a time interval.
|			(TI - Time Inhibit).
|	NALM-QI: 	Alarm reporting is turned off for a selected set of
|			alarm types until the resource is qualified problem-free
|			for a specified persistence interval.
|			Problem-free means that none of the conditions
|			corresponding to the selected alarm types exist.
|			(QI - Qualified Inhibit).
|	NALM-QI-CD:	This is a substate of NALM-QI and performs the
|			persistence timing count down function after the
|			resource is qualified problem-free.
|			(CD - Count Down).
|
|	According to the requirements in M.3100 Amd3, a resource
|	supporting the ARC feature shall support the ALM state and at least
|	one of the NALM, NALM-TI, and NALM-QI states. NALM-QI-CD is an
|	optional substate of NALM-QI.
|
|
|   ARC State Transition
|
|	ALM may transition to NALM, NALM-QI, or NAML-TI by management request.
|
|	NALM may transition to ALM, NALM-QI, or NAML-TI by management request.
|
|	NALM-QI may transition to NALM or ALM by management request.
|	NALM-QI may transition to ALM automatically
|		if qualified problem-free (if NALM-QI-CD is not supported) or
|		if the CD timer expired (if NALM-QI-CD is supported)
|
|	NALM-TI may transition to ALM or NALM by management request.
|	NALM-TI may transition to ALM automatically if the TI timer expired.
|
|	Further details of ARC state transitions are defined in Figure 3
|	of M.3100 Amd3.
|
|   ARC Mode
|	A resource is in the ARC mode when it is in one of NALM, NALM-TI,
|	NALM-QI, or NALM-QI-CD states.
|
|   ARC NALM TI Time Interval
|	A pre-defined length of time in which the resource will state in the
|	NALM-TI ARC state before transition into the ALM state.
|
|   ARC NALM QI CD Time Interval
|	A pre-defined length of time in which the resource will state in the
|	NALM-QI-CD ARC state before transition into the ALM state after it
|	is problem-free.
|
|   ARC NALM Time Remaining
|	The time remaining until the expiration of the time interval when a
|	resource is in the NALM-TI or NALM-QI-CD state.
|
|
|   Relationship between ARC mode entering/exiting and Alarm reporting
|
|	For alarm condition raised prior to entering ARC mode, reporting of
|	alarm raised and alarm cleared will be sent as usual. That it, ARC
|	has no impacts.
|
|	For alarm condition raised after entering ARC mode and also cleared
|	before exiting ARC mode, no reporting of raised will be sent and no
|	reporting of cleared will be sent.
|
|	For alarm condition raised after entering ARC mode and cleared after
|	exiting ARC mode, the reporting of alarm raised will be deferred until
|	the moment of exiting ARC mode. The reporting of alarm clear will be
|	sent as usual (i.e., at the time of alarm cleared).
|
|	Further details can be found in M.3100 Amd3.
|
|4.  Object Definitions
|
|ARC-MIB DEFINITIONS ::= BEGIN
|
|IMPORTS
|    MODULE-IDENTITY, OBJECT-TYPE, Unsigned32
|          FROM SNMPv2-SMI
|    conditionProbableCause
|          FROM COND-MIB
|    MODULE-COMPLIANCE, OBJECT-GROUP
|          FROM SNMPv2-CONF
|
|arcMIB MODULE-IDENTITY
|    LAST-UPDATED "200102230000Z"
|    ORGANIZATION " "
|    CONTACT-INFO
|      "Anni Huynh
|       Lucent Technology
|       E-mail: [email-masked]
|
|       Kam Lam
|       Lucent Technologies
|       E-mail: [email-masked]."
|
|    DESCRIPTION
|       "The MIB module describes the objects for controlling a resource in
|        reporting an condition that it detectes."
|
|    REVISION  "200102230000Z"
|    DESCRIPTION
|       "The initial version."
|    ::={ mib-2 yy}
|
|------------------
|-- MIB Objects
|------------------
|
|arcMIBObjects   OBJECT IDENTIFIER ::= { arcMIB 1 }
|
|arcTable OBJECT-TYPE
|  SYNTAX  SEQUENCE OF ArcEntry
|  MAX-ACCESS  not-accessible
|  STATUS  current
|  DESCRIPTION
|    "A table of arc settings on the system."
|  ::= { arcMIBObjects 1 }
|
|arcEntry OBJECT-TYPE
|  SYNTAX  ArcEntry
|  MAX-ACCESS  not-accessible
|  STATUS  current
|  DESCRIPTION
|    "A conceptual row that contains information about the ARC setting of a
|     resource in the system."
|  INDEX  { arcIndex, arcAlarmType }
|  ::= { arcTable 1 }
|
|ArcEntry ::=
|  SEQUENCE {
|    arcIndex                      OBJECT IDENTIFIER,
|    arcAlarmType                  ConditionProbableCause,
|    arcState                      INTEGER,
|    arcNalmTITimeInterval         Unsigned32,
|    arcNalmCDTimeInterval         Unsigned32,
|    arcNalmTimeRemaining          Unsigned32
|    }
|
|arcIndex OBJECT-TYPE
|  SYNTAX  OBJECT IDENTIFIER
|  MAX-ACCESS  not-accessible
|  STATUS  current
|  DESCRIPTION
|    "The OID of a resource under the control of the ARC setting.
|     It must show all the indice to uniquely identify a resource.
|
|     The resource that does not support ARC will not have an entry in this
|     table."
|  ::= { arcEntry 1 }
|
|arcAlarmType OBJECT-TYPE
|  SYNTAX  condProbableCause
|  MAX-ACCESS  read-create
|  STATUS  current
|  DESCRIPTION
|    "This object identifies the alarm type controled by the arcState.
|     Only one alarm type is identified for each entry.  The alarm type
|     not listed in this object are not affected by the ARC setting in
|     the arcState."
|  ::= { arcEntry 2 }
|
|arcState OBJECT-TYPE
|  SYNTAX  INTEGER {
|            alm (1),
|            nalm (2),
|            nalmQI (3),
|            nalmTI (4),
|            nalmQICD (5)
|            }
|  MAX-ACCESS  read-write
|  STATUS  current
|  DESCRIPTION
|    "The object controls the alarm report of a resource.  A manager can set the
|     arcState to either alm (1), nalm (2), nalmQI (3), or nalmTI.
|
|     The value of nalamQICD is a transitional state from nalmQI(3) to alm (1).
|     It is an optional depending on the type and the implementation of the resource.
|     If it is supported, before the state is transitioned from nalmQI(3) to alm (1),
|     a count down period is activated for a duration set by the object
|     arcNalmCDTimeInterval.  When the time is up, the arcState is set to alm (1)"
|  ::= { arcEntry 3 }
|
|arcNalmTITimeInterval OBJECT-TYPE
|  SYNTAX  Unsigned32
|  MAX-ACCESS  read-write
|  STATUS  current
|  DESCRIPTION
|    "This variable indicates the time interval used for nalmTI,
|     in units of second."
|  ::= { arcEntry 4 }
|
|arcNalmCDTimeInterval OBJECT-TYPE
|  SYNTAX  Unsigned32
|  MAX-ACCESS  read-write
|  STATUS  current
|  DESCRIPTION
|    "This variable indicates the time interval used for nalmQICD,
|     in units of second."
|  ::= { arcEntry 5 }
|
|arcNalmTimeRemaining OBJECT-TYPE
|  SYNTAX  Unsigned32
|  MAX-ACCESS  read-only
|  STATUS  current
|  DESCRIPTION
|    "This variable indicates the time remaining in the NALM-TI interval or the
|     NALM-QI-CD interval, in units of second.
|
|     At the moment the resource enters the NALM-TI state, this variable will have
|     the initial value equal to the value of arcNalmTITimeInterval and then
|     starts decrementing as time goes by.
|
|     Similarly at the moment the resource enters the NALM-QI-CD state, this variable
|     will have the initial value equal to the value of arcNalmCDTimeInterval
|     and then starts decrementing as time goes by.
|
|     If this variable is supported and the resource is currently not in the
|     NALM-TI nor NAML-QI-CD state, the value of this variable shall be zero."
|  ::= { arcEntry 6 }
|
|
|-- conformance information
|-- To be Added
|
|END
|
|5.  Example Application
|
|   The following scenario provides an example application of the ARC feature.
|
|	(i) A bi-directional termination point TP-A has been created in the
|	NALM-QI state in a network device NE-A. Another bi-directional
|	termination point TP-Z has also been created in the NALM-QI state in
|	another network device NE-Z. The ARC probable cause list of both
|	termination points consists of OCI (Open Connection Indication) and
|	TIM (Trace Identifier Mismatch).
|
|	(ii) A bi-directional connection is setup in the network and terminated
|	at TP-A and TP-Z. The transmitted trace identifier and expected trace
|	identifier are provisioned at TP-A and TP-Z.
|
|	(iii) Both TP-A and TP-Z are checking for the OCI and TIM status.
|	If OCI or TIM is detacted at TP-A, no alarm will be reported.
|	Same for TP-Z.
|
|	(iv) IF or when TP-A is problem-free for both OCI and TIM , the ARC
|	state of TP-A will transition from NALM-QI to ALM. Same for TP-Z.
|	Now TP-A, TP-Z, and the bi-directional connection are in-service.
|
|	(v) From then on, if OCI or TIM is detected at TP-A, alarm report
|	will be sent. Same for TP-Z.
|
|6.  Security Considerations
|
|   There are a number of management objects defined in this MIB that
|   have a MAX-ACCESS clause of read-write and/or read-create.  Such
|   objects may be considered sensitive or vulnerable in some network
|   environments. The support for SET operations in a non-secure
|   environment without proper protection can have a negative effect on
|   network operations.
|
|   It is thus important to control even GET access to these objects and
|   possibly to even encrypt the values of these object when sending them
|   over the network via SNMP. Not all versions of SNMP provide features
|   for such a secure environment.
|
|   SNMPv1 by itself is not a secure environment. Even if the network
|   itself is secure (for example by using IPSec), there is no
|   control as to who on the secure network is allowed to access and
|   GET/SET (read/change/create/delete) the objects in this MIB.
|
|   It is recommended that the implementers consider the security
|   features as provided by the SNMPv3 framework. Specifically, the use
|   of the User-based Security Model RFC 2574 [RFC2574] and the View-based
|   Access Control Model RFC 2575 [RFC2575] is recommended.
|
|   It is then a customer/user responsibility to ensure that the SNMP
|   entity giving access to an instance of this MIB, is properly
|   configured to give access to the objects only to those principals
|   (users) that have legitimate rights to indeed GET or SET
|   (change/create/delete) them.
|
|7.  Acknowledgements
|   The authors wish to thank Tom Rutt, Steven Thomas, and Michael Campbell
|   for reviewing and commenting on this draft.
|
|8.  References
|
|[RFC2571]   Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture
|            for Describing SNMP Management Frameworks", RFC 2571, April
|            1999.
|
|[RFC1155]   Rose, M., and K. McCloghrie, "Structure and Identification
|            of Management Information for TCP/IP-based Internets", STD
|            16, RFC 1155, May 1990.
|
|[RFC1212]   Rose, M., and K. McCloghrie, "Concise MIB Definitions", STD
|            16, RFC 1212, March 1991.
|
|[RFC1215]   M. Rose, "A Convention for Defining Traps for use with the
|            SNMP", RFC 1215, March 1991.
|
|[RFC2578]   McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
|            Rose, M., and S. Waldbusser, "Structure of Management
|            Information Version 2 (SMIv2)", STD 58, RFC 2578, April
|            1999.
|
|[RFC2579]   McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
|            Rose, M., and S. Waldbusser, "Textual Conventions for
|            SMIv2", STD 58, RFC 2579, April 1999.
|
|[RFC2580]   McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
|            Rose, M., and S. Waldbusser, "Conformance Statements for
|            SMIv2", STD 58, RFC 2580, April 1999.
|
|[RFC1157]   Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple
|            Network Management Protocol", STD 15, RFC 1157, May 1990.
|
|[RFC1901]   Case, J., McCloghrie, K., Rose, M., and S. Waldbusser,
|            "Introduction to Community-based SNMPv2", RFC 1901, January
|            1996.
|
|[RFC1906]   Case, J., McCloghrie, K., Rose, M., and S. Waldbusser,
|            "Transport Mappings for Version 2 of the Simple Network
|            Management Protocol (SNMPv2)", RFC 1906, January 1996.
|
|[RFC2572]   Case, J., Harrington D., Presuhn R., and B. Wijnen, "Message
|            Processing and Dispatching for the Simple Network Management
|            Protocol (SNMP)", RFC 2572, April 1999.
|
|[RFC2574]   Blumenthal, U., and B. Wijnen, "User-based Security Model
|            (USM) for version 3 of the Simple Network Management
|            Protocol (SNMPv3)", RFC 2574, April 1999.
|
|[RFC1905]   Case, J., McCloghrie, K., Rose, M., and S. Waldbusser,
|            "Protocol Operations for Version 2 of the Simple Network
|            Management Protocol (SNMPv2)", RFC 1905, January 1996.
|
|[RFC2573]   Levi, D., Meyer, P., and B. Stewart, "SNMPv3 Applications",
|            RFC 2573, April 1999.
|
|[RFC2575]   Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based
|            Access Control Model (VACM) for the Simple Network
|            Management Protocol (SNMP)", RFC 2575, April 1999.
|
|[RFC2570]   Case, J., Mundy, R., Partain, D., and B. Stewart,
|            "Introduction to Version 3 of the Internet-standard Network
|            Management Framework", RFC 2570, April 1999.
|
|[RFC2026]   Bradnerand, S., "The Internet Standards Process -- Revision 3",
|            STD 17, RFC 2026, October 1996.
|
|[M.3100 Amd3] ITU Recommendation M.3100 Amendment 3, "Definition of the
|            Management Interface for a Generic Alarm Reporting Control (ARC)
|            Feature", February 2001.
|
|
|9.  Author's Address
|
|   Name(s): Kam Lam
|   Company: Lucent Technologies
|   Address: 480 Red Hill Road, Room 1D-226
|            Middletown, NJ 07748-3098
|   Phone:   1-732-615-4118
|   EMail:   [email-masked]
|
|   Name(s): An-ni Huynh
|   Company: Lucent Technologies
|   Address: 480 Red Hill Road, Room 1B-223
|            Middletown, NJ 07748-3098
|   Phone:   1-732-615-5402
|   EMail:   [email-masked]
|
|10. Intellectual Property
|
|   The IETF takes no position regarding the validity or scope of any
|   intellectual property or other rights that might be claimed to
|   pertain to the implementation or use of the technology described in
|   this document or the extent to which any license under such rights
|   might or might not be available; neither does it represent that it
|   has made any effort to identify any such rights.  Information on the
|   IETF's procedures with respect to rights in standards-track and
|   standards-related documentation can be found in BCP-11.  Copies of
|   claims of rights made available for publication and any assurances of
|   licenses to be made available, or the result of an attempt made to
|   obtain a general license or permission for the use of such
|   proprietary rights by implementers or users of this specification can
|   be obtained from the IETF Secretariat.
|
|   The IETF invites any interested party to bring to its attention any
|   copyrights, patents or patent applications, or other proprietary
|   rights which may cover technology that may be required to practice
|   this standard.  Please address the information to the IETF Executive
|   Director.
|
|11. Full Copyright Statement
|
|  Copyright (C) The Internet Society (2000). All Rights Reserved.
|
|  This document and translations of it may be copied and furnished to
|  others, and derivative works that comment on or otherwise explain it
|  or assist in its implementation may be prepared, copied, published
|  and distributed, in whole or in part, without restriction of any kind,
|  provided that the above copyright notice and this paragraph are
|  included on all such copies and derivative works.  However, this
|  document itself may not be modified in any way, such as by removing
|  the copyright notice or references to the Internet Society or other
|  Internet organizations, except as needed for the  purpose of
|  developing Internet standards in which case the procedures for
|  copyrights defined in the Internet Standards process must be followed,
|  or as required to translate it into languages other than English.
|
|  The limited permissions granted above are perpetual and will not be
|  revoked by the Internet Society or its successors or assigns.
|
|  This document and the information contained herein is provided on an
|  "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
|  TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT
|  NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN
|  WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
|  MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
|
|
|Expires August 23, 2001                                           [Page xx]
|
|------_=_NextPart_000_01C09DDE.FCA5F8D0--
|

 -------------------------------------------------------
 Randy Presuhn           [email-masked]
 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.
 -------------------------------------------------------