Subject: RE: [Geopriv] RE: [Simple] Changes in xcap-auth

From: "Rosen, Brian" <[email-masked]>
Date: Fri, 7 Nov 2003 10:41:27 -0500

I've been on the receiving end of the "broken record".
I do get it.  I have some sympathy, but not a whole lot.
Basically, I think that "it could be useful", is as
good as you get, because no one has deployment experience.
I think you are guilty of having an implantation in mind
and forcing all requests through the lens of your
implementation.

One possible way to look at this is to observe that the
messages sent could express something that is compact,
where the implementation expands the message to a more
explicit set of rules.  In this example IF (big if)
you have a list of users, you could have an arbitrarily
complex set of AND/OR/EXCEPT/... operations, as long
as the result was reducible to a set of users with
the permission.  That set could then be stored in your
database.

I do realize that in a sense, this kind of complexity is
just an optimization, and thus subject to elimination
in a first phase implementation.  However, I think
that the likelihood here is that it actually matters
(all of a domain EXCEPT a couple of people).

Brian

> -----Original Message-----
> From: Henning Schulzrinne [mailto:[email-masked]]
> Sent: Friday, November 07, 2003 10:01 AM
> To: Naoko ITO
> Cc: Simple WG; [email-masked]
> Subject: Re: [Geopriv] RE: [Simple] Changes in xcap-auth
> 
> 
> > I think a separate excepton list is very useful, 
> corresponding to the
> > exact concept of 'black list.'
> 
> It is not exactly a black list, although it can be used for 
> that. That's 
> why I called it an exception list.
> 
> > Still, I'd like to have an except clause in a permission statment as
> > well, which can be used for a differenct purpose, i.e., giving
> > different permissions to some groups of the watchers.
> 
> I'm sorry to sound like a broken record: People requesting 
> features that 
> break overall processing models should please have the kindness to 
> provide motivation beyond "it could be useful".
> 
> > 
> > I don't understand why the except clause in each permission 
> statement
> > should be dismissed while the separate exception list model can be
> > supported.
> > 
> > 1) introducing a separate exception list but not supporting it,
> > 2) introducing an except clause in each permission but not 
> supporting
> >   it.
> 
> See my other message.
> 
> > 
> > In the case of Option #1, the rule enforcer should drop all the
> > permission statements in the rule set in order to prevent those
> > should-be-excepted watchers from accidentally obtaining 
> information, if
> > there is an exception statement which cannot be understood. i.e., no
> > permission is granted to anybody at all. In the case of 
> Option #2,  the
> > rule enforcer should drop the permission statements with 
> unknown except
> > clauses, which still allows some watchers to obtain information. It
> > seems to me that both options give us the ways to ensure the
> > privacy-safe even if the rule enforcer does not support the except
> > mechanism, and rather the latter is more elastic or 
> fault-tolerant. Or
> > is this just plausible?
> 
> Please review the discussion on why this doesn't work when rules are 
> composed from multiple sources.
> 
> 
> > 
> > As for maintaining the row-model, I don't think the former model
> > maintains the row-model, while the entire rule set has no meaning if
> > the actual rule set once has an exception statement. If it means not
> > supporting the exception at all, the same thing can be done with the
> > except clause in each permission.
> 
> The exception-list model does support the row model. Each rule has 
> exactly one field value for each field, including the URI matching.
> 
> > 
> > I see no reason to dismiss the latter approach and would suggest to
> > keep both.
> 
> If you're in Minneapolis, I'd be glad to explain this in more 
> detail in 
> person, since you couldn't be at the interim meeting, where 
> we went over 
> this for several hours...
> 
> > 
> > Regards,
> > -----
> > Naoko Ito / NEC
> 
> 
> _______________________________________________
> Geopriv mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/geopriv
> 

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

---

From: "Rosen, Brian" <[email-masked]>
Date: Fri, 7 Nov 2003 10:48:41 -0500

oh well. Not enough attention paid to spell check!

implantation = implementation

Sorry

Brian

> From: Rosen, Brian [mailto:[email-masked]]
> Sent: Friday, November 07, 2003 10:41 AM
> To: 'Henning Schulzrinne'; Naoko ITO
> Subject: RE: [Geopriv] RE: [Simple] Changes in xcap-auth
> 
> 
> just an opimization, and thus subject to elimination

---

From: [email-masked]
Date: Fri, 7 Nov 2003 10:34:05 -0800

>and forcing all requests through the lens of your

As just another bozo on this bus, let me say that I
don't think that I have the same lens as Henning (and
certainly don't have the same implementation in mind),
but he and I share some concerns.  I agree with you
that no one has deployment experience for this
and that we will no doubt learn something from that
experience.  I question, though, whether that means
the right choice is "put things in that might be needed"
or "put things in we know we need, then see what we're
missing". 

To take up your point on implementation, I note that
folks do seem to be assuming a connection between
the UI and the protocol behavior.  I can easily see
a UI saying "Grant all buddies civil geolocation data
at City level, except $ex-spouse, who should get
my timezone" and translating that as a grant of
timezone to all buddies and a second grant of
City to each of those that isn't the ex-spouse.  From
the user point of view, it's an "except", where from the
protocol point of view it is additive permissions.

There is no question that there are engineering trade-offs here.
You gain simplicity and have an easy method to
ensure maximal privacy, but you may get increased
object size and you may need to structure group data
in ways that ensure it fits this model reasonably
efficiently.  Neither choice is perfect, but this one
does have some very useful characteristics for a
large number of GeoPriv cases.  There may be other
usage patterns in other uses of XCAP that mean
we can't have a perfect fit, but if we can keep that
split to a minimum, I think it's worth it.

			regards,
				Ted

---

From: Adam Roach <[email-masked]>
Date: Mon, 10 Nov 2003 14:28:59 -0600

The difficult issue here is knowledge of group membership.

As has been proposed earlier, the correct way to say
"everyone in my buddy list *except* Bob" is to literally
have your client send the list of everyone in your buddy
list except Bob. For this specific example, I can agree
with the approach of "just explicitly grant permissions."

Now, if a user wants to semantically say "everyone in engineering
at my company except Bob," it gets much more difficult.  From a
user perspective in this case, what he needs to say is "everyone
in engineering except Bob." He doesn't care about the underlying
protocol -- that's the behavior he wants, and anything else is
broken.

To make this model work without an "except" clause, my client
would need to have a mechanism to fetch all the engineering
users from the corporate directory, remove Bob from the list
and enumerate the remainder of them in a grant message.

By my reading, this is basically the solution that advocates
of not using "except" would think is correct.

So, if we take that as a forgone conclusion, the real issue
isn't how long does it take to process rules with exceptions;
rather, the question is: who should expand semantic groups
like "engineering?" Does it make sense for the client to
download the entire several-hundred-member list from the server,
clip one user out of it, and then send it back in a different
format, or to send instructions to the server that say, "take
this list, remove this discrete list of elements from it, and
then install every remaining member as a positive rule"?

I think the key here is that you do *not* need to store the
rules as "group with exceptions." If it makes your processing
model work better, you can trivially expand the group and apply
the exceptions when you receive the message at the server -- and
then everything is reduced to the list of positive statements
that is apparently much easier to implement.

Outlawing the ability to say "except" *will* lead to implementations
that do the horrifically high-bandwidth "fetch, prune, and upload"
client-side exceptions that I describe above -- and, if we don't
have any indicated method for that "fetch" phase, then you *will*
end up with multiple, uninteroperable implementations. (Think of
the case where your client [built into the operating system] and your
server are made by the same large corporation that really likes using
its own proprietary directory service. Is that the direction we want
to drive things?)

/a

(With apologies to all the Bobs out there)

> From: Andrew Newton [mailto:[email-masked]]
> Sent: Friday, November 07, 2003 8:15
> To: Naoko ITO
> As I recall:  at the interim meeting in September we were 
> fortunate to 
> have two people in attendance that had implemented similar access 
> systems.  It was their opinion that the 'except' clause adds enough 
> processing to be a scalability concern for even moderately loaded 
> systems.  The fastest systems are able to take a set of rules and 
> process them one after another until there is a hit.
> 
> Naoko ITO wrote:
> > 
> Neither do I.  But in my opinion, both should be dismissed.
> 
> -andy
> 
> 
> Simple mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/simple
>