Re: [ogpx] Protocol for permitting policy decisions

[Vaughn Deluca <[e-mail]>]

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