Meeting minutes
Organization
Sebastian: reviews agenda at https://
… going to talk about some policy topics first, including resolution on charter extension
… want to clarify some assumptions about priorities
… and relationships to other groups
… short discussion of liaisons, more tomorrow
… then some PRs for some deliverables: security, discovery, and profiles
Sebastian: any other agenda items?
… seems not the case, let's begin
Generic Fixes
<sebastian> PR 1058 - WG 2023 Charter - generic updates
McCool: (goes through the changes)
… CSS issue to be fixed later
Kaz: have you included previous discussion in our other charters?
McCool: no, not really, this PR is just about cleaning up the latest template
Sebastian: any objections to merge?
Sebastian: ok, let's merge
Policy and Workflow
Extension
Sebastian: we need at least 4mo, should we ask for 6mo?
… kaz has been talking to W3M and they suggested we be on the safe side and ask for 6mo
… if we need another extension it will be very difficult
Sebastian: statement for Siemen's view that we have a concern that the 6mos that don't want to delay work on TD 2.0 and OPC UA
… don't want to start new charter after 6mo; if we support this extension, we still want to start work on TD 2.0 and OPC UA sooner
… concerned about delay due to summer break
… so 6mo extension is only acceptable if we start earlier
… so would still plan to start the new charter on 1 June
… also, TD 2.0 is still in our current charter, so we can still work on it
Lagally: thanks for proposal, support it, and don't want to lose time on TD 2.0/DTDL/Digital Twins or OPC UA
… assume we have to follow formal process; how do we want to handle requirements; since use cases are IG, it is already chartered, can start right away
… in summary, support asking for a 6mo extension, does not block requirements analysis in particular
Kaz: I support, also originally suggested; 6mo is max period, if we can finish new charter earlier, then we can submit and start it earlier
McCool: support asking for 6mo, as long as we stick to the current proposed schedule, based on 4mo plan
Sebastian: note for OPC UA we also need to move forward with some formal arrangements, will have to work on that in parallel, want to mention in the new charter
… would like to have this settled and ready
Kaz: regarding OPC UA liaison, if want formal joint deliverables, will have to have in charter, and in the MOU
… both of which will have to be reviewed by AC
Lagally: when talk about MOU, suggest back activity with some requirements that emphasize business value
… what is added value and benefit, suitable for upper management
… this is an IG activity that we could work on
proposal: Request a 6mo extension for our current WoT WG charter, while working to a 4mo plan and an intention to start the new charter as soon as possible, ideally on or before June 1
proposal: Request a 6mo extension for our current WoT WG charter, while working to a 4mo plan and an intention to start the new charter as soon as possible, ideally on or before June 1, while beginning work on TD 2.0 and liaison organization within the current charter.
<sebastian> +1
Lagally: for TD 2.0 requirements, we don't have a document?
Sebastian: be do have a set of issues labelled TD 2.0; we need to derive a list of requirement
Lagally: suggest we create a brief requirements document for TD 2.0 in the use cases TF
Sebastian: agree, where we should start
<Ege> https://
<Ege> https://
Ege: for next charter discussion, also is a collection (see link above) in deliverable proposals, and also a draft PR for the charter
proposal: Request a 6mo extension for our current WoT WG charter, while working to a 4mo plan and an intention to start the new charter as soon as possible, ideally on or before June 1, while beginning work on TD 2.0 and liaison organization within the current charter.
<sebastian> +1
<cris> +1
<mlagally> +1
RESOLUTION: Request a 6mo extension for our current WoT WG charter, while working to a 4mo plan and an intention to start the new charter as soon as possible, ideally on or before June 1, while beginning work on TD 2.0 and liaison organization within the current charter.
License
<kaz> PR 1062 - WG 2023 Charter - License
McCool: propose using the W3C Software and Document license, as in our current charter
Sebastian: (resolves conflict)
… any objections?
… none, merging
Clarify Policies
McCool: is previous discussion, propose we have a resolution to clarify mission statement
… essentially, to prioritize industrial adoption
Kaz: given industry adoption is important for WoT 2.0, we need to clarify how to deal with contributions from the external SDOs and groups. We don't need actual text today, but agreement makes sense
Ege: agree, but should be aware it is hard to measure impact, etc.
… still hard to decide among features still
Sebastian: this is more about where we want to spend time
… better to spend time with industrial SDOs than working with students, for example
… question of prioritization
probably: The WoT WG will prioritize work that leads to industrial adoption of WoT standards, including liaisons with other industrial SDOs and meeting the stated requirements of potential commercial adopters.
probably: The WoT WG will prioritize work that leads to commercial adoption of WoT standards, including liaisons with other SDOs and meeting the stated requirements of potential commercial adopters.
<cris> +1
<kaz> ml: would clearly state business interest and participation
proposal: The WoT WG will prioritize work that leads to commercial adoption of WoT standards, including liaisons with other SDOs and meeting the stated requirements of potential commercial adopters.
Lagally: how do we decide?
McCool: mission statement, not execution plan
Kaz: I agree with Lagally, on Monday, I suggested we think about (1) the basic policy (like McCool is proposing) first and then (2) concrete procedure on how to handle contributions from the outside. For today, we can start with basic policy
McCool: suggest we do something basic now, move on with agenda
Cristiano: was thinking about OSS solution
McCool: that was my intention with the "leads to" part
proposal: The WoT WG will prioritize work that leads to commercial adoption of WoT standards, including liaisons with other SDOs and meeting the stated requirements of potential commercial adopters.
<sebastian> +1
<cris> +1
RESOLUTION: The WoT WG will prioritize work that leads to commercial adoption of WoT standards, including liaisons with other SDOs and meeting the stated requirements of potential commercial adopters.
<mlagally> +1
Sebastian: will copy resolution to issue 206 in use cases and close it
Liaisons
Sebastian: not only other SDOs, but also other W3C groups, and WoT CGs
McCool: we probably need concrete PRs on CG relationship, another for W3C groups, and liaisons with external SDOs we can discuss tomorrow
<kaz> kaz: agree. For today again, we should start with confirming the need to think about related groups including CGs as well as external SDOs.
Ege: do we need a discussion for this?
McCool: just need a few concrete sentences for the charter
Decision Policy
<kaz> PR 1061 - WG 2023 Charter - Decision Policy
<kaz> mm: edits to the latest template as an initial starting point
McCool: this is just resolving the todos in the template, but there are questions to resolve; CfC for resolutions,and asynch merging of PRs
… this PR does not address the last two points
Sebastian: agree with merging this PR, but in general would like to rely more on github features
… if there is clear consensus on a PR, can merge
… email is not my preference for CfC though
… need another resolution later on
Kaz: perhaps should create some issues for these topics for further improvement
McCool: let's create issues, but suggest charter can just have a very general statement, e.g. "Use github features to resolve issues when possible in an asynchronous manner"
Sebastian: (merged PR 1061)
McCool: suggest ben adds a PR as needed
Ben: problem is not actually, but what's in the charter, says it should be asynch
… but not clear we need resolutions to merge PRs
Sebastian: I think what is missing is what it means by consensus
Ben: what it actually says is resolution is proposed, then 10 days for objection
… if we were following this process, we would be doing things differently
Lagally: what I think would help is a better review process to gather input and have evidence of consensus
… so instead we have been using group discussions in place of reviews
<Zakim> mlagally, you wanted to react to kaz
Lagally: if there were changes requested, for instance, then there is not consensus
… we need a couple of simple rules, but if we use github features like reviews would help
… but also a problem with people who just complain but don't propose a resolution
<mlagally> * I have to drop off
McCool: charter just needs simple statement of intent, does not need detailed process
Kaz: ok, but do take care to define the exact procedure later
Sebastian: what is next step? Another meeting to define process?
McCool: maybe use the editor's call next week to discuss the proposal already on the table provided by Ben?
Sebastian: Ben, would you be able to participate?
Ben: text already says asynch, but not sure resolutions are needed to merge PRs for specs?
McCool: this is one of the things that needs to be clarified
Sebastian: note that in general we only merge PRs in TF calls
… and part of the proposal is that we can merge PRs even outside TF calls
Ben: have made a proposal, but does the charter need to change, or just how we do things?
McCool: I do think the current text needs some work, the "for example" part, for example.
Sebastian: I do think the policy is a bit strange
Ben: perhaps we can have the discussion asynchronously... can comment on existing issues and PRs
McCool: do we want to revert this PR?
Ben: I think current text is ok, but maybe some revision would be helpful
Ege: this text is not really about PRs, but more organizational decisions, like publications
… in practice, working on specifications is done in TFs using their own policies
… this specific text is not about PRs, we need an additional paragraph somewhere about that
Kaz: tend to agree with Ben, charter doc is basic policy; need to also clarify concrete procedure, but this does not have to go into the charter itself. we should continue to define the detailed procedure but that should go to a separate wiki page or MD file.
Cristiano: agree with current line of thinking; charter text can be high-level; but if defer, need to define timeline; want to do in parallel and have it ready before the new charter starts
… or longer, maybe 6mo?
Ben: PR for proposal has been open for 2 years; never felt the charter needed to be changed, we just need to define and write down our policy
Sebastian: could plan to write down the policy, and could have different policies for different TFs also
McCool: editors call is one place we can discuss, can also do in main call, but only 10m at a time
Sebastian: would be good to have concrete PRs to discuss... Ben
Ben: what is needed?
Sebastian: I think the current text is too vague, needs to say something about PRs
<cris> +1
Ben: Ege is right, this text is for resolutions; don't think we actually need anything in the charter
<Ege> +1
Kaz: this level of description is OK for the charter, more details can be done later
Sebastian: ok, then it is fine for now
Ben: would encourage people to comment on the PR for the resolution
McCool: suggest we comment on it, discuss comments in next main call, and also set June 1 (new charter) to have this decided
Ege: one policy for all TFs?
McCool: let's add that comment to the PR/issue and cover it as part of the discussion
Deliverables
Security
<kaz> PR 1057 - WG 2023 Charter - Security Deliverable
<kaz> PR 1053 - WG 2023 Charter - Security Work Items
McCool: there are 2 PRs, for work items and deliverables
McCool: ready to review and merge the work items (PR 1053)
McCool: the biggest part is about pairing
McCool: suggest merging the work item PR and waiting on the deliverables PR
Ege: like the idea of moving these deliverables to other documents
Ege: it would raise the priority and visibility of security for assertion checking
Cristiano: like the idea of moving security protocols to the binding templates
<McCool> ack +
<Zakim> McCool, you wanted to react to +
<Zakim> McCool, you wanted to react to +
McCool: we need flexibility to define generic schemes that aren't specific to one protocol
… we can add detail to the binding doc.
Cristiano: agree
Kaz: we should think about the relationships between documents, and which topic should be defined by each document
<Mizushima> +1 kaz
Kaz: this would be useful for the charter as well
Sebastian: agree
Sebastian: question about the ontology
McCool: we need to factor the ontology also, so protocol specifics would be moved into bindings
<kaz> I'm OK with merging this PR as a starting point. However, if we want to work
Kaz: if we want to work on security ontology, we need to survey the current SDO work status
… across various SDOs
Ben: are we going to require RDF prefix processing if we include ontologies in the binding?
… maybe a registry would
McCool: we should be able to validate TDs using only JSON tools
… profiles will insist on using particular bindings
McCool: I would like to merge this PR and then build on that
Daniel: agree that we can merge this, but there is more to be done to make it work with plain JSON
McCool: we would need JSON signing in addition to JSON-LD signing
Daniel: also remove the references to RDF
McCool: OK, will up-level it
Sebastian: any objections?
… on merging?
<kaz> please note that our on
Kaz: our ontologies and registries should be compatible with other existing ontologies and registries
McCool: we would need to add that to the charter
Sebastian: do we decide to not have a deliverables document?
McCool: it will be informative
Discovery
McCool: same structure, there is a work item PR and a deliverables PR
McCool: there is an update to support versioning of TDs
McCool: there is an update to thingmodel to deal with linking TDs to TMs, putting TM into the same directory
McCool: adding CoAP directory services for constrained devices
McCool: next one is JSON-path
… we need a simpler way than SPARQL to do queries
McCool: next is filters
… we need some way to reduce the discovery response volume
… 3-4 common use cases like geolocation having spatial filters
… the only thing not discussed is the TM item, and we need another round of discussion with the discovery TF
Ege: regarding versioning, we need both spec version and TD version
McCool: good point, we will add that to the discussion
Sebastian: thinking about collaboration work like OPC-UA, there are also discovery systems in the systems we are describing in WoT
Sebastian: how would we align with external discovery protocols
McCool: there could be a separate service
jan: one addition is security bootstrapping in CoAP using ACE Oauth
McCool: create issues in wot-discovery
Kaz: for SDO coordination, we need to define a basic policy within the Charter and adapt it to specific liaisons
… the detailed process to be described separately, e.g., an MD file later, though.
<McCool> wot-discovery Issue 458 - WG 2023 Charter - Update
(other SDOs have a policy and procedures document that serves as a template for the TFs)
Sebastian: review the deliverables PR
McCool: assuming the new draft will be based on the current specification
McCool: do we need a 2 year or 3 year charter, assuming 2 years will be sufficient
Sebastian: I prefer a 2 year charter to drive progress
McCool: agree, the additional work is not difficult
Kaz: agree with the 2 year charter, also should have a feasible timeline
Ege: this should not try for a dot increment on the spec, it might be better to go for 2.0
… maybe it would be better to define a revision
McCool: the new features don't conflict, so it would be backward compatible
Ege: we would be limiting ourselves to only be able to add backward compatible features
McCool: we could supersede features in the API if we need to
Ege: it could require us to support broken features
McCool: we can discuss in the discovery call also
Kaz: our goal is industry adoption, so we should survey adopters and decide which features are necessary (so we can't make decision which features are necessary now :)
Sebastian: should we merge this now or keep working on it?
Ben: on API versioning, coding the version into the URL is problematic
Sebastian: no objections? merging
Sebastian: this is the last action for today, we are in a good place on the agenda
… tomorrow we will discuss liaisons
… adjourned