Re: [ogpx] Protocol for permitting policy decisions

[David W Levine <[e-mail]>]

[e-mail] wrote on 10/08/2009 12:45:56 PM:

[snip]
>
> :) Honestly, I was trying to riff on the thread (AD and RD sharing 
> information about agents to make policy decisions), rather than 
> propose anything. I think an attempt to define a global set of 
> characteristics about users that enable all policy decisions is 
> hopeless - cultures, laws, and individuals are too varied and rich. 
> That leaves pair-wise negotiation and/or trust networks, which IMHO 
> needs to happen *if* there are to be service-level distinctions for 
> most cases anyway.
> 
> What I forgot to say is: on the Web, as you move between sites you 
> accept various terms of service. Attempts to have your browser 
> automatically negotiate with sites over content have been extremely 
> limited - things like the defunct PICS (you tell your browser to 
> allow a third party site to rate the site you intend to visit), or 
> Google's features which block malware/phishing sites (and I believe 
> are used by current browsers as well when you just type a URL). Your
> user-agent (Web browser) does *not* have a built-in lawyer that 
> agrees to a TOS on your behalf, however. (I'm having flashbacks of 
> "Diamond Age" here - is that the right novel?)
> 
> In the VWRAP space, I don't believe your VW agent domain will be 
> capable of doing that in a totally generalized, automated way 
> either... so either it will have some a priori knowledge of the RD 
> via some manner (pair-wise negotiation, trust network, etc), defer 
> to the user to accept the TOS, or simply block access.
> 
> In other words: "Just like the web, except where it's different" once 
again.

> I'm leaning ever more strongly towards David's position that only 
> services should carry expressions of policy, not domains, because in
> the direction in which this discussion is heading there will be no 
> widespread interop at all.
> 
> I need to re-read Meadhbh's drafts to internalize the formal 
> terminology (yeah, my bad), but in my head a "domain" is a 
> deployment model for a set of conceptually related services, but 
> it's the service end-points that exist at the protocol level. We 
> talk about domains as clusters of conceptually related services as a
> crutch so we don't have to enumerate the specific services in each 
> conversation.
> 

I think this last is of the essence. Domains seem to be artifacts which
arise out of deployment patterns and how people may administrate deployed
systems. The clustering of services, the shared policies have very little 
to
do with protocol and a lot to do with how the endpoints implementing the
protocol are deployed. 

I am thinking that the overall model is very much that the protocols are 
the
mechanisms to ensure that the endpoints encoding common services work in 
the
same way, and the policies that specific endpoints apply will define 
bounds
on how the mechanisms are used. I would argue that what we need, therefore
(Once again sounding like a looping mp3) is to ensure we have the right
mechanisms defined in the protocols to permit the range of policies for 
which
we have use cases. 

I also think this ties to why I am pushing back a bit on how we are 
slinging
the phrase "domain" around. If domains actually are reflections of 
deployment patterns, then to a large extent, you need to describe
domains in a way that is closely coupled to specific deployments. If I
assume one deployment pattern and you another, and we each say "agent 
domain"
we end up talking at cross purposes, because our deployment assumptions 
create
domains which have different properties, which we paper over in the 
language 



- David Levine
~ Zha Ewwy