Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-data-channel-07.txt - Some editorial comments on section 5

From: Christer Holmberg <[email-masked]>
Date: Tue, 11 Feb 2014 18:12:39 +0000

Hi,

Some editorial comments:

Q1:

Section 5 says:

	"SCTP as specified in [RFC4960] MUST be used in
   	combination with the extension defined in [RFC3758] and provides the
   	following interesting features for transporting non-media data
   	between browsers:"

I suggest to say:

	"The SCTP extension defined in [RFC3758] MUST be supported, and
     	provides the following features:

Q2:

Section 5 says:

	"Each SCTP user message contains a so called Payload Protocol
   	Identifier (PPID) that is passed..."

I suggest to remove "so called".

Q3:

Section 5 says:

	"This value can be used to multiplex multiple protocols
   	over a single SCTP association.  The sender provides for each
   	protocol a specific PPID and the receiver can demultiplex the
   	messages based on the received PPID."

I think we discussed this earlier. The PPID value CAN NOT (at least not as used by WebRTC) be used to multiplex multiple protocols over a single SCTP association. If you create multiple channels, for multiple protocols, the same PPID values may be used for each protocol.

 The PPID CAN, however, be used within a data channel, e.g. to demultiplex the DCP from channel data.

Q4:

Section 5 says:

	"When using DTLS as the lower layer, only single homed SCTP
   	associations MUST be used, since DTLS does not expose any address
   	management to its upper layer."

I suggest to change "MUST be used" to "are supported".

Q5:

Sometimes you say "SCTP" and sometimes "SCTP as defined in [RFC4960]".

I suggest to e.g. use the reference on the first occurrence, and then only use "SCTP".

Regards,

Christer

---

From: Michael Tuexen <[email-masked]>
Date: Tue, 25 Feb 2014 08:09:36 +0100

>     	provides the following features:
But this implies that the listed features are provided by the extension
defined in RFC 3758, which is not true. The features are provided by
the combination of RFC 4960 and RFC 3758.
> I suggest to remove "so called".
Removed.
> The PPID CAN, however, be used within a data channel, e.g. to demultiplex the DCP from channel data.
I guess the problem is that I consider 'protocol' as something running on top of SCTP
like DCEP, Binary of String data, you consider 'protocol' as something running
on top of Binary of String data and the 'protocol' being identified in the JS protocol string.

What about using:

<t>Each SCTP user message contains a Payload Protocol Identifier (PPID)
that is passed to SCTP by its upper layer on the sending side and
provided to its upper layer on the receiving side.
The PPID can be used to multiplex/demultiplex multiple upper layers over
a single SCTP association.
In the WebRTP context, the PPID is used to distinguish between
UTF-8 encoded user data,
binary encoded userdata and
the Data Channel Establishment Protocol defined in
<xref target='I-D.ietf-rtcweb-data-protocol'/>.
Please note that the PPID is not accessable via the Javascript API.</t>

Does this address your issue?
> I suggest to change "MUST be used" to "are supported".
OK.
> I suggest to e.g. use the reference on the first occurrence, and then only use "SCTP".
I double checked:
SCTP as defined in [RFC4960] is used in
* In the Introduction (first occurrence) talking about SCTP / UDP
* In the Introduction to make sure which specifications are used: RFC 4960 and RFC 3758
* In section 5 when used with RFC 2119 language.
* In section 6 to make clear what relates to RFC 4960 and what to the NDATA extension.

All of these are intentional. Which one do you think is not necessary?
> 
> 
> Regards,
> 
> Christer
> 
> 
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 25 Feb 2014 10:48:59 +0000

Hi,

> But this implies that the listed features are provided by the extension defined in RFC 3758, which is not true. The features are provided by the combination of RFC 4960 and RFC 3758.

Correct. My mistake.

So, my suggestion would then be to remove "as specified in" and "interesting".

 	"SCTP [RFC4960] MUST be used in combination with the extension defined in [RFC3758] and 
	provides the following features for transporting non-media data between browsers:"

The reference implicitly means "as specified in", in my opinon :)

----------

>> I think we discussed this earlier. The PPID value CAN NOT (at least not as used by WebRTC) be used to multiplex multiple protocols 
>> over a single SCTP association. If you create multiple channels, for multiple protocols, the same PPID values may be used for each protocol.
>> 
> I guess the problem is that I consider 'protocol' as something running on top of SCTP like DCEP, Binary of String data, you consider 'protocol' 
> as something running on top of Binary of String data and the 'protocol' being identified in the JS protocol string.
>
> What about using:
>
> <t>Each SCTP user message contains a Payload Protocol Identifier (PPID) that is passed to SCTP by its upper layer on the sending side and provided to its upper layer on the receiving side.
> The PPID can be used to multiplex/demultiplex multiple upper layers over a single SCTP association.
> UTF-8 encoded user data, binary encoded userdata and the Data Channel Establishment Protocol defined in <xref target='I-D.ietf-rtcweb-data-protocol'/>.

Instead of talking about SCTP associations, could we talk about data channels? I.e. the PPID can be used to multiplex/demultiplex multiple upper layers within a single data channel?

Because, if you have multiple data channels on a single SCTP association, you will use the stream IDs  - not the PPIDs - to multiplex/demultiplex between the channels.

----------

> * In the Introduction to make sure which specifications are used: RFC 4960 and RFC 3758

In the 2nd paragraph of the Introduction, the text says:

	"SCTP as specified in [RFC4960] with the partial reliability extension defined in [RFC3758]"

Could you remove "as specified in", and say?

	"SCTP [RFC4960] with the partial reliability extension defined in [RFC3758]"

> * In section 5 when used with RFC 2119 language.

I still think you could remove "as specified in", and say:

	"SCTP [RFC4960] MUST be used in combination with the extension defined..."

> All of these are intentional. Which one do you think is not necessary?

In section 6.6, I think you could remove "specified in", and say:

	"The SCTP base protocol [RFC4960]..."

I am not religious about these things, but again: in my opinion adding the reference means "as specified in", and makes the text easier to read :)

Regards,

Christer