Hi Martin, thank you for your comments! Please see replies inline, <ALEX>
--- Alex > -----Original Message----- > From: netmod <[email protected]> On Behalf Of Martin Bjorklund > Sent: Thursday, February 20, 2020 8:59 AM > To: [email protected] > Cc: [email protected]; [email protected] > Subject: Re: [netmod] WGLC - Comparison of NMDA datastores - draft-ietf- > netmod-nmda-diff-03 > > Hi, > > Joel Jaeggli <[email protected]> wrote: > > Greetings, > > > > This was supposed to get processed shortly after IETF 106, however I lost > track of it. We are therefore running a 2 week WGLC on draft-ietf-netmod- > nmda-diff-03. > > > > > https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatr > acker.ietf.org%2Fdoc%2Fdraft-ietf-netmod-nmda- > diff%2F&data=02%7C01%7Calex%40futurewei.com%7C2a7d8572a82d4d > c6fb8208d7b6263e8c%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C6 > 37178147700288369&sdata=z8dXlaWjYttnG2vFn8YWLzld3i2TpQoMkHXks > I9xm%2Bc%3D&reserved=0 > > > > the 02 - 03 diff is available here: > > > > > https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.i > etf.org%2Frfcdiff%3Furl1%3Ddraft-ietf-netmod-nmda-diff- > 02%26url2%3Ddraft-ietf-netmod-nmda-diff- > 03&data=02%7C01%7Calex%40futurewei.com%7C2a7d8572a82d4dc6fb8 > 208d7b6263e8c%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C63717 > 8147700298323&sdata=1uye5dZqb7dhIJ5DZaGb4yChrLD6BUCg8R%2BwK > Pvnlm4%3D&reserved=0 > > > > Please send email to the list indicating your support or concerns. > > > I have reviewed draft-ietf-netmod-nmda-diff-03 and have some comments. > > o Section 4 > > (The filter dow not contain expressions that > would match values data nodes, as this is not required by most use > cases and would complicate the scheme, from implementation to > dealing with race conditions.) > > I don't think it is a good idea to reject filters that match > values. For example, suppose I want to compare the config for a > specific interface. I could do /interfaces/interfac[name='eth0'], > or a subtree filter. Why should this not be possible? > > Besides, the mechanism of rejecting such filters is not defined. > The only text we have is this sentence within parentheses. > <ALEX> In my response to Juergen, I suggested to simply remove the text in the parantheses as it is apparently confusing. Our intent was to keep it simple and simply use the filter to "scope" the operation. If we want to include matching values, things get a bit more complex with no clear benefit (when you would even want to specify such filter), but admittedly we were thinking of e.g. rapidly changing operational data. For example, what if the value matches in the source but not the target, or vice versa - do we need to specify which one we mean (source, target, or any)? There are also the mentioned "race conditions" if snap shots are taken at different times - although I guess those would be implementation limitations. That said, we can of course add it in if you do feel we should have that option (and we don't get objections). You are correct that we should specify an error for rejecting the filter. </ALEX> > > o leaf all in the YANG module > > s/Specifically, if one/For example, if one/ > <ALEX> Changed </ALEX> > > o leaf xpath-filter > > The description needs to specify the XPath context, see RFC 6991. > <ALEX> Not sure what we need to be done here; the leaf uses the type definition from RFC 6991 (i.t. type yang:xpath1.0); is there anything else - please advise </ALEX> > > o container differences > > It is not clear what the YANG patch records reflect. Is it the > patches that are required to go from "source" to "target"? Or the > other way around? > <ALEX> It is from source to target. This is stated e.g. here: "The YANG-Patch data model is augmented to indicate the value of source datastore nodes in addition to the patch itself that would need to be applied to the source to produce the target." I updated the description in the container "differences" as follows: " "The list of differences, encoded per RFC8072, indicating the patches that need to be applied to the source in order to arrive at the target, with an augmentation to include source values where applicable.";" </ALEX> > > o anydata source-value > > This description needs work. The current text isn't correct > ('value' is not present when the operation is 'move'). > > The description should explain what this is supposed to contain. > <ALEX> When the operation is 'move', we want to be able to indicate the order prior to the move. What would you call it? </ALEX> > > o Section 6 > > The example is confusing. It seems the diff is the patches required > to go from target to source. And the source-value contains the > origin present in the target, is that correct? And the value > contains an origin that isn't present in neither the source nor the > target. > <ALEX> We will review the example to ensure it's correct; will get back to you on that tomorrow. The diff contains the patches to go from source to target, ie the patches that, when applied to source, give you the target. Thanks again for your review! </ALEX> > > > /martin > > _______________________________________________ > netmod mailing list > [email protected] > https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.i > etf.org%2Fmailman%2Flistinfo%2Fnetmod&data=02%7C01%7Calex%40fu > turewei.com%7C2a7d8572a82d4dc6fb8208d7b6263e8c%7C0fee8ff2a3b24018 > 9c753a1d5591fedc%7C1%7C0%7C637178147700298323&sdata=W1xgXQS > lSzklkBAE1m324pwfJHnS%2B88OschqnJDdEBw%3D&reserved=0 _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
