Mapping RTP Streams to Controlling Multiple Streams for Telepresence (CLUE) Media Captures
draft-ietf-clue-rtp-mapping-14
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2020-11-16
|
14 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2020-07-28
|
14 | (System) | RFC Editor state changed to AUTH48 from AUTH48-DONE |
2020-07-20
|
14 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2020-07-06
|
14 | (System) | RFC Editor state changed to AUTH48 from RFC-EDITOR |
2020-03-16
|
14 | (System) | RFC Editor state changed to RFC-EDITOR from REF |
2020-02-13
|
14 | (System) | RFC Editor state changed to REF from EDIT |
2019-12-11
|
14 | (System) | RFC Editor state changed to EDIT from MISSREF |
2017-03-07
|
14 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2017-03-07
|
14 | (System) | IANA Action state changed to Waiting on RFC Editor from Waiting on Authors |
2017-03-03
|
14 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2017-03-03
|
14 | (System) | RFC Editor state changed to MISSREF |
2017-03-03
|
14 | (System) | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2017-03-03
|
14 | (System) | Announcement was received by RFC Editor |
2017-03-03
|
14 | (System) | IANA Action state changed to In Progress from On Hold |
2017-03-02
|
14 | (System) | IANA Action state changed to On Hold from In Progress |
2017-02-27
|
14 | (System) | IANA Action state changed to In Progress |
2017-02-27
|
14 | Cindy Morgan | IESG state changed to Approved-announcement sent from IESG Evaluation::AD Followup |
2017-02-27
|
14 | Cindy Morgan | IESG has approved the document |
2017-02-27
|
14 | Cindy Morgan | Closed "Approve" ballot |
2017-02-27
|
14 | Cindy Morgan | Ballot approval text was generated |
2017-02-27
|
14 | Cindy Morgan | Ballot writeup was changed |
2017-02-27
|
14 | Alissa Cooper | [Ballot comment] Magnus' review comments have been addressed. |
2017-02-27
|
14 | Alissa Cooper | [Ballot Position Update] Position for Alissa Cooper has been changed to Yes from Discuss |
2017-02-27
|
14 | Paul Kyzivat | Shepherd writeup for draft-ietf-clue-rtp-mapping-14: [This is based on the template version dated 24 February 2012.] (1) What type of RFC is being requested (BCP, … Shepherd writeup for draft-ietf-clue-rtp-mapping-14: [This is based on the template version dated 24 February 2012.] (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 document is marked as Standards Track in the title page header, and that is appropriate - it is defining required functionality for CLUE. (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 describes how the Real Time transport Protocol (RTP) is used in the context of the CLUE protocol (ControLling mUltiple streams for tElepresence). It also describes the mechanisms and recommended practice for mapping RTP media streams defined in Session Description Protocol (SDP) to CLUE Media Captures and defines a new RTP header extension (CaptureId). Working Group Summary Very late in the game we received substantial comments on this document from an RTP expert that had not been active in the work group. This led to some substantial revisions, primarily for alignment with other RTP-related documents. The primary effect was to remove a lot of text that was thought to be be confusing. Some tightening of language was also added to improve privacy. Document Quality Are there existing implementations of the protocol? A prototype implementation has been built and demonstrated. Have a significant number of vendors indicated their plan to implement the specification? Not yet. Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? Colin Perkins and Magnus Westerlund made major comments that resulted in better alignment of this document with other work. If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted? N/A Personnel Who is the Document Shepherd? Paul Kyzivat Who is the Responsible Area Director? Alissa Cooper (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. The shepherd has been an active reviewer of this document throughout its development, and reviewed it again in its entirety while preparing this writeup. In the view of this shepherd the document is ready for publication? YES. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No concerns. The document has been thoroughly reviewed. (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. N/A (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, each author has stated they have no IPR claims on the document. (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 has been filed against this document. (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? There is strong WG consensus for this document by all those who have actively participated in the group. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) No. (11) Identify any ID nits the Document Shepherd has found in this document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. There are no nits. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. N/A (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? There are normative references to several other CLUE drafts. The intent is that these will all progress together. There is also a normative reference to draft-ietf-mmusic-sdp-bundle-negotiation-36. That draft is itself near to completion. Waiting on it is acceptable. (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 are no downrefs. (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. This document doesn't change the status of any other document. (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 IANA considerations section is in good order. (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. N/A - no new registries are defined. (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. None. |
2017-02-27
|
14 | Roni Even | New version available: draft-ietf-clue-rtp-mapping-14.txt |
2017-02-27
|
14 | (System) | New version approved |
2017-02-27
|
14 | (System) | Request for posting confirmation emailed to previous authors: Jonathan Lennox , Roni Even |
2017-02-27
|
14 | Roni Even | Uploaded new revision |
2017-02-13
|
13 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2017-02-13
|
13 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA - Not OK |
2017-02-13
|
13 | Roni Even | New version available: draft-ietf-clue-rtp-mapping-13.txt |
2017-02-13
|
13 | (System) | New version approved |
2017-02-13
|
13 | (System) | Request for posting confirmation emailed to previous authors: "Roni Even" , "Jonathan Lennox" |
2017-02-13
|
13 | Roni Even | Uploaded new revision |
2017-01-19
|
12 | Cindy Morgan | IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation |
2017-01-19
|
12 | Cindy Morgan | Changed consensus to Yes from Unknown |
2017-01-19
|
12 | Ben Campbell | [Ballot comment] Thanks for addressing my DISCUSS point. I'm leaving the other comments below for posterity; I think most of them have been resolved. Substantive: … [Ballot comment] Thanks for addressing my DISCUSS point. I'm leaving the other comments below for posterity; I think most of them have been resolved. Substantive: -3: The opening paragraph mentions "Point-to-Point, as well as Media-Mixing mixers, Media- Switching mixers, and Selective Forwarding Middleboxs." The section goes on to discuss the first two, but doesn't mention the last two. -5, paragraph 4: "When the media provider switches the MC it sends within an MCC, it MUST send the captureID value for the MC just switched into the MCC." Does MUST send mean MUST send both in the RTP header and as an RTCP SDES item, as in the previous sentence? -5, paragraph 5: It would be helpful to add a sentence or two clarifying the difference between an MCC that carries multiple MCs at the same time, and one that switch between MCs, but only carry one at a time. Editorial: - 1, 2nd paragraph: Please expand SSRC on first use. -3, 2nd paragraph: Please expand SDES on first use. -- "specified in CLUE use case [RFC7205]" should that say "specified in the CLUE use case document [RFC7205]"? -- "described using MCC." missing article ("using an MCC." -3, third paragraph: "If needed by CLUE endpoint," Missing article. -4, 2nd paragraph: s/"slide video"/"side video" -6, first paragraph: s/"made by"/"made up of" ; or "comprises" -9, 2nd paragraph: Please don't use 2119 to describe requirements from other documents, unless in a direct quote (in quotation marks.) |
2017-01-19
|
12 | Ben Campbell | [Ballot Position Update] Position for Ben Campbell has been changed to Yes from Discuss |
2017-01-18
|
12 | Joel Jaeggli | [Ballot Position Update] New position, No Objection, has been recorded for Joel Jaeggli |
2017-01-18
|
12 | Alvaro Retana | [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana |
2017-01-18
|
12 | Jari Arkko | [Ballot comment] Points from Vijay's Gen-ART review seem to not yet have been taken into account. They should, while they are editorial, they made sense … [Ballot comment] Points from Vijay's Gen-ART review seem to not yet have been taken into account. They should, while they are editorial, they made sense at least to me. |
2017-01-18
|
12 | Jari Arkko | [Ballot Position Update] New position, No Objection, has been recorded for Jari Arkko |
2017-01-18
|
12 | Alissa Cooper | [Ballot discuss] Holding a DISCUSS pending the outcome of the discussion stemming from the DE's review. See https://www.ietf.org/mail-archive/web/clue/current/msg05066.html |
2017-01-18
|
12 | Alissa Cooper | [Ballot Position Update] Position for Alissa Cooper has been changed to Discuss from Yes |
2017-01-18
|
12 | Ben Campbell | [Ballot discuss] I plan to ballot "yes" for this, but there's an issue in section 9 that I think needs to be fixed first: In … [Ballot discuss] I plan to ballot "yes" for this, but there's an issue in section 9 that I think needs to be fixed first: In the second paragraph, the draft says "CLUE endpoints MUST support RTP/ SAVPF and DTLS-SRTP keying [RFC5764]." But the framework draft goes further by saying that media MUST be secured, and that DTLS-SRTP SHOULD be used unless the media is secured by some other mechanism. I think that readers will expect the mapping spec to be authoritative about that sort of thing. It's likely to be misleading to have it mention the requirement to support RTP/SAVPF and DTLS-SRTP without also mentioning the MUST be secured, SHOULD be used requirements. This can easily be fixed by mentioning the additional requirements and citing the framework. |
2017-01-18
|
12 | Ben Campbell | [Ballot comment] Substantive: -3: The opening paragraph mentions "Point-to-Point, as well as Media-Mixing mixers, Media- Switching mixers, and Selective Forwarding Middleboxs." The section goes … [Ballot comment] Substantive: -3: The opening paragraph mentions "Point-to-Point, as well as Media-Mixing mixers, Media- Switching mixers, and Selective Forwarding Middleboxs." The section goes on to discuss the first two, but doesn't mention the last two. -5, paragraph 4: "When the media provider switches the MC it sends within an MCC, it MUST send the captureID value for the MC just switched into the MCC." Does MUST send mean MUST send both in the RTP header and as an RTCP SDES item, as in the previous sentence? -5, paragraph 5: It would be helpful to add a sentence or two clarifying the difference between an MCC that carries multiple MCs at the same time, and one that switch between MCs, but only carry one at a time. Editorial: - 1, 2nd paragraph: Please expand SSRC on first use. -3, 2nd paragraph: Please expand SDES on first use. -- "specified in CLUE use case [RFC7205]" should that say "specified in the CLUE use case document [RFC7205]"? -- "described using MCC." missing article ("using an MCC." -3, third paragraph: "If needed by CLUE endpoint," Missing article. -4, 2nd paragraph: s/"slide video"/"side video" -6, first paragraph: s/"made by"/"made up of" ; or "comprises" -9, 2nd paragraph: Please don't use 2119 to describe requirements from other documents, unless in a direct quote (in quotation marks.) |
2017-01-18
|
12 | Ben Campbell | [Ballot Position Update] New position, Discuss, has been recorded for Ben Campbell |
2017-01-18
|
12 | Deborah Brungard | [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard |
2017-01-18
|
12 | Benoît Claise | [Ballot Position Update] New position, No Objection, has been recorded for Benoit Claise |
2017-01-17
|
12 | Terry Manderson | [Ballot Position Update] New position, No Objection, has been recorded for Terry Manderson |
2017-01-17
|
12 | Suresh Krishnan | [Ballot Position Update] New position, No Objection, has been recorded for Suresh Krishnan |
2017-01-17
|
12 | Amanda Baber | IANA Review state changed to IANA - Not OK from Version Changed - Review Needed |
2017-01-17
|
12 | Alia Atlas | [Ballot Position Update] New position, No Objection, has been recorded for Alia Atlas |
2017-01-17
|
12 | Stephen Farrell | [Ballot comment] - abstract: expanding CLUE (or avoiding the acronym) in the abstract would be better (some abstract readers won't have heard of CLUE before). … [Ballot comment] - abstract: expanding CLUE (or avoiding the acronym) in the abstract would be better (some abstract readers won't have heard of CLUE before). - section 9: I think the paragraph about RFC6562 should be reduced to the first sentence only. The rest, if it were correct (and I'm not sure), ought be part of an update to 6562. That's not just process-crap - I would expect the state of the art to change here and when it does then the right place to deal with that will be in an update to 6562. (And hey, it's been 5 years already since we did that, so maybe it'd be timely if someone re-checked the state of the art here?) This could have been, but is not a DISCUSS ballot, on the basis that if we do update 6562 then we could have that formally UPDATE this RFC, but requiring that we remember to do that seems worse than just leaving it to a putative 6562bis. (And again, could we find someone to re-check 6562 and perhaps consider if a BCP on the topic would be a worthwhile thing?) - Section 9 says: "In multi-party communication scenarios using RTP Middleboxes; this middleboxes are trusted to preserve the sessions' security." That is just wrong. The middleboxes may or may not be trusted (or even known to exist) by the parties to the call. What you should be saying is that those middleboxes are REQUIRED, by this protocol/spec, to not weaken security. (And this one is not a DISCUSS because the rest of the para mitigates the horrible first sentence;-) |
2017-01-17
|
12 | Stephen Farrell | [Ballot Position Update] New position, No Objection, has been recorded for Stephen Farrell |
2017-01-17
|
12 | Kathleen Moriarty | [Ballot Position Update] New position, No Objection, has been recorded for Kathleen Moriarty |
2017-01-17
|
12 | Alexey Melnikov | [Ballot Position Update] New position, No Objection, has been recorded for Alexey Melnikov |
2017-01-17
|
12 | Spencer Dawkins | [Ballot Position Update] New position, Yes, has been recorded for Spencer Dawkins |
2017-01-17
|
12 | Mirja Kühlewind | [Ballot comment] - I find the following sentence in the abstract rather confusing: „This document describes how the Real Time transport Protocol (RTP) is used … [Ballot comment] - I find the following sentence in the abstract rather confusing: „This document describes how the Real Time transport Protocol (RTP) is used in the context of the CLUE protocol.“ I would just start with the second sentence directly and potentially also mention that this doc defines a new RTP Header Extension for the mapping. - There is still some redundancy in this document that could be removed for more clarity. |
2017-01-17
|
12 | Mirja Kühlewind | [Ballot Position Update] New position, No Objection, has been recorded for Mirja Kühlewind |
2017-01-17
|
12 | Alissa Cooper | IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead |
2017-01-17
|
12 | Alissa Cooper | Ballot has been issued |
2017-01-17
|
12 | Alissa Cooper | [Ballot Position Update] New position, Yes, has been recorded for Alissa Cooper |
2017-01-17
|
12 | Alissa Cooper | Created "Approve" ballot |
2017-01-14
|
12 | Roni Even | New version available: draft-ietf-clue-rtp-mapping-12.txt |
2017-01-14
|
12 | (System) | New version approved |
2017-01-14
|
12 | (System) | Request for posting confirmation emailed to previous authors: "Roni Even" , "Jonathan Lennox" |
2017-01-14
|
12 | Roni Even | Uploaded new revision |
2017-01-14
|
11 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA - Not OK |
2017-01-14
|
11 | Roni Even | New version available: draft-ietf-clue-rtp-mapping-11.txt |
2017-01-14
|
11 | (System) | New version approved |
2017-01-14
|
11 | (System) | Request for posting confirmation emailed to previous authors: clue-chairs@ietf.org, "Jonathan Lennox" , "Roni Even" |
2017-01-14
|
11 | Roni Even | Uploaded new revision |
2017-01-12
|
10 | Tero Kivinen | Request for Last Call review by SECDIR Completed: Has Nits. Reviewer: Dan Harkins. |
2017-01-12
|
10 | (System) | IESG state changed to Waiting for AD Go-Ahead from In Last Call |
2017-01-10
|
10 | (System) | IANA Review state changed to IANA - Not OK from IANA - Review Needed |
2017-01-10
|
10 | Sabrina Tanamal | (Via drafts-lastcall-comment@iana.org): IESG/Authors/WG Chairs: The IANA Services Operator has completed its review of draft-ietf-clue-rtp-mapping-10.txt. If any part of this review is inaccurate, please let … (Via drafts-lastcall-comment@iana.org): IESG/Authors/WG Chairs: The IANA Services Operator has completed its review of draft-ietf-clue-rtp-mapping-10.txt. If any part of this review is inaccurate, please let us know. The IANA Services Operator understands that, upon approval of this document, there are two actions which we must complete. First, in the RTP SDES Compact Header Extensions subregistry of the Real-Time Transport Protocol (RTP) Parameters registry located at: https://www.iana.org/assignments/rtp-parameters/ a single, new header extension will be registered as follows: Extension URI: urn:ietf:params:rtp-hdrext:sdes:CaptureId Description: CLUE CaptureId Contact: roni.even@mail01.huawei.com Reference: [ RFC-to-be ] Because this registry requires Expert Review [RFC5226] for registration, we've contacted the IESG-designated expert in a separate ticket to request approval. Expert review should be completed before your document can be approved for publication as an RFC. Second, in the RTP SDES item types subregistry of the Real-Time Transport Protocol (RTP) Parameters registry located at: https://www.iana.org/assignments/rtp-parameters/ a single, new item type will be registered as follows: Value: [ TBD-at-registration ] Abbrev.: CCID Name: CLUE CaptureId Reference: [ RFC-to-be ] As this registry also requires Expert Review [RFC5226] for registration, we've contacted the IESG-designated expert in a separate ticket to request approval. Expert review should be completed before your document can be approved for publication as an RFC. The IANA Services Operator understands that these two actions are the only ones 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. Thank you, Sabrina Tanamal IANA Services Specialist PTI |
2017-01-03
|
10 | Jürgen Schönwälder | Request for Last Call review by OPSDIR Completed: Has Nits. Reviewer: Jürgen Schönwälder. Sent review to list. |
2016-12-29
|
10 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Dan Harkins |
2016-12-29
|
10 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Dan Harkins |
2016-12-24
|
10 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Jürgen Schönwälder |
2016-12-24
|
10 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Jürgen Schönwälder |
2016-12-23
|
10 | Vijay Gurbani | Request for Last Call review by GENART Completed: Ready with Nits. Reviewer: Vijay Gurbani. Sent review to list. |
2016-12-22
|
10 | Jean Mahoney | Request for Last Call review by GENART is assigned to Vijay Gurbani |
2016-12-22
|
10 | Jean Mahoney | Request for Last Call review by GENART is assigned to Vijay Gurbani |
2016-12-22
|
10 | Amy Vezza | IANA Review state changed to IANA - Review Needed |
2016-12-22
|
10 | Amy Vezza | The following Last Call announcement was sent out: From: The IESG To: "IETF-Announce" CC: draft-ietf-clue-rtp-mapping@ietf.org, clue@ietf.org, alissa@cooperw.in, pkyzivat@alum.mit.edu, "Paul Kyzivat" , … The following Last Call announcement was sent out: From: The IESG To: "IETF-Announce" CC: draft-ietf-clue-rtp-mapping@ietf.org, clue@ietf.org, alissa@cooperw.in, pkyzivat@alum.mit.edu, "Paul Kyzivat" , clue-chairs@ietf.org Reply-To: ietf@ietf.org Sender: Subject: Last Call: (Mapping RTP streams to CLUE Media Captures) to Proposed Standard The IESG has received a request from the ControLling mUltiple streams for tElepresence WG (clue) to consider the following document: - 'Mapping RTP streams to CLUE Media Captures' 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 2017-01-12. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document describes how the Real Time transport Protocol (RTP) is used in the context of the CLUE protocol. It also describes the mechanisms and recommended practice for mapping RTP media streams defined in SDP to CLUE Media Captures. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-clue-rtp-mapping/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-clue-rtp-mapping/ballot/ No IPR declarations have been submitted directly on this I-D. |
2016-12-22
|
10 | Amy Vezza | IESG state changed to In Last Call from Last Call Requested |
2016-12-22
|
10 | Alissa Cooper | Ballot writeup was changed |
2016-12-22
|
10 | Alissa Cooper | Placed on agenda for telechat - 2017-01-19 |
2016-12-22
|
10 | Alissa Cooper | Last call was requested |
2016-12-22
|
10 | Alissa Cooper | Ballot approval text was generated |
2016-12-22
|
10 | Alissa Cooper | Ballot writeup was generated |
2016-12-22
|
10 | Alissa Cooper | IESG state changed to Last Call Requested from AD Evaluation |
2016-12-22
|
10 | Alissa Cooper | Last call announcement was changed |
2016-12-22
|
10 | Alissa Cooper | IESG state changed to AD Evaluation from Publication Requested |
2016-12-16
|
10 | Paul Kyzivat | Shepherd writeup for draft-ietf-clue-rtp-mapping-10: [This is based on the template version dated 24 February 2012.] (1) What type of RFC is being requested (BCP, … Shepherd writeup for draft-ietf-clue-rtp-mapping-10: [This is based on the template version dated 24 February 2012.] (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 document is marked as Standards Track in the title page header, and that is appropriate - it is defining required functionality for CLUE. (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 describes how the Real Time transport Protocol (RTP) is used in the context of the CLUE protocol. It also describes the mechanisms and recommended practice for mapping RTP media streams defined in SDP to CLUE Media Captures. Working Group Summary Very late in the game we received substantial comments on this document from an RTP expert that had not been active in the work group. This led to some substantial revisions, primarily for alignment with other RTP-related documents. The primary effect was to remove a lot of text that was thought to be be confusing. Document Quality Are there existing implementations of the protocol? A prototype implementation has been built and demonstrated. Have a significant number of vendors indicated their plan to implement the specification? Not yet. Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? Colin Perkins made major comments that resulted in better alignment of this document with other work. If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted? N/A Personnel Who is the Document Shepherd? Paul Kyzivat Who is the Responsible Area Director? Alissa Cooper (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. The shepherd has been an active reviewer of this document throughout its development, and reviewed it again in its entirety while preparing this writeup. In the view of this shepherd the document is ready for publication? YES. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No concerns. The document has been well reviewed. (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. N/A (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, each author has stated they have no IPR claims on the document. (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 has been filed against this document. (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? There is strong WG consensus for this document by all those who have actively participated in the group. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) No. (11) Identify any ID nits the Document Shepherd has found in this document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. There are some references to outdated versions of drafts. Also, some unused references that arose due to text deletions in recent versions. These should be updated at time of publication. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. N/A (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? There are normative references to several other CLUE drafts. The intent is that these will all progress together. There is also a normative reference to draft-ietf-mmusic-sdp-bundle-negotiation-34. That draft is itself near to completion. Waiting on it is acceptable. (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 are no downrefs. (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. This document doesn't change the status of any other document. (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 IANA considerations section is in good order. (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. N/A - no new registries are defined. (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. None. |
2016-12-16
|
10 | Paul Kyzivat | IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up |
2016-12-16
|
10 | Paul Kyzivat | IESG state changed to Publication Requested from AD is watching |
2016-12-16
|
10 | Paul Kyzivat | Shepherd writeup for draft-ietf-clue-rtp-mapping-10: [This is based on the template version dated 24 February 2012.] (1) What type of RFC is being requested (BCP, … Shepherd writeup for draft-ietf-clue-rtp-mapping-10: [This is based on the template version dated 24 February 2012.] (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 document is marked as Standards Track in the title page header, and that is appropriate - it is defining required functionality for CLUE. (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 describes how the Real Time transport Protocol (RTP) is used in the context of the CLUE protocol. It also describes the mechanisms and recommended practice for mapping RTP media streams defined in SDP to CLUE Media Captures. Working Group Summary Very late in the game we received substantial comments on this document from an RTP expert that had not been active in the work group. This led to some substantial revisions, primarily for alignment with other RTP-related documents. The primary effect was to remove a lot of text that was thought to be be confusing. Document Quality Are there existing implementations of the protocol? A prototype implementation has been built and demonstrated. Have a significant number of vendors indicated their plan to implement the specification? Not yet. Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? Colin Perkins made major comments that resulted in better alignment of this document with other work. If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted? N/A Personnel Who is the Document Shepherd? Paul Kyzivat Who is the Responsible Area Director? Alissa Cooper (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. The shepherd has been an active reviewer of this document throughout its development, and reviewed it again in its entirety while preparing this writeup. In the view of this shepherd the document is ready for publication? YES. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No concerns. The document has been well reviewed. (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. N/A (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, each author has stated they have no IPR claims on the document. (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 has been filed against this document. (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? There is strong WG consensus for this document by all those who have actively participated in the group. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) No. (11) Identify any ID nits the Document Shepherd has found in this document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. There are some references to outdated versions of drafts. Also, some unused references that arose due to text deletions in recent versions. These should be updated at time of publication. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. N/A (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? There are normative references to several other CLUE drafts. The intent is that these will all progress together. There is also a normative reference to draft-ietf-mmusic-sdp-bundle-negotiation-34. That draft is itself near to completion. Waiting on it is acceptable. (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 are no downrefs. (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. This document doesn't change the status of any other document. (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 IANA considerations section is in good order. (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. N/A - no new registries are defined. (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. None. |
2016-11-13
|
10 | Roni Even | New version available: draft-ietf-clue-rtp-mapping-10.txt |
2016-11-13
|
10 | (System) | New version approved |
2016-11-13
|
10 | (System) | Request for posting confirmation emailed to previous authors: "Jonathan Lennox" , "Roni Even" |
2016-11-13
|
10 | Roni Even | Uploaded new revision |
2016-10-24
|
09 | Roni Even | New version available: draft-ietf-clue-rtp-mapping-09.txt |
2016-10-24
|
09 | (System) | New version approved |
2016-10-24
|
08 | (System) | Request for posting confirmation emailed to previous authors: "Jonathan Lennox" , "Roni Even" |
2016-10-24
|
08 | Roni Even | Uploaded new revision |
2016-09-15
|
08 | Alissa Cooper | IESG state changed to AD is watching from AD Evaluation::AD Followup |
2016-08-29
|
08 | Alissa Cooper | IESG state changed to AD Evaluation::AD Followup from AD Evaluation |
2016-08-27
|
08 | Roni Even | New version available: draft-ietf-clue-rtp-mapping-08.txt |
2016-08-26
|
07 | Alissa Cooper | IESG state changed to AD Evaluation from Publication Requested |
2016-08-24
|
07 | Paul Kyzivat | Tag Revised I-D Needed - Issue raised by WGLC set. |
2016-08-24
|
07 | Paul Kyzivat | IETF WG state changed to WG Consensus: Waiting for Write-Up from Submitted to IESG for Publication |
2016-08-24
|
07 | Paul Kyzivat | Shepherd writeup for draft-ietf-clue-rtp-mapping-07: [This is based on the template version dated 24 February 2012.] (1) What type of RFC is being requested (BCP, … Shepherd writeup for draft-ietf-clue-rtp-mapping-07: [This is based on the template version dated 24 February 2012.] (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 document is marked as Standards Track in the title page header, and that is appropriate - it is defining required functionality for CLUE. (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 describes how the Real Time transport Protocol (RTP) is used in the context of the CLUE protocol. It also describes the mechanisms and recommended practice for mapping RTP media streams defined in SDP to CLUE Media Captures. Working Group Summary Nothing of particular note occurred during the development of this document. Document Quality Are there existing implementations of the protocol? A prototype implementation has been built and demonstrated. Have a significant number of vendors indicated their plan to implement the specification? Not yet. Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? None that stand out. If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted? N/A Personnel Who is the Document Shepherd? Paul Kyzivat Who is the Responsible Area Director? Alissa Cooper (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. The shepherd has been an active reviewer of this document throughout its development, and reviewed it again in its entirety while preparing this writeup. In the view of this shepherd the document is ready for publication. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No concerns. The document has been well reviewed. (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. N/A (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, each author has stated they have no IPR claims on the document. (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 has been filed against this document. (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? There is strong WG consensus for this document by all those who have actively participated in the group. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) No. (11) Identify any ID nits the Document Shepherd has found in this document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. There are some references to outdated versions of drafts. They should be updated at time of publication. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. N/A (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? There are normative references to several other CLUE drafts. The intent is that these will all progress together. There is also a normative reference to draft-ietf-mmusic-sdp-bundle-negotiation-24. That draft is itself near to completion. Waiting on it is acceptable. (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 are no downrefs. (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. This document doesn't change the status of any other document. (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 IANA considerations section is in good order. (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. N/A - no new registries are defined. (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. None. |
2016-08-24
|
07 | Paul Kyzivat | Responsible AD changed to Alissa Cooper |
2016-08-24
|
07 | Paul Kyzivat | IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up |
2016-08-24
|
07 | Paul Kyzivat | IESG state changed to Publication Requested |
2016-08-24
|
07 | Paul Kyzivat | IESG process started in state Publication Requested |
2016-08-24
|
07 | Paul Kyzivat | Tag Revised I-D Needed - Issue raised by WGLC cleared. |
2016-08-24
|
07 | Paul Kyzivat | IETF WG state changed to WG Consensus: Waiting for Write-Up from Waiting for WG Chair Go-Ahead |
2016-08-24
|
07 | Paul Kyzivat | Changed document writeup |
2016-08-08
|
07 | Roni Even | Notification list changed to "Paul Kyzivat" <pkyzivat@alum.mit.edu> |
2016-08-08
|
07 | Roni Even | Document shepherd changed to Paul Kyzivat |
2016-06-06
|
07 | Daniel Burnett | Just need quick rev from authors to address Paul Kyzivat's comments. |
2016-06-06
|
07 | Daniel Burnett | Tag Revised I-D Needed - Issue raised by WGLC set. |
2016-06-06
|
07 | Daniel Burnett | IETF WG state changed to Waiting for WG Chair Go-Ahead from In WG Last Call |
2016-05-21
|
07 | Daniel Burnett | Restarting WGLC for further review. |
2016-05-14
|
07 | Roni Even | New version available: draft-ietf-clue-rtp-mapping-07.txt |
2016-03-08
|
06 | Daniel Burnett | WGLC to end 18 March 2016. |
2016-03-08
|
06 | Daniel Burnett | IETF WG state changed to In WG Last Call from WG Document |
2016-01-17
|
06 | Roni Even | New version available: draft-ietf-clue-rtp-mapping-06.txt |
2015-10-18
|
05 | Roni Even | New version available: draft-ietf-clue-rtp-mapping-05.txt |
2015-10-14
|
04 | (System) | Notify list changed from "Daniel C. Burnett" to (None) |
2015-04-10
|
04 | Roni Even | Notification list changed to "Daniel C. Burnett" <danielcburnett@gmail.com> |
2015-04-10
|
04 | Roni Even | Document shepherd changed to Daniel C. Burnett |
2015-03-08
|
04 | Roni Even | New version available: draft-ietf-clue-rtp-mapping-04.txt |
2014-10-18
|
03 | Roni Even | New version available: draft-ietf-clue-rtp-mapping-03.txt |
2014-07-22
|
02 | Roni Even | New version available: draft-ietf-clue-rtp-mapping-02.txt |
2013-10-22
|
01 | Mary Barnes | Intended Status changed to Proposed Standard from None |
2013-10-21
|
01 | Roni Even | New version available: draft-ietf-clue-rtp-mapping-01.txt |
2013-02-17
|
00 | Roni Even | New version available: draft-ietf-clue-rtp-mapping-00.txt |