Reviewer: Ladislav Lhotka
Review result: Ready with Nits
***** 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.
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
