[Fiware-oasc-etsi] Main points and action items re ISG CIM - request for feedback

[Lindsay Frost]

Dear Juanjo, dear Cathy, dear all,
we have exchanged a few personal emails, now I would like to summarize for the team and get feedback for next steps.

>From the call on 18.10 it seems clear that the advice given to the ETSI Board, and the ETSI Director General will be:
(a) oneM2M will advise that there is significantly overlap with their work, which is against the PPP agreement with ETSI.
(b) Hermann (of ETSI) will advise that the overlap is "only" on the API definition, so requirements and data models
    could go ahead and there could be a go/no-go decision later re developing an API
(c) SmartM2M will advise that the modelling work is useful, and should be preferably coordinated with SAREF work
    in SmartM2M, but they would like to see an ISG CIM start ... assuming that the API overlap with oneM2M is resolved.

Informal feedback
which I meanwhile got, indicates additional issues, even if not spoken aloud at meetings:
(d) ETSI officers are still not happy with "special IPR rules" in the ToR because OSS IPR is currently a highly sensitive
    issue in ETSI. Their lawyers have approved that part of our text, but it sticks in the throat of some ETSI people.
(e) There is still a fear that the ISG will be used to "rubber stamp some FIWARE protocols", which is against the
    pride and independence of ETSI.
(f) There is a fear that the ISG is not "broadly based" (see above point)

Some conclusions and actions
(based also on discussions with Juanjo and Cathy but they see this text for the first time):
(1) we should win the debate (ETSI Director General decides!) about whether creation of the ISG is
    something conditional to any agreement to the ETSI agreement with OneM2M  - otherwise we lose
(2) we should weaken the "should be done in oneM2M" argument by emphasizing in the ToR that
    transfer of information/documents/contributions to oneM2M is highly desired,
    and the PPP agreement provides for such transfer
(3) we should weaken the "special IPR" resistance by modifying the ToR to show ETSI IPR (FRAND) applies
      (but the CIM can monitor what parts of the spec get into an OSS and we can privately expect that
       members voting on a spec will carefully evaluate if it is implemented in OSS or not)
(4) we should get some extra "outsider" organisations to sign as Founding Members
(5) we should avoid losing control of API work - none of us wants paperware
(6) we should  show the overlap of CIM with oneM2M is non-crucial
              - i.e. update the ToR to make this clearer
              - e.g. a feature comparison of NGSI JSON-LD with Mca
              - e.g. we already made a Use Cases document
(7) we should socialize all the above arguments inside ETSI (e.g. at M2M Workshop in two weeks).
(8) we should have a teleconf/f2f meeting with ETSI people during the Workshop period
              - Juanjo cannot be at ETSI HQ, but who else could attend a f2f meeting there?

Why bother?
I know some of you are tired of this whole discussion. Yet most of the steps above are not too hard,
or anyway are useful, and an ISG has many practical advantages we will appreciate. It also allows much
easier flow of information to/from other standards bodies. For any of you in EU projects, relevant
material which you prepare/present to the ISG will count as "dissemination" at least.

Please give feedback if you agree and will help with the conclusions above!

Below are my notes of the 18.10.2016 call
cheers
Lindsay

On 19/10/16 16:01, Lindsay Frost wrote:

Dear Cathy and Juanjo,

I did not take formal notes, however see below. Meanwhile I had some separate conversations

and I am still confident that (despite some "formal" objections) there is a high chance of starting the ISG.

I admit I did not feel that way after the meeting, but I do now.



______ Main points from the meeting were ______

1) it was very useful that Cathy could represent the smart-city views directly, and I was impressed that

     Juanjo stayed calm the whole time .... I was several times tempted to make impolite remarks!

2) the oneM2M view seems to be that they can do everything: not only can the Mca interface handle any data,

    the oneM2M repositories can be used to contain also  any context information, and can be queried

    for extracting needed "joins" of the data for smart-city applications (and developers)

        - LF, added later: this may be theoretically possible but not currently the case.

        - JH, added later: developers drive adoption.  I have seen many APIs that haven't got adopted

          because they were not designed taking into account the developers' perspective well enough.

3) the oneM2M view is that possibly other systems would be more efficient than it, but it is better

     to restrict everything to one system than to allow fragmentation

        - JH, added later: that describes their view, but we have to battle it

4) the smartM2M view is that FIWARE, oneM2M, smartM2M and other systems all have their place,

    and it is only important to avoid duplication of effort yet allow interworking. In particular it would

    be very useful if the ISG CIM would create information models for smart-city work.

        - LF, added later: however unfortunately there is no guarantee that any SDO would _use_ those models,

        - JH, added later: we see the results of the ISG as a package.

          Developers' should know what API they can use information models with and how both can be used together.

5) oneM2M believes that, even by avoiding any device-oriented interfaces in the ISG CIM, there is still

    overlap because the CIM context model could be done inside oneM2M (see points (2) and (3) above)

6) we were warned NOT to define an API until _after_ an information model for smart-cities is agreed,

    because the API puts constraints and limitations

        - LF, added later: I can see their point, and I would be willing to agree to _parallel_ development,

          but serial development is far too slow   ... haven't they heard of Agile Development?

7) it was agreed that technical discussions should happen in a transparent way, e.g. in the ISG,

    and that the ToR should only cover the scope and (if needed) certain check-points for go/no-go decisions

        - JH stated several times that such go/no-go decisions should be fair, not unilateral

______ Next steps we agreed (all in the meeting) are______

1) CIM team make some joint notes to distribute to the others on the CIM list (Hermann may also send some)

2) CIM team propose to oneM2M some realistic use case for smart-city services and ask how THEY would solve it

    ("realistic" to me means getting inputs for an entity from various sources and including querying of

   the model which does more than just read back out what was written in previously, i.e. includes filters)

3) try to get a f2f meeting of CIM and oneM2M people at ETSI during the demo week starting 14th November

4) make a "last chance for agreement" call  on 22nd November at 17:00 with Hermann and others


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.fiware.org/private/fiware-oasc-etsi/attachments/20161103/796604fe/attachment.html>