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

[Vicky Weissman]

Hi all,

Like Susanne and Steven, I also enjoyed reading Alapan and Andrew's paper.
Comments below:

(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.  

(2) I'm not sure why a use license cannot both grant some permissions and
forbid others.  

(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).  

(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].     

(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.

(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.  

Best,
Vicky
 

-----Original Message-----
Today's Topics:

   1. Re: New ODRL v2.0 Model (Susanne Guth)
   2. Re: New ODRL v2.0 Model (Steven Rowat)

Hi Alapan, happy new year everybody,

thanks for your proposal with regard to ODRL 2.0. Let's get things moving!
Here are my first comments, yet not complete (there have been a bunch of
issues in your paper :) )

With regard to "other issues":

4.5.1 Containers

We kicked out the containers because it is extremely complex to define the
semantics and implement containers. (That showed the implementation
experiences). On the other hand we did not come up with a better solution for
expressing XOR/OR/AND relations. In ODRL v1.1 containers are allowed for a
bunch of things; maybe in v2.0 Containers should only be allowed for
permissions, prohibitions and duties. What do you guy think?

4.5.2 "NOT"

By allowing to express "Prohibitions" we have our means to express "NOT".
Originally the NOT was requested to express things like: "Everything is
allowed, except 'thisandthat'. The odrl-v2.0-"prohibition" offers such a
means.

4.5.3 Next Rights

I kind of like the idea to eliminate one level in the ODRLv2.0 and instead
use a variable to express different types of rights expressions. We might
want to think about adding your "Type" attribute of License to the "Rights"
element. By that however we reduce our flexibility to but e.g. an offer an
"next rights" into one "rights" node tree? 

In your current proposal a ticket could be part of a license which could have
the Type="Offer". That would not really make sense to me. We should keep
ticket, offer, request, agreement, etc. on one level respectively with the
same type of element. In your proposal, offer is an attribute and ticket is
an element.

4.5.4 Parties & Duties

I need some more information on this issue because I don't understand the
conflict that you have. Is it because the Duty always refers to an Action?

That's it for now. More comments to come. Any other thought of the ODRL v2.0
people?

So long
Susanne

----------------------------------------------------------------------

Message: 2
Date: Sun, 15 Jan 2006 15:46:13 -0800
From: Steven_Rowat at sunshine.net (Steven Rowat)
Subject: Re: [Odrl-version2] New ODRL v2.0 Model
To: "ODRL Version 2.0" <odrl-version2 at odrl.net>
Message-ID: <v01520d00bff08acb451b@[216.113.215.204]>
Content-Type: text/plain; charset="us-ascii"

Hi Alapan,

Thanks for the opportunity to see your work. Comments below. Specifics first,
then general.

4.1  Rights, Signature and Legal Elements. 
All changes [#1-3] agreed. 

4.2 Communication and License Elements
Changes 4-6, uncertain if necessary, but no objection

4.3 Contract
Change 7, agreed

Overall Comments:

1. Bidding would probably be a large-scale addition and if so might slow down
dissemination of ODRL at a critical time. 

2. What is a "ticket" in your revamped model (or, for that matter, in the
original version 2. I admit I've forgotten)? How is it different from
"contract"?

3. The use of the word 'contract' will be appropriate for negotiations
between corporations and bureacracies, but might put off the average consumer
wishing to download music or a few pages of text, say. In this situation, in
my opinion, "Agreement" is much more user-friendly. Admittedly, the average
user will not need to be looking under the hood, so "Agreement" could be used
in pull-down menus etc., and 'contract' in the actual code. But still, it
would be more clean to have the same word used at both levels, unless there
is a legal reason why the word 'contract' has to be used; I suspect that
there is not. ("A rose by any other name would smell as sweet").

4. Section 4.5, "Other Issues": Unfortunately in all of these I seem to
understand too little about the situation to see a problem. I think I'll take
the 'glass-is-half-full' approach and treat this as evidence that ODRL 2 is
almost ready for release.  :-) 

steven rowat