RTP Payload Format Restrictions
draft-ietf-mmusic-rid-15
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2020-05-28
|
15 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2020-04-09
|
15 | (System) | RFC Editor state changed to AUTH48 from RFC-EDITOR |
2020-03-16
|
15 | (System) | RFC Editor state changed to RFC-EDITOR from REF |
2019-08-16
|
15 | (System) | RFC Editor state changed to REF from EDIT |
2019-08-15
|
15 | (System) | RFC Editor state changed to EDIT from MISSREF |
2018-06-18
|
15 | (System) | RFC Editor state changed to MISSREF from EDIT |
2018-06-18
|
15 | (System) | RFC Editor state changed to EDIT from MISSREF |
2018-05-17
|
15 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2018-05-17
|
15 | Ben Campbell | RFC Editor Note was changed |
2018-05-17
|
15 | Ben Campbell | RFC Editor Note for ballot was generated |
2018-05-17
|
15 | Ben Campbell | RFC Editor Note for ballot was generated |
2018-05-17
|
15 | (System) | IANA Action state changed to Waiting on RFC Editor from In Progress |
2018-05-17
|
15 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
2018-05-17
|
15 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2018-05-16
|
15 | (System) | RFC Editor state changed to MISSREF |
2018-05-16
|
15 | (System) | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2018-05-16
|
15 | (System) | Announcement was received by RFC Editor |
2018-05-16
|
15 | (System) | IANA Action state changed to In Progress |
2018-05-16
|
15 | Amy Vezza | IESG state changed to Approved-announcement sent from Approved-announcement to be sent |
2018-05-16
|
15 | Amy Vezza | IESG has approved the document |
2018-05-16
|
15 | Amy Vezza | Closed "Approve" ballot |
2018-05-15
|
15 | Ben Campbell | IESG state changed to Approved-announcement to be sent from Approved-announcement to be sent::AD Followup |
2018-05-15
|
15 | Ben Campbell | Ballot approval text was generated |
2018-05-15
|
15 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2018-05-15
|
15 | Adam Roach | New version available: draft-ietf-mmusic-rid-15.txt |
2018-05-15
|
15 | (System) | New version approved |
2018-05-15
|
15 | (System) | Request for posting confirmation emailed to previous authors: Adam Roach |
2018-05-15
|
15 | Adam Roach | Uploaded new revision |
2018-05-07
|
14 | Gunter Van de Velde | Closed request for Last Call review by OPSDIR with state 'No Response' |
2018-04-26
|
14 | Tero Kivinen | Closed request for Last Call review by SECDIR with state 'No Response' |
2018-04-19
|
14 | Cindy Morgan | IESG state changed to Approved-announcement to be sent::Revised I-D Needed from IESG Evaluation |
2018-04-19
|
14 | Ignas Bagdonas | [Ballot Position Update] New position, No Objection, has been recorded for Ignas Bagdonas |
2018-04-18
|
14 | Alvaro Retana | [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana |
2018-04-18
|
14 | Alissa Cooper | [Ballot comment] The Gen-ART reviewer made some useful suggestions. Please take a look. https://datatracker.ietf.org/doc/review-ietf-mmusic-rid-14-genart-lc-sparks-2018-02-27/ |
2018-04-18
|
14 | Alissa Cooper | [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper |
2018-04-18
|
14 | Deborah Brungard | [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard |
2018-04-18
|
14 | Mirja Kühlewind | [Ballot Position Update] New position, No Objection, has been recorded for Mirja Kühlewind |
2018-04-18
|
14 | Martin Vigoureux | [Ballot Position Update] New position, No Objection, has been recorded for Martin Vigoureux |
2018-04-18
|
14 | Terry Manderson | [Ballot Position Update] New position, No Objection, has been recorded for Terry Manderson |
2018-04-17
|
14 | Suresh Krishnan | [Ballot Position Update] New position, No Objection, has been recorded for Suresh Krishnan |
2018-04-17
|
14 | Benjamin Kaduk | [Ballot comment] Presumably I'm just being dense, but from perusing the formal grammar I couldn't decide if it's allowed to have both PT and parameter … [Ballot comment] Presumably I'm just being dense, but from perusing the formal grammar I couldn't decide if it's allowed to have both PT and parameter restrictions applied on the same rid-id. Section 5 Similarly (me being dense), I'm a bit confused at the relationship between max-fps and max-pps -- aren't there encodings that can send update frames that do not include the full pixel density of a frame? Section 6.2.2 4. If the "direction" field is "recv", The answerer ensures that "a=rid" restrictions are supported. In the case of an unsupported restriction, the "a=rid" line is discarded. "that "a=rid" restrictions are supported" reads like a feature test for being able to parse a=rid at all, but the context suggests that this is intended to refer to the Section-5 restriction stanzas that appear on an a=rid line. Section 8 I thought I remembered something going by to the effect of s/non-empty union/non-empty intersection/ but didn't find it in a quick search, so dropping a note just in case. Section 8.2 The following codec format parameters correspond to restrictions on receiver capabilities, and never indicate sending restrictions. Maybe "The codec format parameters covered in the following subsections [...]"? Section 10 Should float-param-val = 1*DIGIT "." 1*DIGIT have the last entry be 1*4DIGIT to catch the "four digits after the decimal place" requirement of max-bpp, or are we leaving the float-param-value grammar less restricted in case of potential future use? |
2018-04-17
|
14 | Benjamin Kaduk | [Ballot Position Update] New position, No Objection, has been recorded for Benjamin Kaduk |
2018-04-16
|
14 | Spencer Dawkins | [Ballot comment] (Meta-comment - thanks for helping me understand what's going on in Section 8, when discussing my previous Discuss) If "rid" actually means something, … [Ballot comment] (Meta-comment - thanks for helping me understand what's going on in Section 8, when discussing my previous Discuss) If "rid" actually means something, it might be nice to expand it in the Abstract and Introduction. After the first couple of pages, I was guessing that it means something like "RTP Stream Identifier", based on a quick scan of https://tools.ietf.org/html/draft-ietf-avtext-rid-09, but that draft doesn't ever expand "rid" or use "rid" in the text, so then I think I'm wrong, because this draft also uses "rid-id", and I'm guessing that's probably not "RTP Stream Identifier Identifier". By the time I get down to Section 5, I decide it means "Restriction Identifier", but then I'm not any happier that I'm guessing "rid-id" means "Restriction Identifier Identifier" :-) I'm confused by the SHOULD NOT in o max-fps, for frame rate in frames per second. For encoders that do not use a fixed framerate for encoding, this value should restrict the minimum amount of time between frames: the time between any two consecutive frames SHOULD NOT be less than 1/max- fps seconds. The related description of max-pps, also uses a SHOULD, but explains why excursions outside this value are permissible. (I'm also confused by "this value should restrict the minimum amount of time between frames" - I saw that you're using RFC 8174 for keywords, but is this just saying "this value restricts the minimum amount of time between frames", or something else?) I note that 8.1 and 8.2 both include something like Both correspond to restrictions on receiver capabilities, and never indicate sending restrictions. Is that true for all format parameters, for all codecs? If so, perhaps that should be explicit, in one of the normative sections (in which case, it wouldn't be useful here). If not, are implementations supposed to know what to do? |
2018-04-16
|
14 | Spencer Dawkins | [Ballot Position Update] Position for Spencer Dawkins has been changed to No Objection from Discuss |
2018-04-16
|
14 | Eric Rescorla | [Ballot comment] Rich version of this review at: https://mozphab-ietf.devsvcdev.mozaws.net/D3309 It took me a while to figure out how this works. I think I would instead … [Ballot comment] Rich version of this review at: https://mozphab-ietf.devsvcdev.mozaws.net/D3309 It took me a while to figure out how this works. I think I would instead say something like "This document makes it possible to specify multiple media profiles in a given session, e.g., for different sending rates for simulcast. Each profile is associated with one or more payload type and identified by a rid value which is carried in the RTP payload [REF], thus allowing the receiver to demultiplex different profiles (and hence sending streams within the session)" COMMENTS > payload format and the associated SDP media description. The SDP > rtpmap and/or fmtp attributes are used, for a given PT, to describe > the properties of the media that is carried in the RTP payload. > > Recent advances in standards have given rise to rich multimedia > applications requiring support for multiple RTP Streams within a RTP Nit; "an RTP" > To expand on these points: [RFC3550] assigns 7 bits for the PT in the > RTP header. However, the assignment of static mapping of RTP payload > type numbers to payload formats and multiplexing of RTP with other > protocols (such as RTCP) could result in a limited number of payload > type numbers available for application usage. In scenarios where the > number of possible RTP payload configurations exceed the available PT Nit: exceeds > a=rid: [pt=;]=... > > An "a=rid" SDP media attribute specifies restrictions defining a > unique RTP payload configuration identified via the "rid-id" field. > This value binds the restriction to the RTP Stream identified by its > RTP Stream Identifier SDES item [I-D.ietf-avtext-rid]. To be clear, SDES is kind of an overloaded term at this point. > the RtpStreamId SDES item described in [I-D.ietf-avtext-rid]. Such > implementations MUST send it for all streams in an SDP media > description ("m=") that have "a=rid" lines remaining after applying > the rules in Section 6 and its subsections. > > Implementations that use the "a=rid" parameter in SDP and that make This is pretty hard to follow. Let me see if I understand this. You have a bunch of PTs and then each RID further restricts the parameters for the set of PTs that it applies to? > media section ("m-line"); they do not necessarily need to be unique > within an entire RTP session. In traditional usage, each media > section is sent on its own unique 5-tuple, which provides an > unambiguous scope. Similarly, when using BUNDLE > [I-D.ietf-mmusic-sdp-bundle-negotiation], MID values associate RTP > streams uniquely to a single media description. So you send both MID and RID in this case? That doesn't seem ideal, but perhaps it should be stated. > > 1. The answerer ensures that the "a=rid" line is syntactically well > formed. In the case of a syntax error, the "a=rid" line is > discarded. > > 2. Extract the rid-id from the "a=rid" line and verify its This is in the imperative mode whereas the other steps are descriptive. You probably want them to match > 1. The value of the "direction" field is reversed: "send" is changed > to "recv", and "recv" is changed to "send". > > 2. The answerer MAY choose to modify specific "a=rid" restriction > values in the answer SDP. In such a case, the modified value > MUST be more restricted than the ones specified in the offer. restrictive? > the offer, then the offerer SHALL discard the "a=rid" line. > > 3. If the restrictions have been changed between the offer and the > answer, the offerer MUST ensure that the modifications can be > supported; if they cannot, the offerer SHALL discard the "a=rid" > line. Should you be checking for "more restricted" > comparison necessarily requires an understanding of the meaning > of codec parameters, rather than a rote byte-wise comparison of > their values. > > 6. If the "a=rid" line contains a "pt=", the offerer verifies that > the attribute values provided in the "a=rid" attributes are Why did you break this out. It seems to just be an addition (5) |
2018-04-16
|
14 | Eric Rescorla | Ballot comment text updated for Eric Rescorla |
2018-04-16
|
14 | Warren Kumari | [Ballot Position Update] New position, No Objection, has been recorded for Warren Kumari |
2018-04-16
|
14 | Adam Roach | [Ballot comment] I'm an author |
2018-04-16
|
14 | Adam Roach | [Ballot Position Update] New position, Recuse, has been recorded for Adam Roach |
2018-04-16
|
14 | Spencer Dawkins | [Ballot discuss] Please consider this to be an opportunity to explain something to an AD who doesn't understand codecs super well ... so I doubt … [Ballot discuss] Please consider this to be an opportunity to explain something to an AD who doesn't understand codecs super well ... so I doubt it will be hard to clear my Discuss. I'm not entirely comfortable that Section 8 isn't normative. Is the theory that if (for example) I decide that my H.264 format parameter maps onto a codec-independent parameter that you don't think it maps to, then you and I probably would probably end up ignoring the rid and doing what we would do, if one of us didn't support rids? If not, what's supposed to happen (normatively)? |
2018-04-16
|
14 | Spencer Dawkins | [Ballot comment] If "rid" actually means something, it might be nice to expand it in the Abstract and Introduction. After the first couple of pages, … [Ballot comment] If "rid" actually means something, it might be nice to expand it in the Abstract and Introduction. After the first couple of pages, I was guessing that it means something like "RTP Stream Identifier", based on a quick scan of https://tools.ietf.org/html/draft-ietf-avtext-rid-09, but that draft doesn't ever expand "rid" or use "rid" in the text, so then I think I'm wrong, because this draft also uses "rid-id", and I'm guessing that's probably not "RTP Stream Identifier Identifier". By the time I get down to Section 5, I decide it means "Restriction Identifier", but then I'm not any happier that I'm guessing "rid-id" means "Restriction Identifier Identifier" :-) I'm confused by the SHOULD NOT in o max-fps, for frame rate in frames per second. For encoders that do not use a fixed framerate for encoding, this value should restrict the minimum amount of time between frames: the time between any two consecutive frames SHOULD NOT be less than 1/max- fps seconds. The related description of max-pps, also uses a SHOULD, but explains why excursions outside this value are permissible. (I'm also confused by "this value should restrict the minimum amount of time between frames" - I saw that you're using RFC 8174 for keywords, but is this just saying "this value restricts the minimum amount of time between frames", or something else?) I note that 8.1 and 8.2 both include something like Both correspond to restrictions on receiver capabilities, and never indicate sending restrictions. Is that true for all format parameters, for all codecs? If so, perhaps that should be explicit, in one of the normative sections (in which case, it wouldn't be useful here). If not, are implementations supposed to know what to do? |
2018-04-16
|
14 | Spencer Dawkins | [Ballot Position Update] New position, Discuss, has been recorded for Spencer Dawkins |
2018-04-16
|
14 | Alexey Melnikov | [Ballot comment] The document is generally fine, but I have a few minor comments: In the ABNF: rid-width-param = "max-width" [ "=" int-param-val ] … [Ballot comment] The document is generally fine, but I have a few minor comments: In the ABNF: rid-width-param = "max-width" [ "=" int-param-val ] rid-height-param = "max-height" [ "=" int-param-val ] rid-fps-param = "max-fps" [ "=" int-param-val ] rid-fs-param = "max-fs" [ "=" int-param-val ] rid-br-param = "max-br" [ "=" int-param-val ] rid-pps-param = "max-pps" [ "=" int-param-val ] rid-bpp-param = "max-bpp" [ "=" float-param-val ] Maybe I missed that, but what is the meaning of "max-width" (and others) with no value? Or to rephrase that: are the values really optional? 12.2. Registry for RID-Level Parameters New restriction registrations are accepted according to the "Specification Required" policy of [RFC5226], provided that the specification includes the following information: o contact name, email address, and telephone number Considering the European GDPR directive is going to come into force in May: is there any legitimate use for collecting phone numbers for this registry? o restriction name (as it will appear in SDP) o long-form restriction name in English o whether the restriction value is subject to the charset attribute o an explanation of the purpose of the restriction o a specification of appropriate attribute values for this restriction o an ABNF definition of the restriction The initial set of "a=rid" restriction names, with definitions in Section 5 of this document, is given below: RID Parameter Name Reference ------------------ --------- max-width [RFCXXXX] max-height [RFCXXXX] max-fps [RFCXXXX] max-fs [RFCXXXX] max-br [RFCXXXX] max-pps [RFCXXXX] max-bpp [RFCXXXX] depend [RFCXXXX] And now you just registered them without following your registration template that you've specified above ;-). |
2018-04-16
|
14 | Alexey Melnikov | [Ballot Position Update] New position, No Objection, has been recorded for Alexey Melnikov |
2018-04-15
|
14 | Eric Rescorla | [Ballot comment] Rich version of this review at: https://mozphab-ietf.devsvcdev.mozaws.net/D3309 It took me a while to figure out how this works. I think I would instead … [Ballot comment] Rich version of this review at: https://mozphab-ietf.devsvcdev.mozaws.net/D3309 It took me a while to figure out how this works. I think I would instead say something like "This document makes it possible to specify multiple media profiles in a given session, e.g., for different sending rates for simulcast. Each profile is associated with one or more payload type and identified by a rid value which is carried in the RTP payload [REF], thus allowing the receiver to demultiplex different profiles (and hence sending streams within the session)" COMMENTS > payload format and the associated SDP media description. The SDP > rtpmap and/or fmtp attributes are used, for a given PT, to describe > the properties of the media that is carried in the RTP payload. > > Recent advances in standards have given rise to rich multimedia > applications requiring support for multiple RTP Streams within a RTP Nit; "an RTP" > To expand on these points: [RFC3550] assigns 7 bits for the PT in the > RTP header. However, the assignment of static mapping of RTP payload > type numbers to payload formats and multiplexing of RTP with other > protocols (such as RTCP) could result in a limited number of payload > type numbers available for application usage. In scenarios where the > number of possible RTP payload configurations exceed the available PT Nit: exceeds > a=rid: [pt=;]=... > > An "a=rid" SDP media attribute specifies restrictions defining a > unique RTP payload configuration identified via the "rid-id" field. > This value binds the restriction to the RTP Stream identified by its > RTP Stream Identifier SDES item [I-D.ietf-avtext-rid]. To be clear, SDES is kind of an overloaded term at this point. > the RtpStreamId SDES item described in [I-D.ietf-avtext-rid]. Such > implementations MUST send it for all streams in an SDP media > description ("m=") that have "a=rid" lines remaining after applying > the rules in Section 6 and its subsections. > > Implementations that use the "a=rid" parameter in SDP and that make This is pretty hard to follow. Let me see if I understand this. You have a bunch of PTs and then each RID further restricts the parameters for the set of PTs that it applies to? > media section ("m-line"); they do not necessarily need to be unique > within an entire RTP session. In traditional usage, each media > section is sent on its own unique 5-tuple, which provides an > unambiguous scope. Similarly, when using BUNDLE > [I-D.ietf-mmusic-sdp-bundle-negotiation], MID values associate RTP > streams uniquely to a single media description. So you send both MID and RID in this case? That doesn't seem ideal, but perhaps it should be stated. > > 1. The answerer ensures that the "a=rid" line is syntactically well > formed. In the case of a syntax error, the "a=rid" line is > discarded. > > 2. Extract the rid-id from the "a=rid" line and verify its This is in the imperative mode whereas the other steps are descriptive. You probably want them to match > 1. The value of the "direction" field is reversed: "send" is changed > to "recv", and "recv" is changed to "send". > > 2. The answerer MAY choose to modify specific "a=rid" restriction > values in the answer SDP. In such a case, the modified value > MUST be more restricted than the ones specified in the offer. restrictive? > the offer, then the offerer SHALL discard the "a=rid" line. > > 3. If the restrictions have been changed between the offer and the > answer, the offerer MUST ensure that the modifications can be > supported; if they cannot, the offerer SHALL discard the "a=rid" > line. Should you be checking for "more restricted" > comparison necessarily requires an understanding of the meaning > of codec parameters, rather than a rote byte-wise comparison of > their values. > > 6. If the "a=rid" line contains a "pt=", the offerer verifies that > the attribute values provided in the "a=rid" attributes are Why did you break this out. It seems to just be an addition (5) |
2018-04-15
|
14 | Eric Rescorla | [Ballot Position Update] New position, No Objection, has been recorded for Eric Rescorla |
2018-04-09
|
14 | Ben Campbell | IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead |
2018-04-09
|
14 | Ben Campbell | Ballot has been issued |
2018-04-09
|
14 | Ben Campbell | [Ballot Position Update] New position, Yes, has been recorded for Ben Campbell |
2018-04-09
|
14 | Ben Campbell | Created "Approve" ballot |
2018-04-09
|
14 | Ben Campbell | Ballot approval text was generated |
2018-03-30
|
14 | (System) | IESG state changed to Waiting for AD Go-Ahead from In Last Call |
2018-03-14
|
14 | Ben Campbell | Placed on agenda for telechat - 2018-04-19 |
2018-02-28
|
14 | Amanda Baber | IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed |
2018-02-27
|
14 | Robert Sparks | Request for Last Call review by GENART Completed: Ready with Nits. Reviewer: Robert Sparks. Sent review to list. |
2018-02-27
|
14 | Amy Vezza | The following Last Call announcement was sent out (ends 2018-03-30): From: The IESG To: IETF-Announce CC: ben@nostrum.com, mmusic@ietf.org, mmusic-chairs@ietf.org, Flemming Andreasen , … The following Last Call announcement was sent out (ends 2018-03-30): From: The IESG To: IETF-Announce CC: ben@nostrum.com, mmusic@ietf.org, mmusic-chairs@ietf.org, Flemming Andreasen , fandreas@cisco.com, draft-ietf-mmusic-rid@ietf.org Reply-To: ietf@ietf.org Sender: Subject: EXTENDED Last Call: (RTP Payload Format Restrictions) to Proposed Standard The IESG has received a request from the Multiparty Multimedia Session Control WG (mmusic) to consider the following document: - 'RTP Payload Format Restrictions' 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 2018-03-30. 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 In this specification, we define a framework for specifying restrictions on RTP streams in the Session Description Protocol. This framework defines a new "rid" SDP attribute to unambiguously identify the RTP Streams within a RTP Session and restrict the streams' payload format parameters in a codec-agnostic way beyond what is provided with the regular Payload Types. This specification updates RFC4855 to give additional guidance on choice of Format Parameter (fmtp) names, and on their relation to the restrictions defined by this document. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-mmusic-rid/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-mmusic-rid/ballot/ No IPR declarations have been submitted directly on this I-D. |
2018-02-27
|
14 | Amy Vezza | Last call announcement was changed |
2018-02-27
|
14 | Amy Vezza | Last call announcement was generated |
2018-02-26
|
14 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA - Not OK |
2018-02-26
|
14 | Adam Roach | New version available: draft-ietf-mmusic-rid-14.txt |
2018-02-26
|
14 | (System) | New version approved |
2018-02-26
|
14 | (System) | Request for posting confirmation emailed to previous authors: Adam Roach |
2018-02-26
|
14 | Adam Roach | Uploaded new revision |
2018-02-23
|
13 | (System) | IANA Review state changed to IANA - Not OK from IANA - Review Needed |
2018-02-23
|
13 | Amanda Baber | (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Services Operator has completed its review of draft-ietf-mmusic-rid-13. 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-rid-13. 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. We have a question about one of the actions. First, in the att-field (media level only) registry on the Session Description Protocol (SDP) Parameters registry page located at: https://www.iana.org/assignments/sdp-parameters/ a single new registration will be made as follows: Type: att-field (media level only) SDP Name: rid Mux Category: SPECIAL Reference: [ RFC-to-be ] As this document requests registration in an Expert Review (see RFC 8126) registry, we have initiated the required expert review via a separate request. Expert review should be completed before your document is approved for publication as an RFC. Second, a new registry is to be created called the att-field (rid level) registry. The new registry will be located on the Session Description Protocol (SDP) Parameters registry page located at: https://www.iana.org/assignments/sdp-parameters/ The new registry is to be managed via Specification Required, as defined in RFC 8126. IANA Question --> Should this registry include the "Mux Category" field that appears in other att-field registries? There are initial registrations in the new registry: Type SDP Name Reference ---------------------+-----------+-------------- att-field (rid level) att-field (rid level) max-width [ RFC-to-be ] att-field (rid level) max-height [ RFC-to-be ] att-field (rid level) max-fps [ RFC-to-be ] att-field (rid level) max-fs [ RFC-to-be ] att-field (rid level) max-br [ RFC-to-be ] att-field (rid level) max-pps [ RFC-to-be ] att-field (rid level) max-bpp [ RFC-to-be ] att-field (rid level) depend [ RFC-to-be ] The IANA Services Operator understands that these are the only actions required 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 meant only to confirm the list of actions that will be performed. Thank you, Amanda Baber Lead IANA Services Specialist |
2018-02-23
|
13 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Joel Jaeggli |
2018-02-23
|
13 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Joel Jaeggli |
2018-02-22
|
13 | Jean Mahoney | Request for Last Call review by GENART is assigned to Robert Sparks |
2018-02-22
|
13 | Jean Mahoney | Request for Last Call review by GENART is assigned to Robert Sparks |
2018-02-22
|
13 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Daniel Franke |
2018-02-22
|
13 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Daniel Franke |
2018-02-20
|
13 | Amy Vezza | IANA Review state changed to IANA - Review Needed |
2018-02-20
|
13 | Amy Vezza | The following Last Call announcement was sent out (ends 2018-03-06): From: The IESG To: IETF-Announce CC: ben@nostrum.com, mmusic@ietf.org, mmusic-chairs@ietf.org, Flemming Andreasen , … The following Last Call announcement was sent out (ends 2018-03-06): From: The IESG To: IETF-Announce CC: ben@nostrum.com, mmusic@ietf.org, mmusic-chairs@ietf.org, Flemming Andreasen , fandreas@cisco.com, draft-ietf-mmusic-rid@ietf.org Reply-To: ietf@ietf.org Sender: Subject: Last Call: (RTP Payload Format Restrictions) to Proposed Standard The IESG has received a request from the Multiparty Multimedia Session Control WG (mmusic) to consider the following document: - 'RTP Payload Format Restrictions' 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 2018-03-06. 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 In this specification, we define a framework for specifying restrictions on RTP streams in the Session Description Protocol. This framework defines a new "rid" SDP attribute to unambiguously identify the RTP Streams within a RTP Session and restrict the streams' payload format parameters in a codec-agnostic way beyond what is provided with the regular Payload Types. This specification updates RFC4855 to give additional guidance on choice of Format Parameter (fmtp) names, and on their relation to the restrictions defined by this document. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-mmusic-rid/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-mmusic-rid/ballot/ No IPR declarations have been submitted directly on this I-D. |
2018-02-20
|
13 | Amy Vezza | IESG state changed to In Last Call from Last Call Requested |
2018-02-20
|
13 | Amy Vezza | Last call announcement was changed |
2018-02-17
|
13 | Ben Campbell | Last call was requested |
2018-02-17
|
13 | Ben Campbell | IESG state changed to Last Call Requested from AD Evaluation |
2018-02-17
|
13 | Ben Campbell | Last call announcement was generated |
2018-02-17
|
13 | Ben Campbell | Ballot writeup was changed |
2018-02-17
|
13 | Ben Campbell | Ballot approval text was generated |
2018-02-16
|
13 | Ben Campbell | IESG state changed to AD Evaluation from Publication Requested::AD Followup |
2018-01-26
|
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 shows the Intended status as Standards Track, which is appropriate given that the document updates RFC 4855 (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. In this specification, we define a framework for specifying restrictions on RTP streams in the Session Description Protocol. This framework defines a new "rid" SDP attribute to unambiguously identify the RTP Streams within a RTP Session and restrict the streams' payload format parameters in a codec-agnostic way beyond what is provided with the regular Payload Types. This specification updates RFC4855 to give additional guidance on choice of Format Parameter (fmtp) names, and on their relation to the restrictions defined by this document. 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? No issues to note. 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 currently no known implementations of the protocol, however the document is a normative dependency for the W3C WebRTC specification. Personnel Who is the Document Shepherd? Who is the Responsible Area Director? Flemming Andreasen is the Document Shepherd Ben Campbell is the Responsible Area Direction (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 -08 of the draft in detail, which resulted in a few updates. I have reviewed the subsequent changes as well. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No concern. Several people have reviewed slightly earlier versions of the document which are substantially similar to the current document. The recent changes (up to -12) have been discussed on the WG list and in meetings as well. Discussions on a related draft in the most recent IETF meeting (Singapore, 100) recently led to a few minor updates related to RTP Stream Redundancy and RTP Redundancy Payload Format. The resulting update was announced on the MMUSIC mailing list with no further comments received. (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 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. 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. N/A (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 solid consensus in the WG with several people having both participated and reviewed the document. (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. No nits found. The idnits tool does produce a couple of warnings, however none of them apply except for one: The reference to RFC 5226 should be replaced with a reference to RFC 8126, which can be done 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. 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? Yes. The document normatively references draft-ietf-avtext-rid-09 which is currently with RFC Editor (in MISSREF state). (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. N/A (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 status change, however the document does update RFC 4855, which is called out on in the title page header and abstract. The document discusses the updated mechanism in the Introduction but does not specifically call out RFC 4855. (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 document defines a new SDP attribute which has a proper IANA registration (per RFC 4566) in the IANA Considerations section The document also defines a new IANA registry within the SDP parameters registry. This new registry is well defined incl initial values and a "Specification Required" policy for the registry. Adam Roach (adam@nostrum.com) has volunteered to be Designated Expert for the registry. (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. See above. (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. ABNF has been verified with Bill Fenner's ABNF parser. |
2018-01-26
|
13 | Flemming Andreasen | IESG state changed to Publication Requested from AD is watching |
2018-01-26
|
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 shows the Intended status as Standards Track, which is appropriate given that the document updates RFC 4855 (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. In this specification, we define a framework for specifying restrictions on RTP streams in the Session Description Protocol. This framework defines a new "rid" SDP attribute to unambiguously identify the RTP Streams within a RTP Session and restrict the streams' payload format parameters in a codec-agnostic way beyond what is provided with the regular Payload Types. This specification updates RFC4855 to give additional guidance on choice of Format Parameter (fmtp) names, and on their relation to the restrictions defined by this document. 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? No issues to note. 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 currently no known implementations of the protocol, however the document is a normative dependency for the W3C WebRTC specification. Personnel Who is the Document Shepherd? Who is the Responsible Area Director? Flemming Andreasen is the Document Shepherd Ben Campbell is the Responsible Area Direction (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 -08 of the draft in detail, which resulted in a few updates. I have reviewed the subsequent changes as well. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No concern. Several people have reviewed slightly earlier versions of the document which are substantially similar to the current document. The recent changes (up to -12) have been discussed on the WG list and in meetings as well. Discussions on a related draft in the most recent IETF meeting (Singapore, 100) recently led to a few minor updates related to RTP Stream Redundancy and RTP Redundancy Payload Format. The resulting update was announced on the MMUSIC mailing list with no further comments received. (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 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. 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. N/A (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 solid consensus in the WG with several people having both participated and reviewed the document. (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. No nits found. The idnits tool does produce a couple of warnings, however none of them apply except for one: The reference to RFC 5226 should be replaced with a reference to RFC 8126, which can be done 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. 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? Yes. The document normatively references draft-ietf-avtext-rid-09 which is currently with RFC Editor (in MISSREF state). (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. N/A (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 status change, however the document does update RFC 4855, which is called out on in the title page header and abstract. The document discusses the updated mechanism in the Introduction but does not specifically call out RFC 4855. (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 document defines a new SDP attribute which has a proper IANA registration (per RFC 4566) in the IANA Considerations section The document also defines a new IANA registry within the SDP parameters registry. This new registry is well defined incl initial values and a "Specification Required" policy for the registry. Adam Roach (adam@nostrum.com) has volunteered to be Designated Expert for the registry. (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. See above. (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. ABNF has been verified with Bill Fenner's ABNF parser. |
2018-01-17
|
13 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2018-01-17
|
13 | Adam Roach | New version available: draft-ietf-mmusic-rid-13.txt |
2018-01-17
|
13 | (System) | New version approved |
2018-01-17
|
13 | (System) | Request for posting confirmation emailed to previous authors: Adam Roach |
2018-01-17
|
13 | Adam Roach | Uploaded new revision |
2017-11-15
|
12 | Ben Campbell | IESG state changed to AD is watching::Revised I-D Needed from Publication Requested |
2017-11-14
|
12 | 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 shows the Intended status as Standards Track, which is appropriate given that the document updates RFC 4855 (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. In this specification, we define a framework for specifying restrictions on RTP streams in the Session Description Protocol. This framework defines a new "rid" SDP attribute to unambiguously identify the RTP Streams within a RTP Session and restrict the streams' payload format parameters in a codec-agnostic way beyond what is provided with the regular Payload Types. This specification updates RFC4855 to give additional guidance on choice of Format Parameter (fmtp) names, and on their relation to the restrictions defined by this document. 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? No issues to note. 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 currently no known implementations of the protocol, however the document is a normative dependency for the W3C WebRTC specification. Personnel Who is the Document Shepherd? Who is the Responsible Area Director? Flemming Andreasen is the Document Shepherd Ben Campbell is the Responsible Area Direction (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 -08 of the draft in detail, which resulted in a few updates. I have reviewed the subsequent changes as well. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No concern. Several people have reviewed slightly earlier versions of the document which are substantially similar to the current document. The recent changes have been discussed on the WG list and in meetings as well. (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 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. 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. N/A (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 solid consensus in the WG with several people having both participated and reviewed the document. (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. No nits found. The idnits tool does produce a couple of warnings, however none of them apply except for one: The reference to RFC 5226 should be replaced with a reference to RFC 8126, which can be done 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. 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? Yes. The document normatively references draft-ietf-avtext-rid-09 which is currently with RFC Editor (in MISSREF state). (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. N/A (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 status change, however the document does update RFC 4855, which is called out on in the title page header and abstract. The document discusses the updated mechanism in the Introduction but does not specifically call out RFC 4855. (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 document defines a new SDP attribute which has a proper IANA registration (per RFC 4566) in the IANA Considerations section The document also defines a new IANA registry within the SDP parameters registry. This new registry is well defined incl initial values and a "Specification Required" policy for the registry. Adam Roach (adam@nostrum.com) has volunteered to be Designated Expert for the registry. (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. See above. (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. ABNF has been verified with Bill Fenner's ABNF parser. |
2017-11-14
|
12 | Flemming Andreasen | Responsible AD changed to Ben Campbell |
2017-11-14
|
12 | Flemming Andreasen | IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up |
2017-11-14
|
12 | Flemming Andreasen | IESG state changed to Publication Requested |
2017-11-14
|
12 | Flemming Andreasen | IESG process started in state Publication Requested |
2017-11-14
|
12 | Flemming Andreasen | Tag Doc Shepherd Follow-up Underway cleared. |
2017-11-14
|
12 | Flemming Andreasen | Changed document writeup |
2017-11-13
|
12 | Adam Roach | New version available: draft-ietf-mmusic-rid-12.txt |
2017-11-13
|
12 | (System) | New version approved |
2017-11-13
|
12 | (System) | Request for posting confirmation emailed to previous authors: mmusic-chairs@ietf.org, Adam Roach , Bo Burman , Mo Zanaty , Suhas Nandakumar , Byron Campen , … Request for posting confirmation emailed to previous authors: mmusic-chairs@ietf.org, Adam Roach , Bo Burman , Mo Zanaty , Suhas Nandakumar , Byron Campen , Peter Thatcher |
2017-11-13
|
12 | Adam Roach | Uploaded new revision |
2017-11-02
|
11 | Flemming Andreasen | Tag Doc Shepherd Follow-up Underway set. Tag Revised I-D Needed - Issue raised by WG cleared. |
2017-07-28
|
11 | Adam Roach | Changed consensus to Yes from Unknown |
2017-07-28
|
11 | Adam Roach | Intended Status changed to Proposed Standard from None |
2017-07-19
|
11 | Adam Roach | New version available: draft-ietf-mmusic-rid-11.txt |
2017-07-19
|
11 | (System) | New version approved |
2017-07-19
|
11 | (System) | Request for posting confirmation emailed to previous authors: Adam Roach , Bo Burman , Mo Zanaty , Suhas Nandakumar , Peter Thatcher , Byron Campen |
2017-07-19
|
11 | Adam Roach | Uploaded new revision |
2017-06-16
|
10 | Flemming Andreasen | Tag Revised I-D Needed - Issue raised by WG set. |
2017-03-29
|
10 | Bo Burman | Added to session: IETF-98: mmusic Thu-1300 |
2017-03-13
|
10 | Adam Roach | New version available: draft-ietf-mmusic-rid-10.txt |
2017-03-13
|
10 | (System) | New version approved |
2017-03-13
|
10 | (System) | Request for posting confirmation emailed to previous authors: Adam Roach , Bo Burman , Mo Zanaty , Suhas Nandakumar , Peter Thatcher , Byron Campen |
2017-03-13
|
10 | Adam Roach | Uploaded new revision |
2017-02-08
|
09 | Adam Roach | New version available: draft-ietf-mmusic-rid-09.txt |
2017-02-08
|
09 | (System) | New version approved |
2017-02-08
|
09 | (System) | Request for posting confirmation emailed to previous authors: "Mo Zanaty" , "Adam Roach" , "Peter Thatcher" , "Bo Burman" , "Suhas Nandakumar" , "Byron Campen" |
2017-02-08
|
09 | Adam Roach | Uploaded new revision |
2017-01-12
|
08 | Flemming Andreasen | IETF WG state changed to WG Consensus: Waiting for Write-Up from In WG Last Call |
2016-10-25
|
08 | Adam Roach | New version available: draft-ietf-mmusic-rid-08.txt |
2016-10-25
|
08 | (System) | New version approved |
2016-10-25
|
07 | (System) | Request for posting confirmation emailed to previous authors: "Mo Zanaty" , "Adam Roach" , "Peter Thatcher" , "Bo Burman" , "Suhas Nandakumar" , "Byron Campen" |
2016-10-25
|
07 | Adam Roach | Uploaded new revision |
2016-07-18
|
07 | Adam Roach | New version available: draft-ietf-mmusic-rid-07.txt |
2016-07-07
|
06 | Flemming Andreasen | IETF WG state changed to In WG Last Call from WG Document |
2016-07-07
|
06 | Adam Roach | New version available: draft-ietf-mmusic-rid-06.txt |
2016-03-28
|
05 | Naveen Khan | New version available: draft-ietf-mmusic-rid-05.txt |
2016-02-08
|
04 | Adam Roach | New version available: draft-ietf-mmusic-rid-04.txt |
2016-02-05
|
03 | Adam Roach | New version available: draft-ietf-mmusic-rid-03.txt |
2016-02-03
|
02 | Adam Roach | New version available: draft-ietf-mmusic-rid-02.txt |
2016-02-01
|
01 | Adam Roach | New version available: draft-ietf-mmusic-rid-01.txt |
2015-11-20
|
00 | Flemming Andreasen | Notification list changed to "Flemming Andreasen" <fandreas@cisco.com> |
2015-11-20
|
00 | Flemming Andreasen | Document shepherd changed to Flemming Andreasen |
2015-11-11
|
00 | Flemming Andreasen | This document now replaces draft-pthatcher-mmusic-rid instead of None |
2015-11-11
|
00 | Adam Roach | New version available: draft-ietf-mmusic-rid-00.txt |