draft-ietf-p2psip-share-05.txt   draft-ietf-p2psip-share-06.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: September 3, 2015 G. Hege Expires: December 19, 2015 G. Hege
daviko GmbH daviko GmbH
M. Waehlisch M. Waehlisch
link-lab & FU Berlin link-lab & FU Berlin
March 2, 2015 June 17, 2015
A Usage for Shared Resources in RELOAD (ShaRe) A Usage for Shared Resources in RELOAD (ShaRe)
draft-ietf-p2psip-share-05 draft-ietf-p2psip-share-06
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 September 3, 2015. This Internet-Draft will expire on December 19, 2015.
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 30 skipping to change at page 2, line 30
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 . . . . . . . . . . . . . . . . . . . . . 10 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 . . . . . . . . . . . . . . . . . . 12 6.1. Granting Write Access . . . . . . . . . . . . . . . . . . 12
6.2. Revoking Write Access . . . . . . . . . . . . . . . . . . 12 6.2. Revoking Write Access . . . . . . . . . . . . . . . . . . 13
6.3. Validating Write Access through an ACL . . . . . . . . . 13 6.3. Validating Write Access through an ACL . . . . . . . . . 13
6.4. Operations of Storing Peers . . . . . . . . . . . . . . . 14 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 . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . . 16 9.2. Data Kind-ID . . . . . . . . . . . . . . . . . . . . . . 17
9.3. XML Name Space Registration . . . . . . . . . . . . . . . 17 9.3. XML Name Space Registration . . . . . . . . . . . . . . . 17
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
11.1. Normative References . . . . . . . . . . . . . . . . . . 17 11.1. Normative References . . . . . . . . . . . . . . . . . . 18
11.2. Informative References . . . . . . . . . . . . . . . . . 18 11.2. Informative References . . . . . . . . . . . . . . . . . 18
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 18 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
1. Introduction 1. Introduction
This document defines a RELOAD Usage for managing shared write access [RFC6940] defines the base protocol for REsource LOcation And
to RELOAD Resources and a mechanism to store Resources with a Discovery (RELOAD) that allows for application-specific extensions by
variable name. The Usage for Shared Resources in RELOAD (ShaRe) Usages. The present document defines such a RELOAD Usage for
enables overlay users to share their exclusive write access to managing shared write access to RELOAD Resources and a mechanism to
specific Resource/Kind pairs with others. Shared Resources form a store Resources with a variable name. The Usage for Shared Resources
basic primitive for enabling various coordination and notification in RELOAD (ShaRe) enables overlay users to share their exclusive
schemes among distributed peers. Write permission is controlled by write access to specific Resource/Kind pairs with others. Shared
an Access Control List (ACL) Kind that maintains a chain of Resources form a basic primitive for enabling various coordination
Authorized Peers for a particular Shared Resource. A newly defined and notification schemes among distributed peers. Write permission
USER-CHAIN-ACL access control policy enables shared write access in is controlled by an Access Control List (ACL) Kind that maintains a
RELOAD. chain of Authorized Peers for a particular Shared Resource. A newly
defined USER-CHAIN-ACL access control policy enables shared write
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
skipping to change at page 4, line 6 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 [RFC6940]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], in particular the RELOAD Usage, Resource
used: and Kind. Additionally, the following terms are 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
RELOAD Resource/Kind pair by following the specifications in this RELOAD Resource/Kind pair by following the specifications in this
document. The list items are stored as Access Control List Kinds document. The list items are stored as Access Control List Kinds
skipping to change at page 6, line 10 skipping to change at page 6, line 10
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
3. Concatenate an 8 bit long short individual index value to those 3. Append an 8 bit long short individual index value to those 24 bit
24 bit of the Node-ID of the Node-ID
The resulting 32 bits long integer MUST be used as the index for The resulting 32 bits long integer MUST be used as the index for
storing an array entry in a Shared Resource. The 8 bit individual storing an array entry in a Shared Resource. The 8 bit individual
index can be incremented individually for further array entries and index can be incremented individually for further array entries and
allows for 256 distinct entries per Peer. allows for 256 distinct entries per Peer.
The mechanism to create the array index is related to the pseudo- The mechanism to create the array index is related to the pseudo-
random algorithm to generate an SSRC identifier in RTP, see random algorithm to generate an SSRC identifier in RTP, see
Section 8.1 in [RFC3550] for calculating the probability of a Section 8.1 in [RFC3550] for calculating the probability of a
collision. collision.
skipping to change at page 7, line 10 skipping to change at page 7, line 10
owner of the public key certificate associated with this Resource-ID. owner of the public key certificate associated with this Resource-ID.
The allow_delegation (ad) flag for a root ACL item is set to 1 by The allow_delegation (ad) flag for a root ACL item is set to 1 by
default. The array index is generated by using the mechanism for default. The array index is generated by using the mechanism for
isolating stored data as described in Section 3.1. Hence, the most isolating stored data as described in Section 3.1. Hence, the most
significant 24 bits of the array index (0x123abc) are the least significant 24 bits of the array index (0x123abc) are the least
significant 24 bits of the Node-ID of the Resource Owner. significant 24 bits of the Node-ID of the Resource Owner.
The array item at index 0x123abc002 represents the first trust The array item at index 0x123abc002 represents the first trust
delegation to an Authorized Peer that is thus permitted to write to delegation to an Authorized Peer that is thus permitted to write to
the Shared Resource of Kind-ID 1234. Additionally, the Authorized the Shared Resource of Kind-ID 1234. Additionally, the Authorized
peer Alice is also granted (limited) write access to the ACL as peer Alice is also granted write access to the ACL as indicated by
indicated by the allow_delegation flag (ad) set to 1. This the allow_delegation flag (ad) set to 1. This configuration
configuration authorizes Alice to store further trust delegations to authorizes Alice to store further trust delegations to the Shared
the Shared Resource, i.e., add items to the ACL. On the contrary, Resource, i.e., add items to the ACL. On the contrary, index
index 0x456def001 illustrates trust delegation for Kind-ID 1234, in 0x456def001 illustrates trust delegation for Kind-ID 1234, in which
which the Authorized Peer Bob is not allowed to grant access to the Authorized Peer Bob is not allowed to grant access to further
further peers (ad = 0). Each Authorized Peer signs its ACL items by peers (ad = 0). Each Authorized Peer signs its ACL items by using
using its own signer identity along with its own private key. This its own signer identity along with its own private key. This allows
allows other peers to validate the origin of an ACL item and makes other peers to validate the origin of an ACL item and makes ownership
ownership transparent. transparent.
To manage Shared Resource access of multiple Kinds at a single To manage Shared Resource access of multiple Kinds at a single
location, the Resource Owner can create new ACL entries that refer to location, the Resource Owner can create new ACL entries that refer to
another Kind-ID as shown in array entry index 0x123abc003. Note that another Kind-ID as shown in array entry index 0x123abc003. Note that
overwriting existing items in an Access Control List that reference a overwriting existing items in an Access Control List with a change in
different Kind-ID revokes all trust delegations in the corresponding the Kind-ID revokes all trust delegations in the corresponding
subtree (see Section 6.2). Authorized Peers are only enabled to subtree (see Section 6.2). Authorized Peers are only enabled to
overwrite existing ACL item they own. The Resource Owner is allowed overwrite existing ACL item they own. The Resource Owner is allowed
to overwrite any existing ACL item, but should be aware of its to overwrite any existing ACL item, but should be aware of its
consequences. consequences on the trust delegation chain.
+------------------------------------------------------+ +------------------------------------------------------+
| Access Control List | | Access Control List |
+-----------+------------------------------+-----------+ +-----------+------------------------------+-----------+
| #Index | Array Entries | signed by | | #Index | Array Entries | signed by |
+-----------+------------------------------+-----------+ +-----------+------------------------------+-----------+
| 123abc001 | to_user:Owner Kind:1234 ad:1 | Owner | | 123abc001 | to_user:Owner Kind:1234 ad:1 | Owner |
+-----------+------------------------------+-----------+ +-----------+------------------------------+-----------+
| 123abc002 | to_user:Alice Kind:1234 ad:1 | Owner | | 123abc002 | to_user:Alice Kind:1234 ad:1 | Owner |
+-----------+------------------------------+-----------+ +-----------+------------------------------+-----------+
skipping to change at page 9, line 25 skipping to change at page 9, line 25
kind: This field contains the Kind-ID of the Shared Resource. kind: This field contains the Kind-ID of the Shared Resource.
allow_delegation: If true, this Boolean flag indicates that the allow_delegation: If true, this Boolean flag indicates that the
Authorized Peer in the 'to_user' field is allowed to add Authorized Peer in the 'to_user' field is allowed to add
additional entries to the ACL for the specified Kind-ID. additional entries to the ACL for the specified Kind-ID.
5. Extension for Variable Resource Names 5. Extension for Variable Resource Names
5.1. Overview 5.1. Overview
In certain use cases such as conferencing (c.f., In certain use cases such as conferencing (c.f.
[I-D.ietf-p2psip-disco]) it is desirable to increase the flexibility [I-D.ietf-p2psip-disco]) it is desirable to increase the flexibility
of a peer in using Resource Names beyond those defined by the of a peer in using Resource Names beyond those defined by the
username or Node-ID fields in its certificate. For this purpose, username or Node-ID fields in its certificate. For this purpose,
this document presents the concept for variable Resources Names that this document presents the concept for variable Resources Names that
enables providers of RELOAD instances to define relaxed naming enables providers of RELOAD instances to define relaxed naming
schemes for overlay Resources. schemes for overlay Resources.
Each RELOAD node uses a certificate to identify itself using its user Each RELOAD node uses a certificate to identify itself using its user
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, (see Section 7.3 in [RFC6940]). The specifications in this document
but enable a RELOAD peer to store values of Resource Names that are scheme adhere to this paradigm, but enable a RELOAD peer to store
derived from the username in its certificate. This is done by using values of Resource Names that are derived from the username in its
a Resource Name with a variable substring that still matches the user certificate. This is done by using a Resource Name with a variable
name in the certificate using a pattern defined in the overlay substring that still matches the user name in the certificate using a
configuration document. Thus despite being variable, an allowable pattern defined in the overlay configuration document. Thus despite
Resource Name remains tied to the Owner's certificate. A sample being variable, an allowable Resource Name remains tied to the
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
skipping to change at page 12, line 7 skipping to change at page 12, line 7
<!-- PATTERN ELEMENT --> <!-- PATTERN ELEMENT -->
element pattern { xsd:string }* element 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 issued by the Resource Owner. A Resource RELOAD users can solely be initiated by the Resource Owner. A
Owner can share RELOAD Kinds by using the following procedure. Resource 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
flag is set to 1. The index of array data structure MUST be flag is set to 1. The index of array data structure MUST be
generated as described in Section 3.1 generated as described in Section 3.1
o Further ACL items for this Kind-ID stored by the Resource Owner o Further ACL items for this Kind-ID stored by the Resource Owner
will delegate write access to Authorized Peers. These ACL items MAY delegate write access to Authorized Peers. These ACL items
contain the same resource name extension field, the username of contain the same resource name extension field, the username of
the Authorized Peer and the Kind-Id of the Shared Resource. the Authorized Peer and the Kind-Id of the Shared Resource.
Optionally, the Resource Owner sets the "ad" to 1 (the default Optionally, the Resource Owner sets the "ad" to 1 (the default
equals 0) to enable the Authorized Peer to further delegate write equals 0) to enable the Authorized Peer to further delegate write
access. Each succeeding ACL item created by the Resource Owner access. For each succeeding ACL item, the Resource Owner
can be stored in the numerical order of the array index starting increments its individual index value by one (see Section 3.1) so
with the index of the root item incremented by one. that items can be stored in the numerical order of the array index
starting with the index of the root item.
An Authorized Peer with delegation allowance ("ad"=1) can extend the An Authorized Peer with delegation allowance ("ad"=1) can extend the
access to an existing Shared Resource as follows. access to an existing Shared Resource as follows.
o An Authorized Peer can store additional ACL items at the Resource- o An Authorized Peer can store additional ACL items at the Resource-
ID of the Shared Resource. These ACL items contain the resource ID of the Shared Resource. These ACL items contain the resource
name extension field, the username of the newly Authorized Peer, name extension field, the username of the newly Authorized Peer,
and the Kind-Id of the Shared Resource. Optionally, the "ad" flag and the Kind-Id of the Shared Resource. Optionally, the "ad" flag
is set to 1 for allowing the Authorized Peer to further delegate is set to 1 for allowing the Authorized Peer to further delegate
write access. The array index MUST be generated as described in write access. The array index MUST be generated as described in
skipping to change at page 14, line 30 skipping to change at page 14, line 36
6.5. Operations of Accessing Peers 6.5. Operations of Accessing Peers
Accessing peers, i.e., peers that fetch a Shared Resource, MAY Accessing peers, i.e., peers that fetch a Shared Resource, MAY
validate that the originator of a Shared Resource was authorized to validate that the originator of a Shared Resource was authorized to
store data at this Resource-ID by processing the corresponding ACL. store data at this Resource-ID by processing the corresponding ACL.
To enable an accessing peer to perform the access validation To enable an accessing peer to perform the access validation
procedure described in Section 6.3, it first needs to obtain the most procedure described in Section 6.3, it first needs to obtain the most
recent Access Control List in the following way. recent Access Control List in the following way.
1. Send a Stat request to the Resource-ID of the Shared Resource to 1. Send a Stat request to the Resource-ID of the Shared Resource to
obtain all array indexes of stored ACL Kinds. obtain all array indexes of stored ACL Kinds (as per [RFC6940],
Section 7.4.3.)
2. Fetch all indexes of existing ACL items at this Resource-ID by 2. Fetch all indexes of existing ACL items at this Resource-ID by
using the array ranges retrieved in the Stat request answer. using the array ranges retrieved in the Stat request answer
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
skipping to change at page 17, line 27 skipping to change at page 17, line 41
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. Acknowledgments
This work was stimulated by fruitful discussions in the P2PSIP This work was stimulated by fruitful discussions in the P2PSIP
working group and SAM research group. We would like to thank all working group and SAM research group. We would like to thank all
active members for constructive thoughts and feedback. In active members for constructive thoughts and feedback. In
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- Emmanuel Baccelli, Lothar Grimm, Cullen Jennings, Peter Musgrave,
Huguenin, Peter Pogrzeba, and Jan Seedorf. This work was partly Joerg Ott, Marc Petit-Huguenin, Peter Pogrzeba, and Jan Seedorf.
funded by the German Federal Ministry of Education and Research, This work was partly funded by the German Federal Ministry of
projects HAMcast, Mindstone, and SAFEST. Education and Research, projects HAMcast, Mindstone, and SAFEST.
11. References 11. References
11.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, March 1997.
skipping to change at page 18, line 10 skipping to change at page 18, line 27
[RFC6940] Jennings, C., Lowekamp, B., Rescorla, E., Baset, S., and [RFC6940] Jennings, C., Lowekamp, B., Rescorla, E., Baset, S., and
H. Schulzrinne, "REsource LOcation And Discovery (RELOAD) H. Schulzrinne, "REsource LOcation And Discovery (RELOAD)
Base Protocol", RFC 6940, January 2014. 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-06 (work in progress), June draft-ietf-p2psip-concepts-07 (work in progress), May
2014. 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-14 (work in progress), January 2015.
skipping to change at page 20, line 19 skipping to change at page 20, line 36
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: schmidt@informatik.haw-hamburg.de Email: t.schmidt@haw-hamburg.de
URI: http://inet.cpt.haw-hamburg.de/members/schmidt URI: http://inet.cpt.haw-hamburg.de/members/schmidt
Gabriel Hege Gabriel Hege
daviko GmbH daviko GmbH
Am Borsigturm 50 Am Borsigturm 50
Berlin D-13507 Berlin D-13507
Germany Germany
Phone: +493043004344 Phone: +493043004344
Email: hege@daviko.com Email: hege@daviko.com
 End of changes. 26 change blocks. 
64 lines changed or deleted 68 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/