Rob, Current implementations are incomplete asynchronous, because they didn't verify the config as operational and applied.
What is frequently done is to perform additional checks on the intended config that go beyond a syntax check. That is fine, but I have a hard time to consider this to be "hybrid" which suggests something in between asynchronous and synchronous. >From a client perspective an asynchronous server and a hybrid server look the >same. The difference is that the asynchronous one should convey a "finished" >information to the client, while the hybrid would remain in a "trust me babe" >mode forever. Another way to look at hybrids is to consider them "cheating synchronous". Given that the new config may not have been applied at the time of the response to the client. This is worse than the situation before where a missing verify lets the client know that something may still go on. Clients can't tell if servers are cheating :-) Gert Sent from my Apple ][ > On 16 Oct 2015, at 18:44, Robert Wilton <rwil...@cisco.com> wrote: > > > >> On 16/10/2015 14:59, Kent Watsen wrote: >> >>>>> 3. Support for both synchronous and asynchronous configuration >>>>> operations >>>>> >>>>> A. A server may choose to support only synchronous >>>>> configuration >>>>> operations, or only asynchronous configuration operations, >>>>> or >>>>> both synchronous and asynchronous configuration operations >>>>> in >>>>> a client specified per-operation basis. >>>> I think the most common mode *today* is a mix of sync/async, on a >>>> per-object basis. >>> Yes, I agree. >> >> Wait, I think we're talking about different things. Martin, I'm sure that >> internal to a NC/RC server, parts of the intended configuration is >> actually applied synchronously (e.g., a hostname) whereas other parts are >> not (e.g., config for data plane). But that nuance is not currently >> exposed in any way today -right? > I think that today, from what a client sees/experiences, many replies from > netconf servers fits neither the definition of "synchronous configuration > operation" nor "asynchronous configuration operation", but instead, the reply > is somewhere between the two extremes. > > So the question I was trying to raise is whether servers that need to meet > the opstate requirements have to change to strictly comply with the defined > async or sync config operation semantics? E.g. not just adding a > "done-applying" option, but perhaps also adding something along the lines of > a "done-verifying" option. > > Thanks, > Rob > > >> >> What we're talking about here is an ability for a client to request a >> protocol operation (PATCH) to block, or for the "done-applying" >> notification to not be sent, until all that processing of the request is >> complete. This regardless if the request contains a mix of nodes that are >> applied internally sync/async. Makes sense? - or it is something else? > > > >> >> >> >>>>> B. Support for synchronous operations as per the definition of >>>>> "synchronous configuration operation". >>>> Doesn't this follow from A? >>> Yes, possibly. I don't mind if B is deleted. If we do this then I >>> would suggest that we also delete the analogous first sentence of C, and >>> re-introduce the "(see terms)" text in the headline description. >> +1 >> >> >> Kent // as a contributor >> >> >> . > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
