IP over InfiniBand
Internet Draft Hal Rosenstock
draft-ietf-ipoib-ibmib-tc-mib-08.txt HNR Consulting
Expires: December 2006 June 2006
Definitions of Textual Conventions
and OBJECT-IDENTITIES for
IP Over InfiniBand (IPOVERIB) Management
<draft-ietf-ipoib-ibmib-tc-mib-08.txt>
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
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 memo defines a Management Information Base (MIB) module that
contains Textual Conventions and OBJECT-IDENTITIES for use in
definitions of management information for IP Over InfiniBand
(IPOVERIB) networks. The intent is that these TEXTUAL
CONVENTIONs (TCs) will be imported and used in IPOVERIB related
MIB modules.
Copyright Notice
Copyright (C) The Internet Society (2006).
Rosenstock Expires December 2006 [Page 1]
Internet-Draft IPOVERIB TC MIB Module June 2006
Table of Contents
1. Introduction...................................................3
2. The Internet-Standard Management Framework.....................3
3. IPOVERIB Textual Conventions MIB Definitions...................4
4. Security Considerations.......................................12
5. IANA Considerations...........................................12
6. Revision History..............................................12
6.1 Changes from <draft-ietf-ipoib-ibmib-tc-mib-07.txt>.......12
7. References....................................................12
7.1 Normative References......................................13
7.2 Informative References....................................13
8. Acknowledgements..............................................13
9. Author's Address..............................................13
10. Intellectual Property Notice.................................14
11. Full Copyright Statement.....................................14
Rosenstock Expires December 2006 [Page 2]
Internet-Draft IPOVERIB TC MIB Module June 2006
1. Introduction
This memo defines a portion of the Management Information Base for
use with network management protocols in the Internet community.
In particular, it defines Textual Conventions used in IETF IPOVERIB
and IPOVERIB-related MIBs.
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].
For an introduction to the concepts of InfiniBand, see [IBTAARCH].
2. The Internet-Standard Management Framework
For a detailed overview of the documents that describe the current
Internet-Standard 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].
Rosenstock Expires December 2006 [Page 3]
Internet-Draft IPOVERIB TC MIB Module June 2006
3. IPOVERIB Textual Conventions MIB Definitions
IB-TC-MIB DEFINITIONS ::= BEGIN
IMPORTS
experimental, MODULE-IDENTITY, Unsigned32
FROM SNMPv2-SMI -- [RFC 2578]
TEXTUAL-CONVENTION
FROM SNMPv2-TC; -- [RFC 2579]
ibTcMIB MODULE-IDENTITY
LAST-UPDATED "200606270000Z" -- 27 June 2006 00:00:00 GMT
ORGANIZATION
"IETF IP over IB (IPOIB) Working Group"
CONTACT-INFO
"Hal Rosenstock
Postal: HNR Consulting
200 Old Harvard Road
Boxboro MA 01719-1834
United States
Email: hnrose@earthlink.net
Email comments to the IPOIB WG Mailing List at
ipoverib@ietf.org."
DESCRIPTION
"Copyright (C) The Internet Society (2006). The initial
version of this MIB module was published in RFC XXXX; for
full legal notices see the RFC itself. Supplementary
information may be available on
http://www.ietf.org/copyrights/ianamib.html.
This MIB contains managed object definitions and textual
conventions for managing InfiniBand devices that support
the IP Over InfiniBand (IPOIB) protocols and procedures."
REVISION
"200606270000Z" -- 27 June 2006 00:00:00 GMT
DESCRIPTION
"Initial version published as part of RFC XXXX."
::= { infinibandMIB 1 }
-- The IANA has currently defined the InfiniBand MIB on the
-- experimental branch.
infinibandMIB OBJECT IDENTIFIER ::= { experimental 117 }
-- This object identifier needs to be reassigned by IANA.
-- Since infiniband has been assigned an ifType of 199 a
-- recommendation is made that this OID be 199 as well, e.g.
Rosenstock Expires December 2006 [Page 4]
Internet-Draft IPOVERIB TC MIB Module June 2006
-- ::= { transmission 199 }
--
-- The updated Object Identifier definition would be:
--
-- infinibandMIB OBJECT IDENTIFIER ::= { transmission 199 }
--
-- Textual Conventions.
IbPort ::= TEXTUAL-CONVENTION
DISPLAY-HINT "d"
STATUS current
DESCRIPTION
"Identifies an InfiniBand (IB) Port. The InfiniBand
Architecture (IBA) defines a maximum of 254 physical ports
numbered Port 1 to Port 254. A port is the location on a
Channel Adapter, IB Router, or IB Switch to which a link is
connected. If a device has N ports, the physical ports are
always numbered from 1 to N. The relationship between an
InfiniBand port and an ifIndex is one-to-one. As such, the
value of an ifIndex object instance can be directly used to
identify corresponding instances of the objects defined
herein as IB ports. Note: this definition does include
enhanced switch port 0 but not base switch port 0. In the
case of a switch with enhanced switch port 0, the ifIndex is
offset by 1 from the ibPort. In all other cases, the ifIndex
is identical to the ibPort."
REFERENCE
"InfiniBand Architecture Release 1.2 Vol. 1. [IBTAARCH]
Section 18.2.4.1 (C18-10.a1) for switches and (C18-14.a1)
for switch port 0, Section 17.2.1.3 (C17-7.a1) for Channel
Adapters, and Section 19.2.4.2 for routers."
SYNTAX Unsigned32 (0..254)
IbPhysPort ::= TEXTUAL-CONVENTION
DISPLAY-HINT "d"
STATUS current
DESCRIPTION
"Identifies a physical InfiniBand (IB) Port. The InfiniBand
Architecture (IBA) defines a maximum of 254 physical ports
numbered Port 1 to Port 254. A port is the location on a
Channel Adapter, IB Router, or IB Switch to which a link is
connected. If a device has N ports, the ports are always
numbered from 1 to N. Note: this definition does NOT include
switch Port 0, which is not a physical port."
REFERENCE
"InfiniBand Architecture Release 1.2 Vol. 1. [IBTAARCH]
Section 18.2.4.1 (C18-10.a1) for switches, Section 17.2.1.3
Rosenstock Expires December 2006 [Page 5]
Internet-Draft IPOVERIB TC MIB Module June 2006
(C17-7.a1) for Channel Adapters, and Section 19.2.4.2 for
routers."
SYNTAX Unsigned32 (1..254)
IbPhysPortAndInvalid ::= TEXTUAL-CONVENTION
DISPLAY-HINT "d"
STATUS current
DESCRIPTION
"Identifies a physical IB port plus an invalid port number.
The invalid port number has a value of 255. Note: this
definition does NOT include switch logical Port 0, which is
not a physical port."
REFERENCE
"InfiniBand Architecture Release 1.2 Vol. 1. [IBTAARCH]
Section 18.2.4.1 (C18-10.a1) for switches, Section 17.2.1.3
(C17-7.a1) for Channel Adapters, and Section 19.2.4.2 for
routers."
SYNTAX Unsigned32 (1..255)
IbDataPort ::= TEXTUAL-CONVENTION
DISPLAY-HINT "d"
STATUS deprecated
DESCRIPTION
"Identifies a physical InfiniBand (IB) Port. The InfiniBand
Architecture (IBA) defines a maximum of 254 physical ports
numbered Port 1 to Port 254. A port is the location on a
Channel Adapter, IB Router, or IB Switch to which a link is
connected. If a device has N ports, the ports are always
numbered from 1 to N. The relationship between an InfiniBand
port and an ifIndex is one-to-one. As such, the value of an
ifIndex object instance can be directly used to identify
corresponding instances of the objects defined herein as IB
data ports. Note: this definition does NOT include logical
Port 0, which is reserved for IB management packets."
REFERENCE
"InfiniBand Architecture Release 1.2 Vol. 1. [IBTAARCH]
Section 18.2.4.1 (C18-10.a1) for switches, Section 17.2.1.3
(C17-7.a1) for Channel Adapters, and Section 19.2.4.2 for
routers."
SYNTAX Unsigned32 (1..254)
IbDataPortAndInvalid ::= TEXTUAL-CONVENTION
STATUS deprecated
DESCRIPTION
"Identifies a physical IB port plus an invalid port number.
The invalid port number has a value of 255. Note: this
definition does NOT include logical Port 0, which is reserved
for IB management packets."
REFERENCE
Rosenstock Expires December 2006 [Page 6]
Internet-Draft IPOVERIB TC MIB Module June 2006
"InfiniBand Architecture Release 1.2 Vol. 1. [IBTAARCH]
Section 18.2.4.1 (C18-10.a1) for switches, Section 17.2.1.3
(C17-7.a1) for Channel Adapters, and Section 19.2.4.2 for
routers."
SYNTAX Unsigned32 (1..255)
IbVirtualLane ::= TEXTUAL-CONVENTION
DISPLAY-HINT "d"
STATUS current
DESCRIPTION
"Identifies a Virtual Lane (VL) instance on a given interface
(i.e., IB port). VLs provide a mechanism for creating
multiple virtual links within a physical link. IBA defines
VL 0 through VL 14 for data and VL 15 exclusively for Subnet
Management. The actual data VLs that a port uses are
configured by the Subnet Manager. The default data VL is
always VL 0."
REFERENCE
"InfiniBand Architecture Release 1.2 Vol. 1. [IBTAARCH]
Section 3.5.7."
SYNTAX Unsigned32 (0..15)
IbDataVirtualLane ::= TEXTUAL-CONVENTION
DISPLAY-HINT "d"
STATUS current
DESCRIPTION
"Identifies a Data Virtual Lane instance on a given interface
(i.e., IB port). This TC definition excludes the management
Virtual Lane (VL 15). The actual data VLs that a port uses
are configured by the Subnet Manager. The default data VL is
always the first VL (VL 0)."
REFERENCE
"InfiniBand Architecture Release 1.2 Vol. 1. [IBTAARCH]
Section 3.5.7."
SYNTAX Unsigned32 (0..14)
IbDlid ::= TEXTUAL-CONVENTION
DISPLAY-HINT "d"
STATUS current
DESCRIPTION
"Identifies the Destination Local Identifier (DLID). The IBA
defines LID 0 as reserved and valid Local Identifier (LID)
values from 1 to 65535. LID 65535 is defined as a permissive
DLID.
This value is stored in IBA defined bit order, that is, the
high-order bit of the Local Identifier byte 0 is positioned
as the high-order bit of the first byte of the integer
representation."
Rosenstock Expires December 2006 [Page 7]
Internet-Draft IPOVERIB TC MIB Module June 2006
REFERENCE
"InfiniBand Architecture Release 1.2 Vol. 1. [IBTAARCH]
Section 4.1.3."
SYNTAX Unsigned32 (0..65535)
IbUnicastLid ::= TEXTUAL-CONVENTION
DISPLAY-HINT "d"
STATUS current
DESCRIPTION
"Identifies a Unicast LID. Value is stored in IBA defined bit
order, that is, the high-order bit of the Local Identifier
byte 0 is positioned as the high-order bit of the first byte
of the integer representation."
REFERENCE
"InfiniBand Architecture Release 1.2 Vol. 1. [IBTAARCH]
Section 4.1.3."
SYNTAX Unsigned32 (0..49151)
IbMulticastLid ::= TEXTUAL-CONVENTION
DISPLAY-HINT "d"
STATUS current
DESCRIPTION
"Identifies a Multicast LID. Value is stored in IBA defined
bit order, that is, the high-order bit of the Local
Identifier byte 0 is positioned as the high-order bit of the
first byte of the integer representation."
REFERENCE
"InfiniBand Architecture Release 1.2 Vol. 1. [IBTAARCH]
Section 4.1.3."
SYNTAX Unsigned32 (49152..65535)
IbGuid ::= TEXTUAL-CONVENTION
DISPLAY-HINT "1x:"
STATUS current
DESCRIPTION
"Globally Unique Identifier (GUID) is a number that uniquely
identifies an IB device or component. It is a compliant
IEEE-defined 64-bit extended unique identifier (EUI-64)
for Host Channel Adapters (HCA), Terminal Channel Adpaters
(TCA), routers, and switches. This 64-bit value is created
by concatenating a 24-bit company ID value and a 40-bit
extension. The IEEE Registration Authority assigns the
company ID. The extension ID is assigned by the particular
company. Each HCA, TCA, switch, and router as well as each
endport shall be assigned an EUI-64 GUID by the
manufacturer."
REFERENCE
"InfiniBand Architecture Release 1.2 Vol. 1. [IBTAARCH]
Section 4.1."
Rosenstock Expires December 2006 [Page 8]
Internet-Draft IPOVERIB TC MIB Module June 2006
SYNTAX OCTET STRING (SIZE(8))
IbSmaPortList ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"Each bit mapping within this value specifies a port presence
within the managed IB device. This definition includes bit0
as IB Port 0, the switch management port. Valid physical
port mappings are from bit1 to bit254. Bit255 is invalid
and MUST always be zero."
REFERENCE
"InfiniBand Architecture Release 1.2 Vol. 1. [IBTAARCH]
Section 18.2.4.1 (C18-10.a1) for switches and (C18-14.a1)
for switch port 0, Section 17.2.1.3 (C17-7.a1) for Channel
Adapters, and Section 19.2.4.2 for routers."
SYNTAX OCTET STRING (SIZE(32))
IbSmPortList ::= TEXTUAL-CONVENTION
STATUS deprecated
DESCRIPTION
"Each bit mapping within this value specifies a port presence
within the managed IB device. This definition includes bit0
as IB Port 0, the logical port used exclusively for
management packets. Valid data port mappings are from bit1 to
bit254. Bit255 is invalid and MUST always be zero."
REFERENCE
"InfiniBand Architecture Release 1.2 Vol. 1. [IBTAARCH]
Section 18.2.4.1 (C18-10.a1) for switches, Section 17.2.1.3
(C17-7.a1) for Channel Adapters, and Section 19.2.4.2 for
routers."
SYNTAX OCTET STRING (SIZE(32))
IbIpoibClientIdentifier ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"The IPOIB Client Identifier uniquely identifies an IPOIB link
layer address associated with the InfiniBand port. It
comprises three fields.
1. Global Identifier (GID)
2. Queue Pair Number field (QPN)
3. reserved
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1:GID(0-7) |2:GID(8-15) |3:GID(16-23) |4:GID(24-31) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|5:GID(32-39) |6:GID(40-47) |7:GID(48-55) |8:GID(56-63) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Rosenstock Expires December 2006 [Page 9]
Internet-Draft IPOVERIB TC MIB Module June 2006
|9:GID(64-71) |10:GID(72-79) |11:GID(80-87) |12:GID(88-95) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|13:GID(96-103) |14:GID(104-111)|15:GID(112-119)|16:GID(120-127)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|17:QPN(0-7) |18:QPN(8-15) |19:QPN(16-23) |20:(reserved) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Global Identifier field is a 16 octet field (octets 1
through 16) that is formed by the combination of the IB
subnet prefix and the port's GUID. It is unique in the
InfiniBand fabric. NOTE: An IPOIB interface may have more
than 1 GID associated with it.
The Queue Pair Number field is a 3 octet field (octets 17,
18, & 19) that identifies the destination queue pair. Note:
The reserved field and the QPN field are collectively
referred to as the interface-id. If an IPOIB interface has
only 1 GID associated with it, the interface-id MAY contain
all zeroes.
The reserved field is octet 20. It is reserved for future
use. These bits SHOULD be set to zero."
SYNTAX OCTET STRING (SIZE(20))
IbSmSubnetPrefix ::= TEXTUAL-CONVENTION
DISPLAY-HINT "2x:"
STATUS current
DESCRIPTION
"The 64-bit value used to identify an InfiniBand subnet."
SYNTAX OCTET STRING (SIZE(8))
IbSmState ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"Subnet Manager's state:
notActive(0) SM is not active
discovering(1) SM is discovering subnet
standby(2) SM is in standby role
master(3) SM is in master role."
SYNTAX INTEGER {
notActive(0),
discovering(1),
standby(2),
master(3)
}
IbNodeType ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
Rosenstock Expires December 2006 [Page 10]
Internet-Draft IPOVERIB TC MIB Module June 2006
"Type of InfiniBand node."
SYNTAX INTEGER {
unknown(0),
channelAdapter(1),
switch(2),
router(3)
}
IbMtu ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"The MTU size of this InfiniBand link."
SYNTAX INTEGER {
mtu256(1),
mtu512(2),
mtu1024(3),
mtu2048(4),
mtu4096(5)
}
IbPartitionKey ::= TEXTUAL-CONVENTION
DISPLAY-HINT "x"
STATUS current
DESCRIPTION
"The 16-bit Partition Key."
SYNTAX Unsigned32 (0..65535)
IbPartition ::= TEXTUAL-CONVENTION
DISPLAY-HINT "x"
STATUS current
DESCRIPTION
"The 15-bit Partition Key Base (without the membership bit)."
SYNTAX Unsigned32 (0..32767)
IbTransportTime ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"The time value used to calculate the InfiniBand network
delay or response. The duration of time is calculated
by the following formula:
delay/response = (4.096 microseconds * 2 ^ IbTransportTime)."
SYNTAX Unsigned32 (0..31)
END
Rosenstock Expires December 2006 [Page 11]
Internet-Draft IPOVERIB TC MIB Module June 2006
4. Security Considerations
This memo defines textual conventions and object identities for use
in IPOVERIB MIB modules. Security issues for these MIB modules are
addressed in the memos defining those modules. Because this memo
does not define management objects, the memo has no impact on the
security of the Internet.
5. IANA Considerations
IANA is requested to make a MIB OID assignment under the transmission
branch, that is, assign the infinibandMIB under { transmission 199 }.
This sub-id is requested because 199 is the ifType for
infiniband(199) and is available under transmission.
In the future, IPOIB related standards track MIB modules should be
rooted under the infinibandMIB subtree. The IANA is requested to
manage that namespace. New assignments can only be made via a
Standards Action as specified in [RFC2434].
This document also requests IANA to assign { infinibandMIB 1 } to the
IB-TC-MIB specified in this document.
6. Revision History
This section should be removed when this document is published as an
RFC.
6.1 Changes from <draft-ietf-ipoib-ibmib-tc-mib-07.txt>
Added IbPort, IbPhysPort, and IbPhysPortAndInvalid and deprecated
IbDataPort and IbDataPortAndInvalid
Added IbSmaPortList and deprecated IbSmPortList
Added IbPartition
Updated to InfiniBand Architecture Revision 1.2 from 1.1
Resolved nits with <draft-ietf-ipoib-ibmib-tc-mib-07.txt>
Added revision history
7. References
Rosenstock Expires December 2006 [Page 12]
Internet-Draft IPOVERIB TC MIB Module June 2006
7.1 Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP: 26, RFC 2434,
October 1998.
[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.
[IBTAARCH] InfiniBand Architecture Specification Volume 1,
Release 1.2, October, 2004, Final Release.
7.2 Informative References
[RFC3410] Case, J., Mundy, R., Partain, D. and B. Stewart,
"Introduction and Applicability Statements for
Internet-Standard Management Framework", RFC 3410,
December 2002.
8. Acknowledgements
This MIB module was updated based on the original work done by Sean
Harnedy. Bill Anderson, and Bill Strahm.
9. Author's Address
Hal Rosenstock
HNR Consulting
200 Old Harvard Road
Boxboro, MA 01719-1834
USA
Email: hnrose@earthlink.net
Rosenstock Expires December 2006 [Page 13]
Internet-Draft IPOVERIB TC MIB Module June 2006
10. Intellectual Property Notice
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights 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; nor does it
represent that it has made any independent effort to identify any
such rights. Information on the procedures with respect to rights
in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat 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 on-line IPR repository
at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention
any copyrights, patents or patent applications, or other
proprietary rights that may cover technology that may be required
to implement this standard. Please address the information to the
IETF at ietf-ipr@ietf.org.
11. Full Copyright Statement
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided
on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
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
Rosenstock Expires December 2006 [Page 14]
Internet-Draft IPOVERIB TC MIB Module June 2006
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.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Rosenstock Expires December 2006 [Page 15]
