Negotiation Data Channels Using the Session Description Protocol (SDP)
draft-ietf-mmusic-data-channel-sdpneg-28

[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.

[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”?

[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?

[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”?

[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”.

[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...

[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.

[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.

[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.

[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.

(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

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.

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

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

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

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.

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).

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

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

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

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