I believe the point of Alia's comment was that something that is
actually one client could behave as if it is multiple clients. It could
have multiple identities it can authenticate. Each of those could be
used with different connections. From the point of view of I2RS this is
multiple clients. From the point of view of the software, it is a single
client with multiple prioritieis. This is a fairly typical
implementation tchnique that keeps protocol simple, while allowing
flexible operation.
Yours,
Joel
On 5/28/15 5:19 AM, Susan Hares wrote:
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
