In line toi make sure we keep context.
Yours,
Joel
On 7/13/15 7:48 PM, Jeffrey Haas wrote:
Joel,
On Mon, Jul 13, 2015 at 07:34:42PM -0400, Joel M. Halpern wrote:
To amplify my previous reply on priority, priority is associated
with the I2RS Client. it does not change even if the client is
acting on behalf of multiple secondary identities. (If the use case
requires that variability, use multiple primary identities, with
separate sessions.)
To attempt to reduce this to an example:
Basis case: Multiple clients speaking directly to an agent. Clients have
distinct priorities. Priority causes config to tie-break appropriately
among the various client interactions.
Yes.
Proxy case: Agent is against as "root" from a proxy, potentially with the
a single priority. As long as the proxy maintains the tie-breaking as if it
had implemented the agent operations, it's okay that the resultant nodes may
have the same priority associated with them?
Having the client keep track of what it has modified, and noticing if
there are direct conflicts among the applications it supports is indeed
a way to handle it.
Note that a client acting on behalf of multiple applications needs to
make sure it keeps track of what it has done, and on whose behalf, for
lots of reasons.
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.
There is a good argument for requiring that the secondary identity be
returned with any error notifications, so as to make the broker clients
job more tractable. But I don't think we said that anywhere.
-- Jeff
_______________________________________________
i2rs mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2rs
