Web Real-Time Communication Use Cases and Requirements
draft-ietf-rtcweb-use-cases-and-requirements-16
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2015-03-09
|
16 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2015-03-04
|
16 | Richard Barnes | Changed consensus to Yes from Unknown |
2015-03-02
|
16 | (System) | RFC Editor state changed to AUTH48 from RFC-EDITOR |
2015-02-27
|
16 | (System) | RFC Editor state changed to RFC-EDITOR from EDIT |
2015-01-23
|
16 | Cindy Morgan | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2015-01-23
|
16 | (System) | RFC Editor state changed to EDIT |
2015-01-23
|
16 | (System) | Announcement was received by RFC Editor |
2015-01-23
|
16 | (System) | IANA Action state changed to No IC from In Progress |
2015-01-23
|
16 | (System) | IANA Action state changed to In Progress |
2015-01-23
|
16 | Amy Vezza | IESG state changed to Approved-announcement sent from Approved-announcement to be sent |
2015-01-23
|
16 | Amy Vezza | IESG has approved the document |
2015-01-23
|
16 | Amy Vezza | Closed "Approve" ballot |
2015-01-23
|
16 | Amy Vezza | Ballot approval text was generated |
2015-01-23
|
16 | Amy Vezza | Ballot writeup was changed |
2015-01-23
|
16 | Amy Vezza | IESG state changed to Approved-announcement to be sent from IESG Evaluation::AD Followup |
2015-01-23
|
16 | Stephen Farrell | [Ballot comment] Thanks for addressing my discuss points (and sorry it took so long) Didn't check these. - intro: I don't get how the document … [Ballot comment] 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. |
2015-01-23
|
16 | Stephen Farrell | [Ballot Position Update] Position for Stephen Farrell has been changed to No Objection from Discuss |
2015-01-23
|
16 | Richard Barnes | Ballot writeup was changed |
2015-01-23
|
16 | Christer Holmberg | New version available: draft-ietf-rtcweb-use-cases-and-requirements-16.txt |
2014-12-18
|
15 | Stephen Farrell | [Ballot discuss] Discuss updated for -15, a bit more mail to check stuff and then we're likely done. Nice document, thanks. But I have some … [Ballot discuss] Discuss updated for -15, a bit more mail to check stuff and then we're likely done. Nice document, thanks. But I have some issues to check. Nothing huge I'd say. (1) Cleared, WG assured me they would consider LoF/TOFU. (2) F20: Is there not a missing requirement that one ought not be able to easily consume the bandwidth of someone else's TURN server just because you once made a call via that? (3) Cleared. WG assured me it'll be handled in the security draft. (4) 3.3.12.1 - if the sound file can be local and played as a result of gameplay then that implies some form of authorization for access to files on the local filesystem - is that requirement actually being worked? (5) 6.2: why is revocation only "expected" and not a MUST? And why doesn't this section have any 2119 terms? I think privilege revocation has to be a 2119 MUST. (But am open to argument that that MUST ought apply to the API not protocol.) |
2014-12-18
|
15 | Stephen Farrell | Ballot discuss text updated for Stephen Farrell |
2014-12-17
|
15 | Jari Arkko | [Ballot Position Update] Position for Jari Arkko has been changed to No Objection from Discuss |
2014-12-17
|
15 | Benoît Claise | [Ballot Position Update] Position for Benoit Claise has been changed to No Objection from Discuss |
2014-12-17
|
15 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2014-12-17
|
15 | Christer Holmberg | IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed |
2014-12-17
|
15 | Christer Holmberg | New version available: draft-ietf-rtcweb-use-cases-and-requirements-15.txt |
2014-10-21
|
14 | Stephen Farrell | [Ballot discuss] Discuss updated Oct 21. Nice document, thanks. But I have some issues to check. Nothing huge I'd say. (1) Cleared, WG assured me … [Ballot discuss] Discuss updated Oct 21. Nice document, thanks. But I have some issues to check. Nothing huge I'd say. (1) Cleared, WG assured me they would consider LoF/TOFU. (2) F20: Is there not a missing requirement that one ought not be able to easily consume the bandwidth of someone else's TURN server just because you once made a call via that? (3) Cleared. WG assured me it'll be handled in the security draft. (4) 3.3.12.1 - if the sound file can be local and played as a result of gameplay then that implies some form of authorization for access to files on the local filesystem - is that requirement actually being worked? (5) 6.2: why is revocation only "expected" and not a MUST? And why doesn't this section have any 2119 terms? I think privilege revocation has to be a 2119 MUST. (But am open to argument that that MUST ought apply to the API not protocol.) |
2014-10-21
|
14 | Stephen Farrell | [Ballot comment] 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, … [Ballot comment] 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. |
2014-10-21
|
14 | Stephen Farrell | Ballot comment and discuss text updated for Stephen Farrell |
2014-05-22
|
14 | Tero Kivinen | Request for Last Call review by SECDIR Completed: Has Nits. Reviewer: Ben Laurie. |
2014-05-15
|
14 | Cindy Morgan | IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation |
2014-05-15
|
14 | Jari Arkko | [Ballot discuss] Thank you for writing a good document. Before recommending the final approval, I would like to see a response to Brian Carpenter's Gen-ART … [Ballot discuss] Thank you for writing a good document. Before recommending the final approval, I would like to see a response to Brian Carpenter's Gen-ART review, however. I believe that at least his first comment on different combinations of IPv4/IPv6 is something that deserves to be addressed in the document. OLD: o Clients can be on networks with a NAT using any type of Mapping and Filtering behaviors (as described in RFC4787). NEW: o Clients can be on networks with a NAT or IPv4-IPv6 translation devices using any type of Mapping and Filtering behaviors (as described in RFC4787). |
2014-05-15
|
14 | Jari Arkko | [Ballot Position Update] New position, Discuss, has been recorded for Jari Arkko |
2014-05-14
|
14 | Benoît Claise | [Ballot discuss] I have not seen any reply to Tina's OPS-DIR review, dated from April 25th. That makes it a DISCUSS to me, even if … [Ballot discuss] I have not seen any reply to Tina's OPS-DIR review, dated from April 25th. That makes it a DISCUSS to me, even if not all points in Tina's feedback are DISCUSS-worthy. See http://www.ietf.org/mail-archive/web/ops-dir/current/msg00274.html |
2014-05-14
|
14 | Benoît Claise | [Ballot comment] - References please Assuming that ICE will be used, this means that the service provider would like to be able to … [Ballot comment] - 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. |
2014-05-14
|
14 | Benoît Claise | [Ballot Position Update] New position, Discuss, has been recorded for Benoit Claise |
2014-05-14
|
14 | Pete Resnick | [Ballot comment] This document is a mishmash of UI requirements, local browser implementation requirements, and protocol requirements, with no distinctions being made among them. Given … [Ballot comment] 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. |
2014-05-14
|
14 | Pete Resnick | [Ballot Position Update] New position, Abstain, has been recorded for Pete Resnick |
2014-05-14
|
14 | Alissa Cooper | [Ballot comment] 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 … [Ballot comment] 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." |
2014-05-14
|
14 | Alissa Cooper | [Ballot Position Update] Position for Alissa Cooper has been changed to No Objection from Discuss |
2014-05-14
|
14 | Martin Stiemerling | [Ballot Position Update] New position, No Objection, has been recorded for Martin Stiemerling |
2014-05-13
|
14 | Spencer Dawkins | [Ballot comment] 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 … [Ballot comment] 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? |
2014-05-13
|
14 | Spencer Dawkins | Ballot comment text updated for Spencer Dawkins |
2014-05-13
|
14 | Spencer Dawkins | [Ballot comment] 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 … [Ballot comment] 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 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? |
2014-05-13
|
14 | Spencer Dawkins | [Ballot Position Update] New position, No Objection, has been recorded for Spencer Dawkins |
2014-05-13
|
14 | Stephen Farrell | [Ballot discuss] Nice document, thanks. But I have some issues to check. Nothing huge I'd say. (1) F13: Authenticate is ambiguous here (and in WebRTC … [Ballot discuss] Nice document, thanks. But I have some issues to check. Nothing huge I'd say. (1) F13: Authenticate is ambiguous here (and in WebRTC generally). There appears to be an understated need for an IdP here, and its really the IdP's that are authenticating (one another and) the endpoints. Did the WG discuss any form of endpoint auth that's based on e.g. an SSH leap-of-faith like setup where the endpoints can re-authenticate one another after a first contact? It'd be a bad thing if the WG made that impossible and effectively required IdPs I think. (2) F20: Is there not a missing requirement that one ought not be able to easily consume the bandwidth of someone else's TURN server just because you once made a call via that? (3) F36: Its not clear to me that this can ever be done safely, since JS code with this privilege can take screenshots every 10ms and hence get everything. A "must" level requirement seems quite inappropriate even if there is a real requirement there to allow some support for screensharing. (4) 3.3.12.1 - if the sound file can be local and played as a result of gameplay then that implies some form of authorization for access to files on the local filesystem - is that requirement actually being worked? (5) 6.2: why is revocation only "expected" and not a MUST? And why doesn't this section have any 2119 terms? I think privilege revocation has to be a 2119 MUST. (But am open to argument that that MUST ought apply to the API not protocol.) |
2014-05-13
|
14 | Stephen Farrell | [Ballot comment] - 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 … [Ballot comment] - 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. |
2014-05-13
|
14 | Stephen Farrell | [Ballot Position Update] New position, Discuss, has been recorded for Stephen Farrell |
2014-05-13
|
14 | Kathleen Moriarty | [Ballot comment] 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 … [Ballot comment] 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. |
2014-05-13
|
14 | Kathleen Moriarty | [Ballot Position Update] New position, No Objection, has been recorded for Kathleen Moriarty |
2014-05-13
|
14 | Alissa Cooper | [Ballot discuss] Section 6 strikes me as somewhat incomplete. I can appreciate that this is not the place to discuss every security issue relevant to … [Ballot discuss] Section 6 strikes me as somewhat incomplete. I can appreciate that this is not the place to discuss every security issue relevant to RTCWEB, but this section makes it sound as if the security threats are limited to DoS and surreptitious stream creation, leaving out considerations related to confidentiality, user identity, etc. At the very least, it seems like this section should stress that the scope of the discussion here is limited to those things (and maybe give a reason why?), and that a fuller treatment of the relevant security threats and mitigations is available in draft-ietf-rtcweb-security and draft-ietf-rtcweb-security-arch. |
2014-05-13
|
14 | Alissa Cooper | [Ballot comment] 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 … [Ballot comment] 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." |
2014-05-13
|
14 | Alissa Cooper | [Ballot Position Update] New position, Discuss, has been recorded for Alissa Cooper |
2014-05-13
|
14 | Adrian Farrel | [Ballot Position Update] New position, No Objection, has been recorded for Adrian Farrel |
2014-05-12
|
14 | Richard Barnes | As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated … As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated 24 February 2012. Write-up by Magnus Westerlund for draft-ietf-rtcweb-use-cases-and-requirements-14 (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? Informational RFC as indicated in header on first page. Appropriate due to the nature of it describing use-cases and derived requirements for the WebRTC system. (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary This document discusses a number of usages of browser based real-time communication and data transfer capabilities and establish requirements for these usages. The document is intended to be used both in IETF and W3C during the development of the WebRTC specifications. Working Group Summary The document has been under development during a longer period and a larger number of use cases has been proposed then what is included in the document. These that have been included has been considered the most basic, most relevant to core functionality and without significant controversies. Document Quality There has been some concerns about the structure of the document, but the WG see no significant need to address this. The document is requested to be published as a documentation of the core consideration around usages that was of interest during the first part of the WebRTC work. The other expected usage of this document will be to analyze if the resulting protocol solution will enable the considered use cases. The document has been reviewed and commented on by a significant number of people within the WG, including persons active in the W3C WEBRTC WG. Personnel Sean Turner is the Document Shepherd. Gonzalo Camarillo and Richard Barnes is the Responsible Area Directors. (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. The shepherd has review the document in WG last call and again prior to the publication request. Further the I-D checklist has been manually checked against the document as well as checking with the ID-Nits tool. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No, and the shepherd doesn't see a need to apply high requirements regarding document quality to a use-case and requirements document like this one. (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. No special review has been considered required. (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why. Yes, all authors have confirmed that they conform. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. No IPR disclosure filed. (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? There is a strong consensus and a large number of people have been involved with the document. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) No. (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. ID Nits reports this: Checking nits according to http://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 6 instances of lines with non-RFC5735-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. This is a false warning due to section references in the document that contains 4 levels of digits. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. There are nothing in this document requiring formal review. (13) Have all references within this document been identified as either normative or informative? Yes (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? No. (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. No downrefs. (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. No RFC will be affected by this documents publication. (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226). This is a use case and requirments document that doesn't define anything, thus no things specified that requires IANA registration. (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. No new registries. (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc. No formal language present. |
2014-05-12
|
14 | Brian Haberman | [Ballot Position Update] New position, No Objection, has been recorded for Brian Haberman |
2014-05-11
|
14 | Joel Jaeggli | [Ballot Position Update] New position, No Objection, has been recorded for Joel Jaeggli |
2014-05-11
|
14 | Brian Carpenter | Request for Telechat review by GENART Completed: Ready with Issues. Reviewer: Brian Carpenter. |
2014-05-08
|
14 | Jean Mahoney | Request for Telechat review by GENART is assigned to Brian Carpenter |
2014-05-08
|
14 | Jean Mahoney | Request for Telechat review by GENART is assigned to Brian Carpenter |
2014-05-08
|
14 | Barry Leiba | [Ballot comment] The change log says that this was done in -11: o Removed the "Conventions" section with the key-words and reference … [Ballot comment] 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. |
2014-05-08
|
14 | Barry Leiba | Ballot comment text updated for Barry Leiba |
2014-05-08
|
14 | Barry Leiba | [Ballot Position Update] New position, No Objection, has been recorded for Barry Leiba |
2014-05-03
|
14 | Gunter Van de Velde | Request for Last Call review by OPSDIR Completed: Ready. Reviewer: Tina Tsou. |
2014-05-01
|
14 | Richard Barnes | IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead |
2014-05-01
|
14 | Richard Barnes | Placed on agenda for telechat - 2014-05-15 |
2014-05-01
|
14 | Richard Barnes | Ballot has been issued |
2014-05-01
|
14 | Richard Barnes | [Ballot Position Update] New position, Yes, has been recorded for Richard Barnes |
2014-05-01
|
14 | Richard Barnes | Created "Approve" ballot |
2014-04-25
|
14 | (System) | IESG state changed to Waiting for AD Go-Ahead from In Last Call |
2014-04-22
|
14 | (System) | IANA Review state changed to IANA OK - No Actions Needed from IANA - Review Needed |
2014-04-22
|
14 | Amanda Baber | IESG/Authors/WG Chairs: IANA has reviewed draft-ietf-rtcweb-use-cases-and-requirements-14, which is currently in Last Call, and has the following comments: We understand that this document doesn't require … IESG/Authors/WG Chairs: IANA has reviewed draft-ietf-rtcweb-use-cases-and-requirements-14, which is currently in Last Call, and has the following comments: We understand that this document doesn't require any IANA actions. While it is helpful for the IANA Considerations section of the document to remain in place upon publication, if the authors prefer to remove it, IANA doesn't object. If this assessment is not accurate, please respond as soon as possible. |
2014-04-20
|
14 | Brian Carpenter | Request for Last Call review by GENART Completed: On the Right Track. Reviewer: Brian Carpenter. |
2014-04-17
|
14 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Ben Laurie |
2014-04-17
|
14 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Ben Laurie |
2014-04-17
|
14 | Sean Turner | Document shepherd changed to Sean Turner |
2014-04-16
|
14 | Jean Mahoney | Request for Last Call review by GENART is assigned to Brian Carpenter |
2014-04-16
|
14 | Jean Mahoney | Request for Last Call review by GENART is assigned to Brian Carpenter |
2014-04-14
|
14 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Tina Tsou |
2014-04-14
|
14 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Tina Tsou |
2014-04-11
|
14 | Amy Vezza | IANA Review state changed to IANA - Review Needed |
2014-04-11
|
14 | Amy Vezza | The following Last Call announcement was sent out: From: The IESG To: IETF-Announce CC: Reply-To: ietf@ietf.org Sender: Subject: Last Call: (Web Real-Time Communication Use-cases and … The following Last Call announcement was sent out: From: The IESG To: IETF-Announce CC: Reply-To: ietf@ietf.org Sender: Subject: Last Call: (Web Real-Time Communication Use-cases and Requirements) to Informational RFC The IESG has received a request from the Real-Time Communication in WEB-browsers WG (rtcweb) to consider the following document: - 'Web Real-Time Communication Use-cases and Requirements' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2014-04-25. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document describes web based real-time communication use-cases. Requirements on the browser functionality are derived from the use- cases. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-rtcweb-use-cases-and-requirements/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-rtcweb-use-cases-and-requirements/ballot/ No IPR declarations have been submitted directly on this I-D. |
2014-04-11
|
14 | Amy Vezza | IESG state changed to In Last Call from Last Call Requested |
2014-04-11
|
14 | Richard Barnes | Last call was requested |
2014-04-11
|
14 | Richard Barnes | Ballot approval text was generated |
2014-04-11
|
14 | Richard Barnes | IESG state changed to Last Call Requested from Publication Requested |
2014-04-11
|
14 | Richard Barnes | Last call announcement was generated |
2014-04-11
|
14 | Richard Barnes | Last call announcement was generated |
2014-04-11
|
14 | Richard Barnes | Ballot writeup was changed |
2014-04-11
|
14 | Richard Barnes | Ballot writeup was generated |
2014-03-05
|
14 | Amy Vezza | Shepherding AD changed to Richard Barnes |
2014-03-05
|
14 | Gonzalo Camarillo | IESG state changed to Publication Requested from Publication Requested::External Party |
2014-02-26
|
14 | Gonzalo Camarillo | IESG state changed to Publication Requested::External Party from Publication Requested |
2014-02-20
|
14 | Magnus Westerlund | IETF WG state changed to Submitted to IESG for Publication |
2014-02-20
|
14 | Magnus Westerlund | IESG state changed to Publication Requested |
2014-02-20
|
14 | Magnus Westerlund | As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated … As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated 24 February 2012. Write-up by Magnus Westerlund for draft-ietf-rtcweb-use-cases-and-requirements-14 (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? Informational RFC as indicated in header on first page. Appropriate due to the nature of it describing use-cases and derived requirements for the WebRTC system. (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary This document discusses a number of usages of browser based real-time communication and data transfer capabilities and establish requirements for these usages. The document is intended to be used both in IETF and W3C during the development of the WebRTC specifications. Working Group Summary The document has been under development during a longer period and a larger number of use cases has been proposed then what is included in the document. These that have been included has been considered the most basic, most relevant to core functionality and without significant controversies. Document Quality There has been some concerns about the structure of the document, but the WG see no significant need to address this. The document is requested to be published as a documentation of the core consideration around usages that was of interest during the first part of the WebRTC work. The other expected usage of this document will be to analyze if the resulting protocol solution will enable the considered use cases. The document has been reviewed and commented on by a significant number of people within the WG, including persons active in the W3C WEBRTC WG. Personnel Magnus Westerlund is the Document Shepherd. Gonzalo Camarillo and Richard Barnes is the Responsible Area Directors. (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. The shepherd has review the document in WG last call and again prior to the publication request. Further the I-D checklist has been manually checked against the document as well as checking with the ID-Nits tool. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No, and the shepherd doesn't see a need to apply high requirements regarding document quality to a use-case and requirements document like this one. (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. No special review has been considered required. (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why. Yes, all authors have confirmed that they conform. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. No IPR disclosure filed. (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? There is a strong consensus and a large number of people have been involved with the document. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) No. (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. ID Nits reports this: Checking nits according to http://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 6 instances of lines with non-RFC5735-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. This is a false warning due to section references in the document that contains 4 levels of digits. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. There are nothing in this document requiring formal review. (13) Have all references within this document been identified as either normative or informative? Yes (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? No. (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. No downrefs. (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. No RFC will be affected by this documents publication. (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226). This is a use case and requirments document that doesn't define anything, thus no things specified that requires IANA registration. (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. No new registries. (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc. No formal language present. |
2014-02-20
|
14 | Magnus Westerlund | State Change Notice email list changed to rtcweb-chairs@tools.ietf.org, draft-ietf-rtcweb-use-cases-and-requirements@tools.ietf.org |
2014-02-20
|
14 | Magnus Westerlund | Responsible AD changed to Gonzalo Camarillo |
2014-02-20
|
14 | Magnus Westerlund | Working group state set to Submitted to IESG for Publication |
2014-02-20
|
14 | Magnus Westerlund | IESG state set to Publication Requested |
2014-02-20
|
14 | Magnus Westerlund | IESG process started in state Publication Requested |
2014-02-20
|
14 | Magnus Westerlund | Changed document writeup |
2014-02-20
|
14 | Magnus Westerlund | This latest version resolves the issues that has been raised with the document after WG last call. There is now consensus to request publication. |
2014-02-20
|
14 | Magnus Westerlund | Tag Revised I-D Needed - Issue raised by WG cleared. |
2014-02-20
|
14 | Magnus Westerlund | IETF WG state changed to WG Consensus: Waiting for Write-Up from In WG Last Call |
2014-02-20
|
14 | Magnus Westerlund | Intended Status changed to Informational from None |
2014-02-20
|
14 | Magnus Westerlund | Changed document writeup |
2014-02-12
|
14 | Stefan Hakansson | New version available: draft-ietf-rtcweb-use-cases-and-requirements-14.txt |
2014-02-06
|
13 | Stefan Hakansson | New version available: draft-ietf-rtcweb-use-cases-and-requirements-13.txt |
2014-01-29
|
12 | Magnus Westerlund | A number of editorial comments plus some substantial changes are required prior to a 1 week last call on those changes. If those changes are … A number of editorial comments plus some substantial changes are required prior to a 1 week last call on those changes. If those changes are accepted, then publication will be requested. |
2014-01-29
|
12 | Magnus Westerlund | Tag Revised I-D Needed - Issue raised by WG set. Tag Other - see Comment Log cleared. |
2014-01-16
|
12 | Magnus Westerlund | Changed document writeup |
2014-01-15
|
12 | Magnus Westerlund | Starting Doc Shepherd write-up and review. Ongoing 1-week verification calls on changes and proposals to make modifications. |
2014-01-15
|
12 | Magnus Westerlund | Tag Other - see Comment Log set. |
2014-01-10
|
12 | Magnus Westerlund | Document shepherd changed to Magnus Westerlund |
2013-10-14
|
12 | Christer Holmberg | New version available: draft-ietf-rtcweb-use-cases-and-requirements-12.txt |
2013-06-27
|
11 | Stefan Hakansson | New version available: draft-ietf-rtcweb-use-cases-and-requirements-11.txt |
2013-01-28
|
10 | Magnus Westerlund | IETF state changed to In WG Last Call from WG Document |
2012-12-19
|
10 | Magnus Westerlund | In WG last call until 1 of Feb. |
2012-12-19
|
10 | Christer Holmberg | New version available: draft-ietf-rtcweb-use-cases-and-requirements-10.txt |
2012-06-27
|
09 | Stefan Hakansson | New version available: draft-ietf-rtcweb-use-cases-and-requirements-09.txt |
2012-06-04
|
08 | Stefan Hakansson | New version available: draft-ietf-rtcweb-use-cases-and-requirements-08.txt |
2012-04-02
|
07 | Christer Holmberg | New version available: draft-ietf-rtcweb-use-cases-and-requirements-07.txt |
2011-10-04
|
06 | (System) | New version available: draft-ietf-rtcweb-use-cases-and-requirements-06.txt |
2011-09-15
|
05 | (System) | New version available: draft-ietf-rtcweb-use-cases-and-requirements-05.txt |
2011-09-01
|
04 | (System) | New version available: draft-ietf-rtcweb-use-cases-and-requirements-04.txt |
2011-08-28
|
03 | (System) | New version available: draft-ietf-rtcweb-use-cases-and-requirements-03.txt |
2011-08-19
|
02 | (System) | New version available: draft-ietf-rtcweb-use-cases-and-requirements-02.txt |
2011-07-04
|
01 | (System) | New version available: draft-ietf-rtcweb-use-cases-and-requirements-01.txt |
2011-06-27
|
00 | (System) | New version available: draft-ietf-rtcweb-use-cases-and-requirements-00.txt |