Re: [netmod] I-D Action: draft-kwatsen-netmod-opstate-02.txt

[Kent Watsen]

[As a contributor]




   If not, does it become a configuration error if a
 line card is inserted to which the configuration can not be applied?
>>> As above, this question doesn't directly apply.
>>>
>>> But a similar question might be: what would happen if the configuration
>>> had previously been accepted and then a linecard removed?  In this case
>>> the the affected interface configuration would stay in intended but be
>>> removed from applied by the system.
>> Looks like the semantics you describe are somewhat inconsistent.
>OK, they were not meant to be inconsistent at all:
>
>- The intended configuration is what the operator wants, and can only be 
>changed by the operator.
>- The applied configuration is what state the system is in, and should 
>be continuously kept up to date with the current system state.
>
>- If a config change completes without any errors that means that for 
>every node in the changeset, the applied config node matches the 
>intended config node.
>- This is why I would say that the cleanest semantics are that 
>attempting to configure an interface that doesn't exist should be 
>regarded as a config apply error.  (If the operator wants to push this 
>config in then I think that they should be using the continue-on-error 
>option - or perhaps something similar).

I disagree.  JUNOS specifically allows for preconfiguration for hardware that 
does not exists yet.  It’s a well-regarded feature.  It is not an error, but 
may be reported as a warning.  This is why we defined leaf "apply-warning” in 
this draft (see subject line).  That said, I do agree that the applied 
configuration would not have the config for the missing hardware, as would be 
evident in a diff between it and the intended configuration.  



>>   BTW,
>> I have been told that 'some operators' do provision configuration for
>> hardware not yet present. RFC 7223 has been designed to allow this to
>> happen. Anyway, this is an example. The point is that it is not clear
>Yes.  I'm not opposed to this on principal, but if a choice of semantics 
>are supported then it should be down the operators request to choose the 
>semantics.  Having rules that give flexibility in how a device is 
>allowed to behave just makes them more difficult for the operator to manage.

I think that this doesn’t scale.  By this token, servers should support 
everything the IETF defines.  But that’s not how it works, instead we have 
features and capabilities that enable devices to advertise what they support.  
This ability is important when a brown-field device is moving to support 
NETCONF/RESTCONF but can’t break compatibility with its legacy APIs.



Note that NETCONF together with YANG provides a rather clear
 definition what validation of a configuration datastore means. When we
 talk about applied config and the difference between intended and
 applied config, the notion of what is a configuration error is not
 clear cut anymore.
>>> Personally, I agree that having tighter semantics are a good thing here
>>> (and should be covered by the solution draft).
>> Then I note that the requirement is at least not well defined.
>Perhaps, but we had already spent a long time discussing the 
>requirements draft, hence personally I think that it is OK to 
>specify/agree the precise semantics/behaviour in a solution draft.

Not just that, but it was the decision we made as a WG, and why the 
requirements say "The configuration protocol MUST specify how configuration 
errors are handled.” - right?



 Second, in order to rollback, there needs to be a configuration that
 can be safely rolled back into. The only robust way I can imagine to
 implement this rollback requirement is to use locks until the whole
 new config has been applied, thereby turning an asynchronous system
 into a synchronous system. Otherwise, I fail to see how I can ensure
 that I have a configuration that can be safely rolled back into.
>>> Locks are the simplest way of implementing this, but I agree that they
>>> defeat the point of async configuration updates.
>>>
>>> I don't think that locking is the only way to solve this.  I would have
>>> thought that one of the optimistic transactional locking approaches
>>> could be used to process multiple requests concurrently.
>> As long as it is clear to which configuration to roll back to. Once
>> you process multiple requests concurrently, this is not at all clear,
>> at least not to me.
>Logically, the system must revert to a state where the failed 
>configuration request was never applied.  I think this is the only 
>guarantee that is being made to the client.
>
>One way to achieve this would be rollback the configuration (intended 
>and applied) back to exactly the point before that failed request (or 
>any other request) was processed.
>
>Any concurrent configuration requests that were previously in progress 
>would then need to be re-applied one by one (in the same order).  

Re: [netmod] I-D Action: draft-kwatsen-netmod-opstate-02.txt

[Robert Wilton]

On 12/02/2016 08:19, Juergen Schoenwaelder wrote:

On Thu, Feb 11, 2016 at 02:52:27PM +, Robert Wilton wrote:

On 11/02/2016 09:29, Juergen Schoenwaelder wrote:

We are discussing this text:

D.  The configuration protocol MUST specify how configuration
errors are handled.  Errors SHOULD be handled by semantics
similar to NETCONF's error-options for the 
operation (stop-on-error, continue-on-error, rollback-on-
error), as described in Section 7.2 in [RFC6241], but
extended to incorporate both the intended and applied
configurations.  Support for "rollback on error" semantics
SHOULD be provided.

First, let me observe that it is underspecified what a 'configuration
error' is in the context of this requirement statement. Is the
configuration of an interface that is currently not present a
configuration error?

My opinion is yes, this is an error and hence would cause configuration
to fail and rollback if "rollback-on-error" semantics had been requested.

If the request had used continue-on-error semantics then I would expect
that you would see this configuration in intended, but not applied.


  If not, does it become a configuration error if a
line card is inserted to which the configuration can not be applied?

As above, this question doesn't directly apply.

But a similar question might be: what would happen if the configuration
had previously been accepted and then a linecard removed?  In this case
the the affected interface configuration would stay in intended but be
removed from applied by the system.

Looks like the semantics you describe are somewhat inconsistent.

OK, they were not meant to be inconsistent at all:

- The intended configuration is what the operator wants, and can only be 
changed by the operator.
- The applied configuration is what state the system is in, and should 
be continuously kept up to date with the current system state.


- If a config change completes without any errors that means that for 
every node in the changeset, the applied config node matches the 
intended config node.
- This is why I would say that the cleanest semantics are that 
attempting to configure an interface that doesn't exist should be 
regarded as a config apply error.  (If the operator wants to push this 
config in then I think that they should be using the continue-on-error 
option - or perhaps something similar).




  BTW,
I have been told that 'some operators' do provision configuration for
hardware not yet present. RFC 7223 has been designed to allow this to
happen. Anyway, this is an example. The point is that it is not clear
Yes.  I'm not opposed to this on principal, but if a choice of semantics 
are supported then it should be down the operators request to choose the 
semantics.  Having rules that give flexibility in how a device is 
allowed to behave just makes them more difficult for the operator to manage.




cut whether something that can't be immediately applied really is an
error.
  

Note that NETCONF together with YANG provides a rather clear
definition what validation of a configuration datastore means. When we
talk about applied config and the difference between intended and
applied config, the notion of what is a configuration error is not
clear cut anymore.

Personally, I agree that having tighter semantics are a good thing here
(and should be covered by the solution draft).

Then I note that the requirement is at least not well defined.
Perhaps, but we had already spent a long time discussing the 
requirements draft, hence personally I think that it is OK to 
specify/agree the precise semantics/behaviour in a solution draft.






Second, in order to rollback, there needs to be a configuration that
can be safely rolled back into. The only robust way I can imagine to
implement this rollback requirement is to use locks until the whole
new config has been applied, thereby turning an asynchronous system
into a synchronous system. Otherwise, I fail to see how I can ensure
that I have a configuration that can be safely rolled back into.

Locks are the simplest way of implementing this, but I agree that they
defeat the point of async configuration updates.

I don't think that locking is the only way to solve this.  I would have
thought that one of the optimistic transactional locking approaches
could be used to process multiple requests concurrently.

As long as it is clear to which configuration to roll back to. Once
you process multiple requests concurrently, this is not at all clear,
at least not to me.
Logically, the system must revert to a state where the failed 
configuration request was never applied.  I think this is the only 
guarantee that is being made to the client.


One way to achieve this would be rollback the configuration (intended 
and applied) back to exactly the point before that failed request (or 
any other request) was processed.


Any concurrent configuration request

Re: [netmod] I-D Action: draft-kwatsen-netmod-opstate-02.txt

[Juergen Schoenwaelder]

On Thu, Feb 11, 2016 at 02:52:27PM +, Robert Wilton wrote:
> 
> On 11/02/2016 09:29, Juergen Schoenwaelder wrote:
> >We are discussing this text:
> >
> >D.  The configuration protocol MUST specify how configuration
> >errors are handled.  Errors SHOULD be handled by semantics
> >similar to NETCONF's error-options for the 
> >operation (stop-on-error, continue-on-error, rollback-on-
> >error), as described in Section 7.2 in [RFC6241], but
> >extended to incorporate both the intended and applied
> >configurations.  Support for "rollback on error" semantics
> >SHOULD be provided.
> >
> >First, let me observe that it is underspecified what a 'configuration
> >error' is in the context of this requirement statement. Is the
> >configuration of an interface that is currently not present a
> >configuration error?
> My opinion is yes, this is an error and hence would cause configuration 
> to fail and rollback if "rollback-on-error" semantics had been requested.
> 
> If the request had used continue-on-error semantics then I would expect 
> that you would see this configuration in intended, but not applied.
> 
> >  If not, does it become a configuration error if a
> >line card is inserted to which the configuration can not be applied?
> As above, this question doesn't directly apply.
> 
> But a similar question might be: what would happen if the configuration 
> had previously been accepted and then a linecard removed?  In this case 
> the the affected interface configuration would stay in intended but be 
> removed from applied by the system.

Looks like the semantics you describe are somewhat inconsistent. BTW,
I have been told that 'some operators' do provision configuration for
hardware not yet present. RFC 7223 has been designed to allow this to
happen. Anyway, this is an example. The point is that it is not clear
cut whether something that can't be immediately applied really is an
error.
 
> >Note that NETCONF together with YANG provides a rather clear
> >definition what validation of a configuration datastore means. When we
> >talk about applied config and the difference between intended and
> >applied config, the notion of what is a configuration error is not
> >clear cut anymore.
> Personally, I agree that having tighter semantics are a good thing here 
> (and should be covered by the solution draft).

Then I note that the requirement is at least not well defined.

> >Second, in order to rollback, there needs to be a configuration that
> >can be safely rolled back into. The only robust way I can imagine to
> >implement this rollback requirement is to use locks until the whole
> >new config has been applied, thereby turning an asynchronous system
> >into a synchronous system. Otherwise, I fail to see how I can ensure
> >that I have a configuration that can be safely rolled back into.
> Locks are the simplest way of implementing this, but I agree that they 
> defeat the point of async configuration updates.
> 
> I don't think that locking is the only way to solve this.  I would have 
> thought that one of the optimistic transactional locking approaches 
> could be used to process multiple requests concurrently.

As long as it is clear to which configuration to roll back to. Once
you process multiple requests concurrently, this is not at all clear,
at least not to me.

> Hence, I think that the decision as to whether or not to use a global 
> lock should probably be specified during the client operation (if at 
> all), and the solution draft shouldn't enforce always using a server 
> side lock.  Instead it should specify the exact semantics that a client 
> can expect when interacting with the server during configuration 
> requests.  This is to allow for flexibility in server implementations - 
> i.e. to trade off complexity for performance.

If it is unclear from the specification what the result of a rollback
is, then I believe this serves little value. And see the previous
examples; what can be applied at time t in general depends on the
overall state of the system at time t. YANG does not allow config true
nodes to depend on config false nodes and the reason is that
configuration validity must not depend on the time varying operational
state of a device.

/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] I-D Action: draft-kwatsen-netmod-opstate-02.txt

[Robert Wilton]

On 11/02/2016 09:29, Juergen Schoenwaelder wrote:

On Wed, Feb 10, 2016 at 05:45:10PM +, Robert Wilton wrote:


On 10/02/2016 12:51, Juergen Schoenwaelder wrote:

On Mon, Feb 08, 2016 at 05:50:00PM +, Gert Grammel wrote:

Hi Juergen,

I think the indentation in  our emails play havoc which is confusing me
too. The key point I am making is:

The mapping of what is called intended-config onto data stores would
deserve more detailed discussion. It seems the authors of
draft-kwatsen-netmod-opstate-02.txt had in mind to associate intended-cfg
with the [running] datastore. In my understanding, a failure in applying
[running] to [applied] will update the [running] datastore to reflect
which part is effectively applied. So a fair representation of that case
would be:
[candidate] -> [running] <--> [applied] -> derived state

This is not how I understood that state of the discussions. I do not
think that the NETCONF  configuration datastore changes in
existing implementations dynamically. Does it on Junos?

On Cisco's IOS XR, for a normal configuration commit (i.e. rollback on
error semantics) then if applying the configuration for any config nodes
fails then the whole config commit is undone.  I.e. the system ends in
the same state as if the configuration commit never happened - standard
transaction commit semantics.


This is how it should be.


In the context of intended-configuration however that doesn’t make sense
to me. A failure in applying intended configuration doesn¹t change the
intention and the delta between intended and applied-config is the key
value. A server that would "clean-up" intended-cfg in presence of a
failure to apply would look picture perfect instead of exposing the
problem clearly. Hence the sequence should more look like:
[candidate] -> [intended] ‹-> [running==applied] -> derived state

Whatever we choose, I believe we need to spell out what¹s the data in a
failure case. It¹s probably a bit late to update the requirements draft,
but we can probably find a suitable place.

———


I am also wondring if we have the same understanding related to the
following statement:
I thought the whole point of having an applied config is to be able
to
see the difference between intended (oops running) and applied.


The current draft-kwatsen-netmod-opstate-02.txt says:
"Any rollback that may occur will restore both the intended and the
applied configurations to their previous states."

This rollback requirement is in my view broken (I assume people will
figure this out when they try to implement solutions for it).

This was meant to be consistent with the existing rollback-on-error
semantics supported by NETCONF (specified in rfc6241).

As above, my understanding is that Cisco IOS XR already supports these
semantics.

Please can you clarify how/why the requirement is broken?

We are discussing this text:

D.  The configuration protocol MUST specify how configuration
errors are handled.  Errors SHOULD be handled by semantics
similar to NETCONF's error-options for the 
operation (stop-on-error, continue-on-error, rollback-on-
error), as described in Section 7.2 in [RFC6241], but
extended to incorporate both the intended and applied
configurations.  Support for "rollback on error" semantics
SHOULD be provided.

First, let me observe that it is underspecified what a 'configuration
error' is in the context of this requirement statement. Is the
configuration of an interface that is currently not present a
configuration error?
My opinion is yes, this is an error and hence would cause configuration 
to fail and rollback if "rollback-on-error" semantics had been requested.


If the request had used continue-on-error semantics then I would expect 
that you would see this configuration in intended, but not applied.



  If not, does it become a configuration error if a
line card is inserted to which the configuration can not be applied?

As above, this question doesn't directly apply.

But a similar question might be: what would happen if the configuration 
had previously been accepted and then a linecard removed?  In this case 
the the affected interface configuration would stay in intended but be 
removed from applied by the system.



Note that NETCONF together with YANG provides a rather clear
definition what validation of a configuration datastore means. When we
talk about applied config and the difference between intended and
applied config, the notion of what is a configuration error is not
clear cut anymore.
Personally, I agree that having tighter semantics are a good thing here 
(and should be covered by the solution draft).




Second, in order to rollback, there needs to be a configuration that
can be safely rolled back into. The only robust way I can imagine to
implement this rollback requirement is to use locks until the whole
new config has been applied, thereby turning an asynchronou

Re: [netmod] I-D Action: draft-kwatsen-netmod-opstate-02.txt

[Juergen Schoenwaelder]

On Wed, Feb 10, 2016 at 05:45:10PM +, Robert Wilton wrote:
> 
> 
> On 10/02/2016 12:51, Juergen Schoenwaelder wrote:
> >On Mon, Feb 08, 2016 at 05:50:00PM +, Gert Grammel wrote:
> >>Hi Juergen,
> >>
> >>I think the indentation in  our emails play havoc which is confusing me
> >>too. The key point I am making is:
> >>
> >>The mapping of what is called intended-config onto data stores would
> >>deserve more detailed discussion. It seems the authors of
> >>draft-kwatsen-netmod-opstate-02.txt had in mind to associate intended-cfg
> >>with the [running] datastore. In my understanding, a failure in applying
> >>[running] to [applied] will update the [running] datastore to reflect
> >>which part is effectively applied. So a fair representation of that case
> >>would be:
> >>[candidate] -> [running] <--> [applied] -> derived state
> >This is not how I understood that state of the discussions. I do not
> >think that the NETCONF  configuration datastore changes in
> >existing implementations dynamically. Does it on Junos?
> On Cisco's IOS XR, for a normal configuration commit (i.e. rollback on 
> error semantics) then if applying the configuration for any config nodes 
> fails then the whole config commit is undone.  I.e. the system ends in 
> the same state as if the configuration commit never happened - standard 
> transaction commit semantics.
>

This is how it should be.

> >
> >>In the context of intended-configuration however that doesn’t make sense
> >>to me. A failure in applying intended configuration doesn¹t change the
> >>intention and the delta between intended and applied-config is the key
> >>value. A server that would "clean-up" intended-cfg in presence of a
> >>failure to apply would look picture perfect instead of exposing the
> >>problem clearly. Hence the sequence should more look like:
> >>[candidate] -> [intended] ‹-> [running==applied] -> derived state
> >>
> >>Whatever we choose, I believe we need to spell out what¹s the data in a
> >>failure case. It¹s probably a bit late to update the requirements draft,
> >>but we can probably find a suitable place.
> >>
> >>———
> >>
> >>
> >>I am also wondring if we have the same understanding related to the
> >>following statement:
> >>I thought the whole point of having an applied config is to be able 
> >>to
> >>see the difference between intended (oops running) and applied.
> >>
> >>
> >>The current draft-kwatsen-netmod-opstate-02.txt says:
> >>"Any rollback that may occur will restore both the intended and the
> >>applied configurations to their previous states."
> >This rollback requirement is in my view broken (I assume people will
> >figure this out when they try to implement solutions for it).
> This was meant to be consistent with the existing rollback-on-error 
> semantics supported by NETCONF (specified in rfc6241).
> 
> As above, my understanding is that Cisco IOS XR already supports these 
> semantics.
> 
> Please can you clarify how/why the requirement is broken?

We are discussing this text:

   D.  The configuration protocol MUST specify how configuration
   errors are handled.  Errors SHOULD be handled by semantics
   similar to NETCONF's error-options for the 
   operation (stop-on-error, continue-on-error, rollback-on-
   error), as described in Section 7.2 in [RFC6241], but
   extended to incorporate both the intended and applied
   configurations.  Support for "rollback on error" semantics
   SHOULD be provided.

First, let me observe that it is underspecified what a 'configuration
error' is in the context of this requirement statement. Is the
configuration of an interface that is currently not present a
configuration error? If not, does it become a configuration error if a
line card is inserted to which the configuration can not be applied?
Note that NETCONF together with YANG provides a rather clear
definition what validation of a configuration datastore means. When we
talk about applied config and the difference between intended and
applied config, the notion of what is a configuration error is not
clear cut anymore.

Second, in order to rollback, there needs to be a configuration that
can be safely rolled back into. The only robust way I can imagine to
implement this rollback requirement is to use locks until the whole
new config has been applied, thereby turning an asynchronous system
into a synchronous system. Otherwise, I fail to see how I can ensure
that I have a configuration that can be safely rolled back into.

/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] I-D Action: draft-kwatsen-netmod-opstate-02.txt

[Robert Wilton]

On 10/02/2016 12:51, Juergen Schoenwaelder wrote:

On Mon, Feb 08, 2016 at 05:50:00PM +, Gert Grammel wrote:

Hi Juergen,

I think the indentation in  our emails play havoc which is confusing me
too. The key point I am making is:

The mapping of what is called intended-config onto data stores would
deserve more detailed discussion. It seems the authors of
draft-kwatsen-netmod-opstate-02.txt had in mind to associate intended-cfg
with the [running] datastore. In my understanding, a failure in applying
[running] to [applied] will update the [running] datastore to reflect
which part is effectively applied. So a fair representation of that case
would be:
[candidate] -> [running] <--> [applied] -> derived state

This is not how I understood that state of the discussions. I do not
think that the NETCONF  configuration datastore changes in
existing implementations dynamically. Does it on Junos?
On Cisco's IOS XR, for a normal configuration commit (i.e. rollback on 
error semantics) then if applying the configuration for any config nodes 
fails then the whole config commit is undone.  I.e. the system ends in 
the same state as if the configuration commit never happened - standard 
transaction commit semantics.






In the context of intended-configuration however that doesn’t make sense
to me. A failure in applying intended configuration doesn¹t change the
intention and the delta between intended and applied-config is the key
value. A server that would "clean-up" intended-cfg in presence of a
failure to apply would look picture perfect instead of exposing the
problem clearly. Hence the sequence should more look like:
[candidate] -> [intended] ‹-> [running==applied] -> derived state

Whatever we choose, I believe we need to spell out what¹s the data in a
failure case. It¹s probably a bit late to update the requirements draft,
but we can probably find a suitable place.

———


I am also wondring if we have the same understanding related to the
following statement:
I thought the whole point of having an applied config is to be able to
see the difference between intended (oops running) and applied.


The current draft-kwatsen-netmod-opstate-02.txt says:
"Any rollback that may occur will restore both the intended and the
applied configurations to their previous states."

This rollback requirement is in my view broken (I assume people will
figure this out when they try to implement solutions for it).
This was meant to be consistent with the existing rollback-on-error 
semantics supported by NETCONF (specified in rfc6241).


As above, my understanding is that Cisco IOS XR already supports these 
semantics.


Please can you clarify how/why the requirement is broken?

Rob

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

Re: [netmod] I-D Action: draft-kwatsen-netmod-opstate-02.txt

[Robert Wilton]

On 10/02/2016 15:46, Kent Watsen wrote:





If there was a way that YANG patch (or equivalent) were able to return
both old and new values (in the same tree) then I think that would be
better.  I don't think that such as solution would be specific to the
opstate requirements and may be useful more generally.

Already the  RPC accepts an enumeration specifying the response 
format.  It seems that all that is needed is to define another enumeration for 
something like “yang-diff” that can do all you say.   We don’t have yang-diff today, 
but someone can write a draft to define it and then it can be added or used instead.

Alternatively, the  RPC could be moved into a diff-draft that defines both 
the RPC and the format together.  Something like this might make sense as  
is generally useful outside of this opstate application.

Yes, OK.

I can easily see how a  RPC message could provide two separate 
trees, i.e. one with the values before, and a separate tree with the 
values after, but I'm not sure that such a message format would really 
be any better than the current YANG patch format.


However, the bit that I'm stuck on is that I can't see how is it 
possible to provide the data in a single tree unless you end up with an 
encoding that is broadly similar to what I have suggested in my draft, 
and several folks have strong views against any such encoding.  AFAIK, 
no alternatives have been proposed.


Rob




Kent  // contributor



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

Re: [netmod] I-D Action: draft-kwatsen-netmod-opstate-02.txt

[Kent Watsen]

>If there was a way that YANG patch (or equivalent) were able to return 
>both old and new values (in the same tree) then I think that would be 
>better.  I don't think that such as solution would be specific to the 
>opstate requirements and may be useful more generally.

Already the  RPC accepts an enumeration specifying the response 
format.  It seems that all that is needed is to define another enumeration for 
something like “yang-diff” that can do all you say.   We don’t have yang-diff 
today, but someone can write a draft to define it and then it can be added or 
used instead.  

Alternatively, the  RPC could be moved into a diff-draft that defines 
both the RPC and the format together.  Something like this might make sense as 
 is generally useful outside of this opstate application. 

Kent  // contributor 

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

Re: [netmod] I-D Action: draft-kwatsen-netmod-opstate-02.txt

[Robert Wilton]

On 10/02/2016 12:42, Juergen Schoenwaelder wrote:

On Mon, Feb 08, 2016 at 04:59:42PM +, Robert Wilton wrote:


So if in my 1 million XML elements one has not been applied, how do I
find out efficiently in your encoding?

By using 'diff-cfg-only' option of the  parameter,
you would get 3 or 4 leaves per mismatching node: (intended value,
applied value, status, and optionally error reason).  Only nodes with
differences would be returned.

A more complete example is in
https://tools.ietf.org/html/draft-wilton-netmod-opstate-yang-02, "A.2.
NETCONF get-config request using with-config-state with diff-cfg-only
option", about page 16.

Yes, this data would be larger than the patch, but it also contains more
information (i.e. reason why they differ, and error string).


OK. Next question: How do I get the diff between  and
? How do I get the diff between  and ?
We can try to build generic primitives or we can choose to create many
point solutions.

I think that this is effectively the same question that I asked Martin, i.e.

"Can you please suggest an approach of how to return a single tree that 
contains the data from two separate datastores (where the leaf paths may 
overlap)?  I think that the approach would need to work both for get 
requests and also notification data. "





The client is also able to process this data straight away.  With the
patch, they may need to generate the before and after values to make it
easier to process.

I fail to get the message, what is easier to process for a client is
largely subjective or a function of the particular client environment
or what I want to do with the data.

What is easier to read:
 - a diff that only gives you the new value and the context, or
 - a diff that gives you both the old and new values?


Here is a hypothetical C example:

1) A diff with just the new context:

***
*** 3112,3118 
  caps_vft->caps_unbuilder_func = dot1q_unbuilder;
  caps_vft->caps_control_func   = dot1q_control;
! caps_vft->caps_upgrade_func   = dot1q_upgrade;
! caps_vft->caps_terminate_func = dot1q_terminate;


2) The same diff with both old and new context:

***
*** 3112,3118 
  caps_vft->caps_unbuilder_func = dot1q_unbuilder;
  caps_vft->caps_control_func   = dot1q_control;
! caps_vft->caps_upgrade_func   = dot1q_terminate;
! caps_vft->caps_terminate_func = dot1q_upgrade;

--- 3115,3121 
  caps_vft->caps_unbuilder_func = dot1q_unbuilder;
  caps_vft->caps_control_func   = dot1q_control;
! caps_vft->caps_upgrade_func   = dot1q_upgrade;
! caps_vft->caps_terminate_func = dot1q_terminate;

In the latter case, it is easy to see what the change is.  In the former 
case you would need to understand what the code was previously to 
understand the change.
In the latter case, if you don't care what the old value was, then that 
is fine it can just be ignored.


So the point that I'm trying to make is that the YANG Patch format is 
broadly equivalent to the former example.  Yes, it strictly meets the 
requirement draft to return a comparison between the two datasets, but 
in a way that I perceive is not as easy or flexible for the client as if 
both the old and new values had been provided.


If there was a way that YANG patch (or equivalent) were able to return 
both old and new values (in the same tree) then I think that would be 
better.  I don't think that such as solution would be specific to the 
opstate requirements and may be useful more generally.


Rob




/js



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

Re: [netmod] I-D Action: draft-kwatsen-netmod-opstate-02.txt

[Juergen Schoenwaelder]

On Mon, Feb 08, 2016 at 05:50:00PM +, Gert Grammel wrote:
> Hi Juergen,
> 
> I think the indentation in  our emails play havoc which is confusing me
> too. The key point I am making is:
> 
> The mapping of what is called intended-config onto data stores would
> deserve more detailed discussion. It seems the authors of
> draft-kwatsen-netmod-opstate-02.txt had in mind to associate intended-cfg
> with the [running] datastore. In my understanding, a failure in applying
> [running] to [applied] will update the [running] datastore to reflect
> which part is effectively applied. So a fair representation of that case
> would be:
> [candidate] -> [running] <--> [applied] -> derived state

This is not how I understood that state of the discussions. I do not
think that the NETCONF  configuration datastore changes in
existing implementations dynamically. Does it on Junos?

> In the context of intended-configuration however that doesn’t make sense
> to me. A failure in applying intended configuration doesn¹t change the
> intention and the delta between intended and applied-config is the key
> value. A server that would "clean-up" intended-cfg in presence of a
> failure to apply would look picture perfect instead of exposing the
> problem clearly. Hence the sequence should more look like:
> [candidate] -> [intended] ‹-> [running==applied] -> derived state
> 
> Whatever we choose, I believe we need to spell out what¹s the data in a
> failure case. It¹s probably a bit late to update the requirements draft,
> but we can probably find a suitable place.
> 
> ———
> 
> 
> I am also wondring if we have the same understanding related to the
> following statement:
>   I thought the whole point of having an applied config is to be able to
> see the difference between intended (oops running) and applied.
> 
> 
> The current draft-kwatsen-netmod-opstate-02.txt says:
> "Any rollback that may occur will restore both the intended and the
> applied configurations to their previous states."

This rollback requirement is in my view broken (I assume people will
figure this out when they try to implement solutions for it). Anyway,
NETCONF today commits  to  and I do not think we
should mess around with that.
 
> The challenge I have is the term “(oops running)” in the first sentence in
> combination with the citation. I reckon that any difference between
> intended-config and applied-config shall be visible whereby the
> intended-config is provided by the client and never altered by the server.
> Applied-config on the other hand represents the state of the server. If a
> failure happens in the application phase, it shall be treated accordingly
> (rollback-, stop-, continue-on-error). As a result the difference between
> intended and applied configuration shall be maintained.
> So does this square with the notion "intended=running" and “applied”
> config?

Yes (with the caveat that the rollback requirement text is kind of
broken).

/js

> - Gert
> 
> 
> 
> 
> 
> On 2016-08-02 17:38, "Juergen Schoenwaelder"
>  wrote:
> 
> >On Mon, Feb 08, 2016 at 02:53:57PM +, Gert Grammel wrote:
> >> 
> >> 
> >> >This is not what is being proposed. We always had
> >> >
> >> >[candidate] -> [running] -> operational state
> >> >
> >> >(and I mark configuration data stores in []). Both [candidate] and
> >> >[running] have the same configuration data model. Now we are asked
> >> >to expose that [running] may not be applied synchronously and hence
> >> >
> >> >[candidate] -> [running] -> [applied] -> derived state
> >> >
> >> >seems to make sense.
> >
> >Why would that be the case? If I configure an interface that is not
> >currently present today in running this is just find and running is
> >not expected to change arbitrarily.
> > 
> >> The mapping of what is called intended-config onto data stores would
> >> deserve more detailed discussion. It seems the authors of this draft had
> >> in mind to associate intended-cfg with the [running] datastore. With
> >>that
> >> mapping, a failure in applying [running] to [applied] will update the
> >> [running] datastore to reflect which part is effectively applied. So a
> >> fair representation of that case would be:
> >> [candidate] -> [running] <--> [applied] -> derived state
> >
> >What is 'this draft'? I thought the whole point of having an applied
> >config is to be able to see the difference between intended (oops
> >running) and applied. I am confused now.
> > 
> >> In the context of intended configuration however that doesn¹t make sense
> >> to me. A failure in applying intended configuration doesn¹t change the
> >> intention and the delta between intended and applied-config is the key
> >> value. A server that would "clean-up² intended-cfg in presence of a
> >> failure to apply would look picture perfect instead of exposing the
> >> problem clearly. Hence the sequence should more look like:
> >> [candidate] -> [intended] ‹> [running==applied] -> derived state
> >> 
> >> Whatever we choose, I believe

Re: [netmod] I-D Action: draft-kwatsen-netmod-opstate-02.txt

[Juergen Schoenwaelder]

On Mon, Feb 08, 2016 at 04:59:42PM +, Robert Wilton wrote:

> >So if in my 1 million XML elements one has not been applied, how do I
> >find out efficiently in your encoding?
> By using 'diff-cfg-only' option of the  parameter, 
> you would get 3 or 4 leaves per mismatching node: (intended value, 
> applied value, status, and optionally error reason).  Only nodes with 
> differences would be returned.
> 
> A more complete example is in 
> https://tools.ietf.org/html/draft-wilton-netmod-opstate-yang-02, "A.2.  
> NETCONF get-config request using with-config-state with diff-cfg-only 
> option", about page 16.
> 
> Yes, this data would be larger than the patch, but it also contains more 
> information (i.e. reason why they differ, and error string).
> 

OK. Next question: How do I get the diff between  and
? How do I get the diff between  and ?
We can try to build generic primitives or we can choose to create many
point solutions.

> The client is also able to process this data straight away.  With the 
> patch, they may need to generate the before and after values to make it 
> easier to process.

I fail to get the message, what is easier to process for a client is
largely subjective or a function of the particular client environment
or what I want to do with the data.

/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] I-D Action: draft-kwatsen-netmod-opstate-02.txt

[Martin Bjorklund]

Robert Wilton  wrote:
> Hi Martin,
> 
> On 08/02/2016 14:38, Martin Bjorklund wrote:
> > Robert Wilton  wrote:
> >> Hi,
> >>
> >> On 05/02/2016 17:34, Juergen Schoenwaelder wrote:
> >>> On Fri, Feb 05, 2016 at 05:22:03PM +, Robert Wilton wrote:
>  2. Personally, for a datastore solution, I would prefer if the new
>  datastore was for the intended configuration, and that the applied
>  configuration was stored in the same datastore (running?) as all the
>  rest of the operational state.
> >>> The running datastore is a configuration datastore, it does not hold
> >>> operational state.
> >> OK.  Thanks for the clarification.  I hadn't realised that the
> >> definition of datastores only applies to configuration and not to
> >> state!
> > No, this is not correct.  RFC 6241 defines both "datastore" and
> > "configuration datastore".  However, "running" is a "configuration
> > datastore".
> OK.  RFC 6241 defines terminology for "datastore", but the body of the
> text only ever seems to ever use the term datastore in the context of
> a "configuration datastore".
> 
> Hence please can you clarify, does the operational state live in a non
> configuration datastore, and if so which one?

Yes, but unfortunately it doesn't have a name, and the only way to get
it with current NETCONF is to do a , which also returns the
running configuration.

> Otherwise, are there
> any other uses of non-configuration datastores by NETCONF?

No, not currently.


/martin

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

Re: [netmod] I-D Action: draft-kwatsen-netmod-opstate-02.txt

[Gert Grammel]

Hi Juergen,

I think the indentation in  our emails play havoc which is confusing me
too. The key point I am making is:

The mapping of what is called intended-config onto data stores would
deserve more detailed discussion. It seems the authors of
draft-kwatsen-netmod-opstate-02.txt had in mind to associate intended-cfg
with the [running] datastore. In my understanding, a failure in applying
[running] to [applied] will update the [running] datastore to reflect
which part is effectively applied. So a fair representation of that case
would be:
[candidate] -> [running] <--> [applied] -> derived state

In the context of intended-configuration however that doesn’t make sense
to me. A failure in applying intended configuration doesn¹t change the
intention and the delta between intended and applied-config is the key
value. A server that would "clean-up" intended-cfg in presence of a
failure to apply would look picture perfect instead of exposing the
problem clearly. Hence the sequence should more look like:
[candidate] -> [intended] ‹-> [running==applied] -> derived state

Whatever we choose, I believe we need to spell out what¹s the data in a
failure case. It¹s probably a bit late to update the requirements draft,
but we can probably find a suitable place.

———


I am also wondring if we have the same understanding related to the
following statement:
I thought the whole point of having an applied config is to be able to
see the difference between intended (oops running) and applied.


The current draft-kwatsen-netmod-opstate-02.txt says:
"Any rollback that may occur will restore both the intended and the
applied configurations to their previous states."


The challenge I have is the term “(oops running)” in the first sentence in
combination with the citation. I reckon that any difference between
intended-config and applied-config shall be visible whereby the
intended-config is provided by the client and never altered by the server.
Applied-config on the other hand represents the state of the server. If a
failure happens in the application phase, it shall be treated accordingly
(rollback-, stop-, continue-on-error). As a result the difference between
intended and applied configuration shall be maintained.
So does this square with the notion "intended=running" and “applied”
config?

- Gert





On 2016-08-02 17:38, "Juergen Schoenwaelder"
 wrote:

>On Mon, Feb 08, 2016 at 02:53:57PM +, Gert Grammel wrote:
>> 
>> 
>> >This is not what is being proposed. We always had
>> >
>> >[candidate] -> [running] -> operational state
>> >
>> >(and I mark configuration data stores in []). Both [candidate] and
>> >[running] have the same configuration data model. Now we are asked
>> >to expose that [running] may not be applied synchronously and hence
>> >
>> >[candidate] -> [running] -> [applied] -> derived state
>> >
>> >seems to make sense.
>
>Why would that be the case? If I configure an interface that is not
>currently present today in running this is just find and running is
>not expected to change arbitrarily.
> 
>> The mapping of what is called intended-config onto data stores would
>> deserve more detailed discussion. It seems the authors of this draft had
>> in mind to associate intended-cfg with the [running] datastore. With
>>that
>> mapping, a failure in applying [running] to [applied] will update the
>> [running] datastore to reflect which part is effectively applied. So a
>> fair representation of that case would be:
>> [candidate] -> [running] <--> [applied] -> derived state
>
>What is 'this draft'? I thought the whole point of having an applied
>config is to be able to see the difference between intended (oops
>running) and applied. I am confused now.
> 
>> In the context of intended configuration however that doesn¹t make sense
>> to me. A failure in applying intended configuration doesn¹t change the
>> intention and the delta between intended and applied-config is the key
>> value. A server that would "clean-up² intended-cfg in presence of a
>> failure to apply would look picture perfect instead of exposing the
>> problem clearly. Hence the sequence should more look like:
>> [candidate] -> [intended] ‹> [running==applied] -> derived state
>> 
>> Whatever we choose, I believe we need to spell out what¹s the data in a
>> failure case. It¹s probably a bit late to update the requirements draft,
>> but we can probably find a suitable place.
>
>There is apparently much less agreement on what the problem is, what
>the terms mean, and how they related to existing technology than I
>thought.
>
>/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] I-D Action: draft-kwatsen-netmod-opstate-02.txt

[Robert Wilton]

On 08/02/2016 16:31, Juergen Schoenwaelder wrote:

On Mon, Feb 08, 2016 at 01:30:02PM +, Robert Wilton wrote:

Hi,

On 05/02/2016 17:34, Juergen Schoenwaelder wrote:

On Fri, Feb 05, 2016 at 05:22:03PM +, Robert Wilton wrote:

2. Personally, for a datastore solution, I would prefer if the new
datastore was for the intended configuration, and that the applied
configuration was stored in the same datastore (running?) as all the
rest of the operational state.

The running datastore is a configuration datastore, it does not hold
operational state.

OK.  Thanks for the clarification.  I hadn't realised that the
definition of datastores only applies to configuration and not to state!

So, am I right in saying that this draft is effectively reclassifying
that definition somewhat - given that applied configuration is being
defined as operational state (at least in the diagram in section 3.
Conceptual model) and datastores don't store state data?

Not sure what 'that definition' refers to. This WG has had lenghty
discussions how we look at operational state has. Some of it is
briefly mentioned in RFC 6244 and there were quite a few presentations
at IETF meetings before 'the operators' started contributing ideas.

I was referring to the definition of Configuration Datastore in RFC-6241.

I had mistakenly thought that the running datastore contained both the 
running configuration and operational state.


You corrected me that the running datastore only contains config, 
although it is still slightly unclear to me whether the operational 
state lives in a datastore or not.




  

If the logical flows of system information is as follows:
  [candidate] -> intended cfg -> applied cfg -> derived state

Then it seems strange to bundle intended cfg & derived state together in
one datastore, and to have applied-cfg separate (a bit like an unwanted
step child).

This is not what is being proposed. We always had

[candidate] -> [running] -> operational state

(and I mark configuration data stores in []). Both [candidate] and
[running] have the same configuration data model. Now we are asked
to expose that [running] may not be applied synchronously and hence

[candidate] -> [running] -> [applied] -> derived state

seems to make sense.

5. Am I correct to presume that this draft doesn't provide any support
to return intended config, applied config & derived state all in a
single request?  I appreciate that this isn't included as a formal
requirement - but part of me wonders whether this might have been an
oversight in the requirements.

Can be defines easily as another RPC. That said, I heard that some big
vendors even refuse to implement today's get operation that returns
the combination of [running] and operational state.

OK, but the key question is what does that returned data look like: Are
the intended and applied config nodes going to be co-located in the same
structure or is the response going to be two separate trees and for it
to be up to the client to merge them together?

  

6. I can understand the decision of get-diff to reuse edit-config or
YANG patch,  but I'm not sure that this makes it particularly easy for
clients to then process that data.  I might be wrong, but I suspect that
a solution that returns the values of the intended and applied config
nodes in an easier to relate way may be preferable (perhaps something
along the lines of the encoding proposed in
draft-wilton-netmod-opstate-yang).

A diff is a way to make delta's efficient.

Yes, but often diffs include both the old and the new values to make it
easier to see what the change is (or certainly they do whenever I review
code diffs).

I don't think that the YANG patch/edit-config encoding is significantly
more efficient that the encoding that I suggested, so I don't think that
efficiency of encoding is a strong argument here.

So if in my 1 million XML elements one has not been applied, how do I
find out efficiently in your encoding?
By using 'diff-cfg-only' option of the  parameter, 
you would get 3 or 4 leaves per mismatching node: (intended value, 
applied value, status, and optionally error reason).  Only nodes with 
differences would be returned.


A more complete example is in 
https://tools.ietf.org/html/draft-wilton-netmod-opstate-yang-02, "A.2.  
NETCONF get-config request using with-config-state with diff-cfg-only 
option", about page 16.


Yes, this data would be larger than the patch, but it also contains more 
information (i.e. reason why they differ, and error string).


The client is also able to process this data straight away.  With the 
patch, they may need to generate the before and after values to make it 
easier to process.






The strongest argument for edit-config and YANG patch is that it is
reusing an existing solution rather than inventing a new way of doing
this.  But I still think that my observation that this doesn't make it
particularly easy for clients is valid, and other ways of encoding the
data could mak

Re: [netmod] I-D Action: draft-kwatsen-netmod-opstate-02.txt

[Juergen Schoenwaelder]

On Mon, Feb 08, 2016 at 02:53:57PM +, Gert Grammel wrote:
> 
> 
> >This is not what is being proposed. We always had
> >
> >[candidate] -> [running] -> operational state
> >
> >(and I mark configuration data stores in []). Both [candidate] and
> >[running] have the same configuration data model. Now we are asked
> >to expose that [running] may not be applied synchronously and hence
> >
> >[candidate] -> [running] -> [applied] -> derived state
> >
> >seems to make sense.

Why would that be the case? If I configure an interface that is not
currently present today in running this is just find and running is
not expected to change arbitrarily.
 
> The mapping of what is called intended-config onto data stores would
> deserve more detailed discussion. It seems the authors of this draft had
> in mind to associate intended-cfg with the [running] datastore. With that
> mapping, a failure in applying [running] to [applied] will update the
> [running] datastore to reflect which part is effectively applied. So a
> fair representation of that case would be:
> [candidate] -> [running] <--> [applied] -> derived state

What is 'this draft'? I thought the whole point of having an applied
config is to be able to see the difference between intended (oops
running) and applied. I am confused now.
 
> In the context of intended configuration however that doesn¹t make sense
> to me. A failure in applying intended configuration doesn¹t change the
> intention and the delta between intended and applied-config is the key
> value. A server that would "clean-up² intended-cfg in presence of a
> failure to apply would look picture perfect instead of exposing the
> problem clearly. Hence the sequence should more look like:
> [candidate] -> [intended] ‹> [running==applied] -> derived state
> 
> Whatever we choose, I believe we need to spell out what¹s the data in a
> failure case. It¹s probably a bit late to update the requirements draft,
> but we can probably find a suitable place.

There is apparently much less agreement on what the problem is, what
the terms mean, and how they related to existing technology than I
thought.

/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] I-D Action: draft-kwatsen-netmod-opstate-02.txt

[Juergen Schoenwaelder]

On Mon, Feb 08, 2016 at 01:30:02PM +, Robert Wilton wrote:
> Hi,
> 
> On 05/02/2016 17:34, Juergen Schoenwaelder wrote:
> >On Fri, Feb 05, 2016 at 05:22:03PM +, Robert Wilton wrote:
> >>2. Personally, for a datastore solution, I would prefer if the new
> >>datastore was for the intended configuration, and that the applied
> >>configuration was stored in the same datastore (running?) as all the
> >>rest of the operational state.
> >The running datastore is a configuration datastore, it does not hold
> >operational state.
> OK.  Thanks for the clarification.  I hadn't realised that the 
> definition of datastores only applies to configuration and not to state!
> 
> So, am I right in saying that this draft is effectively reclassifying 
> that definition somewhat - given that applied configuration is being 
> defined as operational state (at least in the diagram in section 3. 
> Conceptual model) and datastores don't store state data?

Not sure what 'that definition' refers to. This WG has had lenghty
discussions how we look at operational state has. Some of it is
briefly mentioned in RFC 6244 and there were quite a few presentations
at IETF meetings before 'the operators' started contributing ideas.
 
> >>If the logical flows of system information is as follows:
> >>  [candidate] -> intended cfg -> applied cfg -> derived state
> >>
> >>Then it seems strange to bundle intended cfg & derived state together in
> >>one datastore, and to have applied-cfg separate (a bit like an unwanted
> >>step child).
> >This is not what is being proposed. We always had
> >
> >[candidate] -> [running] -> operational state
> >
> >(and I mark configuration data stores in []). Both [candidate] and
> >[running] have the same configuration data model. Now we are asked
> >to expose that [running] may not be applied synchronously and hence
> >
> >[candidate] -> [running] -> [applied] -> derived state
> >
> >seems to make sense.
> >>5. Am I correct to presume that this draft doesn't provide any support
> >>to return intended config, applied config & derived state all in a
> >>single request?  I appreciate that this isn't included as a formal
> >>requirement - but part of me wonders whether this might have been an
> >>oversight in the requirements.
> >Can be defines easily as another RPC. That said, I heard that some big
> >vendors even refuse to implement today's get operation that returns
> >the combination of [running] and operational state.
> OK, but the key question is what does that returned data look like: Are 
> the intended and applied config nodes going to be co-located in the same 
> structure or is the response going to be two separate trees and for it 
> to be up to the client to merge them together?
> 
> >  
> >>6. I can understand the decision of get-diff to reuse edit-config or
> >>YANG patch,  but I'm not sure that this makes it particularly easy for
> >>clients to then process that data.  I might be wrong, but I suspect that
> >>a solution that returns the values of the intended and applied config
> >>nodes in an easier to relate way may be preferable (perhaps something
> >>along the lines of the encoding proposed in
> >>draft-wilton-netmod-opstate-yang).
> >A diff is a way to make delta's efficient.
> Yes, but often diffs include both the old and the new values to make it 
> easier to see what the change is (or certainly they do whenever I review 
> code diffs).
> 
> I don't think that the YANG patch/edit-config encoding is significantly 
> more efficient that the encoding that I suggested, so I don't think that 
> efficiency of encoding is a strong argument here.

So if in my 1 million XML elements one has not been applied, how do I
find out efficiently in your encoding?

> The strongest argument for edit-config and YANG patch is that it is 
> reusing an existing solution rather than inventing a new way of doing 
> this.  But I still think that my observation that this doesn't make it 
> particularly easy for clients is valid, and other ways of encoding the 
> data could make it easier and more useful.

We are on a very slippery slope here - what may be easy for one client
may not be easy for another client. Difficult for taking good
engineering decisions.

/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] I-D Action: draft-kwatsen-netmod-opstate-02.txt

[Robert Wilton]

Hi Martin,

On 08/02/2016 14:38, Martin Bjorklund wrote:

Robert Wilton  wrote:

Hi,

On 05/02/2016 17:34, Juergen Schoenwaelder wrote:

On Fri, Feb 05, 2016 at 05:22:03PM +, Robert Wilton wrote:

2. Personally, for a datastore solution, I would prefer if the new
datastore was for the intended configuration, and that the applied
configuration was stored in the same datastore (running?) as all the
rest of the operational state.

The running datastore is a configuration datastore, it does not hold
operational state.

OK.  Thanks for the clarification.  I hadn't realised that the
definition of datastores only applies to configuration and not to
state!

No, this is not correct.  RFC 6241 defines both "datastore" and
"configuration datastore".  However, "running" is a "configuration
datastore".
OK.  RFC 6241 defines terminology for "datastore", but the body of the 
text only ever seems to ever use the term datastore in the context of a 
"configuration datastore".


Hence please can you clarify, does the operational state live in a non 
configuration datastore, and if so which one?  Otherwise, are there any 
other uses of non-configuration datastores by NETCONF?


Thanks,
Rob

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

Re: [netmod] I-D Action: draft-kwatsen-netmod-opstate-02.txt

[Gert Grammel]

On 2016-05-02 18:34, "netmod on behalf of Juergen Schoenwaelder"
 wrote:

>On Fri, Feb 05, 2016 at 05:22:03PM +, Robert Wilton wrote:
>> 
>> 2. Personally, for a datastore solution, I would prefer if the new
>> datastore was for the intended configuration, and that the applied
>> configuration was stored in the same datastore (running?) as all the
>> rest of the operational state.
>
>The running datastore is a configuration datastore, it does not hold
>operational state.
>
>> If the logical flows of system information is as follows:
>>  [candidate] -> intended cfg -> applied cfg -> derived state
>> 
>> Then it seems strange to bundle intended cfg & derived state together
>>in 
>> one datastore, and to have applied-cfg separate (a bit like an unwanted
>> step child).
>
>This is not what is being proposed. We always had
>
>[candidate] -> [running] -> operational state
>
>(and I mark configuration data stores in []). Both [candidate] and
>[running] have the same configuration data model. Now we are asked
>to expose that [running] may not be applied synchronously and hence
>
>[candidate] -> [running] -> [applied] -> derived state
>
>seems to make sense.

The mapping of what is called intended-config onto data stores would
deserve more detailed discussion. It seems the authors of this draft had
in mind to associate intended-cfg with the [running] datastore. With that
mapping, a failure in applying [running] to [applied] will update the
[running] datastore to reflect which part is effectively applied. So a
fair representation of that case would be:
[candidate] -> [running] <--> [applied] -> derived state


In the context of intended configuration however that doesn¹t make sense
to me. A failure in applying intended configuration doesn¹t change the
intention and the delta between intended and applied-config is the key
value. A server that would "clean-up² intended-cfg in presence of a
failure to apply would look picture perfect instead of exposing the
problem clearly. Hence the sequence should more look like:
[candidate] -> [intended] ‹> [running==applied] -> derived state

Whatever we choose, I believe we need to spell out what¹s the data in a
failure case. It¹s probably a bit late to update the requirements draft,
but we can probably find a suitable place.


>
>> 5. Am I correct to presume that this draft doesn't provide any support
>> to return intended config, applied config & derived state all in a
>> single request?  I appreciate that this isn't included as a formal
>> requirement - but part of me wonders whether this might have been an
>> oversight in the requirements.
>
>Can be defines easily as another RPC. That said, I heard that some big
>vendors even refuse to implement today's get operation that returns
>the combination of [running] and operational state.
> 
>> 6. I can understand the decision of get-diff to reuse edit-config or
>> YANG patch,  but I'm not sure that this makes it particularly easy for
>> clients to then process that data.  I might be wrong, but I suspect
>>that 
>> a solution that returns the values of the intended and applied config
>> nodes in an easier to relate way may be preferable (perhaps something
>> along the lines of the encoding proposed in
>> draft-wilton-netmod-opstate-yang).
>
>A diff is a way to make delta's efficient.
>
>/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

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

Re: [netmod] I-D Action: draft-kwatsen-netmod-opstate-02.txt

[Martin Bjorklund]

Robert Wilton  wrote:
> Hi,
> 
> On 05/02/2016 17:34, Juergen Schoenwaelder wrote:
> > On Fri, Feb 05, 2016 at 05:22:03PM +, Robert Wilton wrote:
> >> 2. Personally, for a datastore solution, I would prefer if the new
> >> datastore was for the intended configuration, and that the applied
> >> configuration was stored in the same datastore (running?) as all the
> >> rest of the operational state.
> > The running datastore is a configuration datastore, it does not hold
> > operational state.
> OK.  Thanks for the clarification.  I hadn't realised that the
> definition of datastores only applies to configuration and not to
> state!

No, this is not correct.  RFC 6241 defines both "datastore" and
"configuration datastore".  However, "running" is a "configuration
datastore".


/martin


> So, am I right in saying that this draft is effectively reclassifying
> that definition somewhat - given that applied configuration is being
> defined as operational state (at least in the diagram in section
> 3. Conceptual model) and datastores don't store state data?
> 
> 
> >> If the logical flows of system information is as follows:
> >>   [candidate] -> intended cfg -> applied cfg -> derived state
> >>
> >> Then it seems strange to bundle intended cfg & derived state together
> >> in
> >> one datastore, and to have applied-cfg separate (a bit like an
> >> unwanted
> >> step child).
> > This is not what is being proposed. We always had
> >
> > [candidate] -> [running] -> operational state
> >
> > (and I mark configuration data stores in []). Both [candidate] and
> > [running] have the same configuration data model. Now we are asked
> > to expose that [running] may not be applied synchronously and hence
> >
> > [candidate] -> [running] -> [applied] -> derived state
> >
> > seems to make sense.
> >> 5. Am I correct to presume that this draft doesn't provide any support
> >> to return intended config, applied config & derived state all in a
> >> single request?  I appreciate that this isn't included as a formal
> >> requirement - but part of me wonders whether this might have been an
> >> oversight in the requirements.
> > Can be defines easily as another RPC. That said, I heard that some big
> > vendors even refuse to implement today's get operation that returns
> > the combination of [running] and operational state.
> OK, but the key question is what does that returned data look like:
> Are the intended and applied config nodes going to be co-located in
> the same structure or is the response going to be two separate trees
> and for it to be up to the client to merge them together?
> 
> >   
> >> 6. I can understand the decision of get-diff to reuse edit-config or
> >> YANG patch,  but I'm not sure that this makes it particularly easy for
> >> clients to then process that data.  I might be wrong, but I suspect
> >> that
> >> a solution that returns the values of the intended and applied config
> >> nodes in an easier to relate way may be preferable (perhaps something
> >> along the lines of the encoding proposed in
> >> draft-wilton-netmod-opstate-yang).
> > A diff is a way to make delta's efficient.
> Yes, but often diffs include both the old and the new values to make
> it easier to see what the change is (or certainly they do whenever I
> review code diffs).
> 
> I don't think that the YANG patch/edit-config encoding is
> significantly more efficient that the encoding that I suggested, so I
> don't think that efficiency of encoding is a strong argument here.
> 
> The strongest argument for edit-config and YANG patch is that it is
> reusing an existing solution rather than inventing a new way of doing
> this.  But I still think that my observation that this doesn't make it
> particularly easy for clients is valid, and other ways of encoding the
> data could make it easier and more useful.
> 
> Rob
> 
> 
> > /js
> >
> 
> ___
> 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] I-D Action: draft-kwatsen-netmod-opstate-02.txt

[Robert Wilton]

Hi,

On 05/02/2016 17:34, Juergen Schoenwaelder wrote:

On Fri, Feb 05, 2016 at 05:22:03PM +, Robert Wilton wrote:

2. Personally, for a datastore solution, I would prefer if the new
datastore was for the intended configuration, and that the applied
configuration was stored in the same datastore (running?) as all the
rest of the operational state.

The running datastore is a configuration datastore, it does not hold
operational state.
OK.  Thanks for the clarification.  I hadn't realised that the 
definition of datastores only applies to configuration and not to state!


So, am I right in saying that this draft is effectively reclassifying 
that definition somewhat - given that applied configuration is being 
defined as operational state (at least in the diagram in section 3. 
Conceptual model) and datastores don't store state data?




If the logical flows of system information is as follows:
  [candidate] -> intended cfg -> applied cfg -> derived state

Then it seems strange to bundle intended cfg & derived state together in
one datastore, and to have applied-cfg separate (a bit like an unwanted
step child).

This is not what is being proposed. We always had

[candidate] -> [running] -> operational state

(and I mark configuration data stores in []). Both [candidate] and
[running] have the same configuration data model. Now we are asked
to expose that [running] may not be applied synchronously and hence

[candidate] -> [running] -> [applied] -> derived state

seems to make sense.

5. Am I correct to presume that this draft doesn't provide any support
to return intended config, applied config & derived state all in a
single request?  I appreciate that this isn't included as a formal
requirement - but part of me wonders whether this might have been an
oversight in the requirements.

Can be defines easily as another RPC. That said, I heard that some big
vendors even refuse to implement today's get operation that returns
the combination of [running] and operational state.
OK, but the key question is what does that returned data look like: Are 
the intended and applied config nodes going to be co-located in the same 
structure or is the response going to be two separate trees and for it 
to be up to the client to merge them together?


  

6. I can understand the decision of get-diff to reuse edit-config or
YANG patch,  but I'm not sure that this makes it particularly easy for
clients to then process that data.  I might be wrong, but I suspect that
a solution that returns the values of the intended and applied config
nodes in an easier to relate way may be preferable (perhaps something
along the lines of the encoding proposed in
draft-wilton-netmod-opstate-yang).

A diff is a way to make delta's efficient.
Yes, but often diffs include both the old and the new values to make it 
easier to see what the change is (or certainly they do whenever I review 
code diffs).


I don't think that the YANG patch/edit-config encoding is significantly 
more efficient that the encoding that I suggested, so I don't think that 
efficiency of encoding is a strong argument here.


The strongest argument for edit-config and YANG patch is that it is 
reusing an existing solution rather than inventing a new way of doing 
this.  But I still think that my observation that this doesn't make it 
particularly easy for clients is valid, and other ways of encoding the 
data could make it easier and more useful.


Rob



/js



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

Re: [netmod] I-D Action: draft-kwatsen-netmod-opstate-02.txt

[Kent Watsen]

On 2/5/16, 7:20 AM, "Gert Grammel"  wrote:

>Hi Kent,
>
>On P.7 the current draft says: "Any rollback that may occur will restore
>both the intended and the applied configurations to their previous states."
>
>It is not clear to me to which phase of the configuration this statement
>refers to. In draft-ietf-netmod-opstate-reqs-04, Asynchronous operation is
>defined as 
>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 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 is updated after the configuration change has been fully
>  effected to all impacted components in the server.
>
>
>The statement "The server MUST update its intended configuration before
>replying to the client indicating whether the request will be processed²,


I think that this statement is/was a mistake.  It should’ve been left open to 
the server to return immediately, as even updating intended can take 3o+ 
seconds on some systems...



>doesn¹t define what to do after responding. I suggest to add the following
>clarification:
>1) in case of a negative response from the Server, the server shall roll
>back the intended config and the applied config shall not be affected.
>2) in case of a positive response from the server, the intended config
>shall remain. Upon failure in applying intended config, only applied
>config is affected according to the error-option (rollback-on-error,
>stop-on-error and continue-on-error)

This does not match my understanding of the desired behavior, nor would I know 
how to implement it without introducing additional API and metadata to 
support/control that approach.

Kent


>Rationale for 1: since the server didn¹t accept a new intended config
>(e.g. due to a syntax error), the original intended config should remain
>untouched.
>Rationale for 2: The intended state is logically owned by the client and a
>server is supposed to align with it. Once a server accepted the intended
>config with a positive response, a failure in the server execution doesn¹t
>affect the intention. It would be the client to modify the intended state
>if the intention changes. The difference between intended and applied
>state is an important source of information for a client. Removing the
>intended state after rollback would nullify the intention rather than
>documenting which applied state differs from its intended state. This is
>also in line with Œcontinue-on-error¹ and Œstop-on-error¹. In both cases
>the difference between intended and applied state is important as changes
>have only partially be applied. Hence the error-option should apply to
>applied-config.
>
>- Gert
>
>
>
>
>On 2016-02-02 18:54, "netmod on behalf of Kent Watsen"
> wrote:
>
>>
>>Hi All,
>>
>>I didn¹t receive the usual announcement CC-ed to the netmod list, so I¹m
>>replying to this one sent to the id-announce list instead.
>>
>>Anyway, this morning I posted -01 of this draft and then shortly after
>>-02 to fix some cleanup items I only noticed after -01 was posted  :ooops:
>>
>>Either way, this update is an overhaul to the original draft posted last
>>September.
>>
>>Kent
>>
>>
>>
>>
>>
>>On 2/2/16, 10:30 AM, "internet-dra...@ietf.org"
>> wrote:
>>
>>>
>>>A New Internet-Draft is available from the on-line Internet-Drafts
>>>directories.
>>>
>>>
>>>Title   : Operational State Enhancements for YANG,
>>>NETCONF, and RESTCONF
>>>Authors : Kent Watsen
>>>  Andy Bierman
>>>  Martin Bjorklund
>>>  Juergen Schoenwaelder
>>> Filename: draft-kwatsen-netmod-opstate-02.txt
>>> Pages   : 27
>>> Date: 2016-02-02
>>>
>>>Abstract:
>>>   This document presents enhancements to YANG, NETCONF, and RESTCONF
>>>   satisfying the requirements set forth in Terminology and Requirements
>>>   for Enhanced Handling of Operational State.
>>>
>>>
>>>The IETF datatracker status page for this draft is:
>>>https://datatracker.ietf.org/doc/draft-kwatsen-netmod-opstate/
>>>
>>>There's also a htmlized version available at:
>>>https://tools.ietf.org/html/draft-kwatsen-netmod-opstate-02
>>>
>>>A diff from the previous version is available at:
>>>https://www.ietf.org/rfcdiff?url2=draft-kwatsen-netmod-opstate-02
>>>
>>>
>>>Please note that it may take a couple of minutes from the time of
>>>submission
>>>until the htmlized version and diff are available at tools.ietf.org.
>>>
>>>Internet-Drafts are also available by anonymous FTP at:
>>>ftp://ftp.ietf.org/internet-drafts/
>>>
>>>___
>>>I-D-Announce mailing list
>>>i-d-annou...@ietf.org
>>>https://

Re: [netmod] I-D Action: draft-kwatsen-netmod-opstate-02.txt

[Juergen Schoenwaelder]

On Fri, Feb 05, 2016 at 05:22:03PM +, Robert Wilton wrote:
> 
> 2. Personally, for a datastore solution, I would prefer if the new 
> datastore was for the intended configuration, and that the applied 
> configuration was stored in the same datastore (running?) as all the 
> rest of the operational state.

The running datastore is a configuration datastore, it does not hold
operational state.

> If the logical flows of system information is as follows:
>  [candidate] -> intended cfg -> applied cfg -> derived state
> 
> Then it seems strange to bundle intended cfg & derived state together in 
> one datastore, and to have applied-cfg separate (a bit like an unwanted 
> step child).

This is not what is being proposed. We always had

[candidate] -> [running] -> operational state

(and I mark configuration data stores in []). Both [candidate] and
[running] have the same configuration data model. Now we are asked
to expose that [running] may not be applied synchronously and hence

[candidate] -> [running] -> [applied] -> derived state

seems to make sense.

> 5. Am I correct to presume that this draft doesn't provide any support 
> to return intended config, applied config & derived state all in a 
> single request?  I appreciate that this isn't included as a formal 
> requirement - but part of me wonders whether this might have been an 
> oversight in the requirements.

Can be defines easily as another RPC. That said, I heard that some big
vendors even refuse to implement today's get operation that returns
the combination of [running] and operational state.
 
> 6. I can understand the decision of get-diff to reuse edit-config or 
> YANG patch,  but I'm not sure that this makes it particularly easy for 
> clients to then process that data.  I might be wrong, but I suspect that 
> a solution that returns the values of the intended and applied config 
> nodes in an easier to relate way may be preferable (perhaps something 
> along the lines of the encoding proposed in 
> draft-wilton-netmod-opstate-yang).

A diff is a way to make delta's efficient.

/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] I-D Action: draft-kwatsen-netmod-opstate-02.txt

[Robert Wilton]

Hi Kent, and other authors,

I've taken a quick look through this draft, and hence have a few 
comments/questions below.  Some of these comments are the same that I 
made in reference to the previous version of this draft.



1. Minor nit: I think that the key point of this solution is that it is 
introducing a new applied configuration datastore, but this draft 
doesn't seem to state that anywhere in the introduction or abstract.  
E.g. the first reference to the applied configuration datastore is in 
section 5.1.



2. Personally, for a datastore solution, I would prefer if the new 
datastore was for the intended configuration, and that the applied 
configuration was stored in the same datastore (running?) as all the 
rest of the operational state.


If the logical flows of system information is as follows:
 [candidate] -> intended cfg -> applied cfg -> derived state

Then it seems strange to bundle intended cfg & derived state together in 
one datastore, and to have applied-cfg separate (a bit like an unwanted 
step child).



3. For the related-state statement, I think that this statement would be 
better as related-config and expressed in the reverse direction.


To give a contrived example of problems with related-state based on the 
example in 4.1.1:


Say I defined a new module that augments the ex-interfaces module that 
provides some further operational state for an interface.  In my 
specific example it wants to report the actual L2 MTU/MRU values 
programmed in the hardware.  (This could differ from a configured MTU to 
take into vary 802.1Q VLAN tag overheads or perhaps other slop).


 module ex-controller {
 namespace "http://example.com/controller";;
 prefix ctrlr;

 import ex-interface {
   prefix ex-if;
 }

 import ietf-yang-related-state {
   prefix yrs;
 }

 // Standard module definition.
 augment "/ex-if:interfaces/ex-if:interface-state" {
   when "if:type = 'ianaift:ethernetCsmacd'";

   leaf hardware-mru {
 type { uint16; }
 description "Actual MRU programmed in hardware";
   }
   leaf hardware-mtu {
 type { uint16; }
 description "Actual MTU programmed in hardware";
   }
 }

 // Separate augmentation required for each related-state
 // statement.
 augment "/ex-if:interfaces/ex-if:interface/ex-if:mtu" {
   when "if:type = 'ianaift:ethernetCsmacd'";
   yrs:related-state
"/interfaces-state/interface/name=current()/name/hardware-mtu";
 }

 // Separate augmentation required for each related-state
 // statement.
 augment "/ex-if:interfaces/ex-if:interface/ex-if:mtu" {
   when "if:type = 'ianaift:ethernetCsmacd'";
   yrs:related-state
"/interfaces-state/interface/name=current()/name/hardware-mru";
 }
   }

Here you will see that I would need a separate augmentation statement to 
set up every related-state binding.  Further, YANG would need to be 
modified to even allow such an augmentation of a leaf.


If you reverse the sense of the binding to "related-config" then I think 
that these problems disappear.



4. For section 5.4, get-state operation, it might be useful to clarify 
that if neither of the applied/derived options are specified then the 
data that is returned covers both the applied configuration and derived 
state (i.e. the data that is returned spans two datastores).



5. Am I correct to presume that this draft doesn't provide any support 
to return intended config, applied config & derived state all in a 
single request?  I appreciate that this isn't included as a formal 
requirement - but part of me wonders whether this might have been an 
oversight in the requirements.



6. I can understand the decision of get-diff to reuse edit-config or 
YANG patch,  but I'm not sure that this makes it particularly easy for 
clients to then process that data.  I might be wrong, but I suspect that 
a solution that returns the values of the intended and applied config 
nodes in an easier to relate way may be preferable (perhaps something 
along the lines of the encoding proposed in 
draft-wilton-netmod-opstate-yang).


Thanks,
Rob


On 02/02/2016 17:54, Kent Watsen wrote:

Hi All,

I didn’t receive the usual announcement CC-ed to the netmod list, so I’m 
replying to this one sent to the id-announce list instead.

Anyway, this morning I posted -01 of this draft and then shortly after -02 to 
fix some cleanup items I only noticed after -01 was posted  :ooops:

Either way, this update is an overhaul to the original draft posted last 
September.

Kent





On 2/2/16, 10:30 AM, "internet-dra...@ietf.org"  
wrote:


A New Internet-Draft is available from the on-line Internet-Drafts directories.


Title   : Operational State Enhancements for YANG, NETCONF, and 
RESTCONF
Authors : Kent Watsen
  Andy Bierman
  Martin Bjorklund
  Juergen Schoenwaelder
   

Re: [netmod] I-D Action: draft-kwatsen-netmod-opstate-02.txt

[Gert Grammel]

Hi Kent,

On P.7 the current draft says: "Any rollback that may occur will restore
both the intended and the applied configurations to their previous states."

It is not clear to me to which phase of the configuration this statement
refers to. In draft-ietf-netmod-opstate-reqs-04, Asynchronous operation is
defined as 
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 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 is updated after the configuration change has been fully
  effected to all impacted components in the server.


The statement "The server MUST update its intended configuration before
replying to the client indicating whether the request will be processed²,
doesn¹t define what to do after responding. I suggest to add the following
clarification:
1) in case of a negative response from the Server, the server shall roll
back the intended config and the applied config shall not be affected.
2) in case of a positive response from the server, the intended config
shall remain. Upon failure in applying intended config, only applied
config is affected according to the error-option (rollback-on-error,
stop-on-error and continue-on-error)

Rationale for 1: since the server didn¹t accept a new intended config
(e.g. due to a syntax error), the original intended config should remain
untouched.
Rationale for 2: The intended state is logically owned by the client and a
server is supposed to align with it. Once a server accepted the intended
config with a positive response, a failure in the server execution doesn¹t
affect the intention. It would be the client to modify the intended state
if the intention changes. The difference between intended and applied
state is an important source of information for a client. Removing the
intended state after rollback would nullify the intention rather than
documenting which applied state differs from its intended state. This is
also in line with Œcontinue-on-error¹ and Œstop-on-error¹. In both cases
the difference between intended and applied state is important as changes
have only partially be applied. Hence the error-option should apply to
applied-config.

- Gert




On 2016-02-02 18:54, "netmod on behalf of Kent Watsen"
 wrote:

>
>Hi All,
>
>I didn¹t receive the usual announcement CC-ed to the netmod list, so I¹m
>replying to this one sent to the id-announce list instead.
>
>Anyway, this morning I posted -01 of this draft and then shortly after
>-02 to fix some cleanup items I only noticed after -01 was posted  :ooops:
>
>Either way, this update is an overhaul to the original draft posted last
>September.
>
>Kent
>
>
>
>
>
>On 2/2/16, 10:30 AM, "internet-dra...@ietf.org"
> wrote:
>
>>
>>A New Internet-Draft is available from the on-line Internet-Drafts
>>directories.
>>
>>
>>Title   : Operational State Enhancements for YANG,
>>NETCONF, and RESTCONF
>>Authors : Kent Watsen
>>  Andy Bierman
>>  Martin Bjorklund
>>  Juergen Schoenwaelder
>>  Filename: draft-kwatsen-netmod-opstate-02.txt
>>  Pages   : 27
>>  Date: 2016-02-02
>>
>>Abstract:
>>   This document presents enhancements to YANG, NETCONF, and RESTCONF
>>   satisfying the requirements set forth in Terminology and Requirements
>>   for Enhanced Handling of Operational State.
>>
>>
>>The IETF datatracker status page for this draft is:
>>https://datatracker.ietf.org/doc/draft-kwatsen-netmod-opstate/
>>
>>There's also a htmlized version available at:
>>https://tools.ietf.org/html/draft-kwatsen-netmod-opstate-02
>>
>>A diff from the previous version is available at:
>>https://www.ietf.org/rfcdiff?url2=draft-kwatsen-netmod-opstate-02
>>
>>
>>Please note that it may take a couple of minutes from the time of
>>submission
>>until the htmlized version and diff are available at tools.ietf.org.
>>
>>Internet-Drafts are also available by anonymous FTP at:
>>ftp://ftp.ietf.org/internet-drafts/
>>
>>___
>>I-D-Announce mailing list
>>i-d-annou...@ietf.org
>>https://www.ietf.org/mailman/listinfo/i-d-announce
>>Internet-Draft directories: http://www.ietf.org/shadow.html
>>or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>>
>___
>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] I-D Action: draft-kwatsen-netmod-opstate-02.txt

[Kent Watsen]

Hi All,

I didn’t receive the usual announcement CC-ed to the netmod list, so I’m 
replying to this one sent to the id-announce list instead.

Anyway, this morning I posted -01 of this draft and then shortly after -02 to 
fix some cleanup items I only noticed after -01 was posted  :ooops:

Either way, this update is an overhaul to the original draft posted last 
September.

Kent





On 2/2/16, 10:30 AM, "internet-dra...@ietf.org"  
wrote:

>
>A New Internet-Draft is available from the on-line Internet-Drafts directories.
>
>
>Title   : Operational State Enhancements for YANG, NETCONF, 
> and RESTCONF
>Authors : Kent Watsen
>  Andy Bierman
>  Martin Bjorklund
>  Juergen Schoenwaelder
>   Filename: draft-kwatsen-netmod-opstate-02.txt
>   Pages   : 27
>   Date: 2016-02-02
>
>Abstract:
>   This document presents enhancements to YANG, NETCONF, and RESTCONF
>   satisfying the requirements set forth in Terminology and Requirements
>   for Enhanced Handling of Operational State.
>
>
>The IETF datatracker status page for this draft is:
>https://datatracker.ietf.org/doc/draft-kwatsen-netmod-opstate/
>
>There's also a htmlized version available at:
>https://tools.ietf.org/html/draft-kwatsen-netmod-opstate-02
>
>A diff from the previous version is available at:
>https://www.ietf.org/rfcdiff?url2=draft-kwatsen-netmod-opstate-02
>
>
>Please note that it may take a couple of minutes from the time of submission
>until the htmlized version and diff are available at tools.ietf.org.
>
>Internet-Drafts are also available by anonymous FTP at:
>ftp://ftp.ietf.org/internet-drafts/
>
>___
>I-D-Announce mailing list
>i-d-annou...@ietf.org
>https://www.ietf.org/mailman/listinfo/i-d-announce
>Internet-Draft directories: http://www.ietf.org/shadow.html
>or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod