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/