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. I2RS Module Nodes (E.g. I2RS RIB routes) are written within an Agent will be annotated with meta-data with the client-id, priority, and secondary ID. The only proposed change to section 5.2 requirements is to the sentence "Additionally, during commit processing, if nodes are found where i2rs-priority is already present, and the priority is better than the transaction's user's priority for that node, the commit SHALL fail. " Additionally, during commit processing" is incorrect because there is not commit processing. Jeff stated we are still working with both NETCONF and RESTCONF - so we must allow for a commit process. In the meeting I noted that the architecture indicates a change is possible only if the priority is greater than (>) existing priority. (First rather than last). Therefore this text should read: "Additionally, during the operation (RESTCONF)/Commit (NETCONF) processing, if the nodes are found where i2rs-priority is already present, and the priority is equal to or better than the transaction's user's priority for the node, the operation/commit SHALL fail." Do you have any suggestions for modifications to section 5 of Jeff's document? Sue ============================ Jeff's document 5.2 states: To support Multi-Headed Control, I2RS requires that there be a decidable means of arbitrating the correct state of data when multiple clients attempt to manipulate the same piece of data. This is done via a priority mechanism with the highest priority winning. This priority may vary on a per-node or sub-tree basis based for a given identity. This further implies that priority is an attribute that is stored in the NETCONF Access Control Model [RFC6536] as part of a rule-list. E.g.: Ephemeral configuration state nodes that are created or altered by users that match a rule carrying i2rs-priority will have those nodes annotated with metadata. Additionally, during commit processing, if nodes are found where i2rs-priority is already present, and the priority is better than the transaction's user's priority for that node, the commit SHALL fail. An appropriate error should be returned to the user stating the nodes where the user had insufficient priority to override the state. -----Original Message----- From: Andy Bierman [mailto:[email protected]] Sent: Thursday, May 28, 2015 7:40 PM To: Susan Hares Cc: Juergen Schoenwaelder; Joel M. Halpern; Jeffrey Haas; [email protected]; [email protected]; Alia Atlas Subject: Re: [i2rs] draft-chen-i2rs-identifier-management-00 On Thu, May 28, 2015 at 4:22 PM, Susan Hares <[email protected]> wrote: > Andy: > > Yes - the client with priority and secondary identity are inherently simple > additions. Can you confirm my understanding below based on Jeff's document? > Not sure what you mean. i don't think the client should provide the priority in request messages. This is configured on the agent, not requested by the client. > Can you explain your statement "I do not want to change NETCONF or RESTCONF > to use client priority?" What are you proposing that you do not want to add > the NACM list the priority? I don't want to change NETCONF and RESTCONF so that config=true objects use priority. Only I2RS should use it. > > Sue Andy > =============== > > Example > ------------------------ > 1) any multiple TCP sessions from a client application will use a different > ID if they want a different priority for write of an object > Application 1: TCP session 1 - priority 1, secondary-identity > "pub-sub monitor" > Application 1: TCP session 2 - priority 10, secondary-identity > "tracing monitor" > Application 1: TCP session 3 - priority 20, opaque "Weekly config" > Application 1: TCP session 4 - priority 55, opaque "Emergency > config" > > Jeff's META-data example: > > <foo xmlns:i2rs="https://ietf.example.com/i2rs"; > i2rs:i2rs-secondary-identity="user1" i2rs:i2rs-priority="47"> > ... > </foo> > > For my example TCP session 1 > <foo xmlns:i2rs="http:s//ietf.example.com/i2rs" > I2rs:i2rs-secondary-identity="pub-sub montior" > i2rs:i2rs-priority="1"> > > Juergen's client example: > > list i2rs-client { > key name; > leaf name { > description "The client name"; > type i2rs:client-name; > } > leaf priority { > description "The priority value assigned to this client."; > type i2rs:client-priority; > } > } > > +--rw rule-list [name] > +--rw name string > +--rw group* union > +--rw rule [name] > +--rw name string > +--rw module-name? union > +--rw (rule-type)? > | +--:(protocol-operation) > | | +--rw rpc-name? union > | +--:(notification) > | | +--rw notification-name? union > | +--:(data-node) > | +--rw path node-instance-identifier > +--rw access-operations? union > +--rw action action-type > +--rw comment? string > +--rw i2rs:i2rs-priority i2rs-priority-type > > Are you proposing something different than Jeff's proposal? > > Sue > > -----Original Message----- > From: Andy Bierman [mailto:[email protected]] > Sent: Thursday, May 28, 2015 11:17 AM > To: Juergen Schoenwaelder; Andy Bierman; Joel M. Halpern; Jeffrey > Haas; [email protected]; [email protected]; Alia Atlas; Susan Hares > Subject: Re: [i2rs] draft-chen-i2rs-identifier-management-00 > > On Wed, May 27, 2015 at 11:05 PM, Juergen Schoenwaelder > <[email protected]> wrote: >> On Wed, May 27, 2015 at 06:04:58PM -0700, Andy Bierman wrote: >>> >>> Although I should be promoting use of NACM, I am not so sure it >>> should be mandatory for I2RS or required to configure I2RS client priority. >>> >>> list i2rs-client { >>> key name; >>> leaf name { >>> description "The client name"; >>> type i2rs:client-name; >>> } >>> leaf priority { >>> description "The priority value assigned to this client."; >>> type i2rs:client-priority; >>> } >>> } >> >> So what is i2rs:client-name - is it any different from a >> NETCONF/RESTCONF username? >> > > Is is probably not different. > > >> NACM maps user names into groups and NACM allows to have the mapping >> supplied by an external source (e.g. RADIUS). If this priority >> mapping is kept separate from NACM, would we need to provision means >> to get the priority from AAA as well? >> > > My point showing the 2 item list is that the information needed to implement > I2RS client priority is rather trivial. > It can certainly be made really complicated by the IETF, but it is an > inherently trivial configuration. > >> And the bigger question: Do we create something specific for I2RS or >> are we going to extend the generic YANG/NC/RC framework to provide >> the tools I2RS needs? This is probably a question the NETCONF WG has >> to answer. > > It is good to make reusable features. > I don't want to change NETCONF or RESTCONF to use client priority. > Let I2RS prove it is useful first. I am not convinced it will really help. > It seems like an implementation detail that is being turned into ad > administrative task. If multiple clients from multiple vendors are stepping > on each other, then the likely outcome of a priority change by the > administrator will be to select which clients should continue working and > which should be broken. > > >> >> /js >> > > Andy > >> -- >> 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 _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
