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:[email protected]] On Behalf Of Juergen Schoenwaelder > Sent: Friday, May 29, 2015 2:10 AM > To: Susan Hares > Cc: [email protected]; [email protected]; '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: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > > Fax: +49 421 200 3103 < <http://www.jacobs-university.de/> > http://www.jacobs-university.de/> > > > > _______________________________________________ > > i2rs mailing list > > <mailto:[email protected]> [email protected] > > <https://www.ietf.org/mailman/listinfo/i2rs> > https://www.ietf.org/mailman/listinfo/i2rs > -- 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
