Re: [Gen-art] Genart last call review of draft-ietf-mile-xmpp-grid-09

["Nancy Cam-Winget (ncamwing)" <[e-mail]>]

Thanks Alissa and Christer, please see further comments below:



On 1/4/19, 4:31 AM, "Christer Holmberg" <[e-mail]> 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.