Change:
NAME revised
Fixed by
Maybe in create-answer as well
The "Initial Offers" section does not distinguish systematically between requirements that apply for any type of offer and the ones that apply only to mediastreams. For instance: I think this should apply both to mediastreamtrack and to datachannels. Then many of the rules described under "Each m= section MUST include the following attribute lines:" seem specific to mediastreams, but not all; and that set of rules is then followed by a statement that a m= section must be created for data channels. This could use some reorganization and clarification.
Agree this could be refactored a bit. Magnus had a similar comment in the past.
Suggest contact with Magnus or Jessep for potential language.
I think this is mostly editorial and as such probably needs to be resolved within the author team.
Can this be considered fixed now? The createOffer section has since been structured into "here's what you generate for each RtpTransceiver", "here's what you generate if there's a data channel". And the data channel requirements look complete to me:
I agree with NAME NAME shall we close this?
I think the concern was that the data channel paragraphs feel a bit like an afterthought. I think this could be improved, but I don't think the current situation is dire.
I can live with the current text as is. Done is a feature and I don't think this will cause any interoperability problems.
This text has been improved as of PR . If we can and this text still reads well, I think we can close this issue.
Pending resolution of
is it's own bug. I think we an just close this and any changes needed can be dealt with by
I want to take one last editorial pass over the text once lands. This is a purely editorial issue at this point.

Discussion:
sctp-sdp.  The "fmt" value MUST be set to "webrtc-datachannel" as specified in I-D.ietf-mmusic-sctp-sdp, Section 4.1. <del> Within the data m= section, the "a=mid", "a=ice-ufrag", "a=ice-pwd", "a=fingerprint", "a=dtls-id", and "a=setup" lines MUST be included as mentioned above, along with an "a=fmtp:webrtc-datachannel" line and an "a=sctp-port" line referencing the SCTP port number as defined in I-D.ietf-mmusic-sctp-sdp, Section 4.1. </del> <ins> Within the data m= section, an "a=mid" line MUST be generated and included as described above, along with an "a=sctp-port" line referencing the SCTP port number, as defined in I-D.ietf-mmusic-sctp- sdp, Section 5.1, and, if appropriate, an "a=max-message-size" line, as defined in I-D.ietf-mmusic-sctp-sdp, Section 6.1. As discussed above, the following attributes are included only if the m= section either has a unique address or is associated with the bundle-tag: "a=ice-ufrag", "a=ice-pwd", "a=fingerprint", "a=dtls-id", and "a=setup". </ins> Once all m= sections have been generated, a session-level "a=group" attribute MUST be added as specified in RFC5888.  This attribute MUST

"application" and the <proto> and "fmt" fields MUST be set to exactly match the fields in the offer. <del> Within the data m= section, the "a=mid", "a=ice-ufrag", "a=ice-pwd", "a=candidate", "a=fingerprint", "a=dtls-id", and "a=setup" lines MUST be included under the conditions described above, along with an "a=fmtp:webrtc-datachannel" line and an "a=sctp-port" line referencing the SCTP port number as defined in I-D.ietf-mmusic-sctp- sdp, Section 4.1. </del> <ins> Within the data m= section, an "a=mid" line MUST be generated and included as described above, along with an "a=sctp-port" line referencing the SCTP port number, as defined in I-D.ietf-mmusic-sctp- sdp, Section 5.1, and, if appropriate, an "a=max-message-size" line, as defined in I-D.ietf-mmusic-sctp-sdp, Section 6.1. As discussed above, the following attributes are included only if the m= section is not bundled into another m= section: "a=ice-ufrag", "a=ice-pwd", "a=fingerprint", "a=dtls-id", and "a=setup". </ins> If "a=group" attributes with semantics of "BUNDLE" are offered, corresponding session-level "a=group" attributes MUST be added as