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/