[netconf] Benjamin Kaduk's No Objection on draft-ietf-netconf-netconf-event-notifications-20: (with COMMENT)

[Benjamin Kaduk via Datatracker <[e-mail]>]

Benjamin Kaduk has entered the following ballot position for
draft-ietf-netconf-netconf-event-notifications-20: 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 IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-netconf-netconf-event-notifications/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Section 6

   Notification messages transported over the NETCONF protocol MUST be
   encoded in a <notification> message as defined within [RFC5277],
   Section 4.  And per [RFC5277]'s "eventTime" object definition, the
   "eventTime" populated with the event occurrence time.

nit: I think the last sentence is actually a sentence fragment.

Section 7

This "Either it will correspond to [...] Or this 'error-tag' will
correspond to [...]" seems to preclude future extensions; do we want to
add some weakening language like "for the mechanisms specified in this
document"?

                                                  The specific identity
      to use depends on the RPC for which the error occurred.  Each
      error identity will be inserted as the "error-app-tag" following
      the form <modulename>:<identityname>.  An example of such as valid
      encoding would be "ietf-subscribed-notifications:no-such-
      subscription".  Viable errors for different RPCs are as follows:

            RPC                     use base identity
            ----------------------  ----------------------------
            establish-subscription  establish-subscription-error
            modify-subscription     modify-subscription-error
            delete-subscription     delete-subscription-error
            kill-subscription       delete-subscription-error
            resync-subscription     resync-subscription-error

This is probably just my lack of familiarity with the protocol, but the
text doesn't do much to indicate how the "base identity" concept in the
table corresponds to the "<modulename>:<identityname>" syntax or the
specific example given.  I think that this just means that the
<identityname> must be of the base type or derived from it, so maybe
"derive from" or "have" instead of "use" in the table heading would be
more clear.

      The yang-data included within "error-info" SHOULD NOT include the
      optional leaf "error-reason", as such a leaf would be redundant
      with information that is already placed within the
      "error-app-tag".

I'm not sure where this "error-reason" leaf is defined -- I don't  see
it in any of subscribed-notifications, yang-push, or RFC 6241.

Section 8

                                                                     The
   publisher MAY also suspend or terminate a subset of the active
   subscriptions on that NETCONF session.

I'd suggest saying/repeating why the publisher might do this, i.e., "MAY
also suspend or terminate [...], in order to reclaim resources and
preserve normal operation for the other subscriptions."

Appendix A.2

I'd suggest adding a note that the "id" values of 22, 23, and 39 are
just examples, and that actual values may not be small integers (akin to
my comment on the RESTCONF document).