Joel: I OK with this approach as well - because we can note the reduction in the combined protocol requirements document. We will eventually get to the architecture full scope after getting experience.
Joe - what do you think? Will this work for you? Sue -----Original Message----- From: Joel M. Halpern [mailto:[email protected]] Sent: Thursday, October 15, 2015 4:41 PM To: Susan Hares; 'Joe Clarke'; [email protected] Cc: [email protected]; 'Alia Atlas' Subject: Re: [i2rs] Call for Input from WG: I2RS error handling simplification for initial I2RS protocol Actually Sue, I would strongly prefer NOT to update the archtiecture. My primary reason is stability. My secondary reason is that I believe the working group would still like to see the other behaviors, but is compromising on the protocol delivery. Which is why my email suggested that the protocol document is the right place to clearly state the choice. Yours, Joel On 10/15/15 1:58 PM, Susan Hares wrote: > 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 > _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
