I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. Document: draft-ietf-mile-xmpp-grid-09 Reviewer: Matthew A. Miller Review Date: 2018-01-23 IETF LC End Date: 2019-01-14 IESG Telechat date: 2019-01-24 Summary: This document defines an architecture for distributing security information using publish-subscribe semantics over XMPP. It is well written and addressed many (but not all) known concerns of a publish-subscribe This document has issues that should be addressed before it is ready to be published as a Proposed Standard. Major Issues: The document does not explicitly discuss the implications of the Controller and Broker having plaintext access and control of the published data. It seems to be implied in the section 8.2.3 for the Controller (and, for those proficient with XMPP, the Broker). I am not strongly recommending any sort of end-to-end protections be proscribed (since existing protections are likely unsuitable for this architecture). The document does not have any real discussion around persistence of node items. if they are expected or desired to be persisted, then there should be some discussion about retention policies (meaning: deployments ought to have one), and behaviors when a Platform subscribes to the Topic (e.g., should or may automatically send the last published item to the recent subscriber). If not, then some discussion on the implications of existing/historic data being unavailable through this mechanism. Minor Issues: XMPP pubsub is complex, and node configuration reflects that. Relying on XEP-0060 is something of a disservice to implementers, in my opinion. I suggest that an addition Topic creation example be added that demonstrates the recommended configuration: * pubsub#access-authorize or access-whitelist * pubsub#persist_items = ?? (1 or 0) * pubsub#send_last_published_item = ?? (on_sub? never?) Nits: N/A