draft-ietf-p2psip-share-02.txt   draft-ietf-p2psip-share-03.txt 
P2PSIP Working Group A. Knauf P2PSIP Working Group A. Knauf
Internet-Draft T. Schmidt, Ed. Internet-Draft T. Schmidt, Ed.
Intended status: Standards Track HAW Hamburg Intended status: Standards Track HAW Hamburg
Expires: February 28, 2014 G. Hege Expires: September 4, 2014 G. Hege
daviko GmbH daviko GmbH
M. Waehlisch M. Waehlisch
link-lab & FU Berlin link-lab & FU Berlin
August 27, 2013 March 3, 2014
A Usage for Shared Resources in RELOAD (ShaRe) A Usage for Shared Resources in RELOAD (ShaRe)
draft-ietf-p2psip-share-02 draft-ietf-p2psip-share-03
Abstract Abstract
This document defines a RELOAD Usage for managing shared write access This document defines a RELOAD Usage for managing shared write access
to RELOAD Resources. Shared Resources in RELOAD (ShaRe) form a basic to RELOAD Resources. Shared Resources in RELOAD (ShaRe) form a basic
primitive for enabling various coordination and notification schemes primitive for enabling various coordination and notification schemes
among distributed peers. Access in ShaRe is controlled by a among distributed peers. Access in ShaRe is controlled by a
hierarchical trust delegation scheme maintained within an access hierarchical trust delegation scheme maintained within an access
list. A new USER-CHAIN-ACL access policy allows authorized peers to list. A new USER-CHAIN-ACL access policy allows authorized peers to
write a Shared Resource without owning its corresponding certificate. write a Shared Resource without owning its corresponding certificate.
skipping to change at page 1, line 43 skipping to change at page 1, line 43
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 February 28, 2014. This Internet-Draft will expire on September 4, 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
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Shared Resources in RELOAD . . . . . . . . . . . . . . . . . 4 3. Shared Resources in RELOAD . . . . . . . . . . . . . . . . . 4
3.1. Mechanisms for Isolating Stored Data . . . . . . . . . . 5 3.1. Mechanisms for Isolating Stored Data . . . . . . . . . . 5
4. Access Control List Definition . . . . . . . . . . . . . . . 6 4. Access Control List Definition . . . . . . . . . . . . . . . 6
4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 6 4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 6
4.2. Data Structure . . . . . . . . . . . . . . . . . . . . . 8 4.2. Data Structure . . . . . . . . . . . . . . . . . . . . . 8
5. Extension for Variable Resource Names . . . . . . . . . . . . 9 5. Extension for Variable Resource Names . . . . . . . . . . . . 9
5.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 9 5.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 9
5.2. Data Structure . . . . . . . . . . . . . . . . . . . . . 9 5.2. Data Structure . . . . . . . . . . . . . . . . . . . . . 10
5.3. Overlay Configuration Document Extension . . . . . . . . 10 5.3. Overlay Configuration Document Extension . . . . . . . . 10
6. Access Control to Shared Resources . . . . . . . . . . . . . 11 6. Access Control to Shared Resources . . . . . . . . . . . . . 11
6.1. Granting Write Access . . . . . . . . . . . . . . . . . . 11 6.1. Granting Write Access . . . . . . . . . . . . . . . . . . 12
6.2. Revoking Write Access . . . . . . . . . . . . . . . . . . 12 6.2. Revoking Write Access . . . . . . . . . . . . . . . . . . 12
6.3. Validating Write Access through an ACL . . . . . . . . . 12 6.3. Validating Write Access through an ACL . . . . . . . . . 13
6.4. Operations of Storing Peers . . . . . . . . . . . . . . . 13 6.4. Operations of Storing Peers . . . . . . . . . . . . . . . 14
6.5. Operations of Accessing Peers . . . . . . . . . . . . . . 14 6.5. Operations of Accessing Peers . . . . . . . . . . . . . . 14
6.6. USER-CHAIN-ACL Access Policy . . . . . . . . . . . . . . 14 6.6. USER-CHAIN-ACL Access Policy . . . . . . . . . . . . . . 14
7. ACCESS-CONTROL-LIST Kind Definition . . . . . . . . . . . . . 15 7. ACCESS-CONTROL-LIST Kind Definition . . . . . . . . . . . . . 15
8. Security Considerations . . . . . . . . . . . . . . . . . . . 15 8. Security Considerations . . . . . . . . . . . . . . . . . . . 15
8.1. Resource Exhaustion . . . . . . . . . . . . . . . . . . . 15 8.1. Resource Exhaustion . . . . . . . . . . . . . . . . . . . 15
8.2. Malicious or Misbehaving Storing Peer . . . . . . . . . . 16 8.2. Malicious or Misbehaving Storing Peer . . . . . . . . . . 16
8.3. Privacy Issues . . . . . . . . . . . . . . . . . . . . . 16 8.3. Privacy Issues . . . . . . . . . . . . . . . . . . . . . 16
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
9.1. Access Control Policy . . . . . . . . . . . . . . . . . . 16 9.1. Access Control Policy . . . . . . . . . . . . . . . . . . 16
9.2. Data Kind-ID . . . . . . . . . . . . . . . . . . . . . . 16 9.2. Data Kind-ID . . . . . . . . . . . . . . . . . . . . . . 16
skipping to change at page 4, line 12 skipping to change at page 4, line 6
Definition of the pattern is arbitrary, but must contain the username Definition of the pattern is arbitrary, but must contain the username
of the Resource creator. of the Resource creator.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
This document uses the terminology and definitions from the RELOAD This document uses the terminology and definitions from the RELOAD
base [I-D.ietf-p2psip-base]and the peer-to-peer SIP concepts draft base [RFC6940]and the peer-to-peer SIP concepts draft
[I-D.ietf-p2psip-concepts]. Additionally, the following terms are [I-D.ietf-p2psip-concepts]. Additionally, the following terms are
used: used:
Shared Resource: The term Shared Resource in this document defines a Shared Resource: The term Shared Resource in this document defines a
RELOAD Resource with its associated Kinds, that can be written or RELOAD Resource with its associated Kinds, that can be written or
overwritten by multiple RELOAD users following the specifications overwritten by multiple RELOAD users following the specifications
in this document. in this document.
Access Control List: The term Access Control List in this document Access Control List: The term Access Control List in this document
defines a logical list of RELOAD users allowed to write a specific defines a logical list of RELOAD users allowed to write a specific
skipping to change at page 8, line 21 skipping to change at page 8, line 38
Implementations of ShaRe should be aware that the trust delegation in Implementations of ShaRe should be aware that the trust delegation in
an Access Control List need not be loop free. Self-contained an Access Control List need not be loop free. Self-contained
circular trust delegation from A to B and B to A are syntactically circular trust delegation from A to B and B to A are syntactically
possible, even though not very meaningful. possible, even though not very meaningful.
4.2. Data Structure 4.2. Data Structure
The Kind data structure for the Access Control List is defined as The Kind data structure for the Access Control List is defined as
follows: follows:
struct { struct {
/* res_name_ext is optional, see documentation */ /* res_name_ext is optional, see documentation */
ResourceNameExtension res_name_ext; ResourceNameExtension res_name_ext;
opaque to_user<0..2^16-1>; opaque to_user<0..2^16-1>;
KindId kind; KindId kind;
Boolean allow_delegation; Boolean allow_delegation;
} AccessControlListItem; } AccessControlListItem;
The AccessControlListItem structure is composed of: The AccessControlListItem structure is composed of:
res_name_ext: This optional field contains the Resource Name of a res_name_ext: This optional field contains the Resource Name of a
ResourceNameExtension (see Section 5.2) to be used by a Shared ResourceNameExtension (see Section 5.2) to be used by a Shared
Resource with variable resource name. This name serves the Resource with variable resource name. This name serves the
storing peer for validating, whether a variable resources name storing peer for validating, whether a variable resources name
matches one of the predefined naming pattern from the matches one of the predefined naming pattern from the
configuration document for this Kind. The presence of this field configuration document for this Kind. The presence of this field
is bound to a variable resource name element in the corresponding is bound to a variable resource name element in the corresponding
skipping to change at page 9, line 32 skipping to change at page 9, line 44
name (or Node-ID) while storing data under a specific Resource-ID. name (or Node-ID) while storing data under a specific Resource-ID.
The specifications in this document scheme adhere to this paradigm, The specifications in this document scheme adhere to this paradigm,
but enable a RELOAD peer to store values of Resource Names that are but enable a RELOAD peer to store values of Resource Names that are
derived from the username in its certificate. This is done by using derived from the username in its certificate. This is done by using
a Resource Name with a variable substring that still matches the user a Resource Name with a variable substring that still matches the user
name in the certificate using a pattern defined in the overlay name in the certificate using a pattern defined in the overlay
configuration document. Thus despite being variable, an allowable configuration document. Thus despite being variable, an allowable
Resource Name remains tied to the Owner's certificate. A sample Resource Name remains tied to the Owner's certificate. A sample
pattern might be formed as follows. pattern might be formed as follows.
Example Pattern: Example Pattern:
.*-conf-\$USER@\$DOMAIN .*-conf-\$USER@\$DOMAIN
When defining the pattern, care must be taken to avoid conflicts When defining the pattern, care must be taken to avoid conflicts
arising from two usernames of witch one is a substring of the other. arising from two usernames of witch one is a substring of the other.
In such cases, the holder of the shorter name could threaten to block In such cases, the holder of the shorter name could threaten to block
the resources of the longer-named peer by choosing the variable part the resources of the longer-named peer by choosing the variable part
of a Resource Name to contain the entire longer username. This of a Resource Name to contain the entire longer username. This
problem can easily be mitigated by delimiting the variable part of problem can easily be mitigated by delimiting the variable part of
the pattern from the username part by some fixed string, that by the pattern from the username part by some fixed string, that by
convention is not part of a username (e.g., the "-conf-" in the above convention is not part of a username (e.g., the "-conf-" in the above
Example). Example).
5.2. Data Structure 5.2. Data Structure
This section defines the optional ResourceNameExtension structure for This section defines the optional ResourceNameExtension structure for
every Kind that uses the USER-CHAIN-ACL access control policy. every Kind that uses the USER-CHAIN-ACL access control policy.
enum { pattern (1), enum { pattern (1),
(255)} ResourceNameType; (255)} ResourceNameType;
struct {
ResourceNameType type;
uint16 length;
select(type) {
case pattern:
opaque resource_name<0..2^16-1>;
/* Types can be extended */ struct {
} ResourceNameType type;
} ResourceNameExtension uint16 length;
select(type) {
case pattern:
opaque resource_name<0..2^16-1>;
/* Types can be extended */
}
} ResourceNameExtension
The content of the ResourceNameExtension consist of The content of the ResourceNameExtension consist of
length: This field contains the length of the remaining data length: This field contains the length of the remaining data
structure. It is only used to allow for further extensions to structure. It is only used to allow for further extensions to
this data structure. this data structure.
The content of the rest of the data structure depends of the The content of the rest of the data structure depends of the
ResourceNameType. Currently, the only defined type is "pattern". ResourceNameType. Currently, the only defined type is "pattern".
skipping to change at page 11, line 35 skipping to change at page 11, line 46
kind-parameter &= element share:variable-resource-names { kind-parameter &= element share:variable-resource-names {
attribute enable { xsd:boolean } attribute enable { xsd:boolean }
<!-- PATTERN ELEMENT --> <!-- PATTERN ELEMENT -->
element pattern { xsd:string }* element pattern { xsd:string }*
}? }?
Figure 2
6. Access Control to Shared Resources 6. Access Control to Shared Resources
6.1. Granting Write Access 6.1. Granting Write Access
Write access to a Kind that is intended to be shared with other Write access to a Kind that is intended to be shared with other
RELOAD users can solely be issued by the Resource Owner. A Resource RELOAD users can solely be issued by the Resource Owner. A Resource
Owner can share RELOAD Kinds by using the following procedure. Owner can share RELOAD Kinds by using the following procedure.
o The Resource Owner stores an ACL root item at the Resource-ID of o The Resource Owner stores an ACL root item at the Resource-ID of
the Shared Resource. The root item contains the resource name the Shared Resource. The root item contains the resource name
extension field (see Section 5.2), the username of the Resource extension field (see Section 5.2), the username of the Resource
Owner and Kind-ID of the Shared Resource. The allow_delegation Owner and Kind-ID of the Shared Resource. The allow_delegation
skipping to change at page 12, line 38 skipping to change at page 12, line 50
ACL item signed by another Peer is unauthorized and causes an ACL item signed by another Peer is unauthorized and causes an
Error_Forbidden response from the Storing Peer. Such access Error_Forbidden response from the Storing Peer. Such access
conflicts could be caused by an array index collision. However, the conflicts could be caused by an array index collision. However, the
probability of a collision of two or more identical array indices probability of a collision of two or more identical array indices
will be negligibly low using the mechanism for isolating stored data will be negligibly low using the mechanism for isolating stored data
(see Section 3.1) (see Section 3.1)
6.2. Revoking Write Access 6.2. Revoking Write Access
Write permissions are revoked by storing a non-existent value Write permissions are revoked by storing a non-existent value
[I-D.ietf-p2psip-base] at the corresponding item of the Access [RFC6940] at the corresponding item of the Access Control List.
Control List. Revoking a permission automatically invalidates all Revoking a permission automatically invalidates all delegations
delegations performed by that user including all subsequent performed by that user including all subsequent delegations. This
delegations. This allows to invalidate entire subtrees of the allows to invalidate entire subtrees of the delegations tree with
delegations tree with only a single operation. Overwriting the root only a single operation. Overwriting the root item with a non-
item with a non-existent value of an Access List invalidates the existent value of an Access List invalidates the entire delegations
entire delegations tree. tree.
An existing ACL item MUST only be overwritten by the user who An existing ACL item MUST only be overwritten by the user who
initially stored the corresponding entry, or by the Resource Owner initially stored the corresponding entry, or by the Resource Owner
that is allowed to overwrite all ACL items for revoking write access. that is allowed to overwrite all ACL items for revoking write access.
6.3. Validating Write Access through an ACL 6.3. Validating Write Access through an ACL
Access Control Lists are used to transparently validate authorization Access Control Lists are used to transparently validate authorization
of peers for writing a data value at a Shared Resource. Thereby it of peers for writing a data value at a Shared Resource. Thereby it
is assumed that the validating peer is in possession of the complete is assumed that the validating peer is in possession of the complete
and most recent ACL for a specific Resource/Kind pair. The and most recent ACL for a specific Resource/Kind pair. The
corresponding procedure consists of recursively traversing the trust corresponding procedure consists of recursively traversing the trust
delegation tree and proceeds as follows. delegation tree and proceeds as follows.
1. Obtain the username of the certificate used for signing the data 1. Obtain the username of the certificate used for signing the data
stored at the Shared Resource. stored at the Shared Resource.
skipping to change at page 14, line 38 skipping to change at page 14, line 44
Peers can cache previously fetched Access Control Lists up to the Peers can cache previously fetched Access Control Lists up to the
maximum lifetime of an individual item. Since stored values could maximum lifetime of an individual item. Since stored values could
have been modified or invalidated prior to their expiration, an have been modified or invalidated prior to their expiration, an
accessing peer SHOULD use a Stat request to check for updates prior accessing peer SHOULD use a Stat request to check for updates prior
to using the data cache. to using the data cache.
6.6. USER-CHAIN-ACL Access Policy 6.6. USER-CHAIN-ACL Access Policy
This document specifies an additional access control policy to the This document specifies an additional access control policy to the
RELOAD base draft [I-D.ietf-p2psip-base]. The USER-CHAIN-ACL policy RELOAD base draft [RFC6940]. The USER-CHAIN-ACL policy allows
allows Authorized Peers to write a Shared Resource, even though they Authorized Peers to write a Shared Resource, even though they do not
do not own the corresponding certificate. Additionally, the USER- own the corresponding certificate. Additionally, the USER-CHAIN-ACL
CHAIN-ACL allows the storage of Kinds with a variable resource name allows the storage of Kinds with a variable resource name that are
that are following one of the specified naming pattern. Hence, on an following one of the specified naming pattern. Hence, on an inbound
inbound store request on a Kind that uses the USER-CHAIN-ACL access store request on a Kind that uses the USER-CHAIN-ACL access policy,
policy, the following rules MUST be applied: the following rules MUST be applied:
In the USER-CHAIN-ACL policy, a given value MUST be written or In the USER-CHAIN-ACL policy, a given value MUST be written or
overwritten, if either one of USER-MATCH or USER-NODE-MATCH overwritten, if either one of USER-MATCH or USER-NODE-MATCH
(mandatory if the data model is dictionary) access policies of the (mandatory if the data model is dictionary) access policies of the
base document [I-D.ietf-p2psip-base] applies. base document [RFC6940] applies.
Otherwise, the value MUST be written if the certificate of the signer Otherwise, the value MUST be written if the certificate of the signer
contains a username that matches to one of the variable resource name contains a username that matches to one of the variable resource name
pattern (c.f. Section 5) specified in the configuration document and, pattern (c.f. Section 5) specified in the configuration document and,
additionally, the hashed Resource Name matches the Resource-ID. The additionally, the hashed Resource Name matches the Resource-ID. The
Resource Name of the Kind to be stored MUST be taken from the Resource Name of the Kind to be stored MUST be taken from the
mandatory ResourceNameExtension field in the corresponding Kind data mandatory ResourceNameExtension field in the corresponding Kind data
structure. structure.
Otherwise, the value MUST be written if the ACL validation procedure Otherwise, the value MUST be written if the ACL validation procedure
skipping to change at page 16, line 30 skipping to change at page 16, line 34
All data stored in the Shared Resource is publicly readable, thus All data stored in the Shared Resource is publicly readable, thus
applications requiring privacy need to encrypt the data. The ACL applications requiring privacy need to encrypt the data. The ACL
needs to be stored unencrypted, thus the list members of a group needs to be stored unencrypted, thus the list members of a group
using a Shared Resource will always be publicly visible. using a Shared Resource will always be publicly visible.
9. IANA Considerations 9. IANA Considerations
9.1. Access Control Policy 9.1. Access Control Policy
IANA shall register the following entry in the "RELOAD Access Control IANA shall register the following entry in the "RELOAD Access Control
Policies" Registry (cf., [I-D.ietf-p2psip-base]) to represent the Policies" Registry (cf., [RFC6940]) to represent the USER-CHAIN-ACL
USER-CHAIN-ACL Access Control Policy, as described in Section 6.6. Access Control Policy, as described in Section 6.6. [NOTE TO IANA/
[NOTE TO IANA/RFC-EDITOR: Please replace RFC-AAAA with the RFC number RFC-EDITOR: Please replace RFC-AAAA with the RFC number for this
for this specification in the following list.] specification in the following list.]
+-------------------+----------+ +-------------------+----------+
| Kind | RFC | | Kind | RFC |
+-------------------+----------+ +-------------------+----------+
| USER-CHAIN-ACL | RFC-AAAA | | USER-CHAIN-ACL | RFC-AAAA |
+-------------------+----------+ +-------------------+----------+
9.2. Data Kind-ID 9.2. Data Kind-ID
IANA shall register the following code point in the "RELOAD Data IANA shall register the following code point in the "RELOAD Data
Kind-ID" Registry (cf., [I-D.ietf-p2psip-base]) to represent the Kind-ID" Registry (cf., [RFC6940]) to represent the ShaRe ACCESS-
ShaRe ACCESS-CONTROL-LIST kind, as described in Section 7. [NOTE TO CONTROL-LIST kind, as described in Section 7. [NOTE TO IANA/RFC-
IANA/RFC-EDITOR: Please replace RFC-AAAA with the RFC number for this EDITOR: Please replace RFC-AAAA with the RFC number for this
specification in the following list.] specification in the following list.]
+----------------------+------------+----------+
+----------------------+------------+----------+ | Kind | Kind-ID | RFC |
| Kind | Kind-ID | RFC | +----------------------+------------+----------+
+----------------------+------------+----------+ | ACCESS-CONTROL-LIST | 17 | RFC-AAAA |
| ACCESS-CONTROL-LIST | 17 | RFC-AAAA | +----------------------+------------+----------+
+----------------------+------------+----------+
9.3. XML Name Space Registration 9.3. XML Name Space Registration
This document registers the following URI for the config XML This document registers the following URI for the config XML
namespace in the IETF XML registry defined in [RFC3688] namespace in the IETF XML registry defined in [RFC3688]
URI: urn:ietf:params:xml:ns:p2p:config-base:share URI: urn:ietf:params:xml:ns:p2p:config-base:share
Registrant Contact: The IESG Registrant Contact: The IESG
skipping to change at page 17, line 33 skipping to change at page 17, line 36
particular, the authors would like to thank (in alphabetical order) particular, the authors would like to thank (in alphabetical order)
Lothar Grimm, Cullen Jennings, Peter Musgrave, Joerg Ott, Marc Petit- Lothar Grimm, Cullen Jennings, Peter Musgrave, Joerg Ott, Marc Petit-
Huguenin, Peter Pogrzeba, and Jan Seedorf. This work was partly Huguenin, Peter Pogrzeba, and Jan Seedorf. This work was partly
funded by the German Federal Ministry of Education and Research, funded by the German Federal Ministry of Education and Research,
projects HAMcast, Mindstone, and SAFEST. projects HAMcast, Mindstone, and SAFEST.
11. References 11. References
11.1. Normative References 11.1. Normative References
[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.
[IEEE-Posix] [IEEE-Posix]
, "IEEE Standard for Information Technology - Portable "IEEE Standard for Information Technology - Portable
Operating System Interface (POSIX) - Part 2: Shell and Operating System Interface (POSIX) - Part 2: Shell and
Utilities (Vol. 1)", IEEE Std 1003.2-1992, ISBN Utilities (Vol. 1)", IEEE Std 1003.2-1992, ISBN
1-55937-255-9, January 1993. 1-55937-255-9, January 1993.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
January 2004. January 2004.
[RFC6940] Jennings, C., Lowekamp, B., Rescorla, E., Baset, S., and
H. Schulzrinne, "REsource LOcation And Discovery (RELOAD)
Base Protocol", RFC 6940, January 2014.
11.2. Informative References 11.2. Informative References
[I-D.ietf-p2psip-concepts] [I-D.ietf-p2psip-concepts]
Bryan, D., Matthews, P., Shim, E., Willis, D., and S. Bryan, D., Matthews, P., Shim, E., Willis, D., and S.
Dawkins, "Concepts and Terminology for Peer to Peer SIP", Dawkins, "Concepts and Terminology for Peer to Peer SIP",
draft-ietf-p2psip-concepts-05 (work in progress), July draft-ietf-p2psip-concepts-05 (work in progress), July
2013. 2013.
[I-D.ietf-p2psip-disco] [I-D.ietf-p2psip-disco]
Knauf, A., Schmidt, T., Hege, G., and M. Waehlisch, "A Knauf, A., Schmidt, T., Hege, G., and M. Waehlisch, "A
RELOAD Usage for Distributed Conference Control (DisCo)", RELOAD Usage for Distributed Conference Control (DisCo)",
draft-ietf-p2psip-disco-02 (work in progress), July 2013. draft-ietf-p2psip-disco-02 (work in progress), July 2013.
[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-11 (work in progress), July 2013. draft-ietf-p2psip-sip-12 (work in progress), January 2014.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003. Applications", STD 64, RFC 3550, July 2003.
Appendix A. Change Log Appendix A. Change Log
The following changes have been made from version draft-ietf-p2psio- The following changes have been made from version draft-ietf-p2psio-
share-02:
1. Updated References
The following changes have been made from version draft-ietf-p2psio-
share-01: share-01:
1. Added IANA registration for namespace 1. Added IANA registration for namespace
2. Editorial improvements 2. Editorial improvements
3. Updated References 3. Updated References
The following changes have been made from version draft-ietf-p2psio- The following changes have been made from version draft-ietf-p2psio-
share-00: share-00:
 End of changes. 29 change blocks. 
75 lines changed or deleted 76 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/