Last Call Review of draft-ietf-netconf-notification-capabilities-05
review-ietf-netconf-notification-capabilities-05-yangdoctors-lc-lhotka-2019-10-29-00

***** Section 2. Introduction
      - Paragraph 3: the use of MAY is inappropriate: publishers
        indeed may have limitations, but this should follow from RFC
        8641, and this document should take it as a fact.
***** Section 3. Notification Capability Model
      - The use of RFC 2119 terms is again questionable: I understand
        the ietf-notification-capabilities data as an optional aid for
        the implementors, but requiring that "The file SHALL be
        available in implementation time ..." is way too strict.
***** Section 3.2. YANG Module
      - This is one of the cases where it would be helpful to know
        which of the imported modules, such as ietf-netconf-acm, is
        also intended to be implemented. This may be addressed in a
        future YANG version (see issue #95 in yang-next), until then I
        would suggest to include YANG library data describing a
        minimum implementation.
***** Appendix A. Instance data examples
      - Example in Fig. 2: the <datastore> element has an incorrect
        XML namespace (of the ietf-datastores module).
      - Many enum values are invalid because they contain
        leading/trailing whitespace. It would be better to encode the
        examples in JSON.