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
