Subject: [netmod] opstate-reqs #6: clarify impact of synchronous vs asynchronous (esp. wrt intended and applied)

From: Kent Watsen <[email-masked]>
Date: Wed, 23 Sep 2015 16:15:41 +0000

Jonathan Hansford writes: The requirements talk about both synchronous and asynchronous systems (1(D), 3, 3(A)) but really only address the behaviour for asynchronous systems. Would it not be worth clarifying the relationship between the intended and applied configurations for synchronous systems (i.e. they are the same), hence there is no need for synchronous requirements equivalent to 1(D) and 3(A)?

Ultimately, I think we need normative text in the "Terminology Section" for a "synchronous system" and "asynchronous system".  Would someone care to take a stab providing these two definitions?

PS: please Reply-All to this thread, rather than post comments on the GitHub issue tracker.

Thanks,
Kent

---

From: Robert Wilton <[email-masked]>
Date: Thu, 24 Sep 2015 14:25:22 +0100

Hi Kent,

On 23/09/2015 17:15, Kent Watsen wrote:
>
> Jonathan Hansford writes: The requirements talk about both synchronous 
> and asynchronous systems (1(D), 3, 3(A)) but really only address the 
> behaviour for asynchronous systems. Would it not be worth clarifying 
> the relationship between the intended and applied configurations for 
> synchronous systems (i.e. they are the same), hence there is no need 
> for synchronous requirements equivalent to 1(D) and 3(A)?
>
> Ultimately, I think we need normative text in the "Terminology 
> Section" for a "synchronous system" and "asynchronous system".  Would 
> someone care to take a stab providing these two definitions?

First stab only, probably needs some tweaking ...

I find that the term "system" is a bit ambiguous in this context. It is 
talking about the NMS, the server, or both together?

Anyway, I've tried to define them relative to the configuration 
operations being performed.

Synchronous configuration operation - A configuration request that the 
server applies synchronously with respect to the client request.  Before 
the server replies back to the client indicating the success or failure 
of the operation it MUST semantically validate the contents of the 
request and update the intended configuration of the target datastore.  
If the request is to the running datastore then the configuration change 
MUST also be applied in the system before the server replies back to the 
client.  The reply to the client indicates whether there are any 
semantic errors or system errors from applying the configuration change.

Asynchronous configuration operation - A configuration request that the 
server applies asynchronously with respect to the client request.  
Before the server replies back to the client indicating the success or 
failure of the operation it MUST semantically validate the contents of 
the request and update the intended configuration of the target 
datastore.  If the request is to the running datastore then the 
configuration change is applied to the system after the server has 
replied back to the client.  The reply to the client only indicates 
whether there are any semantic errors in the configuration change.

Synchronous system - NETCONF/RESTCONF client/server interactions that 
processes all configuration operations as synchronous configuration 
operations.

Asynchronous system - NETCONF/RESTCONF client/server interactions that 
processes all configuration operations as asynchronous configuration 
operations.

Thanks,
Rob

> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod

---

From: Andy Bierman <[email-masked]>
Date: Thu, 24 Sep 2015 11:22:07 -0700

Hi,

I find this exercise to classify servers as synchronous or asynchronous
mostly useless.
We have both types of instrumentation in our server. They can be different
on a per-node basis.  They can both take a long time or both be instant,
depending
on the instrumentation code the vendor writes.

In any case, the server does not know if the instrumentation has finished
making
the network behave according to the new edit.  That would be new
functionality that
no vendor supports at this time.  Currently servers return "ok" if the edit
is accepted
into the running datastore.  There are no other semantics wrt/ returning
"ok".

Even something as simple as "set the log-level" could be centralized or
distributed.
So every single leaf is a separate case and every single implementation of
every leaf
is a separate case.  It is completely implementation-dependent.  One
platform may
take a long time and another from the same vendor may not, for the exact
same leaf.

So instead of talking about the entire server being sync or async, we need
to
talk about a specific implementation of a specific leaf, and not try to
generalize
and simplify the problem.

Andy

On Thu, Sep 24, 2015 at 6:25 AM, Robert Wilton <[email-masked]> wrote:

> Jonathan Hansford writes: The requirements talk about both synchronous and
> asynchronous systems (1(D), 3, 3(A)) but really only address the behaviour
> for asynchronous systems. Would it not be worth clarifying the relationship
> between the intended and applied configurations for synchronous systems
> (i.e. they are the same), hence there is no need for synchronous
> requirements equivalent to 1(D) and 3(A)?
>
> Ultimately, I think we need normative text in the "Terminology Section"
> for a "synchronous system" and "asynchronous system".  Would someone care
> to take a stab providing these two definitions?
>
>
> Anyway, I've tried to define them relative to the configuration operations
> being performed.
>
> the server replies back to the client indicating the success or failure of
> the operation it MUST semantically validate the contents of the request and
> update the intended configuration of the target datastore.  If the request
> is to the running datastore then the configuration change MUST also be
> applied in the system before the server replies back to the client.  The
> reply to the client indicates whether there are any semantic errors or
> system errors from applying the configuration change.
>
> server applies asynchronously with respect to the client request.  Before
> the server replies back to the client indicating the success or failure of
> the operation it MUST semantically validate the contents of the request and
> update the intended configuration of the target datastore.  If the request
> is to the running datastore then the configuration change is applied to the
> system after the server has replied back to the client.  The reply to the
> client only indicates whether there are any semantic errors in the
> configuration change.
>
> netmod mailing [email-masked]://www.ietf.org/mailman/listinfo/netmod
>
>
>

---

From: Robert Wilton <[email-masked]>
Date: Mon, 28 Sep 2015 18:10:53 +0100

Hi Andy,

On 24/09/2015 19:22, Andy Bierman wrote:
> Hi,
>
> I find this exercise to classify servers as synchronous or 
> asynchronous mostly useless.
> on a per-node basis.  They can both take a long time or both be 
> instant, depending
> In any case, the server does not know if the instrumentation has 
> finished making
> no vendor supports at this time.  Currently servers return "ok" if the 
> edit is accepted
> into the running datastore.  There are no other semantics wrt/ 
> returning "ok".

I'm not sure whether we agree here, but as stated previously, Sec 5.1 of 
RFC 6241, implies that if the configuration is in the running datastore 
then that configuration is expected to be active on the device.

Certainly I think that some Cisco's devices behave in the spirit of this 
description.  E.g. for a normal configuration commit (via the CLI, but I 
would expect NETCONF to be the same) a configuration commit event would 
not complete unless the configuration was applied and broadly in effect 
in the system.  However, even after the config commit, there may be some 
components that are still processing parts of the config change (e.g. 
ARP subsystem after an IP address change on an interface), and some 
hardware tables may also still be in the process of being programmed.

I think that is just comes down to the definition of what "that 
configuration is expected to be active on the device" means, and how 
that relates to the definition of "applied configuration".

I've been trying to define "applied configuration" to be the same as 
"configuration is expected to be active on the device".  I.e. it is in 
the config system but isn't necessarily applied everywhere.  This 
description appears to be consistent with sec 4.2. para 1 of 
openconfig-netmod-opstate-01 but inconsistent with how "applied 
configuration" is defined in Sec 2 of openconfig-netmod-opstate-01.

The alternative definition of "applied configuration" that is being put 
forward is something along the lines of "programmed absolutely 
everywhere where it needs to be".  But this definition is in conflict 
with the behaviour described in sec 4.2. para 1 of 
openconfig-netmod-opstate-01, where after a NETCONF commit it is 
expected that applied=intended.  Further, under this definition most 
NETCONF/RESTCONF servers would likely be defined as asynchronous (at 
least for some leaves), and not many (if any) servers currently have the 
capability to report "applied configuration" as per this definition.

>
> Even something as simple as "set the log-level" could be centralized 
> or distributed.
> So every single leaf is a separate case and every single 
> implementation of every leaf
> take a long time and another from the same vendor may not, for the 
> exact same leaf.
>
> So instead of talking about the entire server being sync or async, we 
> need to
> talk about a specific implementation of a specific leaf, and not try 
> to generalize

But from a client perspective, I'm not quite sure whether they would 
want to optimise for this case.  E.g. if some of the configuration has 
been applied immediately and some will be handled asynchronously then I 
would imagine that a client might just treat that equivalently to it all 
being handled asynchronously, and hence poll for the applied config leaves.

Hence your suggestion feels like an optimization to me, a nice to have, 
but I don't currently see that it is required.

In summary, I think that the two main issues that need to be resolved 
w.r.t to the requirements, which are:
(1) What does applied-config actually mean?

(2) What does it mean when an existing NETCONF/RESTCONF commit completes 
(which I see as depending on the definition of applied-config)?

I expect that the rest of the requirements would probably logically 
follow on from these.  It would seem to be beneficial if we could get 
these nailed down before the next meeting on Thursday if at all possible.

Rob

>
>
> Andy
>
>
>
>
>
>
>
> On Thu, Sep 24, 2015 at 6:25 AM, Robert Wilton <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Hi Kent,
>
>>     Jonathan Hansford writes: The requirements talk about both
>>     synchronous and asynchronous systems (1(D), 3, 3(A)) but really
>>     only address the behaviour for asynchronous systems. Would it not
>>     be worth clarifying the relationship between the intended and
>>     applied configurations for synchronous systems (i.e. they are the
>>     same), hence there is no need for synchronous requirements
>>     equivalent to 1(D) and 3(A)?
>>
>>     Section" for a "synchronous system" and "asynchronous system". 
>>     Would someone care to take a stab providing these two definitions?
>
>     I find that the term "system" is a bit ambiguous in this context. 
>     It is talking about the NMS, the server, or both together?
>
>     Synchronous configuration operation - A configuration request that
>     the server applies synchronously with respect to the client
>     request.  Before the server replies back to the client indicating
>     the success or failure of the operation it MUST semantically
>     validate the contents of the request and update the intended
>     configuration of the target datastore.  If the request is to the
>     running datastore then the configuration change MUST also be
>     applied in the system before the server replies back to the
>     Asynchronous configuration operation - A configuration request
>     that the server applies asynchronously with respect to the client
>     request.  Before the server replies back to the client indicating
>     the success or failure of the operation it MUST semantically
>     validate the contents of the request and update the intended
>     configuration of the target datastore.  If the request is to the
>     running datastore then the configuration change is applied to the
>     system after the server has replied back to the client. The reply
>     to the client only indicates whether there are any semantic errors
>     in the configuration change.
>
>     Synchronous system - NETCONF/RESTCONF client/server interactions
>     that processes all configuration operations as synchronous
>     configuration operations.
>
>     Asynchronous system - NETCONF/RESTCONF client/server interactions
>     that processes all configuration operations as asynchronous
>     configuration operations.
>
>     Thanks,
>     Rob
>
>
>>
>>
>>     [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>

---

From: Andy Bierman <[email-masked]>
Date: Mon, 28 Sep 2015 10:17:35 -0700

> then that configuration is expected to be active on the device.
I do not agree at all that the running datastore means anything other
than the intended confg.   A new operation is needed to retrieve
the active config vs. the intended config.

Andy

> would expect NETCONF to be the same) a configuration commit event would not
> complete unless the configuration was applied and broadly in effect in the
> system.  However, even after the config commit, there may be some
> components that are still processing parts of the config change (e.g. ARP
> subsystem after an IP address change on an interface), and some hardware
> tables may also still be in the process of being programmed.
>
> configuration is expected to be active on the device" means, and how that
> relates to the definition of "applied configuration".
>
> "configuration is expected to be active on the device".  I.e. it is in the
> config system but isn't necessarily applied everywhere.  This description
> appears to be consistent with sec 4.2. para 1 of
> forward is something along the lines of "programmed absolutely everywhere
> where it needs to be".  But this definition is in conflict with the
> behaviour described in sec 4.2. para 1 of openconfig-netmod-opstate-01,
> where after a NETCONF commit it is expected that applied=intended.
> Further, under this definition most NETCONF/RESTCONF servers would likely
> be defined as asynchronous (at least for some leaves), and not many (if
> any) servers currently have the capability to report "applied
> configuration" as per this definition.
>
>
>
> But from a client perspective, I'm not quite sure whether they would want
> to optimise for this case.  E.g. if some of the configuration has been
> applied immediately and some will be handled asynchronously then I would
> imagine that a client might just treat that equivalently to it all being
> handled asynchronously, and hence poll for the applied config leaves.
>
> I expect that the rest of the requirements would probably logically follow
> on from these.  It would seem to be beneficial if we could get these nailed
> down before the next meeting on Thursday if at all possible.
>
> Rob
>
>
>
>
> Andy
>
>
>
>
>
>
>
>> behaviour for asynchronous systems. Would it not be worth clarifying the
>> relationship between the intended and applied configurations for
>> synchronous systems (i.e. they are the same), hence there is no need for
>> synchronous requirements equivalent to 1(D) and 3(A)?
>>

---

From: Robert Wilton <[email-masked]>
Date: Tue, 29 Sep 2015 15:47:13 +0100

On 28/09/2015 18:17, Andy Bierman wrote:
>
>
> On Mon, Sep 28, 2015 at 10:10 AM, Robert Wilton <[email-masked] 
>>     no vendor supports at this time.  Currently servers return "ok"
>>     if the edit is accepted
>     I'm not sure whether we agree here, but as stated previously, Sec
>     5.1 of RFC 6241, implies that if the configuration is in the
>     running datastore then that configuration is expected to be active
>     on the device.
>
>

If the running datastore only ever means intended config, then I think 
that would imply:

  - existing NETCONF servers should reply immediately after the config 
has been semantically verified + written to the config subsystem before 
the configuration is applied.

  - existing NETCONF servers are logically classified (as per 
openconfig-netmod-opstate) as being asynchronous w.r.t to the config 
requests.

  - the existing NETCONF/RESTCONF protocols has no direct mechanism for 
indicating a failure to apply any configuration leaf, the only way such 
information could be deduced is through related operational state leaves 
or notifications.

Rob

---

From: Nadeau Thomas <[email-masked]>
Date: Tue, 29 Sep 2015 13:56:56 -0400

Robert,

	It seems this discussion has run out of steam and we’ve come to a head on this issue.  
It seems we have some actions we can take based on the list of three bullets below as part of
that conclusion (potentially).  

	Do folks think we are ready to close this issue down officially?

	—Tom

> On Sep 29, 2015:10:47 AM, at 10:47 AM, Robert Wilton <[email-masked]> wrote:
> 
> 
> 
>> On Mon, Sep 28, 2015 at 10:10 AM, Robert Wilton <[email-masked] <mailto:[email-masked]>> wrote:
>> Hi Andy,
>> 
>> 
>>> I find this exercise to classify servers as synchronous or asynchronous mostly useless.
>>> on a per-node basis.  They can both take a long time or both be instant, depending
>>> In any case, the server does not know if the instrumentation has finished making
>>> the network behave according to the new edit.  That would be new functionality that
>>> no vendor supports at this time.  Currently servers return "ok" if the edit is accepted
>>> into the running datastore.  There are no other semantics wrt/ returning "ok".
>> 
>> I'm not sure whether we agree here, but as stated previously, Sec 5.1 of RFC 6241, implies that if the configuration is in the running datastore then that configuration is expected to be active on the device.
>> 
>> 
> If the running datastore only ever means intended config, then I think that would imply:
> 
>  - existing NETCONF servers should reply immediately after the config has been semantically verified + written to the config subsystem before the configuration is applied.
> 
>  - existing NETCONF servers are logically classified (as per openconfig-netmod-opstate) as being asynchronous w.r.t to the config requests.
> 
>  - the existing NETCONF/RESTCONF protocols has no direct mechanism for indicating a failure to apply any configuration leaf, the only way such information could be deduced is through related operational state leaves or notifications.
> 
> Rob
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 30 Sep 2015 08:47:31 +0200

> 	Do folks think we are ready to close this issue down officially?

Tom,

what do you think is the outcome of the discussion? This is not at all
clear to me so how can I say we are done with it...

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Robert Wilton <[email-masked]>
Date: Wed, 30 Sep 2015 10:52:29 +0100

Hi Tom,

I'm not sure that this discussion has completely reached a conclusion 
with regard to how existing netconf servers are defined as behaving.

But my view is that the requirements are well enough understood that we 
can have a useful discussion on the merits of the proposed solutions, 
and that discussing the possible solutions in the meeting on Thursday 
will be more enlightening than spending further time debating the exact 
semantics of the requirements.

Thanks,
Rob

On 29/09/2015 18:56, Nadeau Thomas wrote:
>> On Sep 29, 2015:10:47 AM, at 10:47 AM, Robert Wilton 
>> <[email-masked] <mailto:[email-masked]>> wrote:
>>
>>
>>
>>>     I'm not sure whether we agree here, but as stated previously,
>>>     Sec 5.1 of RFC 6241, implies that if the configuration is in the
>>>     running datastore then that configuration is expected to be
>>>     active on the device.
>>>
>>>
>> has been semantically verified + written to the config subsystem 
>> before the configuration is applied.
>>
>>  - the existing NETCONF/RESTCONF protocols has no direct mechanism 
>> for indicating a failure to apply any configuration leaf, the only 
>> way such information could be deduced is through related operational 
>> state leaves or notifications.
>>
>> Rob
>>

---

From: Kent Watsen <[email-masked]>
Date: Wed, 30 Sep 2015 12:40:32 +0000

What text do we agree to put into draft-chairs-netmod-opstate-reqs?   I maintain that we need definitions for the terms "synchronous" and "asynchronous".  Robert took a stab at defining these terms on the 24th (thanks Robert!), but so far no one has commented on them.   So I don't think we're ready to close this issue yet.

Thanks,
Kent

From: Thomas Nadeau <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, September 29, 2015 at 10:56 AM
To: Robert Wilton <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [netmod] opstate-reqs #6: clarify impact of synchronous vs asynchronous (esp. wrt intended and applied)

Robert,

It seems this discussion has run out of steam and we've come to a head on this issue.
It seems we have some actions we can take based on the list of three bullets below as part of
that conclusion (potentially).

-Tom

On Sep 29, 2015:10:47 AM, at 10:47 AM, Robert Wilton <[email-masked]<mailto:[email-masked]>> wrote:

On Mon, Sep 28, 2015 at 10:10 AM, Robert Wilton <[email-masked]<mailto:[email-masked]>> wrote:
Hi Andy,

Rob

_______________________________________________
netmod mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/netmod

---

From: Kent Watsen <[email-masked]>
Date: Wed, 30 Sep 2015 14:31:59 +0000

[As a contributor]

I find that the term "system" is a bit ambiguous in this context.  It is talking about the NMS, the server, or both together?

[KENT] I believe that we're talking about the NETCONF/RESTCONF/<foo> server, specifically in how it processes update requests.

Anyway, I've tried to define them relative to the configuration operations being performed.

[KENT] Perhaps these could be collapsed if we use the terms "a/synchronous server" ?

Synchronous configuration operation - A configuration request that the server applies synchronously with respect to the client request.  Before the server replies back to the client indicating the success or failure of the operation it MUST semantically validate the contents of the request and update the intended configuration of the target datastore.  If the request is to the running datastore then the configuration change MUST also be applied in the system before the server replies back to the client.  The reply to the client indicates whether there are any semantic errors or system errors from applying the configuration change.

[KENT]  This generally matches my understanding, but here are some thoughts to improve it:

1. I think the language "semantically validate" would exclude an ephemeral datastore.  We could put a qualifier on it, but I think it can be removed entirely as each datastore already has its own semantics around how it processes update requests.

2. I like how you call out the running datastore, but it is somewhat NETCONF-specific.  How about something like "If the request impacts the intended configuration (see term), then..."

3. "applied in the system" seems too open ended, how about this:  "...MUST also be propagated to and processed by the operational components of the server before..." ???

Asynchronous configuration operation - A configuration request that the server applies asynchronously with respect to the client request.  Before the server replies back to the client indicating the success or failure of the operation it MUST semantically validate the contents of the request and update the intended configuration of the target datastore.  If the request is to the running datastore then the configuration change is applied to the system after the server has replied back to the client.  The reply to the client only indicates whether there are any semantic errors in the configuration change.

[KENT] For the most part, my comments on this are the mirror image of the comments made above.   One additional comment though, when reading in the first sentence "with respect to the client" I was thinking that these terms are actually independent of the protocol.  For instance, they could equally well be defined for a system that only had CLI access.  So, in that sense, the word "client" in the first sentence, and client/server elsewhere generally, may be ground for some confusion.

Synchronous system - NETCONF/RESTCONF client/server interactions that processes all configuration operations as synchronous configuration operations.

Asynchronous system - NETCONF/RESTCONF client/server interactions that processes all configuration operations as asynchronous configuration operations.

[KENT] again, maybe we can collapse the number of terms from 4 to 2 by calling these "a/synchronous server" - what do you think?

Thanks again,
Kent

---

From: Robert Wilton <[email-masked]>
Date: Wed, 30 Sep 2015 16:02:59 +0100

Hi Kent,

Just some quick comments inline ...

On 30/09/2015 15:31, Kent Watsen wrote:
> [As a contributor]
>
>
> I find that the term "system" is a bit ambiguous in this context.  It 
> is talking about the NMS, the server, or both together?
>
> [KENT] I believe that we're talking about the NETCONF/RESTCONF/<foo> 
> server, specifically in how it processes update requests.
>
>

Personally, I think that defining the operations is arguably more useful 
because it is feasible that you could have a server that supports both 
sync and async operations and allows the client to choose which 
semantics should be used for a particular request.

> server applies synchronously with respect to the client request.  
> configuration change MUST also be applied in the system before the 
> server replies back to the client.  The reply to the client indicates 
> whether there are any semantic errors or system errors from applying 
> the configuration change.
>
>
> 1. I think the language "semantically validate" would exclude an 
> ephemeral datastore.  We could put a qualifier on it, but I think it 
> can be removed entirely as each datastore already has its own 
> semantics around how it processes update requests.

My aim here is potentially tied to the definition of intended config, 
were I am suggesting that the system has to at least have been checked 
that the request is well formed and any YANG constraints in the data 
model have been met, before it is accepted as intended config, otherwise 
it would be rejected.

>
> 2. I like how you call out the running datastore, but it is somewhat 
> NETCONF-specific.  How about something like "If the request impacts 
> the intended configuration (see term), then..."

Yes your text is better and I agree that we should avoid making the 
description NETCONF specific at all.

>
> 3. "applied in the system" seems too open ended, how about this: 
>  "...MUST also be propagated to and processed by the operational 
> components of the server before..." ???

So my aim here was to tie it back to the definition of "applied 
configuration", but this could probably be expressed in a more direct 
way, e.g. perhaps ".... MUST update the applied configuration in the 
system before the server replies ..."

>
>
>
> Asynchronous configuration operation - A configuration request that 
> the server applies asynchronously with respect to the client request.  
> [KENT] For the most part, my comments on this are the mirror image of 
> the comments made above.   One additional comment though, when reading 
> in the first sentence "with respect to the client" I was thinking that 
> these terms are actually independent of the protocol.  For instance, 
> they could equally well be defined for a system that only had CLI 
> access.  So, in that sense, the word "client" in the first sentence, 
> and client/server elsewhere generally, may be ground for some confusion.

Perhaps rather than "client request" we could just use "config request", 
and rather than "replies back to the client" use "responds to the config 
request" or similar?

> [KENT] again, maybe we can collapse the number of terms from 4 to 2 by 
> calling these "a/synchronous server" - what do you think?

As per my first comment, personally I see this problem as being framed 
around how requests are handled, and besides I think that describing a 
system or server as being sync or async is open to many different 
conflicting interpretations.

Thanks,
Rob

---

From: Mahesh Jethanandani <[email-masked]>
Date: Wed, 30 Sep 2015 16:55:10 -0700

One comment.

> On Sep 30, 2015, at 8:02 AM, Robert Wilton <[email-masked]> wrote:
> 
> Hi Kent,
> 
> Personally, I think that defining the operations is arguably more useful because it is feasible that you could have a server that supports both sync and async operations and allows the client to choose which semantics should be used for a particular request.
> 
> 
>> 
>> 
> My aim here is potentially tied to the definition of intended config, were I am suggesting that the system has to at least have been checked that the request is well formed and any YANG constraints in the data model have been met, before it is accepted as intended config, otherwise it would be rejected.
> 
> 
>> 
> Yes your text is better and I agree that we should avoid making the description NETCONF specific at all.
> 
>> 
> So my aim here was to tie it back to the definition of "applied configuration", but this could probably be expressed in a more direct way, e.g. perhaps ".... MUST update the applied configuration in the system before the server replies …"

If I understand this correctly, we are still talking about “applied configuration” as configuration that has been written to datastore/hardware/line card etc. It does not imply that anything has come out of it, including whether the configuration is usable. That operating configuration (and I just introduced another term) will be reflected by derived state.

Is that true?

> Perhaps rather than "client request" we could just use "config request", and rather than "replies back to the client" use  "responds to the config request" or similar?
> 
>> 
>> 
> As per my first comment, personally I see this problem as being framed around how requests are handled, and besides I think that describing a system or server as being sync or async is open to many different conflicting interpretations.
> 
> Thanks,
> Rob
> 
> 
>> 
>> 
>> Thanks again,
>> Kent
>> 
>> 
>> 
> 

Mahesh Jethanandani
[email-masked]