Subject: Re: [clue] I-D Action: draft-ietf-clue-datachannel-02.txt

From: Christian Groves <[email-masked]>
Date: Wed, 12 Nov 2014 16:34:17 +1100

Hello Christer,

Some comments on the latest draft:

The "updated" example needs to be updated further, as the SDP for 
datachannel has been updated and the "DTLS over SCTP" error wasn't fixed :

i.e. from  a=group:CLUE 3
            m=application 54111 SCTP/DTLS 54111
            a=sctpmap:54111 webrtc-datachannel
            a=mid:3
to:
a=group:CLUE 3
m=application 54111 DTLS/SCTP webrtc-datachannel
a=sctp-port 5000
a=mid:3

Clause 5.3 needs to be updated because there's no longer a SDP sctpmap 
attribute.

With regards to OPEN ISSUE 2, cl.5.4 and 5.5 are fairly generic but they 
ignore the aspect that for CLUE the SDP O/A procedures must associate 
the CLUE group to the "m=" line, i.e. as per the example. I think if 
these are added then you can remove open issue 2.

I also think the draft needs to update the text around "/If an offerer, 
in a subsequent offer, wants to disable the CLUE Data Channel, it 
assigns a zero port value to the "m=" line describing the SCTPoDTLS 
association used to realize the CLUE Data Channel./" I think the draft 
needs to be updated to reflect that this will have the effect of closing 
the DTLS and SCTP association (which may not be desirable as other 
applications may share the association). As discussed previously to 
close just the CLUE data channel the m=line would be removed from the 
CLUE group.

Regards, Christian

On 28/10/2014 12:03 AM, [email-masked] wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>   This draft is a work item of the ControLling mUltiple streams for tElepresence Working Group of the IETF.
>
>          Title           : CLUE Protocol Data Channel
>          Author          : Christer Holmberg
> 	Filename        : draft-ietf-clue-datachannel-02.txt
> 	Pages           : 13
> 	Date            : 2014-10-27
>
> Abstract:
>     This document defines how to use the WebRTC Data Channel mechanism,
>     together with the Data Channel Establishment Protocol (DCEP) in order
>     to establish a data channel, referred to as CLUE Data Channel, for
>     transporting CLUE protocol messages between two CLUE entities.
>
>     The document defines the SCTP considerations specific to a CLUE Data
>     Channel, the SDP offer/answer procedures for negotiating the
>     establishment of, and the DCEP procedures for opening, a CLUE Data
>     Channel.
>
>     Details and procedures associated with the CLUE protocol are outside
>     the scope of this document.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-clue-datachannel/
>
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-clue-datachannel-02
>
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=draft-ietf-clue-datachannel-02
>
>
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> clue mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/clue
>

---

From: Christer Holmberg <[email-masked]>
Date: Sun, 16 Nov 2014 01:57:35 +0000

Hi Christian,

>The "updated" example needs to be updated further, as the SDP for datachannel has been >updated and the "DTLS over SCTP" error wasn't fixed :
>
>i.e. from  a=group:CLUE 3
>m=application 54111 DTLS/SCTP webrtc-datachannel a=sctp-port 5000
>a=mid:3
>
>Clause 5.3 needs to be updated because there's no longer a SDP sctpmap attribute.

Correct.

However, in Honolulu we agreed to adopt the ejzak draft, and therefor the DTLS/SCTP m- line is not required to be associated with the CLUE group.

In addition we also agree to not include the sctp-port attribute in the examples, as there can only be one SCTP association per DTLS/SCTP m- line (per agreement in MMUSIC).

>With regards to OPEN ISSUE 2, cl.5.4 and 5.5 are fairly generic but they ignore the aspect that >for CLUE the SDP O/A procedures must associate the CLUE group to the "m=" line, i.e. as per >the example. I think if these are added then you can remove open issue 2.
>
>I also think the draft needs to update the text around "/If an offerer, in a subsequent offer, >wants to disable the CLUE Data Channel, it assigns a zero port value to the "m=" line >describing the SCTPoDTLS association used to realize the CLUE Data Channel./" I think the >draft needs to be updated to reflect that this will have the effect of closing the DTLS and >SCTP association (which may not be desirable as other applications may share the >association). As discussed previously to close just the CLUE data channel the m=line would >be removed from the CLUE group.

My understanding is that some/all of this will go away, as it belongs to the signalling draft.

And, again, it was agreed that whether the m- line is associated with the CLUE group or not has no semantical meaning.

Regards,

Christer

On 28/10/2014 12:03 AM, [email-masked] wrote:
> Please note that it may take a couple of minutes from the time of 
> submission until the htmlized version and diff are available at tools.ietf.org.
>

---

From: Stephen Botzko <[email-masked]>
Date: Wed, 19 Nov 2014 15:24:42 -1000

>>>And, again, it was agreed that whether the m- line is associated with
the CLUE group or not has no semantical meaning.
Well, this was agreed assuming the ezjak draft progresses to publication
reasonably promptly.  The current approach (where the m- line needed to be
in the CLUE group does have meaning) is the fallback.

On Sat, Nov 15, 2014 at 3:57 PM, Christer Holmberg <
[email-masked]> wrote:

> datachannel has been >updated and the "DTLS over SCTP" error wasn't fixed :
> >
> >i.e. from  a=group:CLUE 3
> However, in Honolulu we agreed to adopt the ejzak draft, and therefor the
> DTLS/SCTP m- line is not required to be associated with the CLUE group.
>
> In addition we also agree to not include the sctp-port attribute in the
> examples, as there can only be one SCTP association per DTLS/SCTP m- line
> (per agreement in MMUSIC).
>
> ignore the aspect that >for CLUE the SDP O/A procedures must associate the
> CLUE group to the "m=" line, i.e. as per >the example. I think if these are
> added then you can remove open issue 2.
> >
> in a subsequent offer, >wants to disable the CLUE Data Channel, it assigns
> a zero port value to the "m=" line >describing the SCTPoDTLS association
> used to realize the CLUE Data Channel./" I think the >draft needs to be
> updated to reflect that this will have the effect of closing the DTLS and
> >SCTP association (which may not be desirable as other applications may
> share the >association). As discussed previously to close just the CLUE
> data channel the m=line would >be removed from the CLUE group.
>
> And, again, it was agreed that whether the m- line is associated with the
> CLUE group or not has no semantical meaning.
>
> Regards,
>
> Christer
>
>
>