Change:
Lastly, if a data channel has been created, an "m=" section MUST be generated for data.  The <media> field MUST be set to "application", and the <proto> field MUST be set to "UDP/DTLS/SCTP" RFC8841.  The <del> "fmt" value MUST be set to "webrtc-datachannel" as specified in </del> <ins> <fmt> value MUST be set to "webrtc-datachannel" as specified in </ins> RFC8841. Within the data "m=" section, an "a=mid" line MUST be generated and

Discussion:
This PR covers the following: updated xrefs ok, removed comment ( issue 41) fixed xref and formatting of fmt, removed comment. issue 32 current text ok, removed comment. issue 22 It does not cover , issue 37, despite the branch name, because that issue was actually closed with PR
41) [rfced] Section 5.3.2: We found this RFC Editor Note on : OLD: NEW: Please note that the "OLD" text does not match what we found in the provided draft (i.e., "[RFC5245], Section 4.3., paragraph 3" versus "[I-D.ietf-mmusic-ice-sip-sdp], Section 4.1"): Please review, and let us know if further changes are needed. (As noted previously, "[RFC8839]" and "[RFC8840]" are the RFC numbers assigned for [I-D.ietf-mmusic-ice-sip-sdp] and [I-D.ietf-mmusic-trickle-ice-sip], respectively.) Currently:
Proposed text LGTM
I incorrectly mentioned this issue number when I created my branch and PR. This issue is technically still open (the comments that need to be deleted are still there), and instead these edits fixed (note the similarities in the titles of the issues...). Sorry about that.
32) [rfced] Section 5.2.1: We could not find any mention of "webrtc-datachannel" in Section 4.1 of RFC 8841 [I-D.ietf-mmusic-sctp-sdp]. Please confirm that this citation is correct and will be clear to readers. Original: The "fmt" value MUST be set to "webrtc- datachannel" as specified in [I-D.ietf-mmusic-sctp-sdp], Section 4.1.
It's never really spelled out well in that document; Section 4.5 is the only direct mention, but it's as an example, which is suboptimal. NAME any thoughts on this?
Section 15.3 of draft-ietf-mmusic-sctp-sdp registers the "webrtc-datachannel" value with IANA. But, as you point out, there are no real procedures defined. draft-ietf-mmusic-data-channel-sdpneg also only uses the value in examples.
NAME thoughts?

draft-ietf-mmusic-data-channel-sdpneg seems to assume that draft-ietf-mmusic-sctp-sdp defines the usage of "webrtc-datachannel". But, draft-ietf-mmusic-sctp-sdp cannot have a generic procedure for that, since the spec could be used for other things too. I guess the solution would be to add a normative statement somewhere, saying that the m- line fmt value muts be "webrtc-datachannel" for data channels. The question is whether such statement should be in draft-ietf-mmusic-sctp-sdp or draft-ietf-mmusic-data-channel-sdpneg.
I think NAME is correct; and, given that it's draft-ietf-mmusic-sctp-sdp that registers the value with IANA, I think that's the document that should say as much (e.g., "The token 'webrtc-datachannel' indicates the protocol defined in [I-D.ietf-rtcweb-data-protocol]", either in section 4.4.2 or section 15.3) Christer -- can you work with NAME and the RFC Editor to make sure this change makes it into draft-ietf-mmusic-sctp-sdp?
I assume you meant "makes it into draft-ietf-mmusic-sctp-sdp"?
Ah, right. Copied the wrong document name. Thanks -- it should go into draft-ietf-mmusic-sctp-sdp.
I have sent an e-mail where I suggest the following new text to Section 4.4.2.: "When the SCTP association is used to realize a WebRTC data channel [I-D.ietf-rtcweb-data-protocol], the parameter value is 'webrtc-datachannel'." Feel free to indicate your support, so people don't think this is just Christer wanting past deadline additions :)
Thanks NAME for doing this, will chime in on the list.
Looks like this one is now straightforward. I believe the new section to reference is 4.4.2, but please double-check.
I've double-checked the xref and RFC 8841 (was draft-ietf-mmusic-sctp-sdp), Section 4.4.2 is correct.

The formatting of "fmt" is , so the updated sentence is:
22) [rfced] Section 5.2.1: We found this RFC Editor Note on : OLD: NEW: Please note that the "OLD" text does not match what we found in the provided draft: We updated as follows. Is the "and [RFC8445], Section 10" still applicable? Currently:
I think we want An "a=ice-options" line with the "trickle" and "ice2" options MUST be added, as specified in [I-D.ietf-ice-trickle], Section 3 and [RFC8445], Section 10.
NAME please close this issue once you consider it resolved.
Upon further reflection, while I think the current draft text (the 3rd block of text above) is correct, based on the note the proposed text (4th block) may be preferred. NAME as he wrote the note and can help disambiguate.
Well, it's definitely not RFC 8440 section 3, as that says nothing about SDP syntax or the trickle attribute. I think this is correct: >An "a=ice-options" line with the "trickle" and "ice2" options MUST be added, as specified in [RFC8840], Section 4.1.1 and [RFC8445], Section 10. (Which is the final block above.) I have to concede that I've lost context for why the RFC Editor note was necessary in the first place, but it's probably better to be more precise in any case.
NAME we're deciding between mmusic-trickle-sip-sdp, Section 4.1.1, which says: and ice-trickle, Section 3, which says:
Ah, sorry -- I missed that we were talking about two different documents. Given that the reference to trickle-ice-sip-sdp is both more indirect and unnecessarily involves a document about an only marginally related technology, I think the ice-trickle section 3 reference is cleaner. My vague recollection now is that ice-trickle used to rely on trickle-ice-sip-sdp for this behavior, and we reversed that dependency later in the cycle by moving the normative definition into ice-trickle.

I looked into this a bit more closely as part of some related JSEP issues and am now leaning toward keeping the trickle-sip-sdp reference; JSEP already leans on this document for the definition of a=candidate, a=ice-ufrag, a=ice=pwd, etc, and as a similar signaling protocol topic I think a=ice-options should be handled the same way.
For the avoidance of doubt, I am suggesting use of the final block above:
I don't feel strongly about it either way. I think the intention is clear, and implemetors will get it right regardless of which of the two citations you choose.