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

[Juergen Schoenwaelder <[e-mail]>]

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