– DRAFT –
WoT F2F Meeting in Munich - Day 2

Opening

<kaz> agenda for today

Scripting API

Cristiano: Scripting recently changed timeslot
… from Monday to Wed 11-12 CET
… new slot works for most people
… Problematic for pacific time slot

McCool: Yes, early in the morning
… Okay for now

Cristiano: biweekly calls

McCool: Mondays are troublesome .. so Wed is okay

Sebastian: Progress?

Cristiano: Fixing issues ...
… waiting for fixes from TD

Daniel: async actions also
… waiting for TD progress also

Cristiano: Other aspects as well

Kaz: Taskforce should clarify the agenda topics beforehand, and invite relevant people also

Cristiano: Sure

McCool: Question, do we want to raise the level of abstraction

Cristiano: We also explored that aspect
… right now we just call the action

McCool: sure, just that we can monitor actions

Cristiano: Yes, still some pending issues we need to resolve

McCool: Supporting discovery?
… I might join those meetings

Cristiano: Jan, made some progress already

McCool: Question whether we need alignment / updates to discovery

TD

Ege: Taskforce is not going fast enough
… we do many tasks other than the spec generation
… project management etc
… TD features do not go fast enough
… fixing also issues with resources
… new feature is initial connection

<kaz> TD PR 2058 - Initial Connection Feature Description

Ege: PR 2058

<EgeKorkan> Proposed updates for "TD.Next Usability and Design Work Items"

Ege: one place
… for example for security definitions
… let's go into examples

<kaz> TD Examples

Ege: simple case: everything inlined
… group contentType, connection etc

Sebastian: Security ?

Ege: it is gone, part of the outer base form
… there are more complex examples

<Cris> +1 for consistency

Sebastian: Wonder why we use the term "form"?
… we have forms for interactions?

Ege: I will come to it later
… the more verbose examples
… new term, connectionDefinitions, formDefinitions

McCool: array for security goes away.. we just have one object

Ege: connectionDefinitions are for connection and security
… at any point you can inline things
… either string or object
… <Ege showing Example how it looks today>

McCool: Note: looks complicated but goal is to make common cases simple but complicated cases (e.g. multiple protocols in one Thing) possible
… Common case is simple

Ege: correct
… no need to repeat application/cbor all the time

Cristiano: What if we try to test all TDs we used in the past to explore how they might look like and simplify

Ege: good point
… There is also the possibility to add it in each form
… for a human it might look complicated
… maybe we should advise people not doing so

McCool: this is related to how we do parsing and resolution of names - in particular, do we have a preprocessor to eliminate name references?

Ege: flatten TDs -> canonical TD

Jan: If I want to combine security schema I need to use combo?

Ege: Yes

Sebastian: base still possible in global level?

Ege: we did not talk about that
… I think we want to remove it

Sebastian: was sometimes useful to have a single place

Cristiano: I think we can remove it

McCool: if we remove base on top level .. we should remove security also

Ege: then we can have contentType also

CA/Ege: I think this is different

Daniel: expanding is useful for machines

Ege: Agree

Kaz: we should clarify what kind of data model (expanded or not) at what time, e.g., static file on the Thing to be stored vs exported data model on the Consumer.

Ege: Would try to avoid changing files ..
… important for signing

Daniel: Do we need the counter part for expanding?

Ege: Yes, I think so

Bindings

<EgeKorkan> Binding Registry Requirements

Ege: important for OPCUA and ASHRAE
… how do you see that as an outsider?
… each binding is linked in binding document
… like a IANA regsitry
… managed table pointing to the actual content
… W3C has created mechanism for registry
… we can agree on the rules
… but we cannot easily change them later

Ege: other organization might create binding and take ownership .. which would be even better
… <Ege goes through rules>

Ege: 3 things
… what is in the table
… what is the lifecycle
… what are the requirements
… we require static fixed link
… prefix is important ... to avoid collision

McCool: Need to think about subprotocols also

Ege: yes

<McCool> (example of NGSI-LD - it's HTTP, but uses it in a particular way. Is it a subprotocol or a profile?)

Ege: we should also mention compatibility with TD version
… status of the binding

<McCool> (note: we use use htv as the prefix since http won't work - it would look like a URL...)

Josh: you might add the same examples in all sections

Erich: Why modv ? instead of modbus

Ege: people got confused with http prefix .. JSON-LD people suggested htv

Sebastian: What about BACnet in the W3C context
… should it be hosted at ASHRAE ?

Salvatore: We can talk about that
… but it is more complicated ... we had other requests as well
… the problem is maintenance
… we need to clarify that
… Question about multiple binding
… several networks or different buildings
… how do you identify?
… specify "where" this things is

Ege: location could be added

Sebastian: forms can have multiple connections
… or for each connection its own TD
… context see, important here.. like metadata

Salvatore: Do we have a ontology we a use

Sebastian: Yes

Cristiano: BRICKS?

Cristiano: About table
… table in document is per version
… binding can be for several versions

Ege: meant for breaking change versions

Cristiano: Information that binding supports multiple version is where?

Ege: In table and binding also

Salvatore: side question: what does full IANA registration mean ?

Ege: provisional state required before submission
… within IANA there are several states

Kaz: Salvatores comment implies that we need to think about several levels of location
… should continue to clarify that part
… smart city might be of interest also

Salvatore: At ASHRAE we created a dedicated ontology for that
… could be useful in this regard

McCool: We should follow up on the issues of location and multiple networks as part of our use case and requirements gathering process, which we will discuss in a bit
… driving use-cases

<Sal> https://open223.info/ this is the ontology I was talking about.

Ege: next point is "status of binding"
… we support GitHub issues only for starting the process
… initial, current, deprecated are the possible status values

Ege: versioning is also important
… I think we should not allow updating binding
… you need to create a new version
… do we allow 2 versions at the same time?

McCool: compatible versions is the key here
… major vs minor version

Ege: example: change to CoAP binding
… changes URL
… table should contain status information

Cristiano: "deprecated" sounds to strong

Kaz: Who/How to make the decision that something gets deprecated

Ege: Let's get back to the right name
… instead of deprecated?
… old, out-dated?

Cristiano: previous ?

Ege: ownership is the custodian
… reviewer needs to be an expert

Ege: requirements for binding
… technical requirements
… must map one WoT operation
… we need objective mechanisms for checking the process
… we also have call for implementation
… we should mandate the template .. the content should be fine
… can use W3C spec writing tools

Jan: What if binding is rejected ? Do we need a status for that?

Ege: No, in the beginning it is just an issue ...

Cristiano: Since we don't require a template.. it could be part of a given protocol ..

Ege: Yes, I think so

Cristiano: PDF or link?

Ege: Link is enough

<McCool> (time check...)

Kaz: Wonder about final mechanism?
… relation between GitHub issue and document

Ege: result of issue in form of a PR goes into the actual document

Kaz: Will check internally about a better mechanism. So let's clarify all our questions about our expected mechanism, and I'll talk with Philippe on Monday :)

Sebastian: Do we link already in provisional state ?

Ege: yes

<McCool> (final step should be a "permanent" record, e.g. a publication)

Ege: next point we discuss from state initial to current
… open question ... should have some checks to evaluate

Sebastian: Would be happy to be the first candidate from OPC UA side

Ege: thanks!

Use cases and Requirements

Mizushima: We defined a requirement document template
… McCool is responsible on this topic

McCool: we have an use cases document with 15 use cases but it was very hard to do follow ups
… and connect use cases to actual feature
… we want a more structured way of handle requirements
… when we are working on a feature we want connect it to one on more use cases.
… the connect happens with intermediate requirements.
… we want to link feature to text in the specification (we don't know the life time of issues)
… in a wip state we can use issues
… the format of the Use case and requirements document is based on the concept of user stories
… we want to have maintain a one direction link from feature to requirements
… since HTML does not support bi-directional links
… we should keep it simple and maintain what is easier.
… I'm reporting the definition of a requirement
… in summary a requirement is a triple of questions: Who What Why
… we worked on a template
… it is a YAML template for github issues

<kaz> wot-usecases Issue 308 - Create YAML Template for User Stories Issue

McCool: the use case and requirements will be publish as a W3C note
… but the work will be done in issues which is easier
… we created a test case to verify this approach

<EgeKorkan> also see w3c/wot-thing-description#2059

McCool: we can have multiple user stories for the same feature
… we used intial connection as a test case
… and we added it in the use case and requirements document

<kaz> UCR ED - 5.1 User Stories

Cristiano: I like the approach but sometimes is hard to answer

<Zakim> dezell, you wanted to ask about 1) order of creation and 2) provenance of purpose 3) proper level

Cristiano: I'd suggest to add a link to a document with some guidance

McCool: yes, I'm working on this

David: I was wondering was come first
… where the process start?
… the purpose is excellent

McCool: we have a list of use cases but no connection between them
… we are using the user stories to connect them
… for the future we want create all the user stories for all the new features
… I think we will also create user stories also for past features
… we can have a flexible process for use cases and user stories

Kaz: great discussion and good direction. We need to clarify the procedure and process

McCool: to be clear the task force is only maintain the Use case and Requirements document.
… we are not going to create User stories that's the job of other taskforce

Kaz: collaboration with other task forces would be nice

McCool: we want to capture the connection between use cases and features
… the taskforce is resposible of this connection
… the Use case and requirements document is really meant for non-technical people (possibly managers)

Sebastian: I want to ask about speed
… now we have the dependency between the Use case requirements and the other specifications
… it is ok if we work parallel ?

McCool: yes we are following a parallel process rather than a waterfall (more agile)

McCool: it is not a blocker
… if you want to do a feature please create a user stories, but go ahead implementing it

Daniel: keeping the connection between use cases and feature is nice, but sometimes a new feature has implications on other documents
… to we want to eventually include it?

McCool: I didn't include the stakeholders in the template
… but I might because it's going be useful

Kaz: let's discuss these topics in the chair's call :)

Mizushima: there are few participants in the call, please join

Sebastian: need to clarify when and how to organize the upcoming use cases calls.

Liaisons I

Sebastian: we will start from ECHONET

ECHONET

<kaz> ECHONET's slides

Matsuda: I'd make a short introduction about the ECHONET consortium

Matsuda: we work on devices and work on a lite web API
… LITE WEB API is the focus of today presentation
… we have a Web API guideline document where we explain how a server is exposing features and operations of devices
… the api have different functions
… the interaction model is equal to WoT: property action event
… you can read and write a property and you can invoke an action to control a device
… we have events but not for the device part currently
… we have partially support fo discovery
… a client can get a list of devices using a query parameter or get the description using a GET
… GET returns a proprietary description
… client can execute bulk operations
… in ECHONET lite there is the concept of device group
… and historical data
… a client cannot request the recording of historical data
… but it can query already stored timeseries
… you can get history of multiple devices thanks to the groupHistories object

**showing an example of device descriptions**

Matsuda: the description is similar to WoT TD
… we don't support protocol bindings we are just using the HTTP binding
… descriptions are JSON-LD but JSON
… and also there is no scripting api runtime
… and there are no guidelines for discovery in ECHONET specification

Ege: the differences are not that big
… it should be possible to convert your descriptions to TD
… what if you allow to get a Device description in a TD format using a query parameter?
… I see no blockers to move to a TD

Kaz: they already provided a TD for plugfest

Ege: yes I would like to see this in their products or specification

<Zakim> EgeKorkan, you wanted to ask if we can add query to ask for real TD instead of the echonet lite web api device description

Matsuda: some vendors already adopted our device description for their system
… it would be difficult to change to a TD for them
… the consortium does not have plan to add the TD format

Ege: my question is not instead
… but an addition

<McCool> (could also be a translation service providing the TD by automatically translating the Device Descriptions)

Sebastian: it was 5 or 6 ago when the ECHONET API was born but the TD was not stable
… maybe in the future (version 2.0 of ECHONET) we will see a TD

Cristiano: I noticed the query parameters in the list device descriptions
… we should extract requirements for the Discovery spec

McCool: we need a long term allignment strategy and investigate future integration.

Conexxus

David: we are in mainly in latin America north America and Europe, we have some presence in Philippine and japan.
… one problem that we have is that customers understand the requirements when it is already late and we need to be fast
… we have 150 members
… most of our members are small
… and they can't afford a whole IT team
… primary purpose is to reduce technical debt
… certification and standardization is one mean to achieve that
… we write specifications and we are divided in different committees of which the Device integration is the most interesting for WoT.
… we should start talking about OCPP WoT wrapper

Sebastian: Ege and I worked on this

Erich: I contributed to an opensource version

David: for the future it would interesting to integrate WoT in Camera AI and Car wash.

<McCool> (loss detection, people counting, traffic...)

Erich: is driving off a problem in US?

David: not really they have to pay ahead of time

Josh: in the convenience store practices changes a lot
… changing labels is a challenge in this scenario
… a lot of people are moving to smaller digital signage
… they add a product QR code

McCool: ev charging is opportunity to acquire customers
… because of the waiting time

Josh: stores are getting smarter and smarter
… there is a lot data to work with
… that's why Conexxus has a dedicated commitee

McCool: cameras are just mega sensors: in combination with AI, they can replace or emulate things like presence detection, door sensors, traffic counters, etc.
… they can recognize a lot of different things

Josh: the industry is very diverse and they sell a lot of different stuff

Sebastian: definitely interesting use case.

BACnet

Salvatore: We should address questions from the WG

Sebastian: that's why I invited Klaus and Ganesh here
… we developed a BACnet binding

Salvatore: I saw there were some updates

Klaus: BACnet is industry standard for connecting devices in buildings
… the large part of this specification is to map BACnet devices to WoT

** showing an example**
… do not confuse BACnet operations with TD operations
… in the form we do the ASN1 encoding mapping
… we defined the URI scheme
… we made some adjustment to make it work with the TD specification
… we also defined vocabulary terms to map ASN.1 and JSONSchema
… the number of the terms is small
… but covers a lot of use cases

<kaz> Web of Things (WoT) BACnet Binding Template

Salvatore: yes maybe the 80% of use cases

Klaus: to conclude in some cases in bacnet we have the concept of Alarms
… a sort of event state machine
… this mechanism could be reused in other protocol bindings

Salvatore: in the beginning the idea was integrate one single device in WoT
… but 90% of the time we have a network of devices
… they work together in an application
… now knowing this
… I'm wondering why the TD represent just a single device
… would be interesting to see the system in this point of view
… how to integrate a BACnet network
… what should we say to the designer to be ready for wot integration?
… we are very specific
… now, but we should work on the application level
… I like the example brought by Ganesh in the Plugfest of the thermostat

Ganesh: I see it there are existing semantics that are model in the BACnet itself (like the BackLoopController)
… there is also Structured View in BACnet

Klaus: web of things does not prescribe what is your thing
… but it is up to the designer to choose

Erich: I noticed that UDP multicast does not work well in containers
… it would be good to have the ip of the BACnet device in the TD

Ganesh: BBMD (BACnet Broadcast Management Device) could be used to solve the UDP multicast

Erich: ok but that would be an additional thing that the customer would deploy

Salvatore: BBMD you usually get it in a BACnet router

<Zakim> dape, you wanted to usesService vs op readProperty. Is there a 1 to 1 relation? Do we need both?

Daniel: usesServices and ad TD operations seems one to one
… but it is not motivated.

Cristiano: I second Klaus point on how WoT can be used to combine different TD

Kaz: how should we proceed with the discussion?

Sebastian: we should set up a dedicated meeting
… I'd like to continue the development of the binding inside the BACnet side

<kaz> [ lunch break for 45 mins ]

Liaison II

OPC UA

Sebastian: Erich and I are the co-chairs of the OPC UA Binding for WoT WG
… we want that any opc ua server provides a TD, which describes the WoT standards
… the binding will follow the WoT guidelines

[ Security ]

Sebastian: the opc ua servers can give you options on how the security will be established

Sebastian: (shows an OPCUA Client and connects to the plugfest Siemens S7)
… a pop up shows the different security options
… here all options are available
… we can use the auto scheme in the TD
… but you can skip the handshake by doing the communication directly
… for that we need to define opc ua schemes

McCool: We will probably restructure the security schemes. Basic will not be available in protocols other than http

<McCool> (there will however be a subset of schemes available to all schemes, e.g. auto)

Daniel: we will externalize the security schemes though

McCool: yes indeed.
… opc specific schemes should go in the opc ua binding

Kaz: will the security be handled by the registry as well?

McCool: some will apply to all protocols, we need to discuss it further

[ Forms Metadata ]

<McCool> (but there will be some "generic" schemes that should stay in the TD spec, including "auto", but also "nosec" and "combo", for example)

Sebastian: the nodes in a server are like a tree
… knowing that node id is enough to identify the resource

<McCool> (re readproperty and writeproperty - the readOnly and writeOnly options still bug me. should be "readable" and "writeable"...)

Sebastian: that seems to be it
… we hope to finish it by the beginning of next year
… also the node-wot implementation worked almost out of the box
… all WoT WG members are welcome to join

Jan: how does the href look like

Erich: will href contain the node id?

Sebastian: Yes, to indicate where the node is coming from
… the server can change the nodeid though. So you need guarantee it
… that is why we want to put the whole namespace

Jan: but the uri will not be valid with ";"

Daniel: you can use another notation

<McCool> (would be good to have a consistent policy about whether hrefs are always complete URLs or must be "constructed" with other information in the TD. IMO always having "complete" URLS (even if we have to use URL-encoding for special characters) would be better)

Ege: what about the data schema?

Sebastian: it is a work item to specify ua:type in the forms
… we need further specify it in the forms

Erich: types have node ids as well

Ege: anything we cannot describe in JSON Schema

Erich: No. we should be good

Sebastian: but that is all

[ UA Connectivity Companion Spec ]

Erich: We have this repo that tracks the feature requests

<kaz> UA Edge Translator repo

<kaz> Issue 37 - Asset Condition Monitoring

Erich: we want to enable asset condition monitoring
… like whether the device is online, if the firmware is updated, tags that could not be found during onboarding
… we are making it more enterprise-ready
… also listing available supported bindings

<kaz> Issue 35 - Add new variable node called "SupportedWoTBindings"

Erich: now another feature is discovering assets in the network and automatically generating the TD

Ege: how is TD generated?

Erich: it is protocol specific. Some protocols have that feature

Ege: I see. Like ECHONET device description transformed to TD on demand

Daniel: what about updating?

Erich: It is complicated to implement that. You have state modeling etc.
… we want to keep it simple so that it is easy to implement. What we are adding are convenience features

McCool: it is similar to TDD of the discovery spec

Erich: also a request came to a diagnostics interface

<kaz> Issue 33 - Add diagnostic interface to connectivity software

<McCool> (we should see what we can do to align on behavioral aspects to minimize the learning curve, e.g. updates, what to do if you upload something with the same id, etc. Updating the TDD spec at this point is possible but would require a (longish) W3C REC cycle.)

<kaz> Issue 32 - Add GetConfiguration/SetConfiguration methods

Erich: another one is adding interface for adding license, enabling drivers, security settings download
… so auto security is very good

<kaz> Issue 30 - Define how OPC UA type information is specified in WoT TDs

Erich: A nodeid for a type points to a companion spec. There you will see that it is a struct with L1, L2, L3 for each voltage

<kaz> Issue 6 - IEC 61850 southbound interface

<McCool> (OSS evangelist "if you'd like that feature, please volunteer to do it" :)

Coordination with External Groups

Cloud-Edge-Client Coordination CG

<kaz> Cloud-Edge-Client Coordination CG page

McCool: we have intel, china telecom, alibaba and more
… it is about finding where to offload different services to edge

<McCool> https://www.w3.org/community/cloud-edge-client/2024/

McCool: I will report when there is something relevant, we are very new

<McCool> https://www.w3.org/TR/edge-cloud-reqs/#iot-workloads

Ege: We found that robot inputs cannot be checked via json schema etc. You need simulation

McCool: We have a similar thing for mobile robots. Both are forms of "movement planning" which have similar requirements for real-time data input and analysis, the latter of which can be computationally expensive. For mobile robots though you also have a battery limitation and this motivates using remote computation

Kaz: The UCR document was generated by the Web&Networks IG, so I'm wondering what the relationship would be between this new CG and the original Web and Networks IG.

McCool: that group focuses on reliability of networks etc.
… so no real overlaps so far

Smart Cities IG

<kaz> Smart Cities IG Charter

<kaz> TPAC Breakout minutes

<kaz> Doodle poll to identify the slot for the group's monthly call

<kaz> Same information on Doodle poll forwarded to the WoT lists

Kaz: the group was launched in September
… now we are looking for slots for regular calls

Kaz: The regular call is expected as a monthly call. The group should confirm the basic direction based on the Charter first, and then start to invite related SDOs to discuss existing standards, use cases and best practices.

WoT CG

<kaz> WoT CG page

Ege: summarize overall goals: already created 10 years ago, become active agian 2 years ago
… old people left, but also new people joined again, so members have been refreshed
… support community in various ways. E.g. host discord server, lots happening there, critical mass of people there. Not just Ege and Christiano answering, but also other experts replying
… discord started in gaming, but is becoming more popular for other things now
… there are also community groups for other topics, e.g. Node-Red, Home Assistant. Convenient way to get information
… different topics in WoT for more specific discussion
… WoT CG is also giving people a way to present there WoT implementations. Presentations are recorded and published. To proof this is really adopted

Cristiano: during plugfest two people showed interest to present their work in the WoT CG call

Ege: no decision taking on discord, because its not static and disappears over time
… announcements on social media and discord
… WoT CG is also presenting tutorials on youtube, has What is WoT website on github

Sebastian: is there some statistics for the viewing of the pages?

Ege: could maybe be implemented by script
… small group for home assistant inside the WoT CG formed on github/wot-cg

<kaz> WoT CG's GitHub repository

McCool: Home Assistant is very popular, therefore could be worth returing do this

Ege: Summary video of meetups is now online, which shows meetups, but also how companies use it

Sebastian: Big compliments to Ege, this is important work
… we are still not good with simple google search, especially for products. This needs improovement

McCool: CG has less constrains and is therefore more free, can also find out more about users

Ege: more random people can join like this

<EgeKorkan> https://discord.gg/RJNYJsEgnb is the discord :)

Cristiano: encourage to all people to share links to CG Discord to reach 5000 people there, such that it gets elevated status

Sebastian: Problem: WoT is not an outside used thing, but rather a internal usage and therefore not that publicly seen. E.g. Altair IoT Studio uses it but not advertising it

Its not highlighted, but only used

McCool: incentivize people to tell when they use WoT

Salvatore: BACnet is a standard produced by companies, WoT is developing standard, but not that many people making money with it. People who make money will advertise more

Daniel: beginning had call for implementation. People where pinging for advertising. Maybe have some WoT implementing logo?

Salvatore: in companies there are dedicated people for this

Ege: WoT Adopters page is about to get started, still not public yet, also with categories. Issue: Getting logos and approval for that
… Eclipse has a process to submit logo, this makes it safe for the Group

McCool: is this adoptable to WoT?

Ege: would like to find out. In Eclipse to become member, you have to give the rights to show Logo. Sometimes makes it complicated to join

Sebastian: Use the logo belt slider also, but is hard to grab this in slides
… maybe as gif

McCool: the legal process is probably more complicated

Ege: Yes, the technical part is very straight forward.

Cristiano: The companies who use Eclipse Thingweb are just a subset of WoT Adopters

Liaison III

ETSI ISG CIM for NGSI-LD

<kaz> ETSI ISG CIM

<kaz> NGSI-LD API

McCool: is for special data in smart cities, regular meetings for 6 months, this is not regular meeting. Currently: What are deliverables?
… what do we want to do to onboard them with WoT. Is it subprotocol, maybe platform binding, maybe profile
… OPCUA has tooling to convert ontologies to WoT
… maybe this tooling can also be used here
… Wikis and repo has been created, you can join meetings if you are member. Open to all members to join

<kaz> WoT NGSI-LD wiki

<kaz> wot-ngsi-ld repo

<kaz> initial liaison scope document (to be updated)

Ege: Binding Profile, makes sense, but also mirror to Endpoint to allow them to communicate with more devices

McCool: two ways, one, exposing TDs, but also allowing their things to consume TDs
… will talk to OPCUA
… is different to OPCUA sind it has no protocol

Ege: What is their interest?

McCool: Have been very interest even though they have not joined now
… volunteers are needed to work on bindings or according documents
… could also be relevant for smart cities

Kaz: clarify existing resources between their and our side based on the initial liaison scope document

McCool: PR can be commented on, exact variables have not been clarified, yet. Should be done by end of year, then start with more next year

<kaz> W3C Calendar for the WoT and NGSI-LD Liaison call

Kaz: call is biweekly on monday

McCool: not many meetings left this year
… schedules will be discussed in wrap up

Wrap-up

Sebastian: thanks for a fantastic week, with a smiling and a crying eye, a heavy heart

McCool: all emojies at once
… no main call next week?

Sebastian: WoT holiday next week, no calls next week

McCool: Will send email, then only one more week to be able to attend
… try to wrap up this year

Sebastian: sees no objections against canceling events next weeks
… take aways one: Do this more often, have more regular physical meetings, they are more productive

McCool: Having a consistent location helps to build network more reliable, but also keep geographic. maybe have like two main places

Sebastian: not much needed, one big conference room, network
… before or after tpec

Kaz: in november

McCool: maybe too late? better in june or july

Sebastian: invitation from university of vienna. They are organizing IoT conference anyways. Dates need tbc, if this is possible

McCool: having it collocated with conference would be beneficial

Sebastian: some people still have travel restrictions, hopefully gets better

David: meet three days before tpec?

Sebastian: maybe to late, earlier would be nice, needs to be further discussed, but options are available

McCool: should be on agenda for main call

Ege: before covid: trying to do different continents, maybe in the US, having a rotation

McCool: maybe the year after next year in us

Sebastian: cohosting between companies is also be possible

McCool: how to boost us contributions
… cohost of intel and microsoft might be a good opportunity

<kaz> [adjourned]