Re: [ogpx] Protocol for permitting policy decisions

[Meadhbh Hamrick <[e-mail]>]

i think there might be some confusion on what we're using the term
"policy" to mean.

when i use the term with respect to VWRAP, i do not mean a type of
policy like "please, no guns." i mean a policy such as "i (as a region
domain) will only place avatars from this list of agent domains," or
"i will not respond to LLSD messages encoded using the binary
serialization."

so in this sense, policy is not something imposed on you by a third
party, but a collection of decisions you (as a service operator) make
about how your service will behave. this is why i say things like
"domain sets policy," because in many cases, the domain's authority
may make a decision (like "i'm not going to accept MD5 hashed
passwords" or "i won't accept connections from non-authenticated third
parties" that will be global decisions.

that being said, you could have these policies dictated to you by a
third party, perhaps because they're paying you money or offering you
a service. but other than to acknowledge that it might happen, i don't
think it's in our best interest to define a protocol for transporting
policy descriptions between domains. what policies are possible will
differ between implementations, and the purpose of defining them as
part of the policy domain is to explicitly remove them from
negotiation during protocol exchanges.

-cheers
-meadhbh

On Wed, Oct 7, 2009 at 11:12 AM, Vaughn Deluca <[e-mail]> wrote:
> Although I actually think enough has been said on policy,  I want to expand
> my last message a bit to make it even more clear how i view this problem.
> In wrote:
>  "Anything we have said so far on policy in this discussion relates to
> protocol *options*  someone *might* use. None of this will be REQUIRED. The
> protocol will function without using any of it.  So really, as far as i can
> see we *can* move on."
> Here is a longer version of the same message:
> We are talking policy, and by definition, everybody is free to ignore
> policy, and live with the consequences.  If I run a some services in a RD,
> its my choice what  policy i set to determine what is allowed in there. Yet,
> a visiting agent is under *its*  ADs policy if I like that or not. Its the
> agents choice to be in that AD.
> If the policy of that AD is allowing, or even encouraging, the use of deadly
> weapons,  while I like my regions to be free of violence. I can ignore the
> policy of the agents AD. I am free to do so, and apply a policy of "ban on
> the first sight of a gun", after all I run this service. Ignoring the policy
> of the AD may carry the consequence of spoiling my relations with that AD,
> since they strongly belief in the freedom to carry weapons, and this may
> prompt them to prevent any TP to my RD. Yet that is about all thats in the
> power of the AD, unless it has some legal hooks in my service via a real
> world contract with me.
> A more realistic example could be that it is the policy of the AD --or
> rather  some associated asset service *winks to Zha* -- to only let go of
> purple clothes under strict conditions. I have struck a deal with that
> service, promising to follow the rules for purple cloths. Its my choice to
> live by that promise, or -at my peril- ignore it. So to answer one of
> Carlo's older questions, yes, from the perspective of the region service,
> the Asset service policy *can* be forgotten and ignored,  but most likely I
> will prefer not to do so, or I would not have made the deal in the first
> place.
> While all this is very interesting, its  *outside* of the scope of the
> protocol.
> Policy can be ignored, or followed, and its up to those setting the policies
> to enforce them, by whatever means they have at their disposal, but it has
> nothing to do with the protocol as such.
> Infinity is eager to move on, and I fully agree with her. I suddenly
> realised that the source of much of our problems might be that few people
> have made it clear that *whatever* method  we pick to carry  policy related
> information, the use of that information  will *always* be optional, and
> never REQUIRED by protocol.
> I do not think there is a single person on the list that will disagree with
> this, and the chances of getting anything else than this past the IETF are
> in my view remote. [I am new to protocol discussions, but there surly must
> be precedents for this? We can't possibly be the first group to hit this
> obstacle?].
> We can spend a very long time talking about the way to code the policy
> related information, and how explicit it is allowed to be; If it should be
> only payload, or actual part of the control flow; If it may contain actual
> values, or better only ranges. All of that is however somewhat moot as soon
> as it is realised that its *optional* to provide and/or use this info.
> There is not much chance we will gain full or even rough consensus on what
> is appropriate to put in the meta-information, because it depends fully on
> deeply personal value systems. One persons nightmare of a totalitarian state
> is the next persons hope to be free from adult material or unrestrained
> violence.
> The crux is that we realise that the use of anything that will be in the
> protocol relating to policy is optional. If I don't like that info to be
> there, I don't supply it, and ignore it if I find it. Nothing will break in
> protocol terms.
> We could (and probably should) have some discussion how far we want to go in
> facilitating certain use-cases by defining explicit fields to make interop
> easy. Not many will defend a pre-defined field for real-life skin color to
> allow other services more easy discrimination. But *even* if we had the (in
> my eyes) bad taste to define such a field or tag to aid some (in my eyes)
> unacceptable use-case, we are certainly NOT going to REQUIORE its use in the
> protocol, nor saying it MAY NOT be carried ever, since however wrong we
> think such a tag might be, it is a matter of policy, and as such outside the
> scope of the protocol. If we decided in this group that such a tag should be
> forbidden, and MUST NOT be carried we open the gates for demands that other
> tags must also be forbidden. And conversely, if we REQUIRE the use of such a
> tag, we can not prevent others in this discussion to REQUIRE other tags. And
> everything will end in tears.
> I think most (no, *all*) of what i just said  has been mentioned before on
> the list in one form or another, and i really do not think there is much
> more to add that is pertinent to the protocol. I hold  some (strong)
> convictions how meta information should be carried, in particular relating
> to privacy issues, but non of that is crucial, given that i am never forced
> to give this information, nor prevented from using it if somebody is sending
> it.
> That said, if I as a user don't like the choices made by some service, i
> SHOULD be able to pick another with in my view better options, or even run
> one myself. So lets move on, and make that possible!
> -Vaughn
>
>
>
>
>
>
> _______________________________________________
> ogpx mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ogpx
>
>