Connection-Oriented Media Transport over the Transport Layer Security (TLS) Protocol in the Session Description Protocol (SDP)
draft-ietf-mmusic-4572-update-13
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2017-03-16
|
13 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2017-03-13
|
13 | (System) | RFC Editor state changed to AUTH48 from RFC-EDITOR |
2017-03-09
|
13 | (System) | RFC Editor state changed to RFC-EDITOR from EDIT |
2017-02-14
|
13 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2017-02-14
|
13 | (System) | IANA Action state changed to Waiting on RFC Editor from Waiting on Authors |
2017-02-13
|
13 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2017-02-09
|
13 | Tero Kivinen | Closed request for Last Call review by SECDIR with state 'No Response' |
2017-02-06
|
13 | (System) | RFC Editor state changed to EDIT |
2017-02-06
|
13 | (System) | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2017-02-06
|
13 | (System) | Announcement was received by RFC Editor |
2017-02-06
|
13 | (System) | IANA Action state changed to In Progress |
2017-02-06
|
13 | Amy Vezza | IESG state changed to Approved-announcement sent from Approved-announcement to be sent |
2017-02-06
|
13 | Amy Vezza | IESG has approved the document |
2017-02-06
|
13 | Amy Vezza | Closed "Approve" ballot |
2017-02-03
|
13 | Ben Campbell | IESG state changed to Approved-announcement to be sent from Approved-announcement to be sent::AD Followup |
2017-02-03
|
13 | Ben Campbell | Ballot approval text was generated |
2017-02-02
|
13 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2017-02-02
|
13 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2017-02-02
|
13 | Christer Holmberg | New version available: draft-ietf-mmusic-4572-update-13.txt |
2017-02-02
|
13 | (System) | New version approved |
2017-02-02
|
13 | (System) | Request for posting confirmation emailed to previous authors: "Jonathan Lennox" , "Christer Holmberg" |
2017-02-02
|
13 | Christer Holmberg | Uploaded new revision |
2017-02-02
|
12 | Cindy Morgan | IESG state changed to Approved-announcement to be sent::Revised I-D Needed from IESG Evaluation |
2017-02-02
|
12 | Spencer Dawkins | [Ballot Position Update] New position, No Objection, has been recorded for Spencer Dawkins |
2017-02-01
|
12 | Joel Jaeggli | [Ballot Position Update] New position, No Objection, has been recorded for Joel Jaeggli |
2017-02-01
|
12 | Alia Atlas | [Ballot Position Update] New position, No Objection, has been recorded for Alia Atlas |
2017-02-01
|
12 | Jari Arkko | [Ballot Position Update] New position, No Objection, has been recorded for Jari Arkko |
2017-02-01
|
12 | Alissa Cooper | [Ballot comment] Section 5.1 says: "An endpoint MAY, in addition to its more preferred hash function, also verify that each certificate used matches fingerprints … [Ballot comment] Section 5.1 says: "An endpoint MAY, in addition to its more preferred hash function, also verify that each certificate used matches fingerprints calculated using other hash functions. Unless there is a matching fingerprint for each tested hash function, the endpoint MUST NOT establish the TLS connection." This seems a little weird to me. It's up to the endpoint to decide whether to check for errors, and then if it does find an error it can't setup the connection, whereas if it just hadn't checked it would be able to setup the connection. I think it would help to explain why an endpoint would be motivated to check multiple fingerprints. |
2017-02-01
|
12 | Alissa Cooper | [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper |
2017-02-01
|
12 | Kathleen Moriarty | [Ballot comment] I agree with Stephen's comments. |
2017-02-01
|
12 | Kathleen Moriarty | [Ballot Position Update] New position, No Objection, has been recorded for Kathleen Moriarty |
2017-02-01
|
12 | Stephen Farrell | [Ballot comment] I had two (or 4 depending how you count:-) things I'd like to check here. They were pretty easy to handle. (We more … [Ballot comment] I had two (or 4 depending how you count:-) things I'd like to check here. They were pretty easy to handle. (We more or less resolved this by mail.) (1) section 5: I'm wondering if we have the right set of hash functions here. Deprecating md2 and md5 is great, but I have a bunch of questions about the others: (1.1) why not also say that sha-1 MUST NOT be used for new things (or similar)? (1.2) do you really need sha-224 and 384? I think nobody uses those at all. (1.3) I'm a bit surprised you didn't add sha3 (and maybe remove sha-512 if that's not needed) Even if you don't encourage use of sha3, it might be good to include it in the abnf now in case it gets popular. (2) Wouldn't it be a good plan to say that TLS as-used MUST conform to BCP195? If not, why not? |
2017-02-01
|
12 | Stephen Farrell | [Ballot Position Update] Position for Stephen Farrell has been changed to No Objection from Discuss |
2017-01-31
|
12 | Terry Manderson | [Ballot Position Update] New position, No Objection, has been recorded for Terry Manderson |
2017-01-31
|
12 | Deborah Brungard | [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard |
2017-01-31
|
12 | Suresh Krishnan | [Ballot Position Update] New position, No Objection, has been recorded for Suresh Krishnan |
2017-01-31
|
12 | Alvaro Retana | [Ballot comment] RFC4572, which this document obsoletes, Updates RFC4145. I'm wondering why this document doesn't Update RFC4145 too? |
2017-01-31
|
12 | Alvaro Retana | [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana |
2017-01-31
|
12 | Mirja Kühlewind | [Ballot Position Update] New position, No Objection, has been recorded for Mirja Kühlewind |
2017-01-31
|
12 | Stephen Farrell | [Ballot discuss] I've two (or 4 depending how you count:-) things I'd like to check here. Should be pretty easy to handle. (1) section 5: … [Ballot discuss] I've two (or 4 depending how you count:-) things I'd like to check here. Should be pretty easy to handle. (1) section 5: I'm wondering if we have the right set of hash functions here. Deprecating md2 and md5 is great, but I have a bunch of questions about the others: (1.1) why not also say that sha-1 MUST NOT be used for new things (or similar)? (1.2) do you really need sha-224 and 384? I think nobody uses those at all. (1.3) I'm a bit surprised you didn't add sha3 (and maybe remove sha-512 if that's not needed) Even if you don't encourage use of sha3, it might be good to include it in the abnf now in case it gets popular. (2) Wouldn't it be a good plan to say that TLS as-used MUST conform to BCP195? If not, why not? |
2017-01-31
|
12 | Stephen Farrell | [Ballot Position Update] New position, Discuss, has been recorded for Stephen Farrell |
2017-01-27
|
12 | Amanda Baber | IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed |
2017-01-26
|
12 | Ben Campbell | Placed on agenda for telechat - 2017-02-02 |
2017-01-26
|
12 | Ben Campbell | IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead |
2017-01-26
|
12 | Ben Campbell | Ballot has been issued |
2017-01-26
|
12 | Ben Campbell | [Ballot Position Update] New position, Yes, has been recorded for Ben Campbell |
2017-01-26
|
12 | Ben Campbell | Created "Approve" ballot |
2017-01-26
|
12 | Ben Campbell | Ballot approval text was generated |
2017-01-26
|
12 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2017-01-26
|
12 | Christer Holmberg | New version available: draft-ietf-mmusic-4572-update-12.txt |
2017-01-26
|
12 | (System) | New version approved |
2017-01-26
|
12 | (System) | Request for posting confirmation emailed to previous authors: "Jonathan Lennox" , "Christer Holmberg" |
2017-01-26
|
12 | Christer Holmberg | Uploaded new revision |
2017-01-26
|
11 | (System) | IESG state changed to Waiting for AD Go-Ahead from In Last Call |
2017-01-25
|
11 | (System) | IANA Review state changed to IANA OK - Actions Needed from IANA - Review Needed |
2017-01-25
|
11 | Sabrina Tanamal | (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Services Operator has completed its review of draft-ietf-mmusic-4572-update-11.txt. If any part of this review is inaccurate, please let … (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Services Operator has completed its review of draft-ietf-mmusic-4572-update-11.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 is a single action which we must complete. The current document updates RFC4572 and we are aware of three references that should be updated from RFC4572 to [ RFC-to-be ]. They are: SDP Name TCP/TLS in the protoco subregistry of the Session Description Protocol (SDP) Parameters registry located at: https://www.iana.org/assignments/sdp-parameters/ The SDP session and media-level attributes: 'fingerprint' located in the att-field (both session and media level) subregistry also in the Session Description Protocol (SDP) Parameters registry located at: https://www.iana.org/assignments/sdp-parameters/ And, finally, the Hash Function Textual Names registry located on the IANA Protocol Registries Matrix located at: https://www.iana.org/protocols The IANA Services Operator 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 Services Specialist PTI |
2017-01-25
|
11 | Gunter Van de Velde | Request for Last Call review by OPSDIR Completed: Has Nits. Reviewer: Tianran Zhou. |
2017-01-24
|
11 | Elwyn Davies | Request for Last Call review by GENART Completed: Ready. Reviewer: Elwyn Davies. Sent review to list. |
2017-01-19
|
11 | Jean Mahoney | Request for Last Call review by GENART is assigned to Elwyn Davies |
2017-01-19
|
11 | Jean Mahoney | Request for Last Call review by GENART is assigned to Elwyn Davies |
2017-01-19
|
11 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Sandra Murphy |
2017-01-19
|
11 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Sandra Murphy |
2017-01-17
|
11 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Tianran Zhou |
2017-01-17
|
11 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Tianran Zhou |
2017-01-12
|
11 | Cindy Morgan | IANA Review state changed to IANA - Review Needed |
2017-01-12
|
11 | Cindy Morgan | The following Last Call announcement was sent out: From: The IESG To: "IETF-Announce" CC: ben@nostrum.com, mmusic@ietf.org, mmusic-chairs@ietf.org, fandreas@cisco.com, "Flemming Andreasen" , … The following Last Call announcement was sent out: From: The IESG To: "IETF-Announce" CC: ben@nostrum.com, mmusic@ietf.org, mmusic-chairs@ietf.org, fandreas@cisco.com, "Flemming Andreasen" , draft-ietf-mmusic-4572-update@ietf.org Reply-To: ietf@ietf.org Sender: Subject: Last Call: (Connection-Oriented Media Transport over TLS in SDP) to Proposed Standard The IESG has received a request from the Multiparty Multimedia Session Control WG (mmusic) to consider the following document: - 'Connection-Oriented Media Transport over TLS in SDP' 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-26. 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 how to establish secure connection-oriented media transport sessions over the Transport Layer Security (TLS) protocol using the Session Description Protocol (SDP). It defines a new SDP protocol identifier, 'TCP/TLS'. It also defines the syntax and semantics for an SDP 'fingerprint' attribute that identifies the certificate that will be presented for the TLS session. This mechanism allows media transport over TLS connections to be established securely, so long as the integrity of session descriptions is assured. This document obsoletes RFC 4572, by clarifying the usage of multiple fingerprints. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-mmusic-4572-update/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-mmusic-4572-update/ballot/ No IPR declarations have been submitted directly on this I-D. |
2017-01-12
|
11 | Cindy Morgan | IESG state changed to In Last Call from Last Call Requested |
2017-01-12
|
11 | Ben Campbell | Last call was requested |
2017-01-12
|
11 | Ben Campbell | IESG state changed to Last Call Requested from Publication Requested |
2017-01-12
|
11 | Ben Campbell | Last call announcement was generated |
2017-01-12
|
11 | Ben Campbell | Ballot writeup was changed |
2017-01-12
|
11 | Ben Campbell | Ballot approval text was generated |
2017-01-12
|
11 | Christer Holmberg | New version available: draft-ietf-mmusic-4572-update-11.txt |
2017-01-12
|
11 | (System) | New version approved |
2017-01-12
|
11 | (System) | Request for posting confirmation emailed to previous authors: "Jonathan Lennox" , "Christer Holmberg" |
2017-01-12
|
11 | Christer Holmberg | Uploaded new revision |
2017-01-10
|
10 | Ben Campbell | This is my AD evaluation of draft-ietf-mmusic-4572-update-10. Overall it's in good shape, but there are a couple of issues that I think need to be … This is my AD evaluation of draft-ietf-mmusic-4572-update-10. Overall it's in good shape, but there are a couple of issues that I think need to be addressed prior to IETF last call. I also have some minor and editorial comments that can be addressed along with any last call feedback. I realize this is in effect a "bis" draft, and I've mostly confined my comments to new text. However, I have a few comments where something from the original text may be out of date or cause confusion related to the changes. ----------------------- Major Comments (To be addressed before IETF LC: -5.0, 2nd to last paragraph: What does "MUST NOT use" mean? MUST NOT generate? MUST NOT verify? Both? -5.1, 2nd to last paragraph: This paragraph confusing to me. The first part says you MUST NOT establish the TLS connection if the most secure hash fails to match, but then it goes on to say you MAY check other hashes. If the most secure hash must match, what's the point in checking others? Or is the "MUST NOT establish" part incorrect? Or is it saying you can optionally require a hash to match for every included hash function? (If the latter is true, then a note why you might want to do that might be helpful.) It think it would help to cast this paragraph as a stepwise procedure for matching certificates. Minor Comments: -3.2, last paragraph: Is s/mime still a reasonable example, given that no one does it? Would it make sense to cite 4474/4474bis instead or in addition? - 3.4, example: Perhaps the example should use the newly recommended hash function? Maybe illustrate multiple fingerprints? -5.1, last paragraph: I understand this to say that if I have multiple certificates and multiple fingerprints, I have to potentially compare every fingerprint against every cert to figure out which go with which? Is that really the intent? -7, paragraphs 4 and 6. (I think this is old text, but it's confusing enough that it might be worth addressing.) Paragraph 4 says "Users SHOUD NOT, in any circumstances be notified about certificates...sent over an integrity protected channel". But paragraph 6 says that the user SHOULD be notified when the cert identity differs from the SIP signaled identity, even when self-signed certs are used. Nothing there suggests that integrity protection removes the need to notify. Should it? -7, paragraph 7: "The group consensus was to wait until a use-case requiring secure connection-oriented RTP was presented" Is that still true? Editorial comments and nits: - 1, 2nd paragraph: "... channel t provides confidentiality..." s/t/that - 1, last paragraph: Please consider putting this in a separate "changes since..." section. While the information is here, someone wanting to quickly find the changes would appreciate them showing up in the ToC. Also, when using non-mnemonic citation anchors, please do not treat the citation as a word in the sentence. For example, "obsoletes RFC 4572 [21]" and "obsoletes [RFC4572]" are both acceptable, but "obsoletes [21]" is reader-unfriendly. -5.0, 2nd to last paragraph: Should "cipher suites" be "hash functions"? -5.1, 2nd to last paragraph: "MUST be able to" uses the 2119 keyword to describe the condition, not the action. It would be more correct to say something like "MUST NOT establish the connection unless it can match at least one fingerprint." (Yes, I know this is pedantic.) -6.2, 2nd paragraph: "...certificate does not match the provided fingerprint" Should that now say "does not match _a_ provided fingerprint"? |
2017-01-06
|
10 | 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, which is appropriate since the document obsoletes RFC 4572. The title page shows the proper status. (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 The document specifies how to establish secure connection-oriented media transport sessions over the Transport Layer Security (TLS) protocol using the Session Description Protocol (SDP). It defines a new SDP protocol identifier, 'TCP/TLS'. It also defines the syntax and semantics for an SDP 'fingerprint' attribute that identifies the certificate that will be presented for the TLS session. This mechanism allows media transport over TLS connections to be established securely, so long as the integrity of session descriptions is assured. This document obsoletes RFC 4572 but remains backwards compatible with older implementations. The changes from RFC 4572 are that it clarifies that multiple 'fingerprint' attributes can be used to carry fingerprints, calculated using different hash functions, associated with a given certificate, and to carry fingerprints associated with multiple certificates. The fingerprint matching procedure, when multiple fingerprints are provided, are also clarified. The document also updates the preferred cipher suite with a stronger cipher suite, and removes the requirement to use the same hash function for calculating a certificate fingerprint and certificate signature. 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 was adopted as a WG document in April 2016 and hence has progressed fairly quickly. WG adoption was based on strong consensus and a clear need; the document has subsequently seen good WG discussion. The document started out as an update to RFC 4572, but was more recently changed to obsolete RFC 4572 after some concerns were raised. The resulting document has solid consensus in the WG. 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? There are various implementations of the existing RFC 4572. The new specification is needed for RTCWeb and hence several vendors are expected to implement it. There were many individuals providing valuable input, however Martin Thomson and Roman Shpount in particular deserve special mention. Personnel Who is the Document Shepherd? Who is the Responsible Area Director? Flemming Andreasen is the Document Shepherd and 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. I have reviewed the current and several earlier versions of the document, including Nits checks. Note that the first line on Page 3 contains two typos that should be corrected during the publication process (change "TLS to "The TLS" and "channel t" to "channel that") (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No concerns. The changes to RFC 4572 are the result of extensive discussion in the WG. (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. No such concerns. (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. Confirmed (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 disclosure (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 received substantial discussion from several people and the WG consensus is solid at this point. (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.) N/A (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. The document normatively references a NIST specification (FIPS 180-2) and an ITU-T Recommendation (X.509) which causes two "possible down-ref" comments. Both of these references are needed and were also present in the original RFC 4572. The IP examples use IPv4 only, which seems reasonable since the document does not contain any IP version specific mechanisms or considerations. (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? N/A (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 two downward references (as noted above): [1] National Institute of Standards and Technology, "Secure Hash Standard", FIPS PUB 180-2, August 2002, . [2] International Telecommunications Union, "Information technology - Open Systems Interconnection - The Directory: Public-key and attribute certificate frameworks", ITU-T Recommendation X.509, ISO Standard 9594-8, March 2000. (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. The document obsoletes RFC 4572, as indicated on the title page and explained in both the Abstract and Introduction. (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). Confirmed (N/A) (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 (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 ABNF has been verified with Bill Fenner's ABNF parser. |
2017-01-06
|
10 | Flemming Andreasen | Responsible AD changed to Ben Campbell |
2017-01-06
|
10 | Flemming Andreasen | IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up |
2017-01-06
|
10 | Flemming Andreasen | IESG state changed to Publication Requested |
2017-01-06
|
10 | Flemming Andreasen | IESG process started in state Publication Requested |
2017-01-06
|
10 | Flemming Andreasen | Changed consensus to Yes from Unknown |
2017-01-06
|
10 | Flemming Andreasen | Intended Status changed to Proposed Standard from None |
2017-01-06
|
10 | Flemming Andreasen | Changed document writeup |
2017-01-05
|
10 | Christer Holmberg | New version available: draft-ietf-mmusic-4572-update-10.txt |
2017-01-05
|
10 | (System) | New version approved |
2017-01-05
|
10 | (System) | Request for posting confirmation emailed to previous authors: "Jonathan Lennox" , "Christer Holmberg" |
2017-01-05
|
10 | Christer Holmberg | Uploaded new revision |
2017-01-02
|
09 | Christer Holmberg | New version available: draft-ietf-mmusic-4572-update-09.txt |
2017-01-02
|
09 | (System) | New version approved |
2017-01-02
|
09 | (System) | Request for posting confirmation emailed to previous authors: "Jonathan Lennox" , "Christer Holmberg" |
2017-01-02
|
09 | Christer Holmberg | Uploaded new revision |
2016-11-04
|
08 | Cindy Morgan | New version available: draft-ietf-mmusic-4572-update-08.txt |
2016-11-04
|
08 | (System) | Secretariat manually posting. Approvals already received |
2016-11-04
|
08 | Cindy Morgan | Uploaded new revision |
2016-09-25
|
07 | Christer Holmberg | New version approved |
2016-09-25
|
07 | Christer Holmberg | New version available: draft-ietf-mmusic-4572-update-07.txt |
2016-09-25
|
07 | Christer Holmberg | Request for posting confirmation emailed to previous authors: "Christer Holmberg" |
2016-09-25
|
07 | (System) | Uploaded new revision |
2016-09-23
|
06 | Christer Holmberg | New version available: draft-ietf-mmusic-4572-update-06.txt |
2016-09-23
|
06 | Christer Holmberg | New version approved |
2016-09-23
|
06 | Christer Holmberg | Request for posting confirmation emailed to previous authors: "Christer Holmberg" |
2016-09-23
|
06 | (System) | Uploaded new revision |
2016-09-23
|
06 | Christer Holmberg | Request for posting confirmation emailed to previous authors: "Christer Holmberg" |
2016-07-01
|
05 | Flemming Andreasen | IETF WG state changed to WG Consensus: Waiting for Write-Up from Waiting for WG Chair Go-Ahead |
2016-06-10
|
05 | Christer Holmberg | New version available: draft-ietf-mmusic-4572-update-05.txt |
2016-06-08
|
04 | Flemming Andreasen | IETF WG state changed to Waiting for WG Chair Go-Ahead from In WG Last Call |
2016-06-07
|
04 | Christer Holmberg | New version available: draft-ietf-mmusic-4572-update-04.txt |
2016-05-23
|
03 | Flemming Andreasen | IETF WG state changed to In WG Last Call from WG Document |
2016-05-23
|
03 | Flemming Andreasen | Notification list changed to "Flemming Andreasen" <fandreas@cisco.com> |
2016-05-23
|
03 | Flemming Andreasen | Document shepherd changed to Flemming Andreasen |
2016-05-21
|
03 | Christer Holmberg | New version available: draft-ietf-mmusic-4572-update-03.txt |
2016-05-18
|
02 | Christer Holmberg | New version available: draft-ietf-mmusic-4572-update-02.txt |
2016-05-05
|
01 | Christer Holmberg | New version available: draft-ietf-mmusic-4572-update-01.txt |
2016-05-04
|
00 | Christer Holmberg | New version available: draft-ietf-mmusic-4572-update-00.txt |