Re: [P2PSIP] draft-knauf-p2psip-share-00

Marc Petit-Huguenin <petithug@acm.org> Mon, 16 May 2011 23:15 UTC

Return-Path: <petithug@acm.org>
X-Original-To: p2psip@ietfa.amsl.com
Delivered-To: p2psip@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4005E07B8 for <p2psip@ietfa.amsl.com>; Mon, 16 May 2011 16:15:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.065
X-Spam-Level:
X-Spam-Status: No, score=-102.065 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cSn09D5jhjVN for <p2psip@ietfa.amsl.com>; Mon, 16 May 2011 16:15:40 -0700 (PDT)
Received: from server.implementers.org (server.implementers.org [69.55.225.91]) by ietfa.amsl.com (Postfix) with ESMTP id 76967E06EF for <p2psip@ietf.org>; Mon, 16 May 2011 16:15:40 -0700 (PDT)
Received: by server.implementers.org (Postfix, from userid 1001) id 5D224DCC4018; Mon, 16 May 2011 23:15:39 +0000 (UTC)
Received: from [192.168.2.3] (server.implementers.org [127.0.0.1]) by server.implementers.org (Postfix) with ESMTPA id CD9A9DC44002; Mon, 16 May 2011 23:15:30 +0000 (UTC)
Message-ID: <4DD1B011.8060505@acm.org>
Date: Mon, 16 May 2011 16:15:29 -0700
From: Marc Petit-Huguenin <petithug@acm.org>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.15) Gecko/20110402 Iceowl/1.0b2 Icedove/3.1.9
MIME-Version: 1.0
To: Alexander Knauf <alexander.knauf@haw-hamburg.de>
References: <4DCDC1A2.5030201@acm.org> <4DD0F13E.7070007@haw-hamburg.de>
In-Reply-To: <4DD0F13E.7070007@haw-hamburg.de>
X-Enigmail-Version: 1.1.2
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Cc: p2psip@ietf.org
Subject: Re: [P2PSIP] draft-knauf-p2psip-share-00
X-BeenThere: p2psip@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Peer-to-Peer SIP working group discussion list <p2psip.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/p2psip>, <mailto:p2psip-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/p2psip>
List-Post: <mailto:p2psip@ietf.org>
List-Help: <mailto:p2psip-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/p2psip>, <mailto:p2psip-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 16 May 2011 23:15:44 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Alexander,

On 05/16/2011 02:41 AM, Alexander Knauf wrote:
> Hi Marc,
> 
> thanks for your feedback!
> 
> 
> On 14.05.2011 01:41, Marc Petit-Huguenin wrote:
> My problem is with the 4th paragraph of section 3:
> 
> "Access Control Policy:  To ensure write access to Shared Resource by
>    Authorized Peers, each Usage MUST permit the USER-CHAIN-ACL access
>    policy (see Section 5.4) in addition to its regular access
>    policies (USER-MATCH, USER-NODE-MATCH, etc.)."
> 
> I do not see in -base how two (or more) Access Control Policies can be used for
> one Kind.  
>> I also see this conflict in the XML overlay config. document that only allows a
>> single access control policy per Kind. If it would support multiple access
>> policies, something like this:
> 
>> kind-parameter &= element access-control { access-control-type }* <-- note the asterisk, compare with base -13  p.122
> 
> 
>> the receiver of a store request could iterate over the those policies, trying if
>> any of them is true.

Well, in this case I suggest that you talk to the -base authors to add this
behavior in the spec (Note that I am not saying that this is a good idea).

I will send a more detailed review (and will update my access control I-D with
the modifications needed to implement this) when this is decided.

As for the USER-PATTERN-MATCH policy, one problem I see is that the spec does
not define strongly enough the resource_name field.  The problem here is that
when storing a value, a peer does not have access to the definition on this
value - and cannot as each kind will have a different definition.  This is why
you need to say in the spec something like '... MUST define an "opaque
<0..2^16-1>" field as the first field within the Kind data structure,...". With
this field always defined as being the first in a Kind using USER-PATTERN-MATCH,
the policy code will have no problem finding it.

Also I think that the variable-resource-names element should be inside the kind
element, and that you should also define its namespace.

Thanks.

- -- 
Marc Petit-Huguenin
Personal email: marc@petit-huguenin.org
Professional email: petithug@acm.org
Blog: http://blog.marc.petit-huguenin.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iEYEARECAAYFAk3RsBAACgkQ9RoMZyVa61eSQQCeMf3rao3DihzM6ATcElSIyflM
fEEAoIzkoli9Zp8UL82VbOMFRs4N2rMh
=BnQ2
-----END PGP SIGNATURE-----