Meeting minutes
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://
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/
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://
McCool: I will report when there is something relevant, we are very new
<McCool> https://
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://
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]