draft-ietf-p2psip-concepts-05.txt		draft-ietf-p2psip-concepts-06.txt
	P2PSIP Working Group D. Bryan		P2PSIP Working Group D. Bryan
	Internet-Draft St. Edwards University		Internet-Draft Cogent Force, LLC
	Intended status: Informational P. Matthews		Intended status: Informational P. Matthews
	Expires: January 13, 2014 Alcatel-Lucent		Expires: December 15, 2014 Alcatel-Lucent
	E. Shim		E. Shim
	Samsung Electronics Co., Ltd.		Samsung Electronics Co., Ltd.
	D. Willis		D. Willis
	Softarmor Systems		Softarmor Systems
	S. Dawkins		S. Dawkins
	Huawei (USA)		Huawei (USA)
	July 12, 2013		June 13, 2014
	Concepts and Terminology for Peer to Peer SIP		Concepts and Terminology for Peer to Peer SIP
	draft-ietf-p2psip-concepts-05		draft-ietf-p2psip-concepts-06
	Abstract		Abstract
	This document defines concepts and terminology for the use of the		This document defines concepts and terminology for the use of the
	Session Initiation Protocol in a peer-to-peer environment where the		Session Initiation Protocol in a peer-to-peer environment where the
	traditional proxy-registrar and message routing functions are		traditional proxy-registrar and message routing functions are
	replaced by a distributed mechanism. These mechanisms may be		replaced by a distributed mechanism. These mechanisms may be
	implemented using a distributed hash table or other distributed data		implemented using a distributed hash table or other distributed data
	mechanism with similar external properties. This document includes a		mechanism with similar external properties. This document includes a
	high-level view of the functional relationships between the network		high-level view of the functional relationships between the network
	elements defined herein, a conceptual model of operations, and an		elements defined herein, a conceptual model of operations, and an
	outline of the related problems addressed by the P2PSIP working group		outline of the related problems addressed by the P2PSIP working group
	and the RELOAD protocol ([I-D.ietf-p2psip-base],		and the RELOAD protocol and SIP usage ([RFC6940],
	[I-D.ietf-p2psip-sip]) defined by the working group.		[I-D.ietf-p2psip-sip]) defined by the working group.
	Status of this Memo		Status of this Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	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		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."
	This Internet-Draft will expire on January 13, 2014.		This Internet-Draft will expire on December 15, 2014.
	Copyright Notice		Copyright Notice
	Copyright (c) 2013 IETF Trust and the persons identified as the		Copyright (c) 2014 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	skipping to change at page 4, line 7		skipping to change at page 4, line 7
	6.3. NAT Traversal . . . . . . . . . . . . . . . . . . . . . . 15		6.3. NAT Traversal . . . . . . . . . . . . . . . . . . . . . . 15
	6.4. Locating and Joining an Overlay . . . . . . . . . . . . . 15		6.4. Locating and Joining an Overlay . . . . . . . . . . . . . 15
	6.5. Clients and Connecting Unmodified SIP Devices . . . . . . 16		6.5. Clients and Connecting Unmodified SIP Devices . . . . . . 16
	6.6. Architecture . . . . . . . . . . . . . . . . . . . . . . . 17		6.6. Architecture . . . . . . . . . . . . . . . . . . . . . . . 17
	7. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 17		7. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 17
	8. Informative References . . . . . . . . . . . . . . . . . . . . 18		8. Informative References . . . . . . . . . . . . . . . . . . . . 18
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19
	1. Editor's Notes and Changes To This Version		1. Editor's Notes and Changes To This Version
	This version of the draft represents a minor revision of version -04		This version of the draft represents a very minor revision of version
	and is intended to restart conversation on this draft in the group,		-05 and is intended to restart conversation on this draft in the
	to identify open issues, address them, and complete work on the		group, to identify open issues, address them, and complete work on
	document.		the document in light of RELOAD being issued as an RFC.
	Version -03 represented a substantial revision from the previous		Version -03 represented a substantial revision from the previous
	version. Until -02, this work was tracking open questions and being		version. Until -02, this work was tracking open questions and being
	used to help reach consensus on a draft. With the selection of		used to help reach consensus on a draft. With the selection of
	RELOAD as the protocol for this WG, the focus of the group turned to		RELOAD as the protocol for this WG, the focus of the group turned to
	completing the RELOAD drafts, and the WG directed the editors to		completing the RELOAD draft, and the WG directed the editors to
	update the document to reflect the decisions made in RELOAD upon		update the document to reflect the decisions made in RELOAD upon
	completion.		completion.
	Please see Section 7 for the list of major open issues.		Please see Section 7 for the list of major open issues.
	2. Background		2. Background
	One of the fundamental problems in multimedia communication between		One of the fundamental problems in multimedia communication between
	Internet nodes is discovering the host at which a given user can be		Internet nodes is discovering the host at which a given user can be
	reached. In the Session Initiation Protocol (SIP) [RFC3261] this		reached. In the Session Initiation Protocol (SIP) [RFC3261] this
	skipping to change at page 4, line 51		skipping to change at page 4, line 51
	This document gives a high-level description of an alternative		This document gives a high-level description of an alternative
	solution to this problem. In this alternative solution, the		solution to this problem. In this alternative solution, the
	relatively fixed hierarchy of Client/Server SIP is replaced by a		relatively fixed hierarchy of Client/Server SIP is replaced by a
	peer-to-peer overlay network. In this peer-to-peer overlay network,		peer-to-peer overlay network. In this peer-to-peer overlay network,
	the various AoR to Contact URI mappings are not centralized at proxy/		the various AoR to Contact URI mappings are not centralized at proxy/
	registrar nodes but are instead distributed amongst the peers in the		registrar nodes but are instead distributed amongst the peers in the
	overlay.		overlay.
	The details of this alternative solution are specified by the RELOAD		The details of this alternative solution are specified by the RELOAD
	protocol. The RELOAD base draft [I-D.ietf-p2psip-base] defines a		protocol. The RELOAD base draft [RFC6940] defines a mechanism to
	mechanism to distribute using a Distributed Hash Table (DHT) and		distribute using a Distributed Hash Table (DHT) and specifies the
	specifies the wire protocol, security, and authentication mechanisms		wire protocol, security, and authentication mechanisms needed to
	needed to convey this information. This DHT protocol was designed		convey this information. This DHT protocol was designed specifically
	specifically with the purpose of enabling a distributed SIP registrar		with the purpose of enabling a distributed SIP registrar in mind.
	in mind. While designing the protocol other applications were		While designing the protocol other applications were considered, and
	considered, and when possible design decisions were made that allow		when possible design decisions were made that allow RELOAD to be used
	RELOAD to be used in other instances where a DHT is desirable, but		in other instances where a DHT is desirable, but only when making
	only when making such decisions did not add undue complexity to the		such decisions did not add undue complexity to the RELOAD protocol.
	RELOAD protocol. The RELOAD sip draft [I-D.ietf-p2psip-sip]		The RELOAD sip draft [I-D.ietf-p2psip-sip] specifies how RELOAD is
	specifies how RELOAD is used with the SIP protocol to enable a		used with the SIP protocol to enable a distributed, server-less SIP
	distributed, server-less SIP solution.		solution.
	3. High-Level Description		3. High-Level Description
	A P2PSIP Overlay is a collection of nodes organized in a peer-to-peer		A P2PSIP Overlay is a collection of nodes organized in a peer-to-peer
	fashion for the purpose of enabling real-time communication using the		fashion for the purpose of enabling real-time communication using the
	Session Initiation Protocol (SIP). Collectively, the nodes in the		Session Initiation Protocol (SIP). Collectively, the nodes in the
	overlay provide a distributed mechanism for mapping names to overlay		overlay provide a distributed mechanism for mapping names to overlay
	locations. This provides for the mapping of Addresses of Record		locations. This provides for the mapping of Addresses of Record
	(AoRs) to Contact URIs, thereby providing the "location server"		(AoRs) to Contact URIs, thereby providing the "location server"
	function of [RFC3261]. An Overlay also provides a transport function		function of [RFC3261]. An Overlay also provides a transport function
	skipping to change at page 6, line 23		skipping to change at page 6, line 23
	3.2. Clients		3.2. Clients
	An overlay may or may not also include one or more nodes called		An overlay may or may not also include one or more nodes called
	clients. Clients are supported in the RELOAD protocol as peers that		clients. Clients are supported in the RELOAD protocol as peers that
	have not joined the overlay, and therefore do not route messages or		have not joined the overlay, and therefore do not route messages or
	store information. Clients access the services of the RELOAD		store information. Clients access the services of the RELOAD
	protocol by connecting to a peer which performs operations on the		protocol by connecting to a peer which performs operations on the
	behalf of the client. Note that in RELOAD there is no distinct		behalf of the client. Note that in RELOAD there is no distinct
	client protocol. Instead, a client connects using the same protocol,		client protocol. Instead, a client connects using the same protocol,
	but never joins the overlay as a peer. For more information, see		but never joins the overlay as a peer. For more information, see
	[I-D.ietf-p2psip-base].		[RFC6940].
	Note that in the context of P2PSIP, there is an additional entity		Note that in the context of P2PSIP, there is an additional entity
	that is sometimes referred to as a client. A special peer may be a		that is sometimes referred to as a client. A special peer may be a
	member of the in the P2PSIP overlay and may present the functionality		member of the in the P2PSIP overlay and may present the functionality
	of one or all of a SIP registrar, proxy or redirect server to		of one or all of a SIP registrar, proxy or redirect server to
	conventional SIP devices (SIP clients). In this way, existing, non-		conventional SIP devices (SIP clients). In this way, existing, non-
	modified SIP clients may connect to the network. These unmodified		modified SIP clients may connect to the network. These unmodified
	SIP devices do not speak the RELOAD protocol, and this is a distinct		SIP devices do not speak the RELOAD protocol, and this is a distinct
	concept from the notion of client discussed in the previous		concept from the notion of client discussed in the previous
	paragraph.		paragraph.
	skipping to change at page 10, line 26		skipping to change at page 10, line 26
	P2P technology. <http://en.wikipedia.org/wiki/Peer-to-peer>. A		P2P technology. <http://en.wikipedia.org/wiki/Peer-to-peer>. A
	P2P Network may also be called a "P2P Overlay" or "P2P Overlay		P2P Network may also be called a "P2P Overlay" or "P2P Overlay
	Network" or "P2P Network Overlay", since its organization is not		Network" or "P2P Network Overlay", since its organization is not
	at the physical layer, but is instead "on top of" an existing		at the physical layer, but is instead "on top of" an existing
	Internet Protocol network.		Internet Protocol network.
	P2PSIP: A suite of communications protocols related to the Session		P2PSIP: A suite of communications protocols related to the Session
	Initiation Protocol (SIP) [RFC3261] that enable SIP to use peer-		Initiation Protocol (SIP) [RFC3261] that enable SIP to use peer-
	to-peer techniques for resolving the targets of SIP requests,		to-peer techniques for resolving the targets of SIP requests,
	providing SIP message transport, and providing other SIP-related		providing SIP message transport, and providing other SIP-related
	functions. At present, these protocols include		functions. At present, these protocols include [RFC6940],
	[I-D.ietf-p2psip-base], [I-D.ietf-p2psip-sip],		[I-D.ietf-p2psip-sip], [I-D.ietf-p2psip-diagnostics],
	[I-D.ietf-p2psip-diagnostics], [I-D.ietf-p2psip-service-discovery]		[I-D.ietf-p2psip-service-discovery] and
	and [I-D.ietf-p2psip-self-tuning].		[I-D.ietf-p2psip-self-tuning].
	User: A human that interacts with the overlay through SIP UAs		User: A human that interacts with the overlay through SIP UAs
	located on peers and clients (and perhaps other ways).		located on peers and clients (and perhaps other ways).
	The following terms are defined here only within the scope of		The following terms are defined here only within the scope of
	P2PSIP. These terms may have conflicting definitions in other		P2PSIP. These terms may have conflicting definitions in other
	bodies of literature. Some earlier versions of this document		bodies of literature. Some earlier versions of this document
	prefixed each term with "P2PSIP" to clarify the term's scope.		prefixed each term with "P2PSIP" to clarify the term's scope.
	This prefixing has been eliminated from the text; however the		This prefixing has been eliminated from the text; however the
	scoping still applies.		scoping still applies.
	skipping to change at page 12, line 11		skipping to change at page 12, line 11
	hold data about Services, and the working group may define other		hold data about Services, and the working group may define other
	types. The types, usages, and formats of the records are a		types. The types, usages, and formats of the records are a
	question for future study.		question for future study.
	Responsible Peer The Peer that is responsible for storing the		Responsible Peer The Peer that is responsible for storing the
	Resource Record for a Resource. In the literature, the term "Root		Resource Record for a Resource. In the literature, the term "Root
	Peer" is also used for this concept.		Peer" is also used for this concept.
	Peer Protocol: The protocol spoken between P2PSIP Overlay peers to		Peer Protocol: The protocol spoken between P2PSIP Overlay peers to
	share information and organize the P2PSIP Overlay Network. In		share information and organize the P2PSIP Overlay Network. In
	P2PSIP, this is implemented using the RELOAD		P2PSIP, this is implemented using the RELOAD [RFC6940] protocol.
	[I-D.ietf-p2psip-base] protocol.
	Client Protocol: The protocol spoken between Clients and Peers. In		Client Protocol: The protocol spoken between Clients and Peers. In
	P2PSIP and RELOAD, this is the same protocol syntactically as the		P2PSIP and RELOAD, this is the same protocol syntactically as the
	Peer Protocol. The only difference is that Clients are not		Peer Protocol. The only difference is that Clients are not
	routing messages or routing information, and have not (or can not)		routing messages or routing information, and have not (or can not)
	insert themselves into the overlay.		insert themselves into the overlay.
	Peer Protocol Connection / P2PSIP Client Protocol Connection: The		Peer Protocol Connection / P2PSIP Client Protocol Connection: The
	TLS, DTLS, TCP, UDP or other transport layer protocol connection		TLS, DTLS, TCP, UDP or other transport layer protocol connection
	over which the RELOAD Peer Protocol messages are transported.		over which the RELOAD Peer Protocol messages are transported.
	skipping to change at page 13, line 44		skipping to change at page 13, line 44
	user and the location of the UAs that the user is using (the users		user and the location of the UAs that the user is using (the users
	SIP AoR). Full details of how this is implemented using RELOAD are		SIP AoR). Full details of how this is implemented using RELOAD are
	provided in [I-D.ietf-p2psip-sip]		provided in [I-D.ietf-p2psip-sip]
	Before information about a user can be stored in the overlay, a user		Before information about a user can be stored in the overlay, a user
	needs a User Name. The User Name is a human-friendly identifier that		needs a User Name. The User Name is a human-friendly identifier that
	uniquely identifies the user within the overlay. In RELOAD, users		uniquely identifies the user within the overlay. In RELOAD, users
	are issued certificates, which in the case of centrally signed		are issued certificates, which in the case of centrally signed
	certificates, identify the User Name as well as a certain number of		certificates, identify the User Name as well as a certain number of
	Resource-IDs where the user may store their information. For more		Resource-IDs where the user may store their information. For more
	information, see [I-D.ietf-p2psip-base].		information, see [RFC6940].
	The P2PSIP suite of protocols also standardizes information about how		The P2PSIP suite of protocols also standardizes information about how
	to locate services. Services represent actions that a peer (and		to locate services. Services represent actions that a peer (and
	perhaps a client) can do to benefit other peers and clients in the		perhaps a client) can do to benefit other peers and clients in the
	overlay. Information that might be stored in the resource record		overlay. Information that might be stored in the resource record
	associated with a service might include the peers (and perhaps		associated with a service might include the peers (and perhaps
	clients) offering the service. Service discovery for P2PSIP is		clients) offering the service. Service discovery for P2PSIP is
	defined in [I-D.ietf-p2psip-service-discovery].		defined in [I-D.ietf-p2psip-service-discovery].
	Each service has a human-friendly Service Name that uniquely		Each service has a human-friendly Service Name that uniquely
	skipping to change at page 17, line 32		skipping to change at page 17, line 32
	| | RELOAD Layer |		| | RELOAD Layer |
	|______|___________________|		|______|___________________|
	| Transport Layer |		| Transport Layer |
	|__________________________|		|__________________________|
	7. Open Issues		7. Open Issues
	MAJOR OPEN ISSUE: The initial wording in the high-level description		MAJOR OPEN ISSUE: The initial wording in the high-level description
	about proving AoR to contact mapping reflects a very long and		about proving AoR to contact mapping reflects a very long and
	contentious debate about the role of the protocol, and reflected a		contentious debate about the role of the protocol, and reflected a
	pretense that this was an overlay only for P2PSIP. That is		pretense that this was an overlay only for P2PSIP. That is not
	explicitly not true in base anymore (see last paragraph of		really true in base anymore (see last paragraph of introduction) and
	introduction) and the language has been very much genericized in		the language has been very much genericized in base. Should we make
	base. Should we make this text more abstract and then use		this text more abstract and then use AoR->contact mapping as an
	AoR->contact mapping as an example of the (original) use? On a		example of the (original) use? On a related note, see the last
	related note, see the last paragraph of the Background section -- do		paragraph of the Background section -- do we want to reword this?
	we want to reword this?
	OPEN ISSUE: Should we include a section that documents previous		OPEN ISSUE: Should we include a section that documents previous
	decisions made, to preserve the historical debate and prevent past		decisions made, to preserve the historical debate and prevent past
	issues from being raised in the future, or simply rely on the mailing		issues from being raised in the future, or simply rely on the mailing
	list to address these concerns?		list to address these concerns?
	OPEN ISSUE: Should we include the use cases from		OPEN ISSUE: Should we include the use cases from
	draft-bryan-p2psip-app-scenarios-00 (now long expired)? There was		draft-bryan-p2psip-app-scenarios-00 (now long expired)? There was
	some interest in doing so in previous versions, but no conclusion was		some interest in doing so in previous versions, but no conclusion was
	reached.		reached.
	skipping to change at page 18, line 16		skipping to change at page 18, line 16
	[Chord] Singh, K., Stoica, I., Morris, R., Karger, D., Kaashock,		[Chord] Singh, K., Stoica, I., Morris, R., Karger, D., Kaashock,
	M., Dabek, F., and H. Balakrishman, "Chord: A scalable		M., Dabek, F., and H. Balakrishman, "Chord: A scalable
	peer-to-peer lookup protocol for internet applications",		peer-to-peer lookup protocol for internet applications",
	IEEE/ACM Transactions on Neworking Volume 11 Issue 1, pp.		IEEE/ACM Transactions on Neworking Volume 11 Issue 1, pp.
	17-32, Feb. 2003.		17-32, Feb. 2003.
	Copy available at		Copy available at
	http://pdos.csail.mit.edu/chord/papers/paper-ton.pdf		http://pdos.csail.mit.edu/chord/papers/paper-ton.pdf
	[I-D.ietf-p2psip-base]
	Jennings, C., Lowekamp, B., Rescorla, E., Baset, S., and
	H. Schulzrinne, "REsource LOcation And Discovery (RELOAD)
	Base Protocol", draft-ietf-p2psip-base-26 (work in
	progress), February 2013.
	[I-D.ietf-p2psip-diagnostics]		[I-D.ietf-p2psip-diagnostics]
	Song, H., Jiang, X., Even, R., and D. Bryan, "P2P Overlay		Song, H., Jiang, X., Even, R., Bryan, D., and Y. Sun, "P2P
	Diagnostics", draft-ietf-p2psip-diagnostics-11 (work in		Overlay Diagnostics", draft-ietf-p2psip-diagnostics-14
	progress), March 2013.		(work in progress), February 2014.
	[I-D.ietf-p2psip-self-tuning]		[I-D.ietf-p2psip-self-tuning]
	Maenpaa, J. and G. Camarillo, "A Self-tuning Distributed		Maenpaa, J. and G. Camarillo, "Self-tuning Distributed
	Hash Table (DHT) for REsource LOcation And Discovery		Hash Table (DHT) for REsource LOcation And Discovery
	(RELOAD)", draft-ietf-p2psip-self-tuning-08 (work in		(RELOAD)", draft-ietf-p2psip-self-tuning-12 (work in
	progress), February 2013.		progress), June 2014.
	[I-D.ietf-p2psip-service-discovery]		[I-D.ietf-p2psip-service-discovery]
	Maenpaa, J. and G. Camarillo, "Service Discovery Usage for		Maenpaa, J. and G. Camarillo, "Service Discovery Usage for
	REsource LOcation And Discovery (RELOAD)",		REsource LOcation And Discovery (RELOAD)",
	draft-ietf-p2psip-service-discovery-08 (work in progress),		draft-ietf-p2psip-service-discovery-12 (work in progress),
	February 2013.		June 2014.
	[I-D.ietf-p2psip-sip]		[I-D.ietf-p2psip-sip]
	Jennings, C., Lowekamp, B., Rescorla, E., Baset, S.,		Jennings, C., Lowekamp, B., Rescorla, E., Baset, S.,
	Schulzrinne, H., and T. Schmidt, "A SIP Usage for RELOAD",		Schulzrinne, H., and T. Schmidt, "A SIP Usage for RELOAD",
	draft-ietf-p2psip-sip-09 (work in progress),		draft-ietf-p2psip-sip-12 (work in progress), January 2014.
	February 2013.
	[RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound,		[RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound,
	"Dynamic Updates in the Domain Name System (DNS UPDATE)",		"Dynamic Updates in the Domain Name System (DNS UPDATE)",
	RFC 2136, April 1997.		RFC 2136, April 1997.
	[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,		[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
	A., Peterson, J., Sparks, R., Handley, M., and E.		A., Peterson, J., Sparks, R., Handley, M., and E.
	Schooler, "SIP: Session Initiation Protocol", RFC 3261,		Schooler, "SIP: Session Initiation Protocol", RFC 3261,
	June 2002.		June 2002.
	skipping to change at page 19, line 26		skipping to change at page 19, line 19
	[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment		[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment
	(ICE): A Protocol for Network Address Translator (NAT)		(ICE): A Protocol for Network Address Translator (NAT)
	Traversal for Offer/Answer Protocols", RFC 5245,		Traversal for Offer/Answer Protocols", RFC 5245,
	April 2010.		April 2010.
	[RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using		[RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using
	Relays around NAT (TURN): Relay Extensions to Session		Relays around NAT (TURN): Relay Extensions to Session
	Traversal Utilities for NAT (STUN)", RFC 5766, April 2010.		Traversal Utilities for NAT (STUN)", RFC 5766, April 2010.
			[RFC6940] Jennings, C., Lowekamp, B., Rescorla, E., Baset, S., and
			H. Schulzrinne, "REsource LOcation And Discovery (RELOAD)
			Base Protocol", RFC 6940, January 2014.
	Authors' Addresses		Authors' Addresses
	David A. Bryan		David A. Bryan
	St. Edwards University		Cogent Force, LLC
	Austin, Texas		Cedar Park, TX, Texas
	USA		USA
	Email: bryan@ethernot.org		Email: dbryan@ethernot.org
	Philip Matthews		Philip Matthews
	Alcatel-Lucent		Alcatel-Lucent
	600 March Road		600 March Road
	Ottawa, Ontario K2K 2E6		Ottawa, Ontario K2K 2E6
	Canada		Canada
	Phone: +1 613 784 3139		Phone: +1 613 784 3139
	Email: philip_matthews@magma.ca		Email: philip_matthews@magma.ca
	Eunsoo Shim		Eunsoo Shim
	Samsung Electronics Co., Ltd.		Samsung Electronics Co., Ltd.
	San 14, Nongseo-dong, Giheung-gu,		San 14, Nongseo-dong, Giheung-gu,
	Yongin-si, Gyeonggi-do, 446-712		Yongin-si, Gyeonggi-do, 446-712
	South Korea		South Korea
	Email: eunsooshim@gmail.com		Email: eunsooshim@gmail.com
	Dean Willis		Dean Willis
	Softarmor Systems		Softarmor Systems
	3100 Independence Pkwy #311-164		3100 Independence Pkwy #311-164
	Plano, Texas 75075		Plano, Texas 75075
	USA		USA
	Phone: +1 214 504 1987		Phone: +1 214 504 1987
	Email: dean.willis@softarmor.com		Email: dean.willis@softarmor.com
	Spencer Dawkins		Spencer Dawkins
End of changes. 26 change blocks.
	59 lines changed or deleted		54 lines changed or added
This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/