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-----
- Re: [P2PSIP] draft-knauf-p2psip-share-00 Alexander Knauf
- [P2PSIP] draft-knauf-p2psip-share-00 Marc Petit-Huguenin
- Re: [P2PSIP] draft-knauf-p2psip-share-00 Marc Petit-Huguenin
- Re: [P2PSIP] draft-knauf-p2psip-share-00 Alexander Knauf
- Re: [P2PSIP] draft-knauf-p2psip-share-00 Marc Petit-Huguenin