On Mon, Jul 13, 2015 at 7:14 PM, Joel M. Halpern <[email protected]> wrote:
> Andy, I am not following your comments. Questions in line below. > Joel > > On 7/13/15 10:07 PM, Andy Bierman wrote: > >> >> >> On Mon, Jul 13, 2015 at 6:42 PM, Joel M. Halpern <[email protected] >> <mailto:[email protected]>> wrote: >> >> The flexibility Jeff has described, and you have commented upon, is >> permitted but not required by (what I understand of) the agreements >> of the WG. If it can be easily done, it seems like a nice thing to >> do. >> >> >> It means the priority, client-ID, and 2nd-id all need to be saved per >> subtree. >> > > per subtree? The client-ID needs to be saved with the changed node. The > secondary ID ought to be saved there, but is not required. If we want to > support variable priority, then we would need to record the priority. > Otherwise, recording the priority is an implementation acceleration, as it > is determinable from the client ID. > If the client creates a list entry then the priority applies to the list node and its descendants -- that's what I mean by subtree, Is the 2nd-id sticky? If /foo is created with 2nd=app21 and it is updated later with a new value, but no 2nd is provided, is the old 2nd reported (as per traceability requirements doc?) Or is the 2nd forgotten by the server as soon as it is logged? So the update edit would have no 2nd-id (as the request specified)? >> What happens if a client priority mapping is deleted or does not exist? >> Does that client just get the worst possible priority or is it an error >> or is all data deleted for that client? >> > > What happens if the client permissions are missing from the AAA? I would > expect the client to get no permissions. Similarly, if the client priority > is missing, the client would get the worst possible priority. > > Getting worst priority seems correct > If we support variable, per-request, priority (limited by the AAA result) > then we need to pick a behavior for when the client omits the value. I > don't care if he gets the worst priority or the best priority he is > permitted (but if we want to support this we should be explicit.) > >> >> What if the server is aware a client id was removed completely? >> Does that matter for existing data for that client? >> > > If the client ID is no longer valid, and if the Agent (not sure what the > server would be) knows that, then the client would no longer be permitted > to perform new operations. I suppose we should write down whether, in ushc > an event, the clients existing operations are removed or the client retains > the ability to remove them. I am inclined to say that they should be > removed, since the client may not currently have an active session, and > presumably woudl fail any new attempt to authenticate. This seems to be > something we should spell out. > > > >> Yours, >> Joel >> >> >> >> Andy >> >> Andy
_______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
