One document matched: draft-barnes-midcom-mib-00.txt
Internet Draft M. Barnes
Document: draft-barnes-midcom-mib-00.txt Nortel Networks
D. Harrington
Enterasys Networks
M. Stiemerling
Category: Standards Track NEC Europe Ltd.
Expires: September 2003 March 2003
Managed Objects for Middlebox Communications (MIDCOM)
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.
Abstract
This document describes and defines the managed objects for
configuration of middleboxes. The scope of the middleboxes to which
these managed objects apply is limited to NATs and Firewalls. However,
the MIB module as defined by this document is intended to provide a
baseline for the configuration of other types of middleboxes. The
applicability of existing Management Information Base (MIB) modules to
the MIDCOM requirements, framework and semantics is described.
Additional managed objects are defined to satisfy the entirety of the
MIDCOM requirements, framework and semantics, providing a complete
MIDCOM MIB for NATs and Firewalls.
Table of Contents
1. SNMP Management Framework......................................2
2. MIDCOM Overview and SNMP Applicability.........................2
3. SNMP and the MIDCOM data model.................................3
3.1 Secure Communications......................................5
3.2 Device Configuration.......................................5
3.3 Service Configuration......................................6
3.4 Policy Coordination........................................7
3.5 Policy Specification.......................................8
4. Applicability of existing MIBs.................................8
5. Additional MIDCOM specific managed objects.....................9
6. Security Considerations........................................9
Normative References..............................................9
Informative References...........................................10
Full Copyright Statement.........................................11
Barnes,et.al. Expires û August 2003 [Page 1]
MIDCOM MIB March 2003
Overview
This intent of this document is to define a Management Information base
(MIB) for configuration of middleboxes. The scope of the middleboxes to
which this MIB is specifically applied is limited to NATs and Firewalls.
However, this MIB is intended to be extensible and provide a baseline
for the development of managed objects for configuring other types of
middleboxes.
Section 1 provides an overview of the SNMP Management Framework. Section
2 provides further background on SNMP and its applicability to the
MIDCOM Protocol Framework, Requirements and semantics.
Section 3 provides a high level overview of some existing mibs
potentially relevant and reusable, which satisfy the MIDCOM requirements
and semantics, and relate to the MIDCOM architecture and framework.
Section 4 provides a detailed discussion of existing MIBs, defining the
level of applicability to the MIDCOM protocol requirements, framework
and semantics and re-usability for the MIDCOM MIB.
Section 5 defines the additional MIDCOM specific managed objects
required to satisfy some of the requirements and to provide a linkage
between the existing MIBs applicable to MIDCOM.
Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
1. SNMP Management Framework
For a detailed overview of the documents that describe the current
Internet-Standard (SNMP) Management Framework, please refer to section 7
of RFC 3410 [RFC3410].
Managed objects are accessed via a virtual information store, termed the
Management Information Base or MIB. MIB objects are generally accessed
through the Simple Network Management Protocol (SNMP). Objects in the
MIB are defined using the mechanisms defined in the Structure of
Management Information (SMI). This memo specifies a MIB module that is
compliant to the SMIv2, which is described in STD 58, RFC 2578
[RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580[RFC2580].
2. MIDCOM Overview and SNMP Applicability
The MIDCOM architecture and framework [RFC3303] defines a model in which
trusted third parties can be delegated to assist middleboxes in
performing their operations, without requiring application intelligence
be embedded in the middleboxes. This trusted third party is referred to
as the MIDCOM Agent. The MIDCOM protocol is defined between the MIDCOM
agent and middlebox.
The SNMP management framework provides functions equivalent to those
defined by the MIDCOM framework, although there are a few architectural
differences.
Barnes, et. al. Expires - August 2003 [Page 2]
MIDCOM MIB March 2003
For SNMP, application intelligence is captured in MIB modules, rather
than in the messaging protocol. MIB modules define a data model of the
information that can be collected and configured for managed
functionality. The SNMP messaging protocol transports the data in a
standardized format without needing to understand the semantics of the
data being transferred. The endpoints of the communication understand
the semantics of the data.
Traditionally, the SNMP endpoints have been called Manager and Agent. An
SNMP manager is an entity capable of generating requests and receiving
notifications, and a SNMP agent is an entity capable of responding to
requests and generating notifications. As applied to the MIDCOM
framework, the SNMP Manager corresponds to the MIDCOM agent and the SNMP
Agent corresponds to the Middlebox.
The MIDCOM protocol is divided into three phases, per section 4 of
[RFC3303]:
o Session Setup
o Run-time (involving real-time configuration of the middlebox)
o Session Termination
A MIDCOM session is defined to be a lasting association between a MIDCOM
agent and a middlebox. The MIDCOM agent should initiate the session
prior to the start of the application. Although the SNMP management
framework does not have the concept of a session, session-like
associations can be established through the use of managed objects.
Requests from the MIDCOM agent to the Middlebox would be performed using
write access to managed objects defined in MIB modules. The middlebox
(SNMP agent) would respond to requests by sending an SNMP response
message indicating success or failure at modifying the managed objects.
The MIDCOM agent (SNMP manager) can verify this information by reading
or polling the corresponding managed objects, if desired.
The MIDCOM Protocol semantics [MDCSEM] defines two basic transaction
types: request transactions and notify transactions. SNMPv3 uses the
architecture detailed in [RFC3411], where all SNMP entities are capable
of performing certain functions, such as the generation of requests,
response to requests, the generation of asynchronous notifications, the
receipt of notifications, and the proxy-forwarding of SNMP messages.
SNMP is used to read and manipulate a virtual database (the MIB) which
is composed of objects representing commands, controls, status, and
statistics, which are defined in managed-application-specific MIB
modules.
Application-specific mib modules can be defined at varying levels of
abstraction. At the lowest level, vendor-specific, device-specific
parameters may be defined, for instance, to configure a specific model
of firewall. At a higher level, a mib module may define an abstracted
view of firewall functionality that can be used to specify a firewall
policy, which an implementation can translate into the necessary
parameters to configure the specific model of firewall on which the
abstract mib is implemented. At a higher level yet, a mib module may
define service policies or business policies that end up being
translated into more detailed instructions, possibly into the more
detailed mib module data schemas. It is common practice to have one mib
module point to other mib modules that contain less/more concrete
conceptual representations.
3. SNMP and the MIDCOM data model
Barnes, et. al. Expires - August 2003 [Page 3]
MIDCOM MIB March 2003
This section provides a high level description of the categories of data
required to satisfy the MIDCOM requirements and semantics as it relates
to existing SNMP mib models. Wherever possible, mib designers should
attempt to reuse functionality provided by existing mibs.
SNMP for MIDCOM can leverage the data schemas of many existing mib
models designed to permit secure communications, configuration of
devices, configuration of services, policy coordination abstractions,
and the specification of policies. As well as specifying policies,
MIDCOM must verify that policies are being enforced, and many existing
mibs provide monitoring capabilities that can be applied to MIDCOM
functionality.
The following diagram (Figure 1) summarizes the potential relevance and
reusability of the data schema of existing mib models to the MIDCOM
architecture to satisfy the MIDCOM protocol framework, requirements and
semantics:
+----------------------+
| Application |
| |
| +---------------+ |
| | MIDCOM agent | |
| | | |
| | | |
| +---------------+ | +------------+
+------------^---------+ | |
. | Policy |
. | |
. | +--------+ |
Application . | | MIDCOM | |
Requests . /+-| PDP | |
(via SNMP) . / | +--------+ |
. / +------------+
. /
. /
. /
. |
v v
+-------------------------------------------+
| Middlebox * * |
| * a. * b. |
| v v |
| +-------------------------------+ |
| | Middlebox Communication | |
| | Protocol (MIDCOM) Interface | |
| +-------------------------------+ |
| * |
| * c. |
| v |
| +-------------------------------+ |
| | Device/Service Configuration | |
| | | |
| +-------------------------------+ |
| |
+-------------------------------------------+
Legend: .... Middlebox Communication Protocol (MIDCOM)
Barnes, et. al. Expires - August 2003 [Page 4]
MIDCOM MIB March 2003
//// MIDCOM PDP Interface (outside scope of this document)
**** Managed objects relevant to the MIDCOM Interface
(with the associated letters referencing the
mibs potentially applicable summarized below:
a. gaps between existing mibs (b and c) and MIDCOM
requirements
b. POLICY-BASED-MANAGEMENT-MIB, DIFFSERV-CONFIG-MIB,
c. IPSEC-POLICY-MIB
NAT-MIB, DIFFSERV-MIB, IPSEC-POLICY-MIB
Figure 1: Data relationships relevant to the MIDCOM Interface
3.1 Secure Communications
SNMPv3 is designed to provide secure communications between two end-
points, and it provides a proxy capability that can be used to define
trust relationships between multiple domains.
MIDCOM requirements include mutual authentication, message integrity
checking, timeliness checking to prevent replay, message encryption, and
authorization controls to ensure only certain agents can modify certain
subsets of middlebox configurations. MIDCOM requires secure request-
response capabilities and secure notifications.
SNMPv3 defines mib modules to allow the monitoring and configuration of
all these security features. They are defined in RFC3411-RFC3418, and
RFC3410 provides an overview of these capabilities.
3.2 Device Configuration
SNMP is the most commonly used standardized protocol for remotely
monitoring and manipulating the configuration of devices. There are a
large number of IETF standard and vendor-specific mib modules available.
CLI is used more than SNMP for large-scale configuration, but it is not
standardized, which makes the development of vendor-neutral device
configuration policies more difficult.
Most IETF standard mib modules do not provide much configuration support
because SNMPv1 and SNMPv2c were non-secure, and it is difficult to
standardize abstractions that provide enough information to configure
device implementations that require vendor-specific parameters. There
are many vendor-specific mib modules that permit configuration of the
vendorÆs devices.
SNMP mib modules are definitions of virtual databases with scalars and
tables of data. SNMP supports multiple mechanisms to define
relationships between entries in different tables. For example, entries
in multiple tables are often related by common indices. SNMP uses a
standardized hierarchical namespace, so the value of a field in one
table can serve as the index into another table.
The ability to define relationships between mib tables (including tables
in different mib modules) allows an abstracted configuration policy to
point to a vendor-specific configuration mib for more detailed
instructions.
Barnes, et. al. Expires - August 2003 [Page 5]
MIDCOM MIB March 2003
There are multiple ways to send policies to middleboxes, including SNMP
and COPS/PR and RADIUS/Diameter, and most policies are auto-magically
converted into low-level configuration commands that set the correct
operational parameters to enforce desired behavior.
Some middlebox functionalities are related to physical and logical
topologies that are created by manipulating device configurations. Some
mibs that can be used for topology configuration would include the
802.1X MIB [81XMIB] and the Interfaces MIB [RFC2863] to enable or
disable a physical port or logical interface, the Bridge MIB [BREMIB]to
assign interfaces into virtual LANs and to enable port mirroring
functionality for IDS usage, the Layer Two Tunneling MIB or IPSec MIB to
create topology tunnels for VPNs, and so on.
There are many IETF standard mibs that monitor traffic, which can be
used to verify that a policy is being enforced. Most ôtransmissionö mib
modules, those that fall under the { mib-2 transmission } subtree
relative to Interfaces MIB entries, provide statistics about traffic
going in or out of ports on a device. The Bridge MIB can be used to
monitor the amount of traffic being forwarded into or out of virtual
LANs, and so on.
3.3 Service Configuration
A middlebox may be able to support multiple types of services, and a
MIDCOM agent must determine which services are available and running,
and which have stopped running. Middlebox functionalities are
applications that run on a middlebox, and there are multiple mib modules
designed to monitor applications and their operational characteristics.
Most of the mibs described here are for monitoring only, but could be
extended with application-specific mibs for configuration and additional
monitoring.
The Host Resources MIB [RFC2790]provides monitoring of hardware
resources, such as memory and CPU load, and monitors installed
applications, running applications, and application performance. These
can be used to do capability discovery for a middlebox, and these
factors can be important to consider before configuring additional
functionality or sessions on a middlebox.
The Network Services Monitoring MIB [RFC2788] module provides objects
for monitoring high-level concepts related to network services, such as
their current run status and their associations. This mib works with
supplemental service-specific mib modules, including configuration
objects.
The Systems Application MIB [RFC2287] monitors installed applications,
running applications, and running processes. The installed application
information can be important for determining the actual capabilities of
the model and version of firewall installed.
The Application MIB [RFC2564] permits identification of one or more
instances of named services on a system, and the association of running
application elements to these services. The mib permits monitoring
transaction streams and the relation to I/O channels. In the MIDCOM
environment, it could permit discovering a firewall and the associated
installed signature packages.
Barnes, et. al. Expires - August 2003 [Page 6]
MIDCOM MIB March 2003
The WWW Services MIB [RFC2594] is an example of a service-specific mib
that works with the generic Systems Application and Applications mib
modules.
But MIDCOM is primarily about configuring middlebox functionality, so we
should look at mib modules that can do configuration of firewalls and
NATS.
The Diffserv MIB [RFC3289] describes the configuration and management of
a Differentiated Services interface in terms of one or more Traffic
Conditioning Blocks (TCB), each containing, arranged in the specified
order, by definition, zero or more classifiers, meters, actions,
algorithmic droppers, queues and schedulers. The ôlinked-listö approach
is very flexible, and could be used to configure some firewall tasks.
The use of RowPointers as connectors in the Diffserv MIB allows for the
simple extension of the MIB. The RowPointers, whether "next" or
"specific", may point to Entries defined in other MIB modules. This
mechanism can point to other, possibly vendor-specific, configuration
mibs.
The IPSec Policy MIB [IPCMIB] defines objects that could be reused for
purposes of filtering service-related traffic and subsequent policy
actions.
3.4 Policy Coordination
To properly coordinate policy application, it is necessary to determine
if a device has the capabilities needed to effectively enforce a policy,
and to coordinate the application of policies according to time
constraints, priorities, rule groupings, policy sessions, and so on.
The SNMPCONF working has developed a number of mib modules designed for
the purpose of policy coordination.
Many policies are dependent on factors that are not so much traffic-
related as business related. The role that a person plays in the
organization, or that a device serves in the network, or the geographic
location of a device may impact a policy. The SNMPCONF Policy MIB
[PBMMIB] allows an administrator to define roles, and associate them
with policies. A notification facility is included so a PDP can be
informed when a new role is defined for a system.
The SNMPCONF mibs include a policy download table, a policy registration
table, and a scheduling function for defining when a policy should be
made active and when it should be made dormant. Time schedules can be
grouped for easier manipulation, and wildcards are supported. To ease
integration with other policy efforts, the schedule table is modeled
after the Policy Core Information Model scheduler.
SNMPCONF provides a capabilities table to advertise the functionality
available for policy enforcement, including configuration parameters to
enable a MIDCOM agent to be notified when new capabilities are installed
on a system. Capabilities may be available on some components of a
system and not others, such as a board in a chassis, but also may be
accessible only in certain logical partitions, such as the community
profile (more accurately, the SNMPv3 context) of the super-user.
Barnes, et. al. Expires - August 2003 [Page 7]
MIDCOM MIB March 2003
SNMPCONF defines tracking tables, so an administrator can determine
which elements are being controlled by which policies. The mib also
includes debugging tables for logging policy enforcement run-time
exceptions. An administrator can disable policies in place, if they
desire.
3.5 Policy Specification
SNMPCONF Policies have configurable priorities, may be assigned to
groups that have their own priorities, support actions-on-error
planning, and parameters to specify how frequently an element should be
checked to verify that the configuration matches the policy. Statistics
about the application of policies and errors conditions encountered are
included.
SNMPCONF is designed to work with other mibs that provide more concrete
specifications of policy. The Diffserv Configuration MIB [DPCMIB], for
example, defines a template that SNMPCONF applies to the Diffserv MIB
mentioned above.
4. Applicability of existing MIBs
This section summarizes the details of the applicability of existing
mibs to the MIDCOM data model. As highlighted in Figure 1, the MIDCOM
protocol itself is only defined to be the interface from the MIDCOM
agent (SNMP manager) to the middlebox or MIDCOM Interface. However,
Requests from the MIDCOM agent to the MIDCOM Interface must be evaluated
against the installed policies and must contain all the data required
for the specific device/service configuration. In addition, the session
setup reply includes capabilities of the middlebox, several of which
relate to policies. Thus, although the Policy interface itself is out
of scope of the MIDCOM protocol, the correlation of the policy related
data to the data associated with the MIDCOM Interface is imperative. In
effect, an instance of the "MIDCOM mib" comprises the data from the
semantics evaluated against the policy and applied to configure the
device/service.
The following MIBs were analyzed and found to have a high level of
applicability and re-usability for MIDCOM:
o Network Address Translators (NAT) MIB [NATMIB]
o <to be completed once detailed analysis is done >
4.1 Network Address Translators (NAT) MIB
There is currently a NAT MIB module [NATMIB] under development for
configuring NATs. The NAT MIB module appears to meet all of the MIDCOM
requirements concerning NAT control. Additional MIBs, such as those
defined by SNMP Policy Based Management MIB, allowing the definition of
policy rulesets and grouping of policy rules would also be required.
4.2
4.4 Summary of applicability of existing MIBs
< To Be Completed >
<Diagram showing these MIBs as applied to the basic data model>
Barnes, et. al. Expires - August 2003 [Page 8]
MIDCOM MIB March 2003
5. Additional MIDCOM specific managed objects
<MIDCOM specific managed objects may be required to satisfy some of the
requirements and to provide a linkage between the existing MIBs
applicable to MIDCOM.>
< To Be Completed >
6. Security Considerations
The MIDCOM requirements [RFC3304] defines the general security
requirements for the MIDCOM protocol. The SNMPv3 User-based Security
Model (USM, [RFC2574]) satisfies those requirements. USM defines three
standardized methods for providing authentication, confidentiality, and
integrity. The method to use can be optionally chosen. The methods
operate securely across untrusted domains. Additionally, USM has
specific built-in mechanisms for preventing replay attacks including
unique protocol engine IDs, timers and counters per engine and time
windows for the validity of messages.
Normative References
[RFC3304] R. Swale, P. Mart, P. Sijben, S. Brim, M. Shore, "Middlebox
Communications (MIDCOM) Protocol Requirements", RFC 3304, August, 2002.
[RFC3303] P. Srisuresh, J. Kuthan, J. Rosenberg, A. Molitor, A. Rayhan,
"Middlebox Communications Architecture and Framework", RFC 3303, August,
2002.
[MDCSEM] Stiemerling, M., Quittek, J., Taylor, T., "MIDCOM Protocol
Semantics", draft-ietf-midcom-semantics-01.txt, February, 2003.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997.
[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.
[RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture
for Describing SNMP Management Frameworks", STD 62, RFC 3411, November
2002.
[RFC3412] Case, J., Harrington D., Presuhn R., and B. Wijnen, "Message
Processing and Dispatching for the Simple Network Management Protocol
(SNMP)", STD 62, RFC 3412, November 2002.
[RFC3413] Levi, D., Meyer, P., and B. Stewart, "SNMPv3 Applications",
STD 62, RFC 3413, November 2002.
Barnes, et. al. Expires - August 2003 [Page 9]
MIDCOM MIB March 2003
[RFC3414] Blumenthal, U., and B. Wijnen, "User-based Security Model(USM)
for version 3 of the Simple Network Management Protocol (SNMPv3)", STD
62, RFC 3414, November 2002.
[RFC3415] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based Access
Control Model (VACM) for the Simple Network Management Protocol (SNMP)",
STD 62, RFC 3415, November 2002.
[NATMIB] Raghunarayan, R., Pai, N., Rohit, R., Wang, C., Srisuresh, P.,
"Definitions of Managed Objects for Network Address Translators (NAT)",
draft-ietf-nat-natmib-05.txt, November, 2002.
[PBMMIB] Waldbusser, S., Saperia, J., Hongal, T., "Policy Based
Management MIB", draft-ietf-snmpconf-pm-13.txt, March, 2003.
[IPCMIB] Baer, M., Charlet, R., Hardaker, W., Story, R., Wang, C.,
"IPsec Policy Configuration MIB module", draft-ietf-ipsp-ipsec-conf-mib-
06.txt, November, 2002.
Informative References
[RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart,
"Introduction to Version 3 of the Internet-standard Network Management
Framework", 3410, November 2002.
[MDCPEV] Barnes, M., "Middlebox Communications (MIDCOM) Protocol
Evaluation", draft-ietf-midcom-protocol-eval-06.txt, November, 2002.
[RFC2287] Krupczak, C. and J. Saperia, "Definitions of System-Level
Managed Objects for Applications", RFC 2287, February 1998.
[RFC2564] C. Kalbfleisch, C. Krupczak, R.Presuhn, J. Saperia,
"Application Management MIB", May 1999.
[RFC2594] H. Hazewinkel, C. Kalbfleisch, J. Schoenwaelder, "Definitions
of Managed Objects for WWW Services", May 1999.
[RFC2788] N. Freed, S. Kille, "Network Services Monitoring MIB", RFC
2788, March 2000.
[RFC2790] S. Waldbusser, P. Grillo, "Host Resources MIB", March 2000.
[RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB
using SMIv2", RFC 2863, June 2000.
[RFC3289] Baker, F., Chan, K., Smith, A., "Management Information Base
for the Differentiated Services Architecture", RFC 3289, May 2002.
[DPCMIB] Hazewinkel, H, Partain, D., "The Differentiated Services
Configuration MIB", draft-ietf-snmpconf-diffpolicy-05.txt, June 2002.
[BRGMIB] Norseth, K.C. and Bell, E., "Definitions of Managed Objects for
Bridges", draft-ietf-bridge-bridgemib-smiv2-04.txt, October 2002.
[BREMIB] Ngai, V., "Definitions of Managed Objects for Bridges with
Traffic Classes, Multicast Filtering and Virtual LAN Extensions", draft-
ietf-bridge-ext-v2-01.txt, September 2002.
Barnes, et. al. Expires - August 2003 [Page 10]
MIDCOM MIB March 2003
[81xMIB] Norseth, K.C. "Definitions for Port Access Control (IEEE
802.1X) MIB", draft-ietf-bridge-8021x-01.txt, February, 2003.
Acknowledgements
Author's Address
Mary Barnes
Nortel Networks
2380 Performance Drive Phone: 1-972-684-5432
Richardson, TX USA Email: mbarnes@nortelnetworks.com
David Harrington Co-chair SNMPv3 WG
Enterasys Networks
35 Industrial Way Phone: +1 603-337-2614
Rochester, NH 03867-5005 EMail: dbh@enterasys.com
Martin Stiemerling
NEC Europe Ltd.
Network Laboratories
Adenauerplatz 6
69115 Heidelberg Phone: +49 6221 90511-13
Germany Email: stiemerling@ccrle.nec.de
Full Copyright Statement
Copyright (C) The Internet Society (2003). 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."
Barnes, et. al. Expires - August 2003 [Page 11] | PAFTECH AB 2003-2026 | 2026-04-23 08:52:13 |