Re: [ogpx] Protocol for permitting policy decisions

[Morgaine <[e-mail]>]

On Fri, Oct 9, 2009 at 10:43 AM, Magnus Zeisig <[e-mail]> wrote:

>
> Morgaine, I think I understood your meaning with the first example, and I
> also think I do it with the second example.
>


Cool.  :-)   I'll assume the point's taken then.  If any doubt seems to
remain then we can beat it into submission in private mails. :-)


Morgaine.





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

On Fri, Oct 9, 2009 at 10:43 AM, Magnus Zeisig <[e-mail]> wrote:

>  -----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]<[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
>
> wsBVAwUBSs8FtO5MlU9XyaiSAQg8HAf8DHf30qo45JVvrYJ6Vv2essw+MJ1Rbkjk
> BA34EazFEnqoR3krpD5ZOJrYVuG7HbUqBOz8Rl7p4l9lWZBkeeWnpeAk40gCHxNP
> 8fE0cCnDT+n5XShzetNPo7H/VskJ3/niXWMrmI295DwErCKInzelkjUaI/9TgiSi
> DOIwoPMQDPzrn3YM6vvBtDODjoTkajNRP+D5++XDE5gyZ3EJacl4KCOMqkz5ai1B
> XUW5osTLTaDiFDF69QtJIwdl8/BTzN1OsUlBCFC+XlaWK2TgSnXMm1DQ8EWk3iHQ
> DJ0VlRWpJJkmQVWZMsrGivjZi2WaeI3YlsxxCTbAeOaM7Jqvc0EPiw==
> =KZF3
> -----END PGP SIGNATURE-----
>
>
>