On Thu, May 28, 2015 at 5:09 PM, Susan Hares <[email protected]> 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. >
That is an optional mode. There is also a local users table that can be used. > 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. > The last paragraph sounds like some nodes will be accepted and others rejected. If any nodes are rejected, the entire edit should be rejected. I don;t think the rule-list should store the client priority. It should be in the 'group' list, or outside NACM completely. Andy > > > -----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
