Negotiation Data Channels Using the Session Description Protocol (SDP)
draft-ietf-mmusic-data-channel-sdpneg-28
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2021-01-18
|
28 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2020-07-22
|
28 | (System) | RFC Editor state changed to AUTH48 from RFC-EDITOR |
2020-03-16
|
28 | (System) | RFC Editor state changed to RFC-EDITOR from REF |
2020-01-24
|
28 | (System) | RFC Editor state changed to REF from EDIT |
2019-08-26
|
28 | Gunter Van de Velde | Assignment of request for Last Call review by OPSDIR to Susan Hares was marked no-response |
2019-08-20
|
28 | (System) | RFC Editor state changed to EDIT from MISSREF |
2019-05-29
|
28 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2019-05-27
|
28 | (System) | IANA Action state changed to Waiting on RFC Editor from Waiting on Authors |
2019-05-24
|
28 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2019-05-21
|
28 | (System) | RFC Editor state changed to MISSREF |
2019-05-21
|
28 | (System) | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2019-05-21
|
28 | (System) | Announcement was received by RFC Editor |
2019-05-21
|
28 | (System) | IANA Action state changed to In Progress |
2019-05-21
|
28 | Cindy Morgan | IESG state changed to Approved-announcement sent from Approved-announcement to be sent |
2019-05-21
|
28 | Cindy Morgan | IESG has approved the document |
2019-05-21
|
28 | Cindy Morgan | Closed "Approve" ballot |
2019-05-21
|
28 | Cindy Morgan | Ballot approval text was generated |
2019-05-21
|
28 | Adam Roach | IESG state changed to Approved-announcement to be sent from IESG Evaluation::AD Followup |
2019-05-11
|
28 | Roni Even | New version available: draft-ietf-mmusic-data-channel-sdpneg-28.txt |
2019-05-11
|
28 | (System) | New version approved |
2019-05-11
|
28 | (System) | Request for posting confirmation emailed to previous authors: mmusic-chairs@ietf.org, Jerome Marcon , Richard Ejzak , Maridi Makaraju , Keith Drage , Roni Even |
2019-05-11
|
28 | Roni Even | Uploaded new revision |
2019-05-08
|
27 | Magnus Westerlund | [Ballot comment] Thanks for addressing my issues. |
2019-05-08
|
27 | Magnus Westerlund | [Ballot Position Update] Position for Magnus Westerlund has been changed to No Objection from Discuss |
2019-04-29
|
27 | Roni Even | New version available: draft-ietf-mmusic-data-channel-sdpneg-27.txt |
2019-04-29
|
27 | (System) | New version approved |
2019-04-29
|
27 | (System) | Request for posting confirmation emailed to previous authors: mmusic-chairs@ietf.org, Jerome Marcon , Richard Ejzak , Maridi Makaraju , Keith Drage , Roni Even |
2019-04-29
|
27 | Roni Even | Uploaded new revision |
2019-04-25
|
26 | Roman Danyliw | [Ballot comment] Thank you for addressing my DISCUSSes and comments. |
2019-04-25
|
26 | Roman Danyliw | [Ballot Position Update] Position for Roman Danyliw has been changed to No Objection from Discuss |
2019-04-23
|
26 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2019-04-23
|
26 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA - Not OK |
2019-04-23
|
26 | Roni Even | New version available: draft-ietf-mmusic-data-channel-sdpneg-26.txt |
2019-04-23
|
26 | (System) | New version approved |
2019-04-23
|
26 | (System) | Request for posting confirmation emailed to previous authors: mmusic-chairs@ietf.org, Jerome Marcon , Richard Ejzak , Maridi Makaraju , Keith Drage , Roni Even |
2019-04-23
|
26 | Roni Even | Uploaded new revision |
2019-04-11
|
25 | Cindy Morgan | IESG state changed to IESG Evaluation::Revised I-D Needed from Waiting for AD Go-Ahead |
2019-04-10
|
25 | Benjamin Kaduk | [Ballot comment] Section 4 The mechanism in this document only applies to the Session Description Protocol (SDP) [I-D.ietf-mmusic-rfc4566bis] when used … [Ballot comment] Section 4 The mechanism in this document only applies to the Session Description Protocol (SDP) [I-D.ietf-mmusic-rfc4566bis] when used together with the SDP offer/answer mechanism [RFC3264]. Declarative usage of SDP is out of scope of this document, and is thus undefined. nit: this text doesn't actually scope itself to "this mechanism" or the RTCWeb data channel, and seems to be saying that all declarative SDP is undefined, globally. Section 5.1.7 The ordered parameter is optional and takes two values: "true" for ordered and "false" for unordered delivery with "true" as the default value. Any other value is ignored and default "ordered=true" is assumed. [...] This seems to be saying that offers or answers that do not conform to the ABNF will be special-cased as being ignored (instead of rejected) when they appear where ordering-value should appear. It's not clear to me why we need a special case here, since in Section 8 we explicitly say that peers MUST close the relevant data channel when such error cases occur. Section 5.1.8 If we chase links to draft-ietf-rtcweb-data-channel we find that larger values indicate higher priority. Do we want to short-circuit that and say so explicitly here? Section 5.2 Each of these attributes is represented by one new attribute line, and it includes the contents of a media-level SDP attribute already defined for use with this (sub)protocol in another IETF (Internet Engineering Task Force) document. [...] Do we need to limit the data-channel subprotocols to those specified by the IETF? Or is it just the media-level SDP attributes that we are trying to maintain change control over? The detailed offer/answer procedures for the dcsa attribute are dependent on the associated sub-protocol. If no offer/answer procedures exist for the sub-protocol when used outside of the dcsa attribute, no specification is needed for use with dcsa. The IANA registration procedures for the WebSocket Subprotocol Name Registry (Section 9.1) do not strictly require a specification of the offer/ answer procedures for the sub-protocol when used with dcsa. If the sub-protocol has defined offer/answer procedures when used outside of dcsa, such a specification is encouraged to ensure interoperability. If the sub-protocol has defined offer/answer procedures when used outside of dcsa, but no specification exists for the offer/answer procedures for the sub-protocol when used with dcsa, implementations SHOULD assume the use of the default values for all otherwise- negotiable and applicable sub-protocol parameters. I'm not entirely sure I understand what this paragraph is trying to say. The first sentence is clear, but the second sentence seems to be saying that if there are no O/A procedures for a given subprotocol outside the datachannel, it's just a free for all and I can use it in the data channel and make up my own procedures for using the dcsa attribute. I understand that IANA doesn't require a specification for the subprotocol when allocating the subprotocol name, but that just means that there may not be a specification available whether or not I want to use it with dcsa -- the IANA registry doesn't care directly about use with dcsa. If a subprotocol has defined O/A procedures outside of dcsa, doesn't that basically mean there's a specification? Why do we need to go out of our way to encourage a specification in that case (and is it a specification of the O/A semantics when the subprotocol is used outside dcsa or with dcsa)? In the last sentence, I think we're talking about using defaults for parameters that are not explicitly negotiated using dcsa, but we don't actually say that. Section 5.2.1 Note however that not all SDP attributes are suitable as a "a=dcsa:" parameter. IANA SDP parameters contains the lists of IANA (Internet Assigned Numbers Authority) registered session and media level or media level only SDP attributes. Am I supposed to infer that these are the attributes that are suitable for a=dcsa: parameters? As opposed to the data channel "a=dcmap:" attribute parameters, these parameters are subject to offer/answer negotiation following the procedures defined in the subprotocol specific documents. I am not sure where we really say that the a=dcmap: parameters are not subject to O/A negotiation. Section 6.1 SCTP stream identifiers associated with data channels that have been negotiated using DCEP MUST NOT be included in SDP offers and answers. This sentence appears as a dedicated paragraph and is duplicated at the end of the previous paragraph; presumably we only need one copy thereof... Section 6.2 If an SDP answer contains both of these parameters then the offerer MUST treat the associated SDP offer/answer failed. nit: "as failed", I think. Section 6.4 We only mention that the dcmap-stream-id, max-retr, and max-time values need to match the offer, leaving the ordering/subprotocol/label/priority to be omitted because they are conveyed at the SCTP layer? Perhaps we should state explicitly that they need to be absent... Section 6.6 Do we want to say anything about the appropriate response to receiving changed values for the SDP attributes/attribute values is to close the corresponding data channel? Section 6.6.1 It seems like the second bullet point only makes sense after the first has completed, as the tsvart reviewer noted? Specifically, the "; or" at the end of the first bullet point doesn't seem to make much sense. Section 9.3 If existing media attributes are used in a datachannel subprotocol specific way (Section 5.2.1), then a new dcsa usage level MUST be defined for the existing media attribute. [...] I'm not entirely sure that I understand what this means, though I'm not really an expert in SDP. Appendix A.1 I'm not sure that I know what "glare situations" are; is there a reasonable reference to include? Which set of stream identifiers is owned by which endpoint is determined by convention or other means. (specific to the application?) Note:For data channels negotiated via different protocol from DCEP, no convention is defined by default. That seems a bit misleading, since Section 6.1 says that the even/odd split applies to the SDP O/A negotiation case. |
2019-04-10
|
25 | Benjamin Kaduk | [Ballot Position Update] New position, No Objection, has been recorded for Benjamin Kaduk |
2019-04-10
|
25 | Martin Vigoureux | [Ballot Position Update] New position, No Objection, has been recorded for Martin Vigoureux |
2019-04-09
|
25 | Suresh Krishnan | [Ballot Position Update] New position, No Objection, has been recorded for Suresh Krishnan |
2019-04-09
|
25 | Deborah Brungard | [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard |
2019-04-09
|
25 | Roman Danyliw | [Ballot comment] (1) Section 1. Editorial Nits. s/The concept of establishing a bi-directional data channel running on top of the Stream Control Transmission Protocol (SCTP) … [Ballot comment] (1) Section 1. Editorial Nits. s/The concept of establishing a bi-directional data channel running on top of the Stream Control Transmission Protocol (SCTP) is in [I-D.ietf-rtcweb-data-channel] allowing applications to use data channels./ The concept of establishing a bi-directional data channel running on top of the Stream Control Transmission Protocol (SCTP) in [I-D.ietf-rtcweb-data-channel] allows applications to use data channels./ s/An in-band Data Channel Establishment Protocol (DCEP) is in [I-D.ietf-rtcweb-data-protocol], however other in-band or out-of-band protocols may be used for establishing data channels./ In addition to the in-band Data Channel Establishment Protocol (DCEP), other in-band and out-of-band protocols may be used for establishing data channels/ (2) Section 1. Typo (extra space between close bracket and period) s/For MSRP they are documented in [I-D.ietf-mmusic-msrp-usage-data-channel] ./ For MSRP they are documented in [I-D.ietf-mmusic-msrp-usage-data-channel]./ (3) Section 3. Editorial Nit. old: "delivery... )."; new: "delivery, etc.)." (4) Section 6.1. Editorial Nit. There appears to be two instances of the sentence, “SCTP stream identifiers associated with data channels that have been negotiated using DCEP MUST NOT be included in SDP offers and answers.” (5) Section 6.5. The sentence “Note: DCEP is not used, that is neither the SDP offerer nor the SDP answerer send an in-band DCEP DATA_CHANNEL_OPEN message” uses a triple negative so the guidance is not clear. (6) Section 6.7, Per “SDP offer or answer has an "a=dcsa" attribute, whose subprotocol attribute is known, but whose subprotocol attribute semantic is not known for the data channel transport case”, consider a case where the sub-protocol attribute is known but the value is invalid. Is that case a sub-set of what is meant by the “attribute semantic is not known”? |
2019-04-09
|
25 | Roman Danyliw | Ballot comment text updated for Roman Danyliw |
2019-04-09
|
25 | Roman Danyliw | [Ballot discuss] (1) Section 5.2.1. The ABNF of stream-id of “dcsa-value = stream-id …” does not appear to be defined explicitly or by reference in … [Ballot discuss] (1) Section 5.2.1. The ABNF of stream-id of “dcsa-value = stream-id …” does not appear to be defined explicitly or by reference in the draft. (2) Section 6.6, “… the offerer SHALL include previously negotiated SDP attributes … associated with the channel”. What is the behavior of the receiver if the attributes included by the offerer are NOT those that were previously negotiated? |
2019-04-09
|
25 | Roman Danyliw | [Ballot comment] (1) Section 1. Editorial Nits. s/The concept of establishing a bi-directional data channel running on top of the Stream Control Transmission Protocol (SCTP) … [Ballot comment] (1) Section 1. Editorial Nits. s/The concept of establishing a bi-directional data channel running on top of the Stream Control Transmission Protocol (SCTP) is in [I-D.ietf-rtcweb-data-channel] allowing applications to use data channels./ The concept of establishing a bi-directional data channel running on top of the Stream Control Transmission Protocol (SCTP) in [I-D.ietf-rtcweb-data-channel] allows applications to use data channels./ s/An in-band Data Channel Establishment Protocol (DCEP) is in [I-D.ietf-rtcweb-data-protocol], however other in-band or out-of-band protocols may be used for establishing data channels./ In addition to the in-band Data Channel Establishment Protocol (DCEP), other in-band and out-of-band protocols may be used for establishing data channels/ (2) Section 1. Typo (extra space between close bracket and period) s/For MSRP they are documented in [I-D.ietf-mmusic-msrp-usage-data-channel] ./ For MSRP they are documented in [I-D.ietf-mmusic-msrp-usage-data-channel]./ (3) Section 3. Editorial Nit. s/delivery... )./delivery, etc.).. (4) Section 6.1. Editorial Nit. There appears to be two instances of the sentence, “SCTP stream identifiers associated with data channels that have been negotiated using DCEP MUST NOT be included in SDP offers and answers.” (5) Section 6.5. The sentence “Note: DCEP is not used, that is neither the SDP offerer nor the SDP answerer send an in-band DCEP DATA_CHANNEL_OPEN message” uses a triple negative so the guidance is not clear. (6) Section 6.7, Per “SDP offer or answer has an "a=dcsa" attribute, whose subprotocol attribute is known, but whose subprotocol attribute semantic is not known for the data channel transport case”, consider a case where the sub-protocol attribute is known but the value is invalid. Is that case a sub-set of what is meant by the “attribute semantic is not known”? |
2019-04-09
|
25 | Roman Danyliw | [Ballot Position Update] New position, Discuss, has been recorded for Roman Danyliw |
2019-04-08
|
25 | Warren Kumari | [Ballot comment] I agree with the other comments on Labels, but will let others carry the positions.... |
2019-04-08
|
25 | Warren Kumari | [Ballot Position Update] New position, No Objection, has been recorded for Warren Kumari |
2019-04-08
|
25 | Ignas Bagdonas | [Ballot comment] A couple of nits: s7: are examples for SDP offer correct? c= addrtype IP6 is listed twice there. s9.2.1, s9.2.2: s/IESG Chairs/IESG |
2019-04-08
|
25 | Ignas Bagdonas | Ballot comment text updated for Ignas Bagdonas |
2019-04-08
|
25 | Ignas Bagdonas | [Ballot comment] A nit - are examples in section 7 correct? c= addrtype IP6 is listed twice there. |
2019-04-08
|
25 | Ignas Bagdonas | [Ballot Position Update] New position, No Objection, has been recorded for Ignas Bagdonas |
2019-04-08
|
25 | Alissa Cooper | [Ballot comment] In Section 2, please use the exact boilerplate from RFC 8174. |
2019-04-08
|
25 | Alissa Cooper | [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper |
2019-04-07
|
25 | Barry Leiba | [Ballot comment] I agree with Magnus’s DISCUSS. Please use the full BCP 14 boilerplate from RFC 8174, rather than abridging it. — Section 5.1.1 … [Ballot comment] I agree with Magnus’s DISCUSS. Please use the full BCP 14 boilerplate from RFC 8174, rather than abridging it. — Section 5.1.1 — Within an 'a=dcmap:' attribute line's 'dcmap-opt' value only one 'maxretr-opt' parameter or one 'maxtime-opt' parameter MAY be present. Both MUST NOT be present. Lower case “may” here, please. The MUST NOT is the normative bit. — Section 9 subsections — Instances of “IESG Chairs” should just say “IESG”. |
2019-04-07
|
25 | Barry Leiba | [Ballot Position Update] New position, No Objection, has been recorded for Barry Leiba |
2019-04-06
|
25 | Alexey Melnikov | [Ballot comment] I agree with Magnus about UTF-8 in quoted strings for labels. |
2019-04-06
|
25 | Alexey Melnikov | [Ballot Position Update] New position, No Objection, has been recorded for Alexey Melnikov |
2019-04-05
|
25 | Mirja Kühlewind | [Ballot comment] Thanks for quickly addressing the comments from the TSV-ART review regarding interactions with SCTP (and thanks Micheal T. for the review!)! One minor, … [Ballot comment] Thanks for quickly addressing the comments from the TSV-ART review regarding interactions with SCTP (and thanks Micheal T. for the review!)! One minor, more editorial comment on max-time parameter: draft-ietf-rtcweb-data-protocol says "This life-time starts when providing the user message to the protocol stack.". While a reference to draft-ietf-rtcweb-data-protocol is given respectively, I would recommend to also clarify in this draft which time frame is meant given this time frame includes and end-to-end delays. As a side note: not sure it is necessary to expand IETF (Internet Engineering Task Force) (see sec 5.2) in an IETF RFC but the RFC editor might tell you... |
2019-04-05
|
25 | Mirja Kühlewind | [Ballot Position Update] New position, No Objection, has been recorded for Mirja Kühlewind |
2019-04-05
|
25 | Magnus Westerlund | [Ballot discuss] There might be a serious issue in label definition. 5.1.3. Label Parameter The 'label' parameter indicates the name of the channel. It … [Ballot discuss] There might be a serious issue in label definition. 5.1.3. Label Parameter The 'label' parameter indicates the name of the channel. It represents a label that can be used to distinguish, in the context of the WebRTC API [WebRtcAPI], an RTCDataChannel object from other RTCDataChannel objects. This parameter maps to the 'Label' parameter defined in [I-D.ietf-rtcweb-data-protocol]. The 'label' parameter is optional. If it is not present, then its value defaults to the empty string. label-opt = "label=" quoted-string quoted-string = DQUOTE *(quoted-char / escaped-char) DQUOTE quoted-char = SP / quoted-visible quoted-visible = %x21 / %x23-24 / %x26-7E ; VCHAR without " or % escaped-char = "%" HEXDIG HEXDIG I interpret that as the intention is to enable the SDP Attribute to carry the label as defined in W3C API. That value is in the current candidatate specification an https://www.w3.org/TR/webrtc/ as an USVSsting (https://heycam.github.io/webidl/#idl-USVString). And in the reference version of the WebRTC API as an DOMstring. Both are not limited to ASCII and may contain any Unicode characters. Thus the escaping mechanism defined appear to be insufficient. I think the "quoted-string" need a definition of what type of string this truly are so that it is clear what a character in the string is. In addition the specification of escaping is undersspecified. I would recommend at least adding discussion of the need and how to escape DQUOTE and % that can be relatively common operations. |
2019-04-05
|
25 | Magnus Westerlund | [Ballot comment] Section 5.1.3: Is it correct that there are no limiation on the lenght of the label? So it will okay if I use … [Ballot comment] Section 5.1.3: Is it correct that there are no limiation on the lenght of the label? So it will okay if I use the more than 450k words of J.R.R.R Tolkien's Lords of the Ring as label? [WebRtcAPI] Is it really the intention to point to the very old version of the API from 2015? The current candidate specification is available here: https://www.w3.org/TR/webrtc/ and are from 2018. |
2019-04-05
|
25 | Magnus Westerlund | Ballot comment and discuss text updated for Magnus Westerlund |
2019-04-05
|
25 | Magnus Westerlund | [Ballot discuss] There might be a serious issue in label definition. 5.1.3. Label Parameter The 'label' parameter indicates the name of the channel. It … [Ballot discuss] There might be a serious issue in label definition. 5.1.3. Label Parameter The 'label' parameter indicates the name of the channel. It represents a label that can be used to distinguish, in the context of the WebRTC API [WebRtcAPI], an RTCDataChannel object from other RTCDataChannel objects. This parameter maps to the 'Label' parameter defined in [I-D.ietf-rtcweb-data-protocol]. The 'label' parameter is optional. If it is not present, then its value defaults to the empty string. label-opt = "label=" quoted-string quoted-string = DQUOTE *(quoted-char / escaped-char) DQUOTE quoted-char = SP / quoted-visible quoted-visible = %x21 / %x23-24 / %x26-7E ; VCHAR without " or % escaped-char = "%" HEXDIG HEXDIG I interpret that as the intention is to enable the SDP Attribute to carry the label as defined in W3C API. That value is in the current candidatate specification an https://www.w3.org/TR/webrtc/ as an USVSsting (https://heycam.github.io/webidl/#idl-USVString). And in the reference version of the WebRTC API as an DOMstring. Both are not limited to ASCII and may contain any Unicode characters. Thus the escaping mechanism defined appear to be insufficient. |
2019-04-05
|
25 | Magnus Westerlund | [Ballot comment] [WebRtcAPI] Is it really the intention to point to the very old version of the API from 2015? The current candidate specification is … [Ballot comment] [WebRtcAPI] Is it really the intention to point to the very old version of the API from 2015? The current candidate specification is available here: https://www.w3.org/TR/webrtc/ and are from 2018. |
2019-04-05
|
25 | Magnus Westerlund | [Ballot Position Update] New position, Discuss, has been recorded for Magnus Westerlund |
2019-04-04
|
25 | (System) | IANA Review state changed to IANA - Not OK from Version Changed - Review Needed |
2019-04-04
|
25 | Linda Dunbar | Request for Telechat review by GENART Completed: Ready. Reviewer: Linda Dunbar. Sent review to list. |
2019-03-28
|
25 | Jean Mahoney | Request for Telechat review by GENART is assigned to Linda Dunbar |
2019-03-28
|
25 | Jean Mahoney | Request for Telechat review by GENART is assigned to Linda Dunbar |
2019-03-26
|
25 | Cindy Morgan | Placed on agenda for telechat - 2019-04-11 |
2019-03-26
|
25 | Adam Roach | Ballot has been issued |
2019-03-26
|
25 | Adam Roach | [Ballot Position Update] New position, Yes, has been recorded for Adam Roach |
2019-03-26
|
25 | Adam Roach | Created "Approve" ballot |
2019-03-26
|
25 | Adam Roach | Ballot writeup was changed |
2019-03-26
|
25 | Adam Roach | Shepherding AD changed to Adam Roach |
2019-03-21
|
25 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA - Not OK |
2019-03-21
|
25 | Cindy Morgan | New version available: draft-ietf-mmusic-data-channel-sdpneg-25.txt |
2019-03-21
|
25 | (System) | Secretariat manually posting. Approvals already received |
2019-03-21
|
25 | Cindy Morgan | Uploaded new revision |
2019-03-20
|
24 | Jean Mahoney | Closed request for Last Call review by GENART with state 'No Response' |
2019-03-19
|
24 | Michael Tüxen | Request for Last Call review by TSVART Completed: Ready with Nits. Reviewer: Michael Tüxen. Sent review to list. |
2019-03-18
|
24 | (System) | IANA Review state changed to IANA - Not OK from IANA - Review Needed |
2019-03-18
|
24 | Sabrina Tanamal | (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has completed its review of draft-ietf-mmusic-data-channel-sdpneg-24. If any part of this review is inaccurate, please let … (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has completed its review of draft-ietf-mmusic-data-channel-sdpneg-24. If any part of this review is inaccurate, please let us know. The IANA Functions Operator has a question about one of the actions requested in the IANA Considerations section of this document. The IANA Functions Operator understands that, upon approval of this document, there are three actions which we must complete. First, in the WebSocket Subprotocol Name Registry located at: https://www.iana.org/assignments/websocket/ modifications will be made. The following note should be added to the registry: This table also includes subprotocol identifiers specified for usage within a WebRTC data channel. [ RFC-to-be ] is to be added as a reference to the existing registry. Second, 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/ two, new registrations will be made as follows: Type: att-field (media level only) SDP Name: dcmap Mux Category: SPECIAL Reference: [ RFC-to-be ] Type: att-field (media level only) SDP Name: dcsa Mux Category: SPECIAL Reference: [ RFC-to-be ] As this document requests registrations in a Specification Required (see RFC 8126) 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. Third, Section 9.3 of the current document appears to request the creation of a new registry in the Session Description Protocol (SDP) Parameters registry located at: https://www.iana.org/assignments/sdp-parameters/ IANA Question --> The new registry might be modeled upon the existing att-field (. . . level) registries but instead be a registry for att-field (dcsa level). Is this correct? Would the new registry have the same characteristics as other att-field registries on the registry page? Could the draft be revised to explicitly create the registry, if this is correct? Are there any initial registrations in this new registry? The IANA Functions Operator understands that these are the only actions 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 meant only to confirm the list of actions that will be performed. Thank you, Sabrina Tanamal Senior IANA Services Specialist |
2019-03-18
|
24 | (System) | IESG state changed to Waiting for AD Go-Ahead from In Last Call |
2019-03-14
|
24 | Tero Kivinen | Request for Last Call review by SECDIR Completed: Has Nits. Reviewer: Steve Hanna. |
2019-03-11
|
24 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Susan Hares |
2019-03-11
|
24 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Susan Hares |
2019-03-08
|
24 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Steve Hanna |
2019-03-08
|
24 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Steve Hanna |
2019-03-08
|
24 | Dan Harkins | Assignment of request for Last Call review by SECDIR to Dan Harkins was rejected |
2019-03-07
|
24 | Jean Mahoney | Request for Last Call review by GENART is assigned to Matthew Miller |
2019-03-07
|
24 | Jean Mahoney | Request for Last Call review by GENART is assigned to Matthew Miller |
2019-03-07
|
24 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Dan Harkins |
2019-03-07
|
24 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Dan Harkins |
2019-03-05
|
24 | Magnus Westerlund | Request for Last Call review by TSVART is assigned to Michael Tüxen |
2019-03-05
|
24 | Magnus Westerlund | Request for Last Call review by TSVART is assigned to Michael Tüxen |
2019-03-04
|
24 | Amy Vezza | IANA Review state changed to IANA - Review Needed |
2019-03-04
|
24 | Amy Vezza | The following Last Call announcement was sent out (ends 2019-03-18): From: The IESG To: IETF-Announce CC: ben@nostrum.com, draft-ietf-mmusic-data-channel-sdpneg@ietf.org, mmusic@ietf.org, mmusic-chairs@ietf.org, Bo … The following Last Call announcement was sent out (ends 2019-03-18): From: The IESG To: IETF-Announce CC: ben@nostrum.com, draft-ietf-mmusic-data-channel-sdpneg@ietf.org, mmusic@ietf.org, mmusic-chairs@ietf.org, Bo Burman , bo.burman@ericsson.com Reply-To: ietf@ietf.org Sender: Subject: Last Call: (SDP-based Data Channel Negotiation) to Proposed Standard The IESG has received a request from the Multiparty Multimedia Session Control WG (mmusic) to consider the following document: - 'SDP-based Data Channel Negotiation' 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 2019-03-18. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract Data channel setup can be done using either the in- band Data Channel Establishment Protocol (DCEP) or using some out-of- band non-DCEP protocol. This document specifies how the SDP (Session Description Protocol) offer/answer exchange can be used to achieve an out-of-band non-DCEP negotiation for establishing a data channel. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-mmusic-data-channel-sdpneg/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-mmusic-data-channel-sdpneg/ballot/ No IPR declarations have been submitted directly on this I-D. |
2019-03-04
|
24 | Amy Vezza | IESG state changed to In Last Call from Last Call Requested |
2019-03-04
|
24 | Ben Campbell | Last call was requested |
2019-03-04
|
24 | Ben Campbell | IESG state changed to Last Call Requested from AD Evaluation::AD Followup |
2019-03-04
|
24 | Ben Campbell | Last call announcement was generated |
2019-03-04
|
24 | Ben Campbell | Changed consensus to Yes from Unknown |
2019-03-04
|
24 | Ben Campbell | Ballot writeup was changed |
2019-03-04
|
24 | Ben Campbell | Ballot approval text was generated |
2019-03-04
|
24 | Roni Even | New version available: draft-ietf-mmusic-data-channel-sdpneg-24.txt |
2019-03-04
|
24 | (System) | New version approved |
2019-03-04
|
24 | (System) | Request for posting confirmation emailed to previous authors: mmusic-chairs@ietf.org, Jerome Marcon , Richard Ejzak , Maridi Makaraju , Keith Drage , Roni Even , … Request for posting confirmation emailed to previous authors: mmusic-chairs@ietf.org, Jerome Marcon , Richard Ejzak , Maridi Makaraju , Keith Drage , Roni Even , Juergen Stoetzer-Bradler |
2019-03-04
|
24 | Roni Even | Uploaded new revision |
2019-01-17
|
23 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2019-01-17
|
23 | Roni Even | New version available: draft-ietf-mmusic-data-channel-sdpneg-23.txt |
2019-01-17
|
23 | (System) | New version approved |
2019-01-17
|
23 | (System) | Request for posting confirmation emailed to previous authors: mmusic-chairs@ietf.org, Jerome Marcon , Richard Ejzak , Maridi Makaraju , Keith Drage , Roni Even , … Request for posting confirmation emailed to previous authors: mmusic-chairs@ietf.org, Jerome Marcon , Richard Ejzak , Maridi Makaraju , Keith Drage , Roni Even , Juergen Stoetzer-Bradler |
2019-01-17
|
23 | Roni Even | Uploaded new revision |
2018-11-28
|
22 | Ben Campbell | IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation::AD Followup |
2018-11-19
|
22 | Roni Even | New version available: draft-ietf-mmusic-data-channel-sdpneg-22.txt |
2018-11-19
|
22 | (System) | New version approved |
2018-11-19
|
22 | (System) | Request for posting confirmation emailed to previous authors: mmusic-chairs@ietf.org, Jerome Marcon , Richard Ejzak , Maridi Makaraju , Keith Drage , Roni Even , … Request for posting confirmation emailed to previous authors: mmusic-chairs@ietf.org, Jerome Marcon , Richard Ejzak , Maridi Makaraju , Keith Drage , Roni Even , Juergen Stoetzer-Bradler |
2018-11-19
|
22 | Roni Even | Uploaded new revision |
2018-10-23
|
21 | Bo Burman | Added to session: IETF-103: mmusic Thu-1350 |
2018-10-17
|
21 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2018-10-17
|
21 | Roni Even | New version available: draft-ietf-mmusic-data-channel-sdpneg-21.txt |
2018-10-17
|
21 | (System) | New version approved |
2018-10-17
|
21 | (System) | Request for posting confirmation emailed to previous authors: Jerome Marcon , Richard Ejzak , Maridi Makaraju , Keith Drage , Roni Even , Juergen Stoetzer-Bradler |
2018-10-17
|
21 | Roni Even | Uploaded new revision |
2018-08-27
|
20 | Ben Campbell | IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation |
2018-08-27
|
20 | Ben Campbell | This is my AD evaluation of draft-ietf-mmusic-data-channel-sdpneg-20. I think the draft is in pretty good shape, but I have some comments and questions I would … This is my AD evaluation of draft-ietf-mmusic-data-channel-sdpneg-20. I think the draft is in pretty good shape, but I have some comments and questions I would like to discuss prior to IETF last call. Please note that I have a question for the MMUSIC chairs in my second substantive comment. ----------------------- Substantive Comments: - There are 6 authors listed. Normally the limit is 5 unless there is a really good reason. Did all of the authors contribute substantial text? Could the author list be reduced to just editors, and have the rest in a “contributors” section? - I understand the MSRP data channel usage draft is effectively dead. Please consider whether you want continue to use it as an example if it is not likely to progress. (MMUSIC chairs: do you have thoughts on the likely future of the MSRP data channel usage draft?) §2: Unless you have a specific reason not to do so, please use the updated boilerplate from RFC 8174. §5.1: " It is assumed that the data channel properties (reliable/partially reliable, ordered/unordered) are suitable per the subprotocol transport requirements.” What does it mean to assume that? Consider a statement to the effect that the “properties need to be suitable” §5.1.7: I suspect the “MUST” in the first sentence is a statement of fact. Isn’t the actual normative requiremeint defined in rtcweb-data-protocol? If so, please use descriptive language here. §8: I am skeptical that this adds no security considerations above those in sctp-sdp. In particular, it seems worth mentioning that each subprotocol may come with it’s own security considerations that need to be documented as part of the subprotocol definition. (As an example, MSRP has security considerations about the URL used in the a=path attribute that would apply to any definition of the use of “path” at the dcsa level.) §9.1: What is the rational for sharing the websocket subprotocol registry rather than creating a new one for data channels? The websocket subprotocol name registry has a policy of “First Come First Served”. This draft seems to state requirements for subprotocol specifications, but FCFS does not require specifications. §12.2: It seems like the references to [I-D.ietf-rtcweb-data-protocol] and [RFC4960] should be normative. It’s not necessary to include references to IANA registries; just mention them in the text. Editorial Comments: - Abstract: The abstract will not age well. Years from now, no one will think in terms of what RTCWeb vs some other working group defined. I suggest recasting this in terms of the documents and protocols, not the working groups. (Comment repeats for introduction.) §1: - " Data channels are created by endpoint applications through the WebRTC API (Application Programming Interface), or other users of a data channel like CLUE [I-D.ietf-clue-datachannel]” Incomplete sentence--are there missing words? - “They can be used to transport proprietary or well-defined protocols, which...” The antecedent to “They” is ambiguous. Also, proprietary protocols can still be well-defined. I think you mean “proprietary or standardized” - Please include a citation for the first mention of WebSocket. §3: - "If an SDP offer/answer exchange is used as specified in this document to negotiate the establishment of data channels, corresponding data channel properties, associated data channel subprotocols and data channel subprotocol properties, then the data channel subprotocols may be identified by the values of the "subprotocol" parameters of the SDP "a=dcmap" attribute as described in Section 5.1.4.” Convoluted sentence. Please consider breaking it into simpler sentences. §4: Improper comma use after “... the Session Description Protocol (SDP) [RFC4566]” §5: Improper comma use after “attributes” and “parameters”. §5.1, 2nd paragraph: I can’t parse the first sentence. §5.1.1, last paragraph: s/ “... either only one...” / “... only one ...” The “MAY” is not a normal “normative” use of MAY; consider lower case. (The following “MUST NOT” is sufficient.) §6.2: “ By definition max-retr and max-time are mutually exclusive, so at most one of them MAY be present...” This would be better formulated as a MUST NOT. (MAY is typically used to give permission, not create constraints.) §6.5, first bullet: s/closes/close §6.6: Improper comma use after “subsequent offer” §6.6.1, first paragraph: Comma needed after “data channel”. §7: Please refer to the figures by number rather than relative position. (e.g. “The example in figure 2” rather than “The above example”.) §9.3, first paragraph: " SDP attributes that are defined for use at the dcsa usage level only SHALL use the dcsa usage level when registering the attribute.” I don’t understand this sentence. Consider a MUST NOT/SHALL NOT construction. |
2018-08-27
|
20 | Ben Campbell | IESG state changed to AD Evaluation from Publication Requested |
2018-08-20
|
20 | Bo Burman | 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? A Proposed Standard RFC is being requested. The document specifies normatively how SDP offer/answer exchange is used to achieve out-of-band (non-DCEP) negotiation for WebRTC data channel setup. The title page indicates "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. The Real-Time Communication in WEB-browsers (RTCWeb) working group has defined the concept of bi-directional data channels running on top of the Stream Control Transmission Protocol (SCTP), where each data channel might be used to transport other protocols, called subprotocols. Data channel setup can be done using either the in-band Data Channel Establishment Protocol (DCEP) or using some out-of-band non-DCEP protocol. This document specifies how the SDP (Session Description Protocol) offer/answer exchange can be used to achieve such an out-of-band non-DCEP negotiation. 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. 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? The document was reviewed and discussed multiple times by a fair amount of MMUSIC members (listed in Acknowledgements section). Nokia (former Alcatel-Lucent) implemented an earlier version of the draft, but no other implementations are known to the shepherd, although CLUE WG also makes use of WebRTC datachannel as the "CLUE channel" in their specifications and should therefore have seen some implementation. Personnel: Who is the Document Shepherd? Who is the Responsible Area Director? The Document Shepherd is Bo Burman. The Responsible AD is Ben Campbell. (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. The document shepherd read the submitted version of the document fully and found only a few minor nits that were announced on the mailing list and should be addressed in an upcoming revision. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? There are no concerns. The document got good review from a fair number of MMUSIC members and all of those comments were addressed. (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. 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 authors have confirmed that they do not know of any IPR disclosures that would be required. (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 disclosures have been filed. (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? A handful of interested people (except the authors) have commented on the draft in MMUSIC, and all those comments are addressed in the current draft. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) No. (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. No issues are found by ID nits tool. https://www.ietf.org/tools/idnits?url=https://www.ietf.org/archive/id/draft-ietf-mmusic-data-channel-sdpneg-17.txt (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. Not applicable. (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? This document has no normative references that are not ready for advancement: * ietf-rtcweb-data-channel; in RFC Ed queue MISSREF. * ietf-mmusic-sctp-sdp; in RFC Ed queue MISSREF. * ietf-mmusic-sdp-mux-attributes; in RFC Ed queue MISSREF. (15) Are there downward normative references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. No. (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. (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 shepherd reviewed the IANA section and its relation to and consistency with the document body, and found no issues. The IANA SDP attribute new usage level in section 8.3 is correct. No initial registrations for this new usage level are provided in this document. (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. New "DCSA" usage level added to the set of IANA "att-field" registries. Given that all other "att-field" registries require expert review, it is reasonable to assume the same "Specification Required" status for this one. Suggest the same expert as for the existing registries in that set: Flemming Andreasen. (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. Passes Bill's ABNF Parser (https://tools.ietf.org/tools/bap/abnf.cgi). |
2018-08-20
|
20 | Bo Burman | Responsible AD changed to Ben Campbell |
2018-08-20
|
20 | Bo Burman | IETF WG state changed to Submitted to IESG for Publication from WG Document |
2018-08-20
|
20 | Bo Burman | IESG state changed to Publication Requested |
2018-08-20
|
20 | Bo Burman | IESG process started in state Publication Requested |
2018-06-23
|
20 | Roni Even | New version available: draft-ietf-mmusic-data-channel-sdpneg-20.txt |
2018-06-23
|
20 | (System) | New version approved |
2018-06-23
|
20 | (System) | Request for posting confirmation emailed to previous authors: mmusic-chairs@ietf.org, Jerome Marcon , Richard Ejzak , Maridi Makaraju , Keith Drage , Roni Even , … Request for posting confirmation emailed to previous authors: mmusic-chairs@ietf.org, Jerome Marcon , Richard Ejzak , Maridi Makaraju , Keith Drage , Roni Even , Juergen Stoetzer-Bradler |
2018-06-23
|
20 | Roni Even | Uploaded new revision |
2018-05-31
|
19 | Roni Even | New version available: draft-ietf-mmusic-data-channel-sdpneg-19.txt |
2018-05-31
|
19 | (System) | New version approved |
2018-05-31
|
19 | (System) | Request for posting confirmation emailed to previous authors: Jerome Marcon , Richard Ejzak , Maridi Makaraju , Keith Drage , Roni Even , Juergen Stoetzer-Bradler |
2018-05-31
|
19 | Roni Even | Uploaded new revision |
2018-05-01
|
18 | Roni Even | New version available: draft-ietf-mmusic-data-channel-sdpneg-18.txt |
2018-05-01
|
18 | (System) | New version approved |
2018-05-01
|
18 | (System) | Request for posting confirmation emailed to previous authors: Jerome Marcon , Richard Ejzak , Maridi Makaraju , Keith Drage , Roni Even , Juergen Stoetzer-Bradler |
2018-05-01
|
18 | Roni Even | Uploaded new revision |
2018-04-06
|
17 | Bo Burman | Changed document writeup |
2018-04-04
|
17 | Roni Even | New version available: draft-ietf-mmusic-data-channel-sdpneg-17.txt |
2018-04-04
|
17 | (System) | New version approved |
2018-04-04
|
17 | (System) | Request for posting confirmation emailed to previous authors: mmusic-chairs@ietf.org, Richard Ejzak , Maridi Makaraju , Jerome Marcon , Keith Drage , Roni Even , … Request for posting confirmation emailed to previous authors: mmusic-chairs@ietf.org, Richard Ejzak , Maridi Makaraju , Jerome Marcon , Keith Drage , Roni Even , Juergen Stoetzer-Bradler |
2018-04-04
|
17 | Roni Even | Uploaded new revision |
2017-12-25
|
16 | Roni Even | New version available: draft-ietf-mmusic-data-channel-sdpneg-16.txt |
2017-12-25
|
16 | (System) | New version approved |
2017-12-25
|
16 | (System) | Request for posting confirmation emailed to previous authors: mmusic-chairs@ietf.org, Richard Ejzak , Maridi Makaraju , Jerome Marcon , Keith Drage , Roni Even , … Request for posting confirmation emailed to previous authors: mmusic-chairs@ietf.org, Richard Ejzak , Maridi Makaraju , Jerome Marcon , Keith Drage , Roni Even , Juergen Stoetzer-Bradler |
2017-12-25
|
16 | Roni Even | Uploaded new revision |
2017-12-04
|
15 | Roni Even | New version available: draft-ietf-mmusic-data-channel-sdpneg-15.txt |
2017-12-04
|
15 | (System) | New version approved |
2017-12-04
|
15 | (System) | Request for posting confirmation emailed to previous authors: mmusic-chairs@ietf.org, Richard Ejzak , Maridi Makaraju , Jerome Marcon , Keith Drage , Roni Even , … Request for posting confirmation emailed to previous authors: mmusic-chairs@ietf.org, Richard Ejzak , Maridi Makaraju , Jerome Marcon , Keith Drage , Roni Even , Juergen Stoetzer-Bradler |
2017-12-04
|
15 | Roni Even | Uploaded new revision |
2017-12-03
|
14 | Bo Burman | Tags Revised I-D Needed - Issue raised by WG, Author or Editor Needed cleared. |
2017-12-03
|
14 | Roni Even | New version available: draft-ietf-mmusic-data-channel-sdpneg-14.txt |
2017-12-03
|
14 | (System) | New version approved |
2017-12-03
|
14 | (System) | Request for posting confirmation emailed to previous authors: mmusic-chairs@ietf.org, Richard Ejzak , Maridi Makaraju , Jerome Marcon , Keith Drage , Juergen Stoetzer-Bradler |
2017-12-03
|
14 | Roni Even | Uploaded new revision |
2017-11-14
|
13 | Flemming Andreasen | Tag Author or Editor Needed set. |
2017-11-14
|
13 | Flemming Andreasen | IETF WG state changed to WG Document from In WG Last Call |
2017-09-10
|
13 | Maridi Makaraju | New version available: draft-ietf-mmusic-data-channel-sdpneg-13.txt |
2017-09-10
|
13 | (System) | New version approved |
2017-09-10
|
13 | (System) | Request for posting confirmation emailed to previous authors: Maridi Makaraju , mmusic-chairs@ietf.org, Keith Drage , Juergen Stoetzer-Bradler , Richard Ejzak |
2017-09-10
|
13 | Maridi Makaraju | Uploaded new revision |
2017-06-16
|
12 | Flemming Andreasen | Tag Revised I-D Needed - Issue raised by WG set. |
2017-03-27
|
12 | Maridi Makaraju | New version available: draft-ietf-mmusic-data-channel-sdpneg-12.txt |
2017-03-27
|
12 | (System) | New version approved |
2017-03-27
|
12 | (System) | Request for posting confirmation emailed to previous authors: Maridi Makaraju , mmusic-chairs@ietf.org, Keith Drage , Juergen Stoetzer-Bradler , Richard Ejzak |
2017-03-27
|
12 | Maridi Makaraju | Uploaded new revision |
2017-01-15
|
11 | Maridi Makaraju | New version available: draft-ietf-mmusic-data-channel-sdpneg-11.txt |
2017-01-15
|
11 | (System) | New version approved |
2017-01-15
|
11 | (System) | Request for posting confirmation emailed to previous authors: "Richard Ejzak" , mmusic-chairs@ietf.org, " (Unknown)" , "Juergen Stoetzer-Bradler" , "Keith Drage" , "Maridi Makaraju" |
2017-01-15
|
11 | Maridi Makaraju | Uploaded new revision |
2016-09-30
|
10 | Juergen Stoetzer-Bradler | New version approved |
2016-09-30
|
10 | Juergen Stoetzer-Bradler | New version available: draft-ietf-mmusic-data-channel-sdpneg-10.txt |
2016-09-30
|
10 | Juergen Stoetzer-Bradler | Request for posting confirmation emailed to previous authors: "Richard Ejzak" , mmusic-chairs@ietf.org, "Maridi R. Makaraju (Raju)" , "Juergen Stoetzer-Bradler" , "Keith Drage" , "(Unknown)" |
2016-09-30
|
10 | (System) | Uploaded new revision |
2016-09-15
|
09 | Bo Burman | IETF WG state changed to In WG Last Call from WG Document |
2016-07-25
|
09 | Juergen Stoetzer-Bradler | New version available: draft-ietf-mmusic-data-channel-sdpneg-09.txt |
2016-05-23
|
08 | Flemming Andreasen | IETF WG state changed to WG Document from In WG Last Call |
2016-02-17
|
08 | Juergen Stoetzer-Bradler | New version available: draft-ietf-mmusic-data-channel-sdpneg-08.txt |
2015-11-30
|
07 | Juergen Stoetzer-Bradler | New version available: draft-ietf-mmusic-data-channel-sdpneg-07.txt |
2015-11-25
|
06 | Bo Burman | IETF WG state changed to In WG Last Call from WG Document |
2015-11-20
|
06 | Flemming Andreasen | Notification list changed to "Bo Burman" <bo.burman@ericsson.com> |
2015-11-20
|
06 | Flemming Andreasen | Document shepherd changed to Bo Burman |
2015-10-19
|
06 | Juergen Stoetzer-Bradler | New version available: draft-ietf-mmusic-data-channel-sdpneg-06.txt |
2015-10-14
|
05 | (System) | Notify list changed from "Ari Keranen" , "Flemming Andreasen" to (None) |
2015-10-06
|
05 | Flemming Andreasen | Notification list changed to "Ari Keranen" <ari.keranen@ericsson.com>, "Flemming Andreasen" <fandreas@cisco.com> from "Ari Keranen" <ari.keranen@ericsson.com> |
2015-10-06
|
05 | Flemming Andreasen | Document shepherd changed to Flemming Andreasen |
2015-10-05
|
05 | Juergen Stoetzer-Bradler | New version available: draft-ietf-mmusic-data-channel-sdpneg-05.txt |
2015-08-04
|
04 | Juergen Stoetzer-Bradler | New version available: draft-ietf-mmusic-data-channel-sdpneg-04.txt |
2015-07-21
|
03 | Juergen Stoetzer-Bradler | New version available: draft-ietf-mmusic-data-channel-sdpneg-03.txt |
2015-04-10
|
02 | Juergen Stoetzer-Bradler | New version available: draft-ietf-mmusic-data-channel-sdpneg-02.txt |
2015-03-09
|
01 | Juergen Stoetzer-Bradler | New version available: draft-ietf-mmusic-data-channel-sdpneg-01.txt |
2015-02-06
|
00 | Ari Keränen | Notification list changed to "Ari Keranen" <ari.keranen@ericsson.com> |
2015-02-06
|
00 | Ari Keränen | Document shepherd changed to Ari Keränen |
2015-01-27
|
00 | Ari Keränen | Intended Status changed to Proposed Standard from None |
2015-01-27
|
00 | Ari Keränen | This document now replaces draft-ejzak-mmusic-data-channel-sdpneg instead of None |
2015-01-27
|
00 | Juergen Stoetzer-Bradler | New version available: draft-ietf-mmusic-data-channel-sdpneg-00.txt |