vCon
charter-ietf-vcon-01

[Ballot comment]
Does vCon stand for anything? If so, it would be kind of nice to mention that somewhere. If not, respect for not giving in to the pressure to backronym it, but it might be nice to mention that, too.

One example of a working group whose name isn't an acronym is babel, in RTG. The full name of the working group in datatracker is "babel routing protocol", which while not super descriptive, is at least better than having it just be "babel". For the present WG, right now we have "vcon ... vCon" which is not very helpful.

[Ballot block]
I would like to briefly discuss if it is possible to include any notion of user consent in the authentication methods here: e.g. for a recorded/transcribed conversation, is it possible to verifiably attest that the parties consented to this action, when this is required by policy or by law?

[Ballot comment]
# Internet AD comments for charter-ietf-vcon-00-03
CC @ekline

* comment syntax:
  - https://github.com/mnot/ietf-comments/blob/main/format.md

## Nits

### "Out of Scope"

* "It is expected that JOSE or other..."

  This is not really a bullet point under "out of scope".  Suggest:
  de-bullet, de-indent, and clarify "provides sufficient security context"
  (or whatever reads best).

Added charter milestone "Submit draft containing recommendations or analysis of undefined  data containers and media types for components of conversation data to the IESG (Informational)", due June 2024

Added charter milestone "Adopt a draft containing recommendations or analysis of undefined  data containers and media types for components of conversation data (Informational)", due December 2023

[Ballot comment]
** Stepping back from the details of the charter text, this work appears to be trying to define an object security model for a JSON data model for conversational data.  This is my first exposure to the vCon and I don’t know if this was discussed prior.  Please let me know if this has been adjudicated already.  As a starting point for this work, has JOSE’s JWE (RFC7516) been considered?  The JOSE ecosystem provides a rich sent of container formats in JSON and associated code points/identifiers for algorithms.  I don’t mean to invent a solution, but wondering if the use cases or desired security properties preclude the definition of this domain-specific (conversational data) JSON data model that can then be secured with an already standardized JOSE security containers?  I’m trying to ensure that snippet of IETF technology aren’t reinvented unless it is necessary.

** I concur with Lars that the use cases should be pruned from the charter text.

** Paragraph 2.  Opposing forces are being presented, but I don’t understand why “privacy of personal data” necessarily conflicts with “integrating data with multiple sources” or “transitioning from one provider to the next”.

** Paragraph 2.  Per “There are also three open source systems implementing vCon”, what is this text meant to convey?  Are there already draft specification for vCon that this WG will adopt? Or, is this “vCon” in the sense of open source solution generically in the space of conversational data management?

** There are a few places where security related things are said:
(a) “The work group is to define a JSON-based container for conversational data, along with mechanisms to protect the integrity and privacy of data in the container.

(b) “Define/specify a mechanism for proving integrity of the conversation data”

(c) “Define/specify a mechanism for encrypting of the objects enclosed in the vCon conversation data container to provide confidentiality of the data independent of transport such that some parts of the vCon may be disclosed to different parties”

-- “privacy” is mentioned in (a) and “encrypting”/”confidentiality” is mentioned in (b).  I recommend being precise on the security property, is it “confidentiality” that is desired?

-- just checking, this scope is really is only “integrity”, that is “no one modified the bits”.  There is no interest in authenticity, that is “the bits came from who I expected them to come from”.

** Per the scope paragraph saying:

* Data minimization should be considered for each of the use case

What does this mean in terms of deliverables? Or properties of the container?

** Per out-of-scope paragraph saying:

* The encryption keying.

Can this be clarified?  Is this saying key management is out of scope?  MTI algorithms?

** In either the milestone or the scope paragraphs describe the status (Proposed Standard, Informational, etc) of each planned document.

[Ballot comment]
I share Lars' concern about a very long charter.

The mention of FTP could possible be replaced as it should not really be used anymore.

Please provide intended status for all work items: most of them are already "specify" (which I read as "standards track"), but let's specify the use cases as informational, ... OTOH, the use cases do not appear in the milestones, does it mean that they are not intended to be published as RFC ?

TL;DR: too long on the context/positioning, too short on the deliverables and actual work to be done by the WG.

[Ballot block]
# GEN AD review of charter-ietf-vcon-00-02

CC @larseggert

## Discuss

### Paragraph 4

Use Case 1: Contact Center Data Exchange

Including four use cases in the charter makes it extremely lengthy. If
aspects of these use cases influence the charter scope, state those
aspects and their impact on the scope explicitly. Move description of
use cases to an I-D to be done by the WG, if they are considered
important.

[Ballot comment]
## Comments

### "CRM", paragraph 9
```
  The scope of the VCON working group is:
```
This seems redundant/overlapping with the third paragraph above
("The work group is to define...") Consolidate in one place.

### "CRM", paragraph 13
```
  * Data minimization should be considered for each of the use case
```
This isn't really about the scope, it's requirement for use cases.

### "CRM", paragraph 21
```
  Milestones
```
Add expected RFC levels.

## Nits

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

### Typos

#### Paragraph 4
```
- The work group is to define a JSON-based container for conversational data,
+ The working group is to define a JSON-based container for conversational data,
+        +++
```

### Grammar/style

#### Paragraph 14
```
tain the entire conversation or omni channel where the conversation takes pla
                                ^^^^^^^^^^^^
```
This word is normally spelled as one.

#### Paragraph 17
```
general management. The customer they they interact with may be internal to
                                  ^^^^^^^^^
```
Possible typo: you repeated a word.

#### Paragraph 19
```
s * Feed the conversation data to a SAAS provider accepting a standard conver
                                    ^^^^
```
The recommended spelling for the acronym for "Software/Platform as a Service"
is "SaaS".

#### Paragraph 19
```
services such as: transcription, note taking, annotations such as action item
                                ^^^^^^^^^^^
```
The noun or adjective "note-taking" is normally spelled with a hyphen.

#### "CRM", paragraph 3
```
of the captured conversation and meta data may be the most critical feature
                                  ^^^^^^^^^
```
Did you mean "metadata"?

#### "CRM", paragraph 11
```
tional data including: call style meta data, recordings, data exchanged or pr
                                  ^^^^^^^^^
```
Did you mean "metadata"?

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues. Review generated by the [`ietf-reviewtool`][IRT].

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments
[IRT]: https://github.com/larseggert/ietf-reviewtool