Hello Erik, thank you for your review. Please see my responses inline below.
Thanks --- Alex On 7/6/2021 4:59 PM, Erik Kline via Datatracker wrote: > Erik Kline has entered the following ballot position for > draft-ietf-netmod-nmda-diff-09: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-netmod-nmda-diff/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > [S5] [question] > > * In the output yang-patch response when differences are present, is it > theoretically possible that 'create' or 'insert' operations will need > to be represented? If not, why not? <ALEX> The yang-patch response does include those differences. The particular item in question pertains specifically to the augmentation to YANG-patch, in which the origin value is also specified (i.e., when you have a difference, it does not only tell you the new value / the YANG-patch that you have to apply, but it also tells you the original value that it had before). When you apply a 'create' or 'insert' operation, clearly the item that you are creating or inserting was not there before, hence there is nothing to include. </ALEX> > > [S{7,9}] [observation] > > * The last paragraph of Section 9 and the whole of Section 7 seem to be > saying the same things? Perhaps consider if it's better to just say > them once in Section 9 or say everything in Section 7 and just have > the last paragraph of Section 9 say, in effect, "see also Section 7". > > > <ALEX> Well, the same issue (compare issue being potentially computationally > expensive) has ramifications on both security and performance. Originally > this was explained only in Section 9 (Security Considerations), but then an > earlier suggestion was to spell this out explicitly in Section 7 as a > Performance Consideration as well, hence it is mentioned in both places. I > guess this makes it more explicit and at this point I would suggest to leave > it there. </ALEX> _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
