[Fiware-standardization] FIWARE Input to OMA about NGSI - copyright permission needed from Orange, NSN, SAP, Telefonica, SAP, Telecom Italia asap

[thierry.nagellen at orange.com]

Dear Fermin,, dear all,

I would support the approach from NEC for the following reasons, which should also answer to some of your questions:

·         Delay: we are at M27 and we will react at the last minute for a new delivery maybe for M36 but I'm not confident it will be part of our priorities one month before the end of the project. So I prefer to provide all our current results to a community than only a part;

·         As far as I know, there is no other proposal to implement OMA NGSI 9 & 10 so we have no risk that the contribution will be rejected. Describing that some parts are in an early draft, as the standardization body manages itself its documents, could push people/companies to become new contributors, and much better to follow what we are doing in Fi-Ware sp attract some 3rd parties also for existing GE instances which are using Fi-Ware NGSI;

·         EC is also a main driver and EC wants some results in standardization and in fact, only IoT has concrete outputs with NGSI but also a bit in ETSI-M2M with semantic contribution. So we cannot avoid to submit everything, it will be easier to explain that we will submit a revision based on our results

·         And last but not least, we spent lots of time on this topic and this is totally normal but we have to show the results of our work. We have not to emphasize what is not clear, just to explain also what is in our roadmap and that we have on-going work on convenience operations.
BR
Thierry

De : fiware-standardization-bounces at lists.fi-ware.eu [mailto:fiware-standardization-bounces at lists.fi-ware.eu] De la part de Fermín Galán Márquez
Envoyé : mardi 9 juillet 2013 11:56
À : Tobias Jacobs
Cc : Ernoe Kovacs; fiware-standardization at lists.fi-ware.eu; Juanjo Hierro; SERGIO GARCIA GOMEZ
Objet : Re: [Fiware-standardization] FIWARE Input to OMA about NGSI - copyright permission needed from Orange, NSN, SAP, Telefonica, SAP, Telecom Italia asap

Dear Tobias,

I agree in that there is a significant effort put in these documents, thus more reasons to use the best strategy towards OMA in order to get all our contributions standardized. And, in our opinion, the best strategy is to start with the mature part (standard operations), then continue (if we are successful) with the not so mature part (convenience operations).

I have experience in other standarization bodies (I'm one of the contributors to OVF 2.0 in DMTF) and too ambitious contributions use to fail when working groups/committees think that proposals are not aligned with the current standard or are not mature. In that cases they tell you "thanks, re-do it and try again" and you have to wait months to get another chance. In our case, our best option is the standard operations binding as it is very aligned with the existing OMA standard (it is basically a REST XML binding of the existing OMA document) and it is very mature (we have even an XSD document for all the XML elements involved).

Regarding "version chaos", I'm not sure what do you mean (maybe it was something that happens before I joined to the project)... but a proper document management (pe. using a "changelog" table in the documents and Word trac control, using docman instead of SVN to store documents, etc.) could solve it.

Regarding document preparation efforts, I think is pretty simple to prepare documents when you have all the material. In particular, preparing the reduced version of the document has taken around one hour (very small effort). Reintroducing existing convenience functions part would take around the same effort.

Regarding, justification (to whom?) I think is a matter of explaining our strategy. As I told in my previous email: "we are not proposing to leave convenience operations out of the scope of contributions to OMA. What I mean is that currently is not the right moment and that we need to refine it a bit more before that (fiware-ngsi mailist is probably the best place to do that). Let's focus our initial OMA contribution in the more mature part of our work: the standard operations binding."

In addition, it would be great to know how OMA internally works. E.g. they have WPs? how the WPs are governed? what is the process to evolve standards with contributions (e.g. ballots to include ? A briefing on "OMA governance and procedures" will be highly welcome.

Best regards,

------
Fermín

El 08/07/2013 15:10, Tobias Jacobs escribió:
Hi Fermin,

the feeling from the NEC people in WP5 is more that we should submit the whole standard document, not only because our work package has put considerable effort into it.

I agree that the maturity level is not 100%, but proposing bug fixes later is always possible without big problems, and anyway also the abstract specs need some bug fixes and clarification as we have identified in the project.
What is happening now is that the interface is implemented by a number of GEs and that the interoperability is tested, so if there is a good chance that bugs will be found and reported it is now and in the next months.

On the other hand, if we for now remove the convenience operations, we

-          will have another version chaos and inconsistency between the FI-WARE binding and the OMA binding

-          will have much more effort: now for making a new reduced version, and later for re-introducing the convenience functions if we want them to become part of the standard.

-          might potentially have problems justifying our efforts in the binding if it turns out that only the straightforward part (one resource per operation, direct translation of data structures into xml schemas) is proposed for standardization.


What do you think?

Thanks and best regards
Tobias



From: Fermín Galán Márquez [mailto:fermin at tid.es]
Sent: Mittwoch, 3. Juli 2013 18:40
To: Lindsay Frost
Cc: Ernoe Kovacs; Juan Bareño Guerenabarrena; Miguel Carrillo; Juanjo Hierro; luca.giacomello at telecomitalia.it<mailto:luca.giacomello at telecomitalia.it>; fiware-standardization at lists.fi-ware.eu<mailto:fiware-standardization at lists.fi-ware.eu>; Tobias Jacobs; SERGIO GARCIA GOMEZ; CARLOS RALLI UCENDO
Subject: Re: [Fiware-standardization] FIWARE Input to OMA about NGSI - copyright permission needed from Orange, NSN, SAP, Telefonica, SAP, Telecom Italia asap

Dear Lindsay,

"Would you (or a colleague) be willing to modify the two documents (using change tracking) to delete the "not mature" sections ?"

I can try to do a first draft on it.

Best regards,

------
Fermín

El 03/07/2013 18:29, Lindsay Frost escribió:
Dear Fermin,
I can fully appreciate your viewpoint. For the purpose of demonstrating FIWARE partners' commitment
to standardization, your approach is perfectly suitable.

Would you (or a colleague) be willing to modify the two documents (using change tracking) to delete the "not mature" sections ?
Potentially the sections could be retained but replace the content with <<Placeholder for further work after initial draft is mature>>.

Thank you for your feedback how you like to handle it.
best regards
Lindsay

PS Dear Ernoe, please comment later?


From: Fermín Galán Márquez [mailto:fermin at tid.es]
Sent: Mittwoch, 3. Juli 2013 15:02
To: Lindsay Frost
Cc: Juan Bareño Guerenabarrena; Miguel Carrillo; Juanjo Hierro; luca.giacomello at telecomitalia.it<mailto:luca.giacomello at telecomitalia.it>; fiware-standardization at lists.fi-ware.eu<mailto:fiware-standardization at lists.fi-ware.eu>; Tobias Jacobs; Ernoe Kovacs; SERGIO GARCIA GOMEZ; CARLOS RALLI UCENDO
Subject: Re: [Fiware-standardization] FIWARE Input to OMA about NGSI - copyright permission needed from Orange, NSN, SAP, Telefonica, SAP, Telecom Italia asap

Dear Lindsay,

We (Telefónica) agree in general terms that that FI-WARE work on NGSI could be a good contribution to OMA. However, before given our formal agreement as you request we would like to define "the contribution" more precisely.

I mean, we are not sure if all the content included in the attached documents (NGSI-10 HTTP REST-ful binding draft.docx and NGSI-9 HTTP REST-ful binding draft.docx) should be submitted to OMA as initial contribution given that 1) there are parts that we consider at quite mature and other that aren't so matured, 2) the initial contribution to OMA should include only the mature parts.

In particular, we think that the part about the binding for standards operations (including the XSD) is mature for contribution. The part regarding convenience operations is not so mature due to the following reasons:

  1.  Inconsistencies. E.g. in the NGSI10 binding section 2.1.2 (and subsequence sections) "/contextEntities/{EntityID}" and "/contextEntities/{EntityID}/attributes" have exactly the same behavior. Thus, why two have two different URLs at the end?
  2.  Some convenience operations are not "so convenient". In particular, the ones related with subscriptions, which use the same request XMLs than the ones used for standard operations (e.g. subscribeContextRequest, updateContextSubscriptionRequest). So, what's the point of using convenience operations here if the standard operations is "equally complex" to use?
I would like to clarify that we are not proposing to leave convenience operations out of the scope of contributions to OMA. What I mean is that currently is not the right moment and that we need to refine it a bit more before that (fiware-ngsi mailist is probably the best place to do that). Let's focus our initial OMA contribution in the more mature part of our work: the standard operations binding.

In the meanwhile, we will contact our Telefonica's OMA delegates to make them aware of this.

Best regards,

------
Fermín

El 01/07/2013 15:26, Lindsay Frost escribió:

Dear all,



the FIWARE Standardisation Report is due this month and we noticed that there is some very good

FIWARE input about NGSi which could be submitted into OMA, helping to fulfill our project goals.



I have the help of NEC colleagues in OMA ARC group, who would be prepared to submit the contribution

(see attached) on behalf of FIWARE ... *** BUT *** .....



BUT I need formal agreement from the co-authors of the draft specification, so

     Orange, NSN, Telefonica, SAP, Telecom Italia members should please do as follows:

  (a) inform your colleagues in OMA that this topic is coming soon

        and ask them if they would like to co-sign it? (if yes, I need their email addresses)

  (b) confirm to me (so I can reference it if asked) that your company releases any of its copyright

        on the text in the attached zip files according to OMA rules

  (c) make sure your colleagues are aware that the material will be under FRAND licensing rules of OMA

       (inside NEC I already checked that actually there is no known IPR in the files, being based on HTTP)

  (d) confirm to me that you are working on these steps, so I do not nag more ;-)



This nice activity will fail if I do not get replies from ***all*** copyright holders (Orange, NSN, SAP, Telefonica and Telecom Italia)

as soon as possible, i.e. next OMA ARC teleconf is on 09. July.



Please do reply positively! Please fwd this email to whoever should see it with a recommendation to support it!

If anyone is AGAINST this step, please speak up.



best wishes

Lindsay



Note: SAP is not an OMA member, but (b) and (c) and (d) still apply!







________________________________________

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












_______________________________________________

Fiware-standardization mailing list

Fiware-standardization at lists.fi-ware.eu<mailto:Fiware-standardization at lists.fi-ware.eu>

https://lists.fi-ware.eu/listinfo/fiware-standardization

________________________________

Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo.
This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at:
http://www.tid.es/ES/PAGINAS/disclaimer.aspx

________________________________

Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo.
This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at:
http://www.tid.es/ES/PAGINAS/disclaimer.aspx

________________________________

Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo.
This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at:
http://www.tid.es/ES/PAGINAS/disclaimer.aspx

_________________________________________________________________________________________________________________________

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-standardization/attachments/20130709/4ee61356/attachment.html>