Re: [rtcweb] Protesting the QoS document decision

Wesley Eddy <wes@mti-systems.com> Thu, 14 November 2013 17:19 UTC

Return-Path: <wes@mti-systems.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D3D821E80D2 for <rtcweb@ietfa.amsl.com>; Thu, 14 Nov 2013 09:19:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.843
X-Spam-Level:
X-Spam-Status: No, score=-1.843 tagged_above=-999 required=5 tests=[AWL=0.757, BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Tl+Wfm2YTMh for <rtcweb@ietfa.amsl.com>; Thu, 14 Nov 2013 09:19:54 -0800 (PST)
Received: from atl4mhob16.myregisteredsite.com (atl4mhob16.myregisteredsite.com [209.17.115.54]) by ietfa.amsl.com (Postfix) with ESMTP id AD3A921E8056 for <rtcweb@ietf.org>; Thu, 14 Nov 2013 09:19:54 -0800 (PST)
Received: from mailpod.hostingplatform.com ([10.30.71.204]) by atl4mhob16.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id rAEHJr20026496 for <rtcweb@ietf.org>; Thu, 14 Nov 2013 12:19:53 -0500
Received: (qmail 6580 invoked by uid 0); 14 Nov 2013 17:19:53 -0000
X-TCPREMOTEIP: 107.45.110.113
X-Authenticated-UID: wes@mti-systems.com
Received: from unknown (HELO ?192.168.43.65?) (wes@mti-systems.com@107.45.110.113) by 0 with ESMTPA; 14 Nov 2013 17:19:52 -0000
Message-ID: <5285062F.9070204@mti-systems.com>
Date: Thu, 14 Nov 2013 12:19:43 -0500
From: Wesley Eddy <wes@mti-systems.com>
Organization: MTI Systems
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>, Harald Alvestrand <harald@alvestrand.no>
References: <5283DF61.9060807@alvestrand.no> <52848582.1070408@ericsson.com>
In-Reply-To: <52848582.1070408@ericsson.com>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>, rai-ads@tools.ietf.org, tsv-ads@tools.ietf.org
Subject: Re: [rtcweb] Protesting the QoS document decision
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 14 Nov 2013 17:19:59 -0000

On 11/14/2013 3:10 AM, Gonzalo Camarillo wrote:
> Hi Harald,
> 
> thanks for your email. I will touch base with the TSV ADs and with Wes
> (former TSV AD) and get a status update on this piece of work. It will
> take a few days, though (when Martin will be back, as Spencer also
> mentioned in this thread). We will keep the group posted.
> 


I was mostly guilty for advocating that this be moved over, so
no need to bother Martin in order to explain the history.

It was creating some confusion between multiple WGs at the IETF
meeting, particularly with regard to what RMCAT was doing, what
RTCWEB was doing, and how DiffServ actually works.  So we had a
quick discussion about moving it to TSVWG between the available
set of:
- authors
- RTCWEB chairs
- TSVWG chairs
- RAI ADs
- TSV ADs

At the time that it was moved over to TSVWG, I had sent the
TSVWG a description of why:
http://www.ietf.org/mail-archive/web/tsvwg/current/msg11631.html

I agree that this obviously should have also been discussed in
the RTCWEB WG.  If all interested people weren't aware of the
move, then that is bad, and should be corrected now.

As for the current status, the document does not yet address
core issues that have been pointed out.  See, for instance:
http://www.ietf.org/mail-archive/web/tsvwg/current/msg12042.html

People interested should work on this in TSVWG.  There does not
seem to be any reason for RTCWEB to be gated on it, as it has zero
impact on interoperability or the protocol.  Having a normative
reference to it is not correct and is easy to fix.

-- 
Wes Eddy
MTI Systems