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

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

Andy: 

I agree that priority in draft-haas-i2rs-ephemeral-state-reqs  links to each NACM rule.  Jeff states in section 5.2  "this priority may vary on a per-node or sub-tree basis based for a  given identity".  

Joel states http://www.ietf.org/mail-archive/web/i2rs/current/msg02522.html states 

"Priority is associated with a client. A client does not get to change its priority (although administrators clearly can)." 

Alia also stated that if an application wants to use an I2RS client to connect with multiple TCP sessions with different priorities, the client should utilize a different identity for each different priority.  With this restriction, each client has 1 priority setting whether or not it utilizes the multiple TCP sessions. 

If we can reach consensus on this point, then we can suggest change to Jeff's document in section 5.2 based on that consensus. If you agree,  my next step is to call for consensus on this point, so we can change Jeff's document based on this consensus.  
 
Sue 
-----Original Message-----
From: Andy Bierman [mailto:[e-mail]] 
Sent: Friday, May 29, 2015 12:47 PM
To: Juergen Schoenwaelder; Susan Hares; [e-mail]; [e-mail]; Andy Bierman; Alia Atlas; Jeffrey Haas; Joel M. Halpern
Subject: Re: [i2rs] draft-chen-i2rs-identifier-management-00

On Fri, May 29, 2015 at 9:25 AM, Juergen Schoenwaelder <[e-mail]> wrote:
> Thanks for all the details but I am missing an answer to my question.
> Shall I repeat it once more?

The proposal is that the priority is a property of each NACM rule.
Since NACM rules can be shared by multiple groups this design will not actually work.  As Martin pointed out, rules common to multiple groups will produce data with the same priority.  It should also be noted that NACM has "default behavior" that is followed even if no rules are actually configured.

IMO priority is associated with the client.
A client can be placed in multiple NACM groups.
When an edit request is made the client does not indicate which group should be used.  The server will pick the highest priority group that the user is a member, and use that for the priority. (Therefore priority is not the property of the group either).

It has been suggested that the client can connect multiple times, and each transport connection will somehow convey a different priority to the server.  I don't see how this will work.  It seems that different client names are needed.  This is true whether NACM or a client mapping table is used.  The system must produce a different client name in order to use a different priority.



>
> /js

Andy

>
> On Fri, May 29, 2015 at 12:03:18PM -0400, Susan Hares wrote:
>> Juergen:
>>
>>
>>
>> Thank you for asking the question again. I appreciate your patience 
>> as I attempt to answer your question carefully.
>>
>>
>>
>> Short answer: I2RS strategy is re-use of other protocols rather than 
>> invent, and this seemed a reasonable place to put it.
>>
>>
>>
>> Context: Jeff's document is a proposal for the requirements for I2RS 
>> to the NETCONF/NETMOD WG on ephemeral state.  Feedback on the earlier 
>> descriptions from the I2RS group had been "too vague" so Jeff's 
>> document is providing detailed requirements.  I2RS is not designing 
>> thing for NETCONF only making known in detailed terms our 
>> requirements to aid the NETCONF group's response on whether the I2RS design requirements can be met.
>>
>>
>>
>> Longer Answer:  His proposal arises out of section 4.2 in the I2RS 
>> architecture document.  This section states:
>>
>>
>>
>> An approach to a similar access control problem is defined in the 
>> NetConf Access Control Model (NACM) [RFC6536]; it allows arbitrary 
>> access to be specified for a data node instance identifier while 
>> defining meaningful manipulable defaults.  The identity within NACM 
>> [RFC6536] can be specifying as either a user name or a group user 
>> name (e.g.  Root), and this name is linked a scope policy that contained in a set of access control rules.
>> Similarly, it is expected the I2RS identity links to one role which 
>> has a scope policy specified by a set of access control rules.  This 
>> scope policy is can be provided via Local Config, exposed as an I2RS Service for
>> manipulation by authorized clients, or via some other method (e.g.   AAA
>> service).
>>
>>
>>
>> You can see in this point that the client identity is being linked to 
>> the scope policy controlling read or write.  Section 7.8 points out 
>> that priority "ensures predictability" in write conditions between 
>> two I2RS Clients trying to write data in one agent, or between an I2RS client and the
>> local config.   Jeff's requirements flow out of these two sections in the
>> architecture document.
>>
>>
>>
>> What you can do: If you have an alternate suggestion for priority for 
>> Jeff's document, please make a suggestion and indicate why you think 
>> it fits within the I2RS architecture document (please list sections).
>>
>>
>>
>> Sue
>>
>>
>>
>> -----Original Message-----
>> From: i2rs [mailto:[e-mail]] On Behalf Of Juergen 
>> Schoenwaelder
>> Sent: Friday, May 29, 2015 2:10 AM
>> To: Susan Hares
>> Cc: [e-mail]; [e-mail]; 'Andy Bierman'; 'Alia Atlas'; 
>> 'Jeffrey Haas'; 'Joel M. Halpern'
>> Subject: Re: [i2rs] draft-chen-i2rs-identifier-management-00
>>
>>
>>
>> On Thu, May 28, 2015 at 08:09:23PM -0400, Susan Hares 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.
>>
>> >
>>
>>
>>
>> So I will ask again: If the priority is a property of the I2RS client 
>> (this is how I understand the I2RS architecture document), why would 
>> it be configured as part of a NACM rule as suggestd in section 5.2 of 
>> draft-haas-i2rs-ephemeral-state-reqs-00? Jeff's design makes the 
>> priority a property of the scope of a NACM group.
>>
>>
>>
>> /js
>>
>>
>>
>> --
>>
>> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
>>
>> Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
>>
>> Fax:   [phone]         < <http://www.jacobs-university.de/>
>> http://www.jacobs-university.de/>
>>
>>
>>
>> _______________________________________________
>>
>> i2rs mailing list
>>
>>  <mailto:[e-mail]> [e-mail]
>>
>>  <https://www.ietf.org/mailman/listinfo/i2rs>
>> https://www.ietf.org/mailman/listinfo/i2rs
>>
>
> --
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   [phone]         <http://www.jacobs-university.de/>