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

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

Hi Adam,

Many thanks for a prompt review!  And it appears that I culled too much so please see further comments/questions below:

From: mile <[e-mail]> on behalf of Adam Montville <[e-mail]>
Date: Sunday, July 30, 2017 at 6:04 AM
To: Takeshi Takahashi <[e-mail]>, "[e-mail]" <[e-mail]>
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.

[NCW] Perhaps I did indeed cut too much in my endeavor for simplicity, readability and presumptions of XMPP knowledge.  It has been a while since I saw the XEP 268, so was remiss in keep abreast its status.  I can pull out the considerations for this and how IODEF would be defined as an XMPP “topic” that can be discoverable and shared (perhaps using the IODEF Guidance guidelines too).  I can check with David and Peter on XMPP guidelines on this matter as well.


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.
[NCW] Yea, so the intent was to be able to show the broader notion, but I thought I was responding to other comments for readability with the understanding that the discovery extension (XEP-0030) would be sufficient.  Would it help to bring back some of the XMPP XML samples (some are cited in XEP-0030 but I can make them relevant to IODEF discovery)?

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.)
[NCW] The intent is really to say that we want to share measured (observed?) information relevant to security.  Would it simplify to just remove the term?  Or state it as “observed information”?

  *   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.)
[NCW] Ah, I think it is likely to be “transfer” as that is what I was asked to remoniker in the Requirements draft.

  *   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..."
[NCW] I can just converge and use “publisher” only, would that help?

  *   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.
[NCW] OK, will update in the next revision.

  *   The XMPP-Grid Controller is simply an XMPP Server by my read. Is there a compelling reason not to simply call it such?
[NCW] You are correct, I can simplify

  *   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).
[NCW] Admittedly, I had not seen the note (as its been a while since I looked at the XEP-0268), so I can make adjustments to not use it but incorporate its intent in this draft.

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).
[NCW]  The intent is to show the IODEF as a data model that can be shared in a publish/subscribe ecosystem such as XMPP.  Given the scope of IODEF, I did remove the notion of how the discovery works based on the notion that XEP-0030 can be used.  I can put those samples back, as well as incorporating more details of the IODEF as its own namespace and “capability” that can be discovered and then shared.  I believe that is what makes it normative (e.g. standards based) along with the notion of having IANA be a registry for the data models that can be conveyed thru XMPP for information sharing.


Kind regards,

Adam


On Mon, Jul 17, 2017 at 10:57 AM Takeshi Takahashi <[e-mail]<mailto:[e-mail]>> 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
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/mile