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

Hi Adam,

Thank you very much for your thorough review.
These are very helpful comments to advance the work further.

I believe the authors will continue discussion based on these insightful comments.
I also think this is a kind of XMPP configuration guide that facilitates the exchange of security-related information.
So long as I understood until now, this document defines the exchange of security-related information, and describes how IODEF information can be distributed using the technique in order to demonstrate the usability of the technique, but confirmation from the authors would be appreciated on this matter.
I also agree that we had better minimize the invention of new terminology and had better reuse the term that were already used in the original XMPP spec.

In any case, since it is a summer vacation season, let us wait for a while until authors reply to the comments.

Thank you, and kind regards,
Take

From: mile [mailto:mile-bounces@ietf.org] On Behalf Of Adam Montville
Sent: Sunday, July 30, 2017 10:04 PM
To: Takeshi Takahashi <takeshi_takahashi@nict.go.jp>; mile@ietf.org
Subject: Re: [mile] Working group last call for XMPP-grid

Take (and everyone), 

I have read through this latest revision of the draft and find that I am still somewhat confused - not about the intent of the draft, I think, but of how it qualifies as something that is standards track (I could be speaking from ignorance here, so please educate me where necessary). 

To me, the draft is at heart an XMPP configuration guide, to put it simply. For example, I don't see too much I would need to implement (aside from a deferred XEP for IODEF - see my last comment below), but I do see many requirements pertaining to the configuration/operation of, say, ejabberd in my enterprise. 

I feel like the real meat of the problem is punted, and perhaps that is intentional given the narrow IODEF-specific scope. To me, the harder problem is gaining industry-wide understanding of the discoverable capabilities within the ecosystem XMPP-grid (I presume) seeks to enable. Without this, there's very little hope of "plug and play" security infrastructure in a given enterprise.

The following are my current specific comments on this draft (more may follow, but this seems like a bit for now):
• At several points the draft talks about "telemetry", and I remember someone (I think it may have been Henk) describing to me that this has special meaning avoiding real-time-ish or event-ish information. First, is there a need to define what is meant by "telemetry"? Second, is there a reason to limit to "telemetry" given this is a draft seeking to establish the communications infrastructure for a security program's ecosystem? (Maybe that's not the intent of the draft, but if it's not, then there's a whole front-end of activities on the orchestration or command and control fronts that still need to be addressed in this space, and I would question the utility of any approach unconcerned with the full breadth of security program communications needs.)
• Is there a reason we couldn't replace "transport and communication" for "messaging"? This seems cleaner, and removes any of the ambiguity around "transport" when we're at a context that may sometimes be on the network level and sometimes not. (See, for example, the first sentence of the first paragraph of the Introduction.)
• In the terminology, the way "capability provider" and "publisher" are defined, they seem synonymous. It's clear that "publisher" is being set up as a subclass of "capability provider" (i.e. "publisher is a capability provider that..."), but beyond that there's no clear qualification that would make an instance "publisher" distinct from some other instance of "capability provider". I'm not sure how to fix this, but recommend that you ask what would come after "that" in the following sentence fragment: "A publisher is a capability provider that..." 
• Proposed text for "subscriber" definition: An entity participating in XMPP-Grid by consuming information on a subscription basis from one or more publishers also participating in the XMPP-Grid.
• The XMPP-Grid Controller is simply an XMPP Server by my read. Is there a compelling reason not to simply call it such?
• This is a draft about communicating IODEF information over an XMPP infrastructure, and as such it points to (as a normative reference) XEP-0268 (see https://xmpp.org/extensions/xep-0268.html). Unfortunately, that normatively references a XEP containing a clear warning: "WARNING: This document has been automatically Deferred after 12 months of inactivity in its previous Experimental state. Implementation of the protocol described herein is not recommended for production systems. However, exploratory implementations are encouraged to resume the standards process." I'm not an expert, but I wouldn't want this draft to proceed by effectively standardizing something that was experimental, but has been deferred for inactivity, which tells me that it's effectively dead (XSF folks may have a different opinion, and I'll obviously defer to them, as I'm not too knowledgable of the XSF process).

I want to see standardization of a communications infrastructure supporting an ecosystem of software and tools commonly used in the implementation of a security program. It's not clear to me how this draft furthers that goal. Either the draft simply doesn't accomplish that for lack of specification, or it's not clear enough (to me) to see how that enablement happens (even for IODEF given the "non-normative normative" reference to XEP-0268).

Therefore, it's not clear to me how this draft could proceed as standards track, though I hope there is a way we can see this happen (I'm not sure an informational draft would be as well-received nor helpful).

Kind regards,

Adam

On Mon, Jul 17, 2017 at 10:57 AM Takeshi Takahashi <mailto:takeshi_takahashi@nict.go.jp> wrote:
Hello all,

Based on the discussion at the MILE session in Prague, let us re-initiate
the WGLC for draft-ietf-mile-xmpp-grid.
The version to be reviewed is
https://tools.ietf.org/id/draft-ietf-mile-xmpp-grid-03.txt

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

Thank you.
Take

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