Subject: Re: [mile] Please provide comments to draft-ietf-mile-xmpp-grid

From: "Nancy Cam-Winget (ncamwing)" <[email-masked]>
Date: Tue, 11 Oct 2016 02:45:11 +0000

Hi Takeshi,

My apologies for such a long delay….and thank you so much for the comments.

Some answers below (I am also including Syam to further elaborate as
needed):

On 5/17/16, 6:18 AM, "mile on behalf of Takeshi Takahashi"
<[email-masked] on behalf of [email-masked]> wrote:

>Hello Nancy,
>
>I have read the draft and have got a couple of questions and comments on
>the
>XMPP-grid draft.
>I might have misunderstood something, but I would appreciate your answers
>to
>the following questions.
>
>[Section 1.3 Overview of XMPP-grid]
>
>a. Regarding "Grid Connect", how can we know the location of the
>Controller?
>Does either XMPP or XMPP-grid provide such scheme? Or, are we supposed to
>know the Controller in advance by using external means?
[NCW] You can do a discovery to find the Controller in a couple of ways,
the simplest one being a DNS query
As it is expected that the controller would be implemented as a DNS
service.

>
>b. Regarding "publish topic", does XMPP-grid allow us to publish a data
>(that is a part of a Topic)?
>If I understood correctly, Topic is a series of (a group of) security
>items,
>and "publish topic" operation is prepared for publishing topic, not an
>item.
[NCW] Yes, a “topic” is the XMPP nomenclature used to define a schema that
contains the content to be published.
So, one can “filter” parts of the data in the topic as well….but yes, a
topic consists of a set of information items.

>
>[Section 2.1 XMPP Overview]
>
>a. Regarding figure 3, if the XMPP server does not equip with the Grid
>controller, what type of error messages can publisher receive?
[NCW] A publisher could receive error messages against its operations and
transactions that go through the controller.
For instance, the session establishment codes (looking at SASL codes,
section 6.5 of RFC 6120)
Syam can further elaborate of other error codes as well…

>
>[Section 2.6 XMPP-Grid Protocol Details]
>
>a. In the first bullet "Register the Node to XMPP-Grid", the sentence says
>'"[email-masked]/mac" sends the following ...', but the example XML
>below
>the sentence says 'from=[email-masked]/syam-mac"...'. One of the two
>might
>be a typo.
[NCW] Thank you for catching the typo!  We will make them consistent…

>
>b. In the example XMLs, I prefer to see <login/> rather than
><login></login>. Likewise, <register/> and <logout/> could be used.
[NCW] That is fine…we can make the adjustment.

>
>[abstract]
>
>a. Are you going to produce an RFC that defines XMPP-grid somewhere else?
>(If this document defines XMPP-grid, it is fine to me to leave Section 3
>concise as it is.)
[NCW] I currently do not intend to define it elsewhere as once should
suffice!
There may be extensions or other documents that can show how XMPP-grid can
be used for other information that is outside the scope of MILE, but the
core as defined in this document should only be published/described once.

>
>[Section 1 Introduction]
>
>a. The sentences sound like that the XMPP-grid can be usable only for
>security-related information; am I correct that the XMPP-grid can be used
>for arbitrary XML information exchange?
[NCW] Yes, it is meant for any information as XMPP is widely used and
exchanges other information types.
However, the original “target” audience for XMPP-grid was to show how it
can be used for security based information too.
Would you like us to make that clarification?

>
>Thank you,
>Take
>
>
>
>From: mile [mailto:[email-masked]] On Behalf Of Nancy Cam-Winget
>(ncamwing)
>Sent: Wednesday, April 27, 2016 1:28 AM
>To: [email-masked]
>Subject: [mile] Please provide comments to draft-ietf-mile-xmpp-grid
>
>Colleagues,
>
>I’ve posted the draft
>in https://datatracker.ietf.org/doc/draft-ietf-mile-xmpp-grid/  so that we
>can get comments and continue to move this forward.
>
>Thanks, nancy
>
>_______________________________________________
>mile mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/mile

---

From: Dave Cridland <[email-masked]>
Date: Tue, 11 Oct 2016 09:17:06 +0100

> As it is expected that the controller would be implemented as a DNS

I would note that the Controller is not communicated with directly at
a TCP level except by the XMPP Server, according to Section 2. The
XMPP Controller is defined as an "external component", which in XMPP
terms usually means XEP-0114 - however realistically that's an
implementation detail.

DNS records might be used, but not by an end-entity client - clients
would simply connect to their server (which itself has DNS records for
the purpose), and the server would handle onward communication.
Options might be:

* The Controller could be built-in to the Server, and offered by
another domain. This is how existing XEP-0060 and XEP-0045 services
are usually presented.
* The Controller could be an "external component", which means
XEP-0114, and a distinct process connecting directly and solely to the
server. Unusual services are often implemented like this, for example
IRC gateways for chat, etc.
* The Controller could be a server in its own right - so connections
would be made between it and other servers via the S2S protocol in RFC
6120. Typically this isn't done simply because its equivalent to the
other cases from an external standpoint, and S2S functionality is
"hard" - one can achieve the same deployment style just by hosting an
external component in a server.

---

From: "Syam Appala (syam1)" <[email-masked]>
Date: Thu, 13 Oct 2016 01:30:57 +0000

Thanks Nancy. Please see inline:

>As it is expected that the controller would be implemented as a DNS
[SYAM] The clients connect to an XMPP server (that requires a DNS resolution for network reachability). The client requests such as connect, subscribe, publish etc are addressed to the Grid Controller. The Grid Controller FQDN can be resolved via DNS or it is left to XMPP server implementation to route to a pre-determined Jabber ID or FQDN.
>topic consists of a set of information items.
[SYAM] I agree with Nancy.
>Syam can further elaborate of other error codes as well…
[SYAM] SASL error codes are reported back to the client for failures such as authentication or authorization failures, account disabled or does not exist etc. RFC 6120 section 6.5 documents these error codes.

>[SYAM] We will fix the typo. Thank you.

>[NCW] That is fine…we can make the adjustment.
[SYAM] Sure. We will make the adjustment.