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

From: Murray Kucherawy via Datatracker <[email-masked]>
Date: Mon, 04 Oct 2021 19:22:33 -0700

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.

The <CODE ENDS> tag at the bottom of Section 4 appears twice.

The "Note" at the top of the example in Appendix B should probably refer to RFC
8792, as Appendix A does.

---

From: Benoit Claise <[email-masked]>
Date: Tue, 5 Oct 2021 12:29:30 +0200

Hi Murray,

Thanks for your review.
See inline.

> https://datatracker.ietf.org/doc/draft-ietf-netconf-notification-capabilities/
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.
> 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