RTP Payload Format for VP8 Video
draft-ietf-payload-vp8-17
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2016-03-17
|
17 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2016-01-04
|
17 | (System) | RFC Editor state changed to AUTH48 from RFC-EDITOR |
2015-12-20
|
17 | (System) | RFC Editor state changed to RFC-EDITOR from EDIT |
2015-10-14
|
17 | (System) | Notify list changed from payload-chairs@ietf.org, draft-ietf-payload-vp8@ietf.org to (None) |
2015-09-28
|
17 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2015-09-25
|
17 | (System) | IANA Action state changed to Waiting on RFC Editor from Waiting on Authors |
2015-09-25
|
17 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2015-09-25
|
17 | (System) | IANA Action state changed to In Progress |
2015-09-23
|
17 | (System) | RFC Editor state changed to EDIT |
2015-09-23
|
17 | (System) | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2015-09-23
|
17 | (System) | Announcement was received by RFC Editor |
2015-09-23
|
17 | Cindy Morgan | IESG state changed to Approved-announcement sent from Approved-announcement to be sent::Point Raised - writeup needed |
2015-09-23
|
17 | Cindy Morgan | IESG has approved the document |
2015-09-23
|
17 | Cindy Morgan | Closed "Approve" ballot |
2015-09-23
|
17 | Cindy Morgan | Ballot approval text was generated |
2015-09-23
|
17 | Cindy Morgan | Ballot writeup was changed |
2015-09-23
|
17 | Ben Campbell | IESG state changed to Approved-announcement to be sent::Point Raised - writeup needed from Approved-announcement to be sent::Revised I-D Needed |
2015-09-23
|
17 | Ben Campbell | Ballot approval text was generated |
2015-09-23
|
17 | Ben Campbell | Ballot writeup was changed |
2015-09-17
|
17 | Gunter Van de Velde | Closed request for Last Call review by OPSDIR with state 'No Response' |
2015-09-17
|
17 | Cindy Morgan | IESG state changed to Approved-announcement to be sent::Revised I-D Needed from IESG Evaluation |
2015-09-17
|
17 | Alvaro Retana | [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana |
2015-09-16
|
17 | Terry Manderson | [Ballot Position Update] New position, No Objection, has been recorded for Terry Manderson |
2015-09-16
|
17 | Kathleen Moriarty | [Ballot comment] Why is this a SHOULD: Applications SHOULD use one or more appropriate strong security mechanisms. Wouldn't it be more helpful to point out … [Ballot comment] Why is this a SHOULD: Applications SHOULD use one or more appropriate strong security mechanisms. Wouldn't it be more helpful to point out why you would use specific security mechanisms for security considerations? |
2015-09-16
|
17 | Kathleen Moriarty | [Ballot Position Update] New position, No Objection, has been recorded for Kathleen Moriarty |
2015-09-16
|
17 | Alia Atlas | [Ballot Position Update] New position, No Objection, has been recorded for Alia Atlas |
2015-09-16
|
17 | Deborah Brungard | [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard |
2015-09-15
|
17 | Alissa Cooper | [Ballot comment] -- 4.2: Little confused as to why the I and L behavior is specified twice, e.g.: "I: PictureID present. When set to one, … [Ballot comment] -- 4.2: Little confused as to why the I and L behavior is specified twice, e.g.: "I: PictureID present. When set to one, the PictureID MUST be present after the extension bit field and specified as below. Otherwise, PictureID MUST NOT be present." and "The PictureID extension: If the I bit is set to one, the PictureID extension field MUST be present, and MUST NOT be present otherwise." -- 4.2: Why would the index values TL0PICIDX and KEYIDX start at random values? -- 6.1: Seconding Pete's old comment that the normative requirements on use of max-fs and max-fr should appear somewhere other than the media type definition. |
2015-09-15
|
17 | Alissa Cooper | [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper |
2015-09-15
|
17 | Brian Haberman | [Ballot Position Update] New position, No Objection, has been recorded for Brian Haberman |
2015-09-11
|
17 | Ali Begen | This document now replaces draft-westin-payload-vp8 instead of None |
2015-09-10
|
17 | (System) | IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed |
2015-09-09
|
17 | Ben Campbell | IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead::AD Followup |
2015-09-09
|
17 | Ben Campbell | Changed consensus to Yes from Unknown |
2015-09-09
|
17 | Ben Campbell | Telechat date has been changed to 2015-09-17 from 2013-07-18 |
2015-09-09
|
17 | Ben Campbell | Ballot has been issued |
2015-09-09
|
17 | Ben Campbell | [Ballot Position Update] New position, Yes, has been recorded for Ben Campbell |
2015-09-09
|
17 | Ben Campbell | Ballot approval text was generated |
2015-09-09
|
17 | Ben Campbell | Ballot writeup was changed |
2015-09-09
|
17 | Ben Campbell | [Minor edit by Ben Campbell on 9/9/2015] (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why … [Minor edit by Ben Campbell on 9/9/2015] (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? Standards track as indicated in the title page header. (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 specifies the RTP payload format for the VP8 video codec. The VP8 codec supports various applications ranging from low-bitrate peer-to-peer to high-bitrate videoconferencing applications. Working Group Summary The WGLC process was run twice and bunch of comments were addressed in the latest version. After the second WGLC, there were some comments submitted by Cullen Jennings and one of the authors responded in the list. At this time, we are proceeding with publication request. If there are further comments, they can be submitted during the IETF LC. [Ben: Since this, the draft has been through an initial IESG evaluation and a second IETF last call] Document Quality The VP8 codec has been used in various applications (most notably by Google). Earlier versions of codec were used by Skype. The media subtype registration review was request on 11/28/2012. Personnel Ali Begen is the document shepherd. Ben Campbell is the responsible AD. (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 reviewed the latest version (-08) and there are no issues. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? Not at this point. (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. Nope. (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. None. (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. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. There is one IPR submission from Vidyo (IPR 1622). The WG did not have concerns about this IPR submission. (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? Several people reviewed this document, mostly who are interested in implementing this payload. There were no objections from the rest of the WG. (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.) Nope. (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. There are a few ID nits. 1) Unused reference: RFC 3984 2) Obsolete normative reference: RFC 4288 (Obsoleted by RFC 6838) 3) Downref: Normative reference to an Informational RFC: RFC 6386 There are also a few minor errors. For example, the subtype has 3 (not 2) optional parameters. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. Media subtype registration review was requested: http://www.ietf.org/mail-archive/web/media-types/current/msg00455.html (13) Have all references within this document been identified as either normative or informative? No, which means all references will be considered as "normative". (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? Nope. (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 downref to RFC 6386, which is the main RFC that describes the VP8 data format. That RFC is an informational one since it was an independent submission (not thru a WG). [Ben: This downref was called out in the second IETF last call.] (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 changes to existing documents. (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). The media subtype registration is compliant with the registration template (RFC 6838). (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 IANA 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 considerations. |
2015-09-09
|
17 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2015-09-09
|
17 | Henrik Lundin | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2015-09-09
|
17 | Henrik Lundin | New version available: draft-ietf-payload-vp8-17.txt |
2015-07-29
|
16 | Ben Campbell | IESG state changed to Waiting for AD Go-Ahead::Revised I-D Needed from Waiting for AD Go-Ahead |
2015-07-13
|
16 | (System) | IESG state changed to Waiting for AD Go-Ahead from In Last Call |
2015-07-10
|
16 | (System) | IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed |
2015-07-10
|
16 | Pearl Liang | (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: IANA has reviewed draft-ietf-payload-vp8-16. Authors should review the comments and/or questions below. Please report any inaccuracies and respond to any … (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: IANA has reviewed draft-ietf-payload-vp8-16. Authors should review the comments and/or questions below. Please report any inaccuracies and respond to any questions as soon as possible. We received the following comments/questions from the IANA's reviewer: IANA understands that, upon approval of this document, there is a single action which IANA must complete. In the video subspace of the Media Types namespace located at: http://www.iana.org/assignments/media-types/ the following video media type will be registered: Name: VP8 Template: [ TBD-at-Registration ] Reference: [ RFC-to-be ] IANA understands that this is the only action required to be completed upon approval of this document. Note: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed. |
2015-07-02
|
16 | Jean Mahoney | Request for Last Call review by GENART is assigned to Elwyn Davies |
2015-07-02
|
16 | Jean Mahoney | Request for Last Call review by GENART is assigned to Elwyn Davies |
2015-06-30
|
16 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Niclas Comstedt |
2015-06-30
|
16 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Niclas Comstedt |
2015-06-29
|
16 | 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: (RTP Payload Format for VP8 … The following Last Call announcement was sent out: From: The IESG To: IETF-Announce CC: Reply-To: ietf@ietf.org Sender: Subject: Last Call: (RTP Payload Format for VP8 Video) to Proposed Standard The IESG has received a request from the Audio/Video Transport Payloads WG (payload) to consider the following document: - 'RTP Payload Format for VP8 Video' as Proposed Standard This draft contains normative reference to an Informational RFC: RFC 6386 This is a repeated last call. The draft was previously last called and underwent IESG evaluation in 2013. The last call is being repeated due to the normative downward reference, and due to the fairly significant changes since that evaluation. 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 2015-07-13. 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 memo describes an RTP payload format for the VP8 video codec. The payload format has wide applicability, as it supports applications from low bit-rate peer-to-peer usage, to high bit-rate video conferences. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-payload-vp8/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-payload-vp8/ballot/ The following IPR Declarations may be related to this I-D: https://datatracker.ietf.org/ipr/1622/ |
2015-06-29
|
16 | Amy Vezza | IESG state changed to In Last Call from Last Call Requested |
2015-06-29
|
16 | Ben Campbell | I'm doing a quick re-look at draft-ietf-payload-vp8-16 before starting a repeat IETF Last Call. I have a few comments. I don't think any of these … I'm doing a quick re-look at draft-ietf-payload-vp8-16 before starting a repeat IETF Last Call. I have a few comments. I don't think any of these need delay the last call, so please address them along with any last call comments. Please bear in mind that I am reconstructing a lot of history here, so I apologize in advance if I bring up things that have already been discussed. ------------ General: Ted Lemon and Pete Resnick made some AD comments when they were still ADs. Even though they are no longer on the IESG, their comments look reasonable. I don't see evidence that they have been addressed--please consider addressing them. It looks like you have addressed some, but not all, of Stephen Farrell's comments. Has there been discussion on why the ones not addressed were not addressed? (Note that in both of the paragraphs above, I don't mean by "addressed" that the draft necessarily needs to change--just that the authors respond to the input--even if only to say why they don't agree with a comment.) -- 4.5 and 4.5.1: It would be helpful to explain why these are listed as examples. I assume it's one of those cases where this algorithm gives the right results, but others could also do so. If so, some words to that effect would be helpful. It might also be helpful to include a few words indicating why 4.5.1 is a child of 4.5 rather than a peer. (I assume because partition reconstruction is a subset of frame reconstruction?) -- 7: I don't see a response to the secdir review ( Secdir review of draft-ietf-payload-vp8-08 ). For the SRTP question, please consider using the boilerplate in the appendix of draft-ietf-payload-rtp-howto-14 (section A.13). |
2015-06-29
|
16 | Ben Campbell | Last call was requested |
2015-06-29
|
16 | Ben Campbell | IESG state changed to Last Call Requested from AD Evaluation |
2015-06-29
|
16 | Ben Campbell | Last call announcement was changed |
2015-06-29
|
16 | Ben Campbell | Last call announcement was changed |
2015-06-29
|
16 | Ben Campbell | Last call announcement was generated |
2015-06-29
|
16 | Ben Campbell | IESG state changed to AD Evaluation from AD is watching |
2015-06-18
|
16 | Barry Leiba | [Ballot comment] Thanks very much for addressing all my comments. The downref to RFC 6386 was not called out in the Last Call message; that's … [Ballot comment] Thanks very much for addressing all my comments. The downref to RFC 6386 was not called out in the Last Call message; that's required in order to support a downref, unless the referenced document is in the downref registry (which 6386 isn't). That means we'd need to re-run a two-week last call for that. I'll leave it to the responsible AD to decide whether to do that or not. No further blocking from me on the point. |
2015-06-18
|
16 | Barry Leiba | [Ballot Position Update] Position for Barry Leiba has been changed to No Objection from Discuss |
2015-06-05
|
16 | Henrik Lundin | New version available: draft-ietf-payload-vp8-16.txt |
2015-03-25
|
15 | Cindy Morgan | Shepherding AD changed to Ben Campbell |
2015-03-23
|
15 | Henrik Lundin | New version available: draft-ietf-payload-vp8-15.txt |
2015-03-19
|
14 | Richard Barnes | IESG state changed to AD is watching from IESG Evaluation |
2015-03-03
|
14 | Henrik Lundin | New version available: draft-ietf-payload-vp8-14.txt |
2014-11-13
|
13 | Richard Barnes | IESG state changed to IESG Evaluation from AD is watching |
2014-10-16
|
13 | Spencer Dawkins | [Ballot comment] I'm clearing because my first Discuss point about PID fields was addressed, and that was my major concern, but I didn't see any … [Ballot comment] I'm clearing because my first Discuss point about PID fields was addressed, and that was my major concern, but I didn't see any response via e-mail or changed text about my second DIscuss point on wrapping versus restarting at 0. It's not worth holding the document up for my second Discuss point, but if you meant to either tell me the Discuss point wasn't a problem or change text to address it, I missed that. Which could have happened, of course. For reference, that was as follows: TL0PICIDX: 8 bits temporal level zero index. The field MUST be present if the L bit is equal to 1, and MUST NOT be present otherwise. TL0PICIDX is a running index for the temporal base layer frames, i.e., the frames with TID set to 0. If TID is larger than 0, TL0PICIDX indicates which base layer frame the current image depends on. TL0PICIDX MUST be incremented when TID is 0. The index SHOULD start on a random number, and MUST restart at 0 after reaching the maximum number 255. KEYIDX: 5 bits temporal key frame index. The TID/KEYIDX octet MUST be present when either the T bit or the K bit or both are equal to 1, and MUST NOT be present otherwise. The KEYIDX field MUST be ignored by the receiver when the K bit is set equal to 0. The KEYIDX field is a running index for key frames. KEYIDX MAY start on a random number, and MUST restart at 0 after reaching the maximum number 31. I'm not quite sure why PictureID says "MUST wrap" and TL0PICIDX and KEYIDX say "MUST restart at 0". Are these the same thing (I would have thought so, but I'm not the codec guy). If they are the same, and you could consider using one term or the other in the document, that would be great. If they aren't the same, please say more about that. |
2014-10-16
|
13 | Spencer Dawkins | [Ballot Position Update] Position for Spencer Dawkins has been changed to No Objection from Discuss |
2014-10-15
|
13 | Henrik Lundin | New version available: draft-ietf-payload-vp8-13.txt |
2014-08-13
|
12 | Jari Arkko | [Ballot comment] I would prefer clearly listing the name of the references section as "Normative References", to make clear that all the references are required … [Ballot comment] I would prefer clearly listing the name of the references section as "Normative References", to make clear that all the references are required for understanding/implementation. |
2014-08-13
|
12 | Jari Arkko | [Ballot Position Update] Position for Jari Arkko has been changed to No Objection from Discuss |
2014-08-13
|
12 | Henrik Lundin | New version available: draft-ietf-payload-vp8-12.txt |
2014-02-10
|
11 | Benoît Claise | [Ballot Position Update] Position for Benoit Claise has been changed to No Objection from Discuss |
2014-02-10
|
11 | Patrik Westin | New version available: draft-ietf-payload-vp8-11.txt |
2013-10-03
|
10 | Patrik Westin | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2013-10-03
|
10 | Patrik Westin | New version available: draft-ietf-payload-vp8-10.txt |
2013-09-11
|
09 | Elwyn Davies | Request for Telechat review by GENART Completed: Ready with Nits. Reviewer: Elwyn Davies. |
2013-09-11
|
09 | Elwyn Davies | Request for Telechat review by GENART Completed: Ready. Reviewer: Elwyn Davies. |
2013-07-18
|
09 | (System) | Requested Telechat review by GENART |
2013-07-18
|
09 | Cindy Morgan | State changed to AD is watching from IESG Evaluation |
2013-07-18
|
09 | Martin Stiemerling | [Ballot comment] In support of Barry's discuss. |
2013-07-18
|
09 | Martin Stiemerling | [Ballot Position Update] New position, No Objection, has been recorded for Martin Stiemerling |
2013-07-18
|
09 | Richard Barnes | [Ballot discuss] Holding pending resolution of late LC comments. |
2013-07-18
|
09 | Richard Barnes | [Ballot Position Update] Position for Richard Barnes has been changed to Discuss from Yes |
2013-07-18
|
09 | Benoît Claise | [Ballot discuss] Regarding Barry's DISCUSS on downref (which I support obviously) See RFC 3967 3. The Procedure to Be Used … [Ballot discuss] Regarding Barry's DISCUSS on downref (which I support obviously) See RFC 3967 3. The Procedure to Be Used For Standards Track or BCP documents requiring normative reference to documents of lower maturity, the normal IETF Last Call procedure will be issued, with the need for the downward reference explicitly documented in the Last Call itself. Any community comments on the appropriateness of downward references will be considered by the IESG as part of its deliberations. See http://tools.ietf.org/group/iesg/trac/wiki/DownrefRegistry However, idnits shows: Checking nits according to http://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. I guess RFC 6386 should be normative (but not 100% sure). This makes the link with Jari's DISCUSS. I really wish the IESG would not have to spend time on idnits problems, and I even think the IESG should send the document back to the WG. This elevates my feedback to a DISCUSS, even if the problems have been reported in several DISCUSSes. |
2013-07-18
|
09 | Benoît Claise | [Ballot Position Update] New position, Discuss, has been recorded for Benoit Claise |
2013-07-18
|
09 | Gonzalo Camarillo | [Ballot comment] Richard will hold this document until all comments have been addressed. |
2013-07-18
|
09 | Gonzalo Camarillo | [Ballot Position Update] New position, No Objection, has been recorded for Gonzalo Camarillo |
2013-07-18
|
09 | Amanda Baber | IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed |
2013-07-17
|
09 | Adrian Farrel | [Ballot comment] Supporting Barry's Discuss |
2013-07-17
|
09 | Adrian Farrel | [Ballot Position Update] New position, No Objection, has been recorded for Adrian Farrel |
2013-07-17
|
09 | Stephen Farrell | [Ballot comment] I agree with the other discusses and comments. I also got the impression this either hadn't been that thoroughly reviewed or else had … [Ballot comment] I agree with the other discusses and comments. I also got the impression this either hadn't been that thoroughly reviewed or else had been so controversial that folks maybe concentrated only on the difficult parts and not on ovrerall clarity. I think it'd be very good to get someone to do a pass over the whole thing to improve clarity. If there weren't so many other discusses I think this would have been one. - section 3: where do I find out how to set up a reference hierarchy? - 4.1: "PID MUST NOT be larger than" 7 surely? Also given the "SHOULD increment" doesn't that mean I can send PIDs 0,3 and 7 only and that's ok? Do you want that? - 4.1: " If the X bit is 0, the extension bit field MUST NOT be present, and all bits below MUST be implicitly interpreted as 0." If X=0 then these octets are not sent so the various flags are not "bits" really. Suggest s/bits/values/ or similar. - 4.1: I assume TL0PICIDX etc are defined somewhere. Where? Adding some references would seem to be needed. - 4.5: Why is this an example? That's confusing. So is the structure of 4.5 then 4.5.1. - Please see the secdir review [1] which raises a couple more minor issues. [1] http://www.ietf.org/mail-archive/web/secdir/current/msg04030.html |
2013-07-17
|
09 | Stephen Farrell | [Ballot Position Update] New position, No Objection, has been recorded for Stephen Farrell |
2013-07-17
|
09 | Pete Resnick | [Ballot comment] 4.1: Sequence number: The sequence numbers are monotonically increasing and set as packets are sent. I … [Ballot comment] 4.1: Sequence number: The sequence numbers are monotonically increasing and set as packets are sent. I think you mean "strictly increasing". "Monotonically increasing" can (in some circles) mean "nondecreasing". 6.1: max-fr, max-fs These parameters MAY be used to signal the capabilities of a receiver implementation. These parameters MUST NOT be used for any other purpose. Putting MAY and MUST NOT like directives *inside* of the media type registration is a way to get them lost. They should be part of the spec. I suggest just moving the above to somewhere else in section 6. |
2013-07-17
|
09 | Pete Resnick | [Ballot Position Update] New position, No Objection, has been recorded for Pete Resnick |
2013-07-17
|
09 | Ted Lemon | [Ballot comment] In 4.1, in the caption for figure 1: The VP8 payload descriptor and VP8 payload header will be described in the … [Ballot comment] In 4.1, in the caption for figure 1: The VP8 payload descriptor and VP8 payload header will be described in the sequel. OPTIONAL RTP padding MUST NOT be included unless the P bit is set. What does "will be described in the sequel" mean? I looked for an antecedent earlier in the document, and was unable to locate one, and the word "sequel" never appears elsewhere in the document. I presume this is referring to some follow-on document or later section in the current document, but that isn't clear from the text. If by sequel you mean "sections 4.2 and 4.3" then you should just say that. If you are using xml2rfc you can reference a section as described here: http://xml.resource.org/xml2rfcFAQ.html#anchor17 If you are using something other than xml2rfc, I would just say "is described in the following two sections" or else refer to the sections by title. Also in 4.1: Timestamp: The RTP timestamp indicates the time when the frame was sampled at a clock rate of 90 kHz. Is the frame sometimes sampled at other clock rates? I suspect you mean something like this: Timestamp: The RTP timestamp indicates the time when the frame was sampled. The granularity of the clock is 90 kHz, so a value of 1 represents 1/90,000 of a second. Also, the definition of timestamp doesn't say what the timestamp is relative to. I think this would prevent interoperation, since absent any additional specification I can think of at least three times it could be relative to: the time the first packet was sent, the time since the beginning of the video at which the current frame occurs, or the time at which the preceding packet was sent. I was going to make this a DISCUSS, but on reading section 4.5, it looks like this is the time of the frame relative to the beginning of the video, and I suspect implementors will figure this out. However, I still think you ought to say explicitly. Also: Sequence number: The sequence numbers are monotonically increasing and set as packets are sent. Do you mean "set in the order that packets are sent"? At the beginning of 4.3: The beginning of an encoded VP8 frame is referred to as an "uncompressed data chunk" in [RFC6386], and co-serve as payload header in this RTP format. I guess Barry already hassled you about this; I found it equally puzzling. From 5.1: pictures. The positive feedback method is useful for VP8 used as unicast. The use of RPSI for VP8 is preferably combined with a I almost think I know what "VP8 used as unicast" means, but I'm probably wrong. Could you clarify this sentence? Here, First is the macroblock address (in scan order) of the first lost block and Number is the number of lost blocks. PictureID is the six least significant bits of the codec-specific picture identifier in which the loss or corruption has occurred. For VP8, this codec- specific identifier is naturally the PictureID of the current frame, What is a macroblock address? I suspect that this is a VP8-specific term, but it would help to say where the reader could find out more. Also, searching back through the document I notice that the second paragraph of the introduction talks about "decomposition of frames into square sub-blocks of pixels" and subsequently mentions macroblocks; are macroblocks these square sub-blocks of pixels? If so, you should say "square sub-blocks of pixels, called macroblocks," so that the reader can clearly see the connection, rather than having to infer it and be uncertain whether the inference is correct. In section 7: Integrity of the RTP packets through suitable cryptographic integrity protection mechanism. Where is the verb? Thanks for documenting this! |
2013-07-17
|
09 | Ted Lemon | [Ballot Position Update] New position, No Objection, has been recorded for Ted Lemon |
2013-07-16
|
09 | Joel Jaeggli | [Ballot Position Update] Position for Joel Jaeggli has been changed to Abstain from No Record |
2013-07-16
|
09 | Joel Jaeggli | [Ballot comment] This document would probably be fine were it not for the obvious problems citied in the genart review and the other discusses. imho … [Ballot comment] This document would probably be fine were it not for the obvious problems citied in the genart review and the other discusses. imho I have nothing more to add, I wouldn't object to the document were it actually ready. |
2013-07-16
|
09 | Joel Jaeggli | Ballot comment text updated for Joel Jaeggli |
2013-07-16
|
09 | Stewart Bryant | [Ballot comment] I am entering no objection on the basis of a short review which indicated no impact on the routing system. |
2013-07-16
|
09 | Stewart Bryant | [Ballot Position Update] New position, No Objection, has been recorded for Stewart Bryant |
2013-07-15
|
09 | Jari Arkko | [Ballot discuss] I cannot determine if the references are normative or not. Perhaps a change of the section title would be in order? Clearly some … [Ballot discuss] I cannot determine if the references are normative or not. Perhaps a change of the section title would be in order? Clearly some references are normative, but what about these, for instance: [RFC6386] Bankoski, J., Koleszar, J., Quillio, L., Salonen, J., Wilkins, P., and Y. Xu, "VP8 Data Format and Decoding Guide", RFC 6386, November 2011. [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type Specifications and Registration Procedures", BCP 13, RFC 6838, January 2013. |
2013-07-15
|
09 | Jari Arkko | [Ballot comment] See also the Gen-ART review from Elwyn Davies: s10: Are all of the refs normative? If so change the section title. The only … [Ballot comment] See also the Gen-ART review from Elwyn Davies: s10: Are all of the refs normative? If so change the section title. The only one which I am dubious about is RFC 4566 (and there is 6386 - see next comment). |
2013-07-15
|
09 | Jari Arkko | [Ballot Position Update] New position, Discuss, has been recorded for Jari Arkko |
2013-07-15
|
09 | Spencer Dawkins | [Ballot discuss] This discuss point should be easy to clear - there were just a couple of places that were too unclear for me to … [Ballot discuss] This discuss point should be easy to clear - there were just a couple of places that were too unclear for me to be confident that implementers would read them the same way. In 4.2. VP8 Payload Descriptor PictureID: 8 or 16 bits including the M bit. This is a running index of the frames. The field MUST be present if the I bit is equal to one. The 7 following bits carry (parts of) the PictureID. If the extension flag is one, the PictureID continues in the next octet forming a 15 bit index, where the 8 bits in the second octet are the least significant bits of the PictureID. If the extension flag is zero, there is no extension, and the PictureID is the 7 remaining bits of the first (and only) octet. The sender may choose 7 or 15 bits index. The PictureID SHOULD start on a random number, and MUST wrap after reaching the maximum ID. The receiver MUST NOT assume that the number of bits in PictureID stay the same through the session. Did I miss (or does everyone know) how to set the PictureID if you're using a 15-bit index, you have a current value that won't fit in 7 bits, and then the sender decides for whatever reason to start using 7-bit indexes? Should the receiver expect to see the lower 7 bits of the incremented 15-bit PictureID, a newly random 7-bit PictureID, 0, or "something else"? TL0PICIDX: 8 bits temporal level zero index. The field MUST be present if the L bit is equal to 1, and MUST NOT be present otherwise. TL0PICIDX is a running index for the temporal base layer frames, i.e., the frames with TID set to 0. If TID is larger than 0, TL0PICIDX indicates which base layer frame the current image depends on. TL0PICIDX MUST be incremented when TID is 0. The index SHOULD start on a random number, and MUST restart at 0 after reaching the maximum number 255. KEYIDX: 5 bits temporal key frame index. The TID/KEYIDX octet MUST be present when either the T bit or the K bit or both are equal to 1, and MUST NOT be present otherwise. The KEYIDX field MUST be ignored by the receiver when the K bit is set equal to 0. The KEYIDX field is a running index for key frames. KEYIDX MAY start on a random number, and MUST restart at 0 after reaching the maximum number 31. I'm not quite sure why PictureID says "MUST wrap" and TL0PICIDX and KEYIDX say "MUST restart at 0". Are these the same thing (I would have thought so, but I'm not the codec guy). If they are the same, and you could consider using one term or the other in the document, that would be great. If they aren't the same, please say more about that. |
2013-07-15
|
09 | Spencer Dawkins | [Ballot comment] In 4.4. Aggregated and Fragmented Payloads An encoded VP8 frame can be divided into two or more partitions, as described in … [Ballot comment] In 4.4. Aggregated and Fragmented Payloads An encoded VP8 frame can be divided into two or more partitions, as described in Section 1. One packet can contain a fragment of a partition, a complete partition, or an aggregate of fragments and partitions. In the preferred use case, the S bit and PID fields described in Section 4.2 should be used to indicate what the packet contains. The PID field should indicate which partition the first octet of the payload belongs to, and the S bit indicates that the packet starts on a new partition. I'm not bitching about 2119 lower-case "should"s, but I am wondering if this would be clearer if you just said "is used to indicate", etc. Even in the common English sense of the word, "should be used to" leaves the door open that the S bit and PID fields could be used to do something else. Same for PID field. In 4.5.1. Partition reconstruction algorithm 2: Continue scan to detect end of partition; hence a new S=1 (previous packet was the end of the partition) is found or the marker bit is set. If a loss it detected before the end of the ^^ "is detected", I think? but it's a nit. |
2013-07-15
|
09 | Spencer Dawkins | [Ballot Position Update] New position, Discuss, has been recorded for Spencer Dawkins |
2013-07-12
|
09 | Jean Mahoney | Request for Telechat review by GENART is assigned to Elwyn Davies |
2013-07-12
|
09 | Jean Mahoney | Request for Telechat review by GENART is assigned to Elwyn Davies |
2013-07-10
|
09 | Patrik Westin | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2013-07-10
|
09 | Patrik Westin | New version available: draft-ietf-payload-vp8-09.txt |
2013-07-09
|
08 | Barry Leiba | [Ballot discuss] Two points, highlighted below... From the shepherd writeup: There are a few ID nits. 1) Unused reference: RFC 3984 … [Ballot discuss] Two points, highlighted below... From the shepherd writeup: There are a few ID nits. 1) Unused reference: RFC 3984 2) Obsolete normative reference: RFC 4288 (Obsoleted by RFC 6838) 3) Downref: Normative reference to an Informational RFC: RFC 6386 Why weren't these fixed before the document went out for Last Call and then IESG Evaluation? I don't care about #1, but... On #2, it's not just that 4288 is an obsolete reference. It's that the template used in Section 6.1 is from 4288, and that template *changed* in 6838. These idnits warnings have a purpose: you're supposed to fix the reference *and* you're supposed to make sure that the new reference still applies, and make any necessary changes to the document. The template changed in 6838 ("Fragment identifier considerations" was added; there were a couple of other minor changes, but that's the important one). The shepherd writeup says, "The media subtype registration is compliant with the registration template (RFC 6838)." It is not. The procedure for media-type registrations also changed, but I don't think that affects this document. DISCUSS POINT 1: Please update the document with respect to RFC 6838. On #3, the downref was not called out in the Last Call message; that's required in order to support a downref, unless the referenced document is in the downref registry (which 6386 isn't). That means we'd need to re-run a two-week last call for that. DISCUSS POINT 2 (for the AD, not the authors): I think we need to re-run the Last Call for this document. |
2013-07-09
|
08 | Barry Leiba | [Ballot comment] I find a number of things in Section 4.2 to be confusing. These comments are non-blocking, but I think it would be a … [Ballot comment] I find a number of things in Section 4.2 to be confusing. These comments are non-blocking, but I think it would be a very good idea to do some clarification here: When the X bit is set to 1 in the first octet, the OPTIONAL extension bit field MUST be present in the second octet. If the X bit is 0, the extension bit field MUST NOT be present, and all bits below MUST be implicitly interpreted as 0. This is a very odd use of "OPTIONAL"; it's not optional at all. The value of the X bit specifies exactly what the state of the extension bit field has to be. The same is true for the I, L, T, and K fields, which also claim to be OPTIONAL. I'm not making this a DISCUSS, because I think the likelihood of actual misunderstanding is low, but I really think it's best to remove the "OPTIONAL"s, and to state instead that these fields might or might not be present, depending upon the values of the control bits. I also do not understand the last clause: what does "and all bits below MUST be implicitly interpreted as 0" mean? Wait, I think I get it: you mean, "and no extensions (I, L, T, or K) are permitted." Yes? Can you say it that way, or in some other, clearer way? M: The most significant bit of the first octet is an extension flag. The field MUST be present if the I bit is equal to one. If set the PictureID field MUST contain 16 bits else it MUST contain 8 bits including this MSB, see PictureID. This is a little disconnected: the second sentence makes the antecedent of the third sentence unclear. The third sentence appears to have something to do with the I bit. In fact, I think the whole explanation of the extension fields would be better off with each extension field clearly separated out. Something like this (if I may indulge in some suggested re-wording): ------------------- After the extension bit field follow the extension data fields that are enabled. The PictureID extension: If the I bit is set to one, the PictureID extension field MUST be present, and MUST NOT be present otherwise. The field consists of two parts: M: The most significant bit of the first octet is an extension flag. If M is set, the remainder of the PictureID field MUST contain 15 bits, else it MUST contain 7 bits. PictureID: 7 or 15 bits (not including the M bit). This is a running index of the frames, which SHOULD begin as a random number, MUST increase by 1 for each subsequent frame, and MUST wrap to 0 after reaching the maximum ID (all bits set). The 7 or 15 bits of the PictureID go from most significant to least significant, beginning with the first bit after the M bit. The sender chooses a 7 or 15 bit index and sets the M bit accordingly. The TL0PICIDX extension: If the I bit is set to one, the TL0PICIDX extension field MUST be present, and MUST NOT be present otherwise. The field consists of one part: TL0PICIDX: 8 bits temporal level zero index. TL0PICIDX is a running index for the temporal base layer frames, i.e., the frames with TID set to 0. If TID is larger than 0, TL0PICIDX indicates which base layer frame the current image depends on. TL0PICIDX MUST be incremented when TID is 0. The index SHOULD start on a random number, and MUST restart at 0 after reaching the maximum number 255. The TID/KEYIDX extension: ...etc... ------------------- -- Section 4.3 -- The beginning of an encoded VP8 frame is referred to as an "uncompressed data chunk" in [RFC6386], and co-serve as payload header in this RTP format. "co-serve"? What's that mean? |
2013-07-09
|
08 | Barry Leiba | [Ballot Position Update] New position, Discuss, has been recorded for Barry Leiba |
2013-07-09
|
08 | (System) | IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed |
2013-07-08
|
08 | Richard Barnes | State changed to IESG Evaluation from Waiting for AD Go-Ahead |
2013-07-08
|
08 | Richard Barnes | Placed on agenda for telechat - 2013-07-18 |
2013-07-08
|
08 | Richard Barnes | Ballot has been issued |
2013-07-08
|
08 | Richard Barnes | [Ballot Position Update] New position, Yes, has been recorded for Richard Barnes |
2013-07-08
|
08 | Richard Barnes | Created "Approve" ballot |
2013-06-20
|
08 | Tero Kivinen | Request for Last Call review by SECDIR Completed: Has Issues. Reviewer: Brian Weis. |
2013-06-18
|
08 | (System) | State changed to Waiting for AD Go-Ahead from In Last Call |
2013-06-11
|
08 | Pearl Liang | IESG/Authors/WG Chairs: IANA has reviewed draft-ietf-payload-vp8-08. Authors should review the comments and/or questions below. Please report any inaccuracies and respond to any questions as soon … IESG/Authors/WG Chairs: IANA has reviewed draft-ietf-payload-vp8-08. Authors should review the comments and/or questions below. Please report any inaccuracies and respond to any questions as soon as possible. We understand that, upon approval of this document, there is a single action which we must complete. In the Video Media Types registry located at: http://www.iana.org/assignments/media-types/video a new media type will be registered as follows: Type: VP8 Reference: [ RFC-to-be ] We understand that this is the only action required to be completed upon approval of this document. Note: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed. |
2013-06-11
|
08 | (System) | IANA Review state changed to IANA OK - Actions Needed from IANA - Review Needed |
2013-06-07
|
08 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Brian Weis |
2013-06-07
|
08 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Brian Weis |
2013-06-06
|
08 | Jean Mahoney | Request for Last Call review by GENART is assigned to Elwyn Davies |
2013-06-06
|
08 | Jean Mahoney | Request for Last Call review by GENART is assigned to Elwyn Davies |
2013-06-04
|
08 | Cindy Morgan | IANA Review state changed to IANA - Review Needed |
2013-06-04
|
08 | Cindy Morgan | The following Last Call announcement was sent out: From: The IESG To: IETF-Announce CC: Reply-To: ietf@ietf.org Sender: Subject: Last Call: (RTP Payload Format for VP8 … The following Last Call announcement was sent out: From: The IESG To: IETF-Announce CC: Reply-To: ietf@ietf.org Sender: Subject: Last Call: (RTP Payload Format for VP8 Video) to Proposed Standard The IESG has received a request from the Audio/Video Transport Payloads WG (payload) to consider the following document: - 'RTP Payload Format for VP8 Video' 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 2013-06-18. 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 memo describes an RTP payload format for the VP8 video codec. The payload format has wide applicability, as it supports applications from low bit-rate peer-to-peer usage, to high bit-rate video conferences. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-payload-vp8/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-payload-vp8/ballot/ The following IPR Declarations may be related to this I-D: http://datatracker.ietf.org/ipr/1622/ |
2013-06-04
|
08 | Cindy Morgan | State changed to In Last Call from Last Call Requested |
2013-06-04
|
08 | Richard Barnes | Last call was requested |
2013-06-04
|
08 | Richard Barnes | Ballot approval text was generated |
2013-06-04
|
08 | Richard Barnes | State changed to Last Call Requested from AD Evaluation |
2013-06-04
|
08 | Richard Barnes | Ballot writeup was changed |
2013-06-04
|
08 | Richard Barnes | Ballot writeup was generated |
2013-06-04
|
08 | Richard Barnes | Changed document writeup |
2013-06-04
|
08 | Richard Barnes | Last call announcement was generated |
2013-04-17
|
08 | Richard Barnes | State changed to AD Evaluation from Publication Requested |
2013-03-14
|
08 | Cindy Morgan | (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? Standards track as indicated in the title page header. (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 specifies the RTP payload format for the VP8 video codec. The VP8 codec supports various applications ranging from low-bitrate peer-to-peer to high-bitrate videoconferencing applications. Working Group Summary The WGLC process was run twice and bunch of comments were addressed in the latest version. After the second WGLC, there were some comments submitted by Cullen Jennings and one of the authors responded in the list. At this time, we are proceeding with publication request. If there are further comments, they can be submitted during the IETF LC. Document Quality The VP8 codec has been used in various applications (most notably by Google). Earlier versions of codec were used by Skype. The media subtype registration review was request on 11/28/2012. Personnel Ali Begen is the document shepherd. Robert Sparks is the responsible AD. (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 reviewed the latest version (-08) and there are no issues. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? Not at this point. (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. Nope. (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. None. (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. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. There is one IPR submission from Vidyo (IPR 1622). The WG did not have concerns about this IPR submission. (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? Several people reviewed this document, mostly who are interested in implementing this payload. There were no objections from the rest of the WG. (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.) Nope. (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. There are a few ID nits. 1) Unused reference: RFC 3984 2) Obsolete normative reference: RFC 4288 (Obsoleted by RFC 6838) 3) Downref: Normative reference to an Informational RFC: RFC 6386 There are also a few minor errors. For example, the subtype has 3 (not 2) optional parameters. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. Media subtype registration review was requested: http://www.ietf.org/mail-archive/web/media-types/current/msg00455.html (13) Have all references within this document been identified as either normative or informative? No, which means all references will be considered as "normative". (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? Nope. (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 downref to RFC 6386, which is the main RFC that describes the VP8 data format. That RFC is an informational one since it was an independent submission (not thru a WG). (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 changes to existing documents. (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). The media subtype registration is compliant with the registration template (RFC 6838). (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 IANA 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 considerations. |
2013-03-14
|
08 | Cindy Morgan | Note added 'Ali Begen (abegen@cisco.com) is the document shepherd.' |
2013-03-14
|
08 | Cindy Morgan | Intended Status changed to Proposed Standard |
2013-03-14
|
08 | Cindy Morgan | IESG process started in state Publication Requested |
2013-03-13
|
08 | Ali Begen | IETF WG state changed to Submitted to IESG for Publication from In WG Last Call |
2013-01-18
|
08 | Patrik Westin | New version available: draft-ietf-payload-vp8-08.txt |
2012-12-13
|
07 | Patrik Westin | New version available: draft-ietf-payload-vp8-07.txt |
2012-10-19
|
06 | Patrik Westin | New version available: draft-ietf-payload-vp8-06.txt |
2012-08-31
|
05 | Patrik Westin | New version available: draft-ietf-payload-vp8-05.txt |
2012-03-26
|
04 | Patrik Westin | New version available: draft-ietf-payload-vp8-04.txt |
2012-02-14
|
03 | Ali Begen | in WGLC. |
2012-02-14
|
03 | Ali Begen | IETF state changed to In WG Last Call from WG Document |
2012-01-24
|
03 | (System) | New version available: draft-ietf-payload-vp8-03.txt |
2011-11-17
|
02 | (System) | New version available: draft-ietf-payload-vp8-02.txt |
2011-10-05
|
(System) | Posted related IPR disclosure: Vidyo, Inc.'s Statement about IPR related to draft-ietf-payload-vp8-01 | |
2011-07-11
|
01 | (System) | New version available: draft-ietf-payload-vp8-01.txt |
2011-05-02
|
00 | (System) | New version available: draft-ietf-payload-vp8-00.txt |