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
