With regard to the question below, I think that there are some corner
cases regarding authorization sharing that we will probably need to
discuss. I am concerned that trying to solve the corner cases for
non-transparent failover (either to a replacement or to a parent) are
going to be tricky to get right.
I think that the basic architecture we have is probably a good starting
point. For example, it asserts that in normal operation there is no
such thing as a supervising client (B) with rights to over-write state
created by regular client. I think that introducing such a notion
explicitly would create a lot of complexity.
Note that by using the priority mechanism, such over-riding can be done,
but it will be considered an indication of an exceptional error
condition. Which it seems it is. I think generally having one client
guess what another client was trying to accomplish with a change
(supervision) is simply ripe for trouble.
Yours,
Joel
On 6/12/14, 7:37 PM, Joe Marcus Clarke wrote:
Section 7.5. Would a supervisory application work in this case?
This seems like an implementation detail - and potentially a common one.
However, I'm not sure if it's one we'd want to mandate in the
architecture.
Maybe, but I worry about Client A and Client B not being able to write
to each others state. If Client B is a supervisory app, wouldn't it
need to act as Client A?
_______________________________________________
i2rs mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2rs
