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/