[MMUSIC] Additional editorial change suggestions to draft-ietf-mmusic-data-channel-sdpneg

[Christer Holmberg <[e-mail]>]

Hi,

I got some off-line comments from Bo, on the text modifications I suggested for draft-ietf-mmusic-data-channel-sdpneg, and the impact it had on some other text. So, below are some changes that I still think need to be done:

---


Q1 (section 6):



Old text:



   "This section defines how data channels can be negotiated using the

   SDP offer/answer mechanism.  The procedures apply for a given data

   channel."



It was commented that the text is not clear enough that multiple data channels can be negotiated separately and independently of each other, even if they are associated with the same media description (m- line). I suggest to clarify that.



Suggested new text:



       "This section defines how data channels can be negotiated using the SDP

       offer/answer mechanism. A given media description can describe multiple

       data channels (each represented by a separate SDP dcmap attribute) that

       can be created, modified and closed using different offer/answer exchanges.

       The procedures in this section apply for a given data channel."



---



Q2 (section 6):



Old text:

   "The generic offer/answer procedures for negotiating the SCTP
   association used to realize are defined in
   [I-D.ietf-mmusic-sctp-sdp<https://datatracker.ietf.org/doc/html/draft-ietf-mmusic-data-channel-sdpneg-19#ref-I-D.ietf-mmusic-sctp-sdp>]. This section only defines the data
   channel specific procedures."



There is text missing between 'realize' and 'are'.



Suggested new text:


   "The generic offer/answer procedures for negotiating the SCTP
   association used to realize data channels are defined in
   [I-D.ietf-mmusic-sctp-sdp<https://datatracker.ietf.org/doc/html/draft-ietf-mmusic-data-channel-sdpneg-19#ref-I-D.ietf-mmusic-sctp-sdp>]. This section only defines the data
   channel specific procedures."



---



Q3 (section 6.1):



Old text:



   "As described in [I-D.ietf-rtcweb-data-protocol<https://datatracker.ietf.org/doc/html/draft-ietf-mmusic-data-channel-sdpneg-19#ref-I-D.ietf-rtcweb-data-protocol>], in order to avoid

   SCTP Stream identifier collisions, the endpoint acting as DTLS client

   (for the SCTP association used to realize data channels) will use

   even identifier values, and the endpoint acting as DTLS server will

   use odd identifier values.  Those rules also apply when SCTP streams

   for data channels are negotiated using the offer/answer mechanism.

   SCTP stream identifiers associated with data channels that have been

   negotiated using DCEP MUST NOT be included in SDP offers and answers."



It was commented that the text makes normative references to draft-ietf-rtcweb-data-protocol, which is an informative reference (you don't need to support DCEP if you use SDP O/A). However, the DCEP rules regarding even/odd identifier values are also used for SDP.



Suggested new text:



      "In order to avoid SCTP Stream identifier collisions, in alignment with

[I-D.ietf-rtcweb-data-protocol<https://datatracker.ietf.org/doc/html/draft-ietf-mmusic-data-channel-sdpneg-19#ref-I-D.ietf-rtcweb-data-protocol>], the endpoint acting as DTLS client (for

the SCTP association used to realize data channels) MUST use even identifier values,

and the endpoint acting as DTLS server MUST use odd identifier values. SCTP stream

identifiers associated with data channels that have been negotiated using DCEP MUST NOT

be included in SDP offers and answers."



----



Q4 (section 6.2):



Old text:



   "The data channel types defined in [I-D.ietf-rtcweb-data-protocol<https://datatracker.ietf.org/doc/html/draft-ietf-mmusic-data-channel-sdpneg-19#ref-I-D.ietf-rtcweb-data-protocol>] are

   mapped to the dcmap SDP media description in the following manner

   where "ordered=true" is the default and may be omitted:"



The formulation "the dcmap SDP media description" is a bit awkward. A "dcmap" attribute does not make up a media description. Suggest to replace with "the dcmap attribute parameters".



Suggested new text:



   "The data channel types defined in [I-D.ietf-rtcweb-data-protocol<https://datatracker.ietf.org/doc/html/draft-ietf-mmusic-data-channel-sdpneg-19#ref-I-D.ietf-rtcweb-data-protocol>] are

   mapped to the dcmap attribute parameters in the following manner

   where "ordered=true" is the default and may be omitted:"



---



Q5 (section 6.2):



Old text:



   "The SDP answer SHALL echo the same subprotocol, max-retr, max-time,

   and ordered parameters, form the offer, and MAY include a label

   parameter.  They MAY appear in any order, which could be different

   from the SDP offer, in the SDP answer."



It was commented that the text does not belong to section 6.2, but to section 6.4.



I suggest to remove the text from section 6.2, and modify the first bullet in Section 6.4:



"o SHALL include an SDP dcmap attribute (Section 5 and Section 6.2) associated

with the data channel in the "m=" section representing the SCTP association used

to realize the data channel. The value of the dcmap-stream-id, max-retr and max-time

values of the dcmap attribute SHALL be identical to the value used for the data channel

in the offer; and"



---



Q6 (section 6.2):



Old text:



   "When sending a subsequent offer or an answer, and for as long as the

   data channel is still open, the sender MUST replicate the same

   information."



The text does not belong in Section 6.2, and also already exists in section 6.6 (where it belongs).



I suggested to remove the paragraph.



---



Q7 (section 6.3):



Old text:



   "o  MAY include one or more SDP dcsa attributes (Section 6.2<https://datatracker.ietf.org/doc/html/draft-ietf-mmusic-data-channel-sdpneg-19#section-6.2>)

      associated with the data channel.  The value of the stream-id part

      of each attribute SHALL match the dcmap-stream-id value of the

      dcmap attribute."



The reference to Section 6.2 is wrong. It shall be Section 5.2.



Suggested new text:



   "o  MAY include one or more SDP dcsa attributes (Section 5.2<https://datatracker.ietf.org/doc/html/draft-ietf-mmusic-data-channel-sdpneg-19#section-6.2>)

      associated with the data channel.  The value of the stream-id part

      of each attribute SHALL match the dcmap-stream-id value of the

      dcmap attribute."



---



Q8 (section 6.4):



Old text:



   "o  MAY include one or more SDP dcsa attributes (Section 6.2<https://datatracker.ietf.org/doc/html/draft-ietf-mmusic-data-channel-sdpneg-19#section-6.2>)

      associated with the data channel."



The reference to Section 6.2 is wrong. It shall be Section 5.2.



Suggested text:



   "o  MAY include one or more SDP dcsa attributes (Section 6.2<https://datatracker.ietf.org/doc/html/draft-ietf-mmusic-data-channel-sdpneg-19#section-6.2>)

      associated with the data channel."



---



Q9 (section 6.4):



   o  MAY include one or more SDP dcsa attributes (Section 6.2<https://datatracker.ietf.org/doc/html/draft-ietf-mmusic-data-channel-sdpneg-19#section-6.2>)

      associated with the data channel.



It was questioned whether there are no generic offer/answer considerations for dcsa attributes.



In my opinion each new sub-protocol that uses dcsa attributes must define the sub-protocol specific offer/answer procedures for the attributes. In order to make that clear, I suggest to add the following new text:



"The detailed offer/answer procedures for the dcsa attribute are dependent on the associated sub-protocol.

A sub-protocol specification MUST define the offer/answer procedures for the dsca attribute (if applicable)

associated with the sub-protocol."



---



Q10 (section 6.6):



Old text:



"When an offer sends a subsequent offer, that includes information for a previously

negotiated SCTP stream for a data channel, unless the offerer intends to close the

data channel (Section 6.6.1), the offerer SHALL include the previously negotiated

SDP attributes and attribute values associated with the data channel."



It was commented that the sections contains a single, long sentence that is difficult to parse. I suggest to remove the SCTP part, because it doesn't really belong to this spec.



Suggested new text:



"When an offer sends a subsequent offer that includes information for a previously

negotiated data channel, unless the offerer intends to close the data channel

(Section 6.6.1), the offerer SHALL include the previously negotiated SDP attributes

and attribute values associated with the data channel."



---



Q11 (section 6.7):



Old text:



      "An SDP offer or answer has no "a=dcmap:" attributes but has

      "a=dcsa:" attributes.



      *  This is considered an error case.  In this case the receiver of

         such an SDP offer or answer SHOULD ignore the "a=dcsa:"

         attributes and SHOULD process the SDP offer or answer as per

         above case 'SDP offer has no "a=dcmap:" attributes' or case

         'SDP answer has no "a=dcmap:" attributes'."



Due to some other changes, the reference (to section 6.7) is wrong.



I suggested to remove this bullet, and have a generic statement, e.g., in section 5.2, saying that DCSA attributes without an associated DCMAP attribute MUST be discarded.



Alternatively, somehow remove the "as per above" reference.



---


Regards,

Christer