Web Real-Time Communication Use Cases and Requirements
draft-ietf-rtcweb-use-cases-and-requirements-16
Yes
(Richard Barnes)
No Objection
(Adrian Farrel)
(Brian Haberman)
(Jari Arkko)
(Joel Jaeggli)
(Martin Stiemerling)
Abstain
Note: This ballot was opened for revision 14 and is now closed.
Richard Barnes Former IESG member
Yes
Yes
(for -14)
Unknown
Adrian Farrel Former IESG member
No Objection
No Objection
(for -14)
Unknown
Alissa Cooper Former IESG member
(was Discuss)
No Objection
No Objection
(2014-05-14 for -14)
Unknown
Thanks for addressing my DISCUSS. The requirements listed in 3.3.7.2 are incorrect. First, F17 does not derive from the use case described in 3.3.7.1. Second, the text listed for F22 is not the appropriate text. To be consistent with how F22 is used in the rest of the document, it should say: "The browser should be able to take advantage of available capabilities (supplied by network nodes) to prioritize voice, video and data appropriately."
Barry Leiba Former IESG member
No Objection
No Objection
(2014-05-08 for -14)
Unknown
The change log says that this was done in -11: o Removed the "Conventions" section with the key-words and reference to RFC2119. Also changed uppercase MUST's/SHOULD's to lowercase. But some of it was reverted: the "Conventions" section and the 2119 reference re-appeared in -12, and remain there in -14.
Benoît Claise Former IESG member
(was Discuss)
No Objection
No Objection
(2014-05-14 for -15)
Unknown
- References please Assuming that ICE will be used, this means that the service provider would like to be able to provide several STUN and TURN servers (via the app) to the browser; selection of which one(s) to use is part of the ICE processing. - But in addition to this, the users can send and receive files stored in the file system of the device used. 3.3.9.2. Additional Requirements ---------------------------------------------------------------- REQ-ID DESCRIPTION ---------------------------------------------------------------- F35 The browser must be able to send reliable data traffic to a peer browser. ---------------------------------------------------------------- Do you want to say? F35 The browser must be able to send files to a peer browser. Does "data traffic" = file? Also, reliability is implicit, not? - particiapants -> participants - section 3.3.11. Multiparty video communication, 3.3.12, and potentially so other: Any connection with "Use Cases for Telepresence Multistreams", RFC 7205? - Why are the API requirements in an appendix? Because there are not normative? If so, make it clear.
Brian Haberman Former IESG member
No Objection
No Objection
(for -14)
Unknown
Jari Arkko Former IESG member
(was Discuss)
No Objection
No Objection
(for -15)
Unknown
Joel Jaeggli Former IESG member
No Objection
No Objection
(for -14)
Unknown
Kathleen Moriarty Former IESG member
No Objection
No Objection
(2014-05-13 for -14)
Unknown
I support Alissa's discuss and appreciate you addressing her security concerns. In Section 6.2, can you repeat the requirement to prevent wiretapping in this list? Other security requirements are repeated and this one if important in light of the revelation on GHCQ gaining access to Yahoo web chat a couple of months ago.
Martin Stiemerling Former IESG member
No Objection
No Objection
(for -14)
Unknown
Spencer Dawkins Former IESG member
No Objection
No Objection
(2014-05-13 for -14)
Unknown
Thank you for addressing Alissa's DISCUSS, and I agree with the proposed text. I noticed a couple of things other ADs didn't comment on yet: 3.3.12.1. Description Note: the difference regarding local audio processing compared to the "Multiparty video communication" use-case is that other sound objects than the streams must be possible to be included in the ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ spatialization and mixing. "Other sound objects" could for example be a file with the sound of the tank; that file could be stored locally or remotely. This is really rough. Perhaps "other sound objects must be allowed to be included with the audio streams in spatialization and mixing"? In these requirements: ---------------------------------------------------------------- Requirements related to audio processing ---------------------------------------------------------------- REQ-ID DESCRIPTION ---------------------------------------------------------------- F27 The browser must be able to apply spatialization effects when playing audio streams. ---------------------------------------------------------------- F28 The browser must be able to measure the voice activity level in audio streams. ---------------------------------------------------------------- F29 The browser must be able to change the voice activity level in audio streams. ---------------------------------------------------------------- F30 The browser must be able to process and mix sound objects (media that is retrieved from another source than the established media stream(s) with the peer(s) with audio streams. ---------------------------------------------------------------- F27 says "when playing". The other requirements don't. Is it obvious to everyone but me whether F28 and F29 apply to a browser sending audio, a browser receiving audio, or both?
Stephen Farrell Former IESG member
(was Discuss)
No Objection
No Objection
(2015-01-23)
Unknown
Thanks for addressing my discuss points (and sorry it took so long) Didn't check these. - intro: I don't get how the document is planned to be used later, but that's ok. For now however, I'm reading the requirements as if those are the ones that the WG are working to, since I've no other sensible choice really. (And the plan confuses me more if W3C are taking these as real but rtcweb isn't.) - F10: heh, which video codec exactly? :-) - F11: Is 2804 the exactly right reference, maybe 7258 is worth adding (now its published) as that also envisages non-targetted PM whereas 2804 is really only considering targetted wiretap. Or maybe refer to both. - F19: Is acquiring call metadata via TURN considered a breach of F11? If not, then shouldn't that also get a mention somewhere? - F35: the title of 3.3.9 is about files but the requirement is about data, seems like a mismatch - 3.3.10: I've heard this use-case before. It was outlandish then. Not objecting though.
Pete Resnick Former IESG member
Abstain
Abstain
(2014-05-14 for -14)
Unknown
This document is a mishmash of UI requirements, local browser implementation requirements, and protocol requirements, with no distinctions being made among them. Given the IETF's notorious lack of skill in producing good UI work, and a great deal of text over the years indicating that we don't do UI and we don't constrain local implementation choices when they don't affect interoperability, I'm very dubious about the worth of this document. Then the introductions says: This document was developed in an initial phase of the work with rather minor updates at later stages. It has not really served as a tool in deciding features or scope for the WGs efforts so far. It is proposed to be used in a later phase to evaluate the protocols and solutions developed by the WG. So the document was not found to be of use on input to the WG, and it's not clear to me what exactly happens if the evaluation concludes that the protocols and solutions don't meet these requirements at the end. I don't see the point in publishing this document, certainly at this time. Moreover, there are things in this document which strike me as problematic. I suspect things like those said in 3.3.1.1 will end up being (inappropriately) used as a bludgeon later, for no good reason: "Well, the requirements document published by the IETF says that you have to have a self-view during session establishment. You don't have self-view during session establishment. You're non-conformant and therefore will not be allowed in the market." Even mentioning self-view during session establishment in an IETF document gives me the creeps; I can imagine UIs with the feature, and I can imagine them without. Some of the requirements seem awfully suspicious. For example: F13 The browser must encrypt, authenticate and integrity protect media and data on a per-packet basis, and must drop incoming media and data packets that fail the per-packet integrity check. In addition, the browser must support a mechanism for cryptographically binding media and data security keys to the user identity (see R-ID-BINDING in [RFC5479]). Maybe "per-packet encryption" means something magical, but can't we imagine a protocol decision that ends us up with stream-based or body-based encryption that is not "per-packet" that would still be perfectly reasonable? I wonder whether this document is over-constraining. And finally, we have stuff like this: "3.3.10. Hockey Game Viewer" "3.4.2. Fedex Call" Cute, but seriously? Do we really need cultural references like this? I can't support the publication of this document. I won't stand in the way if it has consensus behind it, but I don't see the point.