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

[Andy Bierman <[e-mail]>]

On Fri, May 29, 2015 at 9:40 AM, Susan Hares <[e-mail]> wrote:
> 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?
>

Actually the local user table is in ietf-system.yang:
http://www.netconfcentral.org/modules/ietf-system/2014-08-06#user.659

The 'user-name' leaf-list in the NACM 'group' list is populated by
the administrator.  The actual values are irrelevant to NACM.
They can be local users, Radius, or anything else.  Adding a user-name
to this list does not in any way enable the server to accept sessions
from that user.  This is outside the scope of NACM.


>  Sue Hares

Andy

>
> -----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
>