Thanks Alissa and Christer, please see further comments below:
On 1/4/19, 4:31 AM, "Christer Holmberg" <[email protected]> wrote: Reviewer: Christer Holmberg Review result: Ready with Issues I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-ietf-mile-xmpp-grid-09 Reviewer: Christer Holmberg Review Date: 2019-01-04 IETF LC End Date: 2019-01-14 IESG Telechat date: Not scheduled for a telechat Summary: The document is well written, easy to read, and technically I have no issues. However, as shown below, I do have some questions for clarifications. Major issues: None Minor issues: Q1: There is no explanation of what kind of security-related information is distributed. What kind of security? I assume it is some kind of application security, and not XMPP security. [NCW] IODEF is one such exchange format that allows for security-relevant Information to be shared. As IODEF is “Incident Response”, it is a type of security information. Once SACM has an Exchange format, we can show how that can be distributed using XMPP as well. Q2: Is there a reason why XMPP-Grid is only defined for security-related information? Isn’t XMPP-Grid a way of distributing ANY type on information in a secure manner? [NCW] Yes it can distribute any type of information. The focus of this document is to show how XMPP-Grid could be used for distributing IODEF security events. Q3: It is not clear to me what XMPP-Grid provides that “normal” secure XMPP doesn’t. Is XMPP-Grid only an architecture, using standard XMPP components? If so, I think that should be made more clear. [NCW] Yes, it is only an architecture that uses standard XMPP components. The abstract and introduction states as much in that the “document describes how to use XMPP”. We could update the first part of the introduction by making the following change: “This document defines an architecture, e.g. “XMPP-Grid” as a method for using…. Does that help?? Q4: While section 8 does reference RFC 6120 for the usage of TLS, I can’t find any references to other security considerations in RFC 6120. Is everything in section 8 XMPP-Grid specific? [NCW] Yes, Section 8 are specific to XMPP Grid architecture and the components of XMPP it proposes. But since the draft basically demonstrate the use of XMPP, it should absorb the considerations described in 6120 too. We will adjust the Security considerations to state that as well. Q5: Section 4 talks about a “typical” workflow. I assume that means there could be others? [NCW] Yes, while we expect implementations may extend or leverage other components (XEPs) of XMPP, Section describe a representative workflow . Nits/editorial comments: Q6: The document talks about using XMPP-Grid for distributing “security-relevant”/”security-related” information. I suggest using consistent terminology. [NCW] Thanks for pointing this out. We will make the changes to be consistent with “security-relevant” information.
_______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
