Subject: [MMUSIC] draft-ietf-mmusic-data-channel-sdpneg - proposed text enhancements

From: Juergen Stoetzer-Bradler <[email-masked]>
Date: Fri, 27 Feb 2015 16:29:58 +0100

Hello,

We would propose a couple of modifications of the text in draft-ietf-mmusic-data-channel-sdpneg-00
in order to enhance readability and to avoid potential ambiguities.

If the points in following list are agreeable then we would do corresponding updates in next
draft-ietf-mmusic-data-channel-sdpneg-01.

 1. In whole document, including the document's title, replacement of"data channel" with "WebRTC
    data channel".

 2. In Section 4 removal of following note: 'OPEN ISSUE: The syntax in[I-D.ietf-mmusic-sctp-sdp] may
    change as that document progresses. In particular we expect "webrtc-datachannel" to become a
    moregeneral term.'

 3. Consistent usage of '"m" line' in whole document as per [RFC4566].

 4. In Section 5.1.1 removal of following note:
    "Note: This attributeis derived from attribute "webrtc-DataChannel", which was definedin old
    version 03 of the following draft, but which was removedalong with any support for SDP external
    negotiation in subsequentversions: [I-D.ietf-mmusic-sctp-sdp]."
     1.

 5. Insertion of following new sentence to the beginning ofSection 5.1.1.1:
    "dcmap is a media level attribute havingfollowing ABNF syntax:".

 6. In Section 5.1.1.1 the ABNF definition of "quoted-string" refersto rule name "escaped-char",
    which is not defined.Instead arule with name "escaped" is defined.  Renaming of that rule's name
    to"escaped-char".

 7. Insertion of following dedicated note right after the "a=dcmap:4
    label="foo%09bar";ordered=true;max-time=15000;max-retr=3"attribute example in Section 5.1.1.1:
    "Note: The last example (a=dcmap:4) shows a 'label' parameter value which contains one
    non-printable 'escaped-char' character (the    tabulator character)."

 8. In Section 5.1.2's second paragraph replacement of "sctp streamidentifier" with "SCTP stream
    identifier".

 9. In first paragraph of Section 5.2.1 replacement of first sentence
         "For the SDP-based external negotiation described in thisdocument, the initial offerer
    based "SCTP over DTLS" owns byconvention the even stream identifiers whereas the initialanswerer
    owns the odd stream identifiers."
    with
         "For the SDP-basedexternal negotiation described in this document, the sender of theinitial
    offer owns by convention the even stream identifierswhereas the sender of the initial answer
    owns the odd streamidentifiers."

10. In Section 5.2.3 the first action of an SDP answerer, whenreceiving an SDP offer, is described as
         "Applies the SDP offer.Note that the browser ignores data channel specific attributes inthe
    SDP."
    Replacement of these two sentences with
         "It parses andapplies the SDP offer.Note that the typical parser normallyignores unknown
    SDP attributes, which includes WebRTC data channelrelated attributes."

11. In Section 5.2.3 the second sentence of the third SDP answereraction is
         "Note that the browser is asked to create data channelswith stream identifiers not "owned"
    by the agent.".
    Replacementof this sentence with
         "Note that the agent is asked to createWebRTC data channels with SCTP stream identifiers
    contained in theSDP offer if the SDP offer is accepted."

12. In Section 5.2.4 the third paragraph begins with
         "A data channelcan be closed by sending a new SDP offer which excludes the dcmapand dcsa
    attributes lines for the data channel.The port valuefor the m line should not be changed (e.g.,
    to zero) when closinga data channel (unless all data channels are being closed and theSCTP
    association is no longer needed), since this would close theSCTP association and impact all of
    the data channels.If the answerer accepts the SDP offer then it MUST also exclude
    thecorresponding attribute lines in the answer. ..."
    Replacement ofthis part with
         "The intention to close a WebRTC data channel canbe signaled by sending a new SDP offer
    which excludes the"a=dcmap:" and "a=dcsa:" attributes lines for the WebRTC datachannel.The port
    value for the "m" line SHOULD not be changed (e.g., to zero) when closing a WebRTC data channel
    (unless allWebRTC data channels are being closed and the SCTP association isno longer needed),
    since this would close the SCTP association andimpact all of the WebRTC data channels.If the
    answerer acceptsthe SDP offer then it MUST close those WebRTC data channels whose"a=dcmap:" and
    "a=dcsa:" attribute lines were excluded from thereceived SDP offer, unless those WebRTC data
    channels were alreadyclosed, and it MUST also exclude the corresponding attribute linesin the
    answer."

13. In Section 5.2.4 the hanging text after the third paragraph is
         "This delayed close is to handle cases where a successful SDPanswer is not received, in
    which case the state of session shouldbe kept per the last successful SDP offer/answer."
    Replacement ofthis sentence with
         "This delayed closure is RECOMMENDED in orderto handle cases where a successful SDP answer
    is not received, inwhich case the state of the session SHOULD be kept per the lastsuccessful SDP
    offer/answer."

Juergen

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 27 Feb 2015 10:56:48 -0500

Juergen,

See a couple of comments inline...

On 2/27/15 10:29 AM, Juergen Stoetzer-Bradler wrote:
>  1. In whole document, including the document's title, replacement
>     of"data channel" with "WebRTC data channel".

IMO this is wrong. I've been arguing for a long time to *remove* 
"webrtc" from the formal definitons. While the development of this 
mechanism certainly was motivated by webrtc, it has much broader 
applicability.

[snip]

>          "For the SDP-based external negotiation described in
>     thisdocument, the initial offerer based "SCTP over DTLS" owns
>     byconvention the even stream identifiers whereas the initialanswerer
>          "For the SDP-basedexternal negotiation described in this
>     document, the sender of theinitial offer owns by convention the even
>     stream identifierswhereas the sender of the initial answer owns the
>     odd streamidentifiers."

This is confusing. It isn't clear from the text whether the owner of 
even identifiers is determined by the sender of the first offer in the 
*signaling session* (e.g., sip dialog), or the sender of the first offer 
that includes the "m" line of this SCTP association.

It wasn't entirely clear before, but it is less clear now. IIUC it 
should be the sender of the first offer of the "m" line. But thinking 
about it more as I type, I expect it is more complex than that. If the 
association is subsequently renegotiated then I suspect the owner of 
even IDs is also renegotiated. (This starts to overlap with the other 
discussion of negotiation.

[snip]

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 27 Feb 2015 17:11:02 +0000

Hi,

> IMO this is wrong. I've been arguing for a long time to *remove* "webrtc" from the 
> formal definitons. While the > development of this mechanism certainly was motivated 
> by webrtc, it has much broader applicability.

I agree. Having said that, perhaps something in addition to "data channel" would be useful. E.g. "sctp data channel", or something...

Regards,

Christer

---

From: Juergen Stoetzer-Bradler <[email-masked]>
Date: Fri, 27 Feb 2015 20:52:36 +0100

Paul,

Thanks much for your feedback.
Please see my remarks below.

Thanks,
Juergen

On 27.02.2015 16:56, Paul Kyzivat wrote:
> IMO this is wrong. I've been arguing for a long time to *remove* "webrtc" from the formal 
> definitons. While the development of this mechanism certainly was motivated by webrtc, it has much 
> broader applicability.

[Juergen] I see that Christer also prefers to remove "WebRTC". Will reply to Christer's email on that.

>>     this document, the initial offerer based "SCTP over DTLS" owns
>>     by convention the even stream identifiers whereas the initial answerer
>>          "For the SDP-based external negotiation described in this
>>     document, the sender of the initial offer owns by convention the even
>>     stream identifiers whereas the sender of the initial answer owns the
>>     odd stream identifiers."
>
> This is confusing. It isn't clear from the text whether the owner of even identifiers is 
> determined by the sender of the first offer in the *signaling session* (e.g., sip dialog), or the 
> sender of the first offer that includes the "m" line of this SCTP association.
>
> It wasn't entirely clear before, but it is less clear now. IIUC it should be the sender of the 
> first offer of the "m" line. But thinking about it more as I type, I expect it is more complex 
> than that. If the association is subsequently renegotiated then I suspect the owner of even IDs is 
> also renegotiated. (This starts to overlap with the other discussion of negotiation.

[Juergen] I see. Agree that the new sentence wasn't really clearer after all.
We could reformulate this by saying that the offerer which adds the DTLS/SCTP based "m" line to the 
signaling session for the first time (could be in the initial SDP offer or in a subsequent SDP 
offer) owns the even SCTP stream ids as long as this "m" line is in use. And if this "m" line is 
removed (its <port> set to zero) and later on re-used again, that then that agent owns the even SCTP 
stream ids which creates this new SDP offer with this "m" line's <port> set again to a non-zero 
value (as long as this "m" line is again in use).

What do you think? What that make it clearer?

---

From: Juergen Stoetzer-Bradler <[email-masked]>
Date: Fri, 27 Feb 2015 20:52:51 +0100

Hi Christer,

Thanks for your feedback.

Indeed, except for its headline draft-ietf-rtcweb-data-channel-13 (almost) always just talks of 
"data channel".

Paul, Christer,
Would you be ok if we defined "data channel" in the terminology section as a "WebRTC data channel" 
as specified in [draft-ietf-rtcweb-data-channel]
and then consistently just use "data channel" throughout the remainder of the document?

Thanks again,
Juergen

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 27 Feb 2015 15:34:37 -0500

On 2/27/15 2:52 PM, Juergen Stoetzer-Bradler wrote:
> Indeed, except for its headline draft-ietf-rtcweb-data-channel-13
> (almost) always just talks of "data channel".
>
> Paul, Christer,
> Would you be ok if we defined "data channel" in the terminology section
> as a "WebRTC data channel" as specified in [draft-ietf-rtcweb-data-channel]

Yes, that would work for me.

	Thanks,
	Paul

>>> "webrtc" from the
>> I agree. Having said that, perhaps something in addition to "data
>> channel" would be useful. E.g. "sctp data channel", or something...
>>
>> Regards,
>>
>> Christer
>>
>>
>
>
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
>

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 27 Feb 2015 15:56:14 -0500

On 2/27/15 2:52 PM, Juergen Stoetzer-Bradler wrote:
>> *signaling session* (e.g., sip dialog), or the sender of the first
>> offer that includes the "m" line of this SCTP association.
>>
> We could reformulate this by saying that the offerer which adds the
> DTLS/SCTP based "m" line to the signaling session for the first time
> (could be in the initial SDP offer or in a subsequent SDP offer) owns
> the even SCTP stream ids as long as this "m" line is in use. And if this
> "m" line is removed (its <port> set to zero) and later on re-used again,
> that then that agent owns the even SCTP stream ids which creates this
> new SDP offer with this "m" line's <port> set again to a non-zero value
> (as long as this "m" line is again in use).
>

ISTM that whenever the association is renegotiated, which of necessity 
means that there will be a state change resulting in no channels 
regardless of how many had previously existed, then the owners of the 
even and odd ends should also be redetermined.

	Thanks,
	Paul