Subject: Re: [Netconf] New revision of "Discrepancy detection between NMDA datastores" (draft-clemm-netconf-nmda-diff-02)

From: Yingzhen Qu <[email-masked]>
Date: Thu, 1 Mar 2018 19:23:00 +0000

Ho Joergen,

Thanks for the comments. Please see my answers below starting with “YQ”.

Thanks,
Yingzhen

On 2/24/18, 6:57 AM, "Juergen Schoenwaelder" <[email-masked]> wrote:

    Hi,
    
    I do not like the term "discrepancy detection" or "comparing
    discrepancies"; I think this is really just a datastore compare
    operation. The abstract should simply start with:
    
  This document defines an RPC operation to compare datastores.
  [YQ]: I’m ok with the suggested change. 
    
    Avoid talking about capability since capabilities have a special
    meaning. The 'set of RPCs' seems to have size one (and we usually
  write NETCONF and RESTCONF).
  [YQ]: will correct this in next version.
    
    You may have to think what you include in the comparion, in particular
    when we consider <operational>. If you compare <operational> with
    <intended>, you likely want to skip over all "config false" nodes and
  you may want to skip over nodes that have a "non-suitable" origin.
  [YQ]: I’d like to get more feedbacks from the WG on this question. 
    
    I share Andy's concerns about cmp-dampening - perhaps it is best to
    leave this for vendor extensions for a first version of this. (It is
    also not exactly clear how this would work, what about stuff that is
    changing during the dampening period?)
  [YQ]: right now “cmp-dampening” is defined as a feature, so it’s optional to implementations. But if the WG decides this is not needed, we’ll remove it.
  
    Some of the references do not seem to be needed (did not find
  citations for them).
  [YQ]: will fix this in next version of the draft.
    
    /js
    
    On Fri, Feb 23, 2018 at 09:18:51PM +0000, Alexander Clemm wrote:
    > Hello Netconf WG,
    > 
    > we posted a new revision of "Discrepancy detection between NMDA datastores" earlier today (https://tools.ietf.org/html/draft-clemm-netconf-nmda-diff-02).  This concerns a straightforward extension to NMDA with a facility that will make troubleshooting and diagnosing error scenarios rooted in inconsistencies between different datastores easier.  The new revision contains some instantiated examples which the previous revisions did not.  At the previous IETF, there seemed to be considerable support for the draft in the room.  We would therefore like to ask for WG adoption.
    > 
    > Thanks
    > --- Alex (on behalf of coauthors - Yingzhen, Jeff)
    
    > _______________________________________________
    > Netconf mailing list
    > [email-masked]
    > https://www.ietf.org/mailman/listinfo/netconf

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

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 01 Mar 2018 21:05:12 +0100 (CET)

Hi,

>   [YQ]: I’d like to get more feedbacks from the WG on this question. 

I agree with Juergen.  If one datastore has config true + config
false, and the other just config true, it is not very interesting to
get the config false nodes.  In general, when comparing datastores
that have different schemas, you probably don't want to return nodes
that we know can only be present in one of the datastores.

Maybe have a general rule to only include nodes that can be
instantiated (under some circumstances) in both datastores.

>   [YQ]: right now “cmp-dampening” is defined as a feature, so it’s optional to implementations. But if the WG decides this is not needed, we’ll remove it.

I also would prefer to leave dampening out.

/martin

---

From: Mahesh Jethanandani <[email-masked]>
Date: Thu, 1 Mar 2018 20:43:07 -0800

> On Mar 1, 2018, at 12:05 PM, Martin Bjorklund <[email-masked]> wrote:
> 
> Hi,
> 

I would agree. You want to compare apples to apples. No point comparing something that does not exist in one datastore only.

mahesh //as contributor.