draft-ietf-idr-bgp4-mib-02.txt   draft-ietf-idr-bgp4-mib-03.txt 
Network Working Group S. Willis Network Working Group S. Hares
INTERNET DRAFT Bay Networks INTERNET DRAFT Merit
J. Johnson
RedBack Networks
S. Willis
Argon Networks
J. Burruss J. Burruss
Windata WinData
J. Chu J. Chu
IBM Corporation IBM Corporation
J. Johnson February 1999
cisco Systems
March 1996
Definitions of Managed Objects Definitions of Managed Objects
for the Fourth Version of Border Gateway Protocol (BGP-4) for the Fourth Version of Border Gateway Protocol (BGP-4)
<draft-ietf-idr-bgp4-mib-02.txt> <draft-ietf-idr-bgp4-mib-03.txt>
Status of this Memo Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working This document is an Internet-Draft and is in full conformance with
documents of the Internet Engineering Task Force (IETF), its areas, and all provisions of Section 10 of RFC 2026.
its working groups. Note that other groups may also distribute working
documents as Internet-Drafts. 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 Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet- Drafts as reference material time. It is inappropriate to use Internet- Drafts as reference
or to cite them other than as ``work in progress.'' material or to cite them other than as "work in progress."
To learn the current status of any Internet-Draft, please check the The list of current Internet-Drafts can be accessed at
``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow http://www.ietf.org/ietf/1id-abstracts.txt
Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or The list of Internet-Draft Shadow Directories can be accessed at
ftp.isi.edu (US West Coast). http://www.ietf.org/shadow.html.
Copyright Notice
Copyright (C) The Internet Society (1999). All Rights Reserved.
Abstract Abstract
This memo is an extension to the SNMP MIB. It specifies an IAB This memo is an extension to the SNMP MIB. It specifies an IAB
standards track protocol for the Internet community, and requests standards track protocol for the Internet community, and requests
discussion and suggestions for improvements. The origin of this memo is discussion and suggestions for improvements. The origin of this memo
from RFC 1269 "Definitions of Managed Objects for the Board Gateway is from RFC 1269 "Definitions of Managed Objects for the Border
Protocol (Version 3)" written by the first two authors of this memo, Gateway Protocol (Version 3)", which was updated to support BGP-4 in
which was updated to support BGP-4 in RFC 1657. This memo fixes errors RFC 1657. This memo fixes errors introduced when the MIB was
introduced when the MIB was converted to use the SNMPv2 SMI, as well as converted to use the SNMPv2 SMI, as well as updates references to the
updates references to the Draft Standard SNMPv2 SMI documents. current SNMP framework documents.
Distribution of this memo is unlimited. Please forward comments to Distribution of this memo is unlimited. Please forward comments to
bgp@ans.net. idr@merit.net.
1. Introduction 1. Introduction
This memo defines an experimental portion of the Management Information This memo defines a portion of the Management Information Base (MIB)
Base (MIB) for use with network management protocols in the Internet for use with network management protocols in the Internet community.
community. In particular, it describes managed objects used for In particular, it describes managed objects used for managing the
managing the Border Gateway Protocol Version 4 or lower [1, 2]. Border Gateway Protocol Version 4 or lower [1, 2].
2. The SNMP Network Management Framework 2. The SNMP Network Management Framework
The SNMP Network Management Framework consists of several components. The SNMP Management Framework presently consists of five major
For the purpose of this specification, the applicable components of the components:
Framework are the SMI and related documents [3, 4, 5], which define the
mechanisms used for describing and naming objects for the purpose of
management.
The Framework permits new objects to be defined for the purpose of o An overall architecture, described in RFC 2271 [3].
experimentation and evaluation.
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 RFC 1155 [4], RFC 1212 [5] and RFC 1215 [6]. The
second version, called SMIv2, is described in RFC 1902 [7],
RFC 1903 [8] and RFC 1904 [9].
o Message protocols for transferring management information.
The first version of the SNMP message protocol is called
SNMPv1 and described in RFC 1157 [10]. A second version of
the SNMP message protocol, which is not an Internet standards
track protocol, is called SNMPv2c and described in RFC 1901
[11] and RFC 1906 [12]. The third version of the message
protocol is called SNMPv3 and described in RFC 1906 [12], RFC
2272 [13] and RFC 2274 [14].
o Protocol operations for accessing management information. The
first set of protocol operations and associated PDU formats
is described in RFC 1157 [10]. A second set of protocol
operations and associated PDU formats is described in RFC
1905 [15].
o A set of fundamental applications described in RFC 2273 [16]
and the view-based access control mechanism described in RFC
2275 [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
MIB.
3. Object Definitions 3. Object Definitions
Managed objects are accessed via a virtual information store, termed the Managed objects are accessed via a virtual information store, termed
Management Information Base or MIB. Objects in the MIB are defined the Management Information Base or MIB. Objects in the MIB are
using the subset of Abstract Syntax Notation One (ASN.1) defined in the defined using the subset of Abstract Syntax Notation One (ASN.1)
SMI. In particular, each object type is named by an OBJECT IDENTIFIER, defined in the SMI. In particular, each object type is named by an
an administratively assigned name. The object type together with an OBJECT IDENTIFIER, an administratively assigned name. The object
object instance serves to uniquely identify a specific instantiation of type together with an object instance serves to uniquely identify a
the object. For human convenience, we often use a textual string, specific instantiation of the object. For human convenience, we
termed the descriptor, to refer to the object type. often use a textual string, termed the descriptor, to refer to the
object type.
4. Overview 4. Overview
These objects are used to control and manage a BGP-4 implementation. These objects are used to control and manage a BGP-4 implementation.
Apart from a few system-wide scalar objects, this MIB is broken into Apart from a few system-wide scalar objects, this MIB is broken into
three tables: the BGP Peer Table, the BGP Received Path Attribute Table, three tables: the BGP Peer Table, the BGP Received Path Attribute
and the BGP-4 Received Path Attribute Table. The BGP Peer Table Table, and the BGP-4 Received Path Attribute Table. The BGP Peer
contains information about state and current activity of connections Table contains information about state and current activity of
connections with the BGP peers. The Received Path Attribute Table
with the BGP peers. The Received Path Attribute Table contains path contains path attributes received from all peers running BGP version
attributes received from all peers running BGP version 3 or less. The 3 or less. The BGP-4 Received Path Attribute Table contains path
BGP-4 Received Path Attribute Table contains path attributes received attributes received from all BGP-4 peers. The actual attributes used
from all BGP-4 peers. The actual attributes used in determining a route in determining a route are a subset of the received attribute tables
are a subset of the received attribute tables after local routing policy after local routing policy has been applied.
has been applied.
5. Definitions 5. Definitions
BGP4-MIB DEFINITIONS ::= BEGIN BGP4-MIB DEFINITIONS ::= BEGIN
IMPORTS IMPORTS
MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE, MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE,
IpAddress, Integer32, Counter32, Gauge32, mib-2 IpAddress, Integer32, Counter32, Gauge32, mib-2
FROM SNMPv2-SMI FROM SNMPv2-SMI
MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP
FROM SNMPv2-CONF; FROM SNMPv2-CONF;
bgp MODULE-IDENTITY bgp MODULE-IDENTITY
LAST-UPDATED "9601080000Z" LAST-UPDATED "9902100000Z"
ORGANIZATION "IETF BGP Working Group" ORGANIZATION "IETF IDR Working Group"
CONTACT-INFO CONTACT-INFO "E-mail: idr@merit.net
" John Chu (Editor)
Postal: IBM Corp.
P.O.Box 704
Yorktown Heights, NY 10598
US
Tel: +1 914 784 7839 Susan Hares (Editor)
Fax: +1 914 784 6205 Merit Network
E-mail: jychu@watson.ibm.com 4251 Plymouth Road
Suite C
Ann Arbor, MI 48105-2785
Tel: +1 734 936 2095
Fax: +1 734 647 3185
E-mail: skh@merit.edu
Jeff Johnson (Editor) Jeff Johnson (Editor)
Postal: cisco Systems RedBack Networks, Inc.
170 W. Tasman Drive 1389 Moffett Park Drive
San Jose, CA 95134 Sunnyvale, CA 94089-1134
Tel: +1 408 548 3516
Tel: +1 408 526 7789 Fax: +1 408 548 3599
Fax: +1 408 526 4860 E-mail: jeff@redback.com"
E-mail: jjohnson@cisco.com"
DESCRIPTION DESCRIPTION
"The MIB module for BGP-4." "The MIB module for BGP-4."
REVISION "9601080000Z" REVISION "9601080000Z"
DESCRIPTION DESCRIPTION
"1) Fixed the definitions of the traps to "1) Fixed the definitions of the traps to
make them equivalent to their initial make them equivalent to their initial
definition in RFC 1269. definition in RFC 1269.
2) Added compliance and conformance info." 2) Added compliance and conformance info."
REVISION "9902100000Z"
DESCRIPTION
"Corrected duplicate OBJECT IDENTIFIER
assignment in the conformance information."
::= { mib-2 15 } ::= { mib-2 15 }
bgpVersion OBJECT-TYPE bgpVersion OBJECT-TYPE
SYNTAX OCTET STRING (SIZE (1..255)) SYNTAX OCTET STRING (SIZE (1..255))
MAX-ACCESS read-only MAX-ACCESS read-only
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"Vector of supported BGP protocol version "Vector of supported BGP protocol version
numbers. Each peer negotiates the version numbers. Each peer negotiates the version
from this vector. Versions are identified from this vector. Versions are identified
skipping to change at page 13, line 7 skipping to change at page 14, line 45
::= { bgp 5 } ::= { bgp 5 }
bgpPathAttrEntry OBJECT-TYPE bgpPathAttrEntry OBJECT-TYPE
SYNTAX BgpPathAttrEntry SYNTAX BgpPathAttrEntry
MAX-ACCESS not-accessible MAX-ACCESS not-accessible
STATUS obsolete STATUS obsolete
DESCRIPTION DESCRIPTION
"Information about a path to a network." "Information about a path to a network."
INDEX { bgpPathAttrDestNetwork, INDEX { bgpPathAttrDestNetwork,
bgpPathAttrPeer } bgpPathAttrPeer }
::= { bgpRcvdPathAttrTable 1 } ::= { bgpPathAttrTable 1 }
BgpPathAttrEntry ::= SEQUENCE { BgpPathAttrEntry ::= SEQUENCE {
bgpPathAttrPeer bgpPathAttrPeer
IpAddress, IpAddress,
bgpPathAttrDestNetwork bgpPathAttrDestNetwork
IpAddress, IpAddress,
bgpPathAttrOrigin bgpPathAttrOrigin
INTEGER, INTEGER,
bgpPathAttrASPath bgpPathAttrASPath
OCTET STRING, OCTET STRING,
skipping to change at page 22, line 25 skipping to change at page 24, line 20
BGP path entries." BGP path entries."
::= { bgpMIBGroups 4 } ::= { bgpMIBGroups 4 }
bgp4MIBNotificationGroup NOTIFICATION-GROUP bgp4MIBNotificationGroup NOTIFICATION-GROUP
NOTIFICATIONS { bgpEstablished, NOTIFICATIONS { bgpEstablished,
bgpBackwardTransition } bgpBackwardTransition }
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"A collection of notifications for signaling "A collection of notifications for signaling
changes in BGP peer relationships." changes in BGP peer relationships."
::= { bgpMIBGroups 4 } ::= { bgpMIBGroups 5 }
END END
6. Acknowledgements 6. 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.
7. Acknowledgements
We would like to acknowledge the assistance of all the members of the We would like to acknowledge the assistance of all the members of the
Inter-Domain Routing Working Group, and particularly the following Inter-Domain Routing Working Group, and particularly the following
individuals: individuals:
Yakov Rekhter, cisco Systems Yakov Rekhter, cisco Systems
Rob Coltun, Fore Rob Coltun, Fore
Guy Almes, ANS Guy Almes, ANS
Jeff Honig, Cornell Theory Center Jeff Honig, Cornell Theory Center
Marshall T. Rose, Dover Beach Consulting, Inc. Marshall T. Rose, Dover Beach Consulting, Inc.
Dennis Ferguson, Ipsilon Dennis Ferguson, Juniper Networks
Mike Mathis, PSC Mike Mathis, PSC
John Krawczyk, Bay Networks John Krawczyk, Bay Networks
Curtis Villamizar, ANS Curtis Villamizar, ANS
Dave LeRoy, Pencom Systems Dave LeRoy, Pencom Systems
Paul Traina, cisco Systems Paul Traina, Juniper Networks
Andrew Partan, UUNET Andrew Partan, UUNET
Robert Snyder, cisco Systems Robert Snyder, cisco Systems
Dimitry Haskin, Bay Networks Dimitry Haskin, Bay Networks
Peder Chr Norgaard, Telebit Communications A/S Peder Chr Norgaard, Telebit Communications A/S
Joel Halpern, NewBridge Joel Halpern, NewBridge
Nick Thille, cisco Systems Nick Thille, RedBack Networks
Bert Wijnen, IBM
7. References The origin of this document is from RFC 1269 "Definitions of Managed
Objects for the Border Gateway Protocol (Version 3)" written by Steve
Willis and John Burruss, which was updated by John Chu to support
BGP-4 in RFC 1657. The editors wishes to acknowledge the fine work
of these original authors.
[1] Rekhter, Y., Li, T., "A Border Gateway Protocol 4 (BGP-4)", 8. References
RFC 1771, March 1995.
[2] Rekhter, Y., Gross, P., "Application of the Border [1] Rekhter, Y., Li, T., "A Border Gateway Protocol 4 (BGP-4)", RFC
Gateway Protocol in the Internet", RFC 1772, March 1995. 1771, March 1995.
[3] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and [2] Rekhter, Y., Gross, P., "Application of the Border Gateway
S. Waldbusser, "Structure of Management Information for Version 2 Protocol in the Internet", RFC 1772, March 1995.
of the Simple Network Management Protocol (SNMPv2)", RFC 1902,
January 1996.
[4] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and [3] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for
S. Waldbusser, "Textual Conventions for Version 2 of the Simple Describing SNMP Management Frameworks", RFC 2271, Cabletron
Network Management Protocol (SNMPv2)", RFC 1903, January 1996. Systems, Inc., BMC Software, Inc., IBM T. J. Watson Research,
January 1998
[5] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and [4] Rose, M., and K. McCloghrie, "Structure and Identification of
S. Waldbusser, "Conformance Statements for Version 2 of the Management Information for TCP/IP-based Internets", RFC 1155,
Simple Network Management Protocol (SNMPv2)", RFC 1904, Performance Systems International, Hughes LAN Systems, May 1990
January 1996.
8. Security Considerations [5] Rose, M., and K. McCloghrie, "Concise MIB Definitions", RFC
1212, Performance Systems International, Hughes LAN Systems,
March 1991
Security issues are not discussed in this memo. [6] M. Rose, "A Convention for Defining Traps for use with the
SNMP", RFC 1215, Performance Systems International, March 1991
Authors' Address [7] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser,
"Structure of Management Information for Version 2 of the Simple
Network Management Protocol (SNMPv2)", RFC 1902, SNMP
Research,Inc., Cisco Systems, Inc., Dover Beach Consulting,
Inc., International Network Services, January 1996.
Steve Willis [8] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Textual
Bay Networks, Inc. Conventions for Version 2 of the Simple Network Management
3 Federal St Protocol (SNMPv2)", RFC 1903, SNMP Research, Inc., Cisco
Billerica, MA 01821 Systems, Inc., Dover Beach Consulting, Inc., International
Network Services, January 1996.
Phone: +1 508 436 3927 [9] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser,
Email: swillis@BayNetworks.com "Conformance Statements for Version 2 of the Simple Network
Management Protocol (SNMPv2)", RFC 1904, SNMP Research, Inc.,
Cisco Systems, Inc., Dover Beach Consulting, Inc., International
Network Services, January 1996.
[10] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple
Network Management Protocol", RFC 1157, SNMP Research,
Performance Systems International, Performance Systems
International, MIT Laboratory for Computer Science, May 1990.
[11] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser,
"Introduction to Community-based SNMPv2", RFC 1901, SNMP
Research, Inc., Cisco Systems, Inc., Dover Beach Consulting,
Inc., International Network Services, January 1996.
[12] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser,
"Transport Mappings for Version 2 of the Simple Network
Management Protocol (SNMPv2)", RFC 1906, SNMP Research, Inc.,
Cisco Systems, Inc., Dover Beach Consulting, Inc., International
Network Services, January 1996.
[13] Case, J., Harrington D., Presuhn R., and B. Wijnen, "Message
Processing and Dispatching for the Simple Network Management
Protocol (SNMP)", RFC 2272, SNMP Research, Inc., Cabletron
Systems, Inc., BMC Software, Inc., IBM T. J. Watson Research,
January 1998.
[14] Blumenthal, U., and B. Wijnen, "User-based Security Model (USM)
for version 3 of the Simple Network Management Protocol
(SNMPv3)", RFC 2274, IBM T. J. Watson Research, January 1998.
[15] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Protocol
Operations for Version 2 of the Simple Network Management
Protocol (SNMPv2)", RFC 1905, SNMP Research, Inc., Cisco
Systems, Inc., Dover Beach Consulting, Inc., International
Network Services, January 1996.
[16] Levi, D., Meyer, P., and B. Stewart, "SNMPv3 Applications", RFC
2273, SNMP Research, Inc., Secure Computing Corporation, Cisco
Systems, January 1998
[17] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based Access
Control Model (VACM) for the Simple Network Management Protocol
(SNMP)", RFC 2275, IBM T. J. Watson Research, BMC Software,
Inc., Cisco Systems, Inc., January 1998
9. Security Considerations
There are a number of management objects defined in this MIB that
have a MAX-ACCESS clause of read-write:
bgpPeerAdminStatus
bgpPeerConnectRetryInterval
bgpPeerHoldTimeConfigured
bgpPeerKeepAliveConfigured
bgpPeerMinASOriginationInterval
bgpPeerMinRouteAdvertisementInterval
These objects should be considered sensitive or vulnerable in most
network environments. The support for SET operations in a non-secure
environment without proper protection can have a negative effect on
network operations. Incorrect configuration of these parameters may
cause BGP peer connections to terminate early or to send more routes
under a flapping condition.
There are a number of managed objects in this MIB that may be
considered to contain sensitive information in the operation of a
network. For example, a BGP peer's local and remote addresses may be
sensitive for ISPs who want to keep interface addresses on routers
confidential to prevent router addresses used for a denial of service
attack or spoofing.
Therefore, it may be important in some environments to control read
access to these objects and possibly to even encrypt the values of
these object when sending them over the network via SNMP. Not all
versions of SNMP provide features for such a secure environment.
SNMPv1 by itself is not a secure environment. Even if the network
itself is secure (for example by using IPSec), 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 2274 [14] and the View-based
Access Control Model RFC 2275 [17] 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.
10. Authors' Address
Susan Hares
Merit Network, Inc.
4251 Plymouth Road
Suite C
Ann Arbor, MI 48105-2785
Phone: +1 734 936 2095
Fax: +1 734 647 3185
Email: skh@merit.edu
Jeff Johnson
RedBack Networks, Inc.
1389 Moffett Park Drive
Sunnyvale, CA 94089
Phone: +1 408 548 3516
Email: jeff@redback.com
Steve Willis
Argon Networks
25 Porter Road
Littleton, MA 01450
Phone: +1 508 486 0665
Fax: +1 508 486 9379
Email: swills@argon.com
John Burruss John Burruss
Windata Inc. Windata Inc.
543 Great Road 543 Great Road
Littleton MA 01460 Littleton MA 01460
Phone: +1 508 952 0170 Phone: +1 508 952 0170
Email: jburruss@windata.com Email: jburruss@windata.com
John Chu John Chu
IBM Corporation IBM Corporation
P.O.Box 704 P.O.Box 704
Yorktown Heights, NY 10598 Yorktown Heights, NY 10598
Phone: +1 914 784 7839 Phone: +1 914 784 7839
Email: jychu@watson.ibm.com Email: jychu@watson.ibm.com
Jeff Johnson 11. Full Copyright Statement
cisco Systems
170 W. Tasman Drive
San Jose, CA 95134
Phone: +1 408 526 7789 Copyright (C) The Internet Society (1999). All Rights Reserved.
Email: jjohnson@cisco.com
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.
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/