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

[Juergen Schoenwaelder <[e-mail]>]

Thanks for all the details but I am missing an answer to my question.
Shall I repeat it once more?

/js

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