On Mon, Jul 13, 2015 at 6:42 PM, Joel M. Halpern <[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. 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 if the server is aware a client id was removed completely? Does that matter for existing data for that client? Yours, > Joel > > Andy > On 7/13/15 9:04 PM, Andy Bierman wrote: > >> >> >> On Mon, Jul 13, 2015 at 4:48 PM, Jeffrey Haas <[email protected] >> <mailto:[email protected]>> 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. >> >> 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? >> >> Gloss: We still haven't concluded our discussion as to whether the >> nodes are >> decorated as "owned by an identity" or "have a priority". >> >> 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. >> >> >> >> OK -- it is becoming clearer now -- in order to support a broker, the >> priority is saved with the node, not the client. >> >> The operator configured priority is really the "best allowed". >> Let's say lower priorities are better, and client A is assigned the >> value 10. That means client A is allowed to use priorities 10 .. 255. >> >> Each edit from client A can have a priority that is associated with >> the secondary client. >> >> <rpc> >> <edit-config> >> <target><ephemeral /></target> >> <config> ... </config> >> <secondary-identity>app27</secondary-identity> >> <priority>42</priority> >> </edit-config> >> </rpc> >> >> An error is returned if <priority> is 9 or lower in this example. >> >> IMO this is better than requiring client A to open a session as a >> different user name for each priority value needed. >> >> >> >> -- Jeff >> >> >> >> Andy >> >>
_______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
