[rtcweb] Protesting the QoS document decision

Harald Alvestrand <harald@alvestrand.no> Wed, 13 November 2013 20:22 UTC

Return-Path: <harald@alvestrand.no>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 225B611E8180 for <rtcweb@ietfa.amsl.com>; Wed, 13 Nov 2013 12:22:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.549
X-Spam-Status: No, score=-110.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id UHOr+Y3XnzQA for <rtcweb@ietfa.amsl.com>; Wed, 13 Nov 2013 12:21:57 -0800 (PST)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no []) by ietfa.amsl.com (Postfix) with ESMTP id 00CA011E8107 for <rtcweb@ietf.org>; Wed, 13 Nov 2013 12:21:57 -0800 (PST)
Received: from localhost (localhost []) by eikenes.alvestrand.no (Postfix) with ESMTP id 6A32339E216; Wed, 13 Nov 2013 21:21:55 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no
Received: from eikenes.alvestrand.no ([]) by localhost (eikenes.alvestrand.no []) (amavisd-new, port 10024) with ESMTP id a92hDRTgbnFA; Wed, 13 Nov 2013 21:21:54 +0100 (CET)
Received: from [] (unknown []) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 8938F39E209; Wed, 13 Nov 2013 21:21:54 +0100 (CET)
Message-ID: <5283DF61.9060807@alvestrand.no>
Date: Wed, 13 Nov 2013 21:21:53 +0100
From: Harald Alvestrand <harald@alvestrand.no>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: "rtcweb@ietf.org" <rtcweb@ietf.org>, rai-ads@tools.ietf.org, tsv-ads@tools.ietf.org
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: [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: Wed, 13 Nov 2013 20:22:03 -0000

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
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.

Surveillance is pervasive. Go Dark.