Meeting minutes
Agenda
McCool: suggest we add a discussion of how to use the results of the use case analysis
Kaz: probably several policies, including how to transfer, and how to discuss in TF
Lagally: ok, added the agenda
Minutes
<kaz> Jan-10
Lagally: from 10 January 2023
Lagally: any objections to publishing?
… hearing none, let's publish
Contributions
<kaz> PRs
Lagally: have new use case, uc and requirements process, requirements field in template
PR #207 Smart Agriculture - Pest Control
<kaz> PR 207 - Add a new use case of for smart agriculture-pest control
Lagally: is a new person, seems the PR goes directly into the main doc
… submitters are three people from ETRI
McCool: so involves drones, remote sensing
… question if drones are automated, in which case there will be additional edge computing requirements
Lagally: there is analysis in the cloud
McCool: not sure that covers real time control of flight path, though
Kaz: this is related to discussion on policy; how do we extract requirements? How do we identify additional requirements, such as in this case real-time control?
Kaz: we already have section 3 after section 2, wonder if it would make sense to use section 3 as a requirements section
… keep this section, do requirements separately
<Mizushima> +1 kaz
McCool: think we should focus on the use case for now, and decide whether to merge it or ask them to add a few things
… I personally think edge computing is a technical detail that should be added
Lagally: think this use case does really go deep down into implementation, so we can extract the edge computing requirement later
McCool: agree
Lagally: suggest we merge it then, ok except for a minor typo
McCool: agree; also ok with merging directly into the doc
… probably also need to update the acks section with org, etc.
Lagally: I think this is their second contribution, so they might already be there; yes, they are
… well, two of them; will have to add the third one
… how about we ask them to add the person to the acks and fix the typo
Kaz: or we could just merge it and make some quick fixes
PR merged
Requirements
<kaz> requirements-template.md
Lagally: we have a template
McCool: seems missing technical needs
Kaz: basically agree, and think we should describe why we need a specific feature based on concrete use case(s), e.g., precise time synchronization between multiple devices, rather than just referring to the relates use cases.
Ege: we are modifying this document, but I also have a PR updating this document
… is it us who write the requirements, or external submitters?
<kaz> PR 193 - Add new requirement fields for the template
Ege: now we are getting input from people using the use case template, now we are using another?
Lagally: use case is from user perspective, requirements is from a technical perspective and details
Ege: some details we may not be able to extract from use cases if they do not give them
Lagally: I suspect these people may not know all the details of what is needed
… use case is about satisfying user needs
Ege: ok, but that does not provide enough detail for us to act on it
McCool: two things, policy and process
<Ege> +1 to kaz
McCool: first of all, think external contributors to requirements makes sense; already doing for use cases, overall doc is IG doc, is not binding on WG
… second, I think a separate list of requirements is useful, since may have to pull from multiple use cases, and don't want to modify original use cases
Kaz: think we should also ask people to still add requirements to individual use cases as well
Ege: note template also allows "flexible" as an answer if it is not known, e.g. the specific protocol
Lagally: if it is a separate document, ok with duplicating sections; but not fond of copy-paste in general
Kaz: we can add this kind of information later, because protocol requirements and content type requirements would be useful to the Binding Templates spec.
… However, we should start with abstract-level information
McCool: ok if a lot of fields are empty, it's better than overlooking something
Lagally: expect users to write use cases, technical people to write requirements
… and along with that, would like to add a "business need" point to the requirements document
McCool: business is not really a requirement, it's a motivation
… maybe we handle it separately
… although there might be needs for business, e.g. to monetize a service
Ege: not sure this should be in the use case document
… if someone submits a business-motivated case, would expect them to provide detailed requirements
Ege: what can we do with the use case we just discussed, for example?
… what particular protocol is needed?
Lagally: so do we have video formats in the specs?
Kaz: can understand Ege's concern, but we should not just ask people to submit concrete, perfect requirements; but ask them for collaboration and to continue to discuss and clarify them
… how to achieve that goal is the question
… template is fine and useful, but some contributors may have a hard time filling it out
… we should clarify our policy to ask all
McCool: first, think we should merge ege's PR on template
… second, agree with kaz that gathering requirements is a process, need to keep people engaged
… third, business motivations can be used as a filter after requirements are gathered, e.g. we can see what use cases motivated which requirement and who proposed the use cases
Ege: +1 to kaz. we have to extract the requirements and if this is not possible (collaboration problems), the use case is simply not considered
Lagally: ok, regarding the template, suggest put in a branch and make a PR, will ask for comments
McCool: let's do policy discussion in next call
Lagally: ok, in two weeks
<kaz> [adjourned]