WebRTC Forward Error Correction Requirements
draft-ietf-rtcweb-fec-10
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2020-05-01
|
10 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2020-04-10
|
10 | (System) | RFC Editor state changed to AUTH48 from RFC-EDITOR |
2020-03-16
|
10 | (System) | RFC Editor state changed to RFC-EDITOR from EDIT |
2019-07-17
|
10 | (System) | RFC Editor state changed to EDIT |
2019-07-17
|
10 | (System) | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2019-07-17
|
10 | (System) | Announcement was received by RFC Editor |
2019-07-16
|
10 | (System) | IANA Action state changed to No IANA Actions from In Progress |
2019-07-16
|
10 | (System) | IANA Action state changed to In Progress |
2019-07-16
|
10 | Cindy Morgan | IESG state changed to Approved-announcement sent from Approved-announcement to be sent |
2019-07-16
|
10 | Cindy Morgan | IESG has approved the document |
2019-07-16
|
10 | Cindy Morgan | Closed "Approve" ballot |
2019-07-16
|
10 | Cindy Morgan | Ballot approval text was generated |
2019-07-16
|
10 | Adam Roach | This version addresses all IESG comments, and is ready for publication. |
2019-07-16
|
10 | Adam Roach | IESG state changed to Approved-announcement to be sent from Approved-announcement to be sent::AD Followup |
2019-07-16
|
10 | Justin Uberti | New version available: draft-ietf-rtcweb-fec-10.txt |
2019-07-16
|
10 | (System) | Forced post of submission |
2019-07-16
|
10 | (System) | Request for posting confirmation emailed to previous authors: Justin Uberti |
2019-07-16
|
10 | Justin Uberti | Uploaded new revision |
2019-07-03
|
09 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2019-07-03
|
09 | Justin Uberti | New version available: draft-ietf-rtcweb-fec-09.txt |
2019-07-03
|
09 | (System) | New version approved |
2019-07-03
|
09 | (System) | Request for posting confirmation emailed to previous authors: Justin Uberti |
2019-07-03
|
09 | Justin Uberti | Uploaded new revision |
2019-07-03
|
09 | (System) | Request for posting confirmation emailed to previous authors: Justin Uberti |
2019-07-03
|
09 | Justin Uberti | Uploaded new revision |
2019-02-21
|
08 | Jean Mahoney | Closed request for Last Call review by GENART with state 'No Response' |
2019-02-21
|
08 | Cindy Morgan | IESG state changed to Approved-announcement to be sent::Revised I-D Needed from IESG Evaluation |
2019-02-21
|
08 | Alissa Cooper | [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper |
2019-02-20
|
08 | Spencer Dawkins | [Ballot Position Update] New position, No Objection, has been recorded for Spencer Dawkins |
2019-02-20
|
08 | Ignas Bagdonas | [Ballot Position Update] New position, No Objection, has been recorded for Ignas Bagdonas |
2019-02-20
|
08 | Deborah Brungard | [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard |
2019-02-20
|
08 | Ben Campbell | [Ballot comment] Thanks for this effort. I am balloting "yes", but have some minor comments: §8: - "Given this, WebRTC implementations SHOULD consider using RTX … [Ballot comment] Thanks for this effort. I am balloting "yes", but have some minor comments: §8: - "Given this, WebRTC implementations SHOULD consider using RTX or flexfec retransmissions instead of FEC when RTT is low," "consider" seems vague for a normative requirement. Can you describe concrete requirements? Otherwise I suggest descriptive language. Can you give guidance on what RTT would be reasonable to consider as "low"? - "Note that when probing bandwidth, i.e., speculatively sending extra data to determine if additional link capacity exists, FEC SHOULD be used in all cases." I assume the point of this is the redundant FEC data should _be_ that extra data. But one could read this to mean that, if you are already sending extra data, you should also use FEC. §9, 2nd paragraph: I'm by no means an expert in this, and leave it to the crypto experts to know if this matters, but does the additional redundancy of FEC have any impact on SRTP encryption? |
2019-02-20
|
08 | Ben Campbell | [Ballot Position Update] New position, Yes, has been recorded for Ben Campbell |
2019-02-20
|
08 | Martin Vigoureux | [Ballot Position Update] New position, No Objection, has been recorded for Martin Vigoureux |
2019-02-20
|
08 | Alvaro Retana | [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana |
2019-02-20
|
08 | Warren Kumari | [Ballot comment] Please see the OpsDir review at: https://datatracker.ietf.org/doc/review-ietf-rtcweb-fec-08-opsdir-telechat-schoenwaelder-2019-02-12/ -- it contains some useful comments. Also, a small nit: Abstract: "This document defines a new … [Ballot comment] Please see the OpsDir review at: https://datatracker.ietf.org/doc/review-ietf-rtcweb-fec-08-opsdir-telechat-schoenwaelder-2019-02-12/ -- it contains some useful comments. Also, a small nit: Abstract: "This document defines a new concep of enabling" - typo for concept. |
2019-02-20
|
08 | Warren Kumari | [Ballot Position Update] New position, No Objection, has been recorded for Warren Kumari |
2019-02-19
|
08 | Suresh Krishnan | [Ballot Position Update] New position, No Objection, has been recorded for Suresh Krishnan |
2019-02-19
|
08 | Adam Roach | IESG state changed to IESG Evaluation from Waiting for Writeup |
2019-02-19
|
08 | Mirja Kühlewind | [Ballot comment] I'm not fully sure about the intended status of this document. The shepherd write-up says "the document has normative requirements for conforming WebRTC … [Ballot comment] I'm not fully sure about the intended status of this document. The shepherd write-up says "the document has normative requirements for conforming WebRTC implementations", however, for me it seems this document makes "only" recommendations and has actually no normative requirements. Therefore informational status might be more appropriate, however, I will not block publication as PS. One mostly minor editorial note: Sec 3.3: "experiments performed indicate that when Opus FEC is used, the overhead imposed is about 20-30%, depending on the amount of protection needed." Would it be possible to provide a reference for this number? Also this section says: "See [RFC6716], Section 2.1.7 for complete details." However, section 2.1.7 in RFC6716 is very short and actually does not provide any details... |
2019-02-19
|
08 | Mirja Kühlewind | [Ballot Position Update] New position, No Objection, has been recorded for Mirja Kühlewind |
2019-02-18
|
08 | Alexey Melnikov | [Ballot Position Update] New position, No Objection, has been recorded for Alexey Melnikov |
2019-02-17
|
08 | Benjamin Kaduk | [Ballot comment] Section 3 nit: The subsequent discussion seems to indicate that at least some of these mechanisms are already specified and not new in … [Ballot comment] Section 3 nit: The subsequent discussion seems to indicate that at least some of these mechanisms are already specified and not new in this document; (if so) it would be nice to have the exposition reflect that. Section 3.3 For Opus, packets deemed as important are re-encoded at a lower bitrate and added to the subsequent packet, allowing partial recovery Is "added" supposed to be something other than "appended" (which strongly resembles the "redundant encoding" of the previous section)? Section 4.1 Does it make sense to give subsection backreferences when talking about (e.g.) redundant encoding? Section 5.2 Support for a SSRC-multiplexed flexfec stream to protect a given RTP stream SHOULD be indicated by including one of the formats described in [I-D.ietf-payload-flexible-fec-scheme], Section 5.1, as an nit: Since this Section 5 is solely for video, is it more appropriate to refer to Section 5.1.2 ("Registration of video/flexfec") of draft-ietf-payload-flexible-fec-scheme? Section 7 To support the functionality recommended above, implementations MUST be able to receive and make use of the relevant FEC formats for their supported audio codecs, and MUST indicate this support, as described in Section 4. Use of these formats when sending, as mentioned above, is RECOMMENDED. Just to double-check: this is explicitly only mandating FEC for audio and ignoring video entirely? Section 8 Because use of FEC always causes redundant data to be transmitted, and the total amount of data must remain within any bandwidth limits indicated by congestion control and the receiver, this will lead to less bandwidth available for the primary encoding, even when the redundant data is not being used. This is in contrast to methods like RTX [RFC4588] or flexfec [I-D.ietf-payload-flexible-fec-scheme] retransmissions, which only transmit redundant data when necessary, at the cost of an extra roundtrip. This seems to imply that "FEC" is a specific usage and that flexfec is not a subset of generic FEC. If so, this could probably be reworded to be less confusing to the reader (though my suspicion is that the "always causes redundant data to be transmitted" is only intended to apply to specific mechanisms from Section 3). Section 9 This document seems to be agnostic on the question of RTP vs. SRTP; I would consider referencing their respective security considerations as well as what is already covered here. As described in [RFC3711], Section 10, the default processing when using FEC with SRTP is to perform FEC followed by SRTP at the sender, and SRTP followed by FEC at the receiver. This ordering is used for all the SRTP Protection Profiles used in DTLS-SRTP [RFC5763], as described in [RFC5764], Section 4.1.2. I was going to comment about the lack of clarity here, but I see that Ekr has already gotten the core points, and that the secdir review has already resulted in some chanegs in the editor's copy. It would be nice to have the result of the (merged) edits available to look at, though. |
2019-02-17
|
08 | Benjamin Kaduk | [Ballot Position Update] New position, No Objection, has been recorded for Benjamin Kaduk |
2019-02-17
|
08 | Eric Rescorla | [Ballot comment] Rich version of this review at: https://mozphab-ietf.devsvcdev.mozaws.net/D3278 COMMENTS S 5.2. > as described in [RFC5956], Section 4.1 is not … [Ballot comment] Rich version of this review at: https://mozphab-ietf.devsvcdev.mozaws.net/D3278 COMMENTS S 5.2. > as described in [RFC5956], Section 4.1 is not currently defined for > WebRTC, and SHOULD NOT be offered. > > Answerers SHOULD reject any FEC-only m-lines, unless they > specifically know how to handle such a thing in a WebRTC context > (perhaps defined by a future version of the WebRTC specifications). It seems like the above three paragraphs are generic to this document, and just grouped with video because the audio codecs tend to have internal FEC? If so, maybe put them elasewhere? S 9. > > As described in [RFC3711], Section 10, the default processing when > using FEC with SRTP is to perform FEC followed by SRTP at the sender, > and SRTP followed by FEC at the receiver. This ordering is used for > all the SRTP Protection Profiles used in DTLS-SRTP [RFC5763], as > described in [RFC5764], Section 4.1.2. I of course agree with this text, but I wonder if it's maximally clear. Perhaps rewrite the first sentence as: ```The FEC schemes described in this document use other packets to recover when a packet is lost or damaged but do not allow for recovery of a damaged packet on its own. This is consistent with the default processing for using FEC with SRTP described in RFC 3711, which is to perform FEC followed by SRTP at the sender, and SRTP followed by FEC at the receiver, which implies that damaged packets will be rejected by the SRTP integrity check and discarded.``` |
2019-02-17
|
08 | Eric Rescorla | [Ballot Position Update] New position, No Objection, has been recorded for Eric Rescorla |
2019-02-12
|
08 | Jürgen Schönwälder | Request for Telechat review by OPSDIR Completed: Has Nits. Reviewer: Jürgen Schönwälder. Sent review to list. |
2019-02-12
|
08 | Gunter Van de Velde | Request for Telechat review by OPSDIR is assigned to Jürgen Schönwälder |
2019-02-12
|
08 | Gunter Van de Velde | Request for Telechat review by OPSDIR is assigned to Jürgen Schönwälder |
2019-02-07
|
08 | Amy Vezza | Placed on agenda for telechat - 2019-02-21 |
2019-02-07
|
08 | Adam Roach | Ballot has been issued |
2019-02-07
|
08 | Adam Roach | [Ballot Position Update] New position, Yes, has been recorded for Adam Roach |
2019-02-07
|
08 | Adam Roach | Created "Approve" ballot |
2019-02-07
|
08 | Adam Roach | Ballot writeup was changed |
2019-02-07
|
08 | Tero Kivinen | Request for Last Call review by SECDIR Completed: Has Issues. Reviewer: Hilarie Orman. |
2019-02-04
|
08 | Magnus Westerlund | Closed request for Last Call review by TSVART with state 'No Response' |
2019-02-01
|
08 | Adam Roach | Please also see SECDIR review at https://mailarchive.ietf.org/arch/msg/secdir/rlMXgykB2D5JAI1slbSINen-zvg (Filed against the wrong document, so it's not showing up here yet). |
2019-02-01
|
08 | (System) | IANA Review state changed to IANA OK - No Actions Needed from IANA - Review Needed |
2019-02-01
|
08 | Sabrina Tanamal | (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has reviewed draft-ietf-rtcweb-fec-08, which is currently in Last Call, and has the following comments: We … (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has reviewed draft-ietf-rtcweb-fec-08, which is currently in Last Call, and has the following comments: We understand that this document doesn't require any registry actions. While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object. If this assessment is not accurate, please respond as soon as possible. Thank you, Sabrina Tanamal Senior IANA Services Specialist |
2019-02-01
|
08 | (System) | IESG state changed to Waiting for Writeup from In Last Call |
2019-01-28
|
08 | Magnus Westerlund | Request for Last Call review by TSVART is assigned to Fernando Gont |
2019-01-28
|
08 | Magnus Westerlund | Request for Last Call review by TSVART is assigned to Fernando Gont |
2019-01-24
|
08 | Jean Mahoney | Request for Last Call review by GENART is assigned to Jouni Korhonen |
2019-01-24
|
08 | Jean Mahoney | Request for Last Call review by GENART is assigned to Jouni Korhonen |
2019-01-24
|
08 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Hilarie Orman |
2019-01-24
|
08 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Hilarie Orman |
2019-01-18
|
08 | Cindy Morgan | IANA Review state changed to IANA - Review Needed |
2019-01-18
|
08 | Cindy Morgan | The following Last Call announcement was sent out (ends 2019-02-01): From: The IESG To: IETF-Announce CC: ted.ietf@gmail.com, adam@nostrum.com, rtcweb-chairs@ietf.org, Ted Hardie , … The following Last Call announcement was sent out (ends 2019-02-01): From: The IESG To: IETF-Announce CC: ted.ietf@gmail.com, adam@nostrum.com, rtcweb-chairs@ietf.org, Ted Hardie , draft-ietf-rtcweb-fec@ietf.org, rtcweb@ietf.org Reply-To: ietf@ietf.org Sender: Subject: Last Call: (WebRTC Forward Error Correction Requirements) to Proposed Standard The IESG has received a request from the Real-Time Communication in WEB-browsers WG (rtcweb) to consider the following document: - 'WebRTC Forward Error Correction Requirements' as Proposed Standard 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 2019-02-01. 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 provides information and requirements for how Forward Error Correction (FEC) should be used by WebRTC implementations. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-rtcweb-fec/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-rtcweb-fec/ballot/ No IPR declarations have been submitted directly on this I-D. |
2019-01-18
|
08 | Cindy Morgan | IESG state changed to In Last Call from Last Call Requested |
2019-01-18
|
08 | Adam Roach | Last call was requested |
2019-01-18
|
08 | Adam Roach | Ballot approval text was generated |
2019-01-18
|
08 | Adam Roach | Ballot writeup was generated |
2019-01-18
|
08 | Adam Roach | IESG state changed to Last Call Requested from Waiting for AD Go-Ahead::External Party |
2019-01-18
|
08 | Adam Roach | Last call announcement was generated |
2018-11-06
|
08 | Adam Roach | IESG state changed to Waiting for AD Go-Ahead::External Party from AD Evaluation::External Party |
2018-03-02
|
08 | Justin Uberti | New version available: draft-ietf-rtcweb-fec-08.txt |
2018-03-02
|
08 | (System) | New version approved |
2018-03-02
|
08 | (System) | Request for posting confirmation emailed to previous authors: Justin Uberti |
2018-03-02
|
08 | Justin Uberti | Uploaded new revision |
2018-03-01
|
07 | Adam Roach | Placing in "External Party" state to wait for publication of draft-ietf-payload-flexible-fec-scheme, which should be evaluated in concert with this document. AD Evaluation is complete; … Placing in "External Party" state to wait for publication of draft-ietf-payload-flexible-fec-scheme, which should be evaluated in concert with this document. AD Evaluation is complete; see https://mailarchive.ietf.org/arch/msg/rtcweb/-eq1zTdzuSfboBKT5fKWy6w_OuE |
2018-03-01
|
07 | Adam Roach | IESG state changed to AD Evaluation::External Party from Publication Requested |
2018-03-01
|
07 | Adam Roach | Changed consensus to Yes from Unknown |
2018-01-08
|
07 | Ted Hardie | (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? … (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? This request is for Proposed Standard. The type of RFC is indicated in the title page header. This is the appropriate status because the document has normative requirements for conforming WebRTC implementations. (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 In situations where packet loss is high or perfect media quality is essential, Forward Error Correction (FEC) can be used to proactively recover from packet losses. This specification provides guidance on which FEC mechanisms to use, and how to use them, for WebRTC implementations. Working Group Summary The working group support for the document was generally high. One issued was raised in working group last call regarding the effectiveness of the Opus internal FEC mechanism. The document currently states that it is RECOMMENDED for protection against individual packet loss and that other methods are needed for multi-packet protection. This mirrors text in RFC 6716 and accurately captures a limitation of the in-band FEC mechanism. The question of effectiveness is thus tightly tied to the loss pattern. While data on this was presented, there was no evident consensus to update the requirement, so the recommendation from RFC 6716 was retained. Document Quality This document appears to have the support of the relevant development community and will likely be implemented and deployed. Reviews by Mo Zanaty, Magnus Westerlund, and Bernard Aboba were particularly helpful. Personnel Who is the Document Shepherd? Who is the Responsible Area Director? Ted Hardie is the Document Shepherd. Adam Roach is the Responsible Area Director. (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 document shepherd reviewed the current draft and the set of issues, requesting updates for those which had not yet been addressed. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No concerns. (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. The reviews which took place appear to have been the appropriate reviews. (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. The author has confirmed that no IPR disclosures are required. (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 disclosures have been 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? It is a strong consensus among those engaged in this topic; as it stands, the working groups interests are broad, and some are not following this issue closely. None of those seem likely, however, to raise late objections. (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 appeal has been threatened nor does that level of discontent seem likely. (11) Identify any ID nits the Document Shepherd has found in this document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. These are the identified nits: == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- The document date (December 10, 2017) is 25 days in the past. Is this intentional? The date issues are because the document was last updated in December of 2017 and we are now in January of 2018. I do not believe that the "NOT RECOMMENDED" nit needs to be addressed prior to publication because "RECOMMENDED" is list and defined. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. There are no related formal review requirements. (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? Yes, there is one document, draft-ietf-payload-flexible-fec-scheme, which has not yet been published. It is progressing in the PAYLOAD working group, and this draft will need to await its publication to be published. At the time of this write-up, the draft was in working group last call. There is some feedback there from implementors which may require minor clarifications, but these do not seem likely to impact this draft's references. (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. There is a normative reference to IMS, and it may require an explicit call out in the Last Call, since this version (September 2017) may not have been previously addressed. (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. This document will not change that status of any existing RFC. (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 document makes no requests of IANA. (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. This document makes no requests of IANA. (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. This document has no sections in a formal grammar. |
2018-01-08
|
07 | Ted Hardie | Responsible AD changed to Adam Roach |
2018-01-08
|
07 | Ted Hardie | IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up |
2018-01-08
|
07 | Ted Hardie | IESG state changed to Publication Requested |
2018-01-08
|
07 | Ted Hardie | IESG process started in state Publication Requested |
2018-01-08
|
07 | Ted Hardie | Changed document writeup |
2018-01-05
|
07 | Ted Hardie | Changed document writeup |
2018-01-04
|
07 | Ted Hardie | Changed document writeup |
2017-12-10
|
07 | Justin Uberti | New version available: draft-ietf-rtcweb-fec-07.txt |
2017-12-10
|
07 | (System) | New version approved |
2017-12-10
|
07 | (System) | Request for posting confirmation emailed to previous authors: Justin Uberti |
2017-12-10
|
07 | Justin Uberti | Uploaded new revision |
2017-11-30
|
06 | Ted Hardie | IETF WG state changed to WG Consensus: Waiting for Write-Up from In WG Last Call |
2017-08-02
|
06 | Ted Hardie | One outstanding issue, https://github.com/juberti/draughts/issues/81. |
2017-08-02
|
06 | Ted Hardie | IETF WG state changed to In WG Last Call from WG Document |
2017-07-03
|
06 | Justin Uberti | New version available: draft-ietf-rtcweb-fec-06.txt |
2017-07-03
|
06 | (System) | New version approved |
2017-07-03
|
06 | (System) | Request for posting confirmation emailed to previous authors: Justin Uberti |
2017-07-03
|
06 | Justin Uberti | Uploaded new revision |
2017-05-23
|
05 | Justin Uberti | New version available: draft-ietf-rtcweb-fec-05.txt |
2017-05-23
|
05 | (System) | New version approved |
2017-05-23
|
05 | (System) | Request for posting confirmation emailed to previous authors: Justin Uberti |
2017-05-23
|
05 | Justin Uberti | Uploaded new revision |
2017-05-04
|
04 | (System) | Document has expired |
2017-02-02
|
04 | Ted Hardie | Notification list changed to "Ted Hardie" <ted.ietf@gmail.com> |
2017-02-02
|
04 | Ted Hardie | Document shepherd changed to Ted Hardie |
2016-10-31
|
04 | Justin Uberti | New version available: draft-ietf-rtcweb-fec-04.txt |
2016-10-31
|
04 | (System) | New version approved |
2016-10-31
|
03 | (System) | Request for posting confirmation emailed to previous authors: "Justin Uberti" |
2016-10-31
|
03 | Justin Uberti | Uploaded new revision |
2016-09-21
|
03 | (System) | Document has expired |
2016-03-20
|
03 | Justin Uberti | New version available: draft-ietf-rtcweb-fec-03.txt |
2015-10-18
|
02 | Justin Uberti | New version available: draft-ietf-rtcweb-fec-02.txt |
2015-04-16
|
01 | Sean Turner | This document now replaces draft-uberti-rtcweb-fec instead of None |
2015-03-08
|
01 | Justin Uberti | New version available: draft-ietf-rtcweb-fec-01.txt |
2015-03-03
|
00 | Ted Hardie | Intended Status changed to Proposed Standard from None |
2015-02-06
|
00 | Justin Uberti | New version available: draft-ietf-rtcweb-fec-00.txt |