[Fiware-oasc-etsi] CIM ISG ToR proposal

[Franck Le Gall]

Hi

This looks fine.

We should hurry up in submitting to ETSI, otherwise we are at risk to get delayed again by 1 month.  I do not remember exactly when is the board meeting but Hermann wanted green light from us to “send ToR Omar/Enrico on Wednesday, 24.8, in order to submit the ISG proposal to the Board for consultation one week later”

So we may be running late

Franck

From: fiware-oasc-etsi-bounces at lists.fiware.org [mailto:fiware-oasc-etsi-bounces at lists.fiware.org] On Behalf Of Lindsay Frost
Sent: jeudi 1 septembre 2016 12:00
To: Juanjo Hierro (juanjose.hierro at telefonica.com) <juanjose.hierro at telefonica.com>; Fiware-oasc-etsi at lists.fiware.org
Subject: Re: [Fiware-oasc-etsi] CIM ISG ToR proposal

Dear Juanjo and all,

Thank you Juanjo for your explanation. I think I understand. I would like to suggest a slight clarification of your text to make the process explicit and automatic:

PREVIOUSLY:

Members and Participants of the ETSI ISG CIM agree that their contributions will not evolve from preliminary version of the Group Specifications up to stable versions of the Group Specifications until they provide a reference to a publicly available open source implementation of their contribution (developed by them or third parties) that can be used by applications developers.

SUGGESTED:

Members and Participants of the ETSI ISG CIM agree that, unless they provide a reference to a publicly available open source implementation of their contributions (developed by them or third parties), the corresponding contributions will automatically be withdrawn from the Group Specifications presented to the ISG CIM Members for approval according to section 3.5 of the ToR.
If everyone agrees on my suggestion, we might use the attached ToR ?

PLEASE NOTE: we still have some open issues in the ToR which I tried to complete as shown below:
They are not controversial maybe, but need a decision. I draft the answers below
and inserted them in the appropriate places using change tracking and comments. Please confirm!

(a)    " ETSI Group Reports and Group Specifications will only be approved within physical meetings,
or over a period which may extend beyond the end of the meeting whereby the attendees use electronic voting.

(b)    " Contributions for a CIM ISG meeting shall be uploaded a minimum of 72 hours prior to a meeting.
Late contributions shall be deferred to the next meeting unless there is clear consensus to make an exception.

(c)     " ISG CIM Members are only eligible for voting (voting members), if they have been present during at least 1 out
of the previous 2 physical meetings and 50% of the virtual meetings from the date they joined of
their last physical attendance;

(d)    Insert requested material about TMForum
"TM Forum is a global association for digital business. They provide a platform across a wide range of industries – communications, technology, cities and municipal government, finance, healthcare, and so on –  to collaborate and partner to co-create, prototype, deliver, and monetize innovative digital services for billions of customers."

Best wishes and waiting with eagerness for a consensus ;-)
Lindsay
________________________________________
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: Mittwoch, 31. August 2016 09:07
To: Lindsay Frost; Fiware-oasc-etsi at lists.fiware.org<mailto:Fiware-oasc-etsi at lists.fiware.org>
Subject: Re: CIM ISG ToR proposal


Dear Lindsay,

  Comments between lines ...

On 31/08/16 08:32, Lindsay Frost wrote:
Dear Juanjo, thank you for your email below, agreeing to the version I sent at Di 30.08.2016 20:39,
but reminding to discuss/add your paragraph re an open source implementation. I attach the docx.

Dear all,
Concerning Juanjo's paragraph below.  I am not confident that the mechanism
" until they provide a reference to a publicly available open source implementation of
their contribution" will assure the desired open-source result.

Examples of difficulties:

a)      I can well imagine that Company A might successfully contribute API
specifications  related to Topic A, but not be happy to reference/endorse a complete
implementation which they think does a bad job of Topic A ... but all the other CIM members
think is good enough (or the only running code maybe ;-).  That would mean that the Topic A
features would need to be removed from the final specification.

  There is a difference between "endorsing" and simply "accept" that a referred open source implementation is considered valid.   I would never use the term "endorse".

  If we were using the term "endorse" in the proposed paragraph, I would agree with this your point.   However, it is not the case.

b)      I can well imagine that in a long API specification, and Data Models, it will be very
hard to identify which exact contributions came from Company A. There is a famous example
in 3GPP where the order of two bits was reversed in a radio configuring protocol and the
patent behind it ("higher efficiency for xyz ... by ordering of bits in coded radio messages")
became Standards Essential. What happens in the API if Company A proposes the feature A,
but Company B slightly re-orders the parameters ... is Company A remembered as the author,
or is Company B ? Probably you want both A and B to endorse the implementation. But that
ends with all contributors to the specification needing to endorse the (same) implementation.

  There are two questions in your point.  My answer to the first question ("is Company A remembered as the author, or is Company B ? Probably you want both A and B to endorse the implementation") is "Yes, I want both A and B to comply with whatever rule we agree.

  The second question is what we want those two companies A and B to do.   The same applies here as with the previous point: we want them to *accept* (not endorse) at least one given open source implementation.  BTW, company A may point to implementation X and B may point to implementation Y, which means that, as far as both X and Y are open source, we are covering what want to cover: the fact that there would not hidden patent claims from the contributors (A and B).

  As an example, A and B may be contributing to the specs.   A points FIWARE as the place where they consider that a valid implementation of the specs exist as far as they are concerned.   However, organization B may be developing its own open source version Y they would refer to as valid implementation of the specs as far as they are concerned.   That situation effectively means that A and B are implicitly agreeing the would not be claiming any patent on any IPR they own that is considered essential, which is what we want to cover.

  Note that we don't need to make things over complicated.   The approach means that regarding each version of the specs, there will be always two stages: preliminary and stable.   When the "preliminary" version of the specs is published, specs are stable, but it is no confirmed there is a valid open source implementation.   The specs become stable when each of the contributors can point to at least one publicly available open source implementation they consider a complete and valid implementation of the specs.   This means that they don't need to necessary agree on which one, nor even if they agree on a single one, this doesn't mean they "endorse" it.   But the advantage is that if A, B, C and D have been the contributors and A, B, C can point to one product as valid open source implementation and contributor D doesn't want to point to any, then the valid question will be "Why don't you agree?"  "Is it because you don't want to allow valid open source implementations of the specs?"

  The proposed paragraph tried to cover this.   Another possibility is to establish that Members and Participants have to sign in their Agreements that they have to declare, at the time they make their contributions, whether they agree or not that open source implementations can be derived from their contributors to the specs without payment of royalties.

  I hope I have been able to explain well enough (this matters are complex :-)

  Best regards,

-- Juanjo

Can anyone please suggest some other mechanism ?

Thank you
Lindsay
________________________________________

From: Juanjo Hierro [mailto:juanjose.hierro at telefonica.com]
Sent: Dienstag, 30. August 2016 21:07
To: Lindsay Frost; serge.raes at orange.com<mailto:serge.raes at orange.com>; Franck Le Gall
Cc: Ernoe Kovacs; Martin Bauer; Juanjo Hierro
Subject: Re: [Fiware-oasc-etsi] CIM ISG ToR proposal


Hi,

  I agree to take this as new draft.

  Point is that whether we also agree to include the paragraph I was proposing (again for your convenience):

Members and Participants of the ETSI ISG CIM agree that their contributions will not evolve from preliminary version of the Group Specifications up to stable versions of the Group Specifications until they provide a reference to a publicly available open source implementation of their contribution (developed by them or third parties) that can be used by applications developers.

  My intention is that this doesn't mean that referred open source reference implementation become "part" of the spec.   The intention is to a) clarify that we are going to work on specs that are validatd through implementation (i.e., part of the "driven by implementation" approach, rather than allowing people to arrive and come with ideas when their companies have no intent to implement anything or even to adhere to the implementation some open source initiative like FIWARE is developing) and MOSTLY b) somehow make it implicit that contributions to the specs will be at the end of the day granted by contributors as royalty-free, otherwise an open source implementation would not be viable.   Note that I was proposing to say "they provide a reference to a publicly available open source implementation" and I have deliverately avoided to say "they provide a reference to a publicly available open source reference implementation".   I made this on purpose to avoid that ETSI claims that if we are talking about "reference" implementations then we are talking about implementations somehow "bound" to the specs and therefore whose development should be governed also by the group (in practice meaning we have to go for an OSG).

  But that is a discussion I'm happy to take after consolidation of the proposed draft as new draft.  BTW, fine to carry out the discussion in the more general list.

  Cheers,

-- Juanjo


________________________________

Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción.

The information contained in this transmission is privileged and confidential information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.fiware.org/private/fiware-oasc-etsi/attachments/20160901/3e427a57/attachment.html>