Subject: Re: GenArt LC review: draft-ietf-tsvwg-rtcweb-qos-15

From: "Paul E. Jones" <[email-masked]>
Date: Tue, 03 May 2016 02:18:18 +0000

Robert,

I am finally getting an opportunity to make updates to the text.

I have responses below...

------ Original Message ------
From: "Robert Sparks" <[email-masked]>
To: "General Area Review Team" <[email-masked]>; "[email-masked]" 
<[email-masked]>; [email-masked]
Sent: 3/31/2016 12:39:13 PM
Subject: GenArt LC review: draft-ietf-tsvwg-rtcweb-qos-15

><snip>
>
>These are very small editorial suggestions:
>
>The introduction says "seldom makes things worse".
>Section 5 says "This is one of the cases ... can make things worse."
>There are no other cases called out, leaving the implementer to guess 
>at what the other pitfalls are.
>
>It would be better to tweak that text to be less vague. I suggest 
>changing the introduction to say "there is one case this draft 
>discusses. Other cases may possibly exist, but are expected to be rare" 
>or similar.

How about this:

   There is one case this draft discusses where such marking does not
   help, but it seldom makes things worse if packets are marked
   appropriately.  Other cases where marking does not help may possibly
   exist, but are expected to be rare.  There are some environments
   where DSCP markings frequently help, though.  These include:

>The sentence "These code points are solely defaults." in the 
>introduction is terse, and I suspect it won't translate well. Consider 
>calling out what the consequences of that statement are more simply, 
>even if it takes more words.
How is this?

         This document describes a
         subset of DSCP code point values drawn from existing RFCs and
         common usage for use with WebRTC applications.  These code
         points are intended to be the default values used by a WebRTC
         application.  While other values could be used, using a
         non-default value may result in unexpected per-hop behavior.
         It is RECOMMENDED that WebRTC applications use non-default 
values
         only in private networks that are configured to use different
         values.

Paul

---

From: Jari Arkko <[email-masked]>
Date: Wed, 18 May 2016 15:32:46 -0400

Thanks for the review, Paul, and thanks for the updates, Paul! Are we happy with the changes?

Jari

---

From: Robert Sparks <[email-masked]>
Date: Wed, 18 May 2016 15:37:34 -0400

This works for me (and I apologize for the slow response, I've been 
offline).

RjS

On 5/2/16 10:18 PM, Paul E. Jones wrote:
>> discusses. Other cases may possibly exist, but are expected to be 
>> rare" or similar.
>
> How about this:
>
>> introduction is terse, and I suspect it won't translate well. 
>> Consider calling out what the consequences of that statement are more 
>> simply, even if it takes more words.
> How is this?
>
>         It is RECOMMENDED that WebRTC applications use non-default values

---

From: Robert Sparks <[email-masked]>
Date: Wed, 18 May 2016 15:38:04 -0400

> Thanks for the review, Paul, and thanks for the updates, Paul! Are we happy with the changes?
My comments have been addressed.