Subject: [clue] Fwd: Comments Re: I-D Action: draft-ietf-clue-datachannel-00.txt

From: Christian Groves <[email-masked]>
Date: Fri, 02 May 2014 09:55:33 +1000

Hello Christer,

Some comments on the latest draft:

cl.3.2: The first two paragraphs need to be merged somehow. The first
indicates mandatory support of DCEP, the 2nd indicates optional support
of DCEP. I think the 2nd paragraph can be used as the 1st sentence of
the first paragraph.

cl.3.3.2: With respect to the note. It says partial reliability is not
needed for CLUE and the reason. The part on limited retransmission is
vague. It doesn't say CLUE doesn't use it nor the reason. (yes I know the
paragraph above rules it out).

cl.3.3.4: The extension defined by RFC6525 is "STCP Stream
Reconfiguration". It has more than just "reset" procedures, e.g. adding
streams, rec-configuration streams. We may want to be a bit more precise
here to avoid any confusion that only the reset procedures are supported.

Regards, Christian

On 22/03/2014 1:11 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-00.txt
> 	Pages           : 12
> 	Date            : 2014-03-20
>
> 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-00
>
>
> 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: Fri, 2 May 2014 13:00:32 +0000

Hi Christian,

> cl.3.2: The first two paragraphs need to be merged somehow. The first indicates mandatory support of DCEP, the 2nd indicates 
> optional support of DCEP. I think the 2nd paragraph can be used as the 1st sentence of the first paragraph.

Note that there is a difference between the mandatory SUPPORT of DCEP, and the OPTIONAL use of DCEP.

I wrote it that way in order to allow for the usage of the mechanism described in "Richard's draft", if it gets ready in time for the publication of the datachannel draft.

However, lately I have seen zero progress of "Richard's draft", so I don't know what/if the authors intend to do... Richard? Keith?

> cl.3.3.2: With respect to the note. It says partial reliability is not needed for CLUE and the reason. The part on 
> limited retransmission is vague. It doesn't say CLUE doesn't use it nor the reason. (yes I know the paragraph 
> above rules it out).

Ok, maybe some extra text is needed.

> cl.3.3.4: The extension defined by RFC6525 is "STCP Stream Reconfiguration". It has more than just "reset" procedures, e.g. 
> adding streams, rec-configuration streams. We may want to be a bit more precise here to avoid any confusion that only the 
> reset procedures are supported.

As far as I know, we DO only need the reset procedures. As far as I know, the general data channel framework doesn't require anything else either, but I may be wrong.

Regards

Christer

On 22/03/2014 1:11 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: Paul Kyzivat <[email-masked]>
Date: Fri, 02 May 2014 10:52:28 -0400

> As far as I know, we DO only need the reset procedures. As far as I know, the general data channel framework doesn't require anything else either, but I may be wrong.

That is my understanding too. But I doubt we want to go into details 
about this, or try to respecify the normative requirements. If we 
specify the dependency on the DCEP draft, then we inherit the 
requirements it pulls in.

	Thanks,
	Paul

---

From: Christian Groves <[email-masked]>
Date: Mon, 05 May 2014 14:42:50 +1000

Hello Paul and Christer,

Please see my comments below.

Regards, Christian

On 3/05/2014 12:52 AM, Paul Kyzivat wrote:
>>> cl.3.2: The first two paragraphs need to be merged somehow. The 
>>> first indicates mandatory support of DCEP, the 2nd indicates
>> I wrote it that way in order to allow for the usage of the mechanism 
>> described in "Richard's draft", if it gets ready in time for the 
>> publication of the datachannel draft.
[CNG] I think you can still capture that in one paragraph:
"In the absence of another mechanism, a CLUE entity MUST support the 
Data Channel Establishment Protocol(DCEP) 
[I-D.ietf-rtcweb-data-channel], which can be used in order to
    open a WebRTC Data Channel."

>>
>> However, lately I have seen zero progress of "Richard's draft", so I 
>> don't know what/if the authors intend to do... Richard? Keith?

>>
>>> cl.3.3.2: With respect to the note. It says partial reliability is 
>>> not needed for CLUE and the reason. The part on
>>> limited retransmission is vague. It doesn't say CLUE doesn't use it 
>>> nor the reason. (yes I know the paragraph
>>> above rules it out).
>>
>>> Reconfiguration". It has more than just "reset" procedures, e.g.
>>> adding streams, rec-configuration streams. We may want to be a bit 
>>> more precise here to avoid any confusion that only the
>> As far as I know, we DO only need the reset procedures. As far as I 
>> know, the general data channel framework doesn't require anything 
>> else either, but I may be wrong.
>
[CNG] The problem is for this we don't specify the dependency and we 
only partially normatively say how stream reset is used. If you want to 
defer to the data channel draft then all we'd need to say is "A CLUE 
entity MUST support RFC6525 and RFC5061 according to 
[I-D.ietf-rtcweb-data-channel].

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 05 May 2014 10:30:23 -0400

Christ(er & ian),

inline...

>     open a WebRTC Data Channel."

That seems to say that in the *presence* of another mechanism support of 
DCEP is *not* required. That would either make this other, unspecified, 
mechanism the one that is mandatory to implement. Or, it might mean 
there is no mandatory to implement mechanism.

IIUC the intent was that DCEP be required to *support*. Some other 
mechanism could be *used* if it can be determined to be supported by 
both ends. That requires two statements, whether in one paragraph or two.

> [I-D.ietf-rtcweb-data-channel].

That would work for me.

I do have a problem with "Other features of [RFC5061] MUST NOT be used."
For one thing, it is in the section on Stream Reset. Does this mean the 
other features MUST NOT be used for resetting streams? Or that they must 
not be used at all?

It is entirely possible that an implementation will use the same SCTP 
session for the clue channel and some other channels. It may use other 
features of 5061 in conjunction with some of those other channels.

It is even possible that it will first use the SCTP session for other 
channels, and then eventually want to enable clue. It may decide it 
needs to adjust the max number of channels before creating the clue 
channel with DCEP. That should not be forbidden.

Bottom line - I would like to see the statement "Other features of 
[RFC5061] MUST NOT be used." removed.

	Thanks,
	Paul