Agree to reduce to "all-or-nothing" at current stage. If later we find use cases for the other two modes, they can be added back.
Best regards, Jie > -----Original Message----- > From: i2rs [mailto:[email protected]] On Behalf Of Joel M. Halpern > Sent: Tuesday, October 13, 2015 11:58 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 > > I can live with this reduction. It simplifies the agent implementation (as > it only > has to support one instead of three modes). The increase in effort on the > client is small. If we find out that, as was suspected, there are performance > issues, then we can add back the other error modes. > > Yours, > Joel > > On 10/13/15 4:57 AM, Susan Hares wrote: > > Currently the I2RS requirements have error handling having three parts: > > > > 1)"all-or-nothing", > > > > 2)"continue-on-error", and > > > > 3)"stop-on-error". > > > > To provide an easier first step for the I2RS Agent for the first > > implementation of an I2RS protocol, the I2RS protocol design team > > suggests reduce this to the "all-or-nothing" for the initial version. > > Later versions of the I2RS protocol can provide the "continue-on-error" > > or "stop-on-error" error handling. The earlier decision in the I2RS > > architecture was to support all 3 error handling pieces. > > > > Sue Hares and Jeff Haas > > > > > > > > _______________________________________________ > > 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
