On Wed, May 27, 2015 at 4:35 PM, Joel M. Halpern <[email protected]> wrote:
> 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.)
>
Sounds right to me.
Jeff suggested in the conf-call that the i2rs-priority can be moved to
the 'group' list.
(I prefer the term 'client-priority').
Although I should be promoting use of NACM, I am not so sure it should
be mandatory for I2RS or required to configure I2RS client priority.
list i2rs-client {
key name;
leaf name {
description "The client name";
type i2rs:client-name;
}
leaf priority {
description "The priority value assigned to this client.";
type i2rs:client-priority;
}
}
I think I2RS interaction with NACM needs to be clearly defined.
NACM implementations do not currently check write requests
on config=false data. It is possible some edits to NACM are needed
even if no objects are added to the data structure.
In either case there is the issue of what happens to existing data if
the client priority is changed by the administrator. Does it keep
the old priority or change to the new priority?
> Yours,
> Joel
Andy
>
> 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
_______________________________________________
i2rs mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2rs
