Subject: Re: [MMUSIC] new revision in draft-ietf-mmusic-data-channel-sdpneg-17

From: "Roni Even (A)" <[email-masked]>
Date: Tue, 1 May 2018 14:38:10 +0000

Hi Christer,
Thanks

 I updated the document and submitted -18 version

On
SECTION 6.6.1:
==============

Q10:

The text says:

   "When the application requests the closing of a data channel that was
    negotiated via SDP offer/answer, the data channel stack always
    performs an SCTP SSN reset for this channel.²

However, it later says that a data channel is closed once the offer send in order to close the data channel has been accepted.

[RE] I looked at it and will change the text also for Q11

Q11:

The text says:

   "If a client receives a data channel close indication (due to inband
    SCTP SSN reset or some other reason) without associated SDP offer
    then the client SHOULD generate an SDP offer which excludes this
    closed data channel.²

But, earlier in the section it says that it is subprotocol-specific whether a O/A exchange is needed in order to close a data channel.

<RE> The SCTP SSN reset the Stream Sequence Number of the stream back to zero. It is specific to the subprotocol whether this data channel will be closed or will be re-used by a new Offer/Answer Exchange.
I adjusted the text to address these two cases.

>SECTION 6.7:
>============
>
>Q12:
>
>I think most of the text (apart from the error cases) could be 
>incorporated into the earlier offer/answer sections.
>
>For example, the offer section should make it clear when "a=dcmap:" is 
>included in an offer, and when it is not. There is no need for a 
>separate section to describe the case when "SDP offer has no "a=dcmap:² 
>attributes".
>
>[RE} I am not sure, I can move the cases like for example  no a=dcmap 
>in intial offer to section 6.3 but I think these cases are not the 
>usual ones since 6.3 creates the "normal" offer and it reads better at 
>least to me this way. Anyhow if you feel this is important I will move 
>parts of section 6.7 to earlier sections

To take decamp as an example, the text in section 6.7 says:

   "Initial SDP offer: No data channel is negotiated yet.  The DTLS
    association and SCTP association is negotiated and, if agreed,
    established as per [I-D.ietf-mmusic-sctp-sdp]."

The initial offer is the first offer where you negotiate the data channel
- whatever offer/answers you have done before that is irrelevant. As we do in other drafts, you could clarify that in the draft.

Now, if you want, you can clarify in section 6.3 that the DTLS/SCTP association may have been previously negotiated.

Then the text says:

   "Subsequent SDP offer: All the SDP offer/answer negotiated data
    channels are expected to be closed now.  The DTLS/SCTP
    association remains open for SDP offer/answer or DCEP
    negotiation of data channels."

This should be in section 6.6, in my opinion.

<RE> I moved this paragraphs and some others to the previous ones (6.3-6.6) and renamed the section to considerations

Regards,

Christer

>From:  mmusic <[email-masked]> on behalf of Bo Burman 
><[email-masked]>
>Date:  Friday 6 April 2018 at 18:17
>To:  "Roni Even (A)" <[email-masked]>, "[email-masked]"
><[email-masked]>
>Subject:  Re: [MMUSIC] new revision in
>draft-ietf-mmusic-data-channel-sdpneg-17
>
>
>Thanks Roni,
> 
>I believe this addresses my shepherd¹s review nits.
> 
>/Bo
> 
>From: mmusic [mailto:[email-masked]] On Behalf Of Roni Even 
>(A)
>Sent: den 4 april 2018 14:34
>To: [email-masked]
>Subject: [MMUSIC] new revision in 
>draft-ietf-mmusic-data-channel-sdpneg-17
>
>
> 
>Hi,
>I submitted a new revision of
>https://tools.ietf.org/html/draft-ietf-mmusic-data-channel-sdpneg-17
>trying to address comments from Christer and Bo.
>Thanks
>Roni Even
>