I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by IESG.  These comments were written primarily for the benefit of security area directors.  Document editors and WG chairs should these comments just like any other last call comments.

Summary: not ready

From the abstract, this document provides requirements for a service that allows client applications to subscribe to updates of a YANG datastore. 

I looked up YANG, and wikipedia says it is a data modeling language for the NETCONF network configuration protocol.

The introduction says

   Applications interacting with YANG datastores require capabilities
   beyond the traditional client-server configuration of network
   elements.  One class of such applications are service-assurance
   applications which must maintain a continuous view of operational
   data and state.  Another class of applications are security
   applications which must continuously track changes made upon network
   elements to ensure compliance to corporate policy.

So, this suggests that this pub/sub mechanism will sometimes be used for security-related monitoring.

When I read the document, I wondered where the requirements were coming from. There is a brief “Business Drivers” section that tells why a “push mechanism” (different name for pub/sub?) is useful, but other than this, the document does not describe use cases. This makes it very difficult to evaluate the subsequent requirements assertions. 

I don’t know anything about I2RS, and I won’t comment on anything other than the security considerations.  That section lists various MUSTs and SHOULDs, but gives no rationale. It is not possible to evaluate this section without understanding *why* these requirements are what they are. 

It is possible that the rationale exists in companion documents. If so, this should be called out. If not, I think it should be given here. The intro suggests that this mechanism will be used for enterprise security monitoring operations. Those operations should be described (at a high level), along with associated threats. From those threats come associated mitigation measures, and from those measures come requirements. If you want to punt on the specifics (and address it in later work), then the requirements should at least describe what threats should be mitigated.

I think the ADs should take a look at this document.

--Scott