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: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 <http://www.jacobs-university.de/> _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
