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

On 11 October 2016 at 03:45, Nancy Cam-Winget (ncamwing)
<ncamwing@cisco.com> wrote:
> 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"
> <mile-bounces@ietf.org on behalf of takeshi_takahashi@nict.go.jp> 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.
>

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.

>>
>>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
>>'"Node2@domain.com/mac" sends the following ...', but the example XML
>>below
>>the sentence says 'from=Node2@domain.com/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:mile-bounces@ietf.org] On Behalf Of Nancy Cam-Winget
>>(ncamwing)
>>Sent: Wednesday, April 27, 2016 1:28 AM
>>To: mile@ietf.org
>>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
>>mile@ietf.org
>>https://www.ietf.org/mailman/listinfo/mile
>
> _______________________________________________
> mile mailing list
> mile@ietf.org
> https://www.ietf.org/mailman/listinfo/mile