Joel: +1 to Joel's comments. As always, thank you for clarifying my feeble words,
Sue Hares -----Original Message----- From: Joel M. Halpern [mailto:[email protected]] Sent: Thursday, October 15, 2015 4:39 PM To: Joe Clarke; 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 In terms of making clear this constraint, I would expect whatever RFC describes the protocol to be used for I2RS would indicate that although the archtiecture requested the three behaviors, the current protocol only supports "all-or-none." Assuming we can find ways to use NetConf or RestConf, I presume that will be an applicability / usage document rather than a protocol definition document. Yours, Joel On 10/15/15 1:17 PM, Joe Clarke wrote: > 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
