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

[Robert Wilton]

Hi Kent, Gert,

Balazs pointed out, and I agree, that the text about transaction/not 
transactional can equally apply to both synchronous and asynchronous 
configuration operations.


So rather than reproducing this text twice, once for each configuration 
definition, I propose keeping the transactional text out of the 
definition for synchronous/asynchronous configuration operations and 
instead include it as a sub-bullet for the section 3 requirements.  I'll 
send my proposed text for the section 3 requirements on that separate 
email thread.


Hence, I propose that we revert to this text for synchronous 
configuration operation:


Synchronous configuration operation - A configuration request to update
the running configuration of a server that is applied synchronously 
with

respect to the client request.  The server MUST fully attempt to apply
the configuration change to all impacted components in the server,
updating both the server's intended and applied configuration (see 
terms),
before replying to the client.  The reply to the client indicates 
whether there

are any errors in the request or errors from applying the configuration
change.

I agree with the existing proposed text for asynchronous configuration 
operation and also support the proposal to drop the definition of 
synchronous/asynchronous configuration servers if they are not being used.


Thanks,
Rob


On 15/10/2015 18:03, Kent Watsen wrote:

These terms were edited on today's call, resulting in the following text:

Synchronous configuration operation - A configuration request to 
update
the running configuration of a server that is applied 
synchronously with
respect to the client request.  The server MUST fully attempt to 
apply

the configuration change to all impacted components in the server,
updating both the server's intended and applied configuration (see 
terms),

before replying to the client.  This may be transactional or non-
transactional (need terms!).  The transactionality of the operation
may be a server property or specified on as a property.
The reply to the client indicates whether there
are any errors in the request or errors from applying the 
configuration

change.
Asynchronous configuration operation - A configuration request to 
update

the running configuration of a server that is applied asynchronously
with respect to the client request.  The server MUST update its 
intended

configuration (see term) before replying to the client indicating
whether the request will be processed.  This reply to the client only
indicates whether there are any errors in the  original request.  The
server's applied configuration state (see term) is updated after the
configuration change has been fully effected to all impacted 
components
in the server.  Once applied, there MUST be a mechanism for the 
client to

determine when the request has completed processing and whether the
intended config is now fully effective or there are any errors from
applying the configuration change, which could be from an asynchronous
notification or via a client operation.

Synchronous configuration server - a configuration server that 
processes

all configuration operations as synchronous configuration operations.
Asynchronous configuration server - a configuration server that 
processes

all configuration operations as asynchronous configuration operations.


We have consensus on the above, but are hoping for some word-smithing 
before committing it to the draft.  Anybody want to take a crack at it?


BTW, do we still need to define the last two terms anymore?  - they're 
not used elsewhere in the draft...


Kent



From: Gert Grammel <ggram...@juniper.net <mailto:ggram...@juniper.net>>
Date: Thursday, October 15, 2015 at 10:35 AM
To: Robert Wilton <rwil...@cisco.com <mailto:rwil...@cisco.com>>, Kent 
Watsen <kwat...@juniper.net <mailto:kwat...@juniper.net>>, 
"netmod@ietf.org <mailto:netmod@ietf.org>" <netmod@ietf.org 
<mailto:netmod@ietf.org>>
Subject: Re: [netmod] opstate-reqs #6: clarify impact of synchronous 
vs asynchronous (esp. wrt intended and applied)


Rob,

From a client perspective a server has three states:

 1. intended != applied
 2. Funny-state
 3. Intended == applied

Irrespective of synchronous or asynchronous processing in the server, 
the third state MUST be reported to the client. Else (from a client 
perspective) the server stays in funny-state forever.



Gert


From: Robert Wilton <rwil...@cisco.com <mailto:rwil...@cisco.com>>
Date: Thursday 15 October 2015 15:59
To: Gert Grammel <ggram...@juniper.net <mailto:ggram...@juniper.net>>, 
Kent Watsen <kwat...@juniper.net <mailto:kwat...@juniper.net>>, 
"netmod@ietf.org <mailto:netmod@ietf.org>" <netmod@ietf.org 
&l

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

[Kent Watsen]

>>> These terms were edited on today's call, resulting in the following
>>>text:
>>>
>>>  Synchronous configuration operation - A configuration request to
>>>update
>>>  the running configuration of a server that is applied
>>>synchronously with
>>>  respect to the client request.  The server MUST fully attempt to
>>>apply
>>>  the configuration change to all impacted components in the server,
>>>  updating both the server's intended and applied configuration
>>>(see terms),
>>>  before replying to the client.  This may be transactional or non-
>>>  transactional (need terms!).  The transactionality of the
>>>operation
>>>  may be a server property or specified on as a property.
>> I do not understand the transactionality blurb. What is it and why is
>> it relevant? (The last sentence above also seems incomplete.)
>
>It was added in the meeting because some interpretations of the text
>assumed that the text implied that the server would always
>rollback-on-error, so the proposed text was intended to clarify that.
>
>However, I think that this clarification applies equally to both sync
>and async operations and hence I have proposed (on a separate thread)
>that it be documented as part of the requirement 3 "Support for both
>synchronous and asynchronous configuration operations" instead.


So the proposal is to remove the last two sentences? - I'm OK with that.

I think that the new word "attempt" in the previous sentence fixed it to
be (IMO) a very good definition for what is meant by a "synchronous
configuration operation" without it getting mired in details.

Kent

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Kent Watsen]

> Why is there a need to update the intended config?

Because that is what happens via requests like  and PATCH.  The 
intended (running) config gets updated first and then config is distributed to 
internal components, ultimately updated the applied config.

Kent  // as a contributor


From: Gert Grammel <ggram...@juniper.net<mailto:ggram...@juniper.net>>
Date: Friday, October 16, 2015 at 10:16 AM
To: Kent Watsen <kwat...@juniper.net<mailto:kwat...@juniper.net>>
Cc: Robert Wilton <rwil...@cisco.com<mailto:rwil...@cisco.com>>, 
"netmod@ietf.org<mailto:netmod@ietf.org>" 
<netmod@ietf.org<mailto:netmod@ietf.org>>
Subject: Re: [netmod] opstate-reqs #6: clarify impact of synchronous vs 
asynchronous (esp. wrt intended and applied)

Kent,

The new one looks much better. However the last sentence is confusing with 
respect to intended config. Why is there a need to update the intended config?

Proposal:
The server MUST fully attempt to apply
the configuration change to all impacted components in the server,
updating the server's applied configuration (see terms),
before replying to the client.

Sent from my Apple ][

On 16 Oct 2015, at 15:45, Kent Watsen 
<kwat...@juniper.net<mailto:kwat...@juniper.net>> wrote:


Gert writes:
> I don't see the need for defining synchronous/asynchronous config servers.

Thank you (and Juergen) for the confirmation.   Again, if no objections, these 
two terms will not be removed.


> The new definitions look good. Later in the discussion there was a common
> sentiment that the requirement for synchronous operations contained some
> crisp wording we could use here too.  I particularly liked the mentioning of
> blocking requests for some time,

[Note: the following removes the last two sentences on "transactions", as being 
discussed elsewhere on this thread]

OLD:

Synchronous configuration operation - A configuration request to update
the running configuration of a server that is applied synchronously with
respect to the client request.  The server MUST fully attempt to apply
the configuration change to all impacted components in the server,
updating both the server's intended and applied configuration (see terms),
before replying to the client.

NEW

Synchronous configuration operation - A configuration request to update
the running configuration of a server that is applied synchronously with
respect to the client request (i.e. a blocking call).  The server MUST 
fully attempt to apply
the configuration change to all impacted components in the server,
updating both the server's intended and applied configuration (see terms),
before replying to the client.


What do you think?

Kent

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Gert Grammel]

Kent,

The new one looks much better. However the last sentence is confusing with 
respect to intended config. Why is there a need to update the intended config?

Proposal:
The server MUST fully attempt to apply
the configuration change to all impacted components in the server,
updating the server's applied configuration (see terms),
before replying to the client.

Sent from my Apple ][

On 16 Oct 2015, at 15:45, Kent Watsen 
> wrote:


Gert writes:
> I don't see the need for defining synchronous/asynchronous config servers.

Thank you (and Juergen) for the confirmation.   Again, if no objections, these 
two terms will not be removed.


> The new definitions look good. Later in the discussion there was a common
> sentiment that the requirement for synchronous operations contained some
> crisp wording we could use here too.  I particularly liked the mentioning of
> blocking requests for some time,

[Note: the following removes the last two sentences on "transactions", as being 
discussed elsewhere on this thread]

OLD:

Synchronous configuration operation - A configuration request to update
the running configuration of a server that is applied synchronously with
respect to the client request.  The server MUST fully attempt to apply
the configuration change to all impacted components in the server,
updating both the server's intended and applied configuration (see terms),
before replying to the client.

NEW

Synchronous configuration operation - A configuration request to update
the running configuration of a server that is applied synchronously with
respect to the client request (i.e. a blocking call).  The server MUST 
fully attempt to apply
the configuration change to all impacted components in the server,
updating both the server's intended and applied configuration (see terms),
before replying to the client.


What do you think?

Kent

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Gert Grammel]

Juergen,

Rob summarized the discussion well. Since I also have some strange feelings 
about transactions here, my proposal in the other thread was to define the 
state of the config at the time the client is notified.


Gert

Sent from my Apple ][

> On 16 Oct 2015, at 14:19, Robert Wilton  wrote:
> 
> Hi Juergen,
> 
>> On 15/10/2015 22:59, Juergen Schoenwaelder wrote:
>>> On Thu, Oct 15, 2015 at 05:03:33PM +, Kent Watsen wrote:
>>> These terms were edited on today's call, resulting in the following text:
>>> 
>>> Synchronous configuration operation - A configuration request to update
>>> the running configuration of a server that is applied synchronously with
>>> respect to the client request.  The server MUST fully attempt to apply
>>> the configuration change to all impacted components in the server,
>>> updating both the server's intended and applied configuration (see 
>>> terms),
>>> before replying to the client.  This may be transactional or non-
>>> transactional (need terms!).  The transactionality of the operation
>>> may be a server property or specified on as a property.
>> I do not understand the transactionality blurb. What is it and why is
>> it relevant? (The last sentence above also seems incomplete.)
> 
> It was added in the meeting because some interpretations of the text assumed 
> that the text implied that the server would always rollback-on-error, so the 
> proposed text was intended to clarify that.
> 
> However, I think that this clarification applies equally to both sync and 
> async operations and hence I have proposed (on a separate thread) that it be 
> documented as part of the requirement 3 "Support for both synchronous and 
> asynchronous configuration operations" instead.
> 
> Thanks,
> Rob
> 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Kent Watsen]

Thanks Gert.  I've incorporated these suggestions into my notes for today's 
interim meeting.


From: Gert Grammel <ggram...@juniper.net<mailto:ggram...@juniper.net>>
Date: Thursday, October 15, 2015 at 7:17 AM
To: Kent Watsen <kwat...@juniper.net<mailto:kwat...@juniper.net>>, Robert 
Wilton <rwil...@cisco.com<mailto:rwil...@cisco.com>>, 
"netmod@ietf.org<mailto:netmod@ietf.org>" 
<netmod@ietf.org<mailto:netmod@ietf.org>>
Subject: Re: [netmod] opstate-reqs #6: clarify impact of synchronous vs 
asynchronous (esp. wrt intended and applied)

Kent, Rob,

Comparing the cases, the definition of the asynchronous case doesn’t look 
complete. The way it stands for the synchronous operation, the client knows 
that it's intended config was good AND it has been effected to the server. In 
the Asynchronous case, the client only knows that the intended config was good 
– and that’s not enough.

So the proposal is to refine the asynchronous case definition as follows:

Asynchronous configuration operation - A configuration request to update the 
running configuration of a server that is applied asynchronously with respect 
to the client request.  The server MUST update its intended configuration (see 
term) before replying to the client indicating whether the request will be 
processed.  The reply to the client only indicates whether there are any errors 
in the  original request.
The server's applied configuration state (see term) is updated after the 
configuration change has been applied to all impacted components in the server. 
 Once applied, the client MUST be notified whether the intended config is now 
fully effective or there are any errors from applying the configuration change.

In addition I would suggest to require a verify operation which a client can 
request from the server to obtain above information on an on-demand basis. 
Would that somehow go in the opstate-reqs #3 then?

Best

Gert




From: netmod <netmod-boun...@ietf.org<mailto:netmod-boun...@ietf.org>> on 
behalf of Kent Watsen <kwat...@juniper.net<mailto:kwat...@juniper.net>>
Date: Thursday 15 October 2015 00:11
To: Robert Wilton <rwil...@cisco.com<mailto:rwil...@cisco.com>>, 
"netmod@ietf.org<mailto:netmod@ietf.org>" 
<netmod@ietf.org<mailto:netmod@ietf.org>>
Subject: Re: [netmod] opstate-reqs #6: clarify impact of synchronous vs 
asynchronous (esp. wrt intended and applied)

Hi Robert,

One comment, it seems that the asynchronous configuration operation should
have one more sentence at its end saying that an asynchronous notification
must be used to report any errors produced from when applying the
configuration.

What do you think?

Kent  // as a contributor



On 10/14/15, 10:59 AM, "Robert Wilton" 
<rwil...@cisco.com<mailto:rwil...@cisco.com>> wrote:

Hi All,

Are there any more comments on the following proposed descriptions, or
are these descriptions sufficiently clear to update the requirements
draft and resolve issue #6?

Synchronous configuration operation - A configuration request to update
the running configuration of a server that is applied synchronously with
respect to the client request.  The server MUST fully effect the
configuration change to all impacted components in the server, updating
both the server's intended and applied configuration (see terms), before
replying to the client.  The reply to the client indicates whether there
are any errors in the request or errors from applying the configuration
change.

Asynchronous configuration operation - A configuration request to update
the running configuration of a server that is applied asynchronously
with respect to the client request.  The server MUST update its intended
configuration (see term) before replying to the client indicating
whether the request will be processed.  The server's applied
configuration state (see term) is updated after the configuration change
has been fully effected to all impacted components in the server.  The
reply to the client only indicates whether there are any errors in the
original request.

Synchronous configuration server - a configuration server that processes
all configuration operations as synchronous configuration operations.

Asynchronous configuration server - a configuration server that processes
all configuration operations as asynchronous configuration operations.

Thanks,
Rob


On 13/10/2015 09:48, Juergen Schoenwaelder wrote:
On Tue, Oct 06, 2015 at 09:42:37PM +0100, Robert Wilton wrote:
Hi Juergen,

On 06/10/2015 17:16, Juergen Schoenwaelder wrote:
On Tue, Oct 06, 2015 at 02:59:29PM +0100, Robert Wilton wrote:
Hi Kent,

Feeding in the various input, I think that this is the best
refinement
that I've come up with:

Synchronous configuration operation - A configuration request to
update
the running configuration of a server that is applied synchronously
with
respect to the client

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

[Gert Grammel]

Kent,

I don't see the need for defining synchronous/asynchronous config servers.

The new definitions look good. Later in the discussion there was a common 
sentiment that the requirement for synchronous operations contained some crisp 
wording we could use here too.
I particularly liked the mentioning of blocking requests for some time,

Nevertheless the proposed wording works for me.

Gert

Sent from my Apple ][

On 15 Oct 2015, at 19:03, Kent Watsen 
<kwat...@juniper.net<mailto:kwat...@juniper.net>> wrote:

These terms were edited on today's call, resulting in the following text:

Synchronous configuration operation - A configuration request to update
the running configuration of a server that is applied synchronously with
respect to the client request.  The server MUST fully attempt to apply
the configuration change to all impacted components in the server,
updating both the server's intended and applied configuration (see terms),
before replying to the client.  This may be transactional or non-
transactional (need terms!).  The transactionality of the operation
may be a server property or specified on as a property.
The reply to the client indicates whether there
are any errors in the request or errors from applying the configuration
change.

Asynchronous configuration operation - A configuration request to update
the running configuration of a server that is applied asynchronously
with respect to the client request.  The server MUST update its intended
configuration (see term) before replying to the client indicating
whether the request will be processed.  This reply to the client only
indicates whether there are any errors in the  original request.  The
server's applied configuration state (see term) is updated after the
configuration change has been fully effected to all impacted components
in the server.  Once applied, there MUST be a mechanism for the client to
determine when the request has completed processing and whether the
intended config is now fully effective or there are any errors from
applying the configuration change, which could be from an asynchronous
notification or via a client operation.

Synchronous configuration server - a configuration server that processes
all configuration operations as synchronous configuration operations.

Asynchronous configuration server - a configuration server that processes
all configuration operations as asynchronous configuration operations.


We have consensus on the above, but are hoping for some word-smithing before 
committing it to the draft.  Anybody want to take a crack at it?

BTW, do we still need to define the last two terms anymore?  - they're not used 
elsewhere in the draft...

Kent



From: Gert Grammel <ggram...@juniper.net<mailto:ggram...@juniper.net>>
Date: Thursday, October 15, 2015 at 10:35 AM
To: Robert Wilton <rwil...@cisco.com<mailto:rwil...@cisco.com>>, Kent Watsen 
<kwat...@juniper.net<mailto:kwat...@juniper.net>>, 
"netmod@ietf.org<mailto:netmod@ietf.org>" 
<netmod@ietf.org<mailto:netmod@ietf.org>>
Subject: Re: [netmod] opstate-reqs #6: clarify impact of synchronous vs 
asynchronous (esp. wrt intended and applied)

Rob,

>From a client perspective a server has three states:

  1.  intended != applied
  2.  Funny-state
  3.  Intended == applied

Irrespective of synchronous or asynchronous processing in the server, the third 
state MUST be reported to the client. Else (from a client perspective) the 
server stays in funny-state forever.


Gert


From: Robert Wilton <rwil...@cisco.com<mailto:rwil...@cisco.com>>
Date: Thursday 15 October 2015 15:59
To: Gert Grammel <ggram...@juniper.net<mailto:ggram...@juniper.net>>, Kent 
Watsen <kwat...@juniper.net<mailto:kwat...@juniper.net>>, 
"netmod@ietf.org<mailto:netmod@ietf.org>" 
<netmod@ietf.org<mailto:netmod@ietf.org>>
Subject: Re: [netmod] opstate-reqs #6: clarify impact of synchronous vs 
asynchronous (esp. wrt intended and applied)

Hi Gert, Kent,

I think that notifying the client is one possible way that an asynchronous 
request could be completed, but not necessarily the only way.  E.g. if the 
information as to whether a particular intended leave had been successfully 
applied was available (e.g. as per github issue #2).

So, I wonder whether we shouldn't weaken the last sentence, changing MUST to 
COULD, or perhaps reword it.:

E.g. replacing:

Once applied, the client MUST be notified whether the intended config is now 
fully effective or there are any errors from applying the configuration change.

Perhaps with:

Once applied, the client COULD be notified whether the intended config is now 
fully effective or there are any errors from applying the configuration change.

Or:

Once applied, there MUST be a mechanism avai

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

[Kent Watsen]

>Anyway, as long as a regular NC/RC server does not have to pay a price
>for this applied config idea, I have no real problem with this since I
>am sure the market will sort this out.

This goes to the solution - that it should allow servers to opt-in to
support applied config.

I have also been thinking about market response.  It is a bit frustrating
to even think that solution might not be widely popular, but the reality
is that I don't see how it can be widely implemented - and so maybe it
will only be popular for datacenter operators?

Kent // as a contributor


___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Robert Wilton]

Hi All,

Are there any more comments on the following proposed descriptions, or
are these descriptions sufficiently clear to update the requirements
draft and resolve issue #6?

Synchronous configuration operation - A configuration request to update
the running configuration of a server that is applied synchronously with
respect to the client request.  The server MUST fully effect the
configuration change to all impacted components in the server, updating
both the server's intended and applied configuration (see terms), before
replying to the client.  The reply to the client indicates whether there
are any errors in the request or errors from applying the configuration
change.

Asynchronous configuration operation - A configuration request to update
the running configuration of a server that is applied asynchronously
with respect to the client request.  The server MUST update its intended
configuration (see term) before replying to the client indicating
whether the request will be processed.  The server's applied
configuration state (see term) is updated after the configuration change
has been fully effected to all impacted components in the server.  The
reply to the client only indicates whether there are any errors in the
original request.

Synchronous configuration server - a configuration server that processes
all configuration operations as synchronous configuration operations.

Asynchronous configuration server - a configuration server that processes
all configuration operations as asynchronous configuration operations.

Thanks,
Rob


On 13/10/2015 09:48, Juergen Schoenwaelder wrote:

On Tue, Oct 06, 2015 at 09:42:37PM +0100, Robert Wilton wrote:

Hi Juergen,

On 06/10/2015 17:16, Juergen Schoenwaelder wrote:

On Tue, Oct 06, 2015 at 02:59:29PM +0100, Robert Wilton wrote:

Hi Kent,

Feeding in the various input, I think that this is the best refinement
that I've come up with:

Synchronous configuration operation - A configuration request to update
the running configuration of a server that is applied synchronously with
respect to the client request.  The server SHOULD ensure that the
request is valid, and MUST fully effect the configuration change to all
impacted components in the server, updating both the server's intended
and applied configuration (see terms), before replying to the client.
The reply to the client indicates whether there are any errors in the
request or errors from applying the configuration change.

What does "SHOULD ensure that the request is valid" mean? RFC 6020
says:

When datastore processing is complete, the final contents MUST obey
all validation constraints.  This validation processing is performed
at differing times according to the datastore.  If the datastore is
 or , these constraints MUST be enforced at the
end of the  or  operation.  If the
datastore is , the constraint enforcement is delayed
until a  or  operation.

Are we talking about datastore validation or validation of a request?
If the former, are we watering down a MUST to a SHOULD?

Really it is datastore validation, particularly for an async request
where the intended config nodes are updated before replying. I'm not
intentionally trying to water down a MUST to a SHOULD, but Kent had
concerns that my previous description using "semantically validate"
would exclude an ephemeral datastore, so I was trying to water down the
description and also describe the behaviour in a way that isn't specific
to either RESTCONF/NETCONF or datastores.

Perhaps, the start of sentence could simply be changed to:

The server MUST fully effect the configuration change to all
impacted components in the server ...

And equivalently for the asynchronous case below:

The server MUST update the server's intended configuration ...


Works for me. Sometimes less is more.


And I would not be surprised if we also need this sooner or later:

   Mixed configuration server - a configuration server that processes
   some configuration operations as synchronous configuration
   operations and some configuration operations as asynchronous
   configuration operations.

Yes, I would expect that clients may want to define the expected
behaviour, potentially on a per request basis.

I doubt that servers will offer clients to choose; I am more with Andy
that in real systems, depending on the data model, certain parts of a
data model may be synchronous while others may be asynchronous.


Any further comments?

Based on the feedback from Andy and others, it seems that the prevailing
view is that existing NETCONF and RESTCONF should be regarded as being
asynchronous in their behaviour in that the config nodes in the running
datastore only represent the intended configuration and not the applied
configuration.

Depends on the definition of applied configuration - where is the latest
version of it?

The last proposed text for intended/applied is as below:

   intended configuration - this data represents the 

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

[Juergen Schoenwaelder]

On Tue, Oct 06, 2015 at 09:42:37PM +0100, Robert Wilton wrote:
> Hi Juergen,
> 
> On 06/10/2015 17:16, Juergen Schoenwaelder wrote:
> >On Tue, Oct 06, 2015 at 02:59:29PM +0100, Robert Wilton wrote:
> >>Hi Kent,
> >>
> >>Feeding in the various input, I think that this is the best refinement
> >>that I've come up with:
> >>
> >>Synchronous configuration operation - A configuration request to update
> >>the running configuration of a server that is applied synchronously with
> >>respect to the client request.  The server SHOULD ensure that the
> >>request is valid, and MUST fully effect the configuration change to all
> >>impacted components in the server, updating both the server's intended
> >>and applied configuration (see terms), before replying to the client.
> >>The reply to the client indicates whether there are any errors in the
> >>request or errors from applying the configuration change.
> >What does "SHOULD ensure that the request is valid" mean? RFC 6020
> >says:
> >
> >When datastore processing is complete, the final contents MUST obey
> >all validation constraints.  This validation processing is performed
> >at differing times according to the datastore.  If the datastore is
> > or , these constraints MUST be enforced at the
> >end of the  or  operation.  If the
> >datastore is , the constraint enforcement is delayed
> >until a  or  operation.
> >
> >Are we talking about datastore validation or validation of a request?
> >If the former, are we watering down a MUST to a SHOULD?
> Really it is datastore validation, particularly for an async request 
> where the intended config nodes are updated before replying. I'm not 
> intentionally trying to water down a MUST to a SHOULD, but Kent had 
> concerns that my previous description using "semantically validate" 
> would exclude an ephemeral datastore, so I was trying to water down the 
> description and also describe the behaviour in a way that isn't specific 
> to either RESTCONF/NETCONF or datastores.
> 
> Perhaps, the start of sentence could simply be changed to:
> 
> The server MUST fully effect the configuration change to all
> impacted components in the server ...
> 
> And equivalently for the asynchronous case below:
> 
> The server MUST update the server's intended configuration ...
>

Works for me. Sometimes less is more.

> >And I would not be surprised if we also need this sooner or later:
> >
> >   Mixed configuration server - a configuration server that processes
> >   some configuration operations as synchronous configuration
> >   operations and some configuration operations as asynchronous
> >   configuration operations.
> Yes, I would expect that clients may want to define the expected 
> behaviour, potentially on a per request basis.

I doubt that servers will offer clients to choose; I am more with Andy
that in real systems, depending on the data model, certain parts of a
data model may be synchronous while others may be asynchronous.

> >>Any further comments?
> >>
> >>Based on the feedback from Andy and others, it seems that the prevailing
> >>view is that existing NETCONF and RESTCONF should be regarded as being
> >>asynchronous in their behaviour in that the config nodes in the running
> >>datastore only represent the intended configuration and not the applied
> >>configuration.
> >Depends on the definition of applied configuration - where is the latest
> >version of it?
> The last proposed text for intended/applied is as below:
> 
>   intended configuration - this data represents the configuration
>   state that the network operator intends the system to be in, and 
> that
>   has been accepted by the system as valid configuration.  This 
> data is
>   colloquially referred to as the 'configuration' of the system.
> 
>  applied configuration - this data represents the configuration
>   state that the network element is actually in, i.e., the
>   configuration state which is currently being being used by system
>   components (e.g., control plane daemons, operating system
>   kernels, line cards).

Well, sometimes the config goes to a control plane daemon and then to
the OS kernel and finally to the line cards. This definition leaves
some room what an applied configuration is (which is IMHO needed if
you want to have something implementable) and hence a NC server can
either be considered synchronous or asynchronous.

> From Thursday's interim meeting, Rob Shakir clarified that the desired 
> intention is that applied configuration should mean that the 
> configuration is fully applied everywhere.  I don't know if that means 
> that the definition of applied configuration should be strengthened, or 
> if it is sufficient?

As said before, an OS kernel usually does not track where resource
parameters were coming from. (An interface has a set of IP addresses
and the kernel usually does not know which addresses were coming from
a configuration daemon, a dhcp daemon, a 

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

[Juergen Schoenwaelder]

On Tue, Oct 06, 2015 at 02:25:32PM -0700, Andy Bierman wrote:
> >> What does "SHOULD ensure that the request is valid" mean? RFC 6020
> >> says:
> >>
> >> When datastore processing is complete, the final contents MUST obey
> >> all validation constraints.  This validation processing is performed
> >> at differing times according to the datastore.  If the datastore is
> >>  or , these constraints MUST be enforced at the
> >> end of the  or  operation.  If the
> >> datastore is , the constraint enforcement is delayed
> >> until a  or  operation.
> >>
> >> Are we talking about datastore validation or validation of a request?
> >> If the former, are we watering down a MUST to a SHOULD?
> >>
> > Really it is datastore validation, particularly for an async request where
> > the intended config nodes are updated before replying. I'm not
> > intentionally trying to water down a MUST to a SHOULD, but Kent had
> > concerns that my previous description using "semantically validate" would
> > exclude an ephemeral datastore, so I was trying to water down the
> > description and also describe the behaviour in a way that isn't specific to
> > either RESTCONF/NETCONF or datastores.
> 
> I have been thinking about I2RS validation, and it there might be good
> reasons to say SHOULD instead of MUST (wrt/ ephemeral datastore anyway).

Ephemeral config is a different dimension that is yet to be worked
out. That said, RFC 6020 is quite clear what is expected from a
configuration datastore in terms of validation and we should not
change that.

> The server instrumentation can do a better job than the server at
> deciding how to prune bad config.  It may be much faster to have the
> server do syntax validation but not YANG constraint validation.  The
> instrumentation examines the ephemeral datastore to apply what it
> can. The rest gets ignored.  This may be too sloppy for standards,
> but I2RS is supposed to be fast.

Again, this is an ephemeral state issue. Do we bundle ephemeral state
into the open config discussion? I guess we need to do this but then
we also have a more complex set of players in this discussion.

/js

-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Robert Wilton]

Hi,

On 13/10/2015 09:48, Juergen Schoenwaelder wrote:

On Tue, Oct 06, 2015 at 09:42:37PM +0100, Robert Wilton wrote:

Hi Juergen,

On 06/10/2015 17:16, Juergen Schoenwaelder wrote:

On Tue, Oct 06, 2015 at 02:59:29PM +0100, Robert Wilton wrote:

Hi Kent,

Feeding in the various input, I think that this is the best refinement
that I've come up with:

Synchronous configuration operation - A configuration request to update
the running configuration of a server that is applied synchronously with
respect to the client request.  The server SHOULD ensure that the
request is valid, and MUST fully effect the configuration change to all
impacted components in the server, updating both the server's intended
and applied configuration (see terms), before replying to the client.
The reply to the client indicates whether there are any errors in the
request or errors from applying the configuration change.

What does "SHOULD ensure that the request is valid" mean? RFC 6020
says:

When datastore processing is complete, the final contents MUST obey
all validation constraints.  This validation processing is performed
at differing times according to the datastore.  If the datastore is
 or , these constraints MUST be enforced at the
end of the  or  operation.  If the
datastore is , the constraint enforcement is delayed
until a  or  operation.

Are we talking about datastore validation or validation of a request?
If the former, are we watering down a MUST to a SHOULD?

Really it is datastore validation, particularly for an async request
where the intended config nodes are updated before replying. I'm not
intentionally trying to water down a MUST to a SHOULD, but Kent had
concerns that my previous description using "semantically validate"
would exclude an ephemeral datastore, so I was trying to water down the
description and also describe the behaviour in a way that isn't specific
to either RESTCONF/NETCONF or datastores.

Perhaps, the start of sentence could simply be changed to:

The server MUST fully effect the configuration change to all
impacted components in the server ...

And equivalently for the asynchronous case below:

The server MUST update the server's intended configuration ...


Works for me. Sometimes less is more.


And I would not be surprised if we also need this sooner or later:

   Mixed configuration server - a configuration server that processes
   some configuration operations as synchronous configuration
   operations and some configuration operations as asynchronous
   configuration operations.

Yes, I would expect that clients may want to define the expected
behaviour, potentially on a per request basis.

I doubt that servers will offer clients to choose; I am more with Andy
that in real systems, depending on the data model, certain parts of a
data model may be synchronous while others may be asynchronous.
I think that the question regarding synchronous vs asynchronous is 
really about what a client can usefully do with that information.


If a client knows that a request is synchronous then it doesn't have to 
poll or check whether the configuration has been applied.  Unless it 
gets told in the reply that some configuration failed, it should be able 
to assume that all the configuration has been successfully applied and 
it can proceed to the next step (if any) in provisioning a service.


If a client knows that a request is asynchronous then it has to poll (or 
rely on a notification) to determine when the configuration has been 
applied.  If, when it polls, parts of the config are applied and parts 
of it are not then it might be able to continue with some provisioning 
tasks but have to wait before it can continue with other parts of the 
provisioning.


If a server is a hybrid (where I define a hybrid server as one that 
replies somewhere between when a sync or async server would), then I 
would expect that a client would end up treating this the same as an 
asynchronous server.  I.e. it would expect to query to find out which 
parts of the configuration are applied and which are not.


But I agree that existing NC servers are potentially neither exactly 
synchronous or asynchronous in their behaviour and hence my trying to 
labelling them as such may be a mistake.  Hence, perhaps it would be 
better to classify servers as one of sync, async, hybrid?





Any further comments?

Based on the feedback from Andy and others, it seems that the prevailing
view is that existing NETCONF and RESTCONF should be regarded as being
asynchronous in their behaviour in that the config nodes in the running
datastore only represent the intended configuration and not the applied
configuration.

Depends on the definition of applied configuration - where is the latest
version of it?

The last proposed text for intended/applied is as below:

   intended configuration - this data represents the configuration
   state that the network operator intends the system to be in, and
that

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

[Juergen Schoenwaelder]

On Tue, Oct 13, 2015 at 01:59:52PM +0100, Robert Wilton wrote:
> >As said before, an OS kernel usually does not track where resource
> >parameters were coming from. (An interface has a set of IP addresses
> >and the kernel usually does not know which addresses were coming from
> >a configuration daemon, a dhcp daemon, a tunneling daemon, a command
> >line utility, ...) The same may be true for line card. So in order to
> >implement a very tight definition, one has to either 'guess' which
> >'subset' of operational state can be related 'somehow' to the intended
> >config and then report the result of the guess work as applied config
> >or one would have to to change daemons/kernels/linecards to have a
> >tracking number or something like that.
> 
> Inferring the applied config state from the operation state is one way 
> of doing this.
> 
> An alternative way is for the NC/RC server to maintain separate internal 
> state for intended vs applied cfg nodes.  Then the NC/RC server would 
> update the applied cfg node when the internal IPC to program that 
> configuration had completed for all affected subsystems.

But the reality is that the NC/RC won't know. I invoke a system call
to tell the kernel what I want changed. The kernel sometimes says OK
before all components have been finally updated. The problem remains
to define what exactly applied config is. So are we only talking about
implementations that do not initiate the 'IPC' immediately or that
initiate the 'IPC' but may not wait for a completion of the 'IPC'?

Since this all sounds somewhat academic, do we have operational
evidence that NC/RC implementations do exhibit significant delays
between ACKing a config change and the config change becoming
communicated to the subsystems affected?

/js

-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Andy Bierman]

On Tue, Oct 13, 2015 at 12:13 PM, Juergen Schoenwaelder <
j.schoenwael...@jacobs-university.de> wrote:

> On Tue, Oct 13, 2015 at 01:59:52PM +0100, Robert Wilton wrote:
> > >As said before, an OS kernel usually does not track where resource
> > >parameters were coming from. (An interface has a set of IP addresses
> > >and the kernel usually does not know which addresses were coming from
> > >a configuration daemon, a dhcp daemon, a tunneling daemon, a command
> > >line utility, ...) The same may be true for line card. So in order to
> > >implement a very tight definition, one has to either 'guess' which
> > >'subset' of operational state can be related 'somehow' to the intended
> > >config and then report the result of the guess work as applied config
> > >or one would have to to change daemons/kernels/linecards to have a
> > >tracking number or something like that.
> >
> > Inferring the applied config state from the operation state is one way
> > of doing this.
> >
> > An alternative way is for the NC/RC server to maintain separate internal
> > state for intended vs applied cfg nodes.  Then the NC/RC server would
> > update the applied cfg node when the internal IPC to program that
> > configuration had completed for all affected subsystems.
>
> But the reality is that the NC/RC won't know. I invoke a system call
> to tell the kernel what I want changed. The kernel sometimes says OK
> before all components have been finally updated. The problem remains
> to define what exactly applied config is. So are we only talking about
> implementations that do not initiate the 'IPC' immediately or that
> initiate the 'IPC' but may not wait for a completion of the 'IPC'?
>
>
I agree -- even closed system code can be layered such that the
server does not know if the command has been fully applied or not.



> Since this all sounds somewhat academic, do we have operational
> evidence that NC/RC implementations do exhibit significant delays
> between ACKing a config change and the config change becoming
> communicated to the subsystems affected?
>
>
I have asked this question several times, but no answer so far.
It certainly depends on the data models and the implementation.
How slow is slow enough so that retrieving a lot of meta-data is
worthwhile?
5 sec? 5 min? 5 hours?  Nobody seems to know.




> /js
>


Andy


>
> --
> Juergen Schoenwaelder   Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103 
>
> ___
> 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

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

[Robert Wilton]

Hi Juergen,

On 06/10/2015 17:16, Juergen Schoenwaelder wrote:

On Tue, Oct 06, 2015 at 02:59:29PM +0100, Robert Wilton wrote:

Hi Kent,

Feeding in the various input, I think that this is the best refinement
that I've come up with:

Synchronous configuration operation - A configuration request to update
the running configuration of a server that is applied synchronously with
respect to the client request.  The server SHOULD ensure that the
request is valid, and MUST fully effect the configuration change to all
impacted components in the server, updating both the server's intended
and applied configuration (see terms), before replying to the client.
The reply to the client indicates whether there are any errors in the
request or errors from applying the configuration change.

What does "SHOULD ensure that the request is valid" mean? RFC 6020
says:

When datastore processing is complete, the final contents MUST obey
all validation constraints.  This validation processing is performed
at differing times according to the datastore.  If the datastore is
 or , these constraints MUST be enforced at the
end of the  or  operation.  If the
datastore is , the constraint enforcement is delayed
until a  or  operation.

Are we talking about datastore validation or validation of a request?
If the former, are we watering down a MUST to a SHOULD?
Really it is datastore validation, particularly for an async request 
where the intended config nodes are updated before replying. I'm not 
intentionally trying to water down a MUST to a SHOULD, but Kent had 
concerns that my previous description using "semantically validate" 
would exclude an ephemeral datastore, so I was trying to water down the 
description and also describe the behaviour in a way that isn't specific 
to either RESTCONF/NETCONF or datastores.


Perhaps, the start of sentence could simply be changed to:

The server MUST fully effect the configuration change to all
impacted components in the server ...


And equivalently for the asynchronous case below:

The server MUST update the server's intended configuration ...






Asynchronous configuration operation - A configuration request to update
the running configuration of a server that is applied asynchronously
with respect to the client request.  The server SHOULD ensure that the
request is valid, and MUST update the server's intended configuration
(see term) before replying to the client indicating whether the request
will be processed.  The server's applied configuration state (see term)
is updated after the configuration change has been fully effected to all
impacted components in the server.  The reply to the client only
indicates whether there are any errors in the original request.
Synchronous system -  Client/server interactions that process all
configuration requests as synchronous configuration operations (see term).

I think "synchronous system" is misleading, perhaps "synchronous
configuration server". The definitions talk about how a server
processes requests, they are silent about clients:
I agree.  Some of the requirement text would probably need to be tweaked 
to accommodate this.




   Synchronous configuration server - a configuration server that
   processes all configuration operations as synchronous configuration
   operations.


Asynchronous system - Client/server interactions that process all
configuration requests as asynchronous configuration operations (see term).

   Asynchronous configuration server - a configuration server that
   processes all configuration operations as asynchronous configuration
   operations.

And I would not be surprised if we also need this sooner or later:

   Mixed configuration server - a configuration server that processes
   some configuration operations as synchronous configuration
   operations and some configuration operations as asynchronous
   configuration operations.
Yes, I would expect that clients may want to define the expected 
behaviour, potentially on a per request basis.





Any further comments?

Based on the feedback from Andy and others, it seems that the prevailing
view is that existing NETCONF and RESTCONF should be regarded as being
asynchronous in their behaviour in that the config nodes in the running
datastore only represent the intended configuration and not the applied
configuration.

Depends on the definition of applied configuration - where is the latest
version of it?

The last proposed text for intended/applied is as below:

  intended configuration - this data represents the configuration
  state that the network operator intends the system to be in, and 
that
  has been accepted by the system as valid configuration.  This 
data is

  colloquially referred to as the 'configuration' of the system.

 applied configuration - this data represents the configuration
  state that the network element is actually in, i.e., the
  configuration state which is currently being 

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

[Andy Bierman]

On Tue, Oct 6, 2015 at 1:42 PM, Robert Wilton  wrote:

> Hi Juergen,
>
> On 06/10/2015 17:16, Juergen Schoenwaelder wrote:
>
>> On Tue, Oct 06, 2015 at 02:59:29PM +0100, Robert Wilton wrote:
>>
>>> Hi Kent,
>>>
>>> Feeding in the various input, I think that this is the best refinement
>>> that I've come up with:
>>>
>>> Synchronous configuration operation - A configuration request to update
>>> the running configuration of a server that is applied synchronously with
>>> respect to the client request.  The server SHOULD ensure that the
>>> request is valid, and MUST fully effect the configuration change to all
>>> impacted components in the server, updating both the server's intended
>>> and applied configuration (see terms), before replying to the client.
>>> The reply to the client indicates whether there are any errors in the
>>> request or errors from applying the configuration change.
>>>
>> What does "SHOULD ensure that the request is valid" mean? RFC 6020
>> says:
>>
>> When datastore processing is complete, the final contents MUST obey
>> all validation constraints.  This validation processing is performed
>> at differing times according to the datastore.  If the datastore is
>>  or , these constraints MUST be enforced at the
>> end of the  or  operation.  If the
>> datastore is , the constraint enforcement is delayed
>> until a  or  operation.
>>
>> Are we talking about datastore validation or validation of a request?
>> If the former, are we watering down a MUST to a SHOULD?
>>
> Really it is datastore validation, particularly for an async request where
> the intended config nodes are updated before replying. I'm not
> intentionally trying to water down a MUST to a SHOULD, but Kent had
> concerns that my previous description using "semantically validate" would
> exclude an ephemeral datastore, so I was trying to water down the
> description and also describe the behaviour in a way that isn't specific to
> either RESTCONF/NETCONF or datastores.
>
>

I have been thinking about I2RS validation, and it there might be good
reasons
to say SHOULD instead of MUST (wrt/ ephemeral datastore anyway).

The server instrumentation can do a better job than the server at
deciding how to prune bad config.  It may be much faster to have the server
do syntax validation but not YANG constraint validation.  The
instrumentation
examines the ephemeral datastore to apply what it can. The rest gets
ignored.
This may be too sloppy for standards, but I2RS is supposed to be fast.


Andy

Perhaps, the start of sentence could simply be changed to:
>
> The server MUST fully effect the configuration change to all
> impacted components in the server ...
>
>
> And equivalently for the asynchronous case below:
>
> The server MUST update the server's intended configuration ...
>
>
>
>
>> Asynchronous configuration operation - A configuration request to update
>>> the running configuration of a server that is applied asynchronously
>>> with respect to the client request.  The server SHOULD ensure that the
>>> request is valid, and MUST update the server's intended configuration
>>> (see term) before replying to the client indicating whether the request
>>> will be processed.  The server's applied configuration state (see term)
>>> is updated after the configuration change has been fully effected to all
>>> impacted components in the server.  The reply to the client only
>>> indicates whether there are any errors in the original request.
>>> Synchronous system -  Client/server interactions that process all
>>> configuration requests as synchronous configuration operations (see
>>> term).
>>>
>> I think "synchronous system" is misleading, perhaps "synchronous
>> configuration server". The definitions talk about how a server
>> processes requests, they are silent about clients:
>>
> I agree.  Some of the requirement text would probably need to be tweaked
> to accommodate this.
>
>
>>Synchronous configuration server - a configuration server that
>>processes all configuration operations as synchronous configuration
>>operations.
>>
>> Asynchronous system - Client/server interactions that process all
>>> configuration requests as asynchronous configuration operations (see
>>> term).
>>>
>>Asynchronous configuration server - a configuration server that
>>processes all configuration operations as asynchronous configuration
>>operations.
>>
>> And I would not be surprised if we also need this sooner or later:
>>
>>Mixed configuration server - a configuration server that processes
>>some configuration operations as synchronous configuration
>>operations and some configuration operations as asynchronous
>>configuration operations.
>>
> Yes, I would expect that clients may want to define the expected
> behaviour, potentially on a per request basis.
>
>
>> Any further comments?
>>>
>>> Based on the feedback from Andy and others, it seems that the prevailing

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

[Robert Wilton]

On 01/10/2015 00:55, Mahesh Jethanandani wrote:

One comment.

On Sep 30, 2015, at 8:02 AM, Robert Wilton > wrote:


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/ 
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" ?


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.






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.


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 …"


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?

Yes.

Rather than operating configuration I would perhaps say the "observable 
system behaviour is reflected by derived state".


E.g. if you were to change the MTU of an interface to a different value 
(that was say incompatible with a peer device) then the "applied 
configuration" for the MTU leaf would only tell you whether or not that 
MTU was actively being used by the system.   It wouldn't tell you that 
an ISIS session on that interface had gone down due to the MTU 
incompatibility.  That could only be observed by the changing of the 
derived state representing the status of the ISIS session (or an alarm).


Thanks,
Rob

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Juergen Schoenwaelder]

On Tue, Sep 29, 2015 at 01:56:56PM -0400, Nadeau Thomas wrote:
> 
>   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,

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 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Kent Watsen]

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 <tnad...@lucidvision.com<mailto:tnad...@lucidvision.com>>
Date: Tuesday, September 29, 2015 at 10:56 AM
To: Robert Wilton <rwil...@cisco.com<mailto:rwil...@cisco.com>>
Cc: "netmod@ietf.org<mailto:netmod@ietf.org>" 
<netmod@ietf.org<mailto:netmod@ietf.org>>
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).

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 
<rwil...@cisco.com<mailto:rwil...@cisco.com>> wrote:



On 28/09/2015 18:17, Andy Bierman wrote:


On Mon, Sep 28, 2015 at 10:10 AM, Robert Wilton 
<rwil...@cisco.com<mailto:rwil...@cisco.com>> wrote:
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.
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".

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.


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.

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

___
netmod mailing list
netmod@ietf.org<mailto:netmod@ietf.org>
https://www.ietf.org/mailman/listinfo/netmod

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Mahesh Jethanandani]

One comment.

> On Sep 30, 2015, at 8:02 AM, Robert Wilton  wrote:
> 
> 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/ 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" ?
> 
> 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.
> 
> 
>> 
>> 
>> 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.
> 
> 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 …"

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?

> 
> 
>> 
>> 
>> 
>> 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.
> 
> 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?
> 
>> 
>> 
>> Synchronous system - NETCONF/RESTCONF client/server interactions that 
>> processes all configuration operations as synchronous configuration 

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

[Kent Watsen]

[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/ 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



___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Robert Wilton]

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.

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".


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
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.


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 > wrote:


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". 

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

[Andy Bierman]

On Mon, Sep 28, 2015 at 10:10 AM, Robert Wilton  wrote:

> 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.
> 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".
>
>
> 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.
>
>
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

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
> 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.
>
>
> 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  wrote:
>
>> 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 

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

[Robert Wilton]

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





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


Thanks,
Kent



___
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

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

[Andy Bierman]

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  wrote:

> 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
>
>
>
>
> PS: please Reply-All to this thread, rather than post comments on the GitHub
> issue tracker.
>
> Thanks,
> Kent
>
>
>
> ___
> netmod mailing listnetmod@ietf.orghttps://www.ietf.org/mailman/listinfo/netmod
>
>
>
> ___
> 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