Re: [hono-dev] Agenda for face-to-face meeting

["Hudalla Kai (INST/ESY)" <kai.hudalla@xxxxxxxxxxxx>]

Hi Gordon,

as always you are raising excellent questions :-) Please see below form y comments ...

> -----Ursprüngliche Nachricht-----
> Von: hono-dev-bounces@xxxxxxxxxxx [mailto:hono-dev-bounces@xxxxxxxxxxx] Im
> Auftrag von Gordon Sim
> Gesendet: Donnerstag, 31. März 2016 19:29
> An: hono-dev@xxxxxxxxxxx
> Betreff: Re: [hono-dev] Agenda for face-to-face meeting
> 
> On 29/03/16 07:56, Kai wrote:
> > Here are some issues I would like to discuss during the meeting:
> >
> > * Functional Scope - in particular, I would like to agree on some
> > things that will NOT be in scope (at least not from the beginning)
> > * Rough timeline - when do we want to release milestones, a 1.0 etc?
> > * Topology Options - as already started on the wiki page [1], I would
> > like to come to an agreement which option we start with
> > * Security/Privacy - I would like to make sure that we have a common
> > understanding of the basic guarantees Hono will give regarding data
> > privacy and how these should/could be enforced
> > * AMQP based API - we have started to work on the API for supporting
> > Telemetry data upload [2] which I would like to show to you and get
> > your feedback
> >
> > We will probably not be able to cover sall topics in depth so let me
> > know what you think are the most important topics for which we should
> > reserve the most time.
> 
> Those issues all look valuable to discuss. From my point of view the overall aim is
> to try to clarify what Hono aims to be/do, especially in the short to medium term,
> and these different items on the agenda act as different ways of viewing that.
> 
> One suggestion: would it be worthwhile to spend a very short amount of time
> sketching out a simple use case or two to demonstrate the problem that Hono
> solves and/or help think about the scope in more concrete terms?
> 
[KH] Yes, I think that would be a good idea. I think we can use some of the slides I showed at EclipseCon NA for that purpose.

> > I am currently in the middle of preparing everything for the meeting.
> > We will have two conference rooms to our disposal so we can also split
> > up into groups working on things in parallel if we see fit.
> > You will be able to use our WiFi to get internet access to VPN into
> > your company network to check emails etc.
> >
> > Looking forward to seeing all of you in Berlin next week :-)
> >
> > [1] https://github.com/eclipse/hono/wiki/Topology-Options
> > [2] https://github.com/eclipse/hono/wiki/Telemetry-API
> 
> I am perhaps jumping the gun a little here, but as time next week is short, posting
> some questions on the API drafts now may give people more time to mull over
> them.
> 
> * Should a given authenticated principal be able to access or sumbit data for
> multiple tenants? Should multiple different principals have access to the same
> tenant?
> 
[KH] This should be subject of our discussion around Security/Privacy, I guess. Personally, I think that this should be possible, yes. One way of doing that would be by means of maintaining ACLs for the tenants (I do not think that we should use the devices as the level of granularity for authorization)

> * In uploading telemetry data, the tenant-id is optional. If not provided how is that
> determined? Is a default assumed? Or is there some lookup of the tenant to which
> a device belongs? If the tenant *is* specified is there any verification that it
> matches the owner of the device?
> 
[KH] So far we have discussed that we want to imply a "Default" tenant if the tenant-id is omitted. This would make it easier for customers to use Hono in a single tenant environment. A lookup of the tenant-id is also possible, however (with the additional latency penalty involved, of course). Regarding verification of tenant-id: my take is that we will want to authenticate Protocol Adapters as kind of a _trusted_ component to which we delegate the authentication of the devices and the establishment of the tenant they belong to.

> * Depending on answers to the above, might the tenant be identified via a virtual
> hostname on the connection open?
> 
[KH] This is just another means of conveying the information, isn't it? So, instead of supplying it at the message level, we convey it in the node address used in the link establishment, right? This could also work, I guess but doesn't solve the problem of trustworthiness of the information provided, does it?

> * Is there likely to be a need to filter telemetry data for a given tenant in some way
> (by device, by device type or grouping, by logical subject etc)
> 
[KH] Personally, I would like to defer this to the consumer of the data, e.g. using Storm or any other framework for filtering, processing, forwarding the data. My concern is that we "re-build" a full-fledged message broker when we start to expose too many features of underlying MOM.

> * Might it be worth recommending use of the subject property on an AMQP
> message where appropriate. (E.g. an MQTT protocol adapter might use that to
> hold the original MQTT topic, a CoAP or REST adapter might use it to hold the
> resource identifier)? That then provides a basic uniform way to do logical
> classification.
>
[KH] I am not sure if I understand what you mean by "logical classification". I do not really see (yet) why Hono would be interested in classifying the data based on the technical means it has originally been transmitted. After all, Hono's main purpose is to actually abstract away these technical details. However, a client can include any properties in the telemetry messages it wants to and Hono will forward them to the consumer *as is*. So, if a consumer can/wants to make use of such information it is free to do so.
 
> * Would Hono store telemetry data for any length of time independent of any
> active subscribers?
> 
[KH] I would actually try to define a reasonable retention policy based on message age, e.g. all messages are removed after 10 (?) days regardless of whether any consumer has read the data or not. I guess this would also be consistent with the nature of "telemetry" data in that one value reported will be superseded by the next one anyways.

> * The content-type is described as 'MUST be set to application/octet-stream if
> content is to be considered opaque binary data.'. How would the receiver know
> how to decode that? Would they infer it from the device-id? Or would that be
> 'application specific'? Is the intent of that description to discourage more explicit
> content-types?
> 
[KH] I guess you are right. My proposal would be only have binary payload in a Data section and to use the content-type and content-encoding properties to describe the structure and meaning of the data.

> * On a related point, I would imagine that some solutions would benefit from not
> having to map/convert between different data formats themselves, but to see data
> from different devices in some uniform format/model. Do you see some form of
> canonicalisation and/or conversion of data to be in or out of scope?
> 
[KH] I totally see the benefit of that but would not consider Hono being in charge of doing the normalization. We are discussing this internally at Bosch currently and we think we should try to use Vorto for defining data semantics and normalize data received from devices in the Protocol Adapters the particular type of data would then be indicated by the content-type. Any back-end consumers can then use this information to read (and understand) the payload data.

> * On a very pedantic point, the target and source addresses for telemetry
> producers and consumers respectively is defined to include 'telemetry/upload'. Is
> there any other category of telemetry data being considered, or is the upload
> perhaps redundant?
>
[KH] I feel the same way the more I think about it :-) The client's intention is already conveyed by means of the role it plays in link establishment, right?

 _______________________________________________
> hono-dev mailing list
> hono-dev@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe from this
> list, visit https://dev.eclipse.org/mailman/listinfo/hono-dev