- From: Kazuyuki Ashimura <ashimura@w3.org>
- Date: Fri, 15 Apr 2016 01:03:25 +0900
- To: Public Web of Things IG <public-wot-ig@w3.org>
- Message-ID: <CAJ8iq9XkAYPOiN-dguKFaoiVCdOJcB47zqTubdi0sFTLzXoipw@mail.gmail.com>
available at:
https://www.w3.org/2016/04/13-wot-minutes.html
also as text below.
Thanks a lot for taking notes, Michael, Yingying and Dave!
Kazuyuki
---
[1]W3C
[1] http://www.w3.org/
- DRAFT -
WoT-IG f2f Day 2
13 Apr 2016
See also: [2]IRC log
[2] http://www.w3.org/2016/04/13-wot-irc
Attendees
Present
Joerg_Heuer(Siemens), Dave_Raggett(W3C),
Kaz_Ashimura(W3C), Michael_Koster(Samsung,
_SmartThings), Soumya_Kanti_Datta(Eurecom),
Matthias_Kovatsch(Siemens), Taki_Kamiya(Fujitsu),
Victor_Charpenay(Siemens),
Louay_Bassbouss(Fraunhofer_FOKUS),
Toru_Kawaguchi(Panasonic), Frank_Reusch(RWE/Lemonbeat),
Kazuo_Kajimoto(Panasonic), Claes_Nilsson(Sony),
Yoshiaki_Ohsumi(Panasonic), Katsuyoshi_Naka(Panasonic),
Ryuichi_Matsukura(Fujitsu), Kazuaki_Nimura(Fujitsu),
Daniel_Peinter(Siemens), Sebastian_Kaebisch(Siemens),
Johaness_Hund(Siemens), Yingying_Chen(W3C),
Jeff_Jaffe(W3C), Alan_Bird(W3C)
Regrets
Chair
Joerg
Scribe
mivhael, yingying_, dsr
Contents
* [3]Topics
1. [4]WG Charter
2. [5]Contribution of Fujitsu on Architecture@PK1140
3. [6]W3C "Web of Things" Logistics
4. [7]Working Group Charter
5. [8]Rechartering the Interest Group
6. [9]Deliverables
7. [10]logistics
* [11]Summary of Action Items
* [12]Summary of Resolutions
__________________________________________________________
WG Charter
<inserted> scribenick: mivhael
Dave introduces the topic of charter review
Interest group has been an incubator of ideas, other working
groups forming e.g. security
Charter typically 2 years
Chair will be needed
Process of initial draft + refinement
3 years is not a long time
Joerg: continue discussion from yesterday re inter-platform
over web
Claes: what is the network effect?
Dave: value increases as the number of participants in a
service increases
... face to face meetings
... introduce the web landscape in the document and limits the
scope so organizations can determine IPR concerns
... the WoT is based on web architecture
... introduce diagram and ask Claes to comment
Claes: important that scripting API is for both exposing and
interacting with things
... also important to specify other scripting environments
besides js
... Table, what is the relation between this table and what we
are going to standardize ?
DAve: we could annotate this with the information about what we
are going to do
Sebastian: the document should set out early to define what we
are going to do
Dave: not a spec for what you do in a browser, otherwise we
need browser architects
Joerg: figure vs. range of architectures but the figure only
shows one scenario for architecture
... it needs to convey what we are working on, and can we
communicate the range of scenarios and architectures
... most people are visual, can we show some of a range of
target architectures
... also, what about discovery and other aspects of the system
Dave: it needs to be small and we need to be careful about what
we express
<kaz> [13]Michael's issue on github
[13] https://github.com/w3c/charter-drafts/issues/52
Joerg: what are the problems we are looking at, and our
understanding of the approach
Johannes: THe image should convey 3 good messages
... about what we're doing
Dave: what is WoT as opposed to IoT should be addresses witj
specific intention
... sec. 1.1 describes what we want to do
... starting with TC as vocabulary rather than ontology; more
developer friendly
... security data model not discussed
... concerned that srcurity is not at the same level of
maturity; is trust assertion too ambitious and be dropped
r/scrurity/security/
Kaz: Is this scoping?
Dave: what should we do?
Kaz: should this be shorter? the explanation is overkill, we
should express the key essence
Dave: shorter description would broaden the scope
... will drop the security one
Kaz: should be the few points that express what the whole group
agrees with
Dave: trying to set expectations without too much detail
... we know we need these elements
Daniel: second bullet is concrete, others are too abstract
... should be balances in level
Joerg: make it more focused and make references to other
documents
Sebastian: Doubts that we have worked out how security is done
with linked data
Dave: Oliver wanted to make sure security is mentioned
... we could cite external sources instead of adding content
... and detail
... get review of companies before review
Joerg: ask Oliver for more information about what we should do
Dave: get feedback on the approach and what security people
would like to see
... srcipting section - Johannes invited to present this part
Johannes: Text based on github collection
... why do we need a scripting API and what functions are
needed based on some use case descriptions
... looking at both server side and client side, but it looks
like it is not in the document; it should be in there
Joerg: it is in the first bullet but not clear
Johannes: stronger explanation of the server side scripting
Dave: it's not clear what we mean by server
Johannes: Message we want to convey is that we are scripting
for both access and for exposing, providing
Matthias: server defines a specific interaction pattern
... are we locked into protocols that are client-server, should
there be an abstract interaction model for who initiates and
who provides
Dave: client-server is also misleading
Matthias: assigning server roles to a browser is confusing
Johannes: client interacts, server exposes
Kaz: there are some diagrams we could include
Joerg: we should not assume too much about the audience, get
feedback from reviewers
Johannes: when we have a better way, we can update it but for
now as is
Dave: collect feedback
Johannes: could we have 2 bullet points to illustrate
provider/consumer
Dave: points need to stand alone without relying on a lot of
explanation
Joerg: security is a question to expect here
... we should explain that we are aware of the security issue
Claes: should not use "servient" here
Dave: get tech writers to help
... this will be reviewed by technical people
Joerg: the first section should be more introductory and
complete for a first evaluation
... get outside reviewers to look
... let's be clear about what our message is in the first
section
Johannes: can we get a pull request from Louay?
... describes discovery on one bullet, needs some work?
... description of thing life cycle, want to add something like
creating a thing as a mirror for another thing as an example
... try to explain how different languages are supported in a
consistent way independent of the lenguage
Dave: design pattern
Soumya: provisioning as part of the life cycle
Johannes: does it belong with discovery?
Louay: could define a setup phase in the life cycle
Johannes: not part of the runtime
Louay: has high requirement for security
Soumya: registering could be like provisioning for some cases
Joerg: we need to explain why this appears in the document here
Kajimoto: How do we define state transitions in the life life
cycle model? What are the APIs? examples?
<kaz> kajimoto: mentions the need for managing the transition
of state/phase to handle lifecycle
Matthias: we need metadata that describes life cycle
transitions and states
TD has a life cycle also
Sebastian: we are discussing
Daniel: should there be a separate security section
Johannes: it's good to have security statements in the
descriptions of how we do things also?
Dave: in the intro also?
BIndings
Johannes: this is to explain to developers how to adapt
protocols to the WoT environment
... each protocol has some important features that need
consideration in the binding, the protocol experts should be
involved
Soumya: oneM2M has a protocol binding system
Dave: other groups also have protocol bindings
Johannes: bindings to protocols or frameworks, the scope of it
is bigger
... there may be some confusion around this
Claes: not sure how this impacts our scope, could it be huge?
<Soumya> oneM2M - HTTP protocol binding -
[14]http://www.onem2m.org/images/files/deliverables/TS-0009-HTT
P_Protocol_Binding-V1_0_1.pdf
[14]
http://www.onem2m.org/images/files/deliverables/TS-0009-HTTP_Protocol_Binding-V1_0_1.pdf
Claes: more th escope of the target organization
<Soumya> oneM2M - MQTT protocol binding -
[15]http://www.onem2m.org/images/files/deliverables/TS-0010-MQT
T_protocol_binding-V1_0_1.pdf
[15]
http://www.onem2m.org/images/files/deliverables/TS-0010-MQTT_protocol_binding-V1_0_1.pdf
Dave: the 2 have to work together somehow, from both sides,
leave it open to joint determination with each organization
Johannes: the main output should be how you create a binding to
a protocol or a framework
Dave: we could have informative docs as well to help with this
Matthias: specifically, we want to coordinate and give guidance
but not make the documents
Dave: we should collaborate on the framework-specific documents
Soumya: we could review the oneM2M bindings in TF-AP
Johannes: we could work one level up from this
Dave: bindings to platforms and protocols, orgs we work with
Claes: What about e.g. websockets, who will make the bindings?
Dave: we could charter another activity if needed
... IETF, OASIS, etc. could get involved and help
Johannes: it could be a huge space to try to write binding
specifications
Johannes, we could statr the work informatively and ask SDOs to
pick up the normative work
Louay: could use uri-beacon for pointing to a TD, and provide
some basic mapping
Matthias: some protocols can be mapped, some protocols need to
be modified or have a shim layer added which is out of scope
for W3C
Johannes: this is about who writes the normative text. It's
much better if the SDOs do this
... we need to make it very clear what is needed to be done to
bind a protocol or platform to WoT
Dave: as a matter of scope, we need to be precise about what we
are going to do. For example, we could decide to work with SDOs
to identify changes
Joerg: do this in the context od collaboration
Kaz: we have identified target platforms in the landscape
documents, can we mention these in the document
<inserted> [16]Landscape document
[16] https://w3c.github.io/wot/landscape.html
Joerg: worried about making a list, what message does it sent
to orgs that aren't on the list?
Dave: we should be able to refer to some examples
Matthias: should id be a scope issue vs. a logo collection
... transfer vs. transport
<kaz> [17]Michael issue on github about transfer protocol
[17] https://github.com/w3c/charter-drafts/issues/51
Johannes: this will appear in the collaborations with other
organizations
Dave: if important protocols or platforms need changes, we
would need to take action, what is the action as scope
definition
Joerg: what is in scope, out of scope, for example a shim layer
is between scope
all agree we don't do protocols
Dave: the charter is expected to provide limited detail on the
deliverables
... and timelines, e.g. first public draft
Joerg: should the deliverables tie back to the scope, and be
consistent with what is there
Dave: what is the new W3C charter template?
Joerg: is it about completion ?
Dave: more toward first WG draft as a milestone
<kaz> [18]TV Control WG charter
[18] https://w3c.github.io/charter-drafts/tvcontrol-2015.html
Dave: non-normative deliveraables also
Joerg: add scenarios for cross-platform
Matthias: add architecture document as informative reference
Dave: could be kept as IG document
... binding examples?
... requirements could be IG document
Joerg: normative vs. official/unofficial
Matthias: IG can publish an official informative documants
Dave: IG can do the informative work
... maybe bindings should be a WG product
Joerg: also the primer could be a WG deliverable
Matthias: the intention is to cover a broad range in TD without
needing a lot of other logic
Joerg: specify the relationship of the WG to the IG
<scribe> Done with Charter review
Joerg: At some point the comment phase is done when the number
of comments is reduced and we have more confidence
... We should repeat the run-through as needed
... set a reasonable time frame, have a webconf run-through
Dave: hard to do this in one week
Joerg: 3 weeks?
... ask for input, incorporate comments, have the ren-through
Claes: email is not usually effective
Joerg: github issues
all agree on using github issues
Johannes: send email when you post an issue
Dave: members of IG get feedback from their
company/org/community to insure there is a broad level of
support
Joerg: both company internal, and outreach to the community
... can we get an indication from everyone on whether your
company would join the WG
<kaz> [19]Day2 agenda
[19]
https://www.w3.org/WoT/IG/wiki/F2F_meeting_2016,_April,_11th_-_13th,_Montreal,_Canada#Wednesday.2C_13th_of_April.2C_WoT_IG_Meeting
Joerg: how should we proceed with the meeting today?
... focus on topics for the rest of the day
... rest of the contribution from Fujitsu
... BLE mapping
... start on the bindings scenario document
... those 3 items, are there others?
... should we split into 3 groups next?
<kaz> [ Room assignment will be put on the wiki ]
<kaz> [ morning break ]
__________________________________________________________
<yingying_> scribe: yingying_
Contribution of Fujitsu on Architecture@PK1140
<kaz> [20]Fujitsu's slides
[20]
https://lists.w3.org/Archives/Public/public-wot-ig/2016Apr/att-0022/WoT_architecture_update_160412.pdf
<inserted> Matsukura: page 12
Matsukura: : Maybe many protocols can be converted to this
Legacy Device API.
Johannes: The procotol mapping would be the same? The
difference is in the adaptation to legacy device?
... common APIs would be on top of the protocol mapping.
Examples would be helpful.
Claes: I don't have strong opinion on it. I am wondering the
purpose of the diagram.
Johannes: Where is the line to map the legacy protocol to
protocol mapping layer.
Claes: do we need to have the resource manager layer? it's the
implementation.
Johannes: This resource management is not about the CPU/memory
management.
... I'm not very sure where the TD is pointed. It could be here
in the diagram or one or two layer higher.
<inserted> Matsukura: page 13
Matsukura: This slide shows the resource management.
... the meta data instance is for device.
<inserted> kaz: TD metadata part specifies the basic device
capability whle the TD instance part specifies the information
to identify concrete devices installed at some place, e.g., the
user and the location
<inserted> Matsukura: p14
Matsukura: next slide for protocol mapping.
... we can implement the Device interface.
<inserted> Matsukura: p15
Matsukura: this slide shows the App script provider. App script
calls the script provider and the script provider will use the
information in TD to call the protocol mapping interfaces and
then communication protocol APIs.
... p16 shows the communication protocol layer.
... p17 is the summary.
Joerg: if you are on your local thing, does the local thing
have the resource management.
... is there anything that you don't know how to find the
resource. It is expected to be internal.
Johannes: what should we standardize between resource
management and protocol mapping.
... the red line of API should be between resource management
and protocol mapping.
[some discussions on balance what is in TD and what is in
protocol mapping]
Joerg: now we need to visualize this two ways instead of just
discussion.
Kaz: maybe we can create a github issue of the architecture
document for this.
Johannes: we should really write down this question whether the
app script should know the protocol mapping. For my
implementation, the app script does not know the protocol
mapping.
... if several protocols are supported, should the client
decides which protocol to use or should the server side decides
it.
... for these kind of questions, it would be good that we could
visualize them.
... it is confusing to me what the legacy device API refers to.
Is it the protocol to talk to the device API?
Kaz: given that the upper layer on top of legacy device API and
WoT API is communication protocol, it is confusing that they
are called APIs.
... maybe we can just simply say legacy protocol and WoT
protocol instead of legacy device API and WoT API.
... we should think about the concrete APIs between resource
management and protocol mapping.
Johannes: we should also consider the northbound API and
southbound API.
... for the next step, could we have ppt version as the ground?
In next call, we could discuss on it further.
[ Lunch ]
__________________________________________________________
W3C "Web of Things" Logistics
<dsr> scribenick: dsr
Joerg shows the topics for this afternoon’s session.
- report from the communications & collaboration task force
- draft WoT WG charter and WoT IG charter
- IG perspective
- deliverables/documents
- plugfest preparation
- meeting logistics
Joerg invites Yingying to talk about the communications and
collaboration task force.
slides at:
[21]https://www.w3.org/WoT/IG/wiki/images/8/88/Communication%26
Collaboration_Report_Apr2016.pdf
[21]
https://www.w3.org/WoT/IG/wiki/images/8/88/Communication%26Collaboration_Report_Apr2016.pdf
The task force was set up to strengthen awareness of the
technical and business benefits of the Web of Things.
Joerg runs through the resposibilities of the task force.
The talk on behalf of the eclipse foundation relates to our
goal to reach out to the open source and maker communities.
The W3C Business Development team need help with outreach and
recruitment - which will bring fresh resources to the work we
are doing.
Please help the task force in its aims
Since the last F2F, we prioritized and supported events
relevant to the W3C web of things.
Yingying has added testimonials to the WoT landing page, we
plan improvements in their presentation.
This F2F in Montreal is the first time we’ve been hosted by an
external group.
We need to work to prepare for our next F2F in July in Beijing
We’ve had liaisons with alliances and SDOs, e.g. OCF and OPC
Some pointers and more detail are in the slides
We’ve been collecting testimonials from IG members and are now
also seeking to get testimonials from SDOs and alliances
Joerg turns to the topic of the Beijing F2F in July
This will have 2 days of open meetings followed by 2 days for
the IG internal discussions.
Yingying explains that CETC hosts the China IoT alliance and we
expect to have talks from key people along with demos and talks
from IG members.
<kaz> [22]July f2f wiki
[22]
https://www.w3.org/WoT/IG/wiki/F2F_meeting,_July_2016,_China,_Beijing
Joerg talks about pros and cons for having the senior/business
people on either the first or the second day.
Yingying: we need to finalise this soon.
Jeff_Jaffe: I like the idea of exposing people to the plugfest
demos
This is also an opportunity to introduce industry people in
China to the work we’re doing.
Yingying: we need a good estimate for the number of people who
will attend from the IG
<Sebastian> thanks kaz for the information
Joerg: the number of F2F participants has depended on the
location, travel restrictions and conflicting events.
We need to clarify the expectations of the local people as to
the ordering and nature of the open days.
Johannes: the way we’ve had our plugfests isn’t so good for
non-technical people
Joerg: perhaps we can set it up so that the visitors can be
given a guided explanation as they move between demos
Jeff: we need to be sensitive to making ourselves easy to
understand, e.g. speak slow and simple and give clear elevator
pitches
Dave: perhaps we could provide some written descriptions of the
plugfest demos prior to the event?
This could help with making our work easier to understand
Joerg: we need a contact person for the plugfest. This
especially important for the network issues we’ve had, e.g. in
Montreal.
Yingying: if you can provide us with the requirements we can
take that on.
Dave: this is likely to involve testing the site network and
negotiating arrangements for us to set up an effective demo
network.
Joerg: we’ve had problems here at UQAM with the network
blocking our gateway.
Yingying: the July F2F wiki page is still very rough and will
change considerably
Joerg displays a slide on liaisons.
Matthias summarises the joint OCF/W3C/T2TRG meeting in
California
OCF for instance currently use RAML for describing their APIs
and we have a good chat about the extra value that thing
descriptions can offer.
<kaz> dsr: provides some more supplementary information
Dave summarises the IAB workshop on semantic interoperability
There were some good discussions about the technical challenges
for both semantic interoperability and end to end security
We will be able to build upon this, e.g. in the joint white
paper on semantic interoperability, and another on trust
assumptions in relation to end to end security
The IAB set up a mailing list, and wiki on GitHub to continue
the dialogue
<mkovatsc> [23]https://github.com/iotsi
[23] https://github.com/iotsi
Joerg: we need to clarify what we need to do next
Both in respect to recuiting people to the WoT activity, and
also in respect to open source projects and the maker community
events relating to th web of things.
Joerg: if you participate in the plugfest, you should aim to
provide open source implementation and documentation.
We want to encourage multiple independent implementations
The next teleconference for the communications and
collaboration task force will be on 18 May at 0600 EDT, 12:00
EU, 1800 China and 1900 Japan
Joerg encourages more people to join the communications and
collaboration task force
Joerg asks for how many IG companies have provided testimonials
so far?
Yingying: 6
<kaz> [24]WoT landing page
[24] https://www.w3.org/WoT/
Working Group Charter
We had 2 commenting rounds from the last F2F, and a very
productive discussion this morning.
Joerg summarises the outcome of those discussions.
We need to use github issues to track the issues raised today,
starting with the points from today’s minutes as written by
Michael.
<kaz> [25]github issues
[25] https://github.com/w3c/charter-drafts/issues
A revised draft of the charter by May 4
Telecon to discuss the draft on May 11
Finalised draft WG charter by May 18 for discussion outside of
the IG
Jeff: when will the charter be ready for AC Review?
Joerg: Summer?
Jeff: it would be good to aim to have a WG meeting at TPAC
AC Review is itself 4 weeks, but may take longer depending on
the comments received
The July F2F will be an opportunity for any final adjustments
to the WG charter.
Dave: we are tentatively planning for a joint IG/WG meeting at
TPAC.
Dave cites the experience of the Web Payments IG spawning a WG
as illustrative of what we’re going through
Jeff provides details of the Web Payments IG/WG story
Jeff: working back from a deadline can help to force the pace.
Dave: we need to work in sync on outreach, open source and
liaisons, in order to get the broad support for the WG in place
before the AC Review
Jeff is supportive of the idea of a joint meeting at TPAC even
if the WG hasn’t yet been formally launched. It would be a good
opportunity to gather a broad set of stakeholders and build
support.
Johannes asks Dave about the schedule for the open source work
and what needs to be done
Dave: we need complete implementations, documentation and demos
ready along with outreach to the relevant communities. The July
F2F open days provide a good target to drive that work towards.
<kaz> kaz: It would make sense to have rough expected schedule
till TPAC 2016 in September.
Joerg: adds one line on our expected schedule for TPAC 2016
Joerg: we’ve already chatted about the idea of starter kits for
the web of things
Rechartering the Interest Group
Joerg: displays a screen shot of the charter which ran out on
March 31
Joerg explains the value of continuing the IG in parallel with
the WG
We need to clarify the respective roles of the IG and WG
<kaz> dsr: summarizes the background
<kaz> michael: we can continue plugfest, etc., using the IG?
<kaz> dsr: yes
Dave gives a short rationale - the IG would work on open scope
topics including the plugfests, technical stuff that is not yet
mature enough to standardise, and outreach to external groups.
The IG would have a very narrow focus on driving a few specs
along the REC track
Johannes: I’m worried that we won’t have enough manpower to do
both groups
Dave: this is why we’re working on convincing companies to get
involved and grow the manpower available
Jeff: if companies feel this is important and if they are doing
implementation work they presumably will, then they can be
expected to provide additional manpower
Joerg: building strong relationships with industry alliances
and SDOs is critical, and very important role for the IG. The
IG also can look at the work that needs more study.
We can look at the range of topics we’ve already raised and
identify those the IG should plan for.
Jeff: six weeks ago I presented a keynote at the Industry of
Things World conference in San Diego.
There was strong support for W3C’s role in enabling
interoperability across platforms
During the recent Advisory Committee meeting, we asked Members
to name the next big things.
Web Security was the highest followed by th Web of Things. This
work is essential, so I want to push back on the notion that
this is a fringe activity
Joerg: we need to clarify the next steps.
Jeff: today at the opening of the WWW2016 conference, Tim
Berners-Lee provided the opening keynote and covered the web of
things. So yet more support!
Joerg: we need to brainstorm on formulating the relationship
between the IG and WG
Matthias: it would make sense to co-locate the IG and WG
meetings and it would be worth thinking about the logistics for
that
Kaz: precedent set by automotive Business Group and the Working
Group it spawned. They co-locate with consecutive meetings.
Matthias: perhaps we can focus more on decision making at the
meetings and do more work remotely
Jeff: in practice there will be different people in an IG and
WG with just a few in both.
I don’t think we can extend the charter duration for the IG
unless we have a strong plan in place for rechartering within a
few months and planning for a charter of at least a year and
perhaps longer
<kaz> [26]WoT IG Charter
[26] https://www.w3.org/2014/12/wot-ig-charter.html
Dave: we have the precedent of the web payments and automative
groups to guide us in drafting a revised IG charter
Jeff reads from the existing charter. This already envisions
the IG launching work into existing or new WGs
Joerg summarises
Dave notes the need to start planning for dialog with other W3C
groups, e.g. on security
The IG charter should cover this
Kaz also suggests the IG should think about what to be done by
the IG side in addition to what to be done by the WG, and
mentions there is a possibility the CG could be used instead of
the IG if there is something to do but not for the IG after
launching the WG
Dave: the broadly scope CG hasn’t got any traction. Narrowly
scoped CGs could be a future option for incubating specific
ideas.
Joerg wraps up the discussion. We will set deadlines in
upcoming telecons
<kaz> Jeff suggests we think about the manpower for the
leadership for the WG/IG as well
Deliverables
Joerg reviews the work items we’re doing
These include the use case document, tech landscape document,
architecture document and current practice document.
We’ve agreed to June 10 for freezing the current practice
document for the July plugfest.
Joerg reviews plans for the plugfest. Three topics for
discussion included client interface for discovery, datatypes
and formulation of the protocol binding
Matthias summarises the work on thing description support for
protocol bindings
Joerg looks at the practical logistics. For example, a
developer how-to, participation info, network setup and prior
testing.
We need some pre-testing to reduce the time we otherwise have
to spend during the meeting
We would like to define a specific configuration that people
can test against before travelling to the F2F.
Daniel: we need to have someone responsible for defining the
configuration.
Joerg looks for a volunteer [the room falls silent]
Soumya: perhaps the people who are involved in IETF meetings
could provide advice
Dave: likewise, I could ask the W3C systems team who have
considerable experience with preparations for TPAC. However, we
need someone to take responsibiity within the IG
Michael agrees to look after the router set up config file.
Daniel agrees to look after the network requirements
Yingying will look after the local support for the networking
and other logistics
Joerg: we need the local team in Beijing to conduct some tests
in advance of the meeting.
We want things online by end of May.
Joerg: finally we need to review how we work between face to
face meetings
logistics
Joerg: we may want to reconsider the slots for the regular
calls
We may switch from task forces to a topic oriented assignment
of call slots
With the agenda announced a week in advance
Joerg suggests we have our next call on Wednesday April 20 at
2PM CET
What are the proposed agenda items?
Sebastian suggests we need more time and should start the call
the following week
Joerg says we will have the call on April 20, but *not* on
Thursday April 21
The next F2F is 11-14 July 2016 in Beijing, and the following
one in Lisbon on 22-23 September as part of TPAC.
Some of us may meet up during the IETF 96 in Berlin on 16 July.
Matthias: could we look into the logistics for a joint meeting
with the T2TRG on Saturday 24-25.
Dave & Kaz should ask Coralie about the possible availability
of rooms
This should also include the idea of a plugfest preparation
room
The plugfest would be on the 22nd
Dave: there is an opportunity for demos on the plenary day (Wed
21 Sep)
Joerg: let’s keep that open for now; the basic requirement is
having a preparation room on 21st.
<mkovatsc> [27]https://summit.riot-os.org/
[27] https://summit.riot-os.org/
Matthias the IETF 96 meeting will be combined with a RIOT OS
summit on July 16
Dave: we could perhaps plan for distributed demonstrations!
Joerg: we should consider planning the follow on F2F in North
America
Jeff: we should consider who are the biggest US companies we
want to get involved in the WoT activity
for instance Cisco, General Electric, browser companies, etc.
Joerg: Intel would be another possibility
<kaz> [28]Sunnyvale meeting minutes, fyi
[28] https://www.w3.org/2015/07/29-30-31-wot-minutes.html
Joerg: this is something we can take forward as a pending
action
Michael: I will look into this on behalf of Samsung
Dave: Google could be interesting, we have a standing
invitation for them to present their work on Brillo/Weave when
it is fully public.
Michael: a joint meeting with schema.org is another possibility
Joerg: we now done - thanks for coming to this meeting and talk
to you next week!
Kaz: one last point, we did talk about switching to a US based
time slot rather than Europe based slot
This only effects the two weeks twice a year when North America
and Europe are out of sync
Kaz: China, Japan and Korea don’t change their clocks, i.e.
fixed relative to UTC
Dave: we could fix to UTC then?
RESOLUTION: Fixing to North America would reduce risk of
clashes with other meetings during the 4 weeks a year when the
clocks are out of sync
Joerg brings the meeting to an end
[ Meeting adjourned ]
Summary of Action Items
Summary of Resolutions
[End of minutes]
__________________________________________________________
Minutes formatted by David Booth's [29]scribe.perl version
1.144 ([30]CVS log)
$Date: 2016/04/14 12:26:40 $
[29] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
[30] http://dev.w3.org/cvsweb/2002/scribe/
Received on Thursday, 14 April 2016 16:04:45 UTC