The architecture does not have a proxy. It only has Clients, who may be
acting on behalf of applications. Those applications are not consider,
by the I2RS system, to be I2RS Clients.
Secondary identity is not a full proxy mode. secondary identities are
not authenticated. They do not have priorities. They are included in
the architecture to ease attribution.
So no, if A and B are applications, working through a common I2RS
client, then their operations are handled by the client. The
requirements only call for the client priority to be assigned to those
operations.
As a nice-to-have, allowing clients to specify different priorities for
different operations is acceptable. But it is not necessary. Remember
that even with different priorities, such collisions are considered
errors. Priority is for giving predictable results. It is not expected
to give the "right" results in terms of application intention.
Yours,
Joel
On 7/14/15 1:57 PM, Jeffrey Haas wrote:
Joel,
On Mon, Jul 13, 2015 at 08:01:21PM -0400, Joel M. Halpern wrote:
On 7/13/15 7:48 PM, Jeffrey Haas wrote:
Gloss: We still haven't concluded our discussion as to whether the nodes are
decorated as "owned by an identity" or "have a priority".
From other discussions, I had assumed nodes had to be decorated with
the owned-by identity. In the case of error, when a given clients
entry is removed due to a higher priority client pre-empting it, the
original client is to be notified of the error. If you don't have
the owner decoration, that is impossible. Having said that, I was
not expecting I2RS to give that owner or priority information back
in any request, so I had always considered it an internal
implementation matter how the associations were stored. Returning
such information in response to a get is a nice-to-have, but is not
to the best of my knowledge an I2RS requirement.
Note that the gloss has an interesting impact. If nodes are expected to get
their priority via identity, this makes things very messy if you don't
maintain multiple identities to have distinct priorities in the proxy case.
I am not sure where the complications comes from. The priority
comes from the client that performed that operation. That identity
needs to be available (as noted above). Secondary identities are
recorded for traceability. Again, whether they are actually with
the node, or only in the log, is not something on which I2RS has
expressed a requirement. The requirement is that the information be
provided in the request, and be logged.
User A has priority 10
User B has priority 20
(20 is better than 10 for discussion)
Per-discussion, owner is the meta data that nodes are decorated with for
priority resolution.
If user A writes state foo to an agent directly, foo is owned by A.
If user B writes state bar to an agent directly, bar is owned by B.
foo and bar have priorities 10 and 20 respectively as a consequence of the
priority system mapping clients to priority.
Proxy example:
A and B write above to some proxy, which needs to carry it to some second
system.
Ignore secondary-identity as that is noise for this example.
In order for the remote system to have foo with priority 10 and bar with
priority 20, since priority is tied to client we will either:
1. Require two distinct client IDs to allow the proxied system to store
something with appropriate tie-breaking.
2. Require the distributing agent to resolve the tie-breakers and simply
install the results itself.
You seem to believe that 2 is what will happen.
However, for multi-headed control, there may be more than one agent proxying
to the remote system. This means that to enforce priority, the priority
needs to carry through to that remote system. That also means that multiple
users are required, even if they are not A and B above - perhaps root10 and
root20.
-- Jeff
_______________________________________________
i2rs mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2rs
