[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: snmpconf PM MIB Issue #9



Hi,

Would it be a reasonable compromise to have the StorageTable contain a
VariablePointer to a scalar that is the StorageControl for a specific
mib module?

Then simply define some guidelines about how a StorageControl scalar
pointed to by this table should be defined, possibly by using another
standard TC, such as a TruthValue (StoragePleaseWriteNow).

dbh

Steve Waldbusser wrote:
> 
> Thanks for this.
> 
> I think this is a good approach for a generalized solution. It works
> kindof like sync() except that you get more granularity.
> 
> One of my questions was whether per-row granularity was important. It
> seems the more popular strategy is to have per-row granularity thru
> storageType and then the write buttons write only those that are
> nonVolatile. Thus we should leave in storageType.
> 
> The other question is how we should get the write buttons? We could:
> 1) Do nothing and wait for the storage-type MIB to clarify the PM MIB in
> the same way as it will clarify all other existing use of storageType.
> (This doesn't add any dependence on the completion of the storage type
> MIB).
> 2) Add a scalar to the PM MIB that writes all nonVolatile entries
> 
> Comments?
> 
> Steve
> 
> Juergen Schoenwaelder wrote:
> >
> > >>>>> Steve Waldbusser writes:
> >
> > Steve> I'm happy to replace storage type with another mechanism but
> > Steve> I'd rather not invent it from scratch given that I've never
> > Steve> personally had experience with this problem myself. Is there a
> > Steve> generally-accepted solution to this problem? A single
> > Steve> write-everything-to-nvram button? Or keep (son of) storage-type
> > Steve> and add a button that only writes all storage-type=nonvolatile
> > Steve> rows?
> >
> > Steve> If this happens to just be a DiffServ issue, I hope someone
> > Steve> will speak up. The PM MIB is designed to go well beyond
> > Steve> DiffServ.
> >
> > One can argue that the StorageType definition is vague as it does not
> > clearly spell out when new values are written to non-volatile
> > storage.
> >
> > I know from talking to various people that implementors use different
> > strategies to implement StorageType. I started work on an ID which
> > "clarifies" the behaviour of the StorageType TC and adds some new MIB
> > objects that give you a central set of "write buttons". I never got
> > around to post the ID since I wanted to get more feedback first.
> >
> > Feedback is welcome and if people think this is a good approach, then
> > I am willing to push this forward.
> >
> > /js
> >
> > Network Working Group                                   J. Schoenwaelder
> > Internet-Draft                                           TU Braunschweig
> > Expires: October 2, 2001                                   April 3, 2001
> >
> >                             Storage Type MIB
> >                      draft-schoenw-storage-type-00
> >
> > Status of this Memo
> >
> >    This document is an Internet-Draft and is in full conformance with
> >    all provisions of Section 10 of 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.
> >
> >    This Internet-Draft will expire on October 2, 2001.
> >
> > Copyright Notice
> >
> >    Copyright (C) The Internet Society (2001).  All Rights Reserved.
> >
> > Abstract
> >
> >    The second version of the Structure of Management Information (SMIv2)
> >    introduced the StorageType textual convention in RFC 2579.  It is
> >    used to describe the memory realization of rows in conceptual tables.
> >    Several standards-track MIB modules make use of this convention.
> >    Implementation experience shows that different approaches are used to
> >    actually write conceptual rows to non-volatile memory.  This memo
> >    addresses this question and provides a storage MIB module which can
> >    be used to control when non-volatile rows are actually written to
> >    non-volatile memory.
> >
> > Schoenwaelder            Expires October 2, 2001                [Page 1]
> >
> > Internet-Draft              Storage Type MIB                  April 2001
> >
> > Table of Contents
> >
> >    1. The SNMP Management Framework  . . . . . . . . . . . . . . . .   3
> >    2. StorageType Interpretations  . . . . . . . . . . . . . . . . .   4
> >    3. Definitions  . . . . . . . . . . . . . . . . . . . . . . . . .   6
> >    4. Security Considerations  . . . . . . . . . . . . . . . . . . .   9
> >    5. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . .   9
> >    6. Intellectual Property Notice . . . . . . . . . . . . . . . . .   9
> >       References . . . . . . . . . . . . . . . . . . . . . . . . . .  10
> >       Author's Address . . . . . . . . . . . . . . . . . . . . . . .  11
> >       Full Copyright Statement . . . . . . . . . . . . . . . . . . .  12
> >
> > Schoenwaelder            Expires October 2, 2001                [Page 2]
> >
> > Internet-Draft              Storage Type MIB                  April 2001
> >
> > 1. The SNMP Management Framework
> >
> >    The SNMP Management Framework presently consists of five major
> >    components:
> >
> >    o  An overall architecture, described in RFC 2571 [2].
> >
> >    o  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 [3], STD 16, RFC 1212 [4] and RFC 1215 [5].  The
> >       second version, called SMIv2, is described in STD 58, RFC 2578
> >       [6], STD 58, RFC 2579 [7] and STD 58, RFC 2580 [8].
> >
> >    o  Message protocols for transferring management information.  The
> >       first version of the SNMP message protocol is called SNMPv1 and
> >       described in STD 15, RFC 1157 [9].  A second version of the SNMP
> >       message protocol, which is not an Internet standards track
> >       protocol, is called SNMPv2c and described in RFC 1901 [10] and RFC
> >       1906 [11].  The third version of the message protocol is called
> >       SNMPv3 and described in RFC 1906 [11], RFC 2572 [12] and RFC 2574
> >       [13].
> >
> >    o  Protocol operations for accessing management information.  The
> >       first set of protocol operations and associated PDU formats is
> >       described in STD 15, RFC 1157 [9].  A second set of protocol
> >       operations and associated PDU formats is described in RFC 1905
> >       [14].
> >
> >    o  A set of fundamental applications described in RFC 2573 [15] and
> >       the view-based access control mechanism described in RFC 2575
> >       [16].
> >
> >    A more detailed introduction to the current SNMP Management Framework
> >    can be found in RFC 2570 [17].
> >
> >    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 (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
> >
> > Schoenwaelder            Expires October 2, 2001                [Page 3]
> >
> > Internet-Draft              Storage Type MIB                  April 2001
> >
> >    MIB.
> >
> > 2. StorageType Interpretations
> >
> >    The SMIv2 introduced the StorageType textual convention which is used
> >    to describe how conceptual rows are stored in memory.  Several MIBs
> >    on the standards-track use this StorageType for conceptual tables
> >    that support row creation.  The StorageType textual convention is
> >    defined in RFC 2579 [7] as follows:
> >
> >    StorageType ::= TEXTUAL-CONVENTION
> >        STATUS       current
> >        DESCRIPTION
> >                "Describes the memory realization of a conceptual row.  A
> >                row which is volatile(2) is lost upon reboot.  A row which
> >                is either nonVolatile(3), permanent(4) or readOnly(5), is
> >                backed up by stable storage.  A row which is permanent(4)
> >                can be changed but not deleted.  A row which is readOnly(5)
> >                cannot be changed nor deleted.
> >
> >                If the value of an object with this syntax is either
> >                permanent(4) or readOnly(5), it cannot be written.
> >                Conversely, if the value is either other(1), volatile(2) or
> >                nonVolatile(3), it cannot be modified to be permanent(4) or
> >                readOnly(5).  (All illegal modifications result in a
> >                'wrongValue' error.)
> >
> >                Every usage of this textual convention is required to
> >                specify the columnar objects which a permanent(4) row must
> >                at a minimum allow to be writable."
> >        SYNTAX       INTEGER {
> >                         other(1),       -- eh?
> >                         volatile(2),    -- e.g., in RAM
> >                         nonVolatile(3), -- e.g., in NVRAM
> >                         permanent(4),   -- e.g., partially in ROM
> >                         readOnly(5)     -- e.g., completely in ROM
> >                     }
> >
> >    Note that the text in the DESCRIPTION clause does not make any
> >    explicit statements when a conceptual row is actually written to non-
> >    volatile storage.  One interpretation is that rows must be writen to
> >    non-volatile storage on each set operation on one of the columnar
> >    objects.  However, many implementations prefer to not write to non-
> >    volatile storage on each set operation.  There are two main reasons
> >    for this behavior:
> >
> >    1.  Writing non-volatile storage is on some systems too time
> >        consuming to do it during the set operation itself.
> >
> > Schoenwaelder            Expires October 2, 2001                [Page 4]
> >
> > Internet-Draft              Storage Type MIB                  April 2001
> >
> >    2.  Writing non-volatile storage on every single set of a non-
> >        volatile variable is too costly on systems that can only backup
> >        complex system configurations.
> >
> >    Implementations therefore use different strategies:
> >
> >    1.  Some systems update the non-volatile storage on each set
> >        operation.
> >
> >    2.  Some systems first return a positive response to the set
> >        operation and they write the modified variables to non-volatile
> >        storage at some later point in time when there are no more
> >        changes.
> >
> >    3.  Some systems first return a positive response to the set
> >        operation and they delay the actual write to non-volatile storage
> >        to some external event (e.g.  shutdown of the agent, pushing of a
> >        global write button).
> >
> >    4.  Some systems first return a positive response to the set
> >        operation and they write the modified variables when a logical
> >        row operation has completed.  (For example, incomplete conceptual
> >        rows are not saved in non-volatile storage until they are
> >        complete and activated.)
> >
> >    It seems that delayed writes to non-volatile storage are common
> >    practice.  However, since this behaviour is right now completely
> >    implementation dependent, there is no simple way for a management
> >    application to learn how a given device implements the StorageType
> >    textual convention and therefore it is unclear when a row is actually
> >    written to stable storage.
> >
> >    Commonly used command line interfaces of network devices also follow
> >    a paradigm where explicit commands trigger the storage of the device
> >    configuration (or logical parts of the configuration) in stable
> >    storage.  Operational experience with these interfaces suggests that
> >    it is (i) valuable to have explicit control when configuration data
> >    is written to non-volatile storage and (ii) efficient to implement on
> >    networking devices.
> >
> >    This document therefore proposes to introduce new MIB objects which
> >    can be used by management applications to control when non-volatile
> >    conceptual rows are written to stable storage.  The MIB supports
> >    multiple "write buttons" to support implementations which use
> >    different mechanisms in different parts of the MIBs to save rows in
> >    non-volatile storage.  All "write buttons" are registered in a common
> >    table so that management applications can easily find them.  The
> >    table is organized so that sub-agents can register rows in the table
> >
> > Schoenwaelder            Expires October 2, 2001                [Page 5]
> >
> > Internet-Draft              Storage Type MIB                  April 2001
> >
> >    easily.  In addition, there is a global "write button" which
> >    basically causes all write buttons in the table to be triggered.
> >
> >    An alternative approach would have been to introduce "write button"
> >    scalars in various MIB modules that use the StorageType textual
> >    convention.  However, this leads to serious problems for management
> >    applications to find the right scalars for the right set of MIB
> >    objects.  Furthermore, it would be hard to realize a global "write
> >    button" in a master/subagent environment without specific protocol
> >    support.
> >
> > 3. Definitions
> >
> >    SNMP-STORAGE-MIB DEFINITIONS ::= BEGIN
> >
> >    IMPORTS
> >        MODULE-IDENTITY,
> >        OBJECT-TYPE,
> >        snmpModules,
> >        Unsigned32
> >         FROM SNMPv2-SMI
> >
> >        DateAndTime,
> >        AutonomousType
> >            FROM SNMPv2-TC
> >
> >        SnmpAdminString
> >            FROM SNMP-FRAMEWORK-MIB;
> >
> >    snmpStorageMIB MODULE-IDENTITY
> >        LAST-UPDATED "200104020000Z"
> >        ORGANIZATION "IETF"
> >        CONTACT-INFO
> >         ""
> >        DESCRIPTION
> >         ""
> >        REVISION    "200104020000Z"
> >        DESCRIPTION "The initial revision, published as RFC XXXX."
> >        ::= { snmpModules xxx }
> >
> >    snmpStorageObjects     OBJECT IDENTIFIER ::= { snmpStorageMIB 1 }
> >    snmpStorageConformance OBJECT IDENTIFIER ::= { snmpStorageMIB 2 }
> >
> >    snmpStorageGlobControl OBJECT-TYPE
> >        SYNTAX   INTEGER { nop(1), write(2) }
> >        MAX-ACCESS       read-write
> >        STATUS   current
> >        DESCRIPTION
> >
> > Schoenwaelder            Expires October 2, 2001                [Page 6]
> >
> > Internet-Draft              Storage Type MIB                  April 2001
> >
> >         "This object ..."
> >        ::= { snmpStorageObjects 1 }
> >
> >    snmpStorageGlobStatus OBJECT-TYPE
> >        SYNTAX   INTEGER {
> >                     other(1),
> >                     dirty(2),           -- can probably not be implemented ?
> >                     writing(3),         -- perhaps we only need 'idle' and
> >                     done(4)             -- 'inProgress'?
> >                 }
> >        MAX-ACCESS       read-only
> >        STATUS   current
> >        DESCRIPTION
> >         "This object ..."
> >        ::= { snmpStorageObjects 2 }
> >
> >    snmpStorageGlobError OBJECT-TYPE
> >        SYNTAX   SnmpAdminString
> >        MAX-ACCESS       read-only
> >        STATUS   current
> >        DESCRIPTION
> >         "This object contains a descriptive error message if the
> >          last attempt to write global stable storage has failed."
> >        ::= { snmpStorageObjects 3 }
> >
> >    snmpStorageGlobErrorTime OBJECT-TYPE
> >        SYNTAX   DateAndTime
> >        MAX-ACCESS       read-only
> >        STATUS   current
> >        DESCRIPTION
> >         "The data and time when the snmpStorageGlobError was last
> >          updated. The value '0000000000000000'H is returned if
> >          snmpStorageGlobError has not yet been updated after the
> >          initialization."
> >        ::= { snmpStorageObjects 4 }
> >
> >    snmpStorageTable OBJECT-TYPE
> >        SYNTAX   SEQUENCE OF SnmpStorageEntry
> >        MAX-ACCESS       not-accessible
> >        STATUS   current
> >        DESCRIPTION
> >         ""
> >        ::= { snmpStorageObjects 5 }
> >
> >    snmpStorageEntry OBJECT-TYPE
> >        SYNTAX   SnmpStorageEntry
> >        MAX-ACCESS       not-accessible
> >        STATUS   current
> >
> > Schoenwaelder            Expires October 2, 2001                [Page 7]
> >
> > Internet-Draft              Storage Type MIB                  April 2001
> >
> >        DESCRIPTION
> >         ""
> >        ::= { snmpStorageTable 1 }
> >
> >    SnmpStorageEntry ::= SEQUENCE {
> >        snmpStorageIndex         Unsigned32,
> >        snmpStorageDescr         SnmpAdminString,
> >        snmpStorageID            AutonomousType,
> >        snmpStorageControl               INTEGER,
> >        snmpStorageStatus                INTEGER,
> >        snmpStorageError         SnmpAdminString,
> >        snmpStorageErrorTime     DateAndTime
> >    }
> >
> >    snmpStorageIndex OBJECT-TYPE
> >        SYNTAX   Unsigned32
> >        MAX-ACCESS       not-accessible
> >        STATUS   current
> >        DESCRIPTION
> >         "The index which uniquely identifies a row in the
> >          snmpStorageTable."
> >        ::= { snmpStorageEntry 1 }
> >
> >    snmpStorageDescr OBJECT-TYPE
> >        SYNTAX   SnmpAdminString
> >        MAX-ACCESS       read-only
> >        STATUS   current
> >        DESCRIPTION
> >         ""
> >        ::= { snmpStorageEntry 2 }
> >
> >    snmpStorageID OBJECT-TYPE
> >        SYNTAX   AutonomousType
> >        MAX-ACCESS       read-only
> >        STATUS   current
> >        DESCRIPTION
> >         ""
> >        ::= { snmpStorageEntry 3 }
> >
> >    snmpStorageControl OBJECT-TYPE
> >        SYNTAX   INTEGER { nop(1), write(2) }
> >        MAX-ACCESS       read-write
> >        STATUS   current
> >        DESCRIPTION
> >         ""
> >        ::= { snmpStorageEntry 4 }
> >
> >    snmpStorageStatus OBJECT-TYPE
> >
> > Schoenwaelder            Expires October 2, 2001                [Page 8]
> >
> > Internet-Draft              Storage Type MIB                  April 2001
> >
> >        SYNTAX   INTEGER { other(1), dirty(2), writing(3), done(4) }
> >        MAX-ACCESS       read-only
> >        STATUS   current
> >        DESCRIPTION
> >         ""
> >        ::= { snmpStorageEntry 5 }
> >
> >    snmpStorageError OBJECT-TYPE
> >        SYNTAX   SnmpAdminString
> >        MAX-ACCESS       read-only
> >        STATUS   current
> >        DESCRIPTION
> >         ""
> >        ::= { snmpStorageEntry 6 }
> >
> >    snmpStorageErrorTime OBJECT-TYPE
> >        SYNTAX   DateAndTime
> >        MAX-ACCESS       read-only
> >        STATUS   current
> >        DESCRIPTION
> >            ""
> >        ::= { snmpStorageEntry 7 }
> >
> >    -- XXX Spell out conformance definitions. Just say that the
> >    -- snmpStorageTable is not required on systems that need only
> >    -- a single "write button".
> >
> >    END
> >
> > 4. Security Considerations
> >
> >    ...
> >
> > 5. Acknowledgments
> >
> >    ...
> >
> > 6. Intellectual Property Notice
> >
> >    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
> >
> > Schoenwaelder            Expires October 2, 2001                [Page 9]
> >
> > Internet-Draft              Storage Type MIB                  April 2001
> >
> >    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 propritary
> >    rights by implementors 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.
> >
> > References
> >
> >    [1]   Bradner, S., "Key words for use in RFCs to Indicate Requirement
> >          Levels", BCP 14, RFC 2119, March 1997.
> >
> >    [2]   Harrington, D., Presuhn, R. and B. Wijnen, "An Architecture for
> >          Describing SNMP Management Frameworks", RFC 2571, April 1999.
> >
> >    [3]   Rose, M. and K. McCloghrie, "Structure and Identification of
> >          Management Information for TCP/IP-based Internets", STD 16, RFC
> >          1155, May 1990.
> >
> >    [4]   Rose, M. and K. McCloghrie, "Concise MIB Definitions", STD 16,
> >          RFC 1212, March 1991.
> >
> >    [5]   Rose, M., "A Convention for Defining Traps for use with the
> >          SNMP", RFC 1215, March 1991.
> >
> >    [6]   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.
> >
> >    [7]   McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose,
> >          M. and S. Waldbusser, "Textual Conventions for SMIv2", STD 58,
> >          RFC 2579, April 1999.
> >
> >    [8]   McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose,
> >          M. and S. Waldbusser, "Conformance Statements for SMIv2", STD
> >          58, RFC 2580, April 1999.
> >
> >    [9]   Case, J., Fedor, M., Schoffstall, M. and J. Davin, "A Simple
> >          Network Management Protocol (SNMP)", STD 15, RFC 1157, May
> >          1990.
> >
> >    [10]  Case, J., McCloghrie, K., Rose, M. and S. Waldbusser,
> >          "Introduction to Community-based SNMPv2", RFC 1901, January
> >
> > Schoenwaelder            Expires October 2, 2001               [Page 10]
> >
> > Internet-Draft              Storage Type MIB                  April 2001
> >
> >          1996.
> >
> >    [11]  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.
> >
> >    [12]  Case, J., Harrington, D., Presuhn, R. and B. Wijnen, "Message
> >          Processing and Dispatching for the Simple Network Management
> >          Protocol (SNMP)", RFC 2572, April 1999.
> >
> >    [13]  Blumenthal, U. and B. Wijnen, "User-based Security Model (USM)
> >          for version 3 of the Simple Network Management Protocol
> >          (SNMPv3)", RFC 2574, April 1999.
> >
> >    [14]  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.
> >
> >    [15]  Levi, D., Meyer, P. and B. Stewart, "SNMP Applications", RFC
> >          2573, April 1999.
> >
> >    [16]  Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based Access
> >          Control Model (VACM) for the Simple Network Management Protocol
> >          (SNMP)", RFC 2575, April 1999.
> >
> >    [17]  Case, J., Mundy, R., Partain, D. and B. Stewart, "Introduction
> >          to Version 3 of the Internet-standard Network Management
> >          Framework", RFC 2570, April 1999.
> >
> > Author's Address
> >
> >    Juergen Schoenwaelder
> >    TU Braunschweig
> >    Bueltenweg 74/75
> >    38106 Braunschweig
> >    Germany
> >
> >    Phone: +49 531 391-3266
> >    EMail: schoenw@ibr.cs.tu-bs.de
> >
> > Schoenwaelder            Expires October 2, 2001               [Page 11]
> >
> > Internet-Draft              Storage Type MIB                  April 2001
> >
> > Full Copyright Statement
> >
> >    Copyright (C) The Internet Society (2001).  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.
> >
> > Acknowledgement
> >
> >    Funding for the RFC Editor function is currently provided by the
> >    Internet Society.
> >
> > Schoenwaelder            Expires October 2, 2001               [Page 12]

-- 
---
David Harrington            Network Management Standards Architect
dbh@enterasys.com           Office of the CTO
+1 603 337 2614 - voice     Enterasys Networks
+1 603 332 1524 - fax       Rochester NH, USA