***** 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 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.