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

From: "Roni Even (A)" <[email-masked]>
Date: Wed, 4 Apr 2018 12:33:57 +0000

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

---

From: Bo Burman <[email-masked]>
Date: Fri, 6 Apr 2018 15:17:56 +0000

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,

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 20 Apr 2018 09:54:09 +0000

Hi,

I have reviewed the new version. Thank you for addressing my comments.

However, I think there is still some work (mostly editorial) to do.

SECTION 1:
==========

Q1:

I think the Introduction is rather messy, but I don¹t have a suggestion on
how to fix it. However, there is the following statement:
   "This document defines SDP offer/answer [RFC3264] negotiation
   procedures to establish data channels for transport of well-defined
   subprotocols, to enable out-of-band negotiation.²

 I suggest to say 

   "This document defines SDP offer/answer [RFC3264]
   Procedures that enable out-of-band negotiation for establishing data
channels for transport of well-defined
   subprotocols.² 

---

Q2:

I suggest to remove the following:

   ³In the future, data channels could be defined over other SCTP based
   protocols, such as SCTP over IP.  However, corresponding potential
   other "m=" line proto values are not considered in this document."

It is enough to specify what the draft does - not what may potentially
perhaps be done in future.

---

Q3:

Please add references to MSRP and BFCP on first occurrence.

SECTION 5:
==========

Q4:

The 3rd paragraph repeats much of the 1st paragraph. I think they can be
combined.

Q5:

There is no need to repeat text about ³without the usage of DCEP². It is
enough to make it clear once in the beginning of document. This applies to
other sections too.

SECTION 5.1:
============

Q6:

The text talks about ³The intention of the attribute is to blah blah².
That sounds weird. Instead say ³The attribute is used to blah blah².

SECTION 5.1.9:
==============

Q7:

I think you can remove the first paragraph. Simply include the
[I-D.ietf-mmusic-sdp-mux-attributes] reference in the next sentence:

   "The multiplexing category [I-D.ietf-mmusic-sdp-mux-attributes] of the
"a=dcmap:" attribute is SPECIAL."

SECTIONS 6.3 & 6.4:
===================

Q8:

You don¹t have to say ³Sends the offer²/³Sends the answer².

SECTION 6.6:
============

Q9:

The text seems to be about adding a new data channel. You should have a
separate sub-section (6.6.x) for that.

But, you should also have text about when sending a subsequent offer
without impacting the data channel. For example, the offer must (I assume)
include all attributes associated with the currently open data channels.

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.

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.

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

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

---

From: "Roni Even (A)" <[email-masked]>
Date: Sun, 22 Apr 2018 12:25:25 +0000

Hi Christer,
Thanks for the review, see inline
Roni

-----Original Message-----
From: Christer Holmberg [mailto:[email-masked]] 
Sent: Friday, April 20, 2018 12:54 PM
To: Bo Burman; Roni Even (A); [email-masked]
Subject: Re: [MMUSIC] new revision in draft-ietf-mmusic-data-channel-sdpneg-17

Hi,

SECTION 1:
==========

Q1:

I think the Introduction is rather messy, but I don¹t have a suggestion on how to fix it. However, there is the following statement:
   "This document defines SDP offer/answer [RFC3264] negotiation
   procedures to establish data channels for transport of well-defined
   subprotocols, to enable out-of-band negotiation.²

 I suggest to say 

   "This document defines SDP offer/answer [RFC3264]
   Procedures that enable out-of-band negotiation for establishing data channels for transport of well-defined
   subprotocols.² 

[RE] OK

---

Q2:

It is enough to specify what the draft does - not what may potentially perhaps be done in future.

[RE] OK

---

Q3:

[RE] OK

SECTION 5:
==========

Q4:

The 3rd paragraph repeats much of the 1st paragraph. I think they can be combined.

[RE} OK

Q5:

There is no need to repeat text about ³without the usage of DCEP². It is enough to make it clear once in the beginning of document. This applies to other sections too.

[RE} left it here and remove from next section

SECTION 5.1:
============

Q6:

[RE}OK

SECTION 5.1.9:
==============

Q7:

I think you can remove the first paragraph. Simply include the [I-D.ietf-mmusic-sdp-mux-attributes] reference in the next sentence:

   "The multiplexing category [I-D.ietf-mmusic-sdp-mux-attributes] of the "a=dcmap:" attribute is SPECIAL."

[RE]OK

SECTIONS 6.3 & 6.4:
===================

Q8:

[RE] OK

SECTION 6.6:
============

Q9:

The text seems to be about adding a new data channel. You should have a separate sub-section (6.6.x) for that.

But, you should also have text about when sending a subsequent offer without impacting the data channel. For example, the offer must (I assume) include all attributes associated with the currently open data channels.

[RE} Will see how to do it

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

Q10:

The text says:

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:

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.

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

Regards,

Christer

From:  mmusic <[email-masked]> on behalf of Bo Burman <[email-masked]>

Thanks Roni,

/Bo

 
Hi,

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 30 Apr 2018 10:21:25 +0000

Hi,

...

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

Regards,

Christer