Subject: [clue] Draft new version: CLUE data channel -06 [was: SCTP port in draft-ietf-clue-datachannel-05]

From: Christer Holmberg <[email-masked]>
Date: Wed, 21 Jan 2015 08:42:32 +0000

Hi,

I have not submitted a new version (-06) of the data channel draft, which reflects the fact that the sctp-port attribute is (at least for now) mandatory.

In addition, as the "DTLS/SCTP" protocol value has now been split into "UDP/DTLS/SCTP" and "TCP/DTLS/SCTP", I tried to reflect that.

Regards,

Christer

-----Original Message-----
From: clue [mailto:[email-masked]] On Behalf Of Christer Holmberg
Sent: 12. tammikuuta 2015 15:50
To: Paul Kyzivat; [email-masked]
Subject: Re: [clue] SCTP port in draft-ietf-clue-datachannel-05

Hi,

My understanding was that people did not want to define a default sctp-port value. Personally I don't care - I just want to get the draft done.

Anyway, that discussion belongs to MMUSIC. However, the CLUE documents still need to be aligned with the latest MMUSIC draft.

Regards,

Christer

-----Original Message-----
From: clue [mailto:[email-masked]] On Behalf Of Paul Kyzivat
Sent: 9. tammikuuta 2015 18:56
To: [email-masked]
Subject: Re: [clue] SCTP port in draft-ietf-clue-datachannel-05

On 1/8/15 6:31 PM, Christian Groves wrote:
> Hello Christer,
>
> In draft-ietf-clue-datachannel-05 it says that the sctp-port is 
> optional, i.e.
>
> 3.2.1.2. SDP sctp-port Attribute
>
>     As defined in [I-D.ietf-mmusic-sctp-sdp], the SDP sctp-port attribute
>     value is set to the SCTP port of the SCTPoDTLS association.
>
>     NOTE: Usage of the SDP sctp-port attribute is optional.  As defined
>     in [I-D.ietf-mmusic-sctp-sdp], if the attribute is not present then
>     the default value is 5000.
>
> However  draft-ietf-mmusic-sctp-sdp-11 says it is mandatory.

That is a new change - one I was not in favor of. :-(

> BTW clause
> 4.5 in the draft should probably also be updated to add a=sctp-port 
> because it is mandatory.
>
> Regards, Christian
>
> _______________________________________________
> clue mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/clue
>

_______________________________________________
clue mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/clue

_______________________________________________
clue mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/clue

---

From: Christian Groves <[email-masked]>
Date: Thu, 22 Jan 2015 15:17:43 +1100

Hello Christer,

The draft still contains both the ejzak and DCEP methods of establishing 
CLUE. We had a discussion in late November on the mailing list and it 
sounded like we were going to drop DCEP?

Regards, Christian

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 22 Jan 2015 10:05:32 +0000

Hi,

>The draft still contains both the ejzak and DCEP methods of establishing >CLUE. We had a discussion in late November on the mailing list and it >sounded like we were going to drop DCEP?

I guess I'll need to check the archives, but were we going to drop DCEP all together, or were we going to say that it is not used if one is using the SDP mechanism (Richard's draft)?

Regards,

Christer

Regards, Christian

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 22 Jan 2015 09:44:30 -0500

> I guess I'll need to check the archives, but were we going to drop DCEP all together, or were we going to say that it is not used if one is using the SDP mechanism (Richard's draft)?

My recollection is that we agreed to drop DCEP, with the possibility to 
resurrect it if something goes wrong with the progression of the ejzak 
draft.

	Thanks,
	Paul

---

From: Christian Groves <[email-masked]>
Date: Fri, 23 Jan 2015 09:13:44 +1100

Hello Paul and Christer,

On 23/01/2015 1:44 AM, Paul Kyzivat wrote:
>>> The draft still contains both the ejzak and DCEP methods of 
>>> establishing >CLUE. We had a discussion in late November on the 
>>> mailing list and it >sounded like we were going to drop DCEP?
>>
>> I guess I'll need to check the archives, but were we going to drop 
>> DCEP all together, or were we going to say that it is not used if one 
>> is using the SDP mechanism (Richard's draft)?
>
> My recollection is that we agreed to drop DCEP, with the possibility 
> to resurrect it if something goes wrong with the progression of the 
> ejzak draft.
>
>     Thanks,
>     Paul
[CNG] Yes that was my recollection also. At least that's what I 
understood from the last IETF meeting minutes:
https://tools.ietf.org/wg/clue/minutes?item=minutes-91-clue.html

There would be one option and that the m= for that datachannel would be 
removed from the a=group:CLUE. The signalling document doesn't reflect 
that yet though.

Regards, Christian

>>> I have not submitted a new version (-06) of the data channel draft, 
>>> which reflects the fact that the sctp-port attribute is (at least 
>>> for now) mandatory.
>>>
>>> In addition, as the "DTLS/SCTP" protocol value has now been split 
>>> into "UDP/DTLS/SCTP" and "TCP/DTLS/SCTP", I tried to reflect that.
>>>
>>> Regards,
>>>
>>> Christer
>>>
>>> My understanding was that people did not want to define a default 
>>> sctp-port value. Personally I don't care - I just want to get the 
>>> draft done.
>>>
>>> Anyway, that discussion belongs to MMUSIC. However, the CLUE 
>>> documents still need to be aligned with the latest MMUSIC draft.
>>>
>>> Regards,
>>>
>>> Christer
>>>

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 23 Jan 2015 14:56:07 +0000

Hi,

> My recollection is that we agreed to drop DCEP, with the possibility to resurrect it if something goes wrong with the progression of the ejzak draft.

Ok. So, related to the discussion on whether CLUE is only for SIP, CLUE would at least require the usage of SDP, right?

Regards,

Christer

---

From: Christian Groves <[email-masked]>
Date: Mon, 26 Jan 2015 15:53:44 +1100

Hello Christer,

> Ok. So, related to the discussion on whether CLUE is only for SIP, CLUE would at least require the usage of SDP, right?
[CNG] For our work yes, however I don' think SDP is mandatory in all 
cases. So long as whatever ever is used to describe the encodings/bearer 
(e.g. H.245) contains a reference to the CLUE encodingID then I think 
CLUE can be used.

Regards, Christian

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 26 Jan 2015 08:25:05 +0000

Hi,

>[CNG] For our work yes, however I don' think SDP is mandatory in all cases. So long as whatever ever is used to describe the encodings/bearer (e.g. H.245) contains a reference to the CLUE encodingID then I think CLUE can be used.

Sure. 

But, then, if you want to use DCEP for H.245, you would have to define that separately.

Regards,

Christer

---

From: Christian Groves <[email-masked]>
Date: Mon, 26 Jan 2015 21:16:43 +1100

Hello Christer,

> But, then, if you want to use DCEP for H.245, you would have to define that separately.

Yes exactly, that work is currently being done in Q2 and q5 ITU-T SG16.

Christian