Re: [i2rs] draft-chen-i2rs-identifier-management-00

["Susan Hares" <[e-mail]>]

Andy: 

Just to clarify is this an a

  "That is an optional mode [of NACM]. There is also a local users table
that can be used."   Can you provide an example?  Is this an alternate
proposal to Jeff's proposal on NACM? 

 Sue Hares

-----Original Message-----
From: i2rs [mailto:[e-mail]] On Behalf Of Andy Bierman
Sent: Thursday, May 28, 2015 8:23 PM
To: Susan Hares
Cc: [e-mail]; [e-mail]; Juergen Schoenwaelder; Alia Atlas;
Jeffrey Haas; Joel M. Halpern
Subject: Re: [i2rs] draft-chen-i2rs-identifier-management-00

On Thu, May 28, 2015 at 5:09 PM, Susan Hares <[e-mail]> wrote:
> Andy:
>
> Thank you for your question.  Let me precise.
>
> Jeff proposes that clients specify the priority mechanism is an attribute
that is stored in the NACM list on the agent (see Section 5.2 as described
in the draft-haas-i2rs-ephemeral-state-reqs-00 (quoted below).   The
client-Agent identities are load in a mechanism which is out-of-band from
the I2RS protocol these values.  Into the Client, the Agent's ID is loaded.
Into the Agent, the valid client's identity is loaded along with the
client's priority.  AAA (Radius/Diameter) is an example of an out-of-band
mechanism to pass the information with.  IMU (in my understanding), the NACM
on the agent is created based on this AAA loading.  The i2rs secondary
identity is loaded via an edit-config mechanism in a config operation (see
section 5.1 of Jeff's document.).  Please let me know if my understanding of
NACM creation based on AAA input is correct.
>

That is an optional mode.
There is also a local users table that can be used.

[Sue]: You mean this is an optional mode of NACM?  Can you give me a
reference for the local users table?  Is it RFC6536 in section 2.5 where a
configurable set of users can be defined, and linked to a NACM (section
3.1.1)?  Can you provide an example  how the local users table could be
used? 


> I2RS Module Nodes (E.g. I2RS RIB routes) are written within an Agent will
be annotated with meta-data with the client-id, priority, and secondary ID.
>
> The only proposed change to section 5.2 requirements is to the 
> sentence "Additionally, during commit processing, if
>    nodes are found where i2rs-priority is already present, and the
>    priority is better than the transaction's user's priority for that
>    node, the commit SHALL fail.
>
> " Additionally, during commit processing" is incorrect because there is
not commit processing.   Jeff stated we are still working with both NETCONF
and RESTCONF - so we must allow for a commit process.  In the meeting I
noted that the architecture indicates a change is possible only if the
priority is greater than (>) existing priority.  (First rather than last).
Therefore this text should read:  "Additionally, during the operation
(RESTCONF)/Commit (NETCONF) processing, if the nodes are found where
i2rs-priority is already present, and the priority is equal to or better
than the transaction's user's priority for the node, the operation/commit
SHALL fail."
>
> Do you have any suggestions for modifications to section 5 of Jeff's
document?
>
> Sue
>
> ============================
> Jeff's document 5.2 states:
>
>   To support Multi-Headed Control, I2RS requires that there be a
>    decidable means of arbitrating the correct state of data when
>    multiple clients attempt to manipulate the same piece of data.  This
>    is done via a priority mechanism with the highest priority winning.
>    This priority may vary on a per-node or sub-tree basis based for a
>    given identity.
>
>    This further implies that priority is an attribute that is stored in
>    the NETCONF Access Control Model [RFC6536] as part of a rule-list.
>    E.g.:
>
>    Ephemeral configuration state nodes that are created or altered by
>    users that match a rule carrying i2rs-priority will have those nodes
>    annotated with metadata.  Additionally, during commit processing, if
>    nodes are found where i2rs-priority is already present, and the
>    priority is better than the transaction's user's priority for that
>    node, the commit SHALL fail.  An appropriate error should be returned
>    to the user stating the nodes where the user had insufficient
>    priority to override the state.
>


The last paragraph sounds like some nodes will be accepted and others
rejected.
If any nodes are rejected, the entire edit should be rejected.

I don;t think the rule-list should store the client priority.
It should be in the 'group' list, or outside NACM completely.


Andy

>
>
> -----Original Message-----
> From: Andy Bierman [mailto:[e-mail]]
> Sent: Thursday, May 28, 2015 7:40 PM
> To: Susan Hares
> Cc: Juergen Schoenwaelder; Joel M. Halpern; Jeffrey Haas; 
> [e-mail]; [e-mail]; Alia Atlas
> Subject: Re: [i2rs] draft-chen-i2rs-identifier-management-00
>
> On Thu, May 28, 2015 at 4:22 PM, Susan Hares <[e-mail]> wrote:
>> Andy:
>>
>> Yes - the client with priority and secondary identity are inherently
simple additions.   Can you confirm my understanding below based on Jeff's
document?
>>
>
> Not sure what you mean.
> i don't think the client should provide the priority in request messages.
> This is configured on the agent, not requested by the client.
>
>
>> Can you explain  your statement "I do not want to change NETCONF or
RESTCONF to use client priority?"  What are you proposing that you do not
want to add the NACM list the priority?
>
> I don't want to change NETCONF and RESTCONF so that config=true objects
use priority.  Only I2RS should use it.
>
>>
>> Sue
>
> Andy
>
>> ===============
>>
>> Example
>> ------------------------
>> 1) any multiple TCP sessions from a client application will use a
different ID if they want a different priority for write of an object
>>              Application 1:  TCP session 1 -  priority 1,
secondary-identity  "pub-sub monitor"
>>              Application 1:  TCP session 2 - priority 10,
secondary-identity "tracing monitor"
>>         Application 1:  TCP session 3 -  priority 20, opaque "Weekly
config"
>>         Application 1:  TCP session 4 -  priority 55, opaque "Emergency
config"
>>
>> Jeff's META-data  example:
>>
>>   <foo xmlns:i2rs="https://ietf.example.com/i2rs"
>>         i2rs:i2rs-secondary-identity="user1" i2rs:i2rs-priority="47">
>>        ...
>>    </foo>
>>
>> For my example TCP session 1
>>    <foo xmlns:i2rs="http:s//ietf.example.com/i2rs"
>>         I2rs:i2rs-secondary-identity="pub-sub montior"
>> i2rs:i2rs-priority="1">
>>
>> Juergen's client example:
>>
>>     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;
>>       }
>>     }
>>
>>    +--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
>>
>> Are you proposing something different than Jeff's proposal?
>>
>> Sue
>>
>> -----Original Message-----
>> From: Andy Bierman [mailto:[e-mail]]
>> Sent: Thursday, May 28, 2015 11:17 AM
>> To: Juergen Schoenwaelder; Andy Bierman; Joel M. Halpern; Jeffrey 
>> Haas; [e-mail]; [e-mail]; Alia Atlas; Susan Hares
>> Subject: Re: [i2rs] draft-chen-i2rs-identifier-management-00
>>
>> On Wed, May 27, 2015 at 11:05 PM, Juergen Schoenwaelder
<[e-mail]> wrote:
>>> On Wed, May 27, 2015 at 06:04:58PM -0700, Andy Bierman wrote:
>>>>
>>>> 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;
>>>>      }
>>>>   }
>>>
>>> So what is i2rs:client-name - is it any different from a 
>>> NETCONF/RESTCONF username?
>>>
>>
>> Is is probably not different.
>>
>>
>>> NACM maps user names into groups and NACM allows to have the mapping 
>>> supplied by an external source (e.g. RADIUS). If this priority 
>>> mapping is kept separate from NACM, would we need to provision means 
>>> to get the priority from AAA as well?
>>>
>>
>> My point showing the 2 item list is that the information needed to
implement I2RS client priority is rather trivial.
>> It can certainly be made really complicated by the IETF, but it is an
inherently trivial configuration.
>>
>>> And the bigger question: Do we create something specific for I2RS or 
>>> are we going to extend the generic YANG/NC/RC framework to provide 
>>> the tools I2RS needs? This is probably a question the NETCONF WG has 
>>> to answer.
>>
>> It is good to make reusable features.
>> I don't want to change NETCONF or RESTCONF to use client priority.
>> Let I2RS prove it is useful first.  I am not convinced it will really
help.
>> It seems like an implementation detail that is being turned into ad
administrative task.  If multiple clients from multiple vendors are stepping
on each other, then the likely outcome of a priority change by the
administrator will be to select which clients should continue working and
which should be broken.
>>
>>
>>>
>>> /js
>>>
>>
>> Andy
>>
>>> --
>>> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
>>> Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
>>> Fax:   [phone]         <http://www.jacobs-university.de/>
>>
>> _______________________________________________
>> i2rs mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/i2rs
>

_______________________________________________
i2rs mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/i2rs