Re: [mile] Working group last call for XMPP-grid

Hi Panos,

Many thanks for the review!!  Comments and answers below:

From: Panos Kampanakis <pkampana@cisco.com>
Date: Friday, April 14, 2017 at 1:12 PM
To: Takeshi Takahashi <takeshi_takahashi@nict.go.jp>, "mile@ietf.org" <mile@ietf.org>, "ncamwing@cisco.com" <ncamwing@cisco.com>
Subject: RE: [mile] Working group last call for XMPP-grid

Hello Nancy and team,

I hadn’t gone through the doc before because of my lack of knowledge of XMPP-Grid. I just went through it as a non-XMPP-Grid expert. Below I have some comments and nits. I think the comments below would generated some significant changes to the doc, so it might not be ready for WGLC yet.
·         Nit: Add space in "[RFC6120]that"
·         [NCW] Will fix in next revision
·
·         Nit: "and among network platforms, endpoints, and most any network connected device." Needs rephrasing.
·         [NCW] Will rephrase to: “among any network connected device”
·
·         Section 1.4 should address RID vs ROLIE vs XMPP-Grid. We have now defined 3 transports for IODEF documents, so I think it would be beneficial to qualify where each one fits.
·         [NCW] I am not sure the comparison makes sense to have inside the XMPP-Grid spec, though your point is well taken.  We can add applicability for when XMPP-Grid makes sense to use within the XMPP-Grid draft; and if the group warrants it, we can have a separate writeup that explains the differences between the three transports (at some point Kathleen had a wiki but not sure its up anymore?) and where/how each applies.
·
·         Change all references of [RFC5070] to IODEF-bis [RFC7970].
·         NCW] Will fix in next revision
·
·         In Section 3, I think it would be worth to expand on the IODEF-bis attributes that could serve as filters. Also how Topics and Subtopics would be defined in the context of IODEF. Would there be any rules in searching for attributes that deep in IODEF classes like nodeRole attributes?
·         [NCW] The XMPP Pub/Sub or Query mechanisms allow for filtering on any attributes, do you have some to suggest from IODEF?  We will rework the draft to show the applicability and definition of sharing IODEF as a Topic, as to the subtopics, I would think that it could depend on the publisher of the information as they code potentially define subtopics based on the Assessment impact vs. nodeRole or some other class type as well?
·
·         Nit: There is an empty parent bullet over “Real-time event notifications through publish and subscribe.”
·         [NCW] I will sort out the formatting issues in the XML file, thanks for catching this one.
·
·         I think section 2.6 should be in an appendix since it is mostly showcasing example xml form.
·         [NCW] Will consider moving it as we restructure the draft.
·
·         In section 5.1.4, “Protect the confidentiality of the CA's private key” is inaccurate. The CA signs the public key but does not know the private key that corresponds to that public key.
·         That is correct; but the bullet refers to the CA protecting itself and thus protecting its own (CA) private key as it uses it to validate the issued certs.
·
·         In section 5.1.4, it is not clear what “Issue certificates that go beyond name constraints or other constraints imposed by a relying party or a cross-certificate” means.
·         [NCW] We meant that the CA is only authorized to issue certs to secure the XMPP (XMPP-Grid) connections and thus should not be trusted to issue other types of certs.  So we can just change it to one sentence (vs. the single bullet) to state:  “The CA is not expected (trusted) to issue certificates beyond the constraints imposed by a relying party.”
·
·         In section 5.2.2, could sharing info with other nodes be one more threat for the compromised XMPP-Node?
·         [NCW] Yes, the intent for the bullets was to cite some such examples.  Do you have suggestions for improvement if it isn’t clear?
·
·         Section 5.3.1 mentions that both mutual cert auth or HTTP Basic are acceptable, but section 2.4.1 only requires mutual cert auth. Are certs the only ones mandated?
·         [NCW] Yes, our implementation only uses x.509 certificates, but as XMPP uses SASL for authentication, other mechanisms can be used.  So, I think its appropriate to add the guidance of SHOULD use certs for best security practices (vs. passwords or shared secrets).
·
·         In section 5.3.1 s/certificate-based authentication SHOULD each verify the revocation status of the other party/certificate-based authentication SHOULD each verify the revocation status of the other party’s certificate
·         [NCW] Thanks, will do.
·
·         5.3.1 does not define ARC and SSRC
·         [NCW] Thanks, will do.
·
·         5.3.2 and 5.3.3 does not define TNC.
·         [NCW] Thanks, will do.

A clarification question for my benefit: Is this draft intended to standardize XMPP-Grid and demonstrate its applicability in IODEF and other info sharing standards. Even though IODEF is one of the shared standards, the draft mostly focuses on setting the XMPP-Grid protocol and architecture up. I was curious if SACM had considered the draft back in the day as it is dealing with more broad set of info sharing standards instead of MILE whose charter was focusing on IODEF mostly. No worries, since it already is a MILE WG item anyway.
NCW] Yes, the Intent is to standardize XMPP-Grid and show its applicability into IODEF (though we also state that other info sharing models can be used). The intent, which we’ll strengthen is to show how IODEF is transported thru XMPP-Grid

Rgs,
Panos

-----Original Message-----
From: mile [mailto:mile-bounces@ietf.org] On Behalf Of Takeshi Takahashi
Sent: Thursday, March 30, 2017 11:50 PM
To: mile@ietf.org
Subject: [mile] Working group last call for XMPP-grid

Hello all,

This is a WGLC for draft-ietf-mile-xmpp-grid.
The version to be reviewed is
https://tools.ietf.org/id/draft-ietf-mile-xmpp-grid-02.txt

We will have 1 month for this call.
Please provide comments before May 1st and provide your support and/ or raise any issue you feel are yet to be addressed.

Thank you.
Take

_______________________________________________
mile mailing list
mile@ietf.org<mailto:mile@ietf.org>
https://www.ietf.org/mailman/listinfo/mile