Subject: [clue] draft-clue-data-channel-07(no, -08) WGLC review -- DanB comments

From: Daniel Burnett <[email-masked]>
Date: Fri, 13 Feb 2015 17:54:13 -0500

Christer,

Many of the comments I had for the -07 draft have already been addressed in
-08, so thank you!

General comments:
- For novice (IESG) readers, if 'SCTPoDTLS' means something different than
'SCTP over DTLS', you should add that explanation in section 2 where you
define 'SCTPoDTLS'.  Otherwise, use the same term everywhere.
- I will do a complete grammar/editorial review later, but for now I
noticed that use of a/an before SCTP is inconsistent.  Technically if you
read it as 'S C T P' you should use 'an', but if you read it as 'Stream
Control Transmission Protocol' you should use 'a'.  It doesn't really
matter which you use, but you should be consistent.
- Similarly, capitalization of Data Channel, e.g., in 'WebRTC Data
Channel', is inconsistent.  Pick one style and use it everywhere.

Section 1.

Do we really want to confuse people with the text
'  NOTE: The usage of the Data Channel Establishment Protocol (DCEP)
   [I-D.ietf-rtcweb-data-protocol] for establishing a CLUE data channel
   is outside the scope of this document. '
in the document since we essentially require use of sdpneg?  Or do we
actually permit other ways to set up CLUE data channels?  If we do permit
other ways, this text should probably be made more generic in explaining
that we define only one way to establish CLUE data channels, do not forbid
other ways, but any other way (such as DCEP) is out of scope.

Section 2.

'CLUE session refers to a SIP session [RFC3261] between to SIP UAs' ->
'CLUE session refers to a SIP session [RFC3261] between two SIP UAs'

'SCTP identifier is defined in [RFC4960] as a unsigned integer' ->
'SCTP identifier is defined in [RFC4960] as an unsigned integer'

Section 3.

I don't know whether it belongs here or in section 1, but it might help a
novice reader to say a little more about the relationship between WebRTC
data channels and CLUE data channels as context.  Just a few sentences
might help.  For example, the first paragraph in 3.1 could be changed to

'This section describes the realization of a CLUE data channel using a
WebRTC data channel.  The WebRTC Data Channel was developed to provide a
simple mechanism for two endpoints, for example two web browsers, to
establish channels for carrying arbitrary data.  The WebRTC Data Channel
accomplishes this by creating SCTP streams over a DTLS connection.  The
details are described in [I-D.ietf-rtcweb-data-channel].  Additional items
need to be defined in order to use a WebRTC data channel as a CLUE data
channel:  a set of SCTP characteristics specific to a CLUE data channel,
the values of the m- line describing the SCTPoDTLS association associated
with the WEBRTC Data Channel, and the usage of the SDP-based "SCTP over
DTLS" data channel negotiation mechanism for creating the CLUE data
channel.'

You could also consider adding a few words about how a WebRTC data channel
is normally expected to be signaled so readers can understand what is
different about what CLUE is defining.

-- dan

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 13 Feb 2015 23:19:45 +0000

Hi Dan,

Thanks for your review! See inline.

General comments:

> - For novice (IESG) readers, if 'SCTPoDTLS' means something different than 'SCTP over 
> DTLS', you should add that explanation in section 2 where you define 'SCTPoDTLS'.  Otherwise, 
> use the same term everywhere.

Section 2 does say:

	"SCTPoDTLS association refers to an SCTP association carried over an
   	DTLS connection [I-D.ietf-tsvwg-sctp-dtls-encaps]."

I'm not sure I understand what you want me to add?

---------------

>- I will do a complete grammar/editorial review later, but for now I noticed that use of a/an before SCTP is >inconsistent.  Technically if you read it as 'S C T P' you should use 'an', but if you read it as 'Stream Control Transmission Protocol' >you should use 'a'.  It doesn't really matter which you use, but you should be consistent.

My intention has been to use 'an'. I'll fix it in -09.

> - Similarly, capitalization of Data Channel, e.g., in 'WebRTC Data Channel', is inconsistent.  Pick one style and use it everywhere.

I'll use small letters for now. Once the WebRTC data channel draft is ready, I'll align.

---------------

Section 1.

> in the document since we essentially require use of sdpneg?  Or do we actually permit other ways to set up CLUE data 
> channels?  If we do permit other ways, this text should probably be made more generic in explaining that we define only one 
> way to establish CLUE data channels, do not forbid other ways, but any other way (such as DCEP) is out of scope.

I think the note is useful, because the WebRTC data channel draft does mention DCEP as a mechanism for establishing data channels. And, in my opinion "outside the scope of this document" does mean that others can define it :)

---------------

Section 2.

>'CLUE session refers to a SIP session [RFC3261] between two SIP UAs'

Will be fixed in -09.

>'SCTP identifier is defined in [RFC4960] as an unsigned integer'

Will be fixed in -09.

---------------

Section 3.

> I don't know whether it belongs here or in section 1, but it might help a novice reader to say a little more about the relationship > between WebRTC data channels and CLUE data channels as context.  Just a few sentences might help.  For example, the first 
> paragraph in 3.1 could be changed to
>
> 'This section describes the realization of a CLUE data channel using a WebRTC data channel.  The WebRTC Data Channel was 
> developed to provide a simple mechanism for two endpoints, for example two web browsers, to establish channels for carrying 
> arbitrary data.  The WebRTC Data Channel accomplishes this by creating SCTP streams over a DTLS connection.  The details are 
> described in [I-D.ietf-rtcweb-data-channel].  Additional items need to be defined in order to use a WebRTC data channel as a 
> CLUE data channel:  a set of SCTP characteristics specific to a CLUE data channel, the values of the m- line describing the 
> SCTPoDTLS association associated with the WEBRTC Data Channel, and the usage of the SDP-based "SCTP over DTLS" data 
> channel negotiation mechanism for creating the CLUE data channel.'

I can do the modification in -09.

> You could also consider adding a few words about how a WebRTC data channel is normally 
> expected to be signaled so readers can understand what is different about what CLUE is defining.

Perhaps I could move the note you commented on earlier down to section 3.1?

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 19 Feb 2015 17:29:53 +0000

Hi Dan,

Did you reply to this?

Regards,

Christer

-----Original Message-----
From: clue [mailto:[email-masked]] On Behalf Of Christer Holmberg
Sent: 14 February 2015 01:20
To: Daniel Burnett; [email-masked]
Subject: Re: [clue] draft-clue-data-channel-07(no, -08) WGLC review -- DanB comments

Hi Dan,

General comments:

> - For novice (IESG) readers, if 'SCTPoDTLS' means something different 
> than 'SCTP over DTLS', you should add that explanation in section 2 
> where you define 'SCTPoDTLS'.  Otherwise, use the same term everywhere.

Section 2 does say:

---------------

---------------

Section 1.

> Do we really want to confuse people with the text  '  NOTE: The usage 
>of the Data Channel Establishment Protocol (DCEP)
>actually permit other ways to set up CLUE data  channels?  If we do 
>permit other ways, this text should probably be made more generic in explaining that we define only one  way to establish CLUE data channels, do not forbid other ways, but any other way (such as DCEP) is out of scope.

---------------

Section 2.

Will be fixed in -09.

Will be fixed in -09.

---------------

Section 3.

> I don't know whether it belongs here or in section 1, but it might 
> help a novice reader to say a little more about the relationship > 
> between WebRTC data channels and CLUE data channels as context.  Just 
> a few sentences might help.  For example, the first paragraph in 3.1 
> could be changed to
>
> WebRTC data channel.  The WebRTC Data Channel was developed to provide 
> a simple mechanism for two endpoints, for example two web browsers, to 
> establish channels for carrying arbitrary data.  The WebRTC Data 
> Channel accomplishes this by creating SCTP streams over a DTLS 
> connection.  The details are described in 
> [I-D.ietf-rtcweb-data-channel].  Additional items need to be defined in order to use a WebRTC data channel as a CLUE data channel:  a set of SCTP characteristics specific to a CLUE data channel, the values of the m- line describing the SCTPoDTLS association associated with the WEBRTC Data Channel, and the usage of the SDP-based "SCTP over DTLS" data channel negotiation mechanism for creating the CLUE data channel.'

> You could also consider adding a few words about how a WebRTC data 
> channel is normally expected to be signaled so readers can understand what is different about what CLUE is defining.

Regards,

Christer

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

---

From: Daniel Burnett <[email-masked]>
Date: Thu, 19 Feb 2015 14:17:03 -0500

On Fri, Feb 13, 2015 at 6:19 PM, Christer Holmberg <
[email-masked]> wrote:

> than 'SCTP over

In multiple locations you use "SCTP over DTLS", in quotes, to talk about
SCTP over DTLS.  You do define 'SCTPoDTLS association'.  I'm just saying
that you should either use 'SCTPoDTLS' or "SCTP over DTLS" everywhere.  In
the case of the association it would then either be 'SCTPoDTLS association'
or 'SCTP over DTLS association', whichever you had chosen.  The fact that
you use 'SCTPoDTLS' could make someone wonder if you don't mean "SCTP over
DTLS" when you use it.

> noticed that use of a/an before SCTP is >inconsistent.  Technically if you
> Control Transmission Protocol' >you should use 'a'.  It doesn't really
> actually permit other ways to set up CLUE data
> > channels?  If we do permit other ways, this text should probably be made
> more generic in explaining that we define only one
> > way to establish CLUE data channels, do not forbid other ways, but any
> other way (such as DCEP) is out of scope.
>
> I think the note is useful, because the WebRTC data channel draft does
> mention DCEP as a mechanism for establishing data channels. And, in my
> opinion "outside the scope of this document" does mean that others can
> define it :)
>

How about this?  Replace the text I quote above with

'  NOTE:  This specification defines only one way to establish data
channels.  The mechanism defined in this specification is different from
the Data Channel Establishment Protocol [I-D.ietf-rtcweb-data-protocol]
defined for WebRTC data channels. Definition and/or usage of any protocol
for establishing CLUE data channels other than that defined in this
specification is out of scope for this document.'

> > I don't know whether it belongs here or in section 1, but it might help
> a novice reader to say a little more about the relationship > between
> WebRTC data channels and CLUE data channels as context.  Just a few
> sentences might help.  For example, the first
> WebRTC data channel.  The WebRTC Data Channel was
> > developed to provide a simple mechanism for two endpoints, for example
> two web browsers, to establish channels for carrying
> > arbitrary data.  The WebRTC Data Channel accomplishes this by creating
> SCTP streams over a DTLS connection.  The details are
> > described in [I-D.ietf-rtcweb-data-channel].  Additional items need to
> be defined in order to use a WebRTC data channel as a
> > CLUE data channel:  a set of SCTP characteristics specific to a CLUE
> data channel, the values of the m- line describing the
> > SCTPoDTLS association associated with the WEBRTC Data Channel, and the
> usage of the SDP-based "SCTP over DTLS" data
> channel is normally

I have proposed text after my earlier comment that should take care of this.

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 21 Feb 2015 13:11:25 +0000

Hi Dan,

> SCTP over DTLS.  You do define 'SCTPoDTLS > association'.  I'm just saying 
> that you should either use 'SCTPoDTLS' or "SCTP over DTLS" everywhere.  
> In the case of the association it would then either be 'SCTPoDTLS association' 
> or 'SCTP over DTLS association', whichever you had chosen.  The fact that you u
> se 'SCTPoDTLS' could make someone wonder if you don't mean "SCTP over DTLS" 
> when you use it.  
 
Aaaah, now I got it :)

Unless I've missed it, the only place where I use "SCTP over DTLS" is where I refer to the SDP data channel negotiation draft.

Of course, I could change all instances of "SCTPoDTLS" to "SCTP over DTLS". There are quite a few of them, though, so I think the text could become rather clumsy.

Perhaps I could fix this by modifying the section 2 text to:

	"SCTPoDTLS (SCTP over DTLS) association refers to an SCTP association 
	carried over ancDTLS connection [I-D.ietf-tsvwg-sctp-dtls-encaps]."

---------------

> I'll use small letters for now. Once the WebRTC data channel draft is ready, I'll align.

Just keeping this as a place holder :)

---------------

Section 1.

> I think the note is useful, because the WebRTC data channel draft does mention DCEP as a mechanism for establishing data 
> channels. And, in my opinion "outside the scope of this document" does mean that others can define it :)
>
>'  NOTE:  This specification defines only one way to establish data channels.  The 
> mechanism defined in this specification is different from the Data Channel 
> Establishment Protocol [I-D.ietf-rtcweb-data-protocol] defined for WebRTC data 
> channels. Definition and/or usage of any protocol for establishing CLUE data channels 
> other than that defined in this specification is out of scope for this document.'

I think your suggested text may cause some confusion, because the way I read the text, it talks about "WebRTC data channels" and "CLUE data channels" as two separate things. WebRTC data channel is a mechanism, and the CLUE data channel is a usage of that WebRTC data channel mechanism :)

---------------

Section 3.

>> I don't know whether it belongs here or in section 1, but it might help a novice reader to say a little more about the relationship >> between WebRTC data channels and CLUE data channels as context.  Just a few sentences might help.  For example, the first

I had a closer look at this, and compared it to the existing text in the draft, and I'd like to suggest a little different version.

First, section 1 already says:

	"This document defines how to use the WebRTC data channel mechanism in order to realized a data channel,
	Referred to as CLUE data channel, for transporting CLUE protocol messages between two CLUE endpoints."

So, I think the "relationship is already there".

In addition, section 1 also talks about usage of SCTP over DTLS.

So, my suggestion would be to only modify the first sentence in section 3.1 to:

	"This section describes the realization of a CLUE data channel, using the WebRTC data channel mechanism."

...and keep the rest as it is.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Sat, 21 Feb 2015 11:36:47 -0500

> Of course, I could change all instances of "SCTPoDTLS" to "SCTP over DTLS". There are quite a few of them, though, so I think the text could become rather clumsy.

I think it would be good to be consistent, one way or the other. I don't 
feel strongly - I can live with either.

I will say that *perhaps* "SCTP over DTLS" would be more readable 
without expanding the text much. That avoids the need for a definition 
that some readers apparently miss. This might be something to discuss 
with the rfc editor when it gets that far.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 21 Feb 2015 16:54:48 +0000

Hi,

You can try by doing a seach/replace (SCTPoDTLS -> SCTP over DTLS).

Again, I only use SCTP over DTLS when I am writing the subject of Richard's draft.

But, I could of course NOT write the subject of the draft, but only the draft name.

Regards,

Christer

Sent from my Windows Phone
________________________________
From: Paul Kyzivat<mailto:[email-masked]>
Sent: ‎21/‎02/‎2015 18:36
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [clue] draft-clue-data-channel-07(no, -08) WGLC review -- DanB comments

        Thanks,
        Paul