Skip to main content

Telechat Review of draft-ietf-i2rs-pub-sub-requirements-05
review-ietf-i2rs-pub-sub-requirements-05-secdir-telechat-kelly-2016-04-28-00

Request Review of draft-ietf-i2rs-pub-sub-requirements
Requested revision No specific revision (document currently at 09)
Type Telechat Review
Team Security Area Directorate (secdir)
Deadline 2016-04-29
Requested 2016-04-14
Authors Eric Voit , Alexander Clemm , Alberto Gonzalez Prieto
I-D last updated 2016-04-28
Completed reviews Genart Last Call review of -06 by Francis Dupont (diff)
Secdir Telechat review of -05 by Scott G. Kelly (diff)
Opsdir Last Call review of -06 by Sheng Jiang (diff)
Rtgdir Early review of -03 by Julien Meuric (diff)
Rtgdir Early review of -03 by Dan Frost (diff)
Assignment Reviewer Scott G. Kelly
State Completed
Request Telechat review on draft-ietf-i2rs-pub-sub-requirements by Security Area Directorate Assigned
Reviewed revision 05 (document currently at 09)
Result Not ready
Completed 2016-04-28
review-ietf-i2rs-pub-sub-requirements-05-secdir-telechat-kelly-2016-04-28-00
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