Re: [netmod] a few comments on draft-wilton-netmod-opstate-yang

[Juergen Schoenwaelder]

This I-D seems to break core design assumptions of YANG data encoding
works and hence it seems to break all existing implementations. If you
define

  leaf mtu { type uint32; }

then this is encoded as

  9000

and there is not room for mixed content. I am stictly against any
solution that is not backwards compatible.

/js

On Thu, Feb 04, 2016 at 05:31:54PM -0500, Lou Berger wrote:
> Hello,
> 
> A few of us in the routing area architecture yang DT discussed
> this draft yesterday and had a couple of comments, (note that the
> open config contributors who are members of the design team did
> not participate in this discussion):
> 
> - that with tooling, it is possible for the models available
> using your extension have important similarities to the model
> conventions proposed by open config. We think it would be worth
> mentioning that tooling extensions could be used to auto generate
> both yang and tree formats that would be effectively available
> using the extension.
> 
> - we think there is significant value in having a tools based
> approach which uses existing models, and which keeps config nodes
> in unmodified locations. Chris Hopps came up with the idea of a
> minor change to your extension where instead of adding 4 new
> config leaf values cfg-* replacing the original leaf, the three
> new leaf values would be added underneath a sibling node, perhaps
> called -cfg.  The benefit of this is that user code would be
> the same with respect to intended config with or without your
> extension. This also addresses the list index problem.
> 
> - also from Chris: it would be useful to have a way of retrieving
> intended config along with any applied config that differs from
> the intended config, e.g. with-config-state=intended+diff-cfg.
> 
> Thoughts?
> 
> Lou (with Chris)
> 
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

-- 
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] a few comments on draft-wilton-netmod-opstate-yang

[Robert Wilton]

Hi Juergen,

I don't really follow your point.

The solution is fully backward compatible - in that only clients that 
make use of the protocol extension would see the new encoding. Existing 
clients would continue to see the encoding as directly defined in the 
YANG schema, and a server would be able to support old and new clients 
concurrently.


Rob


On 05/02/2016 09:50, Juergen Schoenwaelder wrote:

This I-D seems to break core design assumptions of YANG data encoding
works and hence it seems to break all existing implementations. If you
define

   leaf mtu { type uint32; }

then this is encoded as

   9000

and there is not room for mixed content. I am stictly against any
solution that is not backwards compatible.

/js

On Thu, Feb 04, 2016 at 05:31:54PM -0500, Lou Berger wrote:

Hello,

A few of us in the routing area architecture yang DT discussed
this draft yesterday and had a couple of comments, (note that the
open config contributors who are members of the design team did
not participate in this discussion):

- that with tooling, it is possible for the models available
using your extension have important similarities to the model
conventions proposed by open config. We think it would be worth
mentioning that tooling extensions could be used to auto generate
both yang and tree formats that would be effectively available
using the extension.

- we think there is significant value in having a tools based
approach which uses existing models, and which keeps config nodes
in unmodified locations. Chris Hopps came up with the idea of a
minor change to your extension where instead of adding 4 new
config leaf values cfg-* replacing the original leaf, the three
new leaf values would be added underneath a sibling node, perhaps
called -cfg.  The benefit of this is that user code would be
the same with respect to intended config with or without your
extension. This also addresses the list index problem.

- also from Chris: it would be useful to have a way of retrieving
intended config along with any applied config that differs from
the intended config, e.g. with-config-state=intended+diff-cfg.

Thoughts?

Lou (with Chris)

___
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] a few comments on draft-wilton-netmod-opstate-yang

[Martin Bjorklund]

Juergen Schoenwaelder  wrote:
> This I-D seems to break core design assumptions of YANG data encoding
> works and hence it seems to break all existing implementations. If you
> define
> 
>   leaf mtu { type uint32; }
> 
> then this is encoded as
> 
>   9000
> 
> and there is not room for mixed content. I am stictly against any
> solution that is not backwards compatible.

It is backwards compatible in the sense that the client has to
explicitly ask for this new encoding from the server.  However, the
solution requires new code paths for encoding/decoding the data.
Interactions with subfiltering is also a bit unclear.


But I have another observation.  Just like
draft-kwatsen-netmod-opstate, this solution makes the assumption that
the server internally has knowledge of "applied" vs. "intended" values
for data modelled as config true.  The two solutions differ in the way
this data is requested and encoded.

I would argue (no surprise here) that the encoding proposed in
draft-kwatsen-netmod-opstate is much simpler.



/martin





> 
> /js
> 
> On Thu, Feb 04, 2016 at 05:31:54PM -0500, Lou Berger wrote:
> > Hello,
> > 
> > A few of us in the routing area architecture yang DT discussed
> > this draft yesterday and had a couple of comments, (note that the
> > open config contributors who are members of the design team did
> > not participate in this discussion):
> > 
> > - that with tooling, it is possible for the models available
> > using your extension have important similarities to the model
> > conventions proposed by open config. We think it would be worth
> > mentioning that tooling extensions could be used to auto generate
> > both yang and tree formats that would be effectively available
> > using the extension.
> > 
> > - we think there is significant value in having a tools based
> > approach which uses existing models, and which keeps config nodes
> > in unmodified locations. Chris Hopps came up with the idea of a
> > minor change to your extension where instead of adding 4 new
> > config leaf values cfg-* replacing the original leaf, the three
> > new leaf values would be added underneath a sibling node, perhaps
> > called -cfg.  The benefit of this is that user code would be
> > the same with respect to intended config with or without your
> > extension. This also addresses the list index problem.
> > 
> > - also from Chris: it would be useful to have a way of retrieving
> > intended config along with any applied config that differs from
> > the intended config, e.g. with-config-state=intended+diff-cfg.
> > 
> > Thoughts?
> > 
> > Lou (with Chris)
> > 
> > ___
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
> 
> -- 
> 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] a few comments on draft-wilton-netmod-opstate-yang

[Robert Wilton]

Hi Lou (& Chris),

Thanks for the comments.

On 04/02/2016 22:31, Lou Berger wrote:

Hello,

A few of us in the routing area architecture yang DT discussed
this draft yesterday and had a couple of comments, (note that the
open config contributors who are members of the design team did
not participate in this discussion):

- that with tooling, it is possible for the models available
using your extension have important similarities to the model
conventions proposed by open config. We think it would be worth
mentioning that tooling extensions could be used to auto generate
both yang and tree formats that would be effectively available
using the extension.

Yes.

I've not considered it in detail, but using tooling extensions it may be 
possible to get even closer to the OpenConfig structure/conventions if 
required.  E.g. something roughly along the lines of every "config true" 
leaf gets put into a config container and state container, state leaves 
just go in a state container, interfaces & interfaces-state could be 
merged similarly, etc. Of course this would be more complex that the 
approach proposed in the draft.




- we think there is significant value in having a tools based
approach which uses existing models, and which keeps config nodes
in unmodified locations. Chris Hopps came up with the idea of a
minor change to your extension where instead of adding 4 new
config leaf values cfg-* replacing the original leaf, the three
new leaf values would be added underneath a sibling node, perhaps
called -cfg.  The benefit of this is that user code would be
the same with respect to intended config with or without your
extension. This also addresses the list index problem.
Yes, there is still a possible naming clash if a model already had a 
config leaf called "-cfg".


Possibly this could be mitigated by putting the additional meta data 
leaves in a separate namespace, or perhaps the pragmatic approach would 
be to say don't allow leaves to be called "-cfg"!


The reasoning for the approach documented in the draft is that I 
perceive that it is cleaner for client that want the intended vs applied 
split, but agree that the approach that Chris suggests could make 
backwards compatibility easier for clients.




- also from Chris: it would be useful to have a way of retrieving
intended config along with any applied config that differs from
the intended config, e.g. with-config-state=intended+diff-cfg.
Yes, I think that such filters should be fairly easy to define and 
implement.  I.e. if there is a scheme in place for returning the 
intended and applied values it should be quite straight forward on the 
server side to filter which elements are returned for a particular request.


Thanks,
Rob




Thoughts?

Lou (with Chris)

.



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

Re: [netmod] a few comments on draft-wilton-netmod-opstate-yang

[Lou Berger]

Rob,
Thanks for the response, see below.


On February 5, 2016 6:36:47 AM Robert Wilton  wrote:


Hi Lou (& Chris),

Thanks for the comments.

On 04/02/2016 22:31, Lou Berger wrote:

Hello,

A few of us in the routing area architecture yang DT discussed
this draft yesterday and had a couple of comments, (note that the
open config contributors who are members of the design team did
not participate in this discussion):

- that with tooling, it is possible for the models available
using your extension have important similarities to the model
conventions proposed by open config. We think it would be worth
mentioning that tooling extensions could be used to auto generate
both yang and tree formats that would be effectively available
using the extension.

Yes.

I've not considered it in detail, but using tooling extensions it may be
possible to get even closer to the OpenConfig structure/conventions if
required.  E.g. something roughly along the lines of every "config true"
leaf gets put into a config container and state container, state leaves
just go in a state container, interfaces & interfaces-state could be
merged similarly, etc. Of course this would be more complex that the
approach proposed in the draft.



While achieving closer alignment with the layout proposed in the open 
config draft is certainly possible, that is not where we were headed. Our 
point was that with a modification to pyang it would be trivial to show the 
tree that would result with your proposal as well as, with a little more 
tooling work, auto generate additional leaves / information. -- and that 
would be generally helpful. I can see how this would be useful during model 
discussion and development, as well as facilitate certain implementation 
approaches. I was not proposing any meaningful change to the Yang that 
would be provided by the server running your extension in this bullet.





- we think there is significant value in having a tools based
approach which uses existing models, and which keeps config nodes
in unmodified locations. Chris Hopps came up with the idea of a
minor change to your extension where instead of adding 4 new
config leaf values cfg-* replacing the original leaf, the three
new leaf values would be added underneath a sibling node, perhaps
called -cfg.  The benefit of this is that user code would be
the same with respect to intended config with or without your
extension. This also addresses the list index problem.

Yes, there is still a possible naming clash if a model already had a
config leaf called "-cfg".

Possibly this could be mitigated by putting the additional meta data
leaves in a separate namespace, or perhaps the pragmatic approach would
be to say don't allow leaves to be called "-cfg"!



I think keeping things as simple as possible is a good idea. Perhaps to 
even further reduce the possibility of naming conflict use something like 
-metadata rather than -cfg.



The reasoning for the approach documented in the draft is that I
perceive that it is cleaner for client that want the intended vs applied
split, but agree that the approach that Chris suggests could make
backwards compatibility easier for clients.



Keep in mind that this is a user in this case. His argument for minimizing 
deltas/ maximizing similarity resonates with me. I can also see how this 
change would make things a bit easier on the server side.




- also from Chris: it would be useful to have a way of retrieving
intended config along with any applied config that differs from
the intended config, e.g. with-config-state=intended+diff-cfg.

Yes, I think that such filters should be fairly easy to define and
implement.  I.e. if there is a scheme in place for returning the
intended and applied values it should be quite straight forward on the
server side to filter which elements are returned for a particular request.



Excellent.

Thanks for the response,

Lou

Thanks,
Rob




Thoughts?

Lou (with Chris)

.







___
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 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] a few comments on draft-wilton-netmod-opstate-yang

[Juergen Schoenwaelder]

On Fri, Feb 05, 2016 at 10:09:37AM +, Robert Wilton wrote:
> Hi Juergen,
> 
> I don't really follow your point.
> 
> The solution is fully backward compatible - in that only clients that 
> make use of the protocol extension would see the new encoding. Existing 
> clients would continue to see the encoding as directly defined in the 
> YANG schema, and a server would be able to support old and new clients 
> concurrently.
>

The YANG RFC details how data is encoded in XML. People have written
and deployed code against based on this RFC. I do not accept an
approach where an RPC option can simply request that the encoding
defined in the YANG RFC is ignored and replaced with a very different
encoding.

/js (stating a clear opinion as a technical contributor)

-- 
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] a few comments on draft-wilton-netmod-opstate-yang

[Lou Berger]

Juergen,

How do you feel about the proposed modification on the table? (Leaving the  
model defined config leaves untouched and adding a -CFG or -metadata 
sibling node which would contain the additional automatically generated 
leaves.)


Lou


On February 5, 2016 7:24:29 AM Juergen Schoenwaelder 
 wrote:



On Fri, Feb 05, 2016 at 10:09:37AM +, Robert Wilton wrote:

Hi Juergen,

I don't really follow your point.

The solution is fully backward compatible - in that only clients that
make use of the protocol extension would see the new encoding. Existing
clients would continue to see the encoding as directly defined in the
YANG schema, and a server would be able to support old and new clients
concurrently.



The YANG RFC details how data is encoded in XML. People have written
and deployed code against based on this RFC. I do not accept an
approach where an RPC option can simply request that the encoding
defined in the YANG RFC is ignored and replaced with a very different
encoding.

/js (stating a clear opinion as a technical contributor)

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

[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

[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] a few comments on draft-wilton-netmod-opstate-yang

[Juergen Schoenwaelder]

Lou,

there are things I find fundamentally flawed and things I find
somewhat flawed. I do not understand why we need to mess around with
data encodings at all. I do not see what gets simpler by messing
around with the data encodings. Engineering decisions are usually
cost/benefit tradeoffs. I see the costs, I am unsure about the
benefits.

/js

On Fri, Feb 05, 2016 at 07:52:33AM -0500, Lou Berger wrote:
> Juergen,
> 
> How do you feel about the proposed modification on the table? (Leaving the  
> model defined config leaves untouched and adding a -CFG or -metadata 
> sibling node which would contain the additional automatically generated 
> leaves.)
> 
> Lou
> 
> 
> On February 5, 2016 7:24:29 AM Juergen Schoenwaelder 
>  wrote:
> 
> >On Fri, Feb 05, 2016 at 10:09:37AM +, Robert Wilton wrote:
> >>Hi Juergen,
> >>
> >>I don't really follow your point.
> >>
> >>The solution is fully backward compatible - in that only clients that
> >>make use of the protocol extension would see the new encoding. Existing
> >>clients would continue to see the encoding as directly defined in the
> >>YANG schema, and a server would be able to support old and new clients
> >>concurrently.
> >>
> >
> >The YANG RFC details how data is encoded in XML. People have written
> >and deployed code against based on this RFC. I do not accept an
> >approach where an RPC option can simply request that the encoding
> >defined in the YANG RFC is ignored and replaced with a very different
> >encoding.
> >
> >/js (stating a clear opinion as a technical contributor)
> >
> >--
> >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
> >
> 
> 

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

[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] a few comments on draft-wilton-netmod-opstate-yang

[Andy Bierman]

On Fri, Feb 5, 2016 at 4:23 AM, Juergen Schoenwaelder <
j.schoenwael...@jacobs-university.de> wrote:

> On Fri, Feb 05, 2016 at 10:09:37AM +, Robert Wilton wrote:
> > Hi Juergen,
> >
> > I don't really follow your point.
> >
> > The solution is fully backward compatible - in that only clients that
> > make use of the protocol extension would see the new encoding. Existing
> > clients would continue to see the encoding as directly defined in the
> > YANG schema, and a server would be able to support old and new clients
> > concurrently.
> >
>
> The YANG RFC details how data is encoded in XML. People have written
> and deployed code against based on this RFC. I do not accept an
> approach where an RPC option can simply request that the encoding
> defined in the YANG RFC is ignored and replaced with a very different
> encoding.
>
>
+1

I brought this up awhile back.

Not only is the YANG schema replaced by some "formula", there is no
indication
in the  at all that this is being done.  Only the sender of the
 knows
that the special encoding rules are used instead of the YANG rules.
IMO, this solution is a non-starter.



> /js (stating a clear opinion as a technical contributor)
>
> --
> Juergen Schoenwaelder   Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103 
>
>

Andy



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