Re: [ogpx] Protocol for permitting policy decisions

[Magnus Zeisig <[e-mail]>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Morgaine, I think I understood your meaning with the first example, and I also think I do it with the second example. And I still see no requirement for your symmetry, or whatever you prefer to call it. Let's recapitulate so people don't need to browse back. An agent using AD1 wants to teleport (TP) from VW1, consisting of AD1 and RD1, to VW2, consisting of AD2 and RD2.

For the TP to happen, AD1 needs to agree to try the TP because it's used by the agent. RD2 needs to accept the TP because it will handle the agent's presence. RD1 should have no say since it will not be used by or handle the agent. AD2 should have no say since it will not be used by or handle the agent. That's my idea of perfect symmetry, but...

Assume that AD1 or RD2 for the reason of "symmetry", or something else, wants AD2 to have a say about the TP. Since AD1 and RD2 are the only entities involved with the agent after TP, they are the only ones who should be able to make that call, except for the agent itself, e.g. if it would like AD2 to act Net-Nanny. Then I believe this is how it should work:

Case 1: Agent (ID1) wants to consult AD2 about TP:

ID1 --(ID1, TP RD2?)-> AD2
AD2 --(ID, <RD2key1?, RD2key2?>)-> RD2
RD2 --(ID, <RD2value1, RD2value2>)-> AD2
AD2 --(ID1, <RD2values OK>, TP RD2 OK)-> ID1
ID1 --(ID1, TP RD2)-> AD1
AD1 --(ID1, <RD2key1?, RD2key2?>)-> RD2
RD2 --(ID1, <RD2value1, RD2value2, AD1key1?, AD1key2?, ID1key1 range?, ID1key2 range?>)-> AD1
AD1 --(ID1, <RD2values OK, AD1value1, AD1value2, ID1keys OK>)-> RD2
RD2 --(ID1, <AD1values OK>, rez cap)-> AD1

Case 2: AD1 wants to consult AD2 about TP:

ID1 --(ID1, TP RD2)-> AD1
AD1 --(ID, TP RD2?)-> AD2
AD2 --(ID, <AD1key1?, AD1key2?, IDkey1 range?, IDkey2 range?>)-> AD1
AD1 --(ID, <AD1value1, AD1value2, IDkeys OK>)-> AD2
AD2 --(ID, <AD1values OK>, TP RD2 OK)-> AD1
AD1 --(ID1, <RD2key1?, RD2key2?>)-> RD2
RD2 --(ID1, <RD2value1, RD2value2, AD1key1?, AD1key2?, ID1key1 range?, ID1key2 range?>)-> AD1
AD1 --(ID1, <RDvalues OK, AD1value1, AD1value2, ID1keys OK>)-> RD2
RD2 --(ID1, <AD1values OK>, rez cap)-> AD1

Case 3: RD2 wants to consult AD2 about TP:

ID1 --(ID1, TP RD2)-> AD1
AD1 --(ID1, <RD2key1?, RD2key2?>)-> RD2
RD2 --(ID, rez cap?)-> AD2
AD2 --(ID, <ADkey1?, ADkey2?, IDkey1 range?, IDkey2 range?>)-> RD2
RD2 --(ID1, <RD2value1, RD2value2, AD1key1?, AD1key2?, ID1key1 range?, ID1key2 range?>)-> AD1
AD1 --(ID1, <RDvalues OK, AD1value1, AD1value2, ID1keys OK>)-> RD2
RD2 --(ID, <ADvalue1, ADvalue2, IDkeys OK>)-> AD2
AD2 --(ID, <ADvalues OK>, rez cap OK)-> RD2
RD2 --(ID1, <AD1values OK>, rez cap)-> AD1

The calling domain or service should never be forced to call more than one (the receiving) domain or service, but it could choose to do so (Cases 1 and 2). What happens behind the endpoint it sees is really none of its business (Case 3).
In cases 2 and 3, much of the extra hand-shaking could be replaced by pre-arranged agreements or duplication of policies, and may also require pre-arranged domains of trust.
The VWRAP protocol may be used for the consulting as well, if it's assumed to have the generalized form suggested in my previous post (http://www.ietf.org/mail-archive/web/ogpx/current/msg00538.html).
The consulting could be made the same way regardless of if the domains or services are controlled by the same entity or not.
Actually, AD2 could be AD3 or service4762, without any administrative connection whatsoever with AD1, RD1 or RD2 (or AD2, if it still exists and forms VW2 with RD2).
Note that the consulting domain or service doesn't have to reveal the identity of the calling agent, domain or service to the consulted domain or service.

Best regards,

Magnus


- -----Ursprungligt meddelande-----
Från: Morgaine [mailto:[e-mail]]
Skickat: den 9 oktober 2009 05:53
Till: Magnus Zeisig
Kopia: [e-mail]
Ämne: Re: [ogpx] Protocol for permitting policy decisions

Magnus, I believe that we're fairly close on everything except the single issue of "symmetry", because you still think that I'm talking about deployment symmetry whereas I'm not at all, I'm talking about definition symmetry.  However, I think I've found another way of expressing it that might come across better --- I'll focus on CODE.  Let's try this new approach instead. :-)

Protocols aren't much use until they have been encoded in programs.  A program that implements a given protocol fully is written to be able to handle all the possible deployment patterns of that protocol.  This allows the program to be used in many different situations to suit local requirements.  Such a program is NOT written to suit one single deployment pattern --- that would be inefficient.  Consequently the code that is written is determined by the definition of the protocol and the definition of the entities in the protocol.  The code that is written is NOT determined by the chosen deployment, I hope that's clear.

So now let's get back to ADs.  We don't want ADs to carry region policy, but let's examine what happens if ADs are defined to do so.

 If ADs are defined to specify region policy, then a program that needs to know about region policy would have to check the ADs --- there is no escaping that.  It would not be protocol-compliant if it did not check the ADs.  The deployment patterns in W1 and W2 (which could be completely different) are of no relevance whatsoever in this --- the program would still have to check for the presence of ADs in both worlds just in case the ADs exist, and all those ADs that exist would have to be queried for region policy because we've defined that region policy is carried by ADs.  If the program did not check both ADs then it could be missing part of the region policy. :-)

See what I mean by definition symmetry now?  However you define an AD, that definition always applies to both ADs in a 2-world deployment if they exist.  The definition can never apply only to one world --- it should be clear that "ADs carry region policies, but the region policies in my AD are valid while the region policies in your AD will be ignored" is completely bogus. :-)  In protocol terms, this would be non-compliant because part of the region policy would be missed.

As a result of this definitional symmetry, the only way we're going to be able to avoid consulting AD2 is our little example scenario is by not allowing ADs to express region policy at all, because if AD1 is allowed to express region policy then AD2 is allowed to express it as well, and hence the program must try to consult AD2 for its region policy, by definition of AD.  It's very strong logic, and it has nothing to do with the chosen deployments, because it applies in case AD2 exists.

Of course, as you pointed out, there are many more realistic deployments out there, but this simple one is all that's needed to invalidate the idea that AD1 can express region policy while AD2 can be present but ignored.  That cannot happen unless the protocol explicitly defines asymmetric relationships, which is not true in our case and cannot be true given that W1 and W2 are peers.

That's all I wanted to describe in this particular reply.  I hope the point was clearer this time. :-)


Morgaine.


-----BEGIN PGP SIGNATURE-----
Version: 9.8.3 (Build 4028)
Charset: utf-8

wsBVAwUBSs8J0O5MlU9XyaiSAQgbNgf+KVMbrtNWtuOgxOWOP3MpNU+xz5q47kNL
LlmK1Chp0b4AVniHYuZ5U7+PprcmFZpkpmU2SAJbUDHLV6aODT607ViyCeIC4vMN
V/OKlD8DDBRaV2suIT6d4QK9TAQ7K3Ln4P/BfEkmj8zPkQfJcrrVRBfWjk+jiQVg
vo0LuifZLFO+vKVBhZhvSNhD0HsQZTrf3OxrYN2Y6Vdsz1ZFd/RaZzQewxAmt7eD
NMBi3WAs4ynXUDz9pZnhPgY1eG7dRrHnzXciaOCm51oHtaDhbxM7ioDctZlySVi7
abItdI5NAWWWkMhXqlL1HcayFjigtHGCgwVQtaluJijmpkwMFkxK8A==
=nHrg
-----END PGP SIGNATURE-----