Skip to main content

vCon
charter-ietf-vcon-01

Yes

(Murray Kucherawy)

No Objection

Jim Guichard
(Andrew Alston)
(Erik Kline)
(Lars Eggert)
(Zaheduzzaman Sarker)

Note: This ballot was opened for revision 00-02 and is now closed.

Ballot question: "Is this charter ready for external review?"

Éric Vyncke
No Objection
Comment (2023-10-03 for -00-02) Sent
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.
Jim Guichard
No Objection
Roman Danyliw
No Objection
Comment (2023-10-04 for -00-02) Sent
** 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.
Murray Kucherawy Former IESG member
Yes
Yes (for -00-02) Not sent

                            
Andrew Alston Former IESG member
No Objection
No Objection (for -00-02) Not sent

                            
Erik Kline Former IESG member
No Objection
No Objection (for -00-02) Not sent

                            
John Scudder Former IESG member
No Objection
No Objection (2023-10-03 for -00-02) Sent
I agree with Lars. ISTM everything could be elided after the first paragraph, up until the “in scope” heading.
Lars Eggert Former IESG member
(was Block) No Objection
No Objection (2023-10-24 for -00-03) Sent for earlier

                            
Paul Wouters Former IESG member
No Objection
No Objection (2023-10-03 for -00-02) Not sent
I agree with Lars that the charter could be shorter.
Zaheduzzaman Sarker Former IESG member
No Objection
No Objection (for -00-02) Not sent