On 10/02/2016 12:42, Juergen Schoenwaelder wrote:
On Mon, Feb 08, 2016 at 04:59:42PM +0000, 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 <with-config-state> 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 <startup/> and
<running/>? How do I get the diff between <candidate/> and <running/>?
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
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
