Subject: [rtcweb] Ben Campbell's Yes on draft-ietf-rtcweb-transports-14: (with COMMENT)

From: "Ben Campbell" <[email-masked]>
Date: Mon, 01 Aug 2016 17:39:05 -0700

Ben Campbell has entered the following ballot position for
draft-ietf-rtcweb-transports-14: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-rtcweb-transports/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thanks for writing this. It's a well written document that really helps
bring together the rather fragmented specifications that an implementor
needs to understand. I have one minor and a few editorial comments:

Minor Comments:

- 4.2, 2nd to last paragraph:"Sending data over multiple 5-tuples is not
supported."
I am confused by this, since the last few paragraphs required support for
a separate 5-tuple per media stream. That seems to be a form of sending
data over multiple 5-tuples.  Does this mean to distinguish "data" from
"media", maybe in the in the sense of "data-channels"?

- Informative References: 
Please consider whether the references to rtcweb-overview, RFC 4595, and
RFC 7656 should be normative references. They are cited for definition of
terms used in this document; if those definitions are needed to fully
understand this document, they should be normative. (IMHO, these are
borderline).

Editorial Comments:

- Please expand TURN, SSL, and ICE on first mention.

- 3.4, 5th paragraph from end: "using TCP only between the endpoint and
its relay"
I _think_ this means the use of TCP on the hop between the endpoint and
the relay and not on other hops, but some may read it as the use of TCP
but not other protocols on that hop.

- 4.2: There are a few instances of text of the form of "...
packets...use a single DSCP code point", which I think would be more
clear with s/a single/the same.

---

From: Harald Alvestrand <[email-masked]>
Date: Tue, 2 Aug 2016 09:54:41 +0200

Thanks for the review!

> https://datatracker.ietf.org/doc/draft-ietf-rtcweb-transports/

Yes, that's the intention. Sending data-channel data (that is, not
"media") over multiple 5-tuples is not supported.

Filed as #27

> understand this document, they should be normative. (IMHO, these are

Filed as #28. Earlier discussions have shown a preference for a) keeping
terminology in -overview, and b) keeping references to -overview
informational, to avoid the "all must be done before anything is done"
problem.

Treating definitions consistently seems reasonable to me. Agree that
it's borderline.
Advice sought.

> clear with s/a single/the same.

Editorials filed as #29. The reason to use "a single" is to avoid the
misinterpretation of "the same" as "the same as in a previous
paragraph", which may be an issue with the TCP paragraph, but not with
the SCTP paragraph. Language should be consistent between the two.

---

From: "Ben Campbell" <[email-masked]>
Date: Tue, 02 Aug 2016 09:42:48 -0500

Thanks for the response. See inline:

Ben.

On 2 Aug 2016, at 2:54, Harald Alvestrand wrote:

[...]

> Treating definitions consistently seems reasonable to me. Agree that

The litmus test is whether a reader can fully understand the draft 
without reading the informative references. It will leave these to you 
and Alissa to decide whether that is the case here; I'm not going to 
block on this either way.

> the SCTP paragraph. Language should be consistent between the two.

I'm okay with the current wording if there is a reason to keep it that 
way.