Re: [ogpx] Protocol for permitting policy decisions

[Morgaine <[e-mail]>]

Vaughn, I like your analysis here.

If rough consensus can be achieved around your point as a design decision, I
think it would remove a large hurdle to progress in regards to filtering and
prohibition semantics.  It would also reduce our workload immensely.

I don't think that I can improve on your analysis, but I can shorten your
wording:

*Policies are only advisary, and not enforced by the protocol.  Failure to
comply with a policy is therefore addressed out of band by non-protocol
means.*

Given this design decision, we would no longer have to worry about semantic
filters and policy blocks which are virtually impossible to get right, and
which would require us to create and manage a *security framework* -- a
major difficulty and source of problems.

Also, this ties in perfectly with what many people have said about "trust
agreements" --- that in the end they come down to courts, lawyers and
contracts, none of which are entities in an IETF protocol which at best
provides authenticated endpoints.

If no such consensus can be found, then I see years of semantic battles
ahead, and in particular a war between those who envisage creating
protocol-enforced prison planets versus those who envisage a metaverse that
by and large operates through emergent behaviour and dynamic consensus, in
the manner of the Internet.


Morgaine.





======================================

On Wed, Oct 7, 2009 at 7:12 PM, Vaughn Deluca <[e-mail]>wrote;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
>
>