Subject: Re: [netmod] Erik Kline's No Objection on draft-ietf-netmod-nmda-diff-09: (with COMMENT)

From: Alexander L Clemm <[email-masked]>
Date: Fri, 6 Aug 2021 11:43:45 -0700

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>