<kaz> scribenick: zkis
<kaz> McCool: (goes through his slides on "Summary of proposed technical standards strategy")
McCool: 2 use cases in edge
computing: compute (including AI inference) and IoT
orchestration
... one tech that can be used is Web Workers, to offload work
to a separate browser thread
... the idea is to generalize this offloading to a separate
execution thread on the edge
... that runs the WoT Scripting API as well
... problems are security and persistence
... need a background execution model
... when the user is not on the web page (i.e. web page is not
in focus and on the top)
... we need to discuss the security and privacy related
issues
... new things (possibly new standards, or extensions): management API to
deploy compute units, and discovery
... might involve new WGs
McCool describes the use cases in detail, for compute offload and IoT orchestration
McCool: requirements: access
local network,security requirements, discovery
... the management APIs could be described by TDs
... discovery needs a directory node that could also be a first
contact point for onboarding/configuration
... after authentication and setup, the edge browser app could
offload compute units to edge devices
... propose Web Workers to deploy compute units to edge
devices
Zoltan: need to differentiate between web workers and edge workers
Lagally: this already assumes some
technology choices
... is this just an example, or is it part of the design?
McCool: the intent is to use current
web technologies
... minimize the work that needs to be done in W3C
... there are a couple of tech that we could use or
extend
... like PWAs (progressive web app) and web workers
... not impossible to do containers
Lagally: there are many options on the
edge, such as docker contains, where you would be more
flexible
... the distribution mechanisms using web tech are very (too)
flexible
McCool: we need a concrete set of designs
<kaz> scribenick: kaz
McCool: code exist running on the
network
... could use the other thing by other service
... using some cloud-based discovery service is also fine
... will have discussion with the Web&Networks IG
... Feb. 13th
... would put the information on the WoT wiki
... but will have a preliminary call with the WN Chairs
first
... [Edge apps: definition and requirements]
... question about who would do the offloarding
... use case 1: compute offload
... allow browser-based computing access
... allow small IoT devices access
... small IoT devices might use Zigbee and/or CoAP
... would be useful to include offloading by small
devices
... management service would be useful for small devices as
well
Zoltan: part of binding?
Lagally: specific need for discovery?
McCool: issue we have to realize
is...
... offloading could be a cloud service
... non-trivial changes for workers
... and I'm sure there will be huge size of privacy discussion
there
Kaz: wondering about discovery as
a kind of "google search"
... can actually get something (some device) by searching with
Google or visiting Amazon shopping site
McCool: yeah, DNS people also are interested and that's related to IETF's work
Kaz: yeah, underlying mechanism could vary
McCool: created an issue
McCool: referring to the PING's Threat Model document: https://w3cping.github.io/privacy-threat-model/
Elena: threat model for what?
McCool: someone needs to look into
it
... will read it for discussion next week
... would help us understand their view
... we can use GitHub issue to give comments
McCool: another topic is IETF MUD
McCool: MUD is inverse of TD
... how it could be aligned with TD?
MUD (D)TLS profiles for IoT devices
McCool: make sure the
consistency
... different kind of algorithms
... related to our security model
... have created an issue (153)
... will be at IETF in Vancouver in March
... there will be DNS session and MUD session there
McCool: I like this structure
... main pass and decommissioned
... need to think about a couple of things
... information lifecycle vs device lifecycle
... really separate lifecycle?
... might be redundant to have two separate lifecycle
diagrams
Elena: don't know if we need to have separate diagrams
McCool: two issues
... directory service
Lagally: should have a separate diagram for directory
McCool: at the decommissioned phase,
information should be destroyed
... there is no "coming-back" from decommissioned
... btw, there were some typos to be fixed
Lagally: we need to continue the
discussion during the architecture call
... may need another phase between manufactured and
bootstrapped
McCool: good point
... for device-specific ID
... we have chip manufacturer and IoT manufacturer
... we should wrap up the discussion and continue the
discussion during the architecture call
Kaz: a device which includes multiple sub-systems like automotive should be also considered. right?
McCool: yeah
Kaz: can continue the detailed discussion during the Architecture call on Thursday
[adjourned]