Dear Juanjo, dear all,
I agree. My own strong preference is an ISG empowered to make the API specification.
My email was intended as neutral reporting.
The trick will be to persuade Hermann and Omar and Enrico that their formal identification
of a potential overlap is valid but too limited, and that the best interest of ETSI and oneM2M
is to share the workload and move forward.
My suggestion is, the founding members have a teleconf on this soon, after a few emails.
My idea for "moving forward" would be to create a list of "use cases" which we intend to
cover in the CIM work, focussing mainly on those which are out of scope of oneM2M.
That would demonstrate to ETSI just what essential work they are risking losing, and
would demonstrate that the "overlap" with oneM2M is truly marginal. We could add
a few of the typical oneM2M use cases perhaps to show that they _do not_ fit the CIM well.
I am confident we can get approval for points (a) - (g) below. In the "worst" case, perhaps
we could insert a final ETSI "check point" of some kind before publishing the final specification.
I am confident that by then everyone involved in ETSI will see the value of publishing.
best wishes
Lindsay
PS: I do not have the Gartner report. Maybe you could add a "value added" page to the powerpoint I sent
regarding "reasons for the ISG CIM" ?
________________________________________
Dr. Lindsay Frost, Chief Standardization Eng.
frost at neclab.eu<mailto:frost at neclab.eu> Mobile +49.163.275.1734
NEC Laboratories Europe, Kurfürsten-Anlage 36,
D-69115 Heidelberg, Germany.
Reg. Headoffice: NEC Europe Ltd, VAT DE161569151
Athene, Odyssey Business Park, West End Road,
London HA4 6QE, Reg. in England 2832014
From: Juanjo Hierro [mailto:juanjose.hierro at telefonica.com]
Sent: Donnerstag, 29. September 2016 00:24
To: Lindsay Frost; Mulligan, Catherine E A; Franck Le Gall; gilles.privat at orange.com
Cc: fiware-oasc-etsi at lists.fiware.org
Subject: Re: [Fiware-oasc-etsi] Wrap-up confcall
Dear Lindsay,
Creating an ISG which is limited to work in those points a) to e) where no overlap exist is a decision to be careful analyzed. Contributing to SDO is time and resource consuming. I seriously doubt that we, at Telefónica, are going to spend time and effort in producing "abstract" things like requirements on features a CIM API have to support. This is the kind of "vaporware" that leads nowhere. We have many examples of standards of that kind (even more concrete) which have failed. And probably the reason why de-facto open source standards, or at least industry standards (e.g., W3C) leveraging on open source reference implementations (Apache), are winning little by little the battle of standards.
If we had to follow the argumentation made by Omar and Enrico then there would not be any space for standardization in Smart Applications beyond what OneM2M. It will be strategic mistake for ETSI to stick to this kind of argumentations.
Refusing to define a standard API for context information management will mean refusing to lead standardization of the kind of infrastructures required for development of smart digital services. Maybe we have to look to other alternatives.
I don't know if you have seen this year Gartner's Hype Cycle for emerging technologies. They establish that a key technology in future smart application architectures has a name: context brokering.
A standard API and information models for Context Information Management will come. It may come as a de-facto standard, and that is a path we are walking. Or endorsed by a SDO. An endorsement may help to accelerate adoption, overall in fields like Smart Cities, but is not strictly necessary. Or at least necessary at any price.
Best regards,
-- Juanjo
On 28/09/16 21:29, Lindsay Frost wrote:
Dear all, I can confirm the points made below by Juanjo, but think there is room still for a solution.
On the one hand, Omar and Enrico were asked formally to provide advice whether there could be overlap with oneM2M.
They were not asked to say what is needed in standards, what is good for smart cities, what would be a way forward, etc.
All three speakers emphasized that ETSI cannot be seen to be acting against its agreement to use oneM2M for m2m activities.
On the other hand, the simplistic argument "if it could be used to cover similar cases to oneM2M then ETSI should not touch it,
even if it covers a bunch of important cases outside the scope of oneM2M" is an argument which would not be completely
acceptable to ETSI board. It is too black-and-white. Partly the problem is that the ToR mainly discusses implementation issue
(with protocols and functional blocks) which makes it look rather similar to a oneM2M-competitor, but we do not talk about
the CIM capabilities needed - which are quite outside of what can be provided by oneM2M any time in the next years.
Therefore I think if we identify some of those CIM capabilities explicitly in the ToR then it will be harder and harder to mistake the CIM
for a oneM2M-competitor. It would also emphasize the new work, which would show the value-add and attract contributors.
I am preparing full notes, but my own brief summary of the call is:
Omar and Enrico judge, based on the outlined statement of work in the ToR, that there is a significant risk
of overlap with the oneM2M work, which ETSI has contracted not to do. Hermann and Omar and Enrico
feel also that a significant PART of the work is clearly NOT overlapping, so one suggestion is to progress those
areas first. It was emphasized that this is a technical judgement, and the actual decision is in the hands of the
ETSI director general.
Lindsay summarized (and the others agreed) that their view is:
- it is NOT overlapping to
a) do a gap analysis
b) consider what context information needs to be managed
c) define requirements on the exchange of that CIM info (maybe re security, interoperability to open standards ,etc)
d) propose data models for smart cities or more generally
e) define capabilities within a CIM system (types of queries, handling inconsistency, etc etc)
- it IS considered a risk of overlapping with oneM2M to
f) propose a specific protocol for communicating the context information
g) propose a communication API and architecture
- it is DEFINITELY an overlap to
h) propose a protocol and API which could handle some of the same use cases as oneM2M,
especially if information is exchanged about the most recent status of entities (devices)
On the other hand, Juanjo emphasized that ETSI may be accepting an enormous constraint if it avoids
any work in future which could under some circumstances handle the same use cases as oneM2M.
There is currently no standard for Context Information Management and Europe could be the leader.
However if ETSI put it out of scope, and oneM2M does not do it, then what will happen?
Lindsay argued that an ISG has unique advantages in allowing stakeholders from smart cities and from
system integration projects to contribute, which is not at all common in the "big SDOs". There was some
discussion at the end about socializing the idea of the ISG CIM towards oneM2M and SmartM2M.
All sides agreed to consider the issues, and the clarifications given, and to make contact again next week.
From: fiware-oasc-etsi-bounces at lists.fiware.org<mailto:fiware-oasc-etsi-bounces at lists.fiware.org> [mailto:fiware-oasc-etsi-bounces at lists.fiware.org] On Behalf Of Juanjo Hierro
Sent: Mittwoch, 28. September 2016 18:42
To: Mulligan, Catherine E A; Franck Le Gall; gilles.privat at orange.com<mailto:gilles.privat at orange.com>
Cc: fiware-oasc-etsi at lists.fiware.org<mailto:fiware-oasc-etsi at lists.fiware.org>
Subject: Re: [Fiware-oasc-etsi] Wrap-up confcall
Hi,
Well, the summary is that the team from OneM2M and SmartM2M will provide formal feedback that they see an overlap between the scope of activities of the ISG and their activities. This was astonishing because, after having worked so many months in explaining why this overlapping didn't exist and having the greenflag from ETSI in that respect already (even captured in a picture :-) this came at least to me as a big surprise.
In essence, Omar (OneM2M technical chair) has stated that, if there is a Restful API "X" that can be used by an application to get access to some set of data and that same set of data can be accessed also through the OneM2M API then there is an overlap between "X" and the iOneM2M APIs. Therefore, any ISG working on standardizing "X" would be considered from their side that is overlapping with the activities of OneM2M (of course, Omar make it clear that the ETSI DG may take a decision to approve creation of the ISG knowing that comment). It doesn't matter whether "X" can be used and it is useful in scenarios where not all information comes from the IoT or even scenarios where no information comes from IoT at all. It also doesn't matter whether in such scenarios the OneM2M API is not suitable. Therefore, it doesn't matter whether there is a gap with regards to standardization of a Context Information Management API. They understand that gap is not fully covered by OneM2M but any work from ETSI regarding standardization of such API would be considered as overlapping with OneM2M work.
Trying to understand their position, I elaborated on an example that helped me to understand the statement. I brought a simple scenario which may indeed happen in a city. Citizens may open claim tickets when they see that a given bin is full of waste or some given city furniture is damaged. Using an application in their smartphones, they would be able to create a ticket and even take a picture and publish it linked to the bin/furniture. This means a change of context information: there is a new entity (the ticket) and some attributes are filled up for the bin/furniture with, for instance, attaching a photo with a date to the bin/furniture. Nothing of all this has to do with M2M or IoT and the city may want to provide access to that information using a standard API. Furthermore, may want to export resources linked to "datasets" through its Open Data portal so clicking on those resources would translate into real-time queries about open tickets around a given location. Do you mean that we have to use the OneM2M API for getting access to that kind of data in real-time? The answer was "Not". Then, is it legitimate to ask for a standard API "X" that provides this kind of access in a portable way? Yes, but it would overlap with the OneM2M API. Why? Because if, besides the referred case, bins have an attribute "temperature", which gets filled because of a measure in a sensor and then that attribute can be queried using the "X" API, then it is overlapping with the OneM2M API :-O
At a given point in time I made the point that, under the same rationale, TCP would be considered as overlapping with IP ... Does the fact that you can do things with TCP that can be done getting direct access to IP mean that TCP should have not been standardized? I didn't receive an answer. In general, with such a position, standardizing any API "X" that is more abstract that an already existing API "Y" and capable to homogenize access to "Y" and other interfaces, would simply not be possible.
This is what I understood. Others may correct me if my description is wrong.
On the other hand, I understood they would accept going for a standardization process that is just focused on the common information models but I wondered why it will be so valuable to run such a process under the scope of an ISG at ETSI. The challenge regarding common information models is to be able to setup a driven-by-implementation approach engaging cities (relevant stakeholders in other domains) and solution providers that movers really fast. I wonder what would be the value that creation of an ETSI ISG would bring here.
Sorry if all the above sounds a bit strong but I have little time to polish this message and I just tried to capture what we discussed. If someone else can bring different impressions, that would be fine.
Cheers,
-- Juanjo
On 28/09/16 17:06, Mulligan, Catherine E A wrote:
Yes can we please have a summary for the group?
Skaffa Outlook för Android<https://aka.ms/ghei36>
On Wed, Sep 28, 2016 at 4:04 PM +0100, "Franck Le Gall" <franck.le-gall at eglobalmark.com<mailto:franck.le-gall at eglobalmark.com>> wrote:
I understand that the discussion has been quite negative. Could someone provide me with some feedback as I was not avaimable to connect ?
Thank you
Envoyé depuis mon appareil Android.
-----Original Message-----
From: Juanjo Hierro <juanjose.hierro at telefonica.com><mailto:juanjose.hierro at telefonica.com>
To: "gilles.privat at orange.com"<mailto:gilles.privat at orange.com> <gilles.privat at orange.com><mailto:gilles.privat at orange.com>
Cc: "Fiware-oasc-etsi at lists.fiware.org"<mailto:Fiware-oasc-etsi at lists.fiware.org> <Fiware-oasc-etsi at lists.fiware.org><mailto:Fiware-oasc-etsi at lists.fiware.org>
Sent: mer., 28 sept. 2016 16:42
Subject: Re: [Fiware-oasc-etsi] Wrap-up confcall
Well ... we stayed for a while but apparently rest of people were still in the confcall with ETSI.
Would be nice to know if something new emerged. Otherwise, It looks like we have reached a deadlock.
We would need to setup a confcall, but I don't have any slot available before Friday 16:00 CET ...
Cheers,
-- Juanjo
On 28/09/16 16:20, gilles.privat at orange.com<mailto:gilles.privat at orange.com> wrote:
I can’t connect
-----Rendez-vous d'origine-----
De : JUAN JOSE HIERRO SUREDA [mailto:juanjose.hierro at telefonica.com]
Envoyé : mercredi 28 septembre 2016 15:51
À : JUAN JOSE HIERRO SUREDA; Fiware-oasc-etsi at lists.fiware.org<mailto:Fiware-oasc-etsi at lists.fiware.org>; Lindsay Frost
Objet : [Fiware-oasc-etsi] Wrap-up confcall
Date : mercredi 28 septembre 2016 16:00-17:00 (UTC+01:00) Sarajevo, Skopje, Varsovie, Zagreb.
Où : Online Meeting
Can we have a quick call?
Here it is a link I suggest to use:
.........................................................................................................................................
Join online meeting<https://meet.tid.es/jhierro/M23N4M8S>
https://meet.tid.es/jhierro/M23N4M8S
Join by Phone
+34914329000
Find a local number<https://dialin.tid.es>
Conference ID: 501911
Forgot your dial-in PIN?<https://dialin.tid.es>|First online meeting?<http://r.office.microsoft.com/r/rlidOC10?clid=1033&p1=4&p2=1041&pc=oc&ver=4&subver=0&bld=7185&bldver=0>
.........................................................................................................................................
<< Fichier: ATT00001.txt >>
_________________________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.fiware.org/private/fiware-oasc-etsi/attachments/20160929/1a4a7185/attachment.html>
You can get more information about our cookies and privacy policies clicking on the following links: Privacy policy Cookies policy