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

[Adam Montville <[e-mail]>]

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 <
[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]
> https://www.ietf.org/mailman/listinfo/mile
>