I believe that most of us expect that in I2rs:
Priority is associated with a client.
A client does not get to change its priority (although adminsitrators
clearly can).
When a client performs an operation, the client identity and priority
are recorded both for traceability and for future comparison.
If a later action attempts to modify the same item, the acting client
identity and priority are compared with the stored values.
(While I read the architecture as saying that, I could be too close to
the document.)
Yours,
Joel
On 5/27/15 6:09 PM, Juergen Schoenwaelder wrote:
On Wed, May 27, 2015 at 02:52:39PM -0400, Susan Hares wrote:
[discussion about priority]
. [Jeff]: It is stored in the NACM for client, and the client
identity is tagged to a node (E.g. per route).
This further implies that priority is an attribute that is stored in
the NETCONF Access Control Model [RFC6536
<https://tools.ietf.org/html/rfc6536> ] as part of a rule-list.
E.g.:
+--rw rule-list [name]
+--rw name string
+--rw group* union
+--rw rule [name]
+--rw name string
+--rw module-name? union
+--rw (rule-type)?
| +--:(protocol-operation)
| | +--rw rpc-name? union
| +--:(notification)
| | +--rw notification-name? union
| +--:(data-node)
| +--rw path node-instance-identifier
+--rw access-operations? union
+--rw action action-type
+--rw comment? string
+--rw i2rs:i2rs-priority i2rs-priority-type
I am confused since sometimes it sounds like the priority is a
property of an I2RS client and yet at other times it sounds like the
priority is associated with a scope accessible for an I2RS client.
If I understand Jeff correctly, then he proposes that a data node
remembers the identity of the I2RS client that created / last modified
it and the priority is obtained at the time a confict needs to be
resolved (and hence the priority may be different from the priority
that was in effect when the data node was created / last modified).
Note that NETCONF/RESTCONF so far allows every client with proper
access rights to modify data nodes. There is no notion of ownership in
the sense that if something got written by A then B cannot update it
unless B has higher priority. If A and B have the same priority (which
is so far always the case), then the last write wins. The I2RS
architecture document, however, requires that the first write blocks
any subsequent writes:
remains in effect. In the case of priority ties, the first client
whose attribution is associated with the data will keep control.
If NETCONF/RESTCONF gets extended with ownership and priorities, I
think it would be desirable if the current behaviour (where all
clients have the same priority) would still fall out naturally.
/js
_______________________________________________
i2rs mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2rs
