Skip to main content

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