On 10/15/15 18:44, Susan Hares wrote:
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?
Yes. This makes good sense.
Joe
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
