Re: [rtcweb] Protesting the QoS document decision

Magnus Westerlund <> Fri, 20 December 2013 08:34 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 00DD81AF70E for <>; Fri, 20 Dec 2013 00:34:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.851
X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id XP1G2JpgMw_Q for <>; Fri, 20 Dec 2013 00:34:53 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id DC7A11AF70D for <>; Fri, 20 Dec 2013 00:34:52 -0800 (PST)
X-AuditID: c1b4fb25-b7eff8e000000eda-98-52b40129ed66
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 35.20.03802.92104B25; Fri, 20 Dec 2013 09:34:50 +0100 (CET)
Received: from [] ( by ( with Microsoft SMTP Server id 14.2.347.0; Fri, 20 Dec 2013 09:34:31 +0100
Message-ID: <>
Date: Fri, 20 Dec 2013 09:34:49 +0100
From: Magnus Westerlund <>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: Harald Alvestrand <>, "" <>, <>, <>
References: <> <> <>
In-Reply-To: <>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprMLMWRmVeSWpSXmKPExsUyM+Jvra4W45Ygg/UvBSyO9XWxWezdPo/R Yu2/dnaLafM+MjqweFyZcIXVY8mSn0weXy5/ZgtgjuKySUnNySxLLdK3S+DK+HRrPkvBY5OK U6suszQwbtXqYuTkkBAwkejt3MYCYYtJXLi3nq2LkYtDSOAQo8T19ncsEM5yRokdvbvZQKp4 BbQlTi+fANbBIqAqMXdVOzOIzSZgIXHzRyNYjahAsMStaQ/YIeoFJU7OfAJWLyLQzihxuzcT xBYWsJJ4cOskWL2QQLbEhOVrGEFsTgFdiVuz3gLFOYAuEpfoaQwCCTML6ElMudrCCGHLSzRv nc0M0aot0dDUwTqBUXAWkm2zkLTMQtKygJF5FSN7bmJmTnq50SZGYMAe3PJbdQfjnXMihxil OViUxHk/vHUOEhJITyxJzU5NLUgtii8qzUktPsTIxMEp1cC4xcvlcEVw9RVRs5m9N2411Ct0 q2Z/LDrH2XYz/Ki3zJoLny7Ezlxwao3HsUz/zIPX6y5YZjfNs7eqt41efTLjXuMy5xX7Mq9x /t651iV3h+vM/Pi0r8JBpgkemh9ZRHp3t+34ddTt3oXEqQV6h1dV90y8Many/fZ5uRYxNd9Z tzHIbXuQpmqnxFKckWioxVxUnAgAQmcqkCYCAAA=
Subject: Re: [rtcweb] Protesting the QoS document decision
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 20 Dec 2013 08:34:56 -0000

On 2013-12-20 09:20, Harald Alvestrand wrote:
> Thank you, this resolves my practical issues, and the acknowledgement of
> the communication & transparency issues seems adequate to help prevent a
> repeat of this stall.
> I'll also take this as instructions to the group to replace all
> references to -rtcweb-qos  with referenes to draft-dsheikan (or its
> successors).

Yes, as this is the document we currently have. If the WG sees a need
for a document that has another scope, then I believe each author and
the WG will need to consider which of the document is the appropriate
one to reference in their contexts.

Merry Christmas

Magnus Westerlund

> On 12/19/2013 05:12 PM, Magnus Westerlund wrote:
>> Harald, WG,
>> We apologize for the failure to inform and keep the WG aware of the
>> discussion and TSV ADs request to move draft-ietf-rtcweb-qos with it's
>> then content to TSVWG. A request chairs and authors accepted in the end
>> more than a year ago. This is clearly a failure by us chairs to ensure
>> sufficient transparency and a venue to timely protest that decision.
>> After reviewing this with TSVWG chairs, the non-recused RTCWEB chairs
>> (Magnus and Ted) do believe that the DSCP aspects require TSVWG action,
>> and that draft-dhesikan belongs there as a result. If there are aspects
>> of the QoS approach that are outside draft-dsheikan's current remit,
>> those might still belong in RTCWEB. We might also be able to pull some
>> pieces out of draft-dhesikan for local progress, but we can't take the
>> full document as it stands. Thus nothing prevents the WG from creating a
>> new QoS related WG document assuming a different scope than the previous
>> document. If any WG participants see a need for such a document they are
>> welcome to submit an individual document as a proposal for such a WG
>> document.
>> We note you protesting the lack of progress of draft-dhesikan in TSVWG,
>> and state that as one reason why this document should be in RTCWEB WG.
>> After reviewing mailing list discussion, meeting minutes and talking to
>> the TSVWG chairs, it appears that the main reason it hasn't been making
>> more progress have been the lack of an draft update to resolve the issue
>> raised in the Berlin TSVWG meeting. We have good hopes that the document
>> can make fair progress in TSVWG assuming author and RTCWEB participants
>> make timely contributions to the document.
>> Harald, does this provide a clear enough way forward or, do you wish to
>> continue your appeal?
>> Best Regards
>> Magnus Westerlund
>> Ted Hardie
>> On 2013-11-13 21:21, Harald Alvestrand wrote:
>>> This mail concerns both administrative and technical issues, which is
>>> why it is explicitly copied to the ADs of RAI and TSV. I hope I have
>>> managed to keep them separate in the message.
>>> Magnus said in an email yesterday, concerning draft-ietf-rtcweb-qos:
>>>> Okay, we might not have been public enough on this. It was requested by
>>>> the Transport ADs quite some time ago that doing the QoS document in
>>>> our
>>>> WG was not appropriate and requested us to direct the document to
>>>> TSVWG.
>>>> Which was done, and where it hasn't made progress.
>>>> You might have noted that James Polk did comment in the milestone part
>>>> in the monday session of IETF88 about our QoS milestone should be
>>>> killed.
>>> I want to protest this - both practically and formally.
>>> To get the formal stuff out of the way first:
>>> Changing the deliverables of the working group *without telling the
>>> working group* is totally inappropriate in an open, consensus-driven
>>> process.
>>> Changing the deliverables of the working group *without telling the
>>> working group why* and *without allowing those reasons to be debated* is
>>> totally inappropriate in an open, consensus-driven process.
>>> I protest against this action.
>>> ACTION REQUEST 1: I request that this decision be declared null and
>>> void, and that the relevant ADs send out a message to RTCWEB (and TSVWG
>>> if appropriate) *PROPOSING* such an action, and giving a reasonable
>>> timeline for when they will make a decision based on mailing list
>>> feedback.
>>> In practice:
>>> The draft as it existed before its untimely demise consisted of two
>>> things:
>>> - A description of how QoS mechanisms could be useful in the RTCWEB
>>> use case
>>> - A description of existing mechanisms that could be appropriate for the
>>> RTCWEB use case
>>> The first one is clearly something that needs RTCWEB consensus. It seems
>>> to have no need for, nor likelyhood of gathering interest enough for, a
>>> TSVWG consensus.
>>> There could be some argument that the second part needs TSVWG consensus,
>>> especially if it was redefining any mechanisms, or it was making choices
>>> between mechanisms where TSVWG had strong opinions about which
>>> mechanisms should be chosen, but had not chosen to document that in any
>>> document on which IETF consensus had been declared (that is to say,
>>> existing RFCs).
>>> My archive shows 36 messages where the title refers to this draft. It
>>> shows no messages declaring that feedback has been incorporated and
>>> calling for new review - something that is usually necessary to get a WG
>>> consensus on any document. The debate hasn't been conclusive, but then,
>>> it hasn't been pushed hard either.
>>> The people who know how RTCWEB works are in this working group. Some of
>>> them may be in TSV, but I think the locus of knowledge for saying what
>>> QoS mechanisms are appropriate for RTCWEB are here, not in TSV.
>>> This results in my second request.
>>> ACTION REQUEST 2: I request that the chairs declare that based on the
>>> debate about the QoS functionality so far, the document should be
>>> resurrected, and will continue to be  worked on in the RTCWEB working
>>> group, bringing in advice from TSVWG as required to make sure the
>>> descriptions of underlying mechanisms, and the choice of such
>>> mechanisms, is correct and appropriate.


Magnus Westerlund

Multimedia Technologies, Ericsson Research EAB/TVM
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: