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.
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.
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
_______________________________________________
i2rs mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2rs
