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

From: Henk Birkholz <[email-masked]>
Date: Thu, 27 Apr 2017 21:58:01 +0200

Hello mile,
hello authors,

a few nits and comments regarding the current draft.

Also, a small prelude.

On one hand, the usage scenarios defined in the xmpp-grid draft, 
illustrated by the different deployment architectures, highlight how 
valuable and flexible this contribution could be. The draft has 
potential to provide a very versatile solution that addresses the 
question: "where do the semantics go?". Either specific (sub-)topics 
with strong semantic binding (and more raw'ish content) or general 
topics with content on the data-plane that provides corresponding 
semantic context via metadata included in the messages. This approach 
could be quite useful for various kinds of information sharing or event 
distribution in automated systems.

On the other hand, both structure and content of the draft require 
significant work in order to make this draft a valuable contribution. In 
consequence, a list of nits:

In 1.1. “Publisher: A capability provider sharing contet information” 
Content

In 1.3.: “contextual information ("Topics") (described in Section 3.3 
and 3.5)“ Reference is out-dated.

In 1.3.: “split into a logical control plane, whereas information 
exchange is considered a logical data plane” The draft highlights that 
‘management information' can be transported via the data plane. What 
about the management interfaces of xmpp-grid itself? Are these out of 
scope? E.g. configuration of methods to secure the xmpp-grid data plane 
or content authorization (authorization to subscribe).

In 1.3.: “The operations carried out by XMPP-Grid”. At this point a 
reader might wonder which XEP are used for which operation. The first 
mention of XEP is in 2.1. Maybe highlight the usage of existing XEP (and 
RFC or other specifications, analogously) earlier (or - in some places - 
at all)?

In 1.3.: “Broker-Flow:” Is this first option a pub/sub model? (see next nit)

In 1.3.: “Centralized Data-Flow” This is phrased confusing, I think. Is 
the use of an optional centralized database mandatory in this option? :)
In general, the list of three options here seems to imply that data 
plane traffic is either directly transferred between two xmpp-grid 
Nodes, or the broker includes a centralized database and enforces a 
common information structure. Is there no option that provides a data 
plane flow through the controller via a pub/sub model without (as with 
the Proxy-Flow option) requiring a common information structure? The 
text is too open to interpretation and in consequence requires work to 
clarify.

In 1.3.: “data exchange modes”: Seems to require the optional Bulk 
historic data query. At the moment it is implied this works only with an 
enforced common information structure. Is that correct? Text requires 
work (structure & content nit) to clarify.

In 1.5. Figure 1 is not referenced in the text, it seems.

In 2. Figure 2 is not referenced in the text, it seems. It also seems 
that Figures are used as elaborate headings, in general. :) While this 
actually is not as confusing as it sounds, I would strongly recommend to 
change that style (structure nit).

In 2.1.: There is a list item that has an empty level one and continues 
with nested level two itemized list.

In 2.1.: “The XMPP extensions used in XMPP-Grid” XMPP extensions and 
XMPP extension protocols seems to be used synonymously (which might be 
common practice?) The acronym XEP should be added to the glossary of 
terms (which is a curious name, btw).

In 2.2.: “XMPP-Grid defines an infrastructure protocol that hides the 
nuances of the XMPP data plane protocol and makes the information 
sharing models extensible with simple intuitive APIs.” This passage 
indirectly implies that a kind of… overlay abstraction on top of xmpp is 
introduced via this draft? The benefits of the contribution should be 
highlighted explicitly. The concepts of registration, subscription and 
login have different semantic meaning (see 2.4.2 nits), I am sure.

In 2.3.: “XMPP-Grid Controller manages all control aspects of the Node 
communication (including management) with the XMPP-Grid and other 
participating Nodes with mutual trust and authorizations' enforcement.” 
Manages including management… rephrase please :)

In 2.3.: “Through a centralized authorization model, XMPP-Grid 
Controller provides -” Should probably end with a colon?

In 2.3.: “Figure 3: XMPP Controller Message Flow” It seems that the 
figure does not illustrate -the- flow, but one of the options? Maybe 
even the option that is not explicitly highlighted in 1.3.? It seems 
that Figure 3 is also not referenced by the text, again. Which 
deployment architecture does this figure fit? Maybe there should be a 
figure for each deployment architecture option?

In 2.4.2.: The use of the login/logout mechanic should be explicitly 
described in the context of registration and subscription. What is the 
added value here, which exact problem is mitigated? The term login is 
used in this section, but never introduced. It seems to be the 
abstraction mentioned earlier? And to be “on top of” registration? (2.6. 
will show an example how it is done, but the reader is probably still 
pretty unclear about the purpose of this operation).

In 2.4.2.: “mutual authentication trust-based auto-approval 
registration” What this actually means is elaborated on in 5.3.1. (some 
hints are already provided in 2.4.1., e.g. TLS, x.509, SASL), I think. 
An improvement of text structure might be required. In general, it is 
probably beneficial (and less surprising) to highlight which 
building-blocks are used in xmpp-grid as an overview earlier in the 
draft. (possibly using ascii art) (note: pls see 2.6. nit)

In 2.4.2.: “The administrator may map the Nodes to the Node groups” What 
is a node group? This is related to the nit about the management plane 
being in scope or not, I think.

In 2.4.2.: “Multiple Node applications running on a Node could use one 
XMPP-Grid Node to connect to XMPP-Grid.” Node applications are the… 
names used in the boxes in Figure 1? The term is not introduced 
sufficiently.

In 2.4.3.: “XMPP data plane server” What is that? I am pretty sure that 
these are the boxes in Figure 1 again, but nevertheless the term should 
be introduced and brought into context.

In 2.4.3.: How are authorization privileges defined?

In 2.4.3.: “Node identity extracted from the request, group to which the 
Node is assigned during account approval and Topic/capability to which 
the permission is sought could be some of the ways to authorize Nodes 
and their requests in XMPP-Grid.” Rephrase… please. Also, this is the 
first time that topic and capability seem to be used synonymously. The 
glossary does not really help here, but it should (content & structure 
nit)! What is the exact relationship between topic, capability and data 
plane server (which is probably a providing Node)?

In 2.4.3.: “rule evaluation engine” What is that? Is that a component 
not in scope of this document but required? (Interfaces?)

In 2.4.3.: “Based this result,” Based on this result.

In 2.4.3.: “trust store” What is that? Probably something that should go 
into the glossary?

In 2.5.: MUST a provider provide a schema for the content it produces on 
the data plane via a topic? It reads that way, but would contradict text 
before.

In 2.5.1.: “The providers of capability include the version number in 
the messages they publish and the receiving Nodes can interpret the 
Topic version and process the attributes accordingly.” The heading of 
this section is topic versioning, but the text seems to describe message 
versioning?

In 2.5.3.: “XMPP-Grid supports semantic message filtering for Topics.” 
This phrasing implies that the content of the message is a factor for 
filtering, but 2.5. implies that this is out of scope. “categories based 
on domain, location of endpoints for example” already clarifies it, but 
the start of the section should be revised.

In 2.5.3.: “XMPP-Grid subscribers query the Controller and obtain the 
filtering options available for each capability” This phrasing implies 
that there is a specific way to represent/express filtering options. The 
draft lacks details how this control plane content is to be conveyed, 
though?

In 2.6.: “Register the Node to XMPP-Grid“ & “Node login to XMPP-Grid”: 
As mentioned above, both operations have to be illustrated in a larger 
context, their different purposes described explicitly, and the delta 
(which would be the contribution, I think) highlighted.

In 3.: I was surprised that there is no mapping of (or guidance how to 
map) IODEF content to specific standard topic names. Would that be in scope?

Viele Grüße,

Henk