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 -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 <http://www.jacobs-university.de/> _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
