Joe: Thank you for letting me know the "all-or-nothing" will be workable for you.
The I2RS architecture will be updated to indicate that the initial pass on error handling for the I2RS client will only be required "all-or-nothing", but may do "stop-on-error", or "continue-on-error". My understanding is that the hello, module library, and other mechanisms in netconf/restconf can signal this. Give me about 24 hours to check my answers on signaling support with the NETCONF/RESTCONf methodology for indicating in the NETCONF Hello or modules library with Andy, Kent and other NETCONF/RESTCONF experts. Sue -----Original Message----- From: i2rs [mailto:[email protected]] On Behalf Of Joe Clarke Sent: Thursday, October 15, 2015 1:17 PM To: Susan Hares; [email protected] Cc: [email protected]; 'Alia Atlas' Subject: Re: [i2rs] Call for Input from WG: I2RS error handling simplification for initial I2RS protocol On 10/15/15 11:45, Susan Hares wrote: > Yes - multiple sub-operation in RESTCONF requires a PATCH, and the > burden is on the client to handle the backing out of data in RESTCONF. > You have hit upon the challenge. The I2RS client is bearing the > burden of this back-out instead of the I2RS agent (Netconf "server" concept). > > Do you think this is reasonable to keep the I2RS agents simple? Will > it make the I2RS clients unworkable? I can't answer an behalf of all I2RS Client implementors, but it doesn't seem like an undue burden. It's just critical that they understand that the burden is upon them. How is this decision to be communicated? Will the architecture be updated? I assume that Agent implementors _could_ do the other two error handling techniques if they wanted and advertise this to the Client? Joe _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
