draft-ietf-p2psip-share-06.txt   draft-ietf-p2psip-share-07.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: December 19, 2015 G. Hege Expires: May 12, 2016 G. Hege
daviko GmbH daviko GmbH
M. Waehlisch M. Waehlisch
link-lab & FU Berlin link-lab & FU Berlin
June 17, 2015 November 9, 2015
A Usage for Shared Resources in RELOAD (ShaRe) A Usage for Shared Resources in RELOAD (ShaRe)
draft-ietf-p2psip-share-06 draft-ietf-p2psip-share-07
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 December 19, 2015. This Internet-Draft will expire on May 12, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 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
skipping to change at page 2, line 44 skipping to change at page 2, line 44
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 . . . . . . . . . . . . . . . . . . . 16 8.1. Resource Exhaustion . . . . . . . . . . . . . . . . . . . 16
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 . . . . . . . . . . . . . . . . . . . . . . 17 9.2. Data Kind-ID . . . . . . . . . . . . . . . . . . . . . . 17
9.3. XML Name Space Registration . . . . . . . . . . . . . . . 17 9.3. XML Name Space Registration . . . . . . . . . . . . . . . 17
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 10.1. Normative References . . . . . . . . . . . . . . . . . . 17
11.1. Normative References . . . . . . . . . . . . . . . . . . 18 10.2. Informative References . . . . . . . . . . . . . . . . . 18
11.2. Informative References . . . . . . . . . . . . . . . . . 18 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 18
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
1. Introduction 1. Introduction
[RFC6940] defines the base protocol for REsource LOcation And [RFC6940] defines the base protocol for REsource LOcation And
Discovery (RELOAD) that allows for application-specific extensions by Discovery (RELOAD) that allows for application-specific extensions by
Usages. The present document defines such a RELOAD Usage for Usages. The present document defines such a RELOAD Usage for
managing shared write access to RELOAD Resources and a mechanism to managing shared write access to RELOAD Resources and a mechanism to
store Resources with a variable name. The Usage for Shared Resources store Resources with a variable name. The Usage for Shared Resources
in RELOAD (ShaRe) enables overlay users to share their exclusive in RELOAD (ShaRe) enables overlay users to share their exclusive
write access to specific Resource/Kind pairs with others. Shared write access to specific Resource/Kind pairs with others. Shared
Resources form a basic primitive for enabling various coordination Resources form a basic primitive for enabling various coordination
and notification schemes among distributed peers. Write permission and notification schemes among distributed peers. Write permission
is controlled by an Access Control List (ACL) Kind that maintains a is controlled by an Access Control List (ACL) Kind that maintains a
chain of Authorized Peers for a particular Shared Resource. A newly chain of Authorized Peers for a particular Shared Resource. A newly
defined USER-CHAIN-ACL access control policy enables shared write defined USER-CHAIN-ACL access control policy enables shared write
access in RELOAD. access in RELOAD.
The Usage for Shared Resources in RELOAD is designed for jointly The Usage for Shared Resources in RELOAD is designed for jointly
coordinated group applications among distributed peers (e.g., third coordinated group applications among distributed peers (e.g., third
party registration, see [I-D.ietf-p2psip-sip] , or distributed party registration, see [I-D.ietf-p2psip-sip], or distributed
conferencing, see[I-D.ietf-p2psip-disco]). Of particular interest conferencing, see[I-D.ietf-p2psip-disco]). Of particular interest
are rendezvous processes, where a single identifier is linked to are rendezvous processes, where a single identifier is linked to
multiple, dynamic instances of a distributed cooperative service. multiple, dynamic instances of a distributed cooperative service.
Shared write access is based on a trust delegation mechanism. It Shared write access is based on a trust delegation mechanism. It
transfers the authorization to write a specific Kind data by storing transfers the authorization to write a specific Kind data by storing
logical Access Control Lists. An ACL contains the ID of the Kind to logical Access Control Lists. An ACL contains the ID of the Kind to
be shared and contains trust delegations from one authorized to be shared and contains trust delegations from one authorized to
another (previously unauthorized) user. another (previously unauthorized) user.
Shared write access augments the RELOAD security model, which is Shared write access augments the RELOAD security model, which is
skipping to change at page 5, line 44 skipping to change at page 5, line 44
Otherwise the Kind data structure does not contain the Otherwise the Kind data structure does not contain the
ResourceNameExtension structure. ResourceNameExtension structure.
3.1. Mechanisms for Isolating Stored Data 3.1. Mechanisms for Isolating Stored Data
This section defines mechanisms to avoid race conditions while This section defines mechanisms to avoid race conditions while
concurrently writing an array or dictionary of a Shared Resource. concurrently writing an array or dictionary of a Shared Resource.
If a dictionary is used in the Shared Resource, the dictionary key If a dictionary is used in the Shared Resource, the dictionary key
MUST be the Node-ID of the certificate that will be used to sign the MUST be the Node-ID of the certificate that will be used to sign the
stored data. Thus data access is bound to the unique ID-holder. stored data. Thus data access is bound to the unique ID holder.
If the data model of the Shared Resource is an array, each Authorized If the data model of the Shared Resource is an array, each Authorized
Peer SHALL obtain its exclusive range of the array indices. The Peer SHALL obtain its exclusive range of the array indices. The
following algorithm will generate an array indexing scheme that following algorithm will generate an array indexing scheme that
avoids collisions. avoids collisions.
1. Obtain the Node-ID of the certificate that will be used to sign 1. Obtain the Node-ID of the certificate that will be used to sign
the stored data the stored data
2. Take the least significant 24 bits of that Node-ID 2. Take the least significant 24 bits of that Node-ID
skipping to change at page 9, line 45 skipping to change at page 9, line 45
(see Section 7.3 in [RFC6940]). The specifications in this document (see Section 7.3 in [RFC6940]). The specifications in this document
scheme adhere to this paradigm, but enable a RELOAD peer to store scheme adhere to this paradigm, but enable a RELOAD peer to store
values of Resource Names that are derived from the username in its values of Resource Names that are derived from the username in its
certificate. This is done by using a Resource Name with a variable certificate. This is done by using a Resource Name with a variable
substring that still matches the user name in the certificate using a substring that still matches the user name in the certificate using a
pattern defined in the overlay configuration document. Thus despite pattern defined in the overlay configuration document. Thus despite
being variable, an allowable Resource Name remains tied to the being variable, an allowable Resource Name remains tied to the
Owner's certificate. A sample pattern might be formed as follows. Owner's certificate. A sample 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 { struct {
ResourceNameType type; ResourceNameType type;
uint16 length; uint16 length;
select(type) { select(type) {
case pattern: case pattern:
opaque resource_name<0..2^16-1>; opaque resource_name<0..2^16-1>;
/* Types can be extended */ /* Types can be extended */
} };
} ResourceNameExtension } 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 4 skipping to change at page 11, line 4
The ResourceNameType enum and the ResourceNameExtension structure can The ResourceNameType enum and the ResourceNameExtension structure can
be extended by further Usages to define other naming schemes. be extended by further Usages to define other naming schemes.
5.3. Overlay Configuration Document Extension 5.3. Overlay Configuration Document Extension
This section extends the overlay configuration document by defining This section extends the overlay configuration document by defining
new elements for patterns relating resource names to user names. new elements for patterns relating resource names to user names.
Configurations in this overlay document MUST adhere in syntax and Configurations in this overlay document MUST adhere in syntax and
semantic of names as defined by the context of use. For example, AOR semantic of names as defined by the context of use. For example, AOR
syntax restrictions apply when using P2PSIP[I-D.ietf-p2psip-sip] , syntax restrictions apply when using P2PSIP[I-D.ietf-p2psip-sip],
while a more general naming is feasible in plain RELOAD. while a more general naming is feasible in plain RELOAD.
The <variable-resource-names> element serves as a container for one The <variable-resource-names> element serves as a container for one
or multiple <pattern> sub-elements. It is an additional parameter or multiple <pattern> sub-elements. It is an additional parameter
within the kind block and has a boolean "enable" attribute that within the kind-block and has a boolean "enable" attribute that
indicates, if true, that the overlay provider allows variable indicates, if true, that the overlay provider allows variable
resource names for this Kind. The default value of the "enable" resource names for this Kind. The default value of the "enable"
attribute is "false". In the absence of a <variable-resource-names> attribute is "false". In the absence of a <variable-resource-names>
element for a Kind using the USER-CHAIN-ACL access policy (see element for a Kind using the USER-CHAIN-ACL access policy (see
Section 6.6), implementors SHOULD assume this default value. Section 6.6), implementors SHOULD assume this default value.
A <pattern> element MUST be present if the "enabled" attribute of its A <pattern> element MUST be present if the "enabled" attribute of its
parent element is set to true. Each <pattern> element defines a parent element is set to true. Each <pattern> element defines a
pattern for constructing extended resource names for a single Kind. pattern for constructing extended resource names for a single Kind.
It is of type xsd:string and interpreted as a regular expression It is of type xsd:string and interpreted as a regular expression
skipping to change at page 11, line 31 skipping to change at page 11, line 31
specifications in [IEEE-Posix]). In this regular expression, $USER specifications in [IEEE-Posix]). In this regular expression, $USER
and $DOMAIN are used as variables for the corresponding parts of the and $DOMAIN are used as variables for the corresponding parts of the
string in the certificate user name field (with $USER preceding and string in the certificate user name field (with $USER preceding and
$DOMAIN succeeding the '@'). Both variables MUST be present in any $DOMAIN succeeding the '@'). Both variables MUST be present in any
given pattern definition. If no pattern is defined for a Kind or the given pattern definition. If no pattern is defined for a Kind or the
"enable" attribute is false, allowable Resource Names are restricted "enable" attribute is false, allowable Resource Names are restricted
to the username of the signer for Shared Resource. to the username of the signer for Shared Resource.
The Relax NG Grammar for the Variable Resource Names Extension reads: The Relax NG Grammar for the Variable Resource Names Extension reads:
<!-- VARIABLE RESOURCE URN SUB-NAMESPACE --> # VARIABLE RESOURCE URN SUB-NAMESPACE
namespace share = "urn:ietf:params:xml:ns:p2p:config-base:share" namespace share = "urn:ietf:params:xml:ns:p2p:config-base:share"
<!-- VARIABLE RESOURCE NAMES ELEMENT --> # VARIABLE RESOURCE NAMES ELEMENT
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 share:pattern { xsd:string }*
}? }?
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 initiated by the Resource Owner. A RELOAD users can solely be initiated by the Resource Owner. A
Resource Owner can share RELOAD Kinds by using the following Resource Owner can share RELOAD Kinds by using the following
procedure. procedure.
skipping to change at page 13, line 8 skipping to change at page 13, line 8
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
[RFC6940] at the corresponding item of the Access Control List. (see[RFC6940] Section 7.2.1) at the corresponding item of the Access
Revoking a permission automatically invalidates all delegations Control List. Revoking a permission automatically invalidates all
performed by that user including all subsequent delegations. This delegations performed by that user including all subsequent
allows to invalidate entire subtrees of the delegations tree with delegations. This allows to invalidate entire subtrees of the
only a single operation. Overwriting the root item with a non- delegations tree with only a single operation. Overwriting the root
existent value of an Access List invalidates the entire delegations item with a non-existent value of an Access List invalidates the
tree. entire delegations 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
skipping to change at page 14, line 51 skipping to change at page 14, line 51
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 [RFC6940]. The USER-CHAIN-ACL policy allows RELOAD base document [RFC6940]. The USER-CHAIN-ACL policy allows
Authorized Peers to write a Shared Resource, even though they do not Authorized Peers to write a Shared Resource, even though they do not
own the corresponding certificate. Additionally, the USER-CHAIN-ACL own the corresponding certificate. Additionally, the USER-CHAIN-ACL
allows the storage of Kinds with a variable resource name that are allows the storage of Kinds with a variable resource name that are
following one of the specified naming pattern. Hence, on an inbound following one of the specified naming pattern. Hence, on an inbound
store request on a Kind that uses the USER-CHAIN-ACL access policy, store request on a Kind that uses the USER-CHAIN-ACL access 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
skipping to change at page 17, line 35 skipping to change at page 17, line 35
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
XML: N/A, the requested URI is an XML namespace XML: N/A, the requested URI is an XML namespace
10. Acknowledgments 10. References
This work was stimulated by fruitful discussions in the P2PSIP
working group and SAM research group. We would like to thank all
active members for constructive thoughts and feedback. In
particular, the authors would like to thank (in alphabetical order)
Emmanuel Baccelli, Lothar Grimm, Cullen Jennings, Peter Musgrave,
Joerg Ott, Marc Petit-Huguenin, Peter Pogrzeba, and Jan Seedorf.
This work was partly funded by the German Federal Ministry of
Education and Research, projects HAMcast, Mindstone, and SAFEST.
11. References 10.1. Normative References
11.1. Normative References
[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,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
January 2004. DOI 10.17487/RFC3688, January 2004,
<http://www.rfc-editor.org/info/rfc3688>.
[RFC6940] Jennings, C., Lowekamp, B., Rescorla, E., Baset, S., and [RFC6940] Jennings, C., Lowekamp, B., Ed., Rescorla, E., Baset, S.,
H. Schulzrinne, "REsource LOcation And Discovery (RELOAD) and H. Schulzrinne, "REsource LOcation And Discovery
Base Protocol", RFC 6940, January 2014. (RELOAD) Base Protocol", RFC 6940, DOI 10.17487/RFC6940,
January 2014, <http://www.rfc-editor.org/info/rfc6940>.
11.2. Informative References 10.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-07 (work in progress), May draft-ietf-p2psip-concepts-07 (work in progress), May
2015. 2015.
[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-14 (work in progress), January 2015. draft-ietf-p2psip-sip-15 (work in progress), July 2015.
[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, DOI 10.17487/RFC3550,
July 2003, <http://www.rfc-editor.org/info/rfc3550>.
Appendix A. Change Log
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:
1. Added IANA registration for namespace
2. Editorial improvements
3. Updated References
The following changes have been made from version draft-ietf-p2psio-
share-00:
1. Clarified use of identities in ACLs
2. Specified use of Posix regular expressions in configuration
document
3. Added IANA considerations
4. Editorial improvements
5. Updated References
The following changes have been made from version draft-knauf-p2psip-
share-02:
1. Editorial improvements
2. Updated References
The following changes have been made from version draft-knauf-p2psip-
share-01:
1. Simplified the ACL data structure in response to WG feedback
2. Added ResourceNameExtension data structure to simplify the use of
variable resource names
3. Restructured document
4. Many editorial improvements
The following changes have been made from version draft-knauf-p2psip-
share-00:
1. Integrated the USER-PATTERN-MATCH access policy into USER-CHAIN-
ACL
2. Access Control List Kind uses USER-CHAIN-ACL exclusively
3. Resources to be shared use USER-CHAIN-ACL exclusively
4. More precise specification of mandatory User_name and
Resource_name fields for Shared Resources
5. Added mechanism for isolating stored data to prevent race
conditions while concurrent storing
6. XML Extension for variable resource names uses its own namespace Acknowledgments
7. Many editorial improvements This work was stimulated by fruitful discussions in the P2PSIP
working group and SAM research group. We would like to thank all
active members for constructive thoughts and feedback. In
particular, the authors would like to thank (in alphabetical order)
Emmanuel Baccelli, Lothar Grimm, Cullen Jennings, Peter Musgrave,
Joerg Ott, Marc Petit-Huguenin, Peter Pogrzeba, and Jan Seedorf.
This work was partly funded by the German Federal Ministry of
Education and Research, projects HAMcast, Mindstone, and SAFEST.
Authors' Addresses Authors' Addresses
Alexander Knauf Alexander Knauf
HAW Hamburg HAW Hamburg
Berliner Tor 7 Berliner Tor 7
Hamburg D-20099 Hamburg D-20099
Germany Germany
Phone: +4940428758067 Phone: +4940428758067
Email: alexanderknauf@gmail.com Email: alexanderknauf@gmail.com
Thomas C. Schmidt Thomas C. Schmidt
skipping to change at page 20, line 37 skipping to change at page 19, line 20
Phone: +4940428758067 Phone: +4940428758067
Email: alexanderknauf@gmail.com Email: alexanderknauf@gmail.com
Thomas C. Schmidt Thomas C. Schmidt
HAW Hamburg HAW Hamburg
Berliner Tor 7 Berliner Tor 7
Hamburg D-20099 Hamburg D-20099
Germany Germany
Email: t.schmidt@haw-hamburg.de Email: t.schmidt@haw-hamburg.de
URI: http://inet.cpt.haw-hamburg.de/members/schmidt URI: http://inet.haw-hamburg.de/members/schmidt
Gabriel Hege Gabriel Hege
daviko GmbH daviko GmbH
Am Borsigturm 50 Schillerstr. 107
Berlin D-13507 Berlin D-10625
Germany Germany
Phone: +493043004344 Phone: +493043004344
Email: hege@daviko.com Email: hege@daviko.com
Matthias Waehlisch Matthias Waehlisch
link-lab & FU Berlin link-lab & FU Berlin
Hoenower Str. 35 Hoenower Str. 35
Berlin D-10318 Berlin D-10318
Germany Germany
Email: mw@link-lab.net Email: mw@link-lab.net
URI: http://www.inf.fu-berlin.de/~waehl URI: http://www.inf.fu-berlin.de/~waehl
 End of changes. 35 change blocks. 
123 lines changed or deleted 60 lines changed or added

This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/