WebRTC MediaStream Identification in the Session Description Protocol
draft-ietf-mmusic-msid-17
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2020-09-16
|
17 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2020-07-13
|
17 | (System) | RFC Editor state changed to AUTH48 from RFC-EDITOR |
2020-03-16
|
17 | (System) | RFC Editor state changed to RFC-EDITOR from REF |
2019-10-22
|
17 | (System) | RFC Editor state changed to REF from EDIT |
2019-08-16
|
17 | (System) | RFC Editor state changed to EDIT from MISSREF |
2019-08-15
|
17 | (System) | RFC Editor state changed to MISSREF from EDIT |
2019-08-15
|
17 | (System) | RFC Editor state changed to EDIT from MISSREF |
2018-12-13
|
17 | Harald Alvestrand | New version available: draft-ietf-mmusic-msid-17.txt |
2018-12-13
|
17 | (System) | New version approved |
2018-12-13
|
17 | (System) | Request for posting confirmation emailed to previous authors: Harald Alvestrand |
2018-12-13
|
17 | Harald Alvestrand | Uploaded new revision |
2017-02-07
|
16 | Harald Alvestrand | New version available: draft-ietf-mmusic-msid-16.txt |
2017-02-07
|
16 | (System) | New version approved |
2017-02-07
|
16 | (System) | Request for posting confirmation emailed to previous authors: "Harald Alvestrand" |
2017-02-07
|
16 | Harald Alvestrand | Uploaded new revision |
2016-07-14
|
15 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2016-07-13
|
15 | (System) | IANA Action state changed to Waiting on RFC Editor from Waiting on Authors |
2016-07-13
|
15 | (System) | IANA Action state changed to Waiting on Authors |
2016-07-12
|
15 | (System) | RFC Editor state changed to MISSREF |
2016-07-12
|
15 | (System) | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2016-07-12
|
15 | (System) | Announcement was received by RFC Editor |
2016-07-12
|
15 | (System) | IANA Action state changed to In Progress |
2016-07-12
|
15 | Cindy Morgan | IESG state changed to Approved-announcement sent from IESG Evaluation::AD Followup |
2016-07-12
|
15 | Cindy Morgan | IESG has approved the document |
2016-07-12
|
15 | Cindy Morgan | Closed "Approve" ballot |
2016-07-12
|
15 | Cindy Morgan | Ballot approval text was generated |
2016-07-12
|
15 | Ben Campbell | Ballot approval text was generated |
2016-07-07
|
15 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2016-07-07
|
15 | Harald Alvestrand | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2016-07-07
|
15 | Harald Alvestrand | New version available: draft-ietf-mmusic-msid-15.txt |
2016-06-24
|
14 | Stephen Farrell | [Ballot comment] My old discuss text was: START I'm not sure that the answer to this question will require any change to the document but … [Ballot comment] My old discuss text was: START I'm not sure that the answer to this question will require any change to the document but wanted to check... I wondered about the privacy properties of these (and related) WebRTC identifiers, esp. if they are being handled at various different layers. Is there work somewhere in the WebRTC space that's analysing that? For example, one concern might be that msid-appdata could end up with some kind of privacy sensitive value, but there's no guidance here about that and as the examples use UUIDs it's not clear to me those represent nor what typical values will be used. (Note: I'm not saying that I believe this is a problem, I'm just checking if it's been considered.) I hope that there's no reason why these can't be very ephemeral values that don't identify (or help re-identification of) people or their preferences, locations etc., and I'd imagine there's little reason to e.g. log them. If that's the case wouldn't it be useful to add such guidance (somewhere, maybe not here) to help developers to do the right thing? END Alissa suggested: I wonder if adding a reference to https://www.w3.org/TR/mediacapture-streams/#dom-mediastream-id or parroting that guidance would help. And in response to a mail from Harald I then said: Given that the W3C document has the details, I've cleared the discuss. I do think it'd be good to at least have a reference to that as Alissa suggested and perhaps to also re-iterate a bit of the advice about avoiding fingerprinting perhaps. |
2016-06-24
|
14 | Stephen Farrell | [Ballot Position Update] Position for Stephen Farrell has been changed to No Objection from Discuss |
2016-06-16
|
14 | Cindy Morgan | IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation |
2016-06-16
|
14 | Stephen Farrell | [Ballot discuss] I'm not sure that the answer to this question will require any change to the document but wanted to check... I wondered about … [Ballot discuss] I'm not sure that the answer to this question will require any change to the document but wanted to check... I wondered about the privacy properties of these (and related) WebRTC identifiers, esp. if they are being handled at various different layers. Is there work somewhere in the WebRTC space that's analysing that? For example, one concern might be that msid-appdata could end up with some kind of privacy sensitive value, but there's no guidance here about that and as the examples use UUIDs it's not clear to me those represent nor what typical values will be used. (Note: I'm not saying that I believe this is a problem, I'm just checking if it's been considered.) I hope that there's no reason why these can't be very ephemeral values that don't identify (or help re-identification of) people or their preferences, locations etc., and I'd imagine there's little reason to e.g. log them. If that's the case wouldn't it be useful to add such guidance (somewhere, maybe not here) to help developers to do the right thing? |
2016-06-16
|
14 | Stephen Farrell | [Ballot Position Update] New position, Discuss, has been recorded for Stephen Farrell |
2016-06-15
|
14 | Cindy Morgan | Changed consensus to Yes from Unknown |
2016-06-15
|
14 | Jari Arkko | [Ballot Position Update] New position, No Objection, has been recorded for Jari Arkko |
2016-06-15
|
14 | Deborah Brungard | [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard |
2016-06-15
|
14 | Kathleen Moriarty | [Ballot Position Update] New position, No Objection, has been recorded for Kathleen Moriarty |
2016-06-15
|
14 | Alia Atlas | [Ballot Position Update] New position, No Objection, has been recorded for Alia Atlas |
2016-06-14
|
14 | Terry Manderson | [Ballot Position Update] New position, No Objection, has been recorded for Terry Manderson |
2016-06-14
|
14 | Spencer Dawkins | [Ballot Position Update] New position, Yes, has been recorded for Spencer Dawkins |
2016-06-14
|
14 | Alvaro Retana | [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana |
2016-06-14
|
14 | Suresh Krishnan | [Ballot Position Update] New position, No Objection, has been recorded for Suresh Krishnan |
2016-06-14
|
14 | Amanda Baber | IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed |
2016-06-14
|
14 | Benoît Claise | [Ballot comment] No sure the following is useful information: This document is a work item of the MMUSIC WG, whose discussion list is … [Ballot comment] No sure the following is useful information: This document is a work item of the MMUSIC WG, whose discussion list is mmusic@ietf.org. First time I see this in an abstract. |
2016-06-14
|
14 | Benoît Claise | Ballot comment text updated for Benoit Claise |
2016-06-14
|
14 | Benoît Claise | [Ballot Position Update] New position, No Objection, has been recorded for Benoit Claise |
2016-06-14
|
14 | Alissa Cooper | [Ballot comment] = Section 2 = OLD Multiple media descriptions with the same value for msid-id and msid- appdata is not permitted. NEW Multiple … [Ballot comment] = Section 2 = OLD Multiple media descriptions with the same value for msid-id and msid- appdata is not permitted. NEW Multiple media descriptions with the same combination of msid-id and msid- appdata are not permitted. = Section 3 = s/and when the corresponding media description is disabled/or when the corresponding media description is disabled/ |
2016-06-14
|
14 | Alissa Cooper | [Ballot Position Update] New position, Yes, has been recorded for Alissa Cooper |
2016-06-14
|
14 | Joel Jaeggli | [Ballot comment] Susan Hares performed the opsdir review. Copied here for completeness as it hasn't been addressed yet. --- I have reviewed this document as … [Ballot comment] Susan Hares performed the opsdir review. Copied here for completeness as it hasn't been addressed yet. --- I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written with the intent of improving the operational aspects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review. Document editors and WG chairs should treat these comments just like any other last call comments. Status: Almost ready to go, 2 minor concerns, NIT General comment: Document and concept are generally clear. Thank you for providing a simple solution to this problem. Caveat: My expertise is at lower end of the stack. I cross referenced all the WebRTC documentation, but I’ve missed how implementations provide feedback that this protocols is up and working. Therefore, I’ve indicated the operational issues as a set of questions for the authors to consider. Minor concern: 1) Error handling: Is it possible that the msid-value, msid-id, and msid-appdata can be inserted, and then received with values that are not valid (1*64token-char]? a. If so, an error sequence is necessary. b. If not, it is important to explain why not Add section to 3.2 2) Operational issues: A few questions for your to consider to provide the link to operational issues. Normal operational: How does the person who is utilizing this protocol in WebRTC situation check the status of the protocols? Is it part of the WebRTC status information that the implementations provide? If so, is there any common management parameters that you can suggest? Is this in another document in IETF or W3C? Error operations: If you can have errors, how does the person who utilizes this protocol in WebRTC find out the error rate. Again, is it part of the WebRTC status information on errors? Is it in another document W3C? Editorial NITS: Page 7, section 3.1 Paragraph 2: double “,” in the section highlighted makes this sentence’s meaning unclear. Are these two sub-thoughts? If not two sub-thoughts, then perhaps the /new/ suggested text. When MSID is used, the only time this can happen is when, at a time subsequent to the initial negotiation, a negotiation is performed where the answerer adds a MediaStreamTrack to an already established connection and starts sending data before the answer is received by the offerer. For initial negotiation, packets won't flow until the ICE candidates and fingerprints have been exchanged, so this is not an issue. /new suggested/ When MSID is used, the only time this can happen is at a time subsequent to the initial negotiation, / Paragraph 3 Pagination makes the following text difficult. Repagination in /new/ may help. Or it may highlight where I was confused by your document. /old/ The recipient of those packets will perform the following steps: o When RTP packets are initially received, it will create an appropriate MediaStreamTrack based on the type of the media (carried in PayloadType), and use the MID RTP header extension [I-D.ietf-mmusic-sdp-bundle-negotiation] (if present) to associate the RTP packets with a specific media section. If the connection is not in the RTCSignalingState "stable", it will wait at this point. o When the connection is in the RTCSignalingState "stable", it will look at the relevant media section to find the msid attribute. o If there is an msid attribute, it will use that attribute to populate the "id" field of the MediaStreamTrack and associated MediaStreams, as described above. o If there is no msid attribute, the identifier of the MediaStreamTrack will be set to a randomly generated string, and it will be signalled as being part of a MediaStream with the WebIDL "label" attribute set to "Non-WebRTC stream". o After deciding on the "id" field to be applied to the MediaStreamTrack, the track will be signalled to the user. / /new/ The recipient of those packets will perform the following steps: o When RTP packets are initially received, it will create an appropriate MediaStreamTrack based on the type of the media (carried in PayloadType), and use the MID RTP header extension [I-D.ietf-mmusic-sdp-bundle-negotiation] (if present) to associate the RTP packets with a specific media section. - If the connection is not in the RTCSignalingState "stable", it will wait at this point. - When the connection is in the RTCSignalingState "stable", it will look at the relevant media section to find the msid attribute. · Looking a Media section: o If there is an msid attribute, it will use that attribute to populate the "id" field of the MediaStreamTrack and associated MediaStreams, as described above. o If there is no msid attribute, the identifier of the MediaStreamTrack will be set to a randomly generated string, and it will be signalled as being part of a MediaStream with the WebIDL "label" attribute set to "Non-WebRTC stream". o After deciding on the "id" field to be applied to the MediaStreamTrack, the track will be signalled to the user. / _______________________________________________ OPS-DIR mailing list OPS-DIR@ietf.org https://www.ietf.org/mailman/listinfo/ops-dir |
2016-06-14
|
14 | Joel Jaeggli | [Ballot Position Update] New position, No Objection, has been recorded for Joel Jaeggli |
2016-06-13
|
14 | Gunter Van de Velde | Request for Last Call review by OPSDIR Completed: Has Issues. Reviewer: Susan Hares. |
2016-06-13
|
14 | Mirja Kühlewind | [Ballot Position Update] New position, No Objection, has been recorded for Mirja Kühlewind |
2016-06-11
|
14 | Alexey Melnikov | [Ballot Position Update] New position, No Objection, has been recorded for Alexey Melnikov |
2016-06-10
|
14 | Ben Campbell | [Ballot comment] I made some editorial comments in my AD evaluation[1] that have not yet been addressed due to an email misconnect. There are no … [Ballot comment] I made some editorial comments in my AD evaluation[1] that have not yet been addressed due to an email misconnect. There are no showstoppers there, so I'd like to move this along in parallel. [1] https://mailarchive.ietf.org/arch/msg/mmusic/KejxusGmZxF6IcEyKmlftpQqosw |
2016-06-10
|
14 | Ben Campbell | Ballot comment text updated for Ben Campbell |
2016-06-10
|
14 | Ben Campbell | Placed on agenda for telechat - 2016-06-16 |
2016-06-10
|
14 | Ben Campbell | IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead::AD Followup |
2016-06-10
|
14 | Ben Campbell | Ballot has been issued |
2016-06-10
|
14 | Ben Campbell | [Ballot Position Update] New position, Yes, has been recorded for Ben Campbell |
2016-06-10
|
14 | Ben Campbell | Created "Approve" ballot |
2016-06-10
|
14 | Ben Campbell | Ballot approval text was generated |
2016-06-06
|
14 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2016-06-06
|
14 | Harald Alvestrand | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2016-06-06
|
14 | Harald Alvestrand | New version available: draft-ietf-mmusic-msid-14.txt |
2016-05-25
|
13 | Ben Campbell | IESG state changed to Waiting for AD Go-Ahead::Revised I-D Needed from Waiting for AD Go-Ahead |
2016-05-25
|
13 | Matthew Miller | Request for Last Call review by GENART Completed: Ready with Nits. Reviewer: Matthew Miller. |
2016-05-24
|
13 | (System) | IESG state changed to Waiting for AD Go-Ahead from In Last Call |
2016-05-23
|
13 | Sabrina Tanamal | IANA Review state changed to IANA OK - Actions Needed from IANA - Not OK |
2016-05-23
|
13 | (System) | IANA Review state changed to IANA - Not OK from IANA - Review Needed |
2016-05-23
|
13 | Sabrina Tanamal | (Via drafts-lastcall-comment@iana.org): IESG/Authors/WG Chairs: IANA has completed its review of draft-ietf-mmusic-msid-13.txt. If any part of this review is inaccurate, please let us know. IANA … (Via drafts-lastcall-comment@iana.org): IESG/Authors/WG Chairs: IANA has completed its review of draft-ietf-mmusic-msid-13.txt. If any part of this review is inaccurate, please let us know. IANA understands that, upon approval of this document, there is a single action which IANA must complete. In the att-field (media level only) subregistry of the Session Description Protocol (SDP) Parameters registry located at: https://www.iana.org/assignments/sdp-parameters/ a single new attribute is to be registered as follows: Type: att-field (media level only) SDP Name: msid Reference: [ RFC-to-be ] As this document requests registrations in an Expert Review or Specification Required (see RFC 5226) registry, we will initiate the required Expert Review via a separate request. Expert review will need to be completed before your document can be approved for publication as an RFC. 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. Thank you, Sabrina Tanamal IANA Specialist ICANN |
2016-05-19
|
13 | Tero Kivinen | Request for Last Call review by SECDIR Completed: Ready. Reviewer: Rifaat Shekh-Yusef. |
2016-05-16
|
13 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Susan Hares |
2016-05-16
|
13 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Susan Hares |
2016-05-13
|
13 | Peter Yee | Request for Last Call review by GENART is assigned to Matthew Miller |
2016-05-13
|
13 | Peter Yee | Request for Last Call review by GENART is assigned to Matthew Miller |
2016-05-12
|
13 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Rifaat Shekh-Yusef |
2016-05-12
|
13 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Rifaat Shekh-Yusef |
2016-05-10
|
13 | Amy Vezza | IANA Review state changed to IANA - Review Needed |
2016-05-10
|
13 | Amy Vezza | The following Last Call announcement was sent out: From: The IESG To: "IETF-Announce" CC: fandreas@cisco.com, ben@nostrum.com, draft-ietf-mmusic-msid@ietf.org, mmusic@ietf.org, mmusic-chairs@ietf.org Reply-To: ietf@ietf.org … The following Last Call announcement was sent out: From: The IESG To: "IETF-Announce" CC: fandreas@cisco.com, ben@nostrum.com, draft-ietf-mmusic-msid@ietf.org, mmusic@ietf.org, mmusic-chairs@ietf.org Reply-To: ietf@ietf.org Sender: Subject: Last Call: (WebRTC MediaStream Identification in the Session Description Protocol) to Proposed Standard The IESG has received a request from the Multiparty Multimedia Session Control WG (mmusic) to consider the following document: - 'WebRTC MediaStream Identification in the Session Description Protocol' 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 2016-05-24. 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 specifies a Session Description Protocol (SDP) Grouping mechanism for RTP media streams that can be used to specify relations between media streams. This mechanism is used to signal the association between the SDP concept of "media description" and the WebRTC concept of "MediaStream" / "MediaStreamTrack" using SDP signaling. This document is a work item of the MMUSIC WG, whose discussion list is mmusic@ietf.org. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-mmusic-msid/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-mmusic-msid/ballot/ No IPR declarations have been submitted directly on this I-D. |
2016-05-10
|
13 | Amy Vezza | IESG state changed to In Last Call from Last Call Requested |
2016-05-10
|
13 | Ben Campbell | Last call was requested |
2016-05-10
|
13 | Ben Campbell | IESG state changed to Last Call Requested from AD Evaluation |
2016-05-10
|
13 | Ben Campbell | Last call announcement was generated |
2016-05-10
|
13 | Ben Campbell | Last call announcement was generated |
2016-05-10
|
13 | Ben Campbell | Ballot writeup was changed |
2016-05-10
|
13 | Ben Campbell | Ballot writeup was generated |
2016-05-10
|
13 | Ben Campbell | Ballot approval text was generated |
2016-05-09
|
13 | Ben Campbell | IESG state changed to AD Evaluation from Publication Requested |
2016-04-28
|
13 | Flemming Andreasen | As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated … As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated 24 February 2012. (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? Proposed Standard. The title page has an intended status of "Standards Track". (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 Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction. This document specifies a Session Description Protocol (SDP) Grouping mechanism for RTP media streams that can be used to specify relations between media streams. This mechanism is used to signal the association between the SDP concept of "media description" and the WebRTC concept of "MediaStream" / "MediaStreamTrack" using SDP signaling. Working Group Summary Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? The document has undergone a number of revisions. Originally, it was believed the mechansim was more generally applicable than WebRTC. As the work progressed, the general applicability became increasingly unclear and a resulting reduction in scope and significant simplication resulted. The WG is fully supportive of this. Document Quality Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? 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? 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? Chrome implements an earlier version of the specification and is committed to implementing the specified version at a later stage. There are no special reviewers or other expert reviews of the document. Personnel Who is the Document Shepherd? Who is the Responsible Area Director? Flemming Andreasen is the document shepherd and Ben Campbell is the responsible Area Director (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. As the document shepherd, I have reviewed multiple versions of the document, including the current one. The document has been reviewed at a technical level as well as the usual nits checks, etc. 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? Different versions of the document has seen reviews by a decent number of people, which ultimately resulted in the simplified document we currently have. This version of the document has been reviewed by a couple of people. The reviews have been fairly detailed, but more reviewers would obviously have been desirable. (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. Not applicable (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. There are no such concerns or issues. (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why. The author has confirmed. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. There are no IPR disclosures for 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? The document has seen solid discussion and review through its lifetime in the WG and as such there is good WG support and consensus behind it. (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.) Not applicable. (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 a few warnings about I-D references that are not up-to-date - they can simply be updated during the publication process. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. No such reviews are required. The document merely defines an extension to SDP. (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 two references to draft documents: 1) draft-ietf-mmusic-sdp-mux-attributes has been submitted to the IESG for publication 2) draft-ietf-rtcweb-jsep is being worked on by RTCWeb. The RTCWeb chairs do not have an estimated publication request date for this document. (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. Not applicable. (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 change to existing RFCs (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). I have reviewed the IANA considerations, which register the SDP extension in accordance with the requirements of RFC 4566. (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. Not applicable. (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. The document contains a few lines of ABNF which have been verified with Bill Fenner's ABNF parser. |
2016-04-28
|
13 | Flemming Andreasen | Responsible AD changed to Ben Campbell |
2016-04-28
|
13 | Flemming Andreasen | IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up |
2016-04-28
|
13 | Flemming Andreasen | IESG state changed to Publication Requested |
2016-04-28
|
13 | Flemming Andreasen | IESG process started in state Publication Requested |
2016-04-28
|
13 | Flemming Andreasen | Changed document writeup |
2016-04-05
|
13 | Harald Alvestrand | New version available: draft-ietf-mmusic-msid-13.txt |
2016-03-18
|
12 | Harald Alvestrand | New version available: draft-ietf-mmusic-msid-12.txt |
2015-10-16
|
11 | Flemming Andreasen | Intended Status changed to Proposed Standard from None |
2015-10-15
|
11 | Flemming Andreasen | IETF WG state changed to WG Consensus: Waiting for Write-Up from WG Document |
2015-10-14
|
11 | (System) | Notify list changed from "Flemming Andreasen" to (None) |
2015-10-06
|
11 | Flemming Andreasen | Notification list changed to "Flemming Andreasen" <fandreas@cisco.com> |
2015-10-06
|
11 | Flemming Andreasen | Document shepherd changed to Flemming Andreasen |
2015-10-01
|
11 | Harald Alvestrand | New version available: draft-ietf-mmusic-msid-11.txt |
2015-04-28
|
10 | Harald Alvestrand | New version available: draft-ietf-mmusic-msid-10.txt |
2015-04-21
|
09 | Harald Alvestrand | New version available: draft-ietf-mmusic-msid-09.txt |
2015-02-11
|
08 | Harald Alvestrand | New version available: draft-ietf-mmusic-msid-08.txt |
2014-10-14
|
07 | Harald Alvestrand | New version available: draft-ietf-mmusic-msid-07.txt |
2014-06-09
|
06 | Harald Alvestrand | New version available: draft-ietf-mmusic-msid-06.txt |
2014-03-06
|
05 | Harald Alvestrand | New version available: draft-ietf-mmusic-msid-05.txt |
2014-02-13
|
04 | Harald Alvestrand | New version available: draft-ietf-mmusic-msid-04.txt |
2014-01-06
|
03 | Harald Alvestrand | New version available: draft-ietf-mmusic-msid-03.txt |
2013-11-05
|
02 | Harald Alvestrand | New version available: draft-ietf-mmusic-msid-02.txt |
2013-08-13
|
01 | Harald Alvestrand | New version available: draft-ietf-mmusic-msid-01.txt |
2013-04-05
|
00 | Ari Keränen | Changed shepherd to Ari Keränen |
2013-02-10
|
00 | Harald Alvestrand | New version available: draft-ietf-mmusic-msid-00.txt |