Subject: [rtcweb] review [draft-ietf-rtcweb-transports]

From: Eduardo Gueiros <[email-masked]>
Date: Wed, 04 Jun 2014 22:16:43 -0600

Some thoughts/suggestions on [draft-ietf-rtcweb-transports-04] that
perhaps could help making the document more clear.

- --
1. Paragraph 1, 2, and 3.

Introduction seems to give fragmented information about this document
[draft-ietf-rtcweb-transports] and the general RTCWEB effort. At times
I don’t know
to which the introduction is referring to. Consider giving that
information in distinct ways. Suggestion:

- - The IETF RTCWEB effort is aimed at specifying a protocol suite that is
useful for real time multimedia exchange between clients. This protocol
suite is designed for WebRTC and intents to satisfy the security
considerations described in the WebRTC security documents [document link].
- - The IEFT RTCWEB effort is part of the WebRTC cooperation between the
IETF and W3C. The overall effort is described in WebRTC Overview
document, [document link].

1. Paragraph 2, 2nd sentence

“This document focuses on the data…” - To me it’s not clear which
document you’re referring to; the one it was just cited, or this
document [draft-ietf-rtcweb-transports].

3.2. 2nd paragraph
“When TURN is used, and the TURN server has IPv4 or IPv6 connectivity
   to the peer or its TURN server, candidates of the appropriate types
   MUST be supported.”

This could be simplified to “When TURN is used, if the server or the
peer has IPv4 or IPv6 connectivity, candidates of the appropriate types
MUST be supported.”

3.4, 1st Paragraph

Avoid contraction in formal writing, change “it’s” to “it is”

3.4, 2nd Paragraph

“this allows interworking with both…” A clearer sentence would read:  “a
full implementation allows interworking with both…”

3.4 3rd Paragraph

missing comma after “NATs”

3.4 5th Paragraph

missing commas “…TURN [comma] using TCP between the client and server
[comma] MUST be supported.”

The sentence could also be rewritten, for clarification, as: “TURN MUST
be supported when using TCP between the client and the server in order
to deal with firewalls that block all UDP traffic. TURN MUST also be
supported when using TLS over TCP between the client and the server.”

3.4, 6th and 7th Paragraphs should be combined.

3.4 7th Paragraph

- - If the intention of the paragraph to show why TURN TCP candidates  do
not provide significant benefit it needs to indicate so: “…not seen as
providing significant benefit since/because:”
- - suggest change “Secondly” to “Second”
- - suggest change “that use case is anyway supported” to “this use case
is not supported”
- - suggest change “Thirdly” to “Third”

4. 1st Paragraph

It seems to me the word “that” in the sentence “…prioritization model is
that the application tells…” should be changed to ‘what’.

4.1 3rd Paragraph

It seems to me this sentence, “ (same as above + DSCP code point)”,
could be clearer  as  “(5-tuple plus DSCP code point)”

- --
Eduardo Gueiros
Developer | Jive Communications, Inc.
Jive.com | egueiros at jive.com

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 11 Jun 2014 14:17:55 +0200

On 06/05/2014 02:01 AM, Eduardo Gueiros wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> perhaps could help making it more clear.

Thanks for the feedback!

> I don’t
> know to which the introduction is referring to. Consider giving that
> - - The IETF RTCWEB effort is aimed at specifying a protocol suite that
> is useful for real time multimedia exchange between clients. This
> protocol suite is designed for WebRTC and intents to satisfy the
> security considerations described in the WebRTC security documents
> [document link].

I'm not sure that helps. But we should make it shorter.

I'm removing the whole effort description, because it's irrelevant to 
this document - especially when the RFC is published, and the effort is 
concluded.

> document [draft-ietf-rtcweb-transports].

I think this is clear enough - if it had pointed to the other document, 
it would have said "that document".

> peer has IPv4 or IPv6 connectivity, candidates of the appropriate
> types MUST be supported.”

I don't think the proposed sentence is correct, because it doesn't say 
what the server or the peer has to have connectivity to.

The following cases exist (at least) where IPv6 candidates are required:

Client  --IPv4-> TURN server --IPv6-> Peer
Client --IPv6-> TURN server --IPv6-> Peer

Client --IPv4-> Client TURN server --IPv6-> Peer TURN server -IPv4 -> Peer

However, in the following scenario, IPv6 candidates are NOT required:

Client --IPv6-> TURN server --IPv4->Peer

Because even though the TURN server has wonderful IPv6 connectivity, it 
doesn't have IPv6 connectivity to the peer or the peer's TURN server.

> Avoid contraction in formal writing, change “it’s” to “it is”

45 "it's" in the last 250 RFCs, and 2227 "it is". Non-contractions win.
(There doesn't seem to be any such written rule)

>
> 3.4, 2nd Paragraph
>
> “this allows interworking with both…” A clearer sentence would read:
> “a full implementation allows interworking with both…”

Done.
> missing comma after “NATs”
It's not supposed to be there. The sentence parses as

"behind (NATs which perform endpoint-dependent mapping), TURN MUST be 
supported"

There are lots of NATs that don't perform endpoint-dependent mapping.
Changed to "NATs of the type that perform endpoint-dependent mapping".

> [comma] MUST be supported.”

Again, this would change the meaning to a claim that TURN always uses 
TCP, which is false.
Rephrased as "the mode of TURN that uses TCP .... MUST be supported".
>
> The sentence could also be rewritten, for clarification, as: “TURN
> MUST be supported when using TCP between the client and the server in
> order to deal with firewalls that block all UDP traffic. TURN MUST
> also be supported when using TLS over TCP between the client and the
> server.”
>
No, they should not. Paragraph 6 deals with IPv6 candidates, paragraph 7 
deals with TCP candidates.

Perhaps you mean paragraph 7 and 8? That makes more sense, but I still 
want those sentences separated by whitespace, so I'll keep the distinction.
>
> 3.4 7th Paragraph
>
> - - If the intention of the paragraph to show why TURN TCP candidates
> do not provide significant benefit it needs to indicate so: “…not seen
> as providing significant benefit since/because:”
But as long as TURN over TCP is supported, the use case is supported, 
that's the point. Changed "anyway supported" to "supported in a 
different way".
> - - suggest change “Thirdly” to “Third”
Done.

>
> 4. 1st Paragraph
>
> It seems to me the word “that” in the sentence “…prioritization model
> is that the application tells…” should be changed to ‘what’.
I tried "The RTCWEB prioritization model is what the application tells 
the RTCWEB implementation", and couldn't find a meaning for it, so I 
don't think that's right.

The model is that the application tells the implementation something 
about what it wants.

What it tells the implementation ... I don't have a name for.
> could be clearer  as  “(5-tuple plus DSCP code point)”
Makes sense. Done.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
> Comment: GPGTools - https://gpgtools.org
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQEcBAEBCgAGBQJTj7NiAAoJEInLDRowktwYsCoIALzUwWWN2CZ5aXa0LJ5BZN2h
> CDOe4XxZAmaZLYDB8A/HS4SfXswCOaCxOgxmqQD1NN++8znd/0TfgZZ9dq6IbV/N
> m71pkzrv8R0mXkj7wLYiHEyhhX0Sb2KzzjRVwIDSfXIEzWrSlDKw9KLuNrXL7qfe
> NZmKhiyxSjdFOI1eF8qckIiQPCovJfi7j4Q7Ee01A6MxCXPXJdU+rYff88GCGgWi
> f1bN+yC5/NtYJo+icc3Kg7lZCOfYIPgCRoiAI+vQl11IMrygCski5bp3S423sQjX
> HAFSC9U9ram951vXMIb9JBNli3TyZlP51JggcUiBq28tEtabYOjTkpALdbdKoyo=
> =+LbI
> -----END PGP SIGNATURE-----