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

From: "Takeshi Takahashi" <[email-masked]>
Date: Wed, 2 Aug 2017 18:28:21 +0900

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:[email-masked]] On Behalf Of Adam Montville
Sent: Sunday, July 30, 2017 10:04 PM
To: Takeshi Takahashi <[email-masked]>; [email-masked]
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:[email-masked]> 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:[email-masked]
https://www.ietf.org/mailman/listinfo/mile

---

From: "Nancy Cam-Winget (ncamwing)" <[email-masked]>
Date: Thu, 3 Aug 2017 16:27:16 +0000

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 <[email-masked]> on behalf of Adam Montville <[email-masked]>
Date: Sunday, July 30, 2017 at 6:04 AM
To: Takeshi Takahashi <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [mile] Working group last call for XMPP-grid

Take (and everyone),

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

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

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 <[email-masked]<mailto:[email-masked]>> wrote:
Hello all,

Thank you.
Take

_______________________________________________
mile mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mile

---

From: Adam Montville <[email-masked]>
Date: Fri, 04 Aug 2017 10:47:53 +0000

:-) 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) <
[email-masked]> 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 <[email-masked]> on behalf of Adam Montville <
> [email-masked]>
> *Date: *Sunday, July 30, 2017 at 6:04 AM
> *To: *Takeshi Takahashi <[email-masked]>, "[email-masked]" <
> [email-masked]>
>
>
> *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..."
>

[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.
>
>    - 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).
>
> [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 <
> [email-masked]> wrote:
>
> Hello all,
>
> [email-masked]

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 4 Aug 2017 09:09:53 -0600

For now, one comment on a particular point...

On 7/30/17 7:04 AM, Adam Montville wrote:

>   * This is a draft about communicating IODEF information over an XMPP

That specification defined a way to use IODEF for communication among
XMPP servers for the purpose of improving operation of the XMPP network,
whereas draft-ietf-mile-xmpp-grid defines a way to use XMPP as the
transport for communication of IODEF data among non-XMPP entities. The
two use cases are very different, and thus the MILE spec should not
normatively reference XEP-0268.

Peter

---

From: "Nancy Cam-Winget (ncamwing)" <[email-masked]>
Date: Fri, 4 Aug 2017 17:48:27 +0000

Hi Peter,
Point well taken, my intent was to only use the means of conveying IODEF reports thru the XMPP as a transfer protocol which I understood XEP-0268 to also demonstrate.  However, the intent of the XMPP-grid draft to enable the sharing beyond XMPP servers….as pointed out, we need to clean and address that better.

	Nancy

On 8/4/17, 8:09 AM, "mile on behalf of Peter Saint-Andre" <[email-masked] on behalf of [email-masked]> wrote:

    

    Peter