Tech-invite3GPPspaceIETF RFCsSIP
929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 3165

Definitions of Managed Objects for the Delegation of Management Scripts

Pages: 64
Proposed Standard
Errata
Obsoletes:  2592
Part 3 of 3 – Pages 49 to 64
First   Prev   None

Top   ToC   RFC3165 - Page 49   prevText

7. Usage Examples

This section presents some examples that explain how a manager can use the Script MIB defined in this memo. The purpose of these examples is to explain the steps that are normally used to delegate management scripts.

7.1. Pushing a Script via SNMP

This example explains the steps performed by a manager to push a script into a distributed manager. 1. The manager first checks the smLangTable and the smExtsnTable in order to select the appropriate script or language. 2. The manager creates a row in the smScriptTable by issuing an SNMP set-request. The smScriptRowStatus object is set to `createAndWait' and the smScriptSource object is set to an empty string. The smScriptLanguage object is set to the language in which the script was written. The smScriptStorageType object is set to `volatile' to indicate that the script will be loaded via the smCodeTable. The smScriptOwner is set to a string which identifies the principal who owns the new row. The smScriptName defines the administratively assigned unique name for the script. 3. The manager sets the smScriptRowStatus object to `active' and the smScriptAdminStatus object to `editing'. 4. The manager pushes the script to the distributed manager by issuing a couple of SNMP set-requests to fill the smCodeTable. 5. Once the whole script has been transferred, the manager sends a set-request to set the smScriptAdminStatus object to `enabled'. The Script MIB implementation now makes the script accessible to the runtime system. This might include the compilation of the script if the language requires a compilation step. 6. The manager polls the smScriptOperStatus object until the value is either `enabled' or one of the error status codes. The script can only be used if the value of smScriptOperStatus is `enabled'. 7. If the manager wants to store the script in local non-volatile storage, it should send a set-request which changes the smScriptStorageType object to `nonVolatile'.
Top   ToC   RFC3165 - Page 50

7.2. Pulling a Script from a URL

This example explains the steps performed by a manager to cause a distributed manager to pull a script from a URL. 1. The manager first checks the smLangTable and the smExtsnTable in order to select the appropriate script or language. 2. The manager creates a row in the smScriptTable by issuing an SNMP set-request. The smScriptRowStatus object is set to `createAndWait' and the smScriptSource object is set to the URL which points to the script source. The smScriptLanguage object is set to the language in which the script was written. The smScriptOwner is set to a string which identifies the principal who owns the new row. The smScriptName defines the administratively assigned unique name for the script. 3. The manager sets the smScriptRowStatus object to `active'. 4. The manager sends a set-request to set the smScriptAdminStatus object to `enabled'. The Script MIB implementation now makes the script accessible to the runtime system. This causes a retrieval operation to pull the script from the URL stored in smScriptSource. This retrieval operation might be followed by a compile operation if the language requires a compilation step. 5. The manager polls the smScriptOperStatus object until the value is either `enabled' or one of the error status codes. The script can only be used if the value of smScriptOperStatus is `enabled'. 6. If the manager wants to store the script in local non-volatile storage, it should send a set-request which changes the smScriptStorageType object to `nonVolatile'.

7.3. Modifying an Existing Script

This section explains how a manager can modify a script by sending SNMP set-requests. 1. First, the script is de-activated by setting the smScriptAdminStatus to `disabled'. 2. The manager polls the smScriptOperStatus object until the value is `disabled'. 3. The manager sets smScriptSource to an empty string and smScriptAdminStatus to `editing'. This makes the script source available in the smCodeTable.
Top   ToC   RFC3165 - Page 51
   4. The manager polls the smScriptOperStatus object until the value is
      `editing'.

   5. The manager sends SNMP set-requests to modify the script in the
      smCodeTable.

   6. The manager sends a set-request to set the smScriptAdminStatus
      object to `enabled'.  The Script MIB implementation now makes the
      script accessible to the runtime system.  This might include the
      compilation of the script if the language requires a compilation
      step.

   7. The manager polls the smScriptOperStatus object until the value is
      either `enabled' or one of the error status codes.  The script can
      only be used if the value of smScriptOperStatus is `enabled'.

7.4. Removing an Existing Script

This section explains how a manager can remove a script from a distributed manager. 1. First, the manager sets the smScriptAdminStatus to `disabled'. This will ensure that no new scripts can be started while running scripts finish their execution. 2. The manager polls the smScriptOperStatus object until the value is `disabled'. 3. The manager sends an SNMP set-request to change the smScriptRowStatus object to `destroy'. This will remove the row and all associated resources from the Script MIB implementation.

7.5. Creating a Launch Button

This section explains how a manager can create a launch button for starting a script. 1. The manager, who is identified by an smLaunchOwner value, first chooses a name for the new row in the smLaunchTable. The manager sends an SNMP set-request to set the smLaunchRowStatus object for this smLaunchOwner and smLaunchName to `createAndWait'. 2. The manager fills the new smLaunchTable row with all required parameters. The smLaunchScriptOwner and smLaunchScriptName values point to the script that should be started from this launch button. 3. The manager sets the smLaunchRowStatus object to `active'.
Top   ToC   RFC3165 - Page 52
   4. The manager sends a set-request to change smLaunchAdminStatus to
      `enabled' once the new smLaunchTable row is complete.

   5. The manager polls the smLaunchOperStatus object until the value is
      `enabled'.

7.6. Launching a Script

This section explains the suggested way to launch a script from a given launch button. 1. The manager first retrieves the value of smLaunchRunIndexNext from the launch button selected to start the script. 2. The manager sends an SNMP set-request to set the smLaunchStart object to the value obtained in step 1. This will launch the script if all necessary pre-conditions are satisfied (see the definition of smLaunchStart for more details). The manager can also provide the smLaunchArgument in the same set-request that is used to start the script. Upon successful start, a new row will be created in the smRunTable indexed by smLaunchOwner, smLaunchName and the value written to smLaunchStart. 3. The manager polls the smRunState object until the value is either `executing' (the default case), `suspended' or `terminated'. The first step is not required. A manager can also try to guess an unused value for smRunIndex if the manager wants to start the script in a single transaction. A manager can also use the special value 0 if it does not care about the smRunIndex.

7.7. Suspending a Running Script

This section explains how a manager can suspend a running script. 1. The manager sets the smRunControl object of the running script or the smLaunchControl object of the launch button used to start the running script to `suspend'. Setting smLaunchControl will suspend all running scripts started from the launch button while smRunControl will only suspend the running script associated with the smRunControl instance. 2. The manager polls the smRunState object until the value is either `suspended', `executing', or `terminated'. If the value is `suspended', then the suspend operation was successful. If the value is `executing', then the attempt to suspend the script
Top   ToC   RFC3165 - Page 53
      failed.  The value `terminated' can be received in cases where the
      suspend operation failed and the running script terminated between
      the polls.

   Note that the set operation in the first step can lead to an
   inconsistentValue error which indicates that the suspend operation
   failed (e.g., because the runtime system does not support
   suspend/resume).  There is no need to poll smRunState in this case.

7.8. Resuming a Suspended Script

This section explains how a manager can resume a suspended script. 1. The manager sets the smRunControl object of the running script or the smLaunchControl object of the launch button used to start the running script to `resume'. Setting smLaunchControl will resume all running scripts started from the launch button while smRunControl will only resume the running script associated with the smRunControl instance. 2. The manager polls the smRunState object until the value is either `suspended', `executing', or `terminated'. If the value is `executing', then the resume operation was successful. If the value is `suspended', then the attempt to resume the script failed. The value `terminated' can be received in cases where the resume operation was successful and the running script terminated between the polls. Note that the set operation in the first step can lead to an inconsistentValue error which indicates that the resume operation failed (e.g., because the runtime system does not support suspend/resume). There is no need to poll smRunState in this case.

7.9. Terminating a Running Script

This section explains two ways to terminate a running script. The first approach is as follows: 1. The manager sets the smRunControl object of the running script or the smLaunchControl object of the launch button used to start the running script to `abort'. Setting smLaunchControl will abort all running scripts started from the launch button while smRunControl will only abort the running script associated with the smRunControl instance. 2. The manager polls the smRunState object until the value is `terminated'.
Top   ToC   RFC3165 - Page 54
   The second way to terminate a script is to set the smRunLifeTime to
   zero which causes the runtime system to terminate the script with a
   `lifeTimeExceeded' exit code:

   1. The manager changes the value of smRunLifeTime to 0.  This causes
      the Script MIB implementation to abort the script because the
      remaining life time has expired.

   2. The manager polls the smRunState object until the value is
      `terminated'.

   Note that changing the smRunLifeTime value can also be used to
   increase the permitted lifetime of a running script.  For example, a
   manager can choose to set smRunLifeTime to a small fixed time
   interval and increase the value periodically.  This strategy has the
   nice effect that scripts terminate automatically if the manager loses
   contact with the Script MIB engine.

7.10. Removing a Terminated Script

This section explains how a manager can remove a terminated script. 1. The manager changes the smRunExpireTime to 0. This causes the Script MIB implementation to destroy the smRunTable entry of the terminated script.

7.11. Removing a Launch Button

This section explains how a manager can remove a launch button from a distributed manager. 1. First, the manager sets the smLaunchAdminStatus to `disabled'. This will ensure that no new scripts can be started from this launch button while running scripts finish their execution. 2. The manager polls the smLaunchOperStatus object until the value is `disabled'. 3. The manager sends an SNMP set-request to change the smLaunchRowStatus object to `destroy'. This will remove the row and all associated resources from the Script MIB implementation.

8. VACM Configuration Examples

This section shows how the view-based access control model defined in RFC 2575 [RFC2575] can be configured to control access to the Script MIB.
Top   ToC   RFC3165 - Page 55

8.1. Sandbox for Guests

The first example demonstrates how to configure VACM to give the members of the VACM group "guest" limited access to the Script MIB. The MIB views defined below give the members of the "guest" group a sandbox where they can install and start their own scripts, but not access any other scripts maintained by the Script MIB implementation. vacmAccessReadView."guest"."".usm.authNoPriv = "guestReadView" vacmAccessWriteView."guest"."".usm.authNoPriv = "guestWriteView" The guestReadView grants read access to the smLangTable, the smExtsnTable and to all the table entries owned by "guest": guestReadView: smLangTable (included) smExtsnTable (included) smScriptObjects.*.*.*."guest" (included) smRunObjects.*.*.*."guest" (included) The guestWriteView grants write access to all the table entries owned by "guest": guestWriteView: smScriptObjects.*.*.*."guest" (included) smRunObjects.*.*.*."guest" (included)

8.2. Sharing Scripts

This example demonstrates how VACM can be used to share a repository of scripts between the members of the "senior" and the members of the "junior" VACM group: vacmAccessReadView."junior"."".usm.authNoPriv = "juniorReadView" vacmAccessWriteView."junior"."".usm.authNoPriv = "juniorWriteView" juniorReadView: smLangTable (included) smExtsnTable (included) smScriptObjects.*.*.*."junior" (included) smRunObjects.*.*.*."junior" (included) smScriptObjects.*.*.*."utils" (included) juniorWriteView: smScriptObjects.*.*.*."junior" (included) smRunObjects.*.*.*."junior" (included)
Top   ToC   RFC3165 - Page 56
   The definitions above allow the members of the "junior" VACM group to
   start the scripts owned by "utils" in addition to the script the
   members of the "junior" VACM group installed themselves.  This is
   accomplished by giving the members of "junior" read access to scripts
   in "utils".  This allows members of "junior" to create entries in the
   smLaunchTable which refer to scripts in "utils", and to launch those
   scripts using these entries in the smLaunchTable.

      vacmAccessReadView."senior"."".usm.authNoPriv = "seniorReadView"
      vacmAccessWriteView."senior"."".usm.authNoPriv = "seniorWriteView"

      seniorReadView:
          smLangTable                       (included)
          smExtsnTable                      (included)
          smScriptObjects.*.*.*."senior"    (included)
          smRunObjects.*.*.*."senior"       (included)
          smScriptObjects.*.*.*."utils"     (included)

      seniorWriteView:
          smScriptObjects.*.*.*."senior"    (included)
          smRunObjects.*.*.*."senior"       (included)
          smScriptObjects.*.*.*."utils"     (included)

   The definitions for the members of the "senior" VACM group allow to
   start the scripts owned by "utils" in addition to the script the
   members of the "senior" VACM group installed themself.  The third
   write access rule in the seniorWriteView also grants the permission
   to install scripts owned by "utils".  The members of the "senior"
   VACM group therefore have the permissions to install and modify
   scripts that can be called by the members of the "junior" VACM group.

8.3. Emergency Scripts

This example demonstrates how VACM can be used to allow the members of the "junior" VACM group to launch scripts that are executed with the permissions associated with the "emergency" owner. This works by adding the following rules to the juniorReadView and the juniorWriteView: juniorReadView: smScriptObjects.*.*.*."emergency" (included) smRunObjects.*.*.*."emergency" (included) juniorWriteView smLaunchStart."emergency" (included) smLaunchArgument."emergency" (included)
Top   ToC   RFC3165 - Page 57
   The rules added to the juniorReadView grant read access to the
   scripts, the launch buttons and the results owned by "emergency".
   The rules added to the juniorWriteView grant write permissions to the
   smLaunchStart and smLaunchArgument variables owned by "emergency".
   Members of the "junior" VACM group can therefore start scripts that
   will execute under the owner "emergency".

      seniorReadView:
          smScriptObjects.*.*.*."emergency" (included)
          smRunObjects.*.*.*."emergency"    (included)

      seniorWriteView:
          smScriptObjects.*.*.*."emergency" (included)
          smRunObjects.*.*.*."emergency"    (included)

   The rules added to the seniorReadView and the seniorWriteView will
   give the members of the "senior" VACM group the rights to install
   emergency scripts and to configure appropriate launch buttons.

9. IANA Considerations

The Internet Assigned Numbers Authority (IANA) is responsible for maintaining a MIB module (IANA-LANGUAGE-MIB) which provides OID registrations for well-known languages. The IANA language registry is intended to reduce interoperability problems by providing a single list of well-known languages. However, it is of course still possible to register languages in private OID spaces. Registering languages in private OID spaces is especially attractive if a language is used for experimentation or if a language is only used in environments where the distribution of MIB modules with the language registration does not cause any maintenance problems. Any additions or changes to the list of languages registered via IANA require Designated Expert Review as defined in the IANA guidelines [RFC2434]. The Designated Expert will be selected by the IESG Area Director for the IETF Operations and Management Area.

10. 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.
Top   ToC   RFC3165 - Page 58
   SNMPv1 by itself is not a secure environment.  Even if the network
   itself is secure (for example by using IPSec), even then, 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.

   This MIB provides the ability to distribute applications written in
   an arbitrary language to remote systems in a network.  The security
   features of the languages available in a particular implementation
   should be taken into consideration when deploying an implementation
   of this MIB.

   To facilitate the provisioning of access control by a security
   administrator using the View-Based Access Control Model (VACM)
   defined in RFC 2575 [RFC2575] for tables in which multiple users may
   need to independently create or modify entries, the initial index is
   used as an "owner index".  Such an initial index has a syntax of
   SnmpAdminString, and can thus be trivially mapped to a securityName
   or groupName as defined in VACM, in accordance with a security
   policy.

   All entries in related tables belonging to a particular user will
   have the same value for this initial index.  For a given user's
   entries in a particular table, the object identifiers for the
   information in these entries will have the same subidentifiers
   (except for the "column" subidentifier) up to the end of the encoded
   owner index.  To configure VACM to permit access to this portion of
   the table, one would create vacmViewTreeFamilyTable entries with the
   value of vacmViewTreeFamilySubtree including the owner index portion,
   and vacmViewTreeFamilyMask "wildcarding" the column subidentifier.
   More elaborate configurations are possible.

   The VACM access control mechanism described above provides control
   over SNMP access to Script MIB objects.  There are a number of other
   access control issues that are outside of the scope of this MIB.  For
   example, access control on URLs, especially those that use the file
   scheme, must be realized by the underlying operating system.  A
   mapping of the owner index value to a local operating system security
Top   ToC   RFC3165 - Page 59
   user identity should be used by an implementation of this MIB to
   control access to operating system resources when resolving URLs or
   executing scripts.

11. 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 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.

12. Changes from RFC 2592

The following list documents major changes from the previous version of this document, published as RFC 2592: - Updated the boilerplate and the references. - Added revision clauses to the module identity macro. - Various typos have been fixed. - Added SIZE restriction to smScriptName which is consistent with smLaunchScriptName. Added DEFVAL and some clarifying text on the usage of a zero-length string to smLaunchScriptName. - Clarified under which conditions changes to smScriptLanguage are invalid. - Added new smScriptError and smLaunchError objects. - Setting smRunLifeTime to its maximum value now disables the timer so that scripts can run forever.
Top   ToC   RFC3165 - Page 60
   -  Added the `autostart' value to the smLaunchAdminStatus object
      which allows to launch scripts during the disable->enabled
      transition of smLaunchOperStatus.

   -  Added an additional step to the "creating a launch button"
      procedure which sets the smLaunchRowStatus to active.

   -  Added a final polling step in the procedure to launch a script.

   -  Added a final polling step in the procedure to terminate a running
      script.

   -  Removed the requirement that smRunError is a zero-length string
      while the smRunExitCode has the value `noError'.

   -  Added new smScriptLastChange, smLaunchLastChange, smRunResultTime,
      and smRunErrorTime objects.

   -  Added some additional boilerplate text to the security
      considerations section.

   -  Added a new smLaunchRowExpireTime object and a new `expired' state
      to the smLaunchOperStatus object.

   -  Clarified that the smRunState object reports the actual state if
      attempts to suspend or resume scripts fail.

   -  Clarified the conditions under which set operations to
      smLaunchControl and smRunControl can lead to inconsistentValue
      errors.

   -  Added procedures for suspending/resuming/removing running scripts
      to section 7.

   -  Added text to the smScriptStorageType description to better
      highlight the difference between the storage type of the script
      row entry and the script itself.

   -  Updated the smCompliances statement to not require write access to
      the smCodeText object after row creation.

   -  Deprecated smCompliance, smScriptGroup, smLaunchGroup, smRunGroup,
      smNotificationsGroup and created smCompliance2, smScriptGroup2,
      smLaunchGroup2, smRunGroup2 and smNotificationsGroup2 that take
      care of the new objects and notifications.
Top   ToC   RFC3165 - Page 61

13. Acknowledgments

This document was produced by the IETF Distributed Management (DISMAN) working group.

14. 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] Rose, M., "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.
Top   ToC   RFC3165 - Page 62
   [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.

   [RFC2028]  Hovey, R. and S. Bradner, "The Organizations Involved in
              the IETF Standards Process", BCP 11, RFC 2028, October
              1996.

   [RFC2396]  Berners-Lee, T., Fielding, R. and L. Masinter, " Uniform
              Resource Identifiers (URI): Generic Syntax", RFC 2396,
              August 1998.

   [RFC959]   Postel, J. and J. Reynolds, "File Transfer Protocol", STD
              9, RFC 959, October 1985.

   [RFC2616]  Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
              Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext
              Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.

   [RFC2434]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 2434,
              October 1998.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.
Top   ToC   RFC3165 - Page 63

15. Editors' Addresses

David B. Levi Nortel Networks 4401 Great America Parkway Santa Clara, CA 95052-8185 USA Phone: +1 423 686 0432 EMail: dlevi@nortelnetworks.com Juergen Schoenwaelder TU Braunschweig Bueltenweg 74/75 38106 Braunschweig Germany Phone: +49 531 391-3283 EMail: schoenw@ibr.cs.tu-bs.de
Top   ToC   RFC3165 - Page 64

16. 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.