Re: [netconf] Murray Kucherawy's No Objection on draft-ietf-netconf-notification-capabilities-18: (with COMMENT)

[Benoit Claise <[e-mail]>]

Hi Murray,

Thanks for your review.
See inline.

On 10/5/2021 4:22 AM, Murray Kucherawy via Datatracker wrote:
> Murray Kucherawy has entered the following ballot position for
> draft-ietf-netconf-notification-capabilities-18: 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/blog/handling-iesg-ballot-positions/
> for more information about how to handle DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-netconf-notification-capabilities/
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> The SHOULDs in Sections 2 and 4 seem bare to me.  Why might an implementer opt
> not to follow them?  SHOULD does allow a choice, after all.  Some guidance here
> might be helpful.
In section 2, we used the SHOULD as best practice, exactly as RECOMMENDED.
We can't force the vendors to publish the capabilities with that format 
and the system is the capabilities could function if the capabilities 
are provided in a different format (proprietary, granted).
So we believe the SHOULD's are appropriate in this case.

Now, for section 4, you have a good point.
OLD:

This module itself does not contain any capabilities; it provides
    augmentation points for capabilities to be defined in subsequent YANG
    modules.  It SHOULD be used by other modules to augment in specific
    capability information.  Every set of such capabilities SHOULD be
    wrapped in a container under the augment statement to cleanly
    separate different groups of capabilities.

NEW:
This module itself does not contain any capabilities; it provides
    augmentation points for capabilities to be defined in subsequent YANG
    modules. The ietf-system-capabilies is used by other modules to augment in specific
    capability information.  Every set of such capabilities MUST be
    wrapped in a container under the augment statement to cleanly
    separate different groups of capabilities.

>
> The <CODE ENDS> tag at the bottom of Section 4 appears twice.
Good catch.
>
> The "Note" at the top of the example in Appendix B should probably refer to RFC
> 8792, as Appendix A does.
Good catch.
Let's change the Appendix B to:
     ========== NOTE: '\' line wrapping per RFC 8792 
<https://datatracker.ietf.org/doc/html/rfc8792>) ===========

And, to be consistent with Appendix B, let's add at the beginning of 
Appendix A:

    The following examples use artwork folding [RFC8792  <https://datatracker.ietf.org/doc/html/rfc8792>] for better
    formatting.


Thanks and regards, Benoit