draft-ietf-idr-bgp-multisession-00.txt		draft-ietf-idr-bgp-multisession-01.txt
	Network Working Group John G. Scudder		Network Working Group Chandra Appanna
	Internet Draft Chandra Appanna		Internet Draft John G. Scudder
	Expiration Date: November 2004 Cisco Systems		Expiration Date: March 2006 Cisco Systems
	File name: draft-ietf-idr-bgp-multisession-00.txt May 2004		File name: draft-ietf-idr-bgp-multisession-01.txt October 2005
	Multisession BGP		Multisession BGP
	draft-ietf-idr-bgp-multisession-00.txt		draft-ietf-idr-bgp-multisession-01.txt
	Status of this Memo		Status of this Memo
	This document is an Internet-Draft and is subject to all provisions		By submitting this Internet-Draft, each author represents that
	of Section 10 of RFC2026.		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		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that other
	other groups may also distribute working documents as Internet-		groups may also distribute working documents as Internet-Drafts.
	Drafts.		Internet-Drafts are draft documents valid for a maximum of six
			months and may be updated, replaced, or obsoleted by other documents
	Internet-Drafts are draft documents valid for a maximum of six months		at any time. It is inappropriate to use Internet-Drafts as reference
	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."		material or to cite them other than as "work in progress."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/1id-abstracts.html		http://www.ietf.org/1id-abstracts.html
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html		http://www.ietf.org/shadow.html
	Abstract		Abstract
	skipping to change at page 2, line 27		skipping to change at page 2, line 27
	A common criticism of BGP is the fact that most malformed messages		A common criticism of BGP is the fact that most malformed messages
	cause the session to be terminated. While this behavior is necessary		cause the session to be terminated. While this behavior is necessary
	for protocol correctness, one may observe that the protocol machinery		for protocol correctness, one may observe that the protocol machinery
	of a given implementation may only be defective with respect to a		of a given implementation may only be defective with respect to a
	given AFI/SAFI. Thus, it would be desirable to allow the session		given AFI/SAFI. Thus, it would be desirable to allow the session
	related to that family to be terminated while leaving other AFI/SAFI		related to that family to be terminated while leaving other AFI/SAFI
	unaffected. As BGP is commonly deployed, this is not possible.		unaffected. As BGP is commonly deployed, this is not possible.
	In this specification, we propose a mechanism by which multiple		In this specification, we propose a mechanism by which multiple
	transport sessions may be established between a pair of peers. Each		transport sessions may be established between a pair of peers.
	transport session can be used for one or more AFI/SAFI. Each session
	is distinct from a BGP protocol point of view; an error or other		Each transport session can be used for one or more AFI/SAFI.
	event on one session has no implications for any other session. All
	protocol modifications proposed by this specification take place		While AFI/SAFI based sessions is one way to group data being exchanged
			between BGP peers it is also possible to concieve of sessions being
			based on other characteristics of the BGP data. In this draft we also
			propose a scheme for creating multiple BGP sessions between BGP peers
			based on criteria other than AFI/SAFI. However, the definition of specific
			criteria for grouping exchanged data into sessions is beyond the scope of
			this proposal. The goal of this proposal is to provide a mechanism for
			doing that if such criteria is available. For ease of understandability
			and readability, AFI/SAFI will be used as an illustrative grouping
			criteria through out the document.
			Each session is distinct from a BGP protocol point of view; an error
			or other event on one session has no implications for any other session.
			All protocol modifications proposed by this specification take place
	during the OPEN exchange phase of the session, there are no		during the OPEN exchange phase of the session, there are no
	modifications to the operation of the protocol once a session reaches		modifications to the operation of the protocol once a session reaches
	ESTABLISHED state.		ESTABLISHED state.
	Routers implementing this specification MUST also implement [MP-BGP].		Routers implementing this specification MUST also implement the base
			criteria that is used to define sessions. For example if AFI/SAFI based
			sessions are desired then peers implementing this specification MUST
			also implement [MP-BGP].
	2. Definitions		2. Definitions
	"MP-BGP capability" refers to the capability [BGP-CAP] with code 1,		"MP-BGP capability" refers to the capability [BGP-CAP] with code 1,
	specified in [MP-BGP] section 10.		specified in [MP-BGP] section 10.
	A BGP speaker is said to "support" some feature or functionality (for		A BGP speaker is said to "support" some feature or functionality (for
	example, to support this specification, or to support a particular		example, to support this specification, or to support a particular
	AFI/SAFI) when the BGP implementation supports the feature AND the		AFI/SAFI) when the BGP implementation supports the feature AND the
	feature has not been disabled by configuration.		feature has not been disabled by configuration.
	A pair of AFI/SAFI groups is said to "conflict" when considering the		The Session Identifier is a capability or group of capabilities that
	two groups as two sets, there is an intersection between the groups		will be used to differentiate individual BGP sessions between two IP
	but neither group is a subset of the other.		endpoints. When the AFI/SAFI is used to distinguish sessions, the MP-BGP
			capability is the session identifier.
			In this document the MP-BGP capability is used as a Session Identifier
			for illustrative and explanatory purpose, i.e as the capability whose
			values differentiates the multiple session between two IP endpoints.
			MP-BGP and AFI/SAFI can be replaced by any other capability and the
			values of that capability to setup multiple sessions, without any
			modifications to the procedures described.
			A pair of session indentifiers are said to conflict when considering the
			two groups as two sets, there is an intersection between the groups either
			in the capabilities or the values in the capabilities, but neither session
			group is a subset of the other. For example, a pair of AFI/SAFI is said
			to "conflict" when considering the two groups as two sets, there is an
			intersection between the groups but neither group is a subset of the other.
	3. Use of BGP Capability Advertisement		3. Use of BGP Capability Advertisement
	This specification defines the Multisession capability [BGP-CAP]:		This specification defines the Multisession capability [BGP-CAP]:
	Capability code (1 octet): TBD		Capability code (1 octet): TBD
	Capability length (1 octet): 1		Capability length (1 octet): variable
	Capability value (1 octet): Flags as below		Capability value (1 octet): Flags followed by the list of capabilities
			that define a session.
	0 1 2 3 4 5 6 7		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 2
	+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+
	|G| Reserved |		|G| Reserved |
	+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| One or more list of Capability codes (1 octet each) |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	The most significant bit is defined as the Grouping Support (G) bit.		The most significant bit is defined as the Grouping Support (G) bit.
	It can be used to indicate support for the ability to group multiple		It can be used to indicate support for the ability to group multiple
	AFI/SAFI into one session. When set (value 1) this bit indicates		capabilty values into one session. When set (value 1) this bit indicates
	that the BGP speaker supports grouping.		that the BGP speaker supports grouping.
	The remaining bits are reserved, and should be set to zero by the		The remaining bits are reserved, and should be set to zero by the
	sender and ignored by the receiver.		sender and ignored by the receiver.
			Following the reserved bits is a list of one or more Capability codes
			defined in BGP. The capabilities listed here represent the session
			identifier for sessions between the BGP speakers.
			For example peers wishing to establish sessions based on AFI/SAFI would
			exchange the Multiprotocol Extensions capability code (1) only in the
			list. In this case the Multisession capability would have a length of
			2 octets.
	4. New NOTIFICATION Subcodes		4. New NOTIFICATION Subcodes
	[BGP, BGP-DRAFT] Section 4.5 provides a number of subcodes to the		[BGP, BGP-DRAFT] Section 4.5 provides a number of subcodes to the
	NOTIFICATION message, and Section 6.2 elaborates on the use of those		NOTIFICATION message, and Section 6.2 elaborates on the use of those
	subcodes.		subcodes.
	This specification introduces two new subcodes:		This specification introduces two new subcodes:
	OPEN Message Error subcodes:		OPEN Message Error subcodes:
	7 - No Supported AFI/SAFI.		7 - No Supported Capability Value.
	8 - Grouping Conflict		8 - Grouping Conflict
	9 - Grouping Required		9 - Grouping Required
	The No Supported AFI/SAFI code MAY be used when an OPEN message		The No Supported Capability Value code MAY be used when an OPEN message
			contains one or more capabilities, none of which list an
			capability supported by the local BGP speaker. It is observed that
			this subcode may be useful for BGP speakers in general, even if
			they do not (otherwise) implement this specification.
			The Grouping Conflict code MAY be used when an OPEN message contains
			several capabilities whose values conflict with one or more
			capability groups configured on the local BGP speaker. The Data field
			SHOULD indicate one of the conflicting locally-configured capability
			groups, encoded as theh appropriate capabilities.
			The Grouping Required code MAY be used when a BGP speaker which is
			configured to require grouping attempts to establish a connection
			with a BGP speaker which does not support grouping. (While it is
			true that it might be possible to communicate much the same
			information using the Unsupported Capability NOTIFICATION message,
			this more explicit method is felt to be more transparent.)
			If MP-BGP capability is used as the session identifier, the notification
			codes could be used as follows:
			The No Supported Capability Value code MAY be used when an OPEN message
	contains one or more MP-BGP capabilities, none of which list an		contains one or more MP-BGP capabilities, none of which list an
	AFI/SAFI supported by the local BGP speaker. It is observed that		AFI/SAFI supported by the local BGP speaker. It is observed that
	this subcode may be useful for MP-BGP speakers in general, even if		this subcode may be useful for MP-BGP speakers in general, even if
	they do not (otherwise) implement this specification.		they do not (otherwise) implement this specification.
	The Grouping Conflict code MAY be used when an OPEN message contains		The Grouping Conflict code MAY be used when an OPEN message contains
	several MP-BGP capabilities whose AFI/SAFI conflict with one or more		several MP-BGP capabilities whose AFI/SAFI conflict with one or more
	AFI/SAFI groups configured on the local BGP speaker. The Data field		AFI/SAFI groups configured on the local BGP speaker. The Data field
	SHOULD indicate one of the conflicting locally-configured AFI/SAFI		SHOULD indicate one of the conflicting locally-configured AFI/SAFI
	groups, encoded as MP-BGP capabilities.		groups, encoded as MP-BGP capabilities.
	skipping to change at page 4, line 19		skipping to change at page 6, line 20
	configured to require grouping attempts to establish a connection		configured to require grouping attempts to establish a connection
	with a BGP speaker which does not support grouping. (While it is		with a BGP speaker which does not support grouping. (While it is
	true that it might be possible to communicate much the same		true that it might be possible to communicate much the same
	information using the Unsupported Capability NOTIFICATION message,		information using the Unsupported Capability NOTIFICATION message,
	this more explicit method is felt to be more transparent.)		this more explicit method is felt to be more transparent.)
	The use of these subcodes is further elaborated below.		The use of these subcodes is further elaborated below.
	5. Overview of Operation		5. Overview of Operation
	Until a BGP speaker has initiated or accepted one connection from a		The operation section is divided into two main subsections.
	given peer, it is unknown whether the peer supports this
	specification or not. Two strategies can be considered for making
	this initial determination -- either the BGP speaker can initially
	assume that the peer does not support this specification, and switch
	modes if it is discovered that it does, or vice-versa. Either
	approach is acceptable.
	The "Using Multisession" sections below discuss the BGP speaker's		The "Using Multisession" sections below discuss the BGP speaker's
	behavior when the peer does support this specification or is assumed		behavior when the peer does support this specification or is assumed
	to. The "Backward Compatibility" section discusses the BGP speaker's		to. The "Backward Compatibility" section discusses the BGP speaker's
	behavior when the peer does not support this specification, or is		behavior when the peer does not support this specification, or is
	assumed not to. Both sections discuss how to switch to the other		assumed not to. Both sections also discuss how to switch to the other
	mode.		mode.
	A BGP speaker which supports this specification SHOULD always		A BGP speaker which supports this specification SHOULD always
	advertise the Multisession capability, regardless of its peer's known		advertise the Multisession capability, regardless of its peer's known
	or presumed capability set.		or presumed capability set.
	5.1. Using Multisession:		In all cases until a BGP speaker has initiated or accepted one connection
			from a given peer, it is unknown whether the peer supports this
			specification or not. Two strategies can be considered for making
			this initial determination -- either the BGP speaker can initially
			assume that the peer does not support this specification, and switch
			modes if it is discovered that it does, or vice-versa. Either
			approach is acceptable.
	The following subsections discuss a BGP speaker's behavior towards a		Again for illustration, section 5.0 describes the operation from the
	peer which is known or assumed to support this specification.		point of view of the MP-BGP capability and the associated AFI/SAFI
			values as the session identifier. It can be replaced with any other
			capability or groups of capabilties without any changes to the behaviour
			described below.
	Note that if a BGP speaker only wishes to support a single AFI/SAFI		Note that if a BGP speaker only wishes to support a single AFI/SAFI
	in its communications with a given peer only one session is needed in		in its communications with a given peer only one session is needed in
	any case, and so the "multisession" feature is moot. In such a case		any case, and so the "multisession" feature is moot. In such a case
	the behavior required would be indistinguishable from that given in		the behavior required would be indistinguishable from that given in
	the "backward compatibility" section below. In the following		the "backward compatibility" section below. In the illustrative examples
	sections, it is generally assumed that a BGP speaker does wish to		in the following sections, it is generally assumed that a BGP speaker
	support multiple AFI/SAFI in its communications with a given peer.		does wish to support multiple AFI/SAFI in its communications with a
			given peer.
			5.1. Using Multisession:
			The following subsections discuss a BGP speaker's behavior towards a
			peer which is known or assumed to support this specification.
	5.1.1. Initiating Connections:		5.1.1. Initiating Connections:
	When a BGP speaker attempts BGP communication with its peer, it		When a BGP speaker attempts BGP communication with its peer, it
	initiates one connection per group of AFI/SAFI it wishes to support.		initiates one connection per group of AFI/SAFI it wishes to support.
	(This implies that a new local TCP port will be allocated for each		(This implies that a new local TCP port will be allocated for each
	new connection.) The OPEN sent on each connection MUST include the		new connection.) The OPEN sent on each connection MUST include the
	Multisession capability and one or more MP-BGP capabilities		Multisession capability and one or more MP-BGP capabilities
	indicating the AFI/SAFI to be supported on that session. If a non-		indicating the AFI/SAFI to be supported on that session. If a non-
	trivial group of AFI/SAFI (i.e., a group of two or more) is proposed,		trivial group of AFI/SAFI (i.e., a group of two or more) is proposed,
	skipping to change at page 5, line 50		skipping to change at page 8, line 23
	grouping, and a non-trivial group of AFI/SAFI has been proposed, then		grouping, and a non-trivial group of AFI/SAFI has been proposed, then
	it will respond as given in the previous paragraph but with the		it will respond as given in the previous paragraph but with the
	additional proviso that the G bit will be clear. In this case, the		additional proviso that the G bit will be clear. In this case, the
	BGP speaker MAY accept the connection as given in the previous		BGP speaker MAY accept the connection as given in the previous
	paragraph, or it MAY reply with a NOTIFICATION message with ERROR		paragraph, or it MAY reply with a NOTIFICATION message with ERROR
	Code OPEN Message Error and Error Subcode Grouping Required, and the		Code OPEN Message Error and Error Subcode Grouping Required, and the
	connection will be closed.		connection will be closed.
	If the peer does not wish to support the AFI/SAFI in question, it		If the peer does not wish to support the AFI/SAFI in question, it
	will reply with a NOTIFICATION message with Error Code OPEN Message		will reply with a NOTIFICATION message with Error Code OPEN Message
	Error, and Error Subcode No Supported AFI/SAFI, and the connection		Error, and Error Subcode No Supported Capability value, and the connection
	will be closed.		will be closed.
	A BGP speaker SHOULD NOT attempt to initiate connections for any		A BGP speaker SHOULD NOT attempt to initiate connections for any
	AFI/SAFI for which a connection already exists.		AFI/SAFI for which a connection already exists.
	If the peer does not support this specification, it will respond with		If the peer does not support this specification, it will respond with
	an OPEN which does not include the Multisession capability. In this		an OPEN which does not include the Multisession capability. In this
	case the connection SHOULD be terminated, and future connections to		case the connection SHOULD be terminated, and future connections to
	the peer should be attempted in the "backward compatibility" mode		the peer should be attempted in the "backward compatibility" mode
	discussed below.		discussed below.
	skipping to change at page 6, line 47		skipping to change at page 9, line 26
	default if grouping is supported.		default if grouping is supported.
	If the BGP speaker does not support AFI/SAFI grouping it MAY reply		If the BGP speaker does not support AFI/SAFI grouping it MAY reply
	with an OPEN listing one of the AFI/SAFI out of those proposed by the		with an OPEN listing one of the AFI/SAFI out of those proposed by the
	peer. It SHOULD also set the G bit in the Multisession capability to		peer. It SHOULD also set the G bit in the Multisession capability to
	zero.		zero.
	If the received OPEN message does not include any MP-BGP capability		If the received OPEN message does not include any MP-BGP capability
	indicating an AFI/SAFI the BGP speaker wishes to support, it should		indicating an AFI/SAFI the BGP speaker wishes to support, it should
	close the connection with a NOTIFICATION message with Error Code OPEN		close the connection with a NOTIFICATION message with Error Code OPEN
	Message Error and Error Subcode No Supported AFI/SAFI.		Message Error and Error Subcode No Supported Capability Value.
	If the received OPEN message does not include the Multisession		If the received OPEN message does not include the Multisession
	capability, then the peer does not support this specification. The		capability, then the peer does not support this specification. The
	connection MAY be continued in the "backward compatibility" mode		connection MAY be continued in the "backward compatibility" mode
	discussed below, or it MAY be terminated and future connections to		discussed below, or it MAY be terminated and future connections to
	the peer attempted in the "backward compatibility" mode.		the peer attempted in the "backward compatibility" mode.
	5.1.3. Collision Detection, Graceful Restart:		5.1.3. Collision Detection, Graceful Restart:
	[BGP, BGP-DRAFT] Section 6.8 (BGP connection collision detection)		[BGP, BGP-DRAFT] Section 6.8 (BGP connection collision detection)
	skipping to change at page 8, line 14		skipping to change at page 10, line 43
	6. State Machine		6. State Machine
	As mentioned under "accepting connections" above, this specification		As mentioned under "accepting connections" above, this specification
	modifies the BGP finite state machine, albeit in a backward-		modifies the BGP finite state machine, albeit in a backward-
	compatible fashion.		compatible fashion.
	In addition, note that one state machine is considered to exist for		In addition, note that one state machine is considered to exist for
	each of the connections which may exist to a given peer. This		each of the connections which may exist to a given peer. This
	implies that, for example, any session flap dampening that may exist		implies that, for example, any session flap dampening that may exist
	is performed per AFI/SAFI.		is performed per session indetifier.
	The specific state machine modifications to [BGP-DRAFT] Section 8.2.2		The specific state machine modifications to [BGP-DRAFT] Section 8.2.2
	are as follows.		are as follows.
	6.1. Modifications to Connect State and Active State		6.1. Modifications to Connect State and Active State
	In the actions in response to the events Open Delay timer expires		In the actions in response to the events Open Delay timer expires
	[Event 12] and TCP connection succeeds [Event 16 or Event 17], an		[Event 12] and TCP connection succeeds [Event 16 or Event 17], an
	OPEN is not sent and the state changes to WaitForOpen and not to		OPEN is not sent and the state changes to WaitForOpen and not to
	OpenSent.		OpenSent.
	skipping to change at page 8, line 46		skipping to change at page 11, line 32
	7. Discussion		7. Discussion
	Note that many BGP implementations already permit multiple sessions		Note that many BGP implementations already permit multiple sessions
	to be used between a given pair of routers, typically by configuring		to be used between a given pair of routers, typically by configuring
	multiple IP addresses on each router and configuring each session to		multiple IP addresses on each router and configuring each session to
	be bound to a different IP address. The principal contribution of		be bound to a different IP address. The principal contribution of
	this specification is to allow multiple sessions to be created		this specification is to allow multiple sessions to be created
	automatically, without additional configuration overhead or address		automatically, without additional configuration overhead or address
	consumption.		consumption.
	In addition to the simple mode of supporting one AFI/SAFI per		The specification supports the simple case of one capability being used
	connection, the procedures described here also permit arbitrary		as the session identifier and one connection per session identifier value.
	grouping of AFI/SAFI onto BGP connections. For such grouping to		It also permits connections be established based on the multiple
	function pleasingly, both peers participating in a connection need to		capabilties as a sessio identifier with multiple values per capability
	agree on what AFI/SAFI groupings will be used. If conflicting		grouped together per connection.
	groupings are configured, the connections may not establish, or more
	connections may be established than were expected (in the degenerate		In the context of MP-BGP based connections, which we believe may be the
	case, one connection per AFI/SAFI could be established despite		most prevalent use of this specification it permits supporting one
	configured groupings). We observe that the potential for misbehavior		AFI/SAFI per connection, and also permits arbitrary grouping of AFI/SAFI
	in the presence of conflicting configuration is not unusual in BGP,		onto BGP connections. For such grouping to function pleasingly, both
	and that support for, and configuration of grouping is purely		peers participating in a connection need to agree on what AFI/SAFI
	optional.		groupings will be used. If conflicting groupings are configured, the
			connections may not establish, or more connections may be established
			than were expected (in the degenerate case, one connection per AFI/SAFI
			could be established despite configured groupings). We observe that
			the potential for misbehavior in the presence of conflicting configuration
			is not unusual in BGP, and that support for, and configuration of grouping
			is purely optional.
	8. Acknowledgements		8. Acknowledgements
	To be supplied.		To be supplied.
	9. References		9. References
	[BGP4]		[BGP4]
	Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)," RFC		Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)," RFC
	1771, March 1995.		1771, March 1995.
	skipping to change at page 10, line 28		skipping to change at page 13, line 28
	100 S. Main Suite 200		100 S. Main Suite 200
	Ann Arbor, MI 48104		Ann Arbor, MI 48104
	Email: jgs@cisco.com		Email: jgs@cisco.com
	Chandra Appanna		Chandra Appanna
	Cisco Systems, Inc.		Cisco Systems, Inc.
	170 West Tasman Drive		170 West Tasman Drive
	San Jose, CA 95134		San Jose, CA 95134
	e-mail: achandra@cisco.com		e-mail: achandra@cisco.com
	13. Full Copyright Statement		13. Intellectual Property Statement
	Copyright (C) The Internet Society (2003). All Rights Reserved.		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.
	This document and translations of it may be copied and furnished to		Copies of IPR disclosures made to the IETF Secretariat and any
	others, and derivative works that comment on or otherwise explain it		assurances of licenses to be made available, or the result of an
	or assist in its implementation may be prepared, copied, published		attempt made to obtain a general license or permission for the use of
	and distributed, in whole or in part, without restriction of any		such proprietary rights by implementers or users of this
	kind, provided that the above copyright notice and this paragraph are		specification can be obtained from the IETF on-line IPR repository at
	included on all such copies and derivative works. However, this doc-		http://www.ietf.org/ipr.
	ument 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 develop-
	ing 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		The IETF invites any interested party to bring to its attention any
	revoked by the Internet Society or its successors or assigns.		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.
	This document and the information contained herein is provided on an		14. Disclaimer of Validity
	"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
	TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING		This document and the information contained herein
	BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION		are provided on an "AS IS" basis and THE CONTRIBUTOR, THE
	HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MER-		ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE
	CHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.		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.
			15. Copyright Statement
			Copyright (C) The Internet Society (2005). 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.
End of changes. 29 change blocks.
	75 lines changed or deleted		159 lines changed or added
This html diff was produced by rfcdiff 1.27, available from http://www.levkowetz.com/ietf/tools/rfcdiff/