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

[Adam Montville <[e-mail]>]

:-) No worries. I'll try responses inline. Note that I'm about to head on
vacation for two weeks. I'll be paying attention, but response times may
lag.

On Thu, Aug 3, 2017 at 11:27 AM Nancy Cam-Winget (ncamwing) <
[e-mail]> wrote:

> 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.
>

[AWM] This seems reasonable. Mostly, I'm trying to wrap my head around how
I would (hypothetically) go about operating such a service, and it's not
super clear to me.


>
>
>
>
> 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)?
>

[AWM] The broader notion is important! I'm not sure that XML samples would
help in this regard, but perhaps some additional language about what
IODEF-specific capabilities would be expected to be discovered?


>
>
> 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”?
>

[AWM] I think I like the direction of "observed information", but please
note that this particular comment isn't a strenuous objection, but more of
a probe for deeper understanding.

>
>    - 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.
>

[AWM] Fair enough.

>
>    - 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?
>

[AWM] I'm not sure (and I'm curious as to what others think about this. To
me, the discovery features of this solution would allow my ecosystem to
discover components capable of performing specific tasks (i.e. those
components that provide capabilities). Those capability providers would, in
turn, publish specific information using specific data models and
serializations. So, there seems to be a distinction, though I'm not sure
how important it is to call out. How about "A publisher is a capability
provider that contributes information pertaining to its capability to the
XMPP grid" or something like that? I'm not sure if that's helpful or makes
things more confusing.

>
>    - 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]> 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
>
>