Subject: [MMUSIC] New draft version: draft-ietf-mmusic-data-channel-sdpneg-01

From: Juergen Stoetzer-Bradler <[email-masked]>
Date: Mon, 9 Mar 2015 12:04:57 +0100

Hello,

Have submitted version -01 of draft-ietf-mmusic-data-channel-sdpneg.
The changes as compared to version -00 are listed below and are related to corresponding recent 
email list discussions.
This list is also copied to the change log section 10.1.

Thanks,
Juergen

    o  In Section 3 "WebRTC data channel" was defined as "A bidirectional
       channel consisting of paired SCTP outbound and inbound streams."
       Replacement of this definition with "Data channel: A WebRTC data
       channel as specified in [I-D.ietf-rtcweb-data-channel]", and
       consistent usage of "data channel" in the remainder of the
       document including the document's headline."

    o  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 more
       general term.'

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

    o  In Section 5.1.1 removal of the example dcmap attribute line
       'a=dcmap:2 subprotocol="BFCP";label="channel 2' as there are
       already four examples right after the ABNF rules in
       Section 5.1.1.1.  Corresponding removal of following related note:
       "Note: This document does not provide a complete specification of
       how to negotiate the use of a WebRTC data channel to transport
       BFCP.  Procedures specific to each sub-protocol such as BFCP will
       be documented elsewhere.  The use of BFCP is only an example of
       how the generic procedures described herein might apply to a
       specific sub-protocol."

    o  In Section 5.1.1 removal of following note: "Note: This attribute
       is derived from attribute "webrtc-DataChannel", which was defined
       in old version 03 of the following draft, but which was removed
       along with any support for SDP external negotiation in subsequent
       versions: [I-D.ietf-mmusic-sctp-sdp]."

    o  Insertion of following new sentence to the beginning of
       Section 5.1.1.1: "dcmap is a media level attribute having
       following ABNF syntax:"

    o  Insertion of new Section 5.1.1.2 containing the dcmap-stream-id
       specifying sentence, which previously was placed right before the
       formal ABNF rules.  Removal of the sentence 'Stream is a mandatory
       parameter and is noted directly after the "a=dcmap:" attribute's
       colon' as this information is part of the ABNF specification.

    o  In Section 5.1.1.1 modification of the 'ordering-value' values
       from "0" or "1" to "true" or "false".  Corresponding text
       modifications in Section 5.1.1.7.

    o  In Section 5.1.1.1 the ABNF definition of "quoted-string" referred
       to rule name "escaped-char", which was not defined.  Instead a
       rule with name "escaped" was defined.  Renamed that rule's name to
       "escaped-char".

    o  Insertion of a dedicated note right after the "a=dcmap:4"
       attribute example in Section 5.1.1.1 regarding the non-printable
       "escaped-char" character within the "label" value.

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

    o  In first paragraph of Section 5.2.1 replacement of first two
       sentences 'For the SDP-based external negotiation described in
       this document, the initial offerer based "SCTP over DTLS" owns by
       convention the even stream identifiers whereas the initial
       answerer owns the odd stream identifiers.  This ownership is
       invariant for the whole lifetime of the signaling session, e.g. it
       does not change if the initial answerer sends a new offer to the
       initial offerer.' with 'If an SDP offer / answer exchange (could
       be the initial or a subsequent one) results in a UDP/DTLS/SCTP or
       TCP/DTLS/SCTP based media description being accepted, and if this
       SDP offer / answer exchange results in the establishment of a new
       SCTP association, then the SDP offerer owns the even SCTP stream
       ids of this new SCTP association and the answerer owns the odd
       SCTP stream identifiers.  If this "m" line is removed from the
       signaling session (its port number set to zero), and if usage of
       this or of a new UDP/DTLS/SCTP or TCP/DTLS/SCTP based "m" line is
       renegotiated later on, then the even and odd SCTP stream
       identifier ownership is redetermined as well as described above.'

    o  In Section 5.2.3 the first action of an SDP answerer, when
       receiving an SDP offer, was described as "Applies the SDP offer.
       Note that the browser ignores data channel specific attributes in
       the SDP."  Replacement of these two sentences with "Parses and
       applies the SDP offer.  Note that the typical parser normally
       ignores unknown SDP attributes, which includes data channel
       related attributes."

    o  In Section 5.2.3 the second sentence of the third SDP answerer
       action was "Note that the browser is asked to create data channels
       with stream identifiers not "owned" by the agent.". Replacement
       of this sentence with "Note that the agent is asked to create data
       channels with SCTP stream identifiers contained in the SDP offer
       if the SDP offer is accepted."

    o  In Section 5.2.4 the third paragraph began with "A data channel
       can be closed by sending a new SDP offer which excludes the dcmap
       and dcsa attribute lines for the data channel.  The port value for
       the m line should not be changed (e.g., to zero) when closing a
       data channel (unless all data channels are being closed and the
       SCTP association is no longer needed), since this would close the
       SCTP association and impact all of the data channels.  If the
       answerer accepts the SDP offer then it MUST also exclude the
       corresponding attribute lines in the answer. ..." Replacement of
       this part with "The intention to close a data channel can be
       signaled by sending a new SDP offer which excludes the "a=dcmap:"
       and "a=dcsa:" attribute lines for the data channel.  The port
       value for the "m" line SHOULD not be changed (e.g., to zero) when
       closing a data channel (unless all data channels are being closed
       and the SCTP association is no longer needed), since this would
       close the SCTP association and impact all of the data channels.
       If the answerer accepts the SDP offer then it MUST close those
       data channels whose "a=dcmap:" and "a=dcsa:" attribute lines were
       excluded from the received SDP offer, unless those data channels
       were already closed, and it MUST also exclude the corresponding
       attribute lines in the answer."

    o  In Section 5.2.4 the hanging text after the third paragraph was
       "This delayed close is to handle cases where a successful SDP
       answer is not received, in which case the state of session should
       be kept per the last successful SDP offer/answer." Replacement of
       this sentence with "This delayed closure is RECOMMENDED in order
       to handle cases where a successful SDP answer is not received, in
       which case the state of the session SHOULD be kept per the last
       successful SDP offer/answer."

    o  Although dedicated to "a=dcmap" and "a=dcsa" SDP syntax aspects
       Section 5.1.1 contained already procedural descriptions related to
       data channel reliability negotiation.  Creation of new
       Section 5.2.2 and moval of reliability negotiation related text to
       this new section.

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 09 Mar 2015 11:33:52 -0400

Juergen,

In general this is good. I have a few remaining comments:

Section 5.2.2 says:

    ... If an SDP offer contains both of
    these parameters then such an SDP offer will be rejected.

The use of "will" is confusing - it isn't normative. IMO it should 
either use "MUST" or else it should say such usage is undefined.

Then:

    The SDP answer shall echo the same subprotocol, max-retr, max-time,
    ordered parameters, if those were present in the offer, and may

Again, "shall" is non-normative. IMO this should be SHALL or MUST.

Then:

    Data channel types defined in [I-D.ietf-rtcweb-data-protocol] are
    mapped to SDP in the following manner:

    DATA_CHANNEL_RELIABLE
          a=dcmap:2 subprotocol="BFCP";label="channel 2"
    ...

"This is a bit unclear because these are *examples* using BFCP. (It also 
uses 'ordered=0' rather than 'ordered=false'. I think it would be 
clearer as:

    Data channel types defined in [I-D.ietf-rtcweb-data-protocol] are
    mapped to SDP a=dcmap parameters in the following manner:

    DATA_CHANNEL_RELIABLE
          ordered=true

    DATA_CHANNEL_RELIABLE_UNORDERED
          ordered=false

    DATA_CHANNEL_PARTIAL_RELIABLE_REXMIT
          ordered=true;max-retr=NNN

    DATA_CHANNEL_PARTIAL_RELIABLE_REXMIT_UNORDERED
          ordered=false;max-retr=NNN

    DATA_CHANNEL_PARTIAL_RELIABLE_TIMED
          ordered=true;max-time=NNN

    DATA_CHANNEL_PARTIAL_RELIABLE_TIMED_UNORDERED
          ordered=false;max-time=NNN

('ordered=true' is default and may be omitted.)"

	Thanks,
	Paul

On 3/9/15 7:04 AM, Juergen Stoetzer-Bradler wrote:
> The changes as compared to version -00 are listed below and are related
> to corresponding recent email list discussions.
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
>

---

From: Christian Groves <[email-masked]>
Date: Tue, 10 Mar 2015 13:32:23 +1100

Hello Juergen,

It looks pretty good. In addition to Paul's comments, a minor comment on 
5.2.5 "SDP offer has no a=dcmap attribute". Perhaps for clarity in the 
"Initial SDP offer" step it should indicate that the DTLS/SCTP is 
requested to be setup but with no data channel requested yet? The step 
"Subsequent SDP offer" indicates that the "established DTLS/SCTP 
association" remains. The other steps also indicate the relation to the 
DTLS association.

Regards, Christian

On 9/03/2015 10:04 PM, Juergen Stoetzer-Bradler wrote:
> The changes as compared to version -00 are listed below and are 
> related to corresponding recent email list discussions.

---

From: Juergen Stoetzer-Bradler <[email-masked]>
Date: Tue, 10 Mar 2015 16:21:52 +0100

Paul,

Thank you for further comments.
Please see my remarks inserted below.

Thanks,
Juergen

On 09.03.2015 16:33, Paul Kyzivat wrote:
> The use of "will" is confusing - it isn't normative. IMO it should either use "MUST" or else it 
> should say such usage is undefined.

[Juergen] The intention is indeed to request the answerer to reject sch an SDP offer.
Thus we could say:
"... If an SDP offer contains both of these parameters then such an SDP offer MUST be rejected."

> Again, "shall" is non-normative. IMO this should be SHALL or MUST.

[Juergen] Agreed. Would propose to say:
"The SDP answer SHALL echo the same subprotocol, max-retr, max-time, ordered parameters, ..."

> "This is a bit unclear because these are *examples* using BFCP. (It also uses 'ordered=0' rather 
> than 'ordered=false'. I think it would be clearer as:
>

[Juergen] We fully agree an will update the text as you propose in next draft -02.

>     Paul
[snip]

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 10 Mar 2015 12:05:29 -0400

WFM

On 3/10/15 11:21 AM, Juergen Stoetzer-Bradler wrote:
>> "This is a bit unclear because these are *examples* using BFCP. (It
>> also uses 'ordered=0' rather than 'ordered=false'. I think it would be
>> clearer as:
>>

---

From: Juergen Stoetzer-Bradler <[email-masked]>
Date: Wed, 11 Mar 2015 14:11:47 +0100

Hello Christian,

Thank you for your comment.

In section 5.2.5, instead of just
     "Initial SDP offer: No data channel negotiated yet.",
what would you think of

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

Thanks,
Juergen

On 10.03.2015 03:32, Christian Groves wrote:
> Hello Juergen,
>
> It looks pretty good. In addition to Paul's comments, a minor comment on 5.2.5 "SDP offer has no 
> a=dcmap attribute". Perhaps for clarity in the "Initial SDP offer" step it should indicate that 
> the DTLS/SCTP is requested to be setup but with no data channel requested yet? The step 
> "Subsequent SDP offer" indicates that the "established DTLS/SCTP association" remains. The other 
> steps also indicate the relation to the DTLS association.
>
> Regards, Christian
>
[snip]

---

From: Christian Groves <[email-masked]>
Date: Thu, 12 Mar 2015 13:04:26 +1100

Hello Juergen,

The suggested change sounds good to me.

Regards, Christian

On 12/03/2015 12:11 AM, Juergen Stoetzer-Bradler wrote:
>     The DTLS connection and SCTP association is negotiated and, if 
> agreed, established as per [draft-ietf-mmusic-sctp-sdp]."
>
> Thanks,
> Juergen
>
>
>> It looks pretty good. In addition to Paul's comments, a minor comment 
>> on 5.2.5 "SDP offer has no a=dcmap attribute". Perhaps for clarity in 
>> the "Initial SDP offer" step it should indicate that the DTLS/SCTP is 
>> requested to be setup but with no data channel requested yet? The 
>> step "Subsequent SDP offer" indicates that the "established DTLS/SCTP 
>> association" remains. The other steps also indicate the relation to 
>> the DTLS association.
>>
>> Regards, Christian
>>
> [snip]
>