Subject: Re: [Simple] <except-domain> element issue for common policy

From: Jonathan Rosenberg <[email-masked]>
Date: Sat, 02 Jul 2005 00:33:01 -0400

add mine to the list of apologies for long delays in responses..

more inline.

Henning Schulzrinne wrote:

> Ted Hardie wrote:
> 
>> I agree that having the <except> clause for applicability within the
>> rule is better than the cases GeoPriv was most concerned with (it's
>> always processed at the same time, so the evaluation order problem
>> isn't salient).  It is, though, a negative permission--it's a grant
>> to all followed by a revoke to a limited set.   One of the issues I
>> expressed is that the limited set isn't useful, because of identity
>> minting. The other is that the except clause here forces a change to
>> the processing model. I'm concerned that changing the processing
>> model to (Grant, followed by revoke) will open us to things that will
>> have the problems GeoPriv wanted to avoid.
> 
> 
> I don't quite agree with the statement of the model made above. This is
> not "grant, then revoke". Rather, the exception condition restricts the
> matching of the rule. Logically speaking, rule processing proceeds in
> two phases:
> 
> (1) Determine if the rule matches a request (subscription, location
> request, etc.)
> 
> (2) Execute the actions and grant the permissions (it's a bit more 
> complicated, but irrelevant for this discussion).
> 
> The "all except" part only affects the matching (step 1), not the action
> (step 2).
> 
> This is an important difference, as it avoids the privacy unsafety
> issues that grant-then-revoke would have. Rules are binary in matching,
> i.e., they either match or don't, and thus the consequences you seem to
> fear cannot occur, inside or outside of the geopriv context.
> 
> I want to make the difference clear since I was also confused on this
> point when this whole discussion started a year or so ago.
> 
> Thus, to make up another example that avoids the identity-minting issue,
> "Apply this rule at any location except New York" would be perfectly fine.
> 
> The distinction becomes clearer if you consider hypothetically that we 
> might allow regular expressions in the matching part. We could have 
> something like
> 
> [^0-9]
> 
> which can be phrases as "any character except 0-9". Or, if we had a 
> numeric matching condition, something like "x > 9 || x < 0" could just 
> as easily be phrased as "any x except between 0 and 9". Clearly, neither 
> of these examples are "grant/revoke" conditions.

Right. Put another way, putting an exception in the matching condition 
is just another way to define the set of users to whom the additive 
permissions apply. The only difference is that the set of people to whom 
they apply is potentially large, but there is no change in the model.

Ted previously wrote:
> Except clauses that are clearly tied to specific directives are better
> than all-out negative permissions, but they can remain problematic
> in their interaction with user expectations.  If I say "Grant anyone
> access to my timezone, except Hisham" and also say "Grant any
> wg chair in APPs access to my full location", Hisham will get my
> time zone--but this may not be what a user expects, especially
> if the user expectation is driven by a sense of "override" and
> wrote the "except Hisham" after the first rule was in place. 

This concern is valid under the assumption that users directly 
manipulate these rules. I dont think that this is going to be the case. 
I think that web applications and other things will provide nice UI for 
these, and present the user with decisions they can understand. An 
application might ask the user to define the set of watchers that are to 
be blocked. Separately, the user might provide lists of people to whom 
various information is to be granted. I think the web application would 
automatically add the blocked users to the exception list for every 
rule. This preserves the expected user experience.

I've been on the fence on this topic for a long time, but at this point 
I am pretty solidly in favor of supporting exceptions for users within a 
domain rule, and exceptions for domains within an any rule.

-Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Director, Service Provider VoIP Architecture   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple

---

From: Ted Hardie <[email-masked]>
Date: Tue, 5 Jul 2005 10:45:41 -0700

At 12:33 AM -0400 7/2/05, Jonathan Rosenberg wrote:
>>
>>which can be phrases as "any character except 0-9". Or, if we had a numeric matching condition, something like "x > 9 || x < 0" could just as easily be phrased as "any x except between 0 and 9". Clearly, neither of these examples are "grant/revoke" conditions.
>
>Right. Put another way, putting an exception in the matching condition is just another way to define the set of users to whom the additive permissions apply. The only difference is that the set of people to whom they apply is potentially large, but there is no change in the model.

<snip>
>This concern is valid under the assumption that users directly manipulate these rules. I dont think that this is going to be the case. I think that web applications and other things will provide nice UI for these, and present the user with decisions they can understand. An application might ask the user to define the set of watchers that are to be blocked. Separately, the user might provide lists of people to whom various information is to be granted. I think the web application would automatically add the blocked users to the exception list for every rule. This preserves the expected user experience.
>
>I've been on the fence on this topic for a long time, but at this point I am pretty solidly in favor of supporting exceptions for users within a domain rule, and exceptions for domains within an any rule.

Okay, I agree that you can model it in a set-based way that avoids many of
the problems.  I am pretty concerned that this won't actually get coded this
way, both because grant/revoke is easier and because non-enumerable sets
aren't intuitively easy to map into many environments.  But, obviously, I'm in
the "rough" on the consensus here.  I would ask that we do two things: review
the language in the documents to ensure it is clear that the steps are 1) create
a set 2) grant permissions to that set, and that grant/revoke will have
untoward results; and add language to the document as a hint to developers
that UIs make crystal clear how "blocked users" will be handled in the rules
engine (i.e. "excepted from every grant").
			regards,
				Ted Hardie