YANG Modules Describing Capabilities for Systems and Datastore Update Notifications
draft-ietf-netconf-notification-capabilities-21

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.

Thank you to Barry Lieba for the SECDIR review.

Thanks for addressing my DISCUSS item and better explaining the design in response to my COMMENT.

Thank to Kent Watsen for the shepherd writeup. I was initially concerned about the Datatracker "6 YANG Errors!!! 11 Warnings!!!!" messages, but I see that Kent has checked it with a newer linter.

Thanks for the efforts put into this specification.

I have questions/comment. Section 2 says -

     For the implementation-time use case: Capabilities SHOULD be provided by the implementer as YANG instance data files complying to [I-D.ietf-netmod-yang-instance-file-format]. The file MUST be available already at implementation time, retrievable in a way that does not depend on a live network node. E.g., download from product website.

How should I interpret this combination of SHOULD and MUST? Is it that if the implementer provides the capabilities then the file must be available at the implementation time? if the answer is yes, then it would be good to make it clear in the text.

Thank you for this very useful piece of work even if I only had time to browse through it.

First time in my life that I see the use of 'centiseconds' as a unit ;-)

Thanks for using RFC 8792 for line continuation.

Regards

-éric

Thanks to Barry Leiba for the secdir review.

Section 1

   Implementation-time information is needed by Network Management
   [...]
   new network node type can be introduced into the network.

   Implementation-time information is needed by system integrators.
   [...]
   node type sometimes depends on these management possibilities.

Commenting here since I read this draft after
draft-ietf-netmod-yang-instance-file-format, but there seems to be
pretty strong overlap between the discussion of how it's expensive to
require NMS implementors to have correclty configured nodes available,
the need for operators to have information about device capabilities
for purchasing decisions, etc.  It would be good to check that the
specific language used to describe these scenarios is in agreement
across documents, to the extent possible.  (The phrasing in this
document is probably a better starting point for the convergence, in my
opinion.)

Section 4.2

        1) search for a datastore-capabilities list entry for
        the specific datastore. When stating a specific capability, the
        relative path for any specific capability must be the same
        under the system-capabilities container and under the
        per-node-capabilities list: the same grouping for defining
        the capabilities MUST be used.

It's a little surprising to find the "MUST use same grouping"
requirement buried in the procedure for finding a capability value for a
specific data node in a specific datastore.

Section 5.2

           leaf minimum-update-period {
             [...]
             description
               "Indicates the minimal update period that is
                supported for a 'periodic' subscription.

                A subscription request to the selected data nodes with
                a smaller period than what this leaf specifies is
                likely to result in a 'period-unsupported' error.";
             [...]
           }
           leaf-list supported-update-period {
             [...]
             description
               "Supported update period values for a 'periodic'
                subscription.

                A subscription request to the selected data nodes with a
                period not included in the leaf-list will result in a
                'period-unsupported' error.";

Is it intended that these disagree on whether it is "likely to result"
or "will result" in a period-unsupported error?

         leaf-list supported-excluded-change-type {
           if-feature "yp:on-change";
           type union {
             type enumeration {
               enum none {
                 value -2;
                 description
                   "None of the change types can be excluded.";
               }
               enum all {
                 value -1;
                 description
                   "Any combination of change types can be excluded.";
               }
             }
             type yp:change-type;

It seems like this allows for some nonsensical edge cases, like a list
that includes both "none" and "any", or all the actual values from RFC
8641 as well as "none", etc.  Do we need to say anything about how to
handle such invalid scenarios?

Section 6

I agree with Roman that it would be nice to be able to say something
about the potential scope of security considerations for future
augmentations, if nothing else to aid authors of such future
augmentations in documenting their own security considerations.

NITS

Section 4.2, 5.2

I think only one "<CODE ENDS>" tag is needed.