Joel and Juergen: This is my understanding as well. When a client performs an operation, the client identity (primary and secondary) and priority are recorded on the object (E.g. Route for traceability and for future comparison). If later actions change the attempt to change the object, only clients identities (primary and secondary) with greater priority can change it. You are correct that this means the first write wins in I2RS architecture. Alia remembers this was discussed on the list and in I2RS sessions.
Jeff's proposal is that all actions by a client identity have the same priority, and that a client identity in a Transport connection cannot change priority. This is a good starting point. However, in the discussion in the interim session - Alia indicated that the client with multiple Transport connections might have different priorities for the different sessions. Alia - did I understand you correctly? Sue Hares -----Original Message----- From: Joel M. Halpern [mailto:[email protected]] Sent: Wednesday, May 27, 2015 7:35 PM To: Susan Hares; [email protected]; 'Jeffrey Haas'; [email protected]; 'Alia Atlas' Subject: Re: [i2rs] draft-chen-i2rs-identifier-management-00 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
