[Odrl-version2] RE: ODRL-Version2 Digest, Vol 12, Issue 3

[Alapan Arnab]

Hi Vicky,
Thanks a lot for your kind comments - glad the paper was informative.
> 
> (1) Your discussion on denial of service attacks raises the question of what
> could be done if the attack is distributed (i.e., attacker infiltrates many
> machines and has each one begin bartering at the same time).  This problem is
> certainly not unique to ODRL and, perhaps, the entire topic of defense should
> be given a full treatment in another paper.  

Yes - the problem affects anonymous negotiations in general. On the
whole, this is not a problem for ODRL as ODRL is focussed on the
language - but does need to be addressed at some level.

> (2) I'm not sure why a use license cannot both grant some permissions and
> forbid others.  
> 
My problems with the existing model was the fact that it was possible to
have a license that granted and forbid the same set of permissions. This
problem is clearly overcome with my approach.

The current motto in RELs is - grant only the rights that are mentioned.
Thus in a prohibition model - it should simply be assign all the rights
except the ones mentioned. For this reason, there is no need to ever
express a set of rights that are forbidden.
> (3) I'm concerned that your interpretation of permitting/prohibiting
> agreements is problematic.  To see why, suppose that Alice is a faculty
> member of Univ. of Cape Town and a citizen of South Africa.  The university
> writes two agreements, the first allows faculty members to "checkout" a
> library resource for 6 months and the second allows any citizen of South
> Africa to put in a request for a library resource (which is then reviewed and
> acting on accordingly).  The two agreements are in conflict, because the
> first forbids Alice to request a resource, since she is faculty and not
> explicitly permitted in the first agreement, and the second permits Alice to
> make the request, since she is a citizen of Cape Town.  In general, I suspect
> that conflicts are likely to arise unless, for each principal p, there is at
> most one agreement that permits (or denies) rights to p.  An obvious solution
> is to remove implicit assumptions from agreements; that is, a
> permitting/prohibiting agreement permits/forbids the actions specified (under
> the conditions given) and does not make any statements beyond that.   
> 
> (4!) You say that the your recommended changes to the permission/prohibition
> elements "removes all the ambiguities presented in the current approach".
> Since you have not given formal semantics for your suggestion, this is simply
> not true.  Because your suggestion is written in English, there are a variety
> of ways in which I could interpret it.  For example, suppose an agreement
> says only that Alice may print 5 copies of the report.  Your suggestion could
> be equivalent to "if Alice has not made 5 copies, then she may print the
> report and is forbidden to do anything else; otherwise, she is forbidden to
> do any action".  Alternatively, you could mean "if Alice has not made 5
> copies, then she may print the report and she is forbidden to do anything
> else to the report; otherwise, there is no action that she can do
> legitimately that involves the report".  (Given the discussion in the second
> paragraph of Section 4.5.4, you seem to favor the first interpretation,
> whereas I think the second is more intuitive.)  Riccardo Pucella and I have
> given formal semantics to a representative fragment of ODRL v.1; I suspect a
> similar approach could be used here (almost finished with journal version,
> which I can send you if interested).  
> 
I would like to read your journal paper. On the examples you mention
(with Alice printing) - I am not sure what the difference is. However, I
do agree that a more formal semantic is required when it comes to the
issue of containers and the prohibition model.
> (5) I can see why a general-purpose NOT container might be useful, but I'm
> not sure it makes sense to have both an XOR and a NOT container.  To see why,
> notice that XOR(true, blah) = NOT blah, and XOR(blah_1,..., blah_n) =
> OR[e_1,..., e_n], where e_i = AND[blah_i, NOT blah_1, ..., NOT blah_{i-1},
> blah_{i+1}, ..., blah_n].     
As I mentioned, one useful function of NOT would be to explicitly
restrict a party (which is not covered by the prohibition model).
> 
> (6) The ambiguity that you allude to in Section 4.5.5 was, I believe,
> discussed in the conference version of  "A Formal Foundation for ODRL",
> WITS-04 (Workshop on Issues in the Theory of Security).  If interested, I can
> send you a copy or you can download it from my homepage
> (http://www.cs.cornell.edu/People/vickyw).  It is also discussed in the full
> version, which is on the verge of being submitted and, I think, is a
> substantial improvement on the conference paper.
> 
I will have a look at the paper.
> (7) Maybe I shouldn't say this, because it's not a "technical comment", but I
> found your paper especially easy to read.  I appreciate you taking the time
> to communicate so clearly.  
> 
Thanks a lot! 

Regards
Alapan
-- 
Alapan Arnab
Data Networks Architecture (DNA) Laboratory
Department of Computer Science
University of Cape Town
Rondebosch, 7700
South Africa

Tel: +27 21 650 3127
Web: http://people.cs.uct.ac.za/~aarnab/
Blog: http://idiots-mind.blogspot.com
----------
"You must always believe that you can be the best, but you must never
believe you have achieved it".
Juan Manuel Fangio